[tor-project] Tor Browser Vision Brainstorm

Pili Guerra pili at torproject.org
Tue Mar 12 11:36:47 UTC 2019


Hi everyone,

Better late than never, here's the recap from the second part of Browser vision exercise that we run at the start of March.

I would like to organise the points discussed during these sessions and also on the email thread into the three areas outlined by Isabela in her email:

Anti Censorship / Surveillance / Tracking
Smarter bootstrapping
What’s next for tor launcher?
Incorporate OONI data to help user make informed configuration decisions
Automate configuration decisions whilst keeping users safe

Better tracking and fingerprinting resistance
Letterboxing
Canvas-like software rendering (is this the same as window dimension spoofing below?)

Incremental redirect protection

User Experience - some of these touch on some of the other areas too
UI polish + product cohesion
Action: Let’s make a list of UI “smells”

User Journey mapping
Warnings and notifications
New identity review

Config automation
Smarter bootstrapping (see above)
Opt-in Persistence to Disk
Browser History retention (aka ability to turn off Private Browsing Mode)
Encrypted bookmarks

Running Tor Browser Maximised
By ensuring users understand the risks and/or implications of maximising Tor Browser window -> Warnings and Notifications work
By including fingerprinting protections:
Through letterboxing
Through spoofing window dimensions without letterboxing

New Features/Innovation
Sandboxing analysis/planning
Tor Browser Ephemeral sessions <- Antonela to explain further :)
User safety work
Protect against malicious exit nodes
Block executable downloads over HTTP
Let users block HTTP connections
Don't let users bypass self-signed cert warning unless self-signed cert is independently “verified"
Detecting when bitcoin addresses are copied on an insecure page

Enabling Safe Browsing

I have added another category to take into account work that needs to be done but does not really fit into any wider project:

Maintenance
ESR Releases
Security Bug fixes
Switch to mingw-clang
Assess new fingerprinting vectors in ESR52, ESR60 (and ESR68)

Finally, here are some "Big Picture" discussions that we might want to have during our dev-meeting:
Working with other organizations to ship a Tor mode/private browser mode
Apple/Safari, Chromium, Opera
Working with product people at these organisations
Looking to help them introduce tor in the background, e.g for telemetry, updates pings, etc…
promoting change within the whole ecosystem
advocating for feature parity with Tor Browser

Working with web standards bodies and/or legislators
Initiate a cross-browser working group to create standards for browser privacy.
Evangelising to web service providers
how to avoid broken usability for Tor Browser users
being profitable without the need for “creepy” tracking

One thing we did not really talk about though are what are the principles we should have in mind when designing and implementing new features? Here's a few I took from our emails and discussions on this topic to get us started:
User first
Secure by default
Providing the best anonymity/privacy tool for users
This is my interpretation of what has been discussed so far, so please correct me if I’ve made any incorrect statements/assumptions and add your own thoughts. If there is something I missed out, it does not mean I do not think it’s important :) there was a lot discussed and I’m sure I’ve forgotten many details. Please share them again if that’s the case!

Thank you so much to everyone that participated and shared their ideas!

Pili
—
Project Manager: Tor Browser, UX and Community teams
pili at torproject dot org
gpg 3E7F A89E 2459 B6CC A62F 56B8 C6CB 772E F096 9C45

> On Monday, Feb 11, 2019 at 12:47 PM, Pili Guerra <pili at torproject.org (mailto:pili at torproject.org)> wrote:
> Hi everyone,
>
> We had a very good meeting to start scoping out the Tor Browser vision for the near future on Friday and I just wanted to recap what was discussed and open it up for wider discussion here for those that wanted, but were unable, to join.
>
> The starting point for the discussion was: "Why do we need Tor Browser?"
>
> It was agreed that there is currently a need for a browser to protect users from tracking, surveillance and censorship as well as making tor more accessible for users. However, currently the Tor Project is not a browser vendor and Tor Browser is still in some ways just a prototype for how to do truly private browsing, at the expense of usability and features. Moving forward, it's not clear whether we should try to become a first-class browser, or help others in the actual browser business to take up the challenge to create a truly secure and private browser that meets the Tor Project's privacy standards and that we can fully endorse.
>
> Does the Tor Project need to become a browser vendor? If so, what would it take for Tor Browser to become a user's main browser as opposed to one that is only used for specific tasks?
>
> If not, what does this mean for Tor Browser in future? Should it continue serving *just* as a prototype for how to put user's privacy first? Do we want to let other browser vendors take up this task and instead create tools that measure the privacy standards of different browsers?
>
> Working on the premise that we do want to become the main browser for a significant percentage of users, what is it that we need to do in order to achieve this? Do we want to make a compromise by slightly reducing privacy in order to improve usability and add more features? Or should we keep on investing in privacy features as a priority?
>
> Further to that, if we did get more users as a result of usability improvements and at the cost of slightly reduced privacy, would the increased aggregate privacy of a larger user base make up for this slight reduction in privacy?
>
> What about users who have no choice but to use Tor Browser? How can we justify any compromise for them?
>
> As you can see from all these questions, there is plenty for us to figure out still and we found out that this was not the sort of discussion we could hash out in just one session. As such, we'll be announcing a follow up session in a couple of weeks time.
>
> You can find the full meeting logs for this first session here[1].
>
> Thanks!
>
> Pili
>
> [1] http://meetbot.debian.net/tor-meeting/2019/tor-meeting.2019-02-08-19.59.log.html
>
>> Project Manager: Tor Browser, UX and Community teams
> pili at torproject dot org
> gpg 3E7F A89E 2459 B6CC A62F 56B8 C6CB 772E F096 9C45
>
>
> > On Thursday, Feb 07, 2019 at 10:17 AM, Pili Guerra <pili at torproject.org (mailto:pili at torproject.org)> wrote:
> > Hi everyone,
> >
> > We’ll be holding a brainstorming session this Friday 8th February @ 20:00 UTC over on #tor-meeting to discuss our joint vision for the Tor Browser in the near future.
> >
> > Please join us! We would love to hear your views.
> >
> > Thanks!
> >
> > Pili
> >
> > —
> > Project Manager: Tor Browser, UX and Community teams
> > pili at torproject dot org
> > gpg 3E7F A89E 2459 B6CC A62F 56B8 C6CB 772E F096 9C45
> >
> >
> > _______________________________________________
> > tor-project mailing list
> > tor-project at lists.torproject.org
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
> _______________________________________________
> tor-project mailing list
> tor-project at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-project/attachments/20190312/7bf81152/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-project/attachments/20190312/7bf81152/attachment.sig>


More information about the tor-project mailing list