61–70 of 128 posts
Why not use WebCrypto instead? No library needed.
You are confusing crypto primitives with a high-level spec like OpenPGP. OpenPGPjs used WebCrypto and node crypto libraries when available for primitives. You still need a library for the OpenPGP stuff.
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…
Unfortunately can't remember the name of the website nor exactly what it did...
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://codegolf.stackexchange.com/questions/18217/javascrip...
https://bitbucket.org/geraintluff/caution.js/
The idea is that a long data-uri containing hashes and a small loader function are bookmarked. The loader won't load the corresponding javascript unless the hashes match. The user only needs to verify the javascript once, then they can rely on their bookmark containing the hashes. If the server were to swap out the javascript, the bookmark would fail to load it.
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.
These concepts are interesting: https://codegolf.stackexchange.com/questions/18217/javascrip... https://bitbucket.org/geraintluff/caution.js/ The idea is that a long data-uri containing hashes and a small loader function are bookmarked. The loader won't load the corresponding javascript unless the hashes match. The user only needs to verify the javascript once, then they can rely on their bookmark containing the hash…
Earlier quoted context omitted.
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 Im inclined to distrust both of you. I find that your arguments might have merit. But I also see…
Nothing you said here addressed the facts that were provided. Good luck!
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.
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.
Earlier quoted context omitted.
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…
There was a site posted on HN a while back that had an interesting take on a solution to this: they had a service-worker that checked github.com for the latest version of the app code and itself (along with the standard subresource integrity of course). That description doesn't do the system justice, as to my memory it seemed like a pretty sound system as long as your public repo remains uncompromised. Unfortunately…
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.
These concepts are interesting: https://codegolf.stackexchange.com/questions/18217/javascrip... https://bitbucket.org/geraintluff/caution.js/ The idea is that a long data-uri containing hashes and a small loader function are bookmarked. The loader won't load the corresponding javascript unless the hashes match. The user only needs to verify the javascript once, then they can rely on their bookmark containing the hash…
Have any current protonmail users experienced denial of service from online providers solely because of their email address?
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.
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…