Page 1 of 1
Alternatives to CAPS
Posted: Mon Dec 23, 2013 11:14 pm
by barbaz
With CAPS going away in Gecko 29, what is the new way to prevent all calls to specified (built-in) JavaScript functions? I've searched the Internet but found nothing on the subject.
Re: Alternatives to CAPS
Posted: Fri Dec 27, 2013 2:34 pm
by barbaz
No one has any idea? This looks bad...
Should I be filing an RFE on Bugzilla for an API that can add additional restrictions (but not grant additional permissions) to built-in JavaScript functions?
Re: Alternatives to CAPS
Posted: Fri Dec 27, 2013 3:05 pm
by therube
Re: Alternatives to CAPS
Posted: Fri Dec 27, 2013 5:28 pm
by barbaz
Thanks, but that's just referring to the removal of CAPS, not any new means of fine-grained control over which JS functions can be used by displayed pages. I believe that the API Giorgio is using to block inline scripts in Gecko 29+ can only block or allow *all* javascript usage, so that's not going to work for my own addon.
Re: Alternatives to CAPS
Posted: Fri Dec 27, 2013 8:19 pm
by Giorgio Maone
this bug is both about CAPS removal and a replacement declarative API, which I helped to shape but I'm still not sure I'm gonna actually use in NoScript.
In facts, at this moment (in latest NoScript dev builds, when used with latest Nightly) NoScript is performing inline script blocking by using the same alternate approach already experimented by NoScript for Android. Of course there are bugs, but it works reliably, at least security-wise.
Re: Alternatives to CAPS
Posted: Sat Dec 28, 2013 3:08 am
by barbaz
Thanks for the link Giorgio. As far as you know, are there any plans for the new DomainPolicy API to include the ability to block specific Javascript actions everywhere, like the default CAPS policy, before Gecko 29 hits beta? If not, are you suggesting that I file an RFE in that bug even though it's already marked as resolved?
Re: Alternatives to CAPS
Posted: Sat Dec 28, 2013 7:22 am
by Giorgio Maone
barbaz wrote:Thanks for the link Giorgio. As far as you know, are there any plans for the new DomainPolicy API to include the ability to block specific Javascript actions everywhere, like the default CAPS policy, before Gecko 29 hits beta? If not, are you suggesting that I file an RFE in that bug even though it's already marked as resolved?
You might try, but I'm afraid it would be marked as a duplicate of
bug 951575 and eventually marked as WONTFIX.
Surrogates/user scripts are the future of that use case, it seems.
Re: Alternatives to CAPS
Posted: Sat Dec 28, 2013 6:25 pm
by barbaz
Giorgio Maone wrote:Surrogates/user scripts are the future of that use case, it seems.
Cool. Sounds like what I want is already possible then, so filing an RFE would be pointless.
After much experimentation, I found that this
Code: Select all
noscript.surrogate.foo.replacement : navigator.__defineSetter__("mozGetUserMedia", function(){});
noscript.surrogate.foo.sources : @.*
would appear to block navigator.mozGetUserMedia pretty effectively...
How reliable and future-proof is this approach in general?
Re: Alternatives to CAPS
Posted: Sat Dec 28, 2013 8:29 pm
by Giorgio Maone
barbaz wrote:Giorgio Maone wrote:Surrogates/user scripts are the future of that use case, it seems.
Cool. Sounds like what I want is already possible then, so filing an RFE would be pointless.
After much experimentation, I found that this
Code: Select all
noscript.surrogate.foo.replacement : navigator.__defineSetter__("mozGetUserMedia", function(){});
noscript.surrogate.foo.sources : @.*
would appear to block navigator.mozGetUserMedia pretty effectively...
How reliable and future-proof is this approach in general?
It is. Since surrogates can run before any other script in the page, they can effectively "patch" the DOM in a non-subvertible way, thanks also to the new Object.* methods and the Proxy objects introduced by recent ECMAScript revisions.
Re: Alternatives to CAPS
Posted: Sun Dec 29, 2013 3:54 pm
by barbaz
Thanks Giorgio for your help with this. While it's not a major problem for my addon to depend on NoScript, that's less than ideal should I ever need to disable NS for testing purposes. So one last question: On, say, page "foo", how does NoScript detect the timing of when to run surrogates with source @foo? I've looked at ScriptSurrogate.js but can't figure it out.
Re: Alternatives to CAPS
Posted: Sun Dec 29, 2013 9:13 pm
by Giorgio Maone
barbaz wrote: On, say, page "foo", how does NoScript detect the timing of when to run surrogates with source @foo? I've looked at ScriptSurrogate.js but can't figure it out.
You can run early scripts in an observer for either the "content-document-global-created" or (if you need to interact with the DOM) the "document-element-inserted"
global notifications.
Re: Alternatives to CAPS
Posted: Mon Dec 30, 2013 6:19 pm
by barbaz
Stupid me to assume that was my last question.
Well, I got it working on top-level documents by basically duplicating ScriptSurrogate.executeDOM, but since document-element-inserted doesn't appear to fire for (i)frames, how can I get this surrogate to work within frames as well? (It also doesn't work within frames when using NoScript to run the surrogate.)
Re: Alternatives to CAPS
Posted: Mon Dec 30, 2013 8:54 pm
by Giorgio Maone
barbaz wrote:document-element-inserted doesn't appear to fire for (i)frames
Really? If it does, sounds like a bug and should be reported to Mozilla.
Does "content-document-global-created" work, instead?
Re: Alternatives to CAPS
Posted: Mon Dec 30, 2013 11:34 pm
by barbaz
Oops, it does work from my addon... I wasn't being careful and ended up applying the surrogate to only chrome documents and top-level documents.
I think it's resolved now. Thanks again Giorgio.