Trevor Jim wrote: > 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.
Our experience is that they want everything, and only know to blacklist the obvious threats, which is of course insufficient for security, and also (they say) bad for users who should be trusted to script (within a jail-type sandbox). They want a mashup without pain. They want the user-generated content to be web content, ideally. > Therefore, we went with an scheme that lets web app developers decide this > themselves. This is like giving whiskey and car keys to teenagers. I'm not kidding, and I'm not saying some web developers should not have the ability to script filtering of user-generated content. The expertise to do this well, and to track evolving browser features, is rare. > 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. Certainly, doing anything will entail risk, and your scheme would be better than the status quo. But if browser vendors are going to agree on something, it need not be very simple, especially if that makes hazards for web developers that will only lead to another cycle of R&D followed by browser changes. > 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. Whitelist beats blacklist, and browser vendors know better what to whitelist. But as I wrote above, mashup hosting services really want it all to "just work" yet be secure. This means a stronger JS security model (two other use-cases -- there are more -- were listed in my slides). Separately, more JS APIs including standard crypto module APIs would be a fine thing. This idea has not come up AFAIK in http://whatwg.org yet (I may have missed a post to the open mailing list). /be _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
