Radical proposal of the day: Can we use the Firefox major version number in the Tor Browser version? This would mean that TBB versions would be 24.0, 24.1, 24.1.1, etc.
Why consider making this change? Because doing so would allow us to greatly simplify the patches needed for bug #4234 (Use Firefox updater).
For the Firefox updater to work correctly, it needs to be able to check the version of an advertised update against the version of the software that is currently installed. At the same time, for add-on compatibility the browser version itself must be close to that of the Firefox release it is based on.
We already have patches for #4234 that modify our Firefox build process to pass the TBB version through and use it inside all of the updater-related code (and to use the 24.x Firefox version when we need to do so). However, the patches are messy and I don't think Mozilla could ever accept them; Mozilla has no need for a bundle version that is separate from the Firefox version.
If we used a version number for TBB that was close to the Firefox version number, we would not need to patch anything; we would just use our version number as THE version number. Doing this would also allow us to eliminate the torbrowser.version hidden preference. And it might help end-users who want to figure out what version of Firefox the Tor Browser is based on.
Hi,
Mark Smith:
We already have patches for #4234 that modify our Firefox build process to pass the TBB version through and use it inside all of the updater-related code (and to use the 24.x Firefox version when we need to do so). However, the patches are messy and I don't think Mozilla could ever accept them; Mozilla has no need for a bundle version that is separate from the Firefox version.
while that is true, would Mozilla have a need to modify its Firefox updater at all and should it? I mean, we only patch the updater as not all our other Tor Browser patches are merged upstream yet. So, I expect Mozilla to say: "Look, neither you nor we need that modified updater as it only exists due to all your other fixes not being upstreamed. Let's fix the latter then." And this position is quite reasonable IMO. Especially as they have to deal with the Tor Project related updater code if there is some time in the future where all our patches are indeed merged upstream (Granted, that will still take quite some time :).). Or do/did you implement some hardening features that Mozilla might be interested in taking? That might change the game...
If we used a version number for TBB that was close to the Firefox version number, we would not need to patch anything; we would just use our version number as THE version number. Doing this would also allow us to eliminate the torbrowser.version hidden preference. And it might help end-users who want to figure out what version of Firefox the Tor Browser is based on.
Sounds good to me for the reasons you gave in the last paragraph. So, yes, I am happy to take the Firefox ESR versions as our Tor Browser versions. We might want to fix that while we are switching away from "Tor Browser Bundle" to "Tor Browser" (which is #11193) (although in a new ticket).
Georg
On 3/24/14, 8:49 AM, Georg Koppen wrote:
while that is true, would Mozilla have a need to modify its Firefox updater at all and should it? I mean, we only patch the updater as not all our other Tor Browser patches are merged upstream yet. So, I expect Mozilla to say: "Look, neither you nor we need that modified updater as it only exists due to all your other fixes not being upstreamed. Let's fix the latter then." And this position is quite reasonable IMO. Especially as they have to deal with the Tor Project related updater code if there is some time in the future where all our patches are indeed merged upstream (Granted, that will still take quite some time :).).
Are you saying that if/when all of our Firefox patches have been merged upstream, we can just ship Firefox as part of TBB? That may be true, but if we plan to continue to ship a bundle that includes tor, the PTs, etc. then we will still need a way to update the entire bundle.
Or do/did you implement some hardening features that Mozilla might be interested in taking? That might change the game...
We have not implemented any hardening features yet but Mozilla might take the hardening features but still not want to take version-related patches.
Mark Smith:
On 3/24/14, 8:49 AM, Georg Koppen wrote:
while that is true, would Mozilla have a need to modify its Firefox updater at all and should it? I mean, we only patch the updater as not all our other Tor Browser patches are merged upstream yet. So, I expect Mozilla to say: "Look, neither you nor we need that modified updater as it only exists due to all your other fixes not being upstreamed. Let's fix the latter then." And this position is quite reasonable IMO. Especially as they have to deal with the Tor Project related updater code if there is some time in the future where all our patches are indeed merged upstream (Granted, that will still take quite some time :).).
Are you saying that if/when all of our Firefox patches have been merged upstream, we can just ship Firefox as part of TBB? That may be true,
Or just ship tor and related stuff as it has been before the decision was made to manage an own browser.
but if we plan to continue to ship a bundle that includes tor, the PTs, etc. then we will still need a way to update the entire bundle.
That is true. But there would be other options if that would actually be needed then (like Thandy).
Don't get me wrong, if Mozilla is taking our patches we should definitely go for it. And if making them as simple as possible helps, even better. I just wanted to point out that relying on the Mozilla argument seemed not particularly strong to me as not getting the updater patch merged is not as important compared to the other patches we have (from a privacy/anon perspective): We could deploy a vanilla Firefox without the updater patch (and use e.g. Thandy or don't ship bundles with Firefox anymore) but not without one of the privacy/anon related ones.
Georg
Mark Smith:
Radical proposal of the day: Can we use the Firefox major version number in the Tor Browser version? This would mean that TBB versions would be 24.0, 24.1, 24.1.1, etc.
How would you support what is currently out there: Tor Browser 3.5.3 as the stable branch and Tor Browser 3.6-beta-1 as the beta branch? Both are based on 24.4.0esr.
On 3/24/14, 8:59 AM, Lunar wrote:
Mark Smith:
Radical proposal of the day: Can we use the Firefox major version number in the Tor Browser version? This would mean that TBB versions would be 24.0, 24.1, 24.1.1, etc.
How would you support what is currently out there: Tor Browser 3.5.3 as the stable branch and Tor Browser 3.6-beta-1 as the beta branch? Both are based on 24.4.0esr.
This is a good question.
We do not need to exactly match the Firefox version numbers; I think just using the major revision number in our TBB version numbers would be sufficient for us to avoid the need to patch Firefox's updater code. But we would need to come up with a way to partition the version number space, e.g.,
Stable: 24.0, 24.0.1, 24.0.2, ... Beta: 24.1b1, 24.1b2, 24.1b3, ...
The problem with this is that it will be confusing to have a 24.1b1 Tor Browser that is based on Firefox 24.4.0esr. The only thing people could assume is that the first portion of the Tor Browser number matches the first portion of the Firefox version. But they might tend to assume more of a relationship since our version numbers would so closely resemble Firefox's.
I am not sure how many people look closely at version numbers though. Most people just care that a higher version number implies newer software.
Mark Smith:
On 3/24/14, 8:59 AM, Lunar wrote:
Mark Smith:
Radical proposal of the day: Can we use the Firefox major version number in the Tor Browser version? This would mean that TBB versions would be 24.0, 24.1, 24.1.1, etc.
How would you support what is currently out there: Tor Browser 3.5.3 as the stable branch and Tor Browser 3.6-beta-1 as the beta branch? Both are based on 24.4.0esr.
This is a good question.
We do not need to exactly match the Firefox version numbers; I think just using the major revision number in our TBB version numbers would be sufficient for us to avoid the need to patch Firefox's updater code. But we would need to come up with a way to partition the version number space, e.g.,
Stable: 24.0, 24.0.1, 24.0.2, ... Beta: 24.1b1, 24.1b2, 24.1b3, ...
The problem with this is that it will be confusing to have a 24.1b1 Tor Browser that is based on Firefox 24.4.0esr. The only thing people could assume is that the first portion of the Tor Browser number matches the first portion of the Firefox version. But they might tend to assume more of a relationship since our version numbers would so closely resemble Firefox's.
I am not sure how many people look closely at version numbers though. Most people just care that a higher version number implies newer software.
Is there a reason why we need to use their exact version numbers? What if we just formatted and stored existing TBB versions in the same way that Firefox does?
We would need version update patches for each TBB release to get applied to the corresponding tor-browser.git branch/tag we use, but that isn't terribly hard.
As for changes to the updater that Mozilla would want: We do want to do some analysis and work to harden the updater against the attacks enumerated by the TUF/Thandy literature. Mozilla has done some of this work, but we probably will want to make some more changes. Making our Tor Browser specific changes as minimal as possible will make this easier.
On 3/24/14, 4:10 PM, Mike Perry wrote:
Is there a reason why we need to use their exact version numbers? What if we just formatted and stored existing TBB versions in the same way that Firefox does?
One issue is extension compatibility, e.g., if an extension is marked as requiring Firefox 24 or newer, then the browser will refuse to load the extension if we change the core browser version to 4.0.
Based on this discussion, we are going to keep the idea of a separate Tor Browser version for now. The patches are small (many "one liners") so they should not be too difficult to maintain/reapply as Mozilla makes changes to the code. We can revisit this later if we decide that the benefit outweighs the effort.
-
Georg Koppen -
Lunar -
Mark Smith -
Mike Perry