Draft a rough plan to switch to an offline about:tor homepage

This is part of the evaluation we're doing for #20936. Most of the work was done on #20822 (closed) already.

Preamble
Problems → solutions
To Do

Preamble

Our analysis on #20822 (closed) has been focused on the problems we've already solved in the past — sometimes by design, sometimes as a result of lucky beneficial side effects — thanks to using an online browser homepage. This past history may or may not reflect our current and future needs. It could be useful, once we're done here, to take a step back and reflect about our current and future needs, and assess their importance without being primed by "here's what our online homepage used to give us for free and regressions are bad".

Problems → solutions

Reliable generic notification mechanism

Proposal

Do nothing purely for the sake of this feature, because no candidate solution has a good enough cost/benefit.

But it's possible that if we look at this together with the desire to advertise release notes of newer Tails versions better, and/or to deliver timely news to users, we can find a shared solution, and the combined benefits of these 2 or 3 features could make the implementation cost worth it.

Value

Low to medium because:

Impact is:
- high, iff. we give the user only the info they need, only when they need it
- low to medium, iff. we always give the user the same info, regardless of whether they need it
Risk of a problem occurring, where this makes a difference, is low: code improvements that were implemented already make it unlikely that all our existing notification mechanisms fail at the same time.

For details, see #20822 (closed).

Candidates

Open about:tor and https://tails.net/news/ in 2 different tabs. Or open about:tor for new tabs and https://tails.net/news/ for new windows.
- Cost: 3 (probably needs test suite updates, possibly doc update)
- Benefit: 1 (directly gives access to the info, but pops up even when there's no reason to notify, so alert fatigue, and probably most users don't know what version they're running, so how can they tell whether the release notes on top of /news are newer than what they are running? They would essentially need to make a mental note of the last version they've seen advertised there, which does not feel super reliable.)
Time-based expiration mechanism: when doing a release, we encode the expected date for the next release. If we're enough past that due date, and the Upgrader did not find an upgrade, it displays a dedicated error message, and proposes the user to open https://tails.net/news/
- Cost: 5
- Benefit: 3 (only notifies when relevant; but only triggers on some Upgrader-related failure modes, so does not work as a generic notification mechanism)
- Implementation details:
  - needs to run after htpdate.service

Rejected

Upgrader: on failure to check for updates, link to https://tails.net/news/
- Rejected because does not move the needle enough to bother
- Cost: 1 (updating 2 strings in the UI)
- Benefit: 1 (not much better than statu quo; only triggers on some Upgrader-related failure modes, so does not work as a generic notification mechanism)
- Statu quo: we tell users "Check your network connection and restart Tails. If the problem persists, try doing a manual upgrade." (which will lead them to our website, so there's a chance they see the news there; and even if they don't, the manual upgrade will solve the problem, so it does not really matter)
- Optional improvement: open that page in Tor Browser, to workaround #17068. This requires much more work and we don't do this for other errors, so not super worth it.
Link from about:tor to https://tails.net/news/
- Rejected as a solution to this problem, because it does not really "notify"; but maybe it could be useful to do this anyway?
- Implementation details: about:tor already has conditional contents (e.g. guarded on whether it's a stable release and whether TorConnect is enabled) so presumably we can add this only when running on Tails.

Allows for easier update, and less need to do the work in advance, for Tails-specific messages

Proposal

Do nothing purely for the sake of this feature, but hope that a solution with other problems will solve this one as well.

Use about:tor to display messages when Tails is detected (if needed, in a time-gated fashion, just like for donation campaigns).

Value

Low, because this only matters for messages that:

We can't guess the need for in advance (for other ones we can display them in about:tor, in a time-gated fashion, just like for donation campaigns, assuming it's feasible to have messages displayed only when running in Tails).
We need to update with low latency, which is rare.

To put this into perspective, most messages displayed in the Tails or Tor Browser UI need a release to be updated, so this would bring this class of messages to that same state; it's less convenient than "whenever I want", for sure, but it's manageable.

Allows people to receive our timing-sensitive news in a "push" fashion

Proposal

Have about:tor advertise not only "sign up for Tor news" on about:tor, but also "sign up for Tails news" (which would point to amnesia-news since currently it's the best we have for this kind of things) when running on Tails.

Value

Low because this is rarely needed.

For example, the scope:

Does not include the call for donations: they are already displayed inside Tor Browser's about:tor.
Does not include news that are not timing-sensitive: they can also go to about:tor.

I (intrigeri) have scanned the last 2 years of /news and there's only 1 post that's in scope here: the merge announcement. It's not critical if users who don't want to leak an email address to subscribe to the Tor newsletter miss this.

Candidates

tails-security-check mechanism does exactly this; we could adapt it to work for non-security stuff as well, or write another minimal feed reader that does this.
- OTOH would be vastly more beneficial for Comms, and for Tor users, if this were implemented in Tor Browser's about:tor, so that it works for news that are not Tails-specific too. We could check with the Applications team, UX team, and Comms, if this is something they would like, and if they do, we could create an issue to track this feature request in Tor Browser.
- In any case, this will create alert fatigue for users without Persistent Storage: we'll keep displaying the same news every time they start Tails, until we switch to the next news. Perhaps it's one of this cases where it's OK to optimize for users with Persistent Storage?
- This would also address "Reliable generic notification mechanism" and "Allows for easier update, and less need to do the work in advance, for Tails-specific messages".

Advertises the release notes for versions of Tails newer than the current one

Proposal

Value

Low, because the statu quo is a pretty weak implementation of this feature, so losing it would not be a huge loss: it's unlikely that most users actually know which version of Tails they're running, so it's not a given they'll notice whether the release notes on top of /home are newer than what they're running, or what they've read already.

Candidates

open about:tor and the release notes in 2 different tabs. Or about:tor for new tabs and the release notes for new windows
- See discussion about this above. tl;dr: does not really solve the problem, so maybe not worth the effort?
When preparing the release notes, we add 1 line to the UDF, that will be displayed in the Upgrader notification; this could the summary of the major changes that we already write for Twitter.
- Implementation details:
  - No need for l10n: we gave up on translating release /news (#21137 (closed)).
- Drawbacks:
  - The RM has to wait for technical writers before they can generate and sign the UDFs.
  - Need a new system and custom code to update this over all UDFs, whenever we want to change the message. And this needs re-signing.
  - Unclickable URLs in Tails Upgrader (#17068) is a bummer here: a link to the release notes
    
    won't work.
Integrate the release notes in the upgrade process (#18861)
- With our current Upgrader, the cheapest way to do this is to forcibly open the release notes of the new version, in a new browser window, while downloading the upgrade. That's questionable UX and this only works for users who have already convinced themselves they should upgrade now, i.e. it's not going to motivate anyone to upgrade.

To Do

In order to make the above plan internally consistent, on top of what's written in the "Proposals" subsections above, we have to:

(Short term, blocker) Build & document a mechanism for Tails technical writers (and optionally Tor Comms) to add messages that will be displayed on about:tor when Tor Browser is running on Tails.
- These messages would have to be written, and baked into the Tor Browser or in Tails, ahead of the release.
- Some of these messages could be (almost) always present, e.g. the invitation to subscribe to Tails news. While others would be temporary. There should be an option to time-gate the display of these news.
- One such message could be a link to the release notes of the running Tails, like Signal's "See what's new in this update": his would address the "here are the changes in the version you've just upgraded to" aspect, but not the "here are the improvements you will get by upgrading" part.
- Ideally we would not display these news when we start Tor Browser offline, because at that point we can't rely on the clock, so the time-gating can fail. Probably not a blocker though.
- l10n support would be great: if the news are written sufficiently in advance, their strings could be picked up by translators just like a Tor YEC (if baked into Tor Browser) or like Tails GUI updates (once merged into our devel branch).
(Mid term) Check with other teams if we want to teach Tor Browser to fetch online news and display them on about:tor. This would basically plug all the regressions created by the switch to about:tor.

Edited Sep 10, 2025 by intrigeri

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information