584637 - get rid of handleNoScript

Status: RESOLVED INVALID

(Firefox :: General, defect)

Description

[:Gavin Sharp [email: [e-mail]]]

We should get NoScript fixed if it's really a problem. Hacks like this don't belong in Firefox code.

Comment 1

[Giorgio Maone [:ma1]]

I guess you refer to
http://mxr.mozilla.org/mozilla-central/source/browser/base/content/syncSetup.js#507

What does "NoScript fixed" would mean in this context, exactly?

Comment 2

[Dão Gottwald [:dao]]

NoScript should let the script through without Firefox knowing about NoScript. If this is somehow impossible we should make it possible, because otherwise we'd restrict extensibility to NoScript and lock out similar add-ons in this case.

Comment 3

[Giorgio Maone [:ma1]]

The "contract" between NoScript and its users is "I won't let the browser run scripts from arbitrary web sites unless you explicitly authorized them in advance". 

As far as I can tell, the problem here is that you're running scripts from remote web sites, which don't technically belong to the browser's chrome and which have not been whitelisted by the user.

How should NoScript "let the script through" without violating its contract? 

FWIW, NoScript maintains a very short "default" whitelist which does include mozilla.org, but users aren't required to keep it (actually the most "advanced" of them erase it on first install) and anyway it doesn't include ReCaptcha because it has a <noscript> fallback.

Comment 4

[Giorgio Maone [:ma1]]

Another problem with the default whitelist is that even if it was enlarged, only new installations would "benefit" of it.

Comment 5

[Dão Gottwald [:dao]]

For the reason I mentioned (extensibility for whole /types/ of add-ons) Firefox doesn't enter contracts with single add-ons. It's not a NoScript user.

Do we have ReCaptcha's <noscript> fallback? If not, can we add it? With that in place it seems that NoScript should just white-listing Weave.Service.serverURL.


(In reply to comment #4)
> Another problem with the default whitelist is that even if it was enlarged,
> only new installations would "benefit" of it.

You can add it to the whitelist when upgrading installations. The current NoScript doesn't claim to be compatible with Firefox 4.0.*, does it?

Comment 6

[Giorgio Maone [:ma1]]

(In reply to comment #5)
> For the reason I mentioned (extensibility for whole /types/ of add-ons) Firefox
> doesn't enter contracts with single add-ons. It's not a NoScript user.

Yet a NoScript user expects scripts from http://some-random-site.com not to run unless given explicit permissions.

> Do we have ReCaptcha's <noscript> fallback? If not, can we add it? With that in
> place it seems that NoScript should just white-listing Weave.Service.serverURL.

I hope it is a HTTPS URL and never get compromised. NoScript users are quite vocal about stuff like that (just look at the comments page on AMO).
 
> (In reply to comment #4)
> > Another problem with the default whitelist is that even if it was enlarged,
> > only new installations would "benefit" of it.
> 


> You can add it to the whitelist when upgrading installations.

I could, but if we get AMO's "No Surprises" policy literally it might be taken as a violation (CCing Jorge Villalobos for that).

> The current
> NoScript doesn't claim to be compatible with Firefox 4.0.*, does it?

NoScript does claim Firefox 4.0b3pre compatibility. It doesn't claim 4.0b4 yet because I need to work-around the breakage caused by bug 546606 first.

Comment 7

[Jorge Villalobos [:jorgev] (he/him)]

Adding something to the whitelist in the update without notifying users is guaranteed to be a problem, specially considering the types of user NoScript tends to have.

I think the approach that is most respectful for users is to allow them to whitelist the domain once the script is going to run, just like with any site. However, I also don't think it makes sense to have these workarounds in Firefox, since that wouldn't scale very well.

Would it be difficult to implement something in NoScript that makes it friendlier to interact with the Sync UI?

Comment 8

[Giorgio Maone [:ma1]]

(In reply to comment #7)

> Would it be difficult to implement something in NoScript that makes it
> friendlier to interact with the Sync UI?

NoScript already has a "Recently blocked sites" submenu which offers the 10 most recent script sources which have been blocked and are not from the current content page. Remote scripts imported by chrome and blocked by NoScript should be available there for allowing.

However IMHO a better solution would be turning the remote scripts into "browser" ones, either by having them static as resource:// stuff (ideal, since they couldn't be tampered with remotely) or by dynamically executing them with Component.util.evalInSandbox().

Comment 9

[Justin Dolske [:Dolske]]

I'm not sure if there's really a great option here. This is a bit of a novel problem, as I think this is the first case of having a web service needing JS tightly integrated with a browser feature.

* Doing nothing means that Weave signups fail (unless the <noscript> bit mentioned in comment 3 will sidestep the problem for now?), and since it's all happening in an <iframe> there's no obvious way for the user to discover what's going on. 

* Continue with what was done here, which is ugly but the recommended way for chrome/addons twiddle NoScript (bug 508112 / http://hackademix.net/2010/07/04/xmarks-and-noscript-compatibility-woes/).

* Have Weave spend time reinventing the ReCaptcha wheel, or someone cook up a new scheme for making chrome-driven web services play better with script blockers.

The only simple solution that comes to mind, albeit with terrible UX,  would be if chrome can detect when the ReCaptcha script is not running, and display an error page suggesting NoScript as a possible cause.

Comment 10

[Dão Gottwald [:dao]]

I don't see why the stock ReCaptcha fallback wouldn't work, unless we broke it like bug 508112 comment 1 suggests, but then we should fix that if we haven't already.

Comment 11

[Gregory Pappas [:gregp]]

No longer relevant