- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 09 Jan 2013 10:16:41 -0500
- To: Adam Barth <w3c@adambarth.com>
- Cc: whatwg <whatwg@lists.whatwg.org>, Ian Hickson <ian@hixie.ch>
On 1/9/13 3:11 AM, Adam Barth wrote: > I'm not convinced of that. I understand that Gecko need to deal with > these complications because of a number of Mozilla-proprietary APIs, Actually, what I'm talking about here has nothing to do with APIs but everything to do with wanting to write web applications that have slightly more privileges than your typical web page. Again, you may want to talk to Jonas and Mounir for details. > If and when features are added to > the platform that cause these sorts of problems, we can deal with the > consequences. My argument is that we should not lock ourselves out of adding such features in the future. > In the mean time, I don't think we should force other > browser engines to implement a more complicated security model than > necessary for the platform as it stands. I'm not saying we should force anyone to implement any particular security model. I'm saying we shouldn't design/spec things that become completely insecure if the security model ever changes in any way and hence prevent evolution of the security model. Which means that we should assume as little as possible about what the security model guarantees us when specifying things. In my opinion. > This paragraph was too abstract for me to understand. Do you have a > concrete example? For example, Ian's argument is that you can skip security checks in various places because the security model does that already. My counter-argument is that we should define the behavior of those places by referencing the security model explicitly, so that if the security model changes we won't have to hunt down all the places that had implicit dependencies on it. Does that make more sense? >> Put another way, I think we have good evidence that the security model in >> the spec, as well as that in every browser, Gecko included, is wrong in the >> same sense that Newtonian mechanics is wrong. The problem is that we don't >> know what our equivalent of special relativity is yet. > > I don't understand the analogy. The current security model describes most common cases, but not some edge cases (see above about a slightly-elevated-privileges web app that can, say, touch nodes from one and only one different origin). > More seriously, life gets complicated when you introduce an asymmetric > access relation I agree. I believe, however, that for many apps based on web technology you in fact might need this. Again, Sicking and Mounir would know more. https://bugzilla.mozilla.org/show_bug.cgi?id=734891 has some of the things in it, but I'm not sure it's all of them. > However, the open web platform contains only a symmetric access relation Yes, I understand that's how it stands now. I'm questioning the viability of this going forward, and especially questioning to what extent we should be intentionally making it impossible to change away from this model. > and I intent to argue against any attempt to introduce an asymmetric access That is, of course, your right. ;) > Maybe I've lost the thread here, but I don't understand the problem > you're trying to solve with this thread. The simplest solution is for > contentDocument to return null when accessed from a different origin. That's not enough. Window has the same problem: the "document" IDL getter needs to check that you're allowed to get the document of the relevant window, for example. Is the check you describe for contentDocument based on origin or effective script origin? -Boris
Received on Wednesday, 9 January 2013 15:17:17 UTC