Formerly this feature was accomplished by a NoScript setting that allowed scripts on HTTPS sites. Allowing scripts on an HTTP site through the NoScript button only allowed them for that particular site.
Now, this feature relies on a per-site permission in NoScript that applies the Untrusted rules to the special "http://http:" site. Allowing a single HTTP site to run scripts requires applying the Default or Trusted rules to the "http://http:" site in the NoScript button UI. This has the undesired effect or granting these permissions to all HTTP sites for the browsing session.
Furthermore, changing a per-site permission to default deletes it from the per-site permissions list in NoScript settings. Users cannot restore the setting manually because "http://http:" is not accepted by the settings UI as a valid input. To stop allowing scripts on subsequent visits to HTTP sites they must toggle the security slider settings, or import a settings backup to NoScript, or restart the browser.
If the above were fixed, and each HTTP site was given its own per-site permission there is an additional problem. There is no "Temp. Default" option, only "Temp. Trusted," but only the default rules are required to allow script execution. This makes it tempting to give HTTP sites Temp. Trusted permissions so that the Revoke Temporary Permissions button will apply to them. At present, restarting the browser will reset all per-site permissions, but this may be changed (see #27175 (moved)). If per-site permissions are saved, users will be forced to choose between granting temporary but excessive permissions, or risk storing a record of their browsing history.
Trac: Username: cypherpunks_reply
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items ...
Show closed items
Linked items 0
Link issues together to show that they're related.
Learn more.
This sounds like a NoScript bug to me, no? Or are you saying that the option of "JavaScript is disabled on non-HTTPS sites" as we ship it in the slider is not working as expected?
As shipped in the slider, it functions differently and unexpectedly worse than before TBB 8.0 / NoScript 10. The difference being that you can't easily allow scripts to run on a single HTTP site without allowing it for all of them, and arguably worse, you can't even settle for temporarily allowing scripts for all HTTP sites, because there's no obvious way to revoke the permission without restarting the browser.
As for where the bug is, the previous implementation relied on a specific feature of NoScript but now it seems that the per-site permission in NoScript for "http://http:" is something special that came from the TorBrowser security slider, since NoScript's settings UI won't allow the user to add it as a per-site permission.
I should clarify that the issue of "no obvious way to revoke the permission without restarting the browser" only applies if you grant HTTP sites the default permission. You could grant all HTTP sites Trusted permissions, and then when you're done, change them to Untrusted permission. This seems wrong since HTTPS sites only get Default permissions with the slider on Safer.
This is because of how NoScript works. A changing a site to default permissions deletes it from from the per-site permission list. This is only problematic because the way the "scripts disable for non-HTTPS" features is implemented. The site's domain doesn't appear in the NoScript button popup as normal, but only as a line "http://http:" that applies to all http sites.
To allow scripts to run on an HTTP site you change the trust level for "http:" which applies to all HTTP sites. In fact it's hardly obvious to the beginner that "http:" applies to the top level site that they wish to allow, and for more experienced users that they're changing permissions for all HTPP sites.
This is a regression over the old version as well as an unexpected change. The old version had a checkbox enabled feature that modified the defaults for HTTPS sites, while allowing them to each have their own entry in the temporary grant UI (the box that pops out when clicking the NoScript button on the toolbar.
7.5.6 - Copy.png: Tooltip confirms the privilege grant only applies geistglobal.com
8.0.2 - Copy.png: Where's geistglobal.com? To grant the least privilege that allows scripts, and without using the custom option, click on DEFAULT for http:.
8.0.2after - Copy.png: After clicking DEFAULT for http:. Where's http:? All HTTP origins now have entries in the UI with DEFAULT permission.
802newtab - Copy.png: "All HTTP origins" as mentioned above is not restricted to third party origins (I hope this is the correct use of origin?) for geistblobal.com but to all HTTP origins. The domains colored red in the UI indicate that they are HTTP origins.
custom_ui - Copy.png: This is to illustrate a personal wish that I think could be done with low effort. I feel like the NoScript UI is targeted to more advanced users than TorBrowser, and in TorBrowser the NoScript UI is essentially there to implement the slider which is supposed to be a user friendly feature. If the UI for the custom tab as seen in the screenshot was always displayed for every domain, it would be much easier for users to learn that unchecked checkboxes with red backgrounds should be clicked to make the page work.
8.0.2 - Copy.png: Where's geistglobal.com? To grant the least privilege that allows scripts, and without using the custom option, click on DEFAULT for http:.
Just brainstorming here: maybe this problem would be mitigated, or even fixed, if we show in the popup UI the actual domains of sites matching the a protocol-only permission key (e.g. "http:"), so you can override them individually to DEFAULT, (temporary) TRUSTED or (temporary) CUSTOM.
Whether showing in the popup also the "http:" entry itself or leaving it to the Options panel only could be debated, or made an Appearance preference.
How does this sound?
If the UI for the custom tab as seen in the screenshot was always displayed for every domain
Not sure I understand: do you mean that every domain in the popup should be pre-set to CUSTOM and its customization UI be displayed by default (i.e. two rows for each site entry) in the popup?
1st point: If that would avoid enabling javascript for all HTTP domains, that sounds good. I think that's the basic expectation of users. If per-domain permissions already gives more specific matches a higher priority then this would only be a change to the pop-up display? I guess you'd have to add a delete button to the per-domain permissions UI in the settings since setting a domain to default is now a legitimate override that should be saved.
2nd point: Yes, I mean that every domain would have two rows, but not that all domains should be set to custom. I mean that the second row should show the details for the domain's current setting. The point is to quickly see that media is unchecked with a red background on 2 out of 10 domains. At this point the user could switch these domains to trusted and see the media checkbox get filled in (the checkboxes could be read-only in this case) or easily create a custom rule by clicking on the media checkbox which would switch the domain to the custom tab. The first is probably better so that the users stick to the presets and the presets can be changed by browser updates if necessary.
I think I made a fair compromise in 10.1.9.7rc2, please check it: it provides site / domain entries to override the protocol-level permissions, while "shadowing" the DEFAULT choice with the actual inherited preset, in order to make clear that you should use either the TRUSTED, UNTRUSTED or CUSTOM ones as an override, otherwise you'll fall back to inheritance.
Replying to ma1:
In Settings/General:
UNTRUSTED* TRUSTED UNTRUSTED
UNTRUSTED* is somewhat confusing, because it shows permissions for DEFAULT https: while its hint shows Untrusted(http:).
Http Media is now visible on https page, but click-to-play doesn't work.
Classic version of NoScript had a Cascading permissions rule which could be easier for users.
Replying to ma1:
In Settings/General:
UNTRUSTED* TRUSTED UNTRUSTED
UNTRUSTED* is somewhat confusing, because it shows permissions for DEFAULT https: while its hint shows Untrusted(http:).
That's a bug, of course, thanks for catching that. I'm gonna fix it ASAP.
Http Media is now visible on https page, but click-to-play doesn't work.
Example URL? BTW, mixed content like that shouldn't work at all, AFACT...
And you? Mixed passive content is allowed in Firefox:
10:46:54.579 Loading mixed (insecure) display content “http://video.com/2013.mp4” on a secure page
and if you allow Media for that domain before you allow js to load it, then NoScript will ignore it, block Media later anyway and add a new row for that domain.
I tried the beta and while it does show the http domains in the pop up, it is still pretty confusing. The leftmost column is highlighted with UNTRUSTED* for the HTTP domains, but until now that column indicated DEFAULT permission. Also this means you can't assign DEFAULT permission to individual HTTP domains. You could allow scripts by changing them to TRUSTED or change all HTTP domains to DEFAULT by modifying the http: row.
I think one issue here is that the term default and trusted are overloaded. HTTPS domains default to DEFAULT permissions, and HTTP domains default to UNTRUSTED. If highlighting the leftmost column in the popup means that the default permission applies (the default permission doesn't have to be the DEFAULT ruleset) then the name of the DEFAULT ruleset is misleading. Similarly, TRUSTED here basically means greater than normal trust. DEFAULT means neutral trust. UNTRUSTED has two possible meanings, neutral trust (so, not worthy of elevation to TRUSTED, which today is DEFAULT), or today's meaning, negative trust (less trust than neutral / DEFAULT). So renaming the DEFAULT ruleset to something that implies generic or no-opinion would clarify the meaning of the left-most column in the popup.
In case the practical part of my previous comment isn't clear, you can't assign DEFAULT to HTTP domains because there is nowhere to click on DEFAULT. It's not clear to me that this is the bug referred to in reply 18 but it could be related.