On Mar 25, 2013, at 18:20 , Steve Weis <[email protected]> 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 -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at [email protected] or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
