21–30 of 128 posts
Earlier quoted context omitted.
isn't this why https://developer.mozilla.org/en-US/docs/Web/Security/Subres... was invented?
If you can change out the JS payload, you can probably also swap out the HTML which supposedly "secures" it. If the users had the option of "locking" a JS version with the Subresource Integrity attribute that they are currently using, it might help.
Not that it matters. They could silently replace it with a backdoored script and your browser would never tell you it happened. 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.
The same can be said for any software that auto update (i.e. Chrome), no?
Not that it matters. They could silently replace it with a backdoored script and your browser would never tell you it happened. 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.
This (rightfully) comes up every time some browser-based encryption tool is posted. It seems like the desire for such tools isn’t going to go away. Is anyone working on solutions for making distribution of JavaScript applications more secure? 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 b…
Earlier quoted context omitted.
isn't this why https://developer.mozilla.org/en-US/docs/Web/Security/Subres... was invented?
No, because the provider would be in the position to change the SRI hashes. Sub Resource Integrity protects you against malicious CDNs and so on, but needs a non-compromised HTML page to provide correct hashes. 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 th…
It's not clear to me that the Cache API offers the same level of security guarantee.
I have zero trust in Proton after learning, that the free ProtonVPN service is provided by a data mining company from Eastern Europe[1]. [1] https://news.ycombinator.com/item?id=17258203 (please turn on "showdead" in settings, to see the entire thread)
> 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.
Have any current protonmail users experienced denial of service from online providers solely because of their email address?
Yupp. My account at a particular website was terminated. They pointed to their TOS, where "anonymous" address are not allowed. Wasn't even given the chance to keep the account and change the email to an "acceptable" one.
Not that it matters. They could silently replace it with a backdoored script and your browser would never tell you it happened. 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.
https://github.com/openpgpjs/openpgpjs/blob/master/README.md
I have zero trust in Proton after learning, that the free ProtonVPN service is provided by a data mining company from Eastern Europe[1]. [1] https://news.ycombinator.com/item?id=17258203 (please turn on "showdead" in settings, to see the entire thread)
Please, that's not a verified claim[0], and you shouldn't trust any VPN service that isn't operated by you in the first place. [0]: 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[1].
Earlier quoted context omitted.
isn't this why https://developer.mozilla.org/en-US/docs/Web/Security/Subres... was invented?
No, because the provider would be in the position to change the SRI hashes. Sub Resource Integrity protects you against malicious CDNs and so on, but needs a non-compromised HTML page to provide correct hashes. 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 th…
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)?
Earlier quoted context omitted.
No, because the provider would be in the position to change the SRI hashes. Sub Resource Integrity protects you against malicious CDNs and so on, but needs a non-compromised HTML page to provide correct hashes. 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 th…
> No, because the provider would be in the position to change the SRI hashes. Sub Resource Integrity protects you against malicious CDNs and so on, but needs a non-compromised HTML page to provide correct hashes. 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)?