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 <[email protected]> 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). > >
