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

Yiorgis Gozadinos ggozad at crypho.com
Tue Mar 26 01:24:13 PDT 2013


On Mar 25, 2013, at 18:20 , Steve Weis <steveweis at gmail.com> wrote:

> 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.

Hey Steve,
I can't say how much I appreciate your comments :)
If I may I would like to leave aside the rest, and try to share my not-implemented and purely based on intuition and speculation vision on authenticated js. This of course means that I acknowledge the fact that the way we serve crypho leaves a lot to be desired in terms of security, and apps will be our short-term solution. I strongly believe though in the browser as the platform, and want to take this as the opportunity to see whether there exists a viable solution outside the apps.

Assuming there is a point of reference for js code, some published instance of the code, that can be audited and verified by others that it does not leak. The point then becomes: "Is the js I am running in my browser the same as the js that everybody else is?". 
Like you said, it comes down to the trust one can put in the verifier.
A first step could be say for instance a browser extension, that compares a hash of the js with a trusted authority. The simplest version of that would be a comparison of a hash with a hash of the code on a repo.
Another (better) idea, would be if browser vendors would take up the task (say Mozilla for instance) and act as the trusted authority and built-in verifier. Developers would sign their code and the browser would verify.
Finally, I want to think there must be a way for users to broadcast some property of the js they received. Say for example the color of a hash. Then when I see blue when everyone else is seeing pink, I know there is something fishy. There might be a way to even do that in a decentralised way, without having to trust a central authority.

All this smells like overkill if there is no general interest in pursuing it, but I would love to hear your thoughts as well as other's on this.

-- 
Yiorgis Gozadinos
www.crypho.com




More information about the liberationtech mailing list