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