rhymepurple

This would require the main proxy running as root or with some other sort of elevated privileges to allow cross-user network access though, right? If so, wouldn't that essentially make the user-specific reverse proxy unnecessary in most cases?

I think this is what OP was originally trying, but this approach breaks when each service's Podman service runs on its own localhost user.

I didn't see the logs when I originally posted. However, I'm not sure what the logs indicate. It could be that nginx successfully received the request and received an authorization error from Podman's networking stack then returned a 503 error to the client (or logged the 503 response that was returned to nginx).

I'm not trying to convince you of this solution (I personally don't like it), but I am curious what didn't work for you. Were you unable to get the reverse proxy to serve each service? Were you unable to have the services behind the reverse proxy to talk to each other?

This is due to a security design deicison of Podman. Each user's network(s) is only available to that user. This is great for most services, but can cause issues for some services - especially reverse proxies. Unfortunately, I'm not aware of an ideal solution. The only solution I've seen is moving the reverse proxy to another host and exposing the services' ports on the localhost. I hope someone can provide a better solution!

I assume you mean the settings within the instance (or more accurately, your session) of Invidious states that it proxies the activity. However, if you're just referring to Invidious itself, this is a setting that can be enabled/disabled for the entire Invidious instance. The instance's default setting could also be disabled even if the instance supports proxying. Regardless, you could verify Invidious is proxying everything by reviewing the networking tab of your browser's developer tools to confirm that all traffic is with your Invidious instance.

Given everything you said, it sounds like any recommendations you receive within Invidious is most likely due to the collective activity of all users on that Invidious instance. Additionally, any recommendations you receive directly on YouTube is likely from other information YouTube collected about you (not your Invidious activity).

While I cannot definitely confirm that this has absolutely nothing to do with Framework, I cannot imagine anyone knowledgeable about this arguing in good faith that Framework is complicity and secretly acting to violate your privacy.

There are no "official" or "trusted" instances. The instances listed on Invidious' site meet (or should meet) a certain set of criteria. Several of those items could be considered bare minimum for hosting any website over 10 years ago (eg: be served via https, must have a domain) or are about other availability metrics. I'm not saying you shouldn't trust any of those instances, but just want to clarify that it doesn't necessarily mean that the instances are endorsed or trusted by the Invidious team. Instead, it is just a directory of instances that meet some minimum criteria.

I didn't check all of the instances currently on the list, but instances that were previously on the list did not proxy all traffic from YouTube. Since this is not an requirement to be included on Invidious' list of instances, I assume that there are likely one or more instance that is not proxying the YouTube traffic.

If the traffic is not proxies, then your browser will interact directly with YouTube's servers for some content (typically the actual video content). While this prevents you from interacting with YouTube's frontend (and all the tracking that comes with that), it does not prevent YouTube from identifying which videos were served to your IP address, which parts of the video were requested, or other identifying information.

Invidious is more private than using YouTube directly or even most other 3rd party services, but it may not completely prevent Google from tracking you depending on it's hosting, configuration, and usage.

• Are you running the Invidious instance yourself?
  • If so, are you running it on a VPN?
• Are you the only user on this Invidious instance?
• Is Invidious proxying all activity?
• Is the Invidious instance outdated, customized, or noticeably different from most other instances?
• Do you click on links from comments or video descriptions?
• Do you first obtain YouTube links or video IDs and then convert them to an Invidious link?
• Are you watching videos with little traffic or videos that are private?

There is also the possibility that Invidious makes the recommendations itself, independently of YouTube. Clearing Invidious cookies and all site data should mitigate this, but if you are signing into Invidious then doing that won't accomplish much.

Additionally, Invidious may make the recommendations based on all its users' activity. If you're using an instance with little activity then the recommendations may be more heavily skewed to your activity. There's also the possibility that other users of your Invidous instance share interests with you.

Lastly, it is also possible that YouTube's recommendations are based on unrelated factors.

• YouTube may be recommending videos because they are genuinely popular or are trending in your area.
• YouTube may be recommending videos based on other users' YouTube activity on your IP address.
• YouTube may be recommending videos based on other internet traffic YouTube/Google/Alphabet has associated with your account, fingerprint, or IP address.

All of this, including several other possibilities not mentioned, is far more likely than Framework shipping a hardware/firmware backdoor that hasn't been caught yet which allows Framework to monitor your Invidious acitivity so Framework can sell/share your data back to YouTube. This is a very niche use case that would be extremely expensive, difficult, and risky for Framework (or any other computer manufacturer) to accomplish. Any money Framework makes from this would likely not even cover the cost to do this.

The Framework "backdoor" that you heard about is likely the data breach that recently impacted Framework. This data breach occurred due to a phishing attack on an employee of the accounting firm contracted by Framework.

I generally agree with this. Unless OpenAI has a track record of being poor stewards of open source projects, then right now the concern is mostly FUD.

However, this is a bit aggressive. It is appropriate to be skeptical about the intent of a controversial company acquiring another company that made a few popular open source projects or of the future state of those open source projects.

Just because a popular open source project is well liked today doesn't mean the community will be happy with the project in the future or even that the project will forever remain open source. Some notable recent examples include Redis, Terraform, and CentOS.

That's correct, but the XMPP portion of this communication chain is just your device to the JMP service. Any messages sent or received to another phone number are delivered via SMS/MMS. As a result, those messages can be read by unrelated 3rd parties. I assume something similar is possible for voice calls as well (or at the very least the call start/stop times and the other number on the call can be determined).

Essentially this just shifts trust from a mobile phone carrier to JMP. However, I understand that it may be more challenging to hack a VOIP number than perform a SIM swap attack. Another benefit of JMP for privacy is the more challenging tracking of location for a JMP phone number.

I'm not saying that using JMP is bad. I am saying if you need a secure and private way of messaging someone then this is not the best solution.

It depends on what your threat model is. For example, do you want to mitigate the ability to easily link accounts and other information to you based on a single phone number? If so, then this will help with that assuming you (at least temporarily) use multiple numbers through JMP. On the other hand, if you want your communication to be private then there are better alternatives.

Ultimately, this is similar to using a privacy respecting email provider over gmail. Unless you take some additional precautions, your communications have a similar security/privacy exposure. It can be an improvement (assuming you trust JMP), but it is not the best means of communication in terms of privacy.

I see there are a few performance comparisons, but I wonder how this compares to ty. I guess it may be a while before we can really compare the two since they're both in alpha/beta.