zooko: > On Tue, Mar 26, 2013 at 09:24:13AM +0100, Yiorgis Gozadinos wrote: > > > > 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. > > Dear Yiorgis: > > I think this is a promising avenue for investigation. I think the problem is > that people like you, authors of user-facing apps, know what the problem is > that you want to solve, but you can't solve it without help from someone else, > namely the authors of web browsers. > > With help from the web browser, this problem would be at least partly > solvable. > There is no reason why this problem is more impossible to solve for apps > written in Javascript and executed by a web browser than for apps written in a > language like C# and executed by an operating system like Windows. > > Perhaps the next step is to explain concisely to the makers of web browsers > what we want. > > Ben Laurie has published a related idea: > > http://www.links.org/?p=1262
Now this is interesting. Had not seen that link before. I wonder how that above 2012 Ben Laurie would get along with this slightly more vintage 2011 Ben Laurie, who discounts not only the hashtree concept, but any attempt to secure it with computation as well: http://www.links.org/?p=1183 The problem is, 2012 Ben Laurie's system is obviously quite easy to censor and manipulate if the adversary has any sort of active traffic capabilities in terms of showing custom extensions of the hash chain (ie malware) to targeted individuals. 2011 Ben Laurie's "Efficient Distributed Currency", on the other hand, suggests a Tor-like multiparty signing protocol to avoid these issues: http://www.links.org/files/distributed-currency.pdf But if we assume the worst, the 2011 model Ben Laurie is weak to an adversary such as the NSA that might compromise his datacenter computers (or keys) behind his back. However, 2012 Ben Laurie could detect this compromise by the NSA if it was reasonably hard to add new, fake entries to the hash tree, if clients kept history, and if he had multiple authenticated network perspectives on the hash tree (ie notaries). Can't both Ben Laurie's just get along? ;) To bring us back to Earth: The core problem with the website-as-an-app JS model is that *every* JS code download from the server is not only authenticated only by the abysmal CA trust root, but that insecure/malicious versions of the software can also be easily targeted *specifically* to your account by the webserver (or by the CA mafia) at any time without informing you in any way. But, the really scary situation we now face is that many of us have accounts on app stores capable of delivering updates *right now* that have the same type of targeted capabilities. In fact, in my opinion, all app stores that exist today are just as unsafe for delivering crypto software as website-based solutions are :/. I think I still agree that the takeaway is that it's better to create situations where you only have to do a heavyweight "double Ben Laurie" PKI+notary+hashtree+PoW all-in-one-check *once* upon initial download, to establish a trust root with the software provider themselves, rather than regularly trusting an intermediary appstore, webserver, and/or CA trust root. Once that initial strong check is done (and you've either run the malware or you haven't), then the software can update using its own strong signature authentication. In the case of paid/proprietary software, proof of purchase from the client should be based upon blind-signatures/ZKPs instead of unique account credentials. But like, really nobody in the world is doing any of this, are they? -- Mike Perry
-- 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
