On Mon, Jan 7, 2013 at 11:17 PM, Bobby Holley <bobbyhol...@gmail.com> wrote: > On Mon, Jan 7, 2013 at 8:05 PM, Ian Hickson <i...@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