Proton announces release of a new VPN protocol, "Stealth" (opens in new tab)

There is no comparison between Crypto AG and us. Our encryption occurs client-side and our cryptographic code is open source and backed by third-party audits: https://proton.me/community/open-source

Do you really expect anyone to be able to answer this? How would anyone ever know before it's too late? Nobody would use it if they knew, and they know that too.

People have too short memory to remember this

Do you even read your own source? Even the truncated URL says Protonmail... a search for "VPN" in that article comes with "Yen said a similar order would also not be able to provide ProtonVPN metadata, as VPNs are subject to different requirements under Swiss law."

Sure you can refuse to believe the company's statement, but your comment is based on your (maybe deliberate, conveniently) misunderstanding of mail vs VPN...

Got any details, reference, quote, or analysis on the CS claim?

AFAICT, the only discriminating factor is lack of solicited third-party security audits. Which I don't think implies being "untrustworthy".

https://www.privacyguides.org/en/vpn/#marketing

https://discuss.privacyguides.net/t/why-is-vpn-providers-lik...

(PIA/Kape I get and relevant information is easily discoverable available on controversy surrounding them and their owners)

i mentioned pia cryptostorm etc (or whatever) in the context of onion plus vpn multihop.

I'd argue physical channels and access are even less secure. People are broken easily (you can't trust anyone) and surveillance is everywhere and more sophisticated than you imagine. My first job was at a US-based video surveillance company owned by Israelis and used by casinos, stadiums, and entire cities. I have an idea of what it's capable of :)

What we need is a truly secure and private method of communication and payment. We're close on both.

you misunderstand, the homeless man signs an agreement to be the authorized agent of contact that is able to tell the data center when authorized servers will arrive by mail and when they need to be sent to a different location. do not collocate servers in data centers run by homeless men, as there is less chance of fire suppression and climate control factors in their facilities (shopping carts/cardboard/tent cities). it may be fine for a startup, check your security model and postures.

Cell modem or being on someone's WiFi gives away your location though.

Because Swiss law for the two services are different, and their compelled actions for email are not applicable to their VPN services. Their public statements, audits, and track record for the two services reflect that reality.

Mullvad accepts XMR which is more difficult to trace than amazon related anything. Mullvad does however state that payment information is disassociated from account numbers 90 days after payment. Theoretically you could use any payment you like, pay the 90 day compliance tax, set a cal event, then begin using it about a week after that 90 days is up. Cheaper to use XMR.

> Wireguard sets up an IPV4 based internal network and the machine responsible for the routing MUST know the client IP that was assigned to the connecting machine.

How else would it work? You could strip the source IP, but then you couldn't get replies and you'd have a very anonymous VPN that could only be used to send UDP packets; no receiving and no TCP since even establishing TCP requires replies.

Are you referring to this issue specifically? “Wireguard leaks IP address in client mode if connection fails” https://github.com/linuxserver/docker-wireguard/issues/139

I think you need to post more context here because this doesn't make sense. We run large-scale WireGuard for hundreds of thousands of clients, and we know none of their client source IP addresses.

Yes, depends on a lot of factors like provider (different telecoms have different network settings/policies), location (GFW is multi-tiered with at least provincial boundaries, certain cities/provinces might have tighter control/policies), time/date (e.g. sensitive periods), etc. But what I'm saying is that traffic analysis is really effective. A single IP with multiple GBs on a day is on the low end and thus probably fine. GFW target potential VPN-like services which have much higher aggregate traffic over a period of time. If you have higher traffic it could trigger IP bans regardless of your custom protocol. I had custom servers setup like yours before and they die mysteriously sometimes so I had to rotate once in a while on new IPs.

I'm sure they have monitoring services to detect banned IPs and rotate on new IPs. However, in my experience, the most popular VPN providers are actually not specialized in evading GFW despite what they claim. During sensitive periods of time, most of the them couldn't be connected reliably. Those providers specializing in providing GFW evasion are called 'airports' or 'ladders' in the Chinese community and they use custom non-VPN protocols and tools for their services.

I had custom servers banned randomly in the ballpark of 100 GB / day, but your mileage may vary.

As it should be -- a government's duty is to serve its citizens, not any foreigners who happen to be visiting.

There are two types of VPN detection people are worried about:

- Endpoints (e.g. Netflix or video game) detecting VPNs and blocking users of VPNs from their server because they don't trust the user to not be bypassing their rules

- Middleboxes (e.g. airport wifi or the great firewall) detecting VPNs and blocking the user from the internet because they don't want the user to have unfiltered internet access.

The latter group have a lot more tools to see if something is VPN traffic since they have access to the entire (encrypted) traffic, so can do stuff like checking are you constantly exchanging the vast majority of your requests through a few hosts.

The former don't have as much information, but they have one really easy, really effective option, which is to contract with one of the IP classification databases that lets them see if the client is on a home internet connection. If it's not, they can just block you. Watching Netflix from your EC2 instance isn't going to be that reliable. And it's hard for the VPN providers to reliably get IPs that look residential, residential service usually prohibits such uses, companies that run both residential and business services still usually run them separately from an infra perspective as it makes their life easier, and even if you found an ISP to co-operate and let you use their residential addresses to run your VPN, the databases can just mark the entire ISP as having this kind of use, which would hurt the ISP's users, which counts as a strong disincentive for an ISP to become known for this kind of business.

So for VPNs to bypass blocks by remote services, it means they're going from (most legitimate) shopping around ISPs willing to host them on residential IPs on the down low to the more sketchy end buying residential IP traffic from places that sell residential IP space from e.g. malware or software that buries this detail in its T&Cs. There's also the Tor exit node route of using your users as a sort of mesh network to get residential IPs, but legitimate VPN providers are not going to do that because of the risk it exposes their users to legal liability.

This is not really something that can be fixed with protocol updates like Proton is doing here - the protocol updates are more about evading the middleware style traffic analysis mentioned here

FAFO. Sounds justified.