- From: Marc Fawzi <marc.fawzi@gmail.com>
- Date: Tue, 18 Nov 2014 22:54:24 -0800
- To: Florian Bösch <pyalot@gmail.com>
- Cc: Michaela Merz <michaela.merz@hermetos.com>, Webapps WG <public-webapps@w3.org>
- Message-ID: <CACioZiuJsG=co9-S_6oVxCF2cFgNKzFq2qVaDBkX8B8iAmnh7Q@mail.gmail.com>
So there is no way for an unsigned script to exploit security holes in a signed script? Funny you mention crypto currencies as an idea to get inspiration from..."Trust but verify" is detached from that... a browser can monitor what the signed scripts are doing and if it detects a potentially malicious pattern it can halt the execution of the script and let the user decide if they want to continue... On Tue, Nov 18, 2014 at 10:34 PM, Florian Bösch <pyalot@gmail.com> wrote: > There are some models that are a bit better than trust by royalty > (app-stores) and trust by hirarchy (TLS). One of them is trust flowing > along flow limited edges in a graph (as in Advogato). This model however > isn't free from fault, as when a highly trusted entity gets compromised, > there's no quick or easy way to revoke that trust for that entity. Also, a > trust graph such as this doesn't solve the problem of stake. We trust say, > the twitter API, because we know that twitter has staked a lot into it. If > they violate that trust, they suffer proportionally more. A graph doesn't > solve that problem, because it cannot offer a proof of stake. > > Interestingly, there are way to provide a proof of stake (see various > cryptocurrencies that attempt to do that). Of course proof of stake > cryptocurrencies have their own problems, but that doesn't entirely > invalidate the idea. If you can prove you have a stake of a given size, > then you can enhance a flow limited trust graph insofar as to make it less > likely an entity gets compromised. The difficulty with that approach of > course is, it would make aquiring high levels of trust prohibitively > expensive (as in getting the priviledge to access the filesystem could run > you into millions of $ of stake shares). > >
Received on Wednesday, 19 November 2014 06:55:32 UTC