- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 21 Oct 2010 14:07:00 -0700
- To: Travis Leithead <travil@microsoft.com>
- Cc: Shiki Okasaka <shiki.okasaka@gmail.com>, public-script-coord <public-script-coord@w3.org>, public-webapps <public-webapps@w3.org>
On Thu, Oct 21, 2010 at 1:38 PM, Travis Leithead <travil@microsoft.com> wrote: > For IE9, we've adopted this attribute as well [msDoNotCheckDomainSecurity] > > It has different meanings for different types of properites (fields vs. accessors) and causes some proxies to be setup, but generally speaking it does allow requests for the property to go through without an "access denied" hard-stop. > > I'm not sure how far WebIDL should go toward specing the security aspects of this attribute if it decides to include it. There are a lot of considerations that IE had to put in place to ensure we were secure, and they are quite varied depending on the scenario. > > My recommendation, if this attribute gets included into the WebIDL syntax, would be merely to indicate what it's intended purpose is, and to leave a general note about further security precautions that should be taken by an implementation to avoid cross-domain problems (or something like that). Starting down the road of defining all the possible attacks and mitigations may not be the best route to take (for this spec anyway). My gut reaction is to leave this out from the spec and not let WebIDL specify security aspects. It seems fine for implementations to add their own extended attributes in their own internal IDL, this is something that we've done for gecko forever. To me, the purpose of WebIDL is to specify behavior at a central place, as well as establish common and recommended usage patterns, not for implementations to be able to copy the IDL into the implementation directly. In fact, implementations doesn't have to use IDL at all. / Jonas
Received on Thursday, 21 October 2010 21:07:54 UTC