Support bridge: scheme URI to configure bridges

For easy bridge configuration on mobile, via QR code scanning, links sent in text messages or emails, TBA should support an agreed upon format for bridges sent via bridge:// encoded URI.

Copy and pasting bridge lines into a settings menu is highly unusable and prone to errors. The ability to one tap or one scan configure bridges with a confirmation dialog is easy and streamlined!

marked this issue as related to tor-browser#28015 (closed)

changed milestone to %Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibet

added Backlog label

mentioned in issue tpo/anti-censorship/team#46

Historic discussion on this issue: legacy/trac#15035

marked this issue as related to tor-browser#40780 (closed)

removed the relation with tor-browser#40780 (closed)

marked this issue as related to tor-browser#40782 (closed)

added Anti-Censorship Sponsor 96 UX labels

removed Backlog label

added Next label

@richard this is likely another issue for 11.5 stable

Works for me, can you look into this implement a sensible encoding scheme for the bridge cards in tor-browser#40774 (closed) (and also draft a spec for the applications wiki documenting the encoding scheme)?

Done: https://gitlab.torproject.org/tpo/applications/team/-/wikis/Design-Documents/Bridge-URI-RFC

(and I discovered that our GitLab does not support some advanced markup, like the alert boxes)

@pierov spec looks good! once it firms up (eg: we reach a decision on how to encode the transport and how transport-specific query params should be encoded), i would find it helpful when implementing if the spec gave one or several example query strings as @n8fr8 does in legacy/trac#15035 or @eighthave does in https://gitlab.com/torproject/Bridge-URLs/.

@pierov spec looks good!

Thanks!

i would find it helpful when implementing if the spec gave one or several example query strings

You are super right! Thanks for the feedback!

PS quick process question/suggestion: since as i cannot begin implementing the logic in Fenix to consume these URIs until their spec has been finalized, it might be nice to somehow split out the task of (1) specifying the scheme from (2) implementing logic to consuem QR codes using the scheme?

that way i could wait to begin work on (2) until i notice that (1) has been completed.

proposal: lets...

• rename this card into "Support Design bridge: scheme URI to configure bridges"
• make a new card called "Conseme QR codes using bridge: scheme to configure bridges"

does that sound reasonable @richard / @pierov ? or: do you have other ways we might accomplish the same thing? (my only real need is to get clearly notified "the spec is done, you can start coding!")

• rename this card into "Support Design bridge: scheme URI to configure bridges"
• make a new card called "Conseme QR codes using bridge: scheme to configure bridges"

Yeah, but we should also move this issue to another project...

Or we could create a new issue for the design task and keep this one for the implementation when we will be done with the design. Either ways work for me, for the moment I'm just waiting for comments .

create a new issue for the design task and keep this one for the implementation when we will be done with the design.

i like that! feel free to go with whatever you think is best and let me know.

we should also move this issue to another project...

can you say more? i assume that pertains to your comment below that "This issue is for Fenix, probably we should open one for Tor Browser (and use the same URL of Fenix)."

is the idea that we maybe have 3 separate tasks/tickets on our hands? something like...

1. design the URI (new ticket, perhaps in tor-browser-spec?)
2. produce QR codes with this URI in Tor Browser Desktop (new ticket in tor-browser?)
3. consume QR codes with this URI in Tor Browser Android (this ticket?)

can you say more? i assume that pertains to your comment below that "This issue is for Fenix, probably we should open one for Tor Browser (and use the same URL of Fenix)."

I meant: «if we rename this issue from "Support bridge: scheme URI to configure bridges" to "Design bridge: scheme URI to configure bridges", we should also move it to some other project (tor-browser-spec), rather than keeping it here on Fenix».

is the idea that we maybe have 3 separate tasks/tickets on our hands? something like...

1. design the URI (new ticket, perhaps in tor-browser-spec?)

Yes, sounds good to me.

We should also check what other apps do, because IIRC Orbot or something else already supports QR codes.

2. produce QR codes with this URI in Tor Browser Desktop (new ticket in tor-browser?)

Either a new one, or include it in tor-browser!254 (closed) (I have already added the code for the QR code).

But we should also handle bridge:// links, which is an additional feature.

(However, I would not register Tor Browser desktop as a handler, at least by default, because we want to keep TB self contained and we want users to be able to make their system forget TB just be deleting the directory - even though I do not believe it is this easy on Windows because tracks even temporary .exe in the registry)

3. consume QR codes with this URI in Tor Browser Android (this ticket?)

Yep. But on Android I would add the intents, and also handle URLs.

cool! also: sorry -- i didn't mean to muddle the QR/link issue or mangle the scope of already existing tickets. this all sounds good, and i'll sit tight until the spec is ready to be implemented in Fenix -- then probably have a few questions about doing that.

I think we ought to also have the emojii table explicitly defined in the spec, possibly even available for download in common formats (json, js, cpp, java, etc, etc, etc)

assigned to @pierov

This issue is for Fenix, probably we should open one for Tor Browser (and use the same URL of Fenix).

I do not know whether you prefer me or @aguestuser to take care of the Fenix implementation.

changed milestone to %Tor Browser 11.5

Yeah I think @aguestuser ought to take care of the fenix implementation

mentioned in issue tor-browser#40848

marked this issue as related to tor-browser#40848

added Q2 label

added Backlog label and removed Next label

added Next label and removed Backlog label

So we are going to want to try and coordinate the bridge-card QR codes URI scheme w/ various mobile consumers:

• TBA
• Orbot
• cwtch
• briar

changed milestone to %Tor Browser 12.0

added Roadmap::Future label and removed Next label

added Q3 label and removed Q2 label

mentioned in issue tpo/anti-censorship/bridgedb#40052

removed Sponsor 96 label

removed Q3 label

added Android label

closed

moved to tor-browser#41193