I know it may be nitpicking or just pedantic, but they say on their page "Your data also never goes to the cloud, as we own and manage our own server infrastructure." But...if you upload your data to their servers (so it can go to all your devices), isn't that the "cloud"?
I think in general one might consider "the cloud" to be virtual resources on hardware shared with third parties. So of course AWS/GCP/Azure, but DigitalOcean would probably also qualify since to my knowledge droplets are virtual servers on shared hardware.
Although renting virtual resources on shared hardware can be convenient (much easier to provision virtual resources than real servers), there are a couple of drawbacks. Most importantly, particularly from a password management perspective, running on shared hardware could expose your virtual resources to hardware exploits like the row hammer effect.
Yes, this is indeed what we mean. Proton does not use third-party providers for hosting encrypted user data. So none of the providers that people typically consider to be "cloud" such as AWS. What we do instead is own and operate all of our physical server hardware and network equipment in datacenters in Switzerland and Germany.
So if you store a file in OneDrive or Google Drive, you'd say it's not storing a file in the cloud? No third parties involved there after all. Just you, the service provider, and the hardware owned and operated by said service provider in their own datacenters.
I'd say there are colloquial and technical definitions of the word. Colloquially people have taken to referring to servers not their own, particularly operated by Amazon/Google/Microsoft, as "the cloud", such as OneDrive and Google Drive. I might even use the word colloquially sometimes. But when technical precision is needed, "cloud" refers to virtual resources on shared hardware.
Applied to this particular context, the colloquial interpretation doesn't make any sense whereas the technical interpretation does.
Im guessing they're using cloud in the classical sense of the term, as in they own their own infra and rack servers which are colocated into a datacenter and so don't depend on third parties for infra and nobody else besides them should have access to your data
I think you're conflating "cloud" to mean any computer on the internet. I think that's generally a fine thing to do most of the time. But, cloud used to mean something a little different and it's been lost to weird arguments it seems.
I look at the cloud as something I can spin up a new service or VM very quickly. Think AWS, or Azure or whatever other service lets you quickly and easily deploy something.
We've now gotten to the point where people are saying any computer on the internet is "the cloud" and I don't think that's right or wrong necessarily, but for the sake of Hacker News, I do wish we were a little more specific.
That said, I think this argument from Proton is bordering on funny word play to make it seem different.
> I think you're conflating "cloud" to mean any computer on the internet.
If you read "cloud" as "somebody else's computer" it entirely depends on perspective.
If you're running a service on your own hardware in your own datacenter, you're clearly not cloud.
However, if you're a user of that same service, and your data lives on some computers that are running in someone else's data center, then for all intents and purposes your data is "in the cloud". It's indistinguishable if the service you're using is using AWS/Azure/etc, running their own hardware, and/or storing data on something like S3.
There's of course a mix of in between stuff that makes this 10x more complicated: if it's a rented server in somebody else's datacenter, are you "cloud" or not? What if it's your hardware, but somebody else's datacenter? What if you store backups on S3?
But, sure enough, bulk import uploads all of your passwords to their servers, even though there's just no rational reason why a server "somewhere, not here" needs to play man-in-the-middle to all your logins. To avoid it, you have to go one by one (even then there's no assurance, but the official docs do not say it's sent up to their servers).
It depends what you mean by data. Metadata maybe, but I'd think they're meaning that once your passwords data is encrypted (on your device), it is no longer your data without the encryption key?
I tend to think this is a fair trade-off for services like this because:
1) for end-to-end encrypted services, I think what you most want to verify is: is my data actually being encrypted with my keys before being sent over the network, which open-source clients allow you to do
2) you can't personally verify what code is running on a company's servers anyway
and to a lesser extent:
3) there could be legitimate security reasons to keep server code confidential
4) there could be legitimate competition reasons to keep server code confidential
Overall I think it is a fine tradeoff. And of course, there is already a great "full-stack open source" password manager out there, in Bitwarden.
There's an argument to be made we shouldn't call the whole thing "open source" and perhaps call it "open client" or something.
While it is theoretically possible that the proprietary software is well-written, I would feel much safer if “defense in depth” were achieved by opening the server code and exposing it to as much audit and commentary as possible.
There's a big difference in that with bitwarden you can host the server part yourself - and that is a great guarantee for continuity of service (and bug fixes) if upstream goes away for some reason.
We appreciate your feedback. We wanted to let you know we're currently working on a new app. In general, the Linux app does lack features in comparison to our Windows application, this has to do mainly with 1) the fact that the Linux team is quite small compared to the window team and 2) the linux team is quite recent. Differently than the other platforms, Linux is an extremely fragmented OS. To support it means supporting a galaxy of combinations among distributions, network subsystems, service subsystems, key stores, desktop environment. In the last year we have been working hard to re-build the foundations of a new Linux application from the ground up. The new app is designed to be solid, extensible, and future-proof, and will allow our engineers to ship faster new features, like WireGuard, and all those that are presently missing from the current app. The alpha has been released, which you can check out here: https://protonvpn.com/support/linux-prerelease/. We're working towards a public beta. Rest assured, our aim is to have the linux app on par with the other clients. The new version (v4) is very flexible and it will be much easier for the community to contribute.
Thank you for the comment! I truly wish you all the best, I've been a customer since you started. But not a VPN customer anymore.
You might suggest your support team repeat what you said rather than an endless loop of submitting logs with no timeline for a fix or obvious intent to release one at all. In lieu of any other information or even meaningful acknowledgement of the problem, I gave up and switched to mullvad. I waited three years for this to work right and your comment is the first I've heard that there is even a Linux team working on it.
I'm using the most recent Ubuntu LTS version recently reinstalled with no other customization to the network configuration. This shouldn't be a hard target to make work. And to be clear, this is two different Ubuntu desktops with different CPU vendors manufactured seven years apart. Maybe it's just me but when I get the same issues over clean reinstalls of the OS over multiple years and multiple computers using one of the most popular distributions...
I dunno, but releasing (at least three!) new offerings while I'm sitting here for years sending bug reports sends a message about priorities.
They didn't even feel it was worth mentioning that there is an alpha to test! So bad!
Any idea if the new one removed all the dependency on systemd? I know it's the most common among distributions, but plenty of popular ones are using OpenRC, for example, and can't use their client at all because of it.
It’s okay if you use a regular OpenVPN client, but yes I agree that they could at least clarify that the Proton VPN client is broken for most Linux use-cases.
"Logical server not found" happened 132 times while out of town for two days. I also use an Ubuntu LTS pretty recently reinstalled with minimal network customization, so I guess that other person was very lucky. This happens on two different Ubuntu computers with different graphics cards and CPU vendors so I don't think I'm imagining things.
If I enable the kill switch, it can convince itself there is no network connection (for itself) because of its own kill switch. I turn the kill switch off and back on and it's fine. That's ridiculous.
They only support udp and tcp in their Linux app. The Android app literally has more features and stability.
On the other hand, now that I've switched to mullvad everything is at least apparently fine. I've been submitting error logs to proton for years, I was one of their first customers and really really wanted them to be good. Instead they just ask me to switch between tcp and udp over and over to provide new logs despite not installing a new version. It's pathetic.
And no, I don't buy the Linux market share thing when it's a VPN! Lol, it's not a video game. Their competitors seem to work great and value the Linux market. Years is enough patience, they redesigned their logo, released drive, and released this without fixing the basic issues with their existing products.
I'm done trying, it's wasting so much time trying to deal with their support now that they clearly just don't care about it. So I'm done.
In the end, we can only rely on anecdotal evidence, but my experience is that it doesn't work on NixOS and the issues are also mostly full of people who encounter multiple problems [1, 2, 3].
I don't know what I did to get so lucky. I'm on Ubuntu and have the following versions: cli@3.13.0, protonvpn-nm-lib@3.14, proton-client@0.7.1
I've even written a couple of tools that manage my connection through the CLI automatically and it all Just Works. The only issue I ever had was when I had to force shutdown my machine for an unrelated reason and I didn't have an internet connection until I opened and closed Proton VPN. I'm sure someone smarter than me could have just reset the interface they were using or something
It's clearly a worthwhile investment of resources to their major competitors like Mullvad and IVPN, whose Linux clients are just as good as their Windows/macOS clients, if not better. In contrast, ProtonVPN's Linux app is so painfully buggy to use that you're better off just generating and using Proton Wireguard config files with command-line Wireguard instead.
Wow, I triggered a lot of linux folks. It was just a curious question. And I have another thought, not gonna answer all of you, sorry:
Wouldn't $linuxuser just not simply install something like keypass w/o having to pay for anything? How many services/apps is the average linux user paying for?
I have used linux for ages before I moved to maco. So my bet is: not much. Why then, as a company, would I try to get people to give me money when they are used to getting stuff for free? And would rather tinker with some half-arsed solution (on average) instead of paying $5 per month?
Maybe sentiment has shifted since I was around. Maybe it was the Arch crowd. But my impression was: "I want it free as in free beer and open".
It could be the other way around, their Linux market share is poor due to their poor support of it. Also, the types of people who use Linux also tend to be the types of people who would be interested in their product.
With Bitwarden supporting passkeys soon[0] is there any announcement from Proton that they would as well? Seems odd to release a password manager at this time and not mention at least eventually supporting WebAuth/FIDO2/passwordless. 1Password, Google, Apple, and likely Microsoft are all going to be having some level of passkey management. For middle of 2023, it seems like at least a good feature to mention is going to be available even if the release is months out.
It grinds my gears when password managers bundle 2FA/MFA without pointing out how this weakens the security of it, or discussing mitigations.
"Proton Pass makes 2FA easier with an integrated authenticator that stores your 2FA codes and automatically displays and autofills them."
Is it really multiple factor auth if you're using the same device for the password and automatically filling in the token? It's not a unique failure of Proton Pass but, people reading this should rightly be sceptical and this is a significant failing.
When I read their audits on Proton Drive, I see that the web page claims the PDF is end-to-end encrypted. But the link with the key in the URL hash is public. It's a poor demonstration of their technology. When I see the defects that were found by the audits, it doesn't leave an amazing impression.
It's great that they have an open source client and do open audits though.
Claiming it's open source, does come across as hype without a server too though.
Overall this is a welcome thing but it's very rough around the edges, I wouldn't feel it's a compelling offering yet with these big issues.
I saw someone refer to that at 1.5FA, and I agree with them. It's still multiple factors if the weakest link is the websites you are using your passwords on. If your password gets leaked they still need the password manager vault to get a 2fa code. However if your vault gets compromised then it's not 2FA
> Is it really multiple factor auth if you're using the same device for the password and automatically filling in the token
No it's not, but plenty of services force MFA, even if the user doesn't want it. And in those scenarios it seems perfectly reasonable to store the 2FA token in a password manager. For some things (frankly most things) 2FA isn't critical as long as you have a high-quality password.
I would also point out that given that most people:
1. Have 2FA codes on their phone (either as SMS or TOTP)
2. Have their password manager installed on their phone (if they use one)
Then in many ways the phone (something easily lost!) becomes a single point of failure anyway.
1. The case in which 2FA is really key is when you have short password (or worse, a reused password). That leaves you open to bruteforce attacks, and attacks where your email/password combination that was leaked from one service is reused to gain
access to another service. But this is generally much less of an issue with a password manager where you are likely using a long random password that is unique per service.
2. 2FA is still an extra layer on top of this, but perhaps isn't super necessary for a lot of less critical services. The chances of your password being compromised are pretty small.
3. Particularly with SMS 2FA, there may be attacks which are present for that that are not present for password-manager based TOTP. For example, attackers may be able to read SMS messages off a phone's lock screen without unlocking the phone. So it's not obvious that this is strictly worse than other options.
4. I think the ideal (aside from U2F tokens) is probably 2 separate password managers, syncing to different clouds (if syncing): a first factor one and second factor one. If one is being really picky: then on separate devices. But this seems like it's probably overkill in most circumstances. Perhaps it makes sense to do something like this for a few key accounts (email, etc), but not everything?
> But the link with the key in the URL hash is public.
Only if is shared publicly. The fragment (part of the URL after the hash) is not sent back to the server by browsers. It can also be coupled with a password which can be sent over a second channel when one is more concerned about the communication channel being compromised, than convenience.
It's really no different to having say, a password manager, and Google authenticator both installed on the phone. At that point, you might as well combine both into a single app for more convenience. And if you don't want both on your phone, then either you don't use 2FA or don't use a password manager, both of which probably leave you worse off.
Btw, the thing you mention for Proton Drive is only for files which are shared publicly. For sure the audit results are not perfect when viewed in isolation, but when compared to other password managers, it's another story.
If my Bitwarden vault gets leaked AND their encryption gets broken, I’m fucked anyway. So I might as well just store my 2FA keys in it too.
I’m more interested in protection against keyloggers, and leaks from the database of the sites I use. And for my critical accounts (Gmail…) I use a physical key for 2FA.
> Is it really multiple factor auth if you're using the same device for the password and automatically filling in the token?
Yes, the two factors are having the device with the password database on it, and knowing the unlock code for the database or being the biometrically identified owner
You might say those are 2 factors, but when it's happily auto-filling passwords and MFA codes automatically, uhh, that's a lot of trust in computer built to run arbitrary code, let alone Javascript etc in a browser environment! Maybe it's 1.5 factor? It's not truly separate. To encourage people to do this with no warning is irresponsible. Variants of timing attacks that can result in arbitrary code execution come out often. Browsers have such a massive attack surface.
Expecting users to remember individualized passwords and maintain separate authentication factors for every service is placing a lot of trust in the user! I think this is a case where it's reasonable to think that automation might actually lower the overall risk.
Furthermore I don't think maintaining individual factors for every service would protect you very much against a browser compromise.
I prefer to diversify. That's why I have Bitwarden, Tutanota, NextCloud & ProtonVPN.
IMO it does not make sense to use any service from your VPN provider at the same time - it's like not using a VPN at all since they do know your real IP. No idea why this is not known to more people.
I'm a bit skeptical about having one more solution in that space, considering that 1) password managers built in OSs and web browsers are becoming better and better (for example the new version of iCloud Keychain) and 2) passkeys are coming.
1 there really requires you to be all-in on an ecosystem though. Have an iPhone but use Windows/Linux? Doesn't really matter how good iCloud is if you can't get it to sync your passwords easily to half of your devices. I suspect Passkeys will be a similar issue that further pushes people towards single-ecosystem life, unless I'm missing something.
I agree with you, but I think a majority of users are fine with being on one ecosystem, as long as it is convenient. iCloud Keychain works on Windows and Chrome using an extension provided by Apple. It is possible to login using passkeys on another device outside of the ecosystem by using QR codes.
Oh sure, but that's not necessarily Proton's market - that's what I'm pointing towards. There's a group of folks who are both most likely to use a password manager, and also don't necessarily want that password manager attached to their Google/MSFT/iCloud accounts.
Correct me if I'm wrong, but I suspect this has the same issue preventing me from using it as does Bitwarden, namely: if I give you my vault and my password, you can access all my passwords.
With how common hardware security keys (or even just tpm2) are these days this limitation seems inexcusable to me. Which is why I'll stick with gopass/pass using my yubikey (w/ touch policy fixed). You might hack my machine and trick me in to decrypting a few passwords, but at least you won't make off with them all.
Would like to see web/desktop clients for this. When I used it recently I found the unexpandable pop-up overlay in the browser to not be adequate for managing my hundreds of logins- it just felt annoying to be confined to such a small "window"- also would like to see along with that more options for managing items in batches (select multiple and move to another vault, etc).
EDIT: Credit cards are available. Somehow I missed that! Might have gotten released in the time since I tried it which hasn't been long at all...
Oh, wow. Edited my original post. Thanks for the clarification. I think it wasn't available when I signed up, as far as I could tell, so maybe it was just added recently (or I just completely missed it...)
If you are paying for Pass Plus or Proton Unlimited then you have integrated 2FA/TOTP which Bitwarden also makes you pay for, same with Yubikey/FIDO2/etc 2-step login, which I think is possible for signing into proton pass.
And no desktop app for proton pass, maybe some day though?
No good reason yet (or many never). It really depends how happy you are with your current setup, Proton pass is young and clearly is still under development. A lot of the features Bitwarden or any other good password manager provides, its on the Proton pass's roadmap.
So if you are happy with your setup, stick with it and no need to move to Proton pass. Maybe keep an eye and check back after few months if their offerings have changed or upgraded that is worth the effort and shifting trust.
I personally would sign up as first year is free/cheap and I like proton products, although somewhat buggy they are trustworthy and worth supporting.
And I am using KeePass as my password manager which is cumbersome to selfhost and manage. I am not giving up on using KeePass yet as I too will wait to see where Proton pass ends up being.
My main concerns are - Can I host / store my own vaults? Are the apps native (not electron)? What are the browser plugins like with autofill of secrets, identity, payment information etc…?
edit: I'd like to inject a reminder that protonmail doesn't encrypt all of your mailbox contents. From their privacy policy:
"we have access to the following email metadata: sender and recipient email addresses, the IP address incoming messages originated from, attachment name, message subject, and message sent and received times"
> "we have access to the following email metadata: sender and recipient email addresses, the IP address incoming messages originated from, attachment name, message subject, and message sent and received times"
Is there any of that that’s not basically required by the fact that they’re running an _email_ service?
Sure, for sending/receiving the email all of that is accessible/needed but some (all, even) of this could be stored encrypted by the user's password/mailbox-password.
If I remember correctly: one of the reasons they don't encrypt that metadata is so they can do the search box server-side.
If you can cite some sources, I will be very interested to read all about it. I trust Proton with most of my crucial e-mails(bank, insurance, govt services) and use a cheap alternative for personal things.
If it is really a NSA honeypot, I'd rather let M$ or GOOG have my e-mails anyways.
Agreed. I'll look for where I read this... Maybe it was just a paranoid loon on the internet but for some reason I shelved it mentally as trustworthy... Bah don't trust me
Sadly no. It is a hit or miss. Particularly, URL match detection is comically bad. I also despise the way the browser extension injects code in every webpage where it detects forms. There's also no way to manually trigger the autofill.
Proton Pass is end-to-end encrypted, but indeed if you want something that doesn't support automatic multi-device sync and is 100% local, then Proton Pass is not the right fit for this use case.
