Yes, I understand your point and think it makes sense. I am focusing on the reasonableness of hiding or not hiding our real cell numbers in accounts such as Google or Apple, given that we cannot hide our real numbers from vendors, companies if we use our smartphones with physical or embedded SIMs. If Google and Apple share the numbers stored in their services with apps we download from their stores, or with other services or apps we grant access to those accounts, I would prefer not to share my real number with dozens of apps and services.

Goes to show that even a highly reputable entity like Tuta can make mistakes and not know what not to “recommend”.

Replicant is from FSF and is pretty much dead and should not be used.

fria: > for some reason they still do it. That’s one of the great mysteries. Even banks are adamant for it. Some bank apps are so “face hugging” that they tie that apps’ registration/log in of your account on it to your IMEI number so if you try to log in with another device, you’re SOL. They also don’t let your copy paste your user credentials for “security” reasons so ironically people are “forced” to use simple passwords they can type in faster. Results in poorer security, ironocally.

It’s dead. And someone like Tuta really shouldn’t be recommending it. And I have never even heard of that second option..

Depends how much you care about that account. The number can be used for account recovery, so putting in a random number could mean you aren’t able to get into the account at some point and it could mean someone else can. I don’t think phone numbers should ever be used for authentication personally but for some reason they still do it.

Its always best to ensure as little PII or any relevant info is gathered by apps or operating systems. If you can ensure of it, then that’s ideal. username0990: > I wonder what privacy benefits we gain by not using our real numbers in the accounts we log into on these devices. It’s like this: some of these companies have a lot of your info but why let any more apps/services get the same? Don’t fall for sunk cost fallacy here.

As far as I understand, applications with the relevant permissions in Android can already read the real cell number of the SIM card inserted into the device. Is Google trying to trick me into revealing my real number with this QR Code verification? - #7 by SkewedZeppelin I think the operating system itself and, naturally, vendors such as Google and Samsung are able to do this. The same scenario holds true for iOS. Perhaps fewer applications can obtain permission to read the real cell number of the SIM card inserted into the device, but I’m not sure, as I’m not an experienced or longtime user of iOS. If Google, Apple, Samsung, and other vendors already know our real cell numbers, I wonder what privacy benefits we gain by not using our real numbers in the accounts we log into on these devices. Is it worth the extra costs to add other entities like SMSPool that we can trust?

Yeah, I thought Calyx was on hold.

It is embeded in so many sites it would be widely impractical. Plus they would lose a lot of access to older devices especially old smart TVs.

CalyxOS?

tropics8997: > It makes me wonder, how do these companies make money off keeping people as long as possible on their platforms? Ads. tropics8997: > if I were to use Facebook with Ublock Origin in a privacy respecting web browser, how can they make money off me? This still doesn’t block Meta ads can they? I don’t use it so can’t say how it looks on the platform but can it fully block the ads? Meta has multi billion user base. They can afford to make many billions and also spend billions to ensure users stay on their platform. There is so much info and many videos out there that talks about this and I won’t even begin doing the topic justice if I explain it here. Also, there’s so much to say here. I recommend researching how Meta makes money. Caution: it will make your skin crawl.

Okay, and how is what they’re saying wrong? Give explanations.

A similar issue is DNS leakage on Android, which remains unresolved in Android 15. But since this is an OS issue and not a VPN provider issue, it has not affected the recommended list. I believe the same applies to this current issue. It’s information worth noting, but I don’t think it warrants removal from the recommended list.

anonymous520: > Feel free to correct me if I misunderstand Yeah, see: Mention kill switch leaks caused by OS limitations > There’s 2 issues here: > > 1. The VPN apps _not_ implementing “killswitch” supported by OSes (regardless of whatever valid justification). > > * This, presently, is PG’s minimum criteria for recommended VPNs. > > 2. The VPN apps _not_ being able guarantee that no traffic will leak (which they can never, unless they have privileged access, which they don’t on most OSes including Android and iOS). > > > Issue #2 on Android, for instance, is a limitation stemming from sandboxes an app might be subject to. > > Both issue #1 & #2 are a genuine concern, if your threat model says, “Use VPN to hide traffic from ISP”, when no such thing is _possible_ without installing VPN software on the router & hoping the router itself does not have “holes”. This puts in to question the 4 points PG today presents as justification for using a VPN

offtopic (click for more details) khoa: > focused on the small things and missed the big What’s that big picture? Depending on how VPNs are marketed, “killswitch” may or may not be important; but, the case today is, they seem to be important given how they are marketed/sold: Change Proposal on Privacy Guides Recommended VPN Providers Page - #37 by ignoramous

ignoramous: > But changing criteria so also means, VPNs will go from “hide your traffic from ISPs” to “hide certain traffic from ISPs, some of the times”. Feel free to correct me if I misunderstand but to me it seems the issues stem from certain OS issues, not from something wrong with the VPNs that make what PG has said less true. If that’s the case it seems to me what needs to be added, in addition to moving the kill switch criteria to a best case, is a warning saying something like “if your threat model requires a VPN we cannot recommend iOS, MacOS, or AOSP based devices without GrapheneOS due to upstream issues affecting kill switches”.

Register3435: > strategy that can fully mitigate a data breach from leaking information about you if you send from an alias to an alias, nobody will known who you’re sending the email to (given the content of it doesn’t share personal info) hence anonymity is preserved.[1] [email protected] ⇆ [email protected] Otherwise, don’t use email because it’s not a secure protocol but rather E2EE instant messaging apps. * * * Might be a useful article overall: Email Security: Where We Are and What the Future Holds - Privacy Guides * * * 1. and you can always buy a gift card without giving away anything personal like banking details ↩︎

Cloudflared/Tailscale are about ease of use and security. If you go the Wireguard/Netbird path, you have the privacy on top of it given a bit more friction to set it up yourself (share it to your family afterwards).

lone-cloud: > It requires for the user to open their terminal, make sure whatever they’re trying to run is executable (chmod a+x) and then to write out the path to script (unless it was previously added to PATH) I’m not talking about letting them run a bash script in itself, more of installing the tool and so that it launches a UI like a CLI, no need for badass WebGL is all I’m saying. :3 lone-cloud: > Where it matters is that python requires a runtime/interpreter to run. It must be either pre-installed or you have to use something like PyInstaller to package your app which will explode its size. Go doesn’t have this problem. Agreed, but OP is not a Gopher and that in itself is enough friction. Imagine needing to be a car mechanic before you need to change the oil of your car. lone-cloud: > I think the bloat is worth it for a cross-platform, consistent GUI given that you’re creating a project that needs a GUI. Fancy buttons + maintenance of all of it is not worth it if you have no JS-ecosystem experience. CLI-like is plenty enough given the limited needs. lone-cloud: > AFAIK, this is a custom feature on Windows that’s not enabled by default. Between enabling that and having a UNIX-compatible running program VS wrapping all of it in a shell of bloat, not sure which one is worse.

I agree I’m definitely not going to force it it really try to push certain levels of privacy beyond basic and see if that gets anywhere

Register3435: > not being end-to-end encrypted Messages (including metadata) in ProtonMail inboxes are still stored with zero-access encryption after being received though. Register3435: > gmail and then use an email client like Thunderbird to automatically download and remove the emails from the server That’s not notably any better than using Proton. Google still gets to scan any incoming messages, and is more likely to retain some data about that even if the full message gets removed.

To be honest, what I’d rely on here is that even if you trust Google, you can’t trust that they’d never be hacked. Maybe show/send them an article on the salt typhoon telecom hacks to see how bad it could get and explain that Google’s such a juicy target. The Snowden NSA leaks are also a good example. But at a certain level, I just accept that my family and friends are adults and can make their own decisions. You can give people information, but they really do have to “want” to do something themselves to make the changes sustainable.

Hello, I am trying to pick a better email provider. My question is, is there actually an email provider or strategy that can fully mitigate a data breach from leaking information about you? I ask this because to my understanding, Protonmail’s protection is weakened by the headers not being end-to-end encrypted ( Proton Mail encryption explained | Proton ), which means that (however unlikely), a data breach could expose who you’ve been emailing with. To me, that seems like a significant weakness. It makes me think that maybe the best strategy would be sticking with a standard mail provider like gmail and then use an email client like Thunderbird to automatically download and remove the emails from the server. But I was hoping there might be a less clunky alternative.

https://www.nytimes.com/2025/12/23/technology/texas-app-age-law-blocked.html This appears to be a major victory for privacy. Of course, it’s also to Apple and Google’s benefit, but requiring an ID to access any app is just insane. Glad to see the court has landed on the right side of this, at least for now.