Unverified Commit 6becf9c0 authored by Georg Koppen's avatar Georg Koppen
Browse files

Starting Tor Browser proposals

parent 1f99fbdb
......@@ -75,7 +75,7 @@ Direct paths to DNS resolution:
+ nsDNSService::AsyncResolve
+ Patched for safety
+ nsHostResolver::ResolveHost
+ Only used by nsDNSService
+ Only used by nsDNSService2
Misc UDP (SOCK_DGRAM, PR_DESC_SOCKET_UDP):
+ PR_DESC_SOCKET_UDP
......
Filename: 001-process.txt
Title: The Tor Browser Proposal Process
Author: Georg Koppen
Created: 21-Sep-2018
Status: Meta
Overview:
This document describes how Tor Browser proposals work. It heavily borrowed
and copied from the Tor proposal process.
This is an informational document.
Motivation:
Previously, our process for implementing complex features possibly including
the expertise of different teams consisted of discussions on IRC, our bug
tracker, and at informal sessions at our developer meetings. While this worked
more or less it's hard to keep track of the status of various ideas and it
makes it more difficult to reason about their pros and cons. Tor Browser
proposals should help address those issues and aid in deciding which ideas to
implement and how, and which not.
How new proposals get added:
Once an idea has been proposed on the tbb-dev (or if relevant: the tor-dev)
development list, a properly formatted (see below) draft exists, and rough
consensus within the active development community exists that this idea
warrants consideration, the proposal editors will officially add the proposal.
To get your proposal in, send it to the tbb-dev mailing list.
The current proposal editors are Georg Koppen.
What should go in a proposal:
Every proposal should have a header containing these fields:
Filename, Title, Author, Created, Status, Ticket.
These fields are optional but recommended:
Target, Implemented-In.
The Target field should describe which version the proposal is hoped to be
implemented in (if it's Open or Accepted). The Implemented-In field should
describe which version the proposal was implemented in (if it's Finished or
Closed). The Ticket field should be a ticket number referring to Tor's
canonical bug tracker (e.g. "#21952" refers to
https://bugs.torproject.org/21952) or to a publicly accessible URI where one
may subscribe to updates and/or retrieve information on implementation
status.
The body of the proposal should start with an Overview section explaining
what the proposal's about, what it does, and about what state it's in.
After the Overview, the proposal becomes more free-form. Depending on its
length and complexity, the proposal can break into sections as appropriate,
or follow a short discursive format. Every proposal should contain at least
the following information before it is "ACCEPTED", though the information
does not need to be in sections with these names.
Motivation: What problem is the proposal trying to solve? Why does this
problem matter? If several approaches are possible, why take this one?
Design: A high-level view of what the new or modified features are, how the
new or modified features work, how they interoperate with each other, and
how they interact with the rest of Tor Browser. This is the main body of
the proposal.
Proposal status:
Open: A proposal under discussion.
Accepted: The proposal is complete, and we intend to implement it. After this
point, substantive changes to the proposal should be avoided, and regarded
as a sign of the process having failed somewhere.
Finished: The proposal has been accepted and implemented. After this point,
the proposal should not be changed.
Rejected: We're not going to implement the feature as described here, though
we might do some other version. See comments in the document for details.
The proposal should not be changed after this point; to bring up some other
version of the idea, write a new proposal.
Draft: This isn't a complete proposal yet; there are definite missing pieces.
Please don't add any new proposals with this status; put them in the "ideas"
sub-directory instead.
Needs-Revision: The idea for the proposal is a good one, but the proposal as
it stands has serious problems that keep it from being accepted. See
comments in the document for details.
Dead: The proposal hasn't been touched in a long time, and it doesn't look
like anybody is going to complete it soon. It can become "Open" again if it
gets a new proponent.
Needs-Research: There are research problems that need to be solved before it's
clear whether the proposal is a good idea.
Meta: This is not a proposal, but a document about proposals.
Reserve: This proposal is not something we're currently planning to
implement, but we might want to resurrect it some day if we decide to do
something like what it proposes.
Informational: This proposal is the last word on what it's doing.
It isn't going to turn into a spec unless somebody copy-and-pastes it into
a new spec for a new subsystem.
Obsolete: This proposal was flawed and has been superseded by another
proposal. See comments in the document for details.
The editors maintain the correct status of proposals, based on rough
consensus and their own discretion.
Proposal numbering:
Numbers 000-099 are reserved for special and meta-proposals. 100 and up
are used for actual proposals. Numbers aren't recycled.
Filename: 100-onion-location-header.txt
Title: Onion redirects using Onion-Location HTTP header
Author: George Kadianakis
Created: 02-02-2018
Status: Open
Ticket: #21952
1. Motivation:
Lots of high-profile websites have onion addresses these days (e.g. Tor,
NYT, blockchain, ProPublica). All those websites seem confused on what's
the right way to inform their users about their onion addresses. Here are
some confusion examples:
a) torproject.org does not even advertise their onion address to Tor users (!!!)
b) blockchain.info throws an ugly ASCII page to Tor users mentioning their onion
address and completely wrecking the UX (loses URL params, etc.)
c) ProPublica has a "Browse via Tor" section which redirects to the onion site.
Ideally there would be a consistent way for websites to inform their users
about their onion counterpart. This would provide the following positives:
+ Tor users would use onions more often. That's important for user
education and user perception, and also to partially dispell the darkweb myth.
+ Website operators wouldn't have to come up with ad-hoc ways to advertise
their onion services, which sometimes results in complete breakage of
the user experience (particularly with blockchain)
This proposal specifies a simple way forward here that's far from perfect,
but can still provide benefits and also improve user-education around onions
so that in the future we could employ more advanced techniques.
Also see Tor ticket #21952 for more discussion on this:
https://trac.torproject.org/projects/tor/ticket/21952
2. Proposal
2.1. Redirection method
We introduce a new HTTP header called "Onion-Location" with the exact same
restrictions and semantics as the Location HTTP header. Websites can use the
Onion-Location HTTP header to specify their onion counterpart, in the same
way that they would use the Location header.
Example:
Onion-Location: http://vwc43ag5jyewlfgf.onion
2.2. Browser logic
The Tor Browser intercepts the Onion-Location HTTP header (if any) and
informs the user of the existence of the onion site, giving them the option
to visit it. Tor Browser only does so if the header is served over HTTPS.
Tor Browser should inform the user about the onion in a non-intrusive way
(e.g. an infobar below the address bar), it should also provide a way for
the user to visit the onion, and a button that offers more information about
onions.
Browsers that don't support Tor SHOULD ignore the Onion-Location header.
3. Drawbacks
3.1. No security/performance benefits
While we could come up with onion redirection proposals that provide
security and performance benefits, this proposal does not actually provide
any of those.
As a matter of fact, the security remains the same as connecting to normal
websites, since for this proposal to work we need to trust their HTTP headers,
and the user might have already provided identifying information
(e.g. cookies) to the website. The performance is worse than connecting to a
normal website, since Tor first needs to connect to the website, get its
headers, and then finally connect to the onion.
Still _all_ the website approaches mentioned in the "Motivation" section
suffer from the above drawbacks, and sysadmins still come up with ad-hoc
ways to inform users about their onions. So this simple proposal will still
help those websites and also pave the way forward for future auto-redirect
techniques.
3.2. Defining new HTTP headers is not the best idea
This proposal defines a new non-standard HTTP header. This is not great
because it makes Tor into a "special" thing that needs to be supported with
special headers. However, the fact that it's a new HTTP header that only
works for Tor is a positive thing since it means that non-Tor browsers will
just ignore it.
Furthermore, another drawback is that this HTTP header will increase the
bandwidth needlessly if it's also served to non-Tor clients. Hence websites
with lots of client traffic are encouraged to use tools that detect Tor
users and only serve the header to them (e.g. tordnsel). Website operators
should be aware that tools like tordnsel have false positive potential (they
might treat Tor users as non-Tor users) which will result in not sending
them the Onion-Location header.
Finally, websites can also detect Tor users (as discussed in the above
paragraph) and redirect them using the Location header, thus triggering a
non-prompting redirect. Websites doing so should consider the potential user
confusion of being redirected to an odd-looking domain. The Onion-Location
mechanism offered in this proposal is designed to provide a
browser-supported option to consistently offer an onion service in a
hopefuly less-confusing way.
4. The future
As previously discussed, this is just a simple proposal to introduce the
redirection concept to people, and also to help some sysadmins who are
currently coming up with weird ways to inform people about their
onions. It's not the best way to do this, but it's definitely one of the
simplest ways.
In the future we could implement more advanced auto-redirect proposals like:
a) Have a "domains to onions" map into HTTPS-everywhere and have the
extension do the autoredirects for us (performance benefits, and security
benefits under many threat models).
b) Bake onion addresses into SSL certificates and Let's Encrypt as suggested
by comment:42 in #21952.
But both of the designs above require non-trivial engineering/policy work
and would still confuse people. So I think starting with a simple approach
that will educate users and then moving to more advanced designs is a more
normative way to go.
Filename: 101-security-controls-redesign.txt
Title: Redesign of Tor Browser's Security Controls
Author: Georg Koppen
Created: 5-Apr-2018
Status: Open
Ticket: #25658
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 Showing Security Slider State
We essentially have one tool we want to promote to deal with security
settings: the security slider. Keeping in mind that icons on the
toolbar serve as well the purpose of showing state of important
settings, we could think about providing an own toolbar button for the
security slider. We could use an icon similar to the one suggested by
ninavizz[3] or come up with a different solution.
However, being able to easily adjust the slider level is risky as it
affects all the tabs and windows in a session. It might lead to
confusion as to whether the settings are applied globally or just for
a tab in question, which is error-prone. To mitigate that problem we
could at least warn users about the possible danger and provide the
option to acquire a New Identity right after changing the security
slider level. Doing so is a good idea anyway, but might not be enough
to justify exposing security slider functionality on the toolbar.
We'll add a security settings button to the toolbar which shows the
current slider state but, once clicked on, opens an about:preferences
pane in a new tab which contains the security slider. That way we
make the current slider state easily visible while avoiding the risk
of accidentally changing it. Moreover, having it as an option on
Firefox's preferences pane reinforces the idea of slider settings
being applied to the whole session and not just to a particular tab or
window.
2.1.3 Reorganizing the Toolbar
Taking the preceding chapters into account this leaves us with two
toolbar buttons for the Tor Browser toolbar: the one from the
Torbutton extension and the button for the security settings.
Following the toolbar layout of Firefox we should move both buttons to
the right, between the search bar and the menu button.
Now, the new toolbar would look like:
----------------------------------------------------------------------
| -------------------------------- -------------- --- --- --- |
| | URL bar | | Search bar | |T| |S| |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/tor-browser/Bundle-Data/linux/Data/Browser/profile.default/preferences/extension-overrides.js
[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
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment