[the Montreal meeting], we discussed the possibility of creating an opt-in, embedded testing/telemetry module for Tor Browser that would allow collection of data on connectivity for Tor and for different bridges and pluggable transports. OONI could collate and analyze this data to give a better picture of the per-country bridge connectivity situation. That data could be used to improve Tor Launcher's connection UX, and also help compare different censorship circumvention tools.
This can be a parent ticket for designing and developing such a module.
Designs
Child items ...
Show closed items
Linked items 0
Link issues together to show that they're related.
Learn more.
Trac: Description: At the Montreal meeting, we discussed the possibility of creating an opt-in, embedded testing/telemetry module for Tor Browser that would allow collection of data on connectivity for Tor and for different bridges and pluggable transports. OONI could collate and analyze this data to give a better picture of the per-country bridge connectivity situation. That data could be used to improve Tor Launcher's connection UX, and also help compare different censorship circumvention tools.
This can be a parent ticket for designing and developing such a module.
to
[the Montreal meeting], we discussed the possibility of creating an opt-in, embedded testing/telemetry module for Tor Browser that would allow collection of data on connectivity for Tor and for different bridges and pluggable transports. OONI could collate and analyze this data to give a better picture of the per-country bridge connectivity situation. That data could be used to improve Tor Launcher's connection UX, and also help compare different censorship circumvention tools.
This can be a parent ticket for designing and developing such a module.
I was going to go make a ticket for this idea ("Make a "censorship detection" Tor Browser variant") when I found this ticket already existing. It is still a good idea.
We spoke at various times of a Tor Launcher feature ("make the connect option just work") that cycles through bridge types and transport types until it gets to one that works. There are tradeoffs with user safety and user experience that make us pause.
But there's a variation of the idea that we could do first, and it would be useful now, and the effort would be mostly reusable for that future idea:
Let's make a Tor Browser variant, or an option inside Tor Browser, that tries all of the various anti-censorship combinations and reports to the user on their status.
That way when people are in a crappy network environment they will have a simple tool they can fetch and run and it will tell them about their ability to use various Tor transports on their network. And if we make it clear that this isn't "normal Tor Browser", hopefully we sidestep many of the user experience / user confusion questions.
An advanced step would be to figure out a way to automatically exfiltrate the answers, OONI style, via domain fronting or some similar trick. But to start, it could just pop up a window / write out a text file with the assessment, and the user can copy-paste the analysis, or read it, or whatever they want to do.
Another advanced step would be to have Tor give better feedback to Tor Launcher (and thus to our output file) about what went wrong (legacy/trac#28018 (moved)). But I think we can develop this idea in parallel with how exactly Tor will report about its success for each permutation attempt.
Adding sysrqb to the huge cc list, to get him thinking about how this idea would work on mobile. Would Tor Launcher just do the same thing on Android as it does in Tor Browser? I think it depends on Tor Browser Android's interaction with Orbot.
Trac: Cc: gk, arthuredelstein, brade, mcs, boklm, pospesel, hellias, arma to gk, arthuredelstein, brade, mcs, boklm, pospesel, hellias, arma, sysrqb