The reason why FireGPG no longer ships with tails is that the DOM of a web app is not a safe place for plaintext https://tails.boum.org/doc/encryption_and_privacy/FireGPG_susceptible_to_devastating_attacks/ Any architecture where plaintext is stored inside a web app's DOM is dangerous. Especially a webmail app that can be expected to save drafts, but not only. Web apps can be MITMed, XSSed, etc. If it came via the web, it's a suspect.
I'd expect a crypto add-on to only accept plaintext (and other sensitive) information via separate GUI that can only be launched manually (not via javascript in an app's DOM) and has a hard-to-imitate look-and-feel (to discourage phishing). The only communication between this add-on and the rest of the browser should be via the clipboard. Users who can't handle copy/paste shouldn't be trusted with a key pair :) >From what I see at the http://www.mailvelope.com/ slide-show, it seems to provide even more shooting-yourself-in-the-leg firepower than FireGPG. On Wed, Dec 12, 2012 at 3:21 AM, Nadim Kobeissi <[email protected]> wrote: > Cryptocat is a local browser plugin served over SSL, installed locally, > loads/executes no external code, and communicates only via SSL. It does not > rely on server integrity with regards to these parameters. > > Regarding Mailvelope — does its operation depend on the Gmail DOM? What > happens if the Gmail DOM is modified, can that be used to damage the > integrity of Mailvelope operations? There's a reason Cryptocat operates in > its own browser tab separate from other sites. > > NK > > On 2012-12-11, at 6:54 PM, Andy Isaacson <[email protected]> wrote: > > > On Mon, Dec 10, 2012 at 10:07:23PM +0000, StealthMonger wrote: > >> "Fabio Pietrosanti (naif)" <[email protected]> writes: > >>> for whose who has still not see that project, i wanted to send a notice > >>> about MailVelope, OpenPGP encryption for webmail: > http://www.mailvelope.com > >> > >>> It's a client-side, plug-in based (similar to CryptoCat), OpenPGP email > >>> encryption plugin available for Chrome and Firefox. > >> > >> To compare it with CryptoCat is unfair to MailVelope. As I understand > >> things, CryptoCat has an ongoing reliance on server integrity. On the > >> other hand, MailVelope is self-contained once securely installed, > > > > I'm not sure why you claim that. It was true for Cryptocat v1 which was > > a browser app and could be compromised at any time with new JS from a > > compromised server. Cryptocat v2 is a downloadable + installable plugin > > which at least doesn't immediately execute code served to it. > > > > In both the JS and plugin versions, Cryptocat (with uncompromised code) > > does not depend on server integrity for message confidentiality. > > > > Now, both CryptoCat and MailVelope probably have an upgrade > > vulnerability where a compromised server can tell the app "there's a new > > version available, plese ask the user to install it". And since the > > compromised server could refuse to provide service to the secure version > > of the app, there's a powerful functional reason for the user to accept > > the upgrade. > > > > Ah, perhaps you're referring to the fact that MailVelope layers on top > > of another server (Gmail) for its transport layer, rather than depending > > on a "MailVelope server" which could selectively deny service to the > > uncompromised version of the product. In that respect, MailVelope might > > be more secure-by-design than Cryptocat. > > > > -andy > > -- > > Unsubscribe, change to digest, or change password at: > https://mailman.stanford.edu/mailman/listinfo/liberationtech > > -- > Unsubscribe, change to digest, or change password at: > https://mailman.stanford.edu/mailman/listinfo/liberationtech >
-- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
