Alternatives to CAPS

[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.

[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?

[therube]

Giorgio did make a passing comment, http://forums.informaction.com/viewtopi ... 05&p=66509.

[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.

[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.

[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?

[Giorgio Maone]

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.

[barbaz]

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?

[Giorgio Maone]

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.

[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.

[Giorgio Maone]

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.

[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.)

[Giorgio Maone]

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?

[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.