[liberationtech] In defense of client-side encryption

[Francisco Ruiz]

@Edulix  (hombre, un paisano ;-)

>I believe we need is an standard way to do client side encryption in
>the web. We need secure end-to-end communications in the web, so that
>we don't need to be trust and dependent on the html/css/javascript
>given by any server. We have a "server in the middle" security
>problem. This is different from a man in the middle, where there's
>*potentially* someone spying in the middle: in the web, by design,
>there's a server in the middle. We should not trust this server just
>because it's part of the design.

I believe the big problem that we are not addressing is precisely
this. The server is a big liability, because a server can always be
hacked or subpoenaed. We'd get better security from strictly
client-side encryption/decryption.

> This might seem like the holy grail, but it's not something
>unachievable (but it's surely very difficult to solve in a nice
>general way), here I talk about this problem:
>http://edulix.wordpress.com/2012/01/08/the-server-in-the-middle-problem-and-solution/
>. BTW, as a funny note, I gave a lighting talk about the "server in
>the middle" in Madrid Google's offices in 2012, showing in the slides
>google as being that server. People assisting to the talk loved the
>talk, but I think the google people didn't, as they didn't call me
>again next year for the same event  (which was "remote" Google I/O).

It's servers that are getting shut down. If we move encryption to the
client, then they can't shut them down. They might try to inject malicious
code in a static page as it loads (not easier than injecting it into
anything else, if it comes via SSL), but if the code is transparent, it can
be detected. That's all I'm saying.

Kind regards, too.

-- 
Francisco Ruiz
Associate Professor
MMAE department
Illinois Institute of Technology

PL13lok=WsH3zTgZn8V3hnIqjdbfPus+5YF5n+LBRPuH9USMMp8izPv+hsLoZKv+jaCFMapJFfiA11Q9yJU1K1Wo0TbjXK/=PL13lok

get the PassLok privacy app at: http://passlok.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20130811/bd46653d/attachment.html>