[tor-bugs] #28015 [Applications/Tor Browser]: Brainstorm improved ux for orgs that want to give bridges to their people
Tor Bug Tracker & Wiki
blackhole at torproject.org
Tue Jan 29 13:09:52 UTC 2019
#28015: Brainstorm improved ux for orgs that want to give bridges to their people
-----------------------------------------------+---------------------------
Reporter: arma | Owner: tbb-team
Type: defect | Status: new
Priority: Medium | Milestone:
Component: Applications/Tor Browser | Version:
Severity: Normal | Resolution:
Keywords: ux-team, education, documentation | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor: Sponsor19
-----------------------------------------------+---------------------------
Comment (by eighthave):
It should be pretty straightforward to use "bridge://" URLs on desktop
platforms. I only vaguely know Windows, but I've done this kind of thing
on GNOME things and on Mac OS X over the years. Both have a system-wide
place to register apps that handle certain URL schemes. So Tor Browser
would just need to register itself to handle "bridge://" then receive it
somewhere, and parse it. It should probably also bring up the bridge
config UI after receiving such a link.
The trickier case to handle in Tor Browser is perhaps the case where there
is a bridge URL with an "https://" scheme. Of course, all platforms will
direct that to the browser, but only Android can provide strict matching
of something like
"https://bridge.torproject.org/config#984ujqw9d82m398end" (perhaps iOS
also, but I don't know the details there). Then the question is: if Tor
Browser receives such a URL, is it appropriate for it to intercept that
URL and show the bridge config UI instead of the web page?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28015#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list