Tor Browser 7.0a2 is released
Tor Browser 7.0a2 is now available from the Tor Browser Project page and also from our distribution directory.
This release features important security updates to Firefox.
This alpha release mainly contains updates to several of our Tor Browser components: Firefox got updated to 45.8.0esr, Tor to 0.3.0.4-rc, OpenSSL to 1.0.2k, and HTTPS-Everywhere to 5.2.11.
Additionally, we updated the bridges we ship with Tor Browser and fixed some regressions that came with our last release.
In the previous release we introduced filtering of content requests to resource:// and chrome:// URIs in order to neuter a fingerprinting vector. This change however breaks the Session Manager addon. Users who think having extensions like that one working is much more important than avoiding the possible information leakage associated with that can now toggle the 'extensions.torbutton.resource_and_chrome_uri_fingerprinting' preference, setting it to 'true' to disable our defense against this type of fingerprinting.
Another known regression is the resizing of the window. We are currently working on a fix for this issue.
The full changelog since Tor Browser 7.0a1 is:
- All Platforms
- Update Firefox to 45.8.0esr
- Tor to 0.3.0.4-rc
- OpenSSL to 1.0.2k
- Update Torbutton to 1.9.7.1
- Update HTTPS-Everywhere to 5.2.11
- Bug 21514: Restore W^X JIT implementation removed from ESR45
- Bug 21536: Remove scramblesuit bridge
- Bug 21342: Move meek-azure to the meek.azureedge.net backend and cymrubridge02 bridge
- Bug 21348: Make snowflake only available on Linux for now
- Linux
- Bug 21326: Update the "Using a system-installed Tor" section in start script
- Build system
Comments
Please note that the comment area below has been archived.
11:25:23.157 no element
11:25:23.157 no element found moz-nullprincipal:{70ca31a6-2f3f-4e4b-8450-24cf68d8210f}:1:1
12:32:53.433 : Component
12:32:53.433 : Component returned failure code: 0x805e0007 [nsIWebNavigation.loadURI] viewSource-content.js:349:0
https://check.torproject.org/
https://check.torproject.org/torcheck/img/tor-on.png
12:27:15.751 Public-Key-Pins: An unknown error occurred processing the header specified by the site. tor-on.png
Torbutton INFO: Updated
Torbutton INFO: Updated NoScript status for security settings
when switching tabs in NoScript Options
https://www.ssllabs.com/sslte
https://www.ssllabs.com/ssltest/analyze.html?d=aus1.torproject.org&s=20…
Images with "+" sign are not working after, probably, circuit is broken.
I updated 7.01 to
I updated 7.01 to 7.02
Torbirdie still does not find a connection, stable works fine
Set Torbirdy to Transparent
Set Torbirdy to Transparent Torification and then it should work. It does in my case
This is because we still
This is because we still have not fixed the underlying bug: https://trac.torproject.org/projects/tor/ticket/20761. This is scheduled for the next alpha release, though.
If you hit the Help ==>
If you hit the Help ==> About the window of the version opens up.
If you hit new identity on the main window the help/about/version window remains open. Is this an issue? Will cookies and fingerprints carry over if by mistake it has been forgotten open?
We currently believe this is
We currently believe this is not an issue. However, as you indicate, this is highly confusing. We have https://trac.torproject.org/projects/tor/ticket/10952 to fix that.
Please, remove debug
Please, remove debug compiler flag -g from stable versions.
Hm, why? Mozilla is doing
Hm, why? Mozilla is doing the same in the official releases.
WHAT???
WHAT??? https://trac.torproject.org/projects/tor/ticket/21448#comment:2
Never use debug tools for production. It's obvious.
Even if you think that Mozilla does - Mozilla and security are incompatible things.
Also see GCC 5.1 bugs with -g, you will be surprised.
17:10:36.500 TypeError:
17:10:36.500 TypeError: can't access dead object
Stack trace:
WalkerActor<.documentElement<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/inspector.js:1584:1
actorProto/ resource://devtools/server/protocol.js:1013:19
DSC_onPacket@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/main.js:1643:15
LocalDebuggerTransport.prototype.send/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/transport/transport.js:569:11
makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/DevToolsUtils.js:87:14
makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/DevToolsUtils.js:87:14
1 protocol.js:907
17:10:36.600 Protocol error (unknownError): TypeError: can't access dead object1 Promise-backend.js:936
when trying to connect, but security connection failed immediately.
HAR (DevTools warn that connection wasn't secure!):
{
"log": {
"version": "1.1",
"creator": {
"name": "Firefox",
"version": "45.8.0"
},
"browser": {
"name": "Firefox",
"version": "45.8.0"
},
"pages": [
{
"startedDateTime": "2017-03-09T17:10:31.552+00:00",
"id": "page_1",
"title": "Problem loading page",
"pageTimings": {
"onContentLoad": -1,
"onLoad": -1
}
}
],
"entries": [
{
"pageref": "page_1",
"startedDateTime": "2017-03-09T17:10:31.552+00:00",
"time": 547,
"request": {
"bodySize": 0,
"method": "GET",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1238079",
"httpVersion": "",
"headers": [
{
"name": "Host",
"value": "bugzilla.mozilla.org"
},
{
"name": "User-Agent",
"value": "Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0"
},
{
"name": "Accept",
"value": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"
},
{
"name": "Accept-Language",
"value": "en-US,en;q=0.5"
},
{
"name": "Accept-Encoding",
"value": "gzip, deflate"
},
{
"name": "Referer",
"value": "https://groups.google.com/forum/?_escaped_fragment_=topic/firefox-dev/W…"
},
{
"name": "Cookie",
"value": "_ga=GA1.2.123456789.1489123456; Bugzilla_login_request_cookie=dYUoo5667A; github_secret=a34567FgHjkl89cB"
},
{
"name": "Connection",
"value": "keep-alive"
}
],
"cookies": [
{
"name": "Bugzilla_login_request_cookie",
"value": "dYUoo5667A"
},
{
"name": "_ga",
"value": "GA1.2.123456789.1489123456"
},
{
"name": "github_secret",
"value": "a34567FgHjkl89cB"
}
],
"queryString": [
{
"name": "id",
"value": "1238079"
}
],
"postData": {
"mimeType": "",
"params": [],
"text": ""
},
"headersSize": 527
},
"response": {
"status": 0,
"statusText": "",
"httpVersion": "",
"headers": [],
"cookies": [],
"content": {
"mimeType": "text/plain",
"size": 0,
"encoding": "base64",
"text": ""
},
"redirectURL": "",
"headersSize": -1,
"bodySize": -1
},
"cache": {},
"timings": {
"blocked": 0,
"dns": 0,
"connect": 547,
"send": 0,
"wait": 0,
"receive": 0
}
}
]
}
}
Update to the previous
Update to the previous post:
It's definitely a Tor Browser issue that "Try Again" button on Secure Connection Failed page doesn't trigger making a new circuit for the current site (as previous was lost). (Because opening the same site in a new tab does which also fixes the issue ("Try Again" starts to work.)
(Note: Reloading the page with devtools still breaks FPI.)
"Try Again" should not per
"Try Again" should not per se use a new Tor circuit. That's what "New Circuit for this Site" in the onion button menu is for. But maybe I am misunderstanding you. Could you elaborate where the '"Try Again" starts to work' comes into play? Is the issue that the "Try Again" button is broken or that it does not use a new circuit? Or both? Or...?
Huh. For every
Huh. For every update/refresh/reload/hyperlink/etc of the tab Tor Browser automatically change a circuit when it was lost/broken/unresponsive/etc. But sometimes Tor Browser breaks (only secure?) connection to the site immediately (first bug) from the hyperlink, and this site was already opened for a long time in other tabs too, in this case (in log). And no refresh/F5/"Try Again" button can help (second bug), but any action in other tabs with this site triggers Tor Browser to make new connections and change the circuit until it finds a working one.
It could be, because
It could be, because of
[03-14 19:32:46] Torbutton INFO: controlPort >> 650 STREAM 650 CLOSED 99 63.245.215.80:443 REASON=END REMOTE_REASON=CONNRESET
Bug: - enter one bridge: it
Bug:
- enter one bridge: it works
- replace it with one other bridge: many error messages
"[warn] Failed to find node for hop 0 of our path. Discarding this circuit."
- to work with bridges again, need to put back first bridge (to get "listed=1"), or erase manually its "Guard" line in state file (with "unlisted_since=..." and "listed=0"), after connecting directly (and thus erasing parameters).
Reported as
Reported as https://trac.torproject.org/projects/tor/ticket/21768
Not all symbols are visible
Not all symbols are visible on https://www.mozilla.org/en-US/firefox/organizations/all/
06:39:35.082 A promise chain
06:39:35.082 A promise chain failed to handle a rejection. Did you forget to '.catch', or did you forget to 'return'?
See https://developer.mozilla.org/Mozilla/JavaScript_code_modules/Promise.j…
Date: Sat Mar 11 2017 06:39:27 GMT+0000 (UTC)
Full Message: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [imgIRequest.image]
Full Stack: JS frame :: chrome://browser/content/content.js :: PageInfoListener.serializeElementInfo :: line 1189
JS frame :: chrome://browser/content/content.js :: PageInfoListener.getMediaNode/addImage :: line 1082
JS frame :: chrome://browser/content/content.js :: PageInfoListener.getMediaNode :: line 1116
JS frame :: chrome://browser/content/content.js :: PageInfoListener.processFrames :: line 1058
JS frame :: resource://gre/modules/Task.jsm :: TaskImpl_run :: line 315
JS frame :: resource://gre/modules/Task.jsm :: TaskImpl :: line 276
JS frame :: resource://gre/modules/Task.jsm :: createAsyncFunction/asyncFunction :: line 250
JS frame :: resource://gre/modules/Task.jsm :: Task_spawn :: line 164
JS frame :: chrome://browser/content/content.js :: PageInfoListener.getMediaInfo :: line 1033
JS frame :: chrome://browser/content/content.js :: PageInfoListener.receiveMessage :: line 9341 content.js:1189:0
19:31:42.244 TypeError:
19:31:42.244 TypeError: el.ownerDocument is null noscriptOverlay.js:2473:11
Now Tor Browser accesses
Now Tor Browser accesses \device\physicalmemory during startup, same as FF52 does, and crashes if denied. But why is it doing it? For https://www.computer.org/web/csdl/index/-/csdl/proceedings/cscwd/2009/3… ?
Have you filed a bug in
Have you filed a bug in Mozilla? Seems we should have this investigated at Mozilla's site.
OpenSSL to
OpenSSL to 1.0.1k
and
OpenSSL to 1.0.2k
referred in article. One reference is wrong. Please update article.
Done.
Done.
Look how Adobe works with
Look how Adobe works with Mozilla
https://bugzilla.mozilla.org/show_bug.cgi?id=1325592#c9
Could you ask them to add anti-fingerprinting and proxy-obedience features to private browsing mode?
[03-14 19:39:44] Torbutton
[03-14 19:39:44] Torbutton DBUG: Got timer update, but no cookie change.
every minute, is OK?
Yes.
Yes.
Dear Tor Project: Stop
Dear Tor Project:
Stop intentionally making download signature verification difficult.
According to https://vbdvexcmqi.oedi.net/blog/tor-browser-numbers
1. There are 100,000 downloads of Tor Browser per day.
2. But only 5000-7000 signature verification is done per day.
93%-95% Tor Browser downloads remains unverified at all.
This is because users only have 2 options:
1. Use GPG to verify and expose their true IP.
2. Not verify at all.
Proper checksums for unsigned raw download has been requested many times, but everytime Tor Project response with the same excuse with a stuck up attitude:
"What if Tor Project get hacked and you download the wrong sig?"
Listen, this is only a valid excuse for providing a better method (The GPG method), this is not a valid excuse for not providing even basic sha256/sha512 checksum at all, because they're not mutually exclusive, you can check both.
Look around, from Linux OSes to bitcoin software, everyone provide sha256 checksums. Somehow Tor Project think they are better than everyone dispite a dismal 95% unverified rate. Worse, they have a head-in-the-sand attitude regarding this basic but critical matter.
What Tor Project need to do:
1. Provide sha256/512 checksum for the raw download like everyone else.
2. Make GPG signature verification easy, and possible over tor itself, current guide doesn't cover how to use GPG to verify over tor, thus expose your true IP.
Tor Project developers, stop thinking in ideals and look at the reality.
Take your head out of the sand and actually look at what is happening (95% downloads not verified), not what you want to happen (everyone use GPG to verify).
If Tor Project can't do that, then stop pretending you guys care about user's security and anonymity.
You are already getting that
You are already getting that for Linux bundles by default. Even for Windows you don't need GPG if you just want to check the provided SHA-256 sums (you need to strip the authenticode signature first but we have a guide for that on our signature verification page). So, OS X users are remaining then. But it seems to me that does not account for the gap between downloads/sig downloads. Moreover, we are working on that trying to provide tools to strip the signature and getting the same SHA-256 sum as the unsigned .dmg file.
Still being able to check the SHA-256 hash alone is not really more secure than just downloading the bundle and running it.
1. SHA256 checksums are
1. SHA256 checksums are available for download.
2. You can use GPG over Tor but that isn't possible if you don't have Tor installed. This is like asking the Tor developers to allow users to download the Tor Browser over Tor because it will reveal their true IP.
13:47:11.099 A promise chain
13:47:11.099 A promise chain failed to handle a rejection. Did you forget to '.catch', or did you forget to 'return'?
See https://developer.mozilla.org/Mozilla/JavaScript_code_modules/Promise.j…
Date: Sat Mar 18 2017 13:47:03 GMT+0000 (UTC)
Full Message: TypeError: inspector is undefined
Full Stack: CM_inspectNode/<@chrome://browser/content/nsContextMenu.js:593:9
Handler.prototype.process@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/Promise-backend.js:933:23
this.PromiseWalker.walkerLoop@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/Promise-backend.js:812:7
this.PromiseWalker.scheduleWalkerLoop/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/Promise-backend.js:746:1
1 nsContextMenu.js:593:0
[03-18 14:04:08] Torbutton
[03-18 14:04:08] Torbutton INFO: controlPort >> 650 STREAM 6660 DETACHED 1161 duckduckgo.com:443 REASON=END REMOTE_REASON=RESOURCELIMIT
Periodically empty page instead of DDG. Is there anything TTP can help?
fine
fine
i really feel like a noob...
i really feel like a noob... but i cant stop reading
7.0a2 uses between 70-80 MB
7.0a2 uses between 70-80 MB more ram, than 6.5.1. Just sitting on tor startpage.
Is there a regression or is this expected?
02:12:30.106 NetworkError: A
02:12:30.106 NetworkError: A network error occurred.
It is reproducible with security settings set to High and Temporarily allow all the page https://bugzilla.mozilla.org/query.cgi
It seems to be related to blocked fonts. Sometimes it shows , sometimes - query.cgi, sometimes - chrome://noscript/content/ScriptSurrogate.js, so it points to some underlying bug.
15:20:36.726 NoScript could
15:20:36.726 NoScript could not disable scripts for system global [System Principal] WinScript.js:13:11
when temporarily enabling a webpage. NoScript tries to disable scripts when it should enable them, it's a bug.
Is there instruction on how
Is there instruction on how to run snowfalke bridge?
21:08:45.531
21:08:45.531 NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMWindowUtils.sendMouseEvent]1 Main.js:2714:0
Why are my first comments in
Why are my first comments in the threads approved, but replies aren't?