And to preempt the ProtonMail rep who is probably going to respond to this comment, I know that you can run the web app on localhost. But that doesn't mean that users who don't are any more secure.
data:text/html,<script crossorigin="anonymous" integrity="..." src="...">
There’s a range of assurances you could try to provide, e.x. signatures from the author (or even 3rd parties), prompting for updates, etc. It would likely require support from browsers.
At one point I investigated using service workers to intercept subsequent app updates to check signatures but there was no way to prevent the service worker itself from being replaced (probably because it would be easy for a site to permanently “brick” itself in users browssr).
Cyph nailed this back with appcaches, later migrating to service workers (and ultimately got a patent for the solution), but the implementation of the solution itself got an entire protocol canned by one browser (HPKP).
Source: did the talk on it.
If you could require the root page be cryptographically signed (but by who?) and optionally prompted for updates then we’re talking.
As far as I'm aware that means their approach no longer works (across browsers), and, though it was a fantastic idea, it did require you to trust that they really were throwing their keys away (a trust model slightly weaker than TOFU).
Paraphrasing, but IIRC the reasoning pretty much boiled down to "it's a pain to maintain and Expect-CT is kind of similar anyway" — which I think is a really weak justification for harming end user security and breaking established APIs that people depend on in production. Fingers crossed that Firefox keeps it alive!
That said, it doesn't entirely break WebSign in Chrome, just weakens a bit further below strict TOFU. https://www.cyph.com/websign goes into detail, but WebSign has some client-side logic to validate its own hash against a signed whitelist. The major downsides to relying on this are:
1. It depends on a caching layer, not a security feature. This means that any guarantees are potentially out the window if a browser vendor decides to do something crazy for performance reasons or whatever.
2. It opens up an attack vector where it can be forcibly unpinned by filling up the user's disk and making the browser evict the cached WebSign instance.
All in all I think it's still basically fine, but shipping an optional browser extension for hardening WebSign is now a higher priority because of this.
Unfortunately can't remember the name of the website nor exactly what it did...
- Hack Google
- Hack the servers hosting OpenPGPjs
- Hack the browser to inject or replace content across domains, sandboxes, other security barriers
Another way to think of it is if your entire Linux OS were actually just web apps with GUIs. Every time you run 'bash', it was actually downloaded from a remote server. And every time you used bash, and it used some plug-in which was hosted on some other site, that plug-in could be compromised, and could be trying to attack your OS, which if successful, would compromise your entire host.
That doesn't happen right now because all the apps sit on your host, aren't constantly re-acquired, aren't constantly subject to potential 3rd party attacks over a wide surface area. Though this does sort-of happen with programming language package managers like npm, pip and so on. But you can pin those versions and hashes if you're paranoid, which I don't think you can do with a browser.
It would actually be much easier to just find a vuln in Chrome that can break out of sandbox and get root.
> - Hack Google
- NSL Google
1. Most platforms these days require a signature with a key issued by the platform. In the browser you have HTTPS but that doesn’t help if the server is compromised.
2. It’s easier to target individuals (thus evading detection) if you’re serving the code to users directly (which I think is also the case with Chrome, but not Mac App Store, Linux package managers, etc)
3. Some platforms even do some amount of auditing before including software in their repositories.
You could however probably provide a signed entry point via a webextension or so and a an audit trail via a trusted distribution plattform, like addons.mozilla.org. Are there apps which use a mechanism like this?
Can you not trust the originating site to serve non-compromised HTML if using HSTS and a trusted local certificate store (eliminating MITM as an attack vector)?
It's not clear to me that the Cache API offers the same level of security guarantee.
Last I checked it seemed there wasn’t any way to prevent the service worker itself from being updated.
If the users had the option of "locking" a JS version with the Subresource Integrity attribute that they are currently using, it might help.
(They are both protocols for distributed web apps based on immutable content.)
 https://news.ycombinator.com/item?id=17258203 (please turn on "showdead" in settings, to see the entire thread)
: Plus, it was raised by a competitor, Private Internet Access, so it makes it even more difficult to get the facts straight.
The co-founders of ProtonMail were caught providing multiple inaccurate statements about their business practices in that thread, and couldn't deny any of the facts stated by the co-founder of PIA.
Focus on the facts. Not the messenger. Secondly, I admire your love of this discussion .
1. You are the user in question that is a co-founder for PIA.
2. You are a direct competitor to Proton*
3. "Messengers", especially in the position of founder of the competitor, have significant bias.
4. You have a fiduciary reason for them to fail.
5. user protonmail has noted significant harassment regarding this issue
It's neither religion, nor politics. It's tech. You don't need to believe in anything you cannot verify yourself. I have checked most of the statements provided by the co-founder of PIA, and found none of them to be false, even if he sometimes crossed the line of a civil discussion.
As was listed, there are plenty of good reasons to learn about the messenger, just like how looking up my comment history will show my propensity for calling this argument out. You know my ulterior motives and where I'm coming from.
 https://news.ycombinator.com/item?id=17261149 -- need to have "showdead" enabled in profile
EDIT: I'm sure the competition is intense and I'm not sure I would be able to rise above it myself but I think you need to be aware of what it looks like.
They bring shame to our industry, and further, shame to our cause.
I will stand up against them everyday regardless of what kind of repercussions come to me. That’s what it means to protect people’s privacy.
This is a lie. Private Internet Access is probably the largest paid VPN provider in the world, and ProtonVPN (by Tesonet?) belongs to a short list of free VPN providers, such as Onavo VPN by Facebook and Hola VPN by Luminati, most of which are subsidized by data mining companies. These are two completely different markets.
> We used the same legal address and nominee directors as our local partners because we still did not have our own office yet. For contractual reasons, these moves took some time. For example, ProtonLabs Skopje, our newest entity, only moved in November 2017.
ProtonVPN UAB has been founded in July 2016, and was still operated from Tesonet HQ in June 2018, when this fact was made public by the co-founder of PIA. The current ProtonVPN legal address in Vilnius, Lithuania can be used by any company, which agrees to pay for 1 work-place without any long-term obligations. This means, that ProtonVPN might as well be still operating from Tesonet HQ.
> ProtonVPN/ProtonMail does not, and has never used any IPs or servers from Tesonet (this can be publicly verified)
This is a lie. ProtonMail admitted to using Tesonet IPs, when presented with Whois results in June 2018. Those IP blocks were later assigned to ProtonVPN.
> Proton does not share any employees (or company directors) with Tesonet. This is also a verifiable fact.
This is a lie. It is no longer possible to verify, who is the director of ProtonVPN, because the company made the public record unavailable after changing its name multiple times in the last two months. The last public record listed the CEO of Tesonet as the director of ProtonVPN, which was still true in early June 2018, when the co-founder of PIA made the fact public.
> There is little actual evidence that Tesonet does data-mining (in any case we have never used infrastructure from them).
This is a lie. There is plenty of actual evidence, that Tesonet is running a data mining company, called Oxylabs, which sells access to "10+ Million Mobile IPs in Every Country and Every City in the World".
> We used Tesonet as a local partner before we had an official Lithuanian subsidiary, and rented office space from them. We don't share employees, infrastructure, etc. We have had a similar temporary arrangements with local companies when we opened offices in other jurisdictions where we didn't have an official presence yet.
This type of arrangement is common in the startup world.
"For the latest project, Tesonet is working together with an international brand from Switzerland to create a security product that helps users protect their network traffic. As part of this technical partnership, we are collaborating on datacenter and network infrastructure that can easily supply 10 Gbps worth of bandwidth to users around the world. The product is developed using the latest authentication encryption methods and the best practices in the security world."
Eastern Europe is not a jurisdiction.
Tesonet provides all kinds of services, like hosting, software development and cybersecurity for it's customers.
Tesonet's Oxylabs offers "10+ Million Mobile IPs in Every Country and Every City in the World", which might explain why ProtonVPN, whose Android app is signed by Tesonet, is a free service. This is how Luminati, Tesonet's largest competitor in Residential Proxies, operates: it provides a free VPN service, Hola VPN, and then connects its users into a botnet, which is used for data mining operations.
How would this compare to something like WebCrypto, which assume would be implemented in a way that would allow for side channel resistance etc? It does seem surprising that we don't have something like a browser API version of libsodium in widespread use already.
Is the supposed threat actor a MitM that can use the timing of the packets your browser sends to work out when you stopped typing your email and when the email was sent to the server, allowing them to calculate the time taken by the encryption operation and thus infer something about the plaintext of the email?
Perhaps they are imagining an attacker who could do both, and it would be very interesting to see a practical attack along these lines, but I still think that a decent WebCrypto implementation should make it close to impossible for an attacker to extract any useful information unless the user is sending billions of emails through the ProtonMail web client.
1) No negativity towards your provider reflects on you
2) If your mail provider locks you out you can move to another
Just do a little mental simulation right now of what would happen if gmail or ms/hotmail/etc. locked your account.
What PGP really needs is a modern security model so you'd have many device keys registered to an identity rather than requiring the risk of spreading copies around. I think I have IIRC 8 GPG subkeys currently (6 of them being Yubikeys) and every aspect of that toolchain is unacceptable in the modern era.
What do you mean by "device keys"? Something like forward secrecy keys for initial session setup as used by e.g. Signal? This could be done with some effort... actually Rust OpenPGP library Sequoia developers already work on making this use case easier.
Another set of patches circulating on the ML adds support for TPM bound keys, that are non extractable.
I didn’t think it was worth it to post to HN as news, though. Perhaps I should start posting our achievements a bit more.
Like for example our Group Rides feature:
Maybe, but don't do it in someone else's thread trying to steal the spotlight from them... Really bad taste.
If anything, the comments saying that they shouldn't be trusted, etc. harm them more than my comment.
Actually my comment should be: I don't think being audited by a third party firm is newsworthy, this is us being audited and we didn't post it.
(Chin up and all that. This is not intended to be in any way hostile.)