71–80 of 173 posts
Could someone better across current cryptographic trends than I comment on that choice? We know the NSA has found weaknesses in certain implementations of elliptic-curve based cryptography in the past, and I was under the impression there was a preference in the community to move away from them in general given the unknown extent of the integrity concerns.
Just tried this out and it works great! Had to build it using the instructions on the wiki, but nothing too painful. It doesn't just integrate with gmail, but more with all textarea's around the web. When you are typing in a textarea and press the extension icon next to the hamburger menu it will pop open a menu containing the text that you were typing on the site, and are given the options to encrypt/sign a message.…
But as I'm typing, Gmail is saving my draft automatically to Google servers. Normally, at least. This means Google would have a copy of my email as it existed before I encrypted it. In your testing, do you see any evidence that this extension prevents Gmail's automatic draft saving?
Just tried this out and it works great! Had to build it using the instructions on the wiki, but nothing too painful. It doesn't just integrate with gmail, but more with all textarea's around the web. When you are typing in a textarea and press the extension icon next to the hamburger menu it will pop open a menu containing the text that you were typing on the site, and are given the options to encrypt/sign a message.…
But as I'm typing, Gmail is saving my draft automatically to Google servers. Normally, at least. This means Google would have a copy of my email as it existed before I encrypted it. In your testing, do you see any evidence that this extension prevents Gmail's automatic draft saving?
Earlier quoted context omitted.
Under "JavaScript crypto has very real risk of side-channel attacks": End-To-End’s crypto operations are performed in a different process from the web apps it interacts with.
If process isolation is already done, disabling stack dumps for crypto processes seems like a logical next step that shouldn't be hard to accomplish.
Maybe there could be some new extension permission for "encryption extension" or something, but it's possible that could be abused...
Earlier quoted context omitted.
This "end to end" encryption happens in the browser. Google is the browser. Google dont need your keys, they have the plain text.
Also, other browser extensions may be able to access what is going on in the browser. So Google and (insert list of other parties.)
On the one hand, I'm happy Google is trying to make GPG usable within GMail: https://code.google.com/p/end-to-end/ . On the other hand, this leaves many ?s It sounds like all you get from "end-to-end", other than a name that's going to cause horrible confusion, is a bare mininum of GPG functions. No TOFU, no pushing users to encrypt by default, no better management of keys, no attempt to stop metadata surveillance. It's good GMail users will have an easier time with GPG, but if it keeps them on a broken-by-architecture centralized service, we all lose. This doesn't seem to go far enough in making crypto usable (no indexing solution, for instance) but it will slow development of alternatives. I admit Google is kind of in a bind here - if they want to help GMail users, they're also necessarily slowing the evolution of a safe net. Mostly I wish they hadn't called it "end-to-end". Because, you know, words mean things, and like "Off the record", that means something else. I'm surprised Google weren't willing to spend the internal security resources on end-to-end to be able to stand behind it at time of release. All told, it pretty much smells like "keep engineers happy" + "win points with the net freedom community as cheaply as possible." Google, if they wanted to, could do some pretty revolutionary stuff in the secure comms space, but that would cost actual cash. Ssh, no one wants to talk about how Silicon Valley business models depend on surveillance.
Earlier quoted context omitted.
If process isolation is already done, disabling stack dumps for crypto processes seems like a logical next step that shouldn't be hard to accomplish.
It's probably relying on normal process isolation (and extensions run in a different process), but in order to disable stack dumps for it, you'd have to have some way of indicating "this process is special", which rules out treating it like any other extension. Maybe there could be some new extension permission for "encryption extension" or something, but it's possible that could be abused...
Earlier quoted context omitted.
But as I'm typing, Gmail is saving my draft automatically to Google servers. Normally, at least. This means Google would have a copy of my email as it existed before I encrypted it. In your testing, do you see any evidence that this extension prevents Gmail's automatic draft saving?
In the FAQ they mention "End-To-End doesn’t trust any website's DOM or context with unencrypted data. We have tried to ensure that the interaction between the extension and websites is minimal and does not reveal secrets to the website." I'm curious about this too. Does that mean they somehow insert a textbox that the host page can't see? I didn't realize extensions could do that. Edit: ah, this appears to be where i…
Regarding JavaScript crypto: We hold ourselves to a higher standard; we started from scratch and created a testable, modern, cryptographic library. That is awesome. So's this: Chrome’s design means that extensions should be safe against other extensions. And this: End-To-End uses Content Security Policy as well as inherently safe APIs in frameworks (strict Closure Templates). End-To-End doesn’t trust any website's DO…
Just tried this out and it works great! Had to build it using the instructions on the wiki, but nothing too painful. It doesn't just integrate with gmail, but more with all textarea's around the web. When you are typing in a textarea and press the extension icon next to the hamburger menu it will pop open a menu containing the text that you were typing on the site, and are given the options to encrypt/sign a message.…
But as I'm typing, Gmail is saving my draft automatically to Google servers. Normally, at least. This means Google would have a copy of my email as it existed before I encrypted it. In your testing, do you see any evidence that this extension prevents Gmail's automatic draft saving?