[tor-bugs] #31283 [UX]: O3.2 - Design the flow of how our users can bypass the scenarios of O3.1.
Tor Bug Tracker & Wiki
blackhole at torproject.org
Wed Jun 10 22:02:28 UTC 2020
#31283: O3.2 - Design the flow of how our users can bypass the scenarios of O3.1.
---------------------+--------------------------------
Reporter: gaba | Owner: antonela
Type: project | Status: new
Priority: Medium | Milestone:
Component: UX | Version:
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: #31269 | Points:
Reviewer: | Sponsor: Sponsor30-must
---------------------+--------------------------------
Comment (by phw):
> Does user solve a puzzle?
[[br]]
Moat currently serves a CAPTCHA before it hands out bridges. While not
perfect, a CAPTCHA is still better than no CAPTCHA. That said, I'm open to
hearing about alternatives!
[[br]]
> Does user disclose sensitive information eg. location?
[[br]]
Knowing the user's location would help us pick the best circumvention
method. For example, default bridges are all that a censored user needs in
some places. Over at #28531, we are working on a censorship snapshot. We
could embed this snapshot in Tor Browser, so it knows the best
circumvention method in a given country. The problem is that censorship
can change faster than we can ship a new version of Tor Browser, resulting
in an outdated snapshot that suggest a circumvention method that no longer
works.
However, we don't ''need'' to know the best circumvention method. Tor
Browser could start with a direct connection and switch over to default
bridges if it cannot connect to the network directly. If default bridges
don't work either, it can start using Moat to request an obfs4 bridge.
Bundling Tor Browser with OONI may be difficult because of size
constraints.
[[br]]
> Do you feel comfortable with picking the best bridge for users instead
of asking them to find one?
[[br]]
Yes, definitely. We already know what works in many countries and we might
as well make Tor Browser take this information into account.
[[br]]
> Given our short capacity for browser development, can this team provide
the needed patches to tor browser devs for making this happen?
[[br]]
Do you mean the anti-censorship team? That may be difficult because we
have little to no experience with Tor Browser development. That said, if
this turns out to be a mostly self-contained task (and I'm not in a
position to tell if it is), we may be able to help here.
It would be great to hear from a Tor Browser person because most of the
work for this ticket will happen in Tor Browser.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/31283#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list