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
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....
— 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@torproject.org (mailto:pili@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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
Hi there,
I really liked the discussion last Friday, thanks for organizing it! I wanted to share some thoughts I have in relationship to being User First or not.
It got me by surprise that folks did not thought we are already User First. I think by the time we are investing so much on learning about our users and applying improvements that focus on making their experience better we are being User First.
Getting a full dedicated team (UX) just to support this development process, all the 8.0 work and getting ourselves to mobile to reach more users are things we are doing because we are prioritizing our user.
At the discussion I saw folks had questions regarding the direction we should be thinking, becoming a full browser or keeping doing what we are doing. And to do what we are doing might not include things that are on Arthur's doc. Also, how we deal with other browsers trying to provide a private experience with Tor network, like we do.
This is how I see it. First, I don't think we (the Tor Project) are in the business of competing in the Browser market. We are in the business of providing anonymity and privacy technologies, and that is what we are doing.
We should own this, use our Tor Browser to show how the experience can be for all different types of use cases with anonymity and privacy as the main drivers for this experience.
I know there has been (and will always be) discussions on how we should build a feature, stuff like what settings should be pre-configured or not. And that is normal, we are building experience for a diverse user base. Some people will need all security features we can provide, and some will want a subset of it. At the end of the day, our mission should be to provide users choices for customizing their experience. Retention comes from one being able to control their experience.
We should allow this control to our users. And of course, should make sure we are providing education for them to make such decisions.
What is on Arthur's doc does not make us less or more user first. It's part of an organic process we are going through as we invest more and more on our users. So, this got me thinking, the question here is not should we be 'user first' or not. We are already. The question here is: what are the principles that will guide us while making the decisions on our product?
For instance, I think that one of our principles is that if we can provide a secure way of doing something, that should exist for our user by default. Be that something like the backend fix for the window resizing suggestion from Arthur doc, or an 'opted-in' configuration that allows our user to save their browser history.
So my suggestion here is for us to brainstorm our principles. Review Tor mission but also think of the TB as a team mission on what y'all are building.
cheers, isabela
ps1: regarding how we deal with other browsers adopting tor - we should do our best to influence them to adopt all our standards for security and privacy but as well as the experience we are shaping. If we are successful with that then we will have different problems to think about :) which should not influence this vision exercise because I don't think that will happen in the next 2 years or so. which is the timeframe this exercise is focusing on.
ps2: Arthur's doc: https://docs.google.com/document/d/1AN4RsNhZW7uqfjDQBAvw3kLFymFBBaDU6lh4YvEz...
On Mon, 11 Feb 2019 at 13:54, isabela isabela@torproject.org wrote:
It got me by surprise that folks did not thought we are already User First. I think by the time we are investing so much on learning about our users and applying improvements that focus on making their experience better we are being User First.
I might be one of the people you're referring to - but I don't think we're not being User First. I think that there is a difference between User First and targeting Tor Browser as being a user's primary browser. I think we're doing the first and not doing the second.
This is how I see it. First, I don't think we (the Tor Project) are in the business of competing in the Browser market. We are in the business of providing anonymity and privacy technologies, and that is what we are doing.
To be clear: I am not solidly behind the idea of Tor Browser becoming a full-fledged browser. I'm probably against it; but I'll also probably never decide on a position concretely. =) But I can see the advantages of it (and disadvantages) and to play devil's advocate I would suggest that *competing* in the browser market is different from *being in* the browser market.
Competing implies trying to win users, actively. But choosing to exist in the browser market - choosing to lean into the goal of supporting Tor Browser as a primary browser - would bring privacy and anonymity to *more of* a user's activity online, if not more users themselves. If people flock to us because of our success, fantastic. But we don't have to try to convince people the way other browsers 'compete'.
For instance, I think that one of our principles is that if we can provide a secure way of doing something, that should exist for our user by default. Be that something like the backend fix for the window resizing suggestion from Arthur doc, or an 'opted-in' configuration that allows our user to save their browser history.
The opt-in-save-history goal would be example of something that would be necessary (IMO) to be a primary browser; but I won't assume your suggestion of doing so is with the intent to become a primary browser.
-tom
isabela:
[snip]
At the discussion I saw folks had questions regarding the direction we should be thinking, becoming a full browser or keeping doing what we are doing. And to do what we are doing might not include things that are on Arthur's doc. Also, how we deal with other browsers trying to provide a private experience with Tor network, like we do.
This is how I see it. First, I don't think we (the Tor Project) are in the business of competing in the Browser market. We are in the business of providing anonymity and privacy technologies, and that is what we are doing.
We should own this, use our Tor Browser to show how the experience can be for all different types of use cases with anonymity and privacy as the main drivers for this experience.
I know there has been (and will always be) discussions on how we should build a feature, stuff like what settings should be pre-configured or not. And that is normal, we are building experience for a diverse user base. Some people will need all security features we can provide, and some will want a subset of it. At the end of the day, our mission should be to provide users choices for customizing their experience. Retention comes from one being able to control their experience.
We should allow this control to our users. And of course, should make sure we are providing education for them to make such decisions.
Okay, so let's translate this a bit and get some points from a developer perspective into focus.
Let's ignore "browser vendor", "full-fledged" and "primary browser" etc. for a while. If I understand this correctly then the goal here is to provide the best anonymity/privacy tool for basically any use case we can find: the casual user that just wants to have some privacy to do X before switching back to Google's Chrome to do non-X-y things, the powser user that wants to only use Tor Browser in safest default settings with the best fingerprinting/tracking resistance they can get, and all sorts of use cases that lie within those two poles. And that basically on all platforms available (i.e. those a Firefox is running on) with as little breakage as possible.
This vision is interesting and definitely ambitious. :) There are some consequences of that which might be worth pondering:
1) It would mean we are de facto committing ourselves to delivering a browser as good as we can (no shortcuts when technically possible, no usecase reduction etc.), with a focus on anonymity/privacy protections for the years to come: not just 2, not even just 5 but very likely for a much longer period. That's because there will essentially always be
(a) things we can fix to improve the protections Tor Browser can provide, yet that other browsers can't enable because they are not focused on anonymity/privacy protections and have to balance a bunch of other goals we might not care about as much. For example, they might need to take performance and memory restrictions into acconut which are not so important for us compared to the protections we want to provide to our users. Part of those improved protections could probably be made available by prefs. However, I think it's not unreasonable to assume that a part of them will need to get compiled in, though.
(b) unsolved or not good-enough-solved possible fingerprinting and tracking issues which we need to take care.
(c) user experiences/websites that are broken due to our patches and the ways the web works which in turn requires workarounds and fixes on our side or evangelism to solve the problems on the server side.
2) While not really a paradigm change the proposal above considerably changes the *scope* of our work in the sense that we so far limited the browser functionality we actively supported, as Tor Browser was meant to be a reference implementation of a portable browser, focusing on a proper Private Browser Browsing mode (Note: that does *not* mean we did/do not try to do the User First thing. We actually did/do that as one can see in Tor Browser 8 UX improvements and in the more and more platforms we support etc.).
3) Even though we have 2), which means we are focusing on the browser as a whole now, and are providing a privacy/anonymity-enhanced alternative to everything on the browser market, I think there is no change in our relationship to Mozilla or the patch upstreaming we have done for a while now. It's still worthwhile to get our patches into Firefox for
(a) making it easier for us to maintain our patch set and (b) giving something back to Mozilla e.g. for Firefox users that would like to have Tor Browser's privacy protections but are not using Tor (but some other proxy solution etc.).
4) The widened scope due to 2) will make it necessary to think even more about our specific priorities in a particular situation, given that we are a pretty small team compared to the huge browser code we need to maintain and enhance.
All in all, it's not anything we can't manage but I think it's worth having the grander vision broken down a bit (as I hopefully did) as this helps thinking about all the various aspects that make up day-to-day browser work.
Georg
Hi Everyone,
Related to this thread: Georg asked what changes I think might be necessary for Tor Browser to become a "First Class Browser". FWIW I came up with some suggestions for Tor Browser strategy that I think would help with this goal: (1) Make increasing the number of users a top priority. (2) Continuously get feedback from users and non-users on Tor Browser's usability shortcomings. (3) Make usability improvements iteratively, based on that feedback.
Here is a link to my brief writeup: https://storm.torproject.org/shared/JtS2sFkUGsCLWbZaojqACeCG8XOSE4-YyZy50nGJ...
Interested to hear what you all think! :)
Thanks, Arthur
On Tue, Feb 26, 2019 at 1:11 PM Georg Koppen gk@torproject.org wrote:
isabela:
[snip]
At the discussion I saw folks had questions regarding the direction we should be thinking, becoming a full browser or keeping doing what we are doing. And to do what we are doing might not include things that are on Arthur's doc. Also, how we deal with other browsers trying to provide a private experience with Tor network, like we do.
This is how I see it. First, I don't think we (the Tor Project) are in the business of competing in the Browser market. We are in the business of providing anonymity and privacy technologies, and that is what we are doing.
We should own this, use our Tor Browser to show how the experience can be for all different types of use cases with anonymity and privacy as the main drivers for this experience.
I know there has been (and will always be) discussions on how we should build a feature, stuff like what settings should be pre-configured or not. And that is normal, we are building experience for a diverse user base. Some people will need all security features we can provide, and some will want a subset of it. At the end of the day, our mission should be to provide users choices for customizing their experience. Retention comes from one being able to control their experience.
We should allow this control to our users. And of course, should make sure we are providing education for them to make such decisions.
Okay, so let's translate this a bit and get some points from a developer perspective into focus.
Let's ignore "browser vendor", "full-fledged" and "primary browser" etc. for a while. If I understand this correctly then the goal here is to provide the best anonymity/privacy tool for basically any use case we can find: the casual user that just wants to have some privacy to do X before switching back to Google's Chrome to do non-X-y things, the powser user that wants to only use Tor Browser in safest default settings with the best fingerprinting/tracking resistance they can get, and all sorts of use cases that lie within those two poles. And that basically on all platforms available (i.e. those a Firefox is running on) with as little breakage as possible.
This vision is interesting and definitely ambitious. :) There are some consequences of that which might be worth pondering:
- It would mean we are de facto committing ourselves to delivering a
browser as good as we can (no shortcuts when technically possible, no usecase reduction etc.), with a focus on anonymity/privacy protections for the years to come: not just 2, not even just 5 but very likely for a much longer period. That's because there will essentially always be
(a) things we can fix to improve the protections Tor Browser can provide, yet that other browsers can't enable because they are not focused on anonymity/privacy protections and have to balance a bunch of other goals we might not care about as much. For example, they might need to take performance and memory restrictions into acconut which are not so important for us compared to the protections we want to provide to our users. Part of those improved protections could probably be made available by prefs. However, I think it's not unreasonable to assume that a part of them will need to get compiled in, though.
(b) unsolved or not good-enough-solved possible fingerprinting and tracking issues which we need to take care.
(c) user experiences/websites that are broken due to our patches and the ways the web works which in turn requires workarounds and fixes on our side or evangelism to solve the problems on the server side.
- While not really a paradigm change the proposal above considerably
changes the *scope* of our work in the sense that we so far limited the browser functionality we actively supported, as Tor Browser was meant to be a reference implementation of a portable browser, focusing on a proper Private Browser Browsing mode (Note: that does *not* mean we did/do not try to do the User First thing. We actually did/do that as one can see in Tor Browser 8 UX improvements and in the more and more platforms we support etc.).
- Even though we have 2), which means we are focusing on the browser as
a whole now, and are providing a privacy/anonymity-enhanced alternative to everything on the browser market, I think there is no change in our relationship to Mozilla or the patch upstreaming we have done for a while now. It's still worthwhile to get our patches into Firefox for
(a) making it easier for us to maintain our patch set and (b) giving something back to Mozilla e.g. for Firefox users that would like to have Tor Browser's privacy protections but are not using Tor (but some other proxy solution etc.).
- The widened scope due to 2) will make it necessary to think even more
about our specific priorities in a particular situation, given that we are a pretty small team compared to the huge browser code we need to maintain and enhance.
All in all, it's not anything we can't manage but I think it's worth having the grander vision broken down a bit (as I hopefully did) as this helps thinking about all the various aspects that make up day-to-day browser work.
Georg
tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
Hello everyone!
I wanted to share this email before the meeting - sorry that is still quite close to the meeting. And sorry if I am not answering the other comments, I will go back to them another time. But I just wanted to share the following thought.
I think that maybe we are having a discussion for a longer term vision than what Pili needs for the 'money machine' team. Our fundraising team needs to have a backlog of things tor teams wants to be doing in the near term (next 2 years) so they know what they could be applying if opportunities comes.
I feel that some topics raised so far are good for a f2f discussion at the Tor meeting because they might have a deeper effect on how we do things etc. So I am suggesting that maybe we organizing some time there to do so.
Giving the above ^^, I would like to share some thoughts of how we can focus the discussion on continuity of what is already in course.
Here is where I am coming from, in 2015 I shared this with tor-internal: https://docs.google.com/presentation/d/16GoPHkZDuECn-NkDyePiZAeyJ_E7Y41YW_3l...
If you look at that user strategy, we have put in place some of it already, but other parts are still being done, like the new website.
In 2017 I tried to organize an update on this strategy: https://docs.google.com/presentation/d/1a0Lwuj44mjtDqm28cSRKr2Udu2QVArLtGYcC...
Sorry, is not really finished. But what I am trying to show here is how long it can take to get the resources and put in place a strategy. I feel that we are right now with a good part of the resources that we needed back then, and maybe there is why we feel we might be changing how we do things. But in my head we are just now being able to start doing it like how it should be, with all the resources like design, ux, user feedback/research etc.
So! For the brainstorming Pili is asking for. I feel what would make sense is to look at what is in course and where we want to take it in the next 2 years.
But we also need to be realistic. The TB team is not only about building new features, it has to carry on other work like keeping up with ESR releases, fix security bugs etc.
I would like to suggest that we do some capacity calculation for the team, so we know for sure what much time the team has in the next 2 years for ux/new features stuff. (I think this time might be something like 8 to 10 months).
I think we have right now 3 tracks of work on the ux/new features:
1. anti-censorship track - tor launcher work, we have a proposal about it; we should look what we are doing there, and think of what next. Is extreme important that our users can connect to the network.
2. bring all the good practices of ux to tb track - bring TB to be up to date with 2019 :) a lot of what we did on TB 8.0 has to do with it, the proposal to review notifications to users, the educational moments we are creating etc. What else we need to be doing here?
3. new features / innovation track - for me the work we proposed for onion services is on this track. there are some ideas from Arthur doc which is on this track as well.
Track #3 is where we will need the most the 'principles' I mentioned that we should have to guide us on our feature decisions. So I would suggest that this team do create such list of principles.
Alright, this is what I am suggesting for us to focus on during today's brainstorming. Hopefully is helpful for y'all.
Cheers, isabela
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@torproject.org (mailto:pili@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....
— 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@torproject.org (mailto:pili@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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
tor-project@lists.torproject.org
-
Arthur D. Edelstein -
Georg Koppen -
isabela -
Pili Guerra -
Tom Ritter