> lavaboom.com and protonmail.ch both appear deliver you their
> code (javascript) on the fly to run in your browser. Yeah, that's
> secure.

I have long thought that it's high time to implement JS code signing
that can be verified by the client, either innately or through an extension.

A quick addition to the comment-metadata system devised to provide
licensing information (and parsed by an FSF extension to inform you
whether the code your browser is running is libre or not) could be used
for this purpose; what's left, then, is to establish a way to translate
code signatures into trust.

For a monolithic system like a zero-knowledge email host, that's easy;
when you sign up, you install their pubkey into your extension,
preventing MITM attacks on the JS payload. At best, that's an additional
layer over SSL, or it could be used instead of SSL (a crypto-AJAX engine
run in browser for sending and receiving data; could be handy for shared
hosting where SSL isn't an option).

However, it falls down vs. NSLs, etcetera, because hosts can be
compelled to send you malware signed with their keys. You need
trustworthy third parties who can sign and verify that code is shipped
intact. It'd be nice if you could hack a system like this to use the PGP
web of trust as a first port of call, and then to fall back to a wider
set of "trusted" people if that fails.

As a way to further enhance security, having people with these
extensions installed send hashes of the JS payloads they receive to a
comparison server would be nice. Might even detect some attacks that fly
under the radar at present, like people being sent tailored-attack
versions of major third-party libs like JQuery, etcetera. When an
anomalous hash arrives that doesn't match any "official" releases of the
lib, alarm bells should ring.

On 27/05/14 05:27, grarpamp wrote:
> On Tue, May 20, 2014 at 11:05 AM, Kelly J. Rose <iam@kjro.se> wrote:
>> Which is totally subverted if you are American citizens or located in the
>> us. Simply by the national security letters.
>>
>> You could have the sexiest cryptosystem ever and the NSL attack will still
>> beat you if you put it on American soil.
>
> If you operate a machine upon which plaintext 'email' for users transits/sits
> on their behalf, you will still be subverted and beaten (literally or
> not)... either
> remotely by cooperative agreements (or simply giving), or your own local
> mitm, [extra]legal force major, etc. The only way out of the mess is either:
> a) basically start street protesting to change global law and practice
> and somehow manage to create utopia.
> b) defend in depth and bury all user messaging within secure p2p darknet
> overlay networks where only Alice and Bob are parties to the plaintext content.
> And the code you run to get on it is developed and audited by separate
> groups, be they well known nyms on such nets, or real world.
>
> Any proposed messaging system that is centralized, not pay anonymous,
> not open, works by you giving up key material you shouldn't, or you needing
> to demandload their code instead of running your own trusted copy... isn't
> worth your time. Otherwise stick with plain old email, text, and whatever
> the fad of the day is. And don't try to call either of them secure.
>
>> This kind of problem should be tackled by some honest idealists from either China, Russia
>
> Yet people applaud eliminating such idealists, even eg:
> Iraq, Iran, Cuba, DPRK, Venezuela, Israel, etc.
> Keep on wiping out your only counter voices and you'll
> get what you asked for next. None of these suggested places/people
> are immune either, only alternatively 'hard'[er] under some
> given threat models.
>
> lavaboom.com and protonmail.ch both appear deliver you their
> code (javascript) on the fly to run in your browser. Yeah, that's
> secure.
>

--
T: @onetruecathal, @IndieBBDNA
P: +353876363185
W: http://indiebiotech.com