- From: Adam Barth <w3c@adambarth.com>
- Date: Tue, 8 Jan 2013 21:50:37 -0800
- To: Bobby Holley <bobbyholley@gmail.com>
- Cc: whatwg <whatwg@lists.whatwg.org>, Ian Hickson <ian@hixie.ch>
On Mon, Jan 7, 2013 at 11:17 PM, Bobby Holley <bobbyholley@gmail.com> wrote: > On Mon, Jan 7, 2013 at 8:05 PM, Ian Hickson <ian@hixie.ch> wrote: >> On Mon, 7 Jan 2013, Bobby Holley wrote: >> > >> > Aside from concerns about stack introspection, the main downside of this >> > approach is that it's a blacklist, rather than a whitelist (like our >> > other security code), so we'll have to be extra careful when >> > implementing anything new on Location. Please keep that in mind when >> > updating the spec. ;-) >> >> Can you elaborate on what is a blacklist? > > In the sense that we have to implement it as explicit per-method checks in > C++. Our regular security model is an object-capability system enforced > with wrappers across scope boundaries (using a whitelist), which, as > previously discussed, doesn't jive with the current spec for Location. So > if something new is ever added to nsLocation, we're going to need to > remember to add a security check. The way we handle this in WebKit is with an IDL attribute [CheckDomainSecurity] on the interface that instructs the code generator to generate these security checks for each method automatically. Individual methods can be whitelisted using the IDL attribute [DoNotCheckDomainSecurity]. That's all much easier than implementing a secure JavaScript wrapper. (I understand that some existing Mozilla-proprietary features require you to spend the engineering effort to build secure JavaScript wrappers, but nothing in the web platform requires other browser engines to make that investment.) Adam
Received on Wednesday, 9 January 2013 05:51:35 UTC