Hi everyone,
Here's a plan for experimenting with moving Tor Browser from ESRs to
mozilla-central. Why try this? There are several reasons I can think
of:
* There is no mobile Firefox ESR. In order to keep mobile Tor Browser
secure, we would either need to constantly monitor for security fixes
and apply backports. It will be simpler to follow the Mozilla release
cycle.
* Tor Browser will receive all security patches and security features
from Mozilla, not simply those deemed important enough …
[View More]to backport to
the last ESR.
* Closer collaboration between Mozilla and the Tor Browser team will
be possible, because everyone will be focused on the same codebase.
For example, non-urgent patches can land directly on mozilla-central,
bypassing tor-browser.git altogether, and those patches will be
deployed to Tor Browser faster than they would have been on an
ESR-only schedule. Mozilla will provide expert review of patches.
Also, some non-urgent patches by Tor Browser may be written by Mozilla
engineers.
* The Tor Browser development process will be smoother and more
gradual. Instead of rebasing and patch-fixing sprints ahead of each
ESR, we can automatically rebase patches every night, and fix any
patch whenever its rebase fails. (The total rebase effort should be
approximately the same as before.)
* Patches that frequently break because they live on "hot code" can be
identified and uplifted.
* We'll need to continuously monitor the mozilla codebase for new
features that could harm privacy. That's potentially difficult, but by
focusing on Mozilla's current work, we can hopefully stop patches that
affect privacy before they land.
Here's how I envision the new rebase process:
* An automated script rebases all tor browser patches every night
against mozilla-central, mozilla-beta, mozilla-stable and mozilla-esr.
An email alert will be sent if the rebase of any patch fails. (I have
a prototype script that does the basic rebasing -- it found that
~40/140 patches from our ESR-52 branch could be auto-rebased onto
mozilla-central without any intervention.)
* Any failed patches will need to be manually fixed up promptly so
that the automated rebase can resume.
* Diagnostic Tor Browser bundles will be built against the latest
rebase branches. We can also run regression tests.
So how do we ramp up this experiment?
1. 2018-1-1 to 2017-2-22: Rebase tor-browser.git patches manually on
top of Firefox 59-beta. (We have to do this anyway.)
2. 2017-2-22 to 2018-3-13: Activate a script that rebases Tor Browser
patches nightly onto mozilla-(central, beta, stable, esr).
3. 2018-03-13 to 2018-05-07: Create nightly Tor Browser bundle builds
based on nightly rebases.
At this point, we can evaluate whether we would like to transition to
releasing Tor Browser alphas based on the mozilla-beta branch.
Switching Tor Browser stable to mozilla-stable can happen sometime
after that.
How does this sound? Interested to hear what you think.
Thanks,
Arthur
[View Less]
Hello tb team!
as mentioned on today's sync the ux team would like to have weekly syncs
with you on Wednesdays during the month of April.
The syncs will be at 1800UTC at #tor-meeting channel.
For this first one we would like to discuss tickets:
Activity 4.1: Improve how circuits are displayed to the user
https://trac.torproject.org/projects/tor/ticket/24309
Activity 2.1: Improve user understanding and user control by clarifying
Tor Browser's security feature
https://trac.torproject.org/…
[View More]projects/tor/ticket/25658
As we discussed in Rome, we will also be building the design for mobile
as we work on these desktop items.
These syncs will be to have quick review/feedback cycles every week so
we can move on with the work and be ready for when its time to implement it.
See you tomorrow!
cheers,
isabela
[View Less]
Hi,
I was wondering if there was any community interest in migrating the Orbot
project (or portions of it) to the Kotlin language?
This is more of a personal itch since I’m migrating some of my own
open-source projects to Scala/Kotlin to reduce code complexity. I will be
using Tor for the endpoint connections so will be migrating/writing some of
the Tor management libraries.
As a prototype, I migrated orbotservice module to Kotlin. I managed to
reduce a fair amount of code and to break …
[View More]apart some of the pure data
operations from state changes. Below is the code, if anyone is interested
in seeing how it looks
https://github.com/sisbell/orbot/tree/kotlin/orbotservice
If there’s interest, I’ll write up unit tests and verify functionality
before doing a merge request to the Orbot project. I would like to
eventually explore making the code functional and introducing actors as
event handlers.
If there is not much community interest, I’ll just maintain a fork and see
how it evolves.
Best Regards,
Shane
[View Less]
Recently, Kathy and I spent some time looking at the changes that have
been made to the Firefox updater since ESR52. The purpose of this
message is to highlight a few of the most important changes. It would be
helpful for other people on the team to review and comment on our
assumptions.
1. "Simplify the application update UI"
https://bugzilla.mozilla.org/show_bug.cgi?id=893505
The user experience has been streamlined. The big ugly update dialog has
been removed and doorhangers are instead …
[View More]used to prompt people to
update. We will want to adjust some prefs that control how soon users
are nagged to update (to reduce the time, as we did with the older
update UI) but Kathy and I think the new experience should be okay for
Tor Browser users. There is a work item for later this year to work with
our UX team to improve the update experience, but first we will need to
get the ESR60-based one working.
2. "LZMA support for updater"
https://bugzilla.mozilla.org/show_bug.cgi?id=641212
Within the MAR files, each file or patch is compressed. Prior to Firefox
60, BZip2 compression was used. By switching to LZMA, file size is
reduced by 10-20% in most cases. Some size comparisons that were done
for Firefox are available here:
https://bugzilla.mozilla.org/show_bug.cgi?id=641212#c250
Kathy and I think we want this change for Tor Browser, but it will mean
that we must execute a "watershed" (two-step) update process wherein
older browsers must first update to a Tor Browser based on ESR60 before
they can update to a newer version. In other words, we will need to
provide old-format MAR files to old browsers so they can be updated to a
browser that understands the new LZMA-based format. We have never done a
watershed update for Tor Browser, so it will be exciting to try.
3. "Support stronger hash algorithms than SHA1 for signing certificates"
https://bugzilla.mozilla.org/show_bug.cgi?id=1105689
Mozilla switched from SHA1 hashes for MAR files to SHA384. We have been
using SHA512 for Tor Browser from the beginning (via patches to the
Mozilla code). The reason Mozilla chose SHA384 over SHA512 is reduced
vulnerability to length extension attacks. I am not a crypto person, but
it seems to Kathy and me that switching to SHA384 is a win because we
can eliminate some of our patches. If we are doing a watershed
(two-step) update process to get the LZMA support, we can handle the
SHA512 -> SHA384 transition at the same time. Mozilla did this same
thing, adopting both incompatible changes to the MAR format together in
Firefox 56.0 timeframe.
4. "Remove hashFunction and hashValue attributes"
https://bugzilla.mozilla.org/show_bug.cgi?id=1373267
Mozilla removed support for a hash check of the MAR files that has
historically been implemented by including hash values in the update
manifest (XML) file that is returned by the update server. Mozilla
relies on MAR signatures to verify the integrity of the Firefox MAR
files, but in the past we have talked about the value in requiring that
two things need to be compromised: the update server as well as a MAR
signing key. For that reason, Kathy and I believe we should back out
these changes and continue to have our update server return hash values.
As I mentioned above, your input is welcome. Thanks!
-Mark
[View Less]
Hi all!
Below is the updated version taking the feedback I got so far into
account. If you think it did not address the points you brought up,
please say so (and do so as well in case new issues popped up since the
first draft got sent).
We had quite some discussion about doing First Party Isolation (FPI) on
top of the security slider. I think that idea is sufficiently complex
that it merits an own proposal, especially as I still don't see how we
can get it right. See bug 21034 for the …
[View More]context where at least one
example is shown that the security provided by the slider gets actually
worse with FPI. So, we seem to be in a situation that FPI both enhances
and decreases the security benefits promised by the slider depending on
the context and on users expectations which seems tricky to resolve.
Regarding the all-features-enabled-button idea Arthur had it seems to me
we should think about that one more as well, taking the different
blocked content into account and, above all, its different treatment by
NoScript: it is possible to enable/disable scripts right now by web site
while e.g. WebGL premissions are session-wide. Providing one button and
allowing to blow away big parts of the slider protections for the whole
session that way seems not like a thing we should do lightly. We might
want to make a distinction between JavaScript which is what users need
to have enabled most of the time to interact with a site and "active
content" and expose just two buttons for that for the time being. That's
what I propose in the proposal update while we think more about it. I
agree that we should not bother users with concepts like WebGL, Fonts,
SVG etc.
I've attached a diff to the original proposal for those following along
and not wanting to read the full one again in order to spot the updates.
Filename: XXX-redesign-security-controls.txt
Title: Redesign of Tor Browser's Security Controls
Author: Georg Koppen
Created: 6-March-2018
Status: Open
1 Introduction
Tor Browser is well-known for its defenses against web tracking and
fingerprinting. However, providing Tor users just a privacy-enhanced
browser is often not enough to safeguard against deanonymization
attacks as those protections might simply get bypassed by exploiting
browser vulnerabilities. Tor Browser therefore offers several security
enhancements as well to reduce that risk. Most of those features are
provided by extensions which Tor Browser includes, namely Torbutton,
NoScript, and HTTPS Everywhere.
1.1 Motivation
By default Torbutton, NoScript, and HTTPS Everywhere are visible on
the toolbar in Tor Browser and there is no hint about possible
security enhancements, with the exception of a notification bar shown
on first start and pointing to our security slider. This has a number
of suboptimal outcomes which this proposal seeks to address:
a) Security controls are scattered over and within different
extensions. That makes it hard to understand which knobs a user
could turn to improve their security settings while not being
exposed to additional fingerprinting risks.
b) The toolbar gets cluttered with three additional icons that provide
access to both per-site and global security settings. This is
confusing to users. Part of the confusion stems from mixing
non-global with global security controls on the toolbar not
indicating which of them just affect a particular website while
others affect the whole browser session. Another part is that users
feel the need to navigate through different levels of extension
menus to make basic adjustments to their security level.
c) There is the security vs. usability trade-off and little incentives
to change the default which comes with Tor Browser. That results in
users just staying on the lowest security level while at least some
of them could get convinced to raise that level if we managed to
provide an improved experience around our security controls, both
functionality- and UX-wise.
1.2 The State of the Security Controls
That is how the toolbar in Tor Browser looks like currently:
----------------------------------------------------------------------
| --- --- ------------------------- --------------- --- --- |
| |N| |T| | URL bar | | Search bar | |H| |M| |
| --- --- ------------------------- --------------- --- --- |
----------------------------------------------------------------------
N = NoScript button
T = Torbutton button
H = HTTPS Everywhere button
M = (Hamburger) Menu button
We include HTTPS Everywhere to help against potential Tor Exit node
eavesdroppers and active attackers. To provide users with optional
defense-in-depth against JavaScript and other potential exploit
vectors, we use NoScript modifying some of its defaults[1]. Torbutton
includes the security slider which is meant to give users an easy way
to adjust their security level from Standard to Safest, depending on
their perceived needs.
2 Proposal
Generally, items on the toolbar serve two important purposes: they are
shortcuts to features often used and they inform about current state.
With that in mind we can think about redoing our toolbar helping that
way with issues outlined in 1.1 a) and b). The remaining problems
(part of 1.1 b) and 1.1 c)) will be addressed in section 2.2, 3.3, and
follow-up proposals.
2.1 Restructuring the Toolbar
2.1.1 Removing HTTPS Everywhere and NoScript from the Toolbar
I'd propose we remove both NoScript and HTTPS Everywhere from the
toolbar and leave Torbutton on it for now:
Torbutton serves a number of purposes and access to security settings
is just one of them. Moreover, we are in the process of restructuring
at least part of its functionality right now[2] and more will likely
happen in the future in this area. We can think about whether
Torbutton should remain on the toolbar after that transition is done.
HTTPS Everywhere has the option to block all unencrypted requests and
apart from that is just enforcing HTTPS connections according to the
rulesets it ships, which is our default. There is not much gain
security-wise leaving it on the toolbar and users might just be
confused by the "Block all unencrypted requests" option. I'd argue as
well that the status indicator is not important enough to justify
precious space on the toolbar either.
NoScript comes with a myriad of configuration options. We try to
abstract that away by shipping a list of defaults for Tor Browser[1].
But still having NoScript easily accessible makes it dangerous to
choose the wrong option, especially as the majority of its
functionality does not need to be exposed for Tor Browser users.
Moreover, the scary warning icon which is visible when NoScript
allows JavaScript is highly confusing to users as we ship this
configuration as our default. Removing the icon from the toolbar
should solve those two problems. We might want to think about exposing
the small amount of functionality which especially users with the
security slider set to "Safest" might need: managing finer-grained
script control. See section 2.2 for that.
2.1.2 Adding a Security Settings Button to the Toolbar
I'd like to propose a new button on the toolbar giving easy access to
what is essentially the tool that we want to promote: the security
slider. We could use an icon similar to the one suggested by
ninavizz[3] or come up with a different solution. The button would
open the security slider menu with a right-click. With a left-click,
keyboard shortcuts, and mouse-wheel scrolling one can adjust the
security level directly.
However, easily adjusting the slider settings just for a single tab
is risky as it affects all the other tabs and windows in the session
as well. We should therefore at least warn the users about the
possible danger and provide the option to acquire a New Identity right
after changing the security slider level.
The new toolbar would look like:
----------------------------------------------------------------------
| --- --- ------------------------------- --------------- --- |
| |T| |S| | URL bar | | Search bar | |M| |
| --- --- ------------------------------- --------------- --- |
----------------------------------------------------------------------
T = Torbutton button
S = Security Settings button
M = (Hamburger) Menu button
Note: The reorganized toolbar has the additional benefit that no
per-site state is shown anymore on it, which should lead to less
confusion about whether the settings visible there apply globally or
not.
2.2 Dealing with Per-Site Security Settings
There are a number of features disabled on higher security settings as
they are potentially dangerous, yet sometimes users need or want to
allow them anyway. So far, these options were exposed by click-to-play
buttons or directly in the NoScript user interface accessible over the
toolbar button.
With NoScript gone from the toolbar the click-to-play options remain,
but easily allowing JavaScript per site and making the status of
NoScript related settings visible is not available anymore. To solve
this I'd propose to follow the path we are currently taking with our
circuit display redesign[2]: we are moving site specific settings into
the URL bar.
One way to do that would be to use the Permissions section which opens
after clicking on the "i" icon in the URL bar. However, while showing
the security permissions the user has granted there (too) is a good
idea, it does not solve the problem of easily allowing e.g. JavaScript
on a website, and seeing its status without the need to click on any
button. We could have small icons on the right side of the URL bar
accomplishing that, though. That way, users could easily see if they
had JavaScript, or WebGL, or ... enabled on that particular website in
case they are on higher security levels. Moreover, they would be able
to adjust those permissions quickly without the need to deal with any
NoScript user interface or additional menus just by toggling those
icons.
By default only the option to temporarily allow JavaScript would be
visible. All the click-to-play features could show up once there is a
respective object embedded on a website. We should refrain from
exposing icons for every single "active content" in the URL bar,
though. Rather, besides the button for temporarily allowing JavaScript
we would only add one additionally, which is responsible for
manipulating and showing the state of "active content" (like WebGL,
SVG, fonts etc.).
3 Additional Considerations
3.1 Where Are My Extensions Gone?
Some users might be confused and think NoScript and HTTPS Everywhere
are gone now, plus they want to have their "old" way of setting their
per-site settings back. That's okay and they can easily add NoScript
and HTTPS Everywhere back to their toolbar if they wish. It would be
good to point this out in the transition phase to the new interface at
least.
3.2 How Do We Inform Users about the New Interface?
I don't know yet how we ideally inform users about the new interface.
That is not part of this proposal but might merit an own one.
3.3 Should We Change the Default Security Level?
As much as I wished to change the default security level, to e.g.
"Safer", right now I think we are not there yet. Part of the security
control redesign should be fixing bugs that make the current and new
interface less effective and painful to use[4][5][6][7]. We could
revisit that discussion, though, once we have solved the low hanging
bugs.
[1]
https://gitweb.torproject.org/builders/tor-browser-build.git/tree/projects/…
[2] https://trac.torproject.org/projects/tor/ticket/24309
[3] https://trac.torproject.org/projects/tor/ticket/21183
[4] https://trac.torproject.org/projects/tor/ticket/22981
[5] https://trac.torproject.org/projects/tor/ticket/22985
[6] https://trac.torproject.org/projects/tor/ticket/20314
[7] https://trac.torproject.org/projects/tor/ticket/21805
Georg
[View Less]