Regarding the last point: in my case, my torbrowser was up to date.

ultimately, do not allow a rogue exit nodes to random DOS torbrowser-launcher users: let the user launch a potentially out of date version of the software and maybe warn the user about the problem.

'there was a problem looking for updates, one relay in the tor network may be compromised')

do not report that the user may be individually under attack ('you are under attack') and instead report the problem more factually (e.g.

report which exit node is (presumably) was in use when the verification failed.

failing that, at least try another circuit if the first one is compromised.

use a hidden service address to download the tarball to avoid exit node MITM (I can't find the address right now, but i seem to recall setup exit nodes for all services).

I recommend the following measures be taken: It is way more likely this is a rogue exit node. I think this is a mischaracterisation of how tor works: if the user able to build a circuit (which seems to be the case here), then the exit node is not supposed to know who he/she is, unless the tor network is compromised in a novel way, or some very powerful actor is running a correlation attack. I am particularly concerned that the user is being informed that he/she 'may be under attack'.

it doesn't identify the rogue exit node so there is no way for tor operators to fix the issue.

it makes it possible to 'DOS' (Denial Of Service) users out of starting tor completely by jamming the communication channel - presumably this could fail if key entry points are censored as well.

users may assume they are under an individually targeted attack, which is probably not the case here.

compromised exit node) and that there is an easy workaround (restarting the browser)

users will not know this is a possibly transient failure (e.g.

Restarting the launcher fixed the problem.

Tor browser download failed