Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] Crypho

Steve Weis steveweis at gmail.com
Mon Mar 25 10:20:39 PDT 2013


Hi Yiorgis. The "ways of asserting the authenticity of served [JavaScript]"
always reduce to trusted code executing on the client. You need to trust
whatever is authenticating the served application. You can't get around it.

This approach always ends up with either trusting the service or running
client-side code. The former is a perfectly fine business model and the
standard for almost all web apps, but you can't make the claim that "the
government and our staff cannot access your data". It's simply not true,
and not just because there might be incidental bugs you're working on
fixing. It's fundamentally untrue.

I appreciate the challenge you are trying to tackle and understand that
delivering client-side code across all browsers and platforms is a
non-starter for an early startup. If it were an easy problem, we wouldn't
be having this discussion. I wish you luck in solving it.

On Sun, Mar 24, 2013 at 3:08 AM, Yiorgis Gozadinos <ggozad at crypho.com>wrote:

> On the technical side, like I said, we will try to address the issue of
> trusted js by implementing apps as well as explore ways of asserting the
> authenticity of served js. Open-sourcing the client code will certainly
> help in auditing. There are other things we put in place to help, CSP,
> Strict-Transport-Security and X-Frame-Options headers for example or a
> proper SSL setup.
>  These cannot guarantee of course that we haven't overseen things, but our
> hope is that gradually we can build trust on our app.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20130325/1aad5c2c/attachment.html>


More information about the liberationtech mailing list