Windows 7/8 and macOS 10.12-10.14 Legacy/Maintenance
Mozilla announced on Reddit that legacy Windows (7 through 8.1) support woulds be extended past the original planned end-date of September 2024. We don't yet know how long this support will extend for, but word through the grapevine suggests at least 6 months. It is still not determined if legacy macOS will also be getting security updates.
I made a post about the problems/tradeoffs of maintaining a legacy 13.5 release channel on the Tor Project forum:
Tor Browser Legacy 13.5 Release Channel post
We've been keeping an eye on the developments upstream regarding legacy Windows support. We don't have any details yet on what Mozilla's specific plans are, but we're guessing the most likely answer is that they will be maintaining the Firefox ESR-115 series going for Windows for some time past the original early September deprecation date. We don't know how long this support will last.
This solves the (Firefox-specific) security issues outlined above and in other posts. Hurray!
So what does this mean for Tor Browser hypothetically? To be clear, we have not evaluated yet whether this work fits into our existing roadmap, nor if it is worth the effort. This comes down to determining how much work is this going to be, will it get in the way of our existing work, and does it benefit enough users to justify the cost.
So here's a potential hand-wavy plan for a possible legacy Windows support:
- Maintain Tor Browser 13.5 past the current planned last version in early September on Windows x86 and x86_64 only
- Drop Windows support for the pluggable-transports which require the newer version of Go that is not Windows 7 compatible (just Snowflake for now)
- Create a watershed update at the ESR 115.15 version of Tor Browser, to split legacy Windows users to maintenance 13.5 channel and everyone else to 14.0
- Update the website and documentation to take this legacy channel into account
- No feature back-ports, only critical bug-fix backports to Tor Browser 13.5
Ongoing work until Mozilla drops legacy Windows support:
- Monthly minor ESR 115 rebases and releases
- Maintaining an additional legacy fork of lyrebird pluggable-transport which works on Windows 7
- User-support to handle the inevitable confusion of browser feature set drift between legacy and latest
And finally the likely consequences of this support:
-
Anti-censorship features will probably stop working long-term; the pluggable-transport work and rdsys (anti-censorship backend infra) are under active development and respond to real-life events. These systems are written in Go which has a very aggressive update and deprecation schedule (Windows 7 support was dropped and subsquently broken sometime in the past year), which means that the anti-censorship team needs either yolo not worry about legacy Windows users, or they need to develop new features using only a legacy-supported subset of the Go ecosystem. If we were to try and support legacy-Windows users, there are some more consequences:
- legacy-Windows users will be using pluggable-transports built with out-of-date and out-of-support versions of the Go tool-chain which may have critical security bugs.
- this will limit the team's productivity working on new features if they are effectively developing with a metaphorical hand tied behind their back at the expense of all the other non-legacy Windows users.
Another hidden factor here, is that the anti-censorship team and the apps team are working to reduce the size of the Android apk to meet Google Play store requirements. Some of the potential solutions here involve some non-trivial changes to how pluggable-transports are built which adds another layer of complexity. Most of the solutions here will complicate maintaining an up-to-date set of pluggable-transports in a potential legacy 13.5 release channel.
So, realistically we will probably have to freeze the pluggable-transports in whatever state they are in com September and/or drop support in the legacy 13.5 channel once the Go ecosystem has moved on.
If we add new rdsys-dependant features to the mix, it is also unlikely that we will be able to backport these changes to the 13.5 release channel as the code-base diverges from current-stable. So, odds are connect-assist will stop working long-term beyond basic bootstrapping.
-
Less capacity to do other things. It does take labour to maintain, build, and publish Tor Browser, even just minor ESR updates. Time spent here is time not spent elsewhere. :woman_shrugging:
A lot of the above proposed solutions involve maintaining various legacy branches, which is of course more overhead.
The other half of the puzzle is that we don't actually know how much impact maintaining legacy Tor Browser will have. We are a small team with a lot of users, so we need to be wise about how we spend our time. The problem with building actually privacy-respecting software is that we don't know who are users are, or what software they are using. The only real stat we have is the number of update pings per platform (ie, Windows, macOS, and Linux) per day. We don't actually know how many of these pings are coming from Windows 7 versus 8, 8.1, 10, or 11.
Suppose our our Windows demographics match vanilla Firefox ( https://data.firefox.com/dashboard/hardware ). The latest (2024-07-01) stats are:
- Windows 10: 48.778%
- Windows 11: 27.479%
- Windows 7: 9.517%
- Non-Windows: 14.226%
Which means about 11.1% of our Windows users would be on Windows 7. If we presume our 'Update pings' rate is roughly the number of daily users we have and we presume our relative Windows demographics is the same as vanilla Firefox, then we're looking at roughly 66,000 Tor Browser users still on Windows 7 (or at the very least, 66,000 daily update pings).
This is not a great situation to be in...
Per our meeting today, we the apps team are left with 3 blocks of questions:
- What would be the impact for maintaining a legacy 13.5 channel for Windows? How many users can't or won't upgrade? Do we care about these users, are they more or less at risk than the general Tor Browser population?
- How much work would maintenance be? Can we handle the overhead of an additional minor rebase, build, publish each month? Is pluggable-transport maintenance likely to be possible long-term if legacy is stuck on an older version of Go?
- What is likely to happen long-term w/ regard to non-Firefox related functionality (tor, pluggable-transports, rdsys, etc)?
We also should outline a plan for the final 13.5 release now to gracefully handle branching Windows 7,8,8.1 users to a new legacy channel while sending everyone else to 14.0 so we're not caught without a plan come September.
Ping:
EDIT: Oh and the final question of course, is it a good use of resources to maintain legacy 13.5 channel?