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

Reply via email to