On Apr 11, 2007, at 5:20 PM, Brendan Eich wrote: > My sketch was just that: a slideware sketch. The idea is to put the > onus > of whitelisting or sandboxing (or taint-tracking information flow, > etc.) > on the browser implementors, who are fewer and more used to this level > of threat and standardization than the myspace wannabes.
Yes, the devil is in the details here, so a full description of the scheme would be welcome. Since we implemented our scheme and have done testing, I have some confidence in it, but I just don't know how things will play out with your idea yet. Regarding putting the onus on browser developers, I don't think we should put the complete responsibility on them. Our idea is that the responsibility has to be shared between browser developers and web app writers. I don't think I can anticipate just what policies web app developers will want. Therefore, we went with an scheme that lets web app developers decide this themselves. At the same time we want the burden on browser developers to be low, with only very simple changes to current browsers. We hope this will make it easier to convince them to adopt our scheme. Just for example, I don't want to ask browser developers to agree on a whitelist scheme; instead, I would like them to agree on a library of crypto functions that could be made available to scripts running in the browser. (This can be done entirely in JavaScript but it's too slow.) This is easy for them to implement, and then the web app developer can decide whether to use hashing, or signatures, or whatever they like. -Trevor _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
