Opened 9 months ago

Last modified 8 months ago

#27589 reopened enhancement

"Javascript is disabled on non-HTTPS sites" from security slider has regressed in TBB 8 / NoScript 10

Reported by: cypherpunks_reply Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: noscript, tbb-8.0-issues, tbb-regression
Cc: ma1 Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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

Child Tickets

Attachments (5)

7.5.6 - Copy.png (821.7 KB) - added by cypherpunks_reply 9 months ago.
8.0.2 - Copy.png (847.6 KB) - added by cypherpunks_reply 9 months ago.
8.0.2after - Copy.png (717.2 KB) - added by cypherpunks_reply 9 months ago.
802newtab - Copy.png (104.4 KB) - added by cypherpunks_reply 9 months ago.
custom_ui - Copy.png (724.4 KB) - added by cypherpunks_reply 9 months ago.

Change History (27)

comment:1 Changed 9 months ago by rl1987

Component: - Select a componentApplications/Tor Browser
Owner: set to tbb-team

comment:2 Changed 9 months ago by gk

Status: newneeds_information

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?

comment:3 Changed 9 months ago by cypherpunks_reply

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.

comment:4 Changed 9 months ago by gk

Keywords: tbb-8.0-issues added; regression removed

comment:5 Changed 9 months ago by gk

Keywords: tbb-regression added

comment:6 Changed 9 months ago by gk

Status: needs_informationnew

comment:7 Changed 9 months ago by cypherpunks_reply

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.

comment:8 Changed 9 months ago by cypherpunks_reply

NoScript to 10.1.9.6 that is bundled with 8.0.1 now allows you to create a per-site permission for http://

comment:9 Changed 9 months ago by gk

Resolution: fixed
Status: newclosed

Great, so we are done here I guess. If not, please reopen.

comment:10 Changed 9 months ago by cypherpunks_reply

Resolution: fixed
Status: closedreopened

comment:11 Changed 9 months ago by cypherpunks_reply

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.

Changed 9 months ago by cypherpunks_reply

Attachment: 7.5.6 - Copy.png added

Changed 9 months ago by cypherpunks_reply

Attachment: 8.0.2 - Copy.png added

Changed 9 months ago by cypherpunks_reply

Attachment: 8.0.2after - Copy.png added

Changed 9 months ago by cypherpunks_reply

Attachment: 802newtab - Copy.png added

Changed 9 months ago by cypherpunks_reply

Attachment: custom_ui - Copy.png added

comment:12 Changed 9 months ago by cypherpunks_reply

I added some screenshots to illustrate the issue.

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.

comment:13 Changed 9 months ago by gk

Cc: ma1 added

Let's see what Giorgio thinks.

comment:14 in reply to:  12 ; Changed 9 months ago by ma1

Replying to cypherpunks_reply:

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?

comment:15 in reply to:  14 Changed 9 months ago by cypherpunks_reply

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.

comment:16 Changed 9 months ago by ma1

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.

comment:17 in reply to:  16 ; Changed 9 months ago by reportUrl

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.

Otherwise, it's a great improvement!

comment:18 in reply to:  17 Changed 9 months ago by ma1

Replying to reportUrl:

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

comment:19 Changed 9 months ago by reportUrl

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.

Of course, usual behavior is like in https://www.w3schools.com/html/html5_video.asp
But click-to-play is better, and also NoScript silently blocks Media in https://www.w3schools.com/html/tryit.asp?filename=tryhtml5_video_js_prop and doesn't show it on its icon.

(BTW, https://blog.torproject.org/comment/277566#comment-277566)

comment:21 Changed 8 months ago by cypherpunks_reply

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.

comment:22 Changed 8 months ago by cypherpunks_reply

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.

Note: See TracTickets for help on using tickets.