#27553 closed defect (fixed)

Tor Browser 8 enables JS in local files even when JS is disabled by default

Reported by: pf.team Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Major Keywords: noscript tbb-8.0-issues tbb-regression
Cc: ma1 Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Tor Browser 8.0 enables JS when opening local files, even when Javascript is disabled by default. For example, the following test file:

<html>
<head>
<title>Page with JS</title>
</head>
<body>
<script>window.alert("JS enabled")</script>
</body>
</html>

would not display the message in version 7.5 or older, when NoScript is set to "disable scripts globally", but in 8.0 the script will run and display the message. The only way to avoid this behavior seems to be setting javascript.enabled = false in about:config, but this disables Javascript entirely.

This potentially allows to track users who saved some web pages with tracking JS code to review locally later on, and then opened them in TB, thinking that, since they set JS to be disabled by default in their browser, this will also hold true for any local files. Especially considering the fact, that this is how it used to work until now.

Child Tickets

Change History (4)

comment:1 Changed 10 months ago by gk

Keywords: tbb-8.0-issues tbb-regression added; ff60-esr javascript removed

comment:2 Changed 10 months ago by gk

Cc: ma1 added

We might need a NoScript fix here, adding Giorgio.

comment:3 Changed 10 months ago by ma1

file:/// URLs are not processed by webRequest, so in theory this would be out of reach for WebExtensions, which usually operate on page permissions by injecting a customized CSP in webRequest.onResponseHeaders.

But luckily enough, I've very recently I devised a new redundant approach for dealing with edge cases like this, so 10.1.9.2 RCs should "fix" this.

comment:4 in reply to:  3 Changed 10 months ago by gk

Resolution: fixed
Status: newclosed

Replying to ma1:

file:/// URLs are not processed by webRequest, so in theory this would be out of reach for WebExtensions, which usually operate on page permissions by injecting a customized CSP in webRequest.onResponseHeaders.

But luckily enough, I've very recently I devised a new redundant approach for dealing with edge cases like this, so 10.1.9.2 RCs should "fix" this.

Hey, this got release faster than I could test it. ;) Anyway, this works for me now with 10.1.9.5, thanks!

Note: See TracTickets for help on using tickets.