- tbb-dev - lists.torproject.org

[Proposal] Tor Browser Quickstart - Call for Comments
by Antonela Debiasi 30 Nov '20

30 Nov '20

Hi, We've been defining an improved user flow for starting Tor Browser and connecting to Tor, with particular attention in censored contexts. The aim is making Tor Browser proactive in detecting censorship and improve the bridge's acquisition by making it easier for users to use them. We'd be interested in hearing thoughts from folks bootstrapping Tor in their clients about these improvements.[0] The target of this proposal is Tor Browser 10.5 (Q22021). Have a lovely weekend! A [0] https://gitlab.torproject.org/tpo/applications/tor-browser-spec/-/merge_req… ----- Filename: xxx-quickstart.txt Title: Tor Browser Quickstart Author: antonela Created: 09-Sep-2020 Status: Draft Target: Tor Browser 10.5 1. Introduction This proposal aims to improve the user experience of Tor Browser when connecting to the Tor network. 2. Motivation Tor Browser is opened more than 2 million times a day. In the last years, we have been working on qualitatively improving the entire Tor browser user journey: from discovering, finding, downloading, installing, starting, and browsing, we released a seamless and familiar experience for our largest set of users. But, launching the Tor Browser for the first time is still being a frictional experience. Tor Launcher has been confusing for users. Past research exposed those pain points and how that confusion delays the decision making flow by cognitive overloading [0]. Also, known issues around Tor Launcher like the time gap between Tor Launcher and the main browser windows opening on first-time installers have made Tor Browser starting even more disappointing for first-time users. This proposal aims to improve the bootstrapping flow for first-time and recurrent users by removing Tor Launcher UI, making Tor bootstrapping automatic, and relying on a better UI embedded in the main browser screen as visual progress feedback. We will also consider the censored user's experience by informing detected censorship and suggesting and providing bridges to connect to the Tor network successfully. 3. The case of the censored user Around 2% of daily Tor users need bridges to reach the Tor network [1]. In any case, this small percentage doesn't enable us to de-prioritize the need of these users. Instead, this proposal will also provide a user experience that contemplates censored users' need to access the network by making Tor Browser proactive to detect censorship and suggest Bridges. 3.1 Bridges It is difficult for a user to select between a different bridge option relying on its name if they don't know what that bridge does for them. A usual flow for users requesting bridges is trying in-build Tor Browser bridges and failing to connect until they work. As well, users with specific needs are pointed to specific bridges by trusted community members, and they pick the recommended choice without a technical background. Over the years, Bridges' technology has been improving as how the censorship arms race has been developing. OBSF3, OBSF4, Meek, Snowflake, and more proxy techniques are available for successfully reaching the Tor network. Regular users cannot differentiate between the technologies under the construction of Bridges. I suggest attaching the name **"bridge"** to any intermediate node that allows users to reach the network. By unifying the vocabulary in the interface and our user manuals, we will simplify the complexity behind all this technology by warning and educating users about bridges uses. This strategic decision will allow the community to continue developing technology for bridges without moving the attention to the technical name but the conceptual solution [2]. 3.2 Detecting censorship As discussed in the past, it is plausible for us to use retrospective data or a Tor reachability test in any fashion to detect network interference in the user's NAT and act upon that [3][4][7]. Most of the time, users get aware of a kind of network interference when they try to connect to the network, and the bootstrapping fails. But even in those cases, most users have not the technical background to understand nor explain that censorship experience. Within this proposal, the Tor Browser will be able to detect censorship for users and suggest the best bridge available to connect. 3.3 Suggesting Bridges With this iteration, we aim to make Tor Browser proactive on detecting censorship, respectful on asking user consent to use a Bridge and smart enough to open the best bridge available. Advanced users will be able to configure custom bridges, private bridges, friends bridges, and any tunnel they want via `about:preferences#Tor` - Bridges. Once censorship has been detected, Tor users will be able to opt-in for a Bridge connection to reach a successful connection [5]. 4. Proposal Specifically, this proposal will handle this issues: - Remove gap between Tor Launcher window and main browser window https://bugs.torproject.org/27476 - Improve user visual feedback on bootstrapping connection https://bugs.torproject.org/23486, https://bugs.torproject.org/23971 - Show Tor log in Tor Browser https://bugs.torproject.org/9516 - Firewall option is visible behind Tor Network Settings... but not during start-up https://bugs.torproject.org/24452 - "Tor is censored in my country" does not cover some scenarios https://bugs.torproject.org/25431 - Tor Launcher should suggest the use of bridges if Tor is dangerous in user's area https://bugs.torproject.org/11132 - Inform users in Tor Launcher of which settings are best for them based on their country https://bugs.torproject.org/24527 - Make it easier to add a bridge in network settings https://bugs.torproject.org/14638 - Use OONI to inform Tor Launcher user workflow https://bugs.torproject.org/23838 4.1 Requirements R1 Remove Tor Launcher UI from the entire starting flow R2 Allow users to give consent on the first time use of automatic connection R3 Implement a new UI integrated with the main windows that provide visual feedback during tor bootstrapping. R4 Allow advanced users to customize their bootstrapping experience using an extra startup parameter. [8][13] R5 Develop a detecting network interference that allows users to request a bridge if it is needed. Users under controlled networks are detailed in section 3. R6 Continue keeping Tor Launcher repository for 3rd parties using their controllers or UI. 4.2 User flow The user opens the Tor Browser and automatically connects. If interference is detected, then an explainer error page appears, and a Use a Bridge is offered. 4.3 Quickstart Previous experiences of clients bootstrapping Tor without asking to Connect have been successful. Onionshare, the popular Tor sharing files app, doesn't request user action to bootstrap Tor. Instead, a minimal UI progress bar is shown during the 1 or 2 seconds bootstrapping happens. OnionBrowser, the Tor Browser for iOS also bootstrap automatically. Brave's Tor startup is transparent to the user and the bootstrapping visual progress feedback happens at the URL bar. Quickstart is the feature that enables an automatic Tor connection in Tor Browser. As a first step in introducing this feature, we may want to make this Opt-In by allowing users to give consent and save this setting in our persistent configuration. * Phase One - Userflow The user opens the app; the connecting screen appears. Like the current flow, user needs to click in the Connect button to connect to Tor. On first time users, we ask consent for automatic connections. [9, IMG 0.0] Opted-in recurrent users will go directly to `about:tor`. We will disable the URL bar and we will rely on a loading bar UI to render immediate visual feedback. A work in progress user interface for desktop [9] and mobile [10] is attached to the main ticket [12]. * Phase Two - Userflow The user opens the app; Tor bootstraps automatically. To enable phase two, we need a Tor reachability test in place as part of the Tor bootstrapping. If there is network interference, the interference detected screen appears and Use a Bridges is offered. 4.4 Customizing Tor connection Specific use cases, as in users who want to hide the fact that are using Tor or users aware of censorship in their network, should be able to start Tor Browser offline, be directed to `about:preferences#tor` and configure their connection before Connect. A startup parameter should allow this option. 4.5 Recovering from error During our product iteration cycles in this flow, there may be the case where the bridge that is being suggested does not work. We will allow users to try a Bridge again, and then we will move them to the manual configuration in `about:preferences#Tor` - Bridges. General Tor bootstrapping errors handling will not be covered in this proposal. 5. User research Our ongoing user research over Tor Browser Start pain-points and bridges' use is being tracked in its corresponding ticket [14][15]. [0] https://github.com/lindanlee/PETS2017-paper [1] https://metrics.torproject.org/userstats-relay-country.htmlvs https://metrics.torproject.org/userstats-bridge-country.html [2] https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/8 [3] https://gitlab.torproject.org/tpo/community/outreach/-/issues/28531 [4] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/23839 [5] https://gitlab.torproject.org/tpo/applications/tor-launcher/-/issues/34343 [6] https://gitlab.torproject.org/tpo/anti-censorship/trac/-/issues/40004/desig… [7] https://gitlab.torproject.org/tpo/core/tor/-/issues/30477 [8] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/34345 [9] https://gitlab.torproject.org/tpo/anti-censorship/trac/-/issues/40004/desig… [10] https://gitlab.torproject.org/tpo/anti-censorship/trac/-/issues/40004/desig… [11] https://trac.torproject.org/projects/tor/ticket/31286 [12] https://gitlab.torproject.org/tpo/anti-censorship/trac/-/issues/40004 [13] https://tails.boum.org/blueprint/network_connection/ [14] https://gitlab.torproject.org/tpo/anti-censorship/trac/-/issues/40003 [15] https://gitlab.torproject.org/groups/tpo/-/milestones/7 -- Antonela Debiasi UX Team Lead @antonela E2330A6D1EB5A0C8 https://torproject.org

8 10

RFC: WebGL Click-to-Play as a Privacy Protection
by Matthew Finkel 23 Nov '20

23 Nov '20

In light of WebGL extensions now being available [0] and other potential uses of WebGL for fingerprinting, I'd like to consider restricting access to the WebGL API in Tor Browser as a Privacy enhancement, and no longer as a Security enhancement. One major usability (webcompat) issue I know about when WebGL usage requires click-to-play is Google Maps. Are there other popular sites that break when click-to-play is enabled that we should consider? Thanks, Matt [0] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40117

2 1

Intent to Remove: Fuzzyfox
by Tom Ritter 11 Nov '20

11 Nov '20

Fuzzyfox[0] is an implementation of a research idea that severely limits the data that can be extracted by timing side channels exploited by untrusted JavaScript. It effectively provides a knob that allows one to control the amount of data that can be extracted by controlling the coarseness and fuzziness of the clock used by the browser. In comparison to our existing clock fuzziness enabled now, it operates in the context of the entire browser, rather than just the explicit timers and clocks exposed to untrusted JavaScript - therefore it also mitigates the data that can be extracted by constructed clocks relying on e.g. web animations. Unfortunately it does not address the fact that Shared Array Buffer can be turned into a precise timer, it was written in the early days of SAB and produces its results by disabling it. We landed it two years ago[1], and had intended to explore it further if needed for Spectre, as well as see if it could be used practically to mitigate the multiple and various timing attacks that have been demonstrated in browsers to steal user browser history, cross-application user activity, cross-origin images or frame data, etc etc. We've never gotten to that examination, and it seems that we might never; so in the interest of clarity and cleanliness it makes sense to remove it. Presently, if you enable privacy.fuzzyfox.enabled you will switch over to Fuzzyfox mode. You will probably experience some jank and bowser slowdown. Fuzzyfox affects the entire browser, and that does include sleeping on the main thread[2] in certain circumstances. Had time been available, the next steps would have been to get profiles of poor browser behavior under Fuzzyfox, and try to understand why they were occuring. (Setting privacy.fuzzyfox.clockgrainus too coarse would cause expected slowness, but 250 ought to be a usable number, ideally 1000.) This work will be done in https://bugzilla.mozilla.org/show_bug.cgi?id=1666222 -tom [0] https://www.usenix.org/conference/usenixsecurity16/technical-sessions/prese… [1] https://bugzilla.mozilla.org/show_bug.cgi?id=fuzzyfox [2] https://searchfox.org/mozilla-central/rev/02cb78667e87ccc42fea5edc6f3f2dd2e…

1 0

Moving non-mobile platforms over to the rapid release train
by Georg Koppen 06 Nov '20

06 Nov '20

Hello everyone! We have been working the last few months on getting mobile Tor Browser hooked into the rapid release train, away from the ESR series. It's been exciting all around. We are close to releasing a first stable mobile release and are getting used to the process of frequently updating toolchains, different patch sets, and auditing new code. It's time for looking forward and thinking about desktop Tor Browser. Getting desktop To Browser onto the rapid release train at the same time while maintaining the mobile part + having additional sponsor work on our plate is very likely too much for our 2 1/2 current browser devs. So, we originally thought about postponing that until we have more capacity. But maybe we can be smarter. It's not desktop vs. mobile but more that we have 4 different platforms we support and the first one, Android, made it onto the rapid release train. What if we moved the others platform by platform to test how hard it is and just move forward if we are confident we can handle the workload? I'd propose we start with Linux on the non-ESR train next and soon. That means switching Linux nightlies, or if we are confident, even Linux alphas, too, off ESR. Now, how well works this with 1) Toolchain updates: I think there are no large issues to expect as we need to update compilers etc. anyway for mobile. With tor-browser-build#40125 fixed we are back to a somewhat reasonable project structure and making the necessary changes for Linux should just be some additional lines in a small part of config files and build scripts. This should be manageable. 2) tor-browser patch rebasing: I think, too, here are no issues to expect. We already need to rebase all the patches for mobile and are not skipping the desktop-only ones. 3) desktop-specific code parts That's the item with the biggest uncertainty to me given that we basically ignore the desktop-only parts to a large extent (apart from making sure things are compiling) when preparing for mobile. There are two parts to it: a) torbutton/tor-launcher and b) the updater. We already fixed Torbutton code in the past for changes introduced after ESR 78. Extrapolating from that experience I am not too worried about either Torbutton or Tor Launcher. The updater is an unknown here but looking over the changes we need(ed) to make for tor-browser rebasing they seem farily small and uncontroversial, so I am not too pessimistic here either. 4) Test suite (tor-browser-bundle-testsuite) We have updating the test suite for new mozillaXX milestones already on our ToDo list when preparing new mobile releases (see: tor-browser-bundle-testsuite#40008 and #40009 for examples). And now the important part: we need to build Linux builds for that task anyway. So, we would actually benefit here from officially moving Linux off the ESR train without any additional costs test-suite-wise. 5) Proxy bypass/feature/closed bugs audit We do all those audits already for mobile. No additional work for any of the desktop platforms is needed (apart from having the respective platforms in my, too, when going over, say, all the closed Mozilla bugs). Now, if we start soon-ish (e.g. with mozilla84 landing on beta) we even have enough time to get accustomed to and test the whole process so that we can think about releasing 10.5 with Linux off the ESR train and/or b) adding macOS and Windows (in that order) to the rapid release wagon as well in the not too distant future. If we still feel uncomfortable with having Linux or any of the other desktop platforms off ESR for 10.5 then it should not be too hard to leave those platforms on the alpha/nightly series on rapid release and go for them with ESR for 10.5. So, the risk for not stabilizing 10.5 and not shipping a good 10.5 because of the above proposal should be low. Georg

2 2

Parsing PDBs
by Sanketh Menda 04 Nov '20

04 Nov '20

Hi, Yesterday, I was looking into Firefox Bug 1612422 which aims to create a reproducible build job for mingw, and I came across the following two tools for parsing PDBs, you might find them useful: - microsoft's cvdump.exe: https://github.com/Microsoft/microsoft-pdb/ - LLVM's llvm-pdbutil: https://llvm.org/docs/CommandGuide/llvm-pdbutil.html Best, Sanketh

1 0

Tor Browser Meeting - 2 November at 1900 UTC
by Matthew Finkel 03 Nov '20

03 Nov '20

Hello everyone, During last week's browser meeting we decided we should change the time of today's meeting to 1900 UTC. At today's meeting we will decide at which time we'll have the meeting over the next few months. - Matt

1 1

Tor browser fingerprint with javascript enabled problem
by joel04g_t535e＠secmail.pro 30 Sep '20

30 Sep '20

With javascript enabled, websites can know If you use linux or windows. In my opinion, this is more information than a website should have. As a linux user, I visited panopticlick.eff.org and did the browser fingerprint test. The results revealed my platform to be "Linux x86_64". Is there a way that Tor devs can make Tor browser spoof this value to be the same for all users or random, regardless of OS? -Joel

3 3

browser build for Linux arm64
by Martin Kepplinger 29 Sep '20

29 Sep '20

hi, in order to serve Linux tablets and phones, even Laptops based on arm64 will become more popular I guess: Are there plans to add arm64 builds to https://www.torproject.org/download/languages/ ? thanks a lot, martin

3 2

Re: [tbb-dev] Canvas Breakage Ideas
by Alex Catarineu 21 Sep '20

21 Sep '20

On 5/19/20 6:02 AM, Matthew Finkel wrote: > On Wed, Apr 29, 2020 at 01:07:40PM +0200, Alex Catarineu wrote: >> With respect to 2), I think it's interesting, but I also don't know whether >> it's feasible in practice. Specifically, I was thinking of Gijs idea of >> trying to keep state about whether the canvas is safe to read or not, >> fingerprinting-wise. I assume that there is a (non-empty) subset of canvas >> write operations that are "fingerprinting-safe". Probably a bit naively, I'd >> like to think that `canvas.drawImage` is "fp-safe" (irrespective of the >> image source). But even if we have to check the image source, I think >> implementing this could potentially unbreak some of these common legit >> canvas use cases. >> >> For example, in the WhatsApp case mentioned above, I'm quite sure it's >> just used for image format conversion, since the bug does not occur >> when uploading "jpeg" images. So, that would be something like >> `canvas.drawImage(pngImage, 0, 0);` plus `canvas.toDataURL('image/jpeg');`, >> which should be covered if we implement the `canvas.drawImage` exemption >> when the image was uploaded by the user. This "fingerprinting-tainting" >> canvas logic might start with just the `drawImage` case, but perhaps it >> would be possible to extend little by little, if we know that some >> canvas write operation is safe and can help fixing breakage for legit >> use cases. > > I generally agree with your message, but I am curious about this idea. > Are you saying that ctx.drawImage() is fingerprinting-safe, or are you > saying that any "canvas extraction" from a canvas element initialized by > ctx.drawImage is fingerprinting-safe? As far as I'm aware, drawImage() > is not protected by the Canvas prompt (so that should never be a > problem). If your comment was about "subsequent canvas extraction", then > that is worth investigating. Yes, by fingerprinting-safe I meant the subsequent canvas extraction after a `drawImage`. And by checking the image source I meant that we might consider a `drawImage` fp-safe if we know the input is an image uploaded by the user, even if `drawImage` was not "fingerprinting-safe" in general (with the idea that canvas extraction might not result in useful fingerprinting in that case). > Are any of the conversions passed onto the > GPU? Do we know if format conversation is deterministic? True, I did not consider that the extraction (e.g. `toDataURL('image/jpeg')`) might add some entropy by itself. Good questions, we would need to investigate if this approach is going to be pursued. And I agree with tom, it would be good first to investigate what these sites are doing exactly with the canvas to evaluate what would be the best approach.

5 10

Release schedule for the Tor Browser alphas?
by anonym 27 Aug '20

27 Aug '20

Hi, I'm in the process of scheduling a release candidate for Tails 4.11 and I'd like it to include the latest possible Tor Browser 10 alpha, so I'm interested in what your plans are for the coming weeks (especially around September 7-11, which likely is when we have to release this release candidate). Do you have any dates set yet? Guesses? Is there a (public) schedule I can look at somewhere so I don't have to ask you in the future? :) Otherwise, do you think we'll miss out on anything important to test if we ship the current 10.0a5 in the release candidate? Cheers!

2 2