Improvements for the QR codes

For the hackweek I worked on the bridge QR codes support for Tails.

We have noticed that at the moment multiple bridges (which is the case both of the web request and of the email) are encoded as Python lists. It is almost a JSON format, but it uses single quotes/apostrophes (') instead of double quotes ("). So, parsing the strings is feasible, but not immediate, and I wonder if PT params may include quotes in the future (it would break this workaround).

From the code, I understood that the original intention was having strings separated by \n. This is also compatible with what Tor Browser output (only one bridge line, without any wrapping). Sorry for not checking before. We have still some time to do a last-minute change before Tor Browser 11.5 goes stable.

The Tails's POC implementation can handle both the formats. I don't know if there are other QR code consumers and/or producers, at the moment.

As discussed in IRC, we thought about using the bridge:// URI in the future, too.

Also, I think that PNG would be better as a format, because JPEG doesn't handle sharp edges in a very good way. And we could make them larger, because they are very dense.

assigned to @meskio

added Next label

Ups, sorry, I guess I'm late for 11.5. Let's move directly to use bridge URIs and standarize something with the rest of the interested parties.

Related: tpo/applications/fenix#40189 (moved)

Conversation we had at the Limerick meeting about bridge URIs:

• We want more than one bridge line in a URI, to avoid having users to scan/copy-paste multiple QR codes/bridge links.
• Links to websites instead of custom scheme URIs are nice, but could actually expose our users and make them stand out to the censor / ISPs, so we rather don't want to send unsuspecting users without the right app installed to a Tor-related website.

Suggestion for bridge URIs containing multiple lines using URL-encoded bridge lines:

bridge:///?b=obfs4%2037.218.245.14%3A38224%20D9A82D2F9C2F65A18407B1D2B764F130847F8B5D%20cert%3DbjRaMrr1BRiAW8IE9U5z27fQaYgOhX1UCmOpg2pFpoMvo6ZgQMzLsaTzzQNTlm7hNcb%2BSg%20iat-mode%3D0&b=obfs4%2085.31.186.98%3A443%20011F2599C0E9B27EE74B353155E244813763C3E5%20cert%3Dayq0XzCwhpdysn5o0EyDUbmSOx3X%2FoTEbzDMvczHOdBJKlvIdHHLJGkZARtT4dcBFArPPg%20iat-mode%3D0

bridge:///?b=b2JmczQgMzcuMjE4LjI0NS4xNDozODIyNCBEOUE4MkQyRjlDMkY2NUExODQwN0IxRDJCNzY0RjEzMDg0N0Y4QjVEIGNlcnQ9YmpSYU1ycjFCUmlBVzhJRTlVNXoyN2ZRYVlnT2hYMVVDbU9wZzJwRnBvTXZvNlpnUU16THNhVHp6UU5UbG03aE5jYitTZyBpYXQtbW9kZT0w&b=b2JmczQgODUuMzEuMTg2Ljk4OjQ0MyAwMTFGMjU5OUMwRTlCMjdFRTc0QjM1MzE1NUUyNDQ4MTM3NjNDM0U1IGNlcnQ9YXlxMFh6Q3docGR5c241bzBFeURVYm1TT3gzWC9vVEViekRNdmN6SE9kQkpLbHZJZEhITEpHa1pBUnRUNGRjQkZBclBQZyBpYXQtbW9kZT0w

Pros:

• Multiple bridge lines in one URI
• Agnostic to configuration needs of pluggable transport
• Can be easily exchanged with a https link to a Tor domain. Relevant payload doesn't change.
• Easily parsed by programming languages' standard lib URI parsers.

Cons:

• Human readability suffers
• Might get too long to encode in a QR code which is scannable by low-end devices
• No clean use of the concept of a URI being a pointer to a resource.

Open Questions:

• BASE64 vs. URL-encode? (Looks like URL-encode is better)
• Compression feasible to reduce QR code size?

=> BASE64 in BASE64 looks like a dumb idea. Compression probably also won't gain us much. Is QR already compressed, anyway?

https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#Syntax

bridge:///?b=obfs4%2045.145.95.6%3A27015%20C5B7CD6946FF10C5B3E89691A7D3F2C122D2117C%20cert%3DTD7PbUO0%2F0k6xYHMPW3vJxICfkMZNdkRrb63Zhl5j9dW3iRGiCx0A7mPhe5T2EDzQ35%2BZw%20iat-mode%3D0&b=obfs4%20%5B2a0c%3A4d80%3A42%3A702%3A%3A1%5D%3A27015%20C5B7CD6946FF10C5B3E89691A7D3F2C122D2117C%20cert%3DTD7PbUO0%2F0k6xYHMPW3vJxICfkMZNdkRrb63Zhl5j9dW3iRGiCx0A7mPhe5T2EDzQ35%2BZw%20iat-mode%3D0%0A&b=obfs4%20146.57.248.225%3A22%2010A6CD36A537FCE513A322361547444B393989F0%20cert%3DK1gDtDAIcUfeLqbstggjIw2rtgIKqdIhUlHp82XRqNSq%2FmtAjp1BIC9vHKJ2FAEpGssTPw%20iat-mode%3D0%0A&b=obfs4%20193.11.166.194%3A27015%202D82C2E354D531A68469ADF7F878FA6060C6BACA%20cert%3D4TLQPJrTSaDffMK7Nbao6LC7G9OW%2FNHkUwIdjLSS3KYf0Nv4%2FnQiiI8dY2TcsQx01NniOg%20iat-mode%3D0%0A

We've discussed the multiple bridges per QRCode a lot over the years, I'm still convinced it is not workable. It is just too fussy. I think most of most of the time, it'll literally take longer to scan that single giant QR Code than it would to scan three or four small ones. Giant QR Codes are fussy even when using custom optimized equipment run by trailed professionals. For example, I've been using QRCode-based e-tickets on rail journeys throughout Europe for years now. The scanning is often error prone, sometimes taking quite a while.

QRCode has forms of compression, if you want to try that. Seen the "alphanumeric" encoding: https://en.wikipedia.org/wiki/QR_code It means basically only using all uppercase and few punctuation chars.

Seen the "alphanumeric" encoding: https://en.wikipedia.org/wiki/QR_code

This has been standardized as rfc9285 .

I think I might have contributed to the noise here. Let me try to clarify!

• At the Tor meeting, I asked meskio how could we move things forward so that we have a new, standard, format in place and we at Tails can actually consume it, to help users connect to Tor: https://gitlab.tails.boum.org/tails/tails/-/issues/18219
• He clarified that doing all the work needed (ie: changing BridgeDB) might require quite some time, so I could not expect this to happen soon
• I proposed, therefore, to "quickly" agree on the URI format, so that we could write code to support it
• Defining a URI format which could only support one bridge seemed worthy of much longer discussions; having the format supporting any number of bridges, and then leaving the decision of how to use this format to QR code producers (ie: BridgeDB, TorBrowser) seemed to us the simplest way of reaching consensus over the URI format.

So, to me, the fact that the URI proposal supports multiple bridges is not a sign that it will be used to create huge QR codes. I actually hope that single-bridge QR code will be the norm!

Hope this helps!

It would be nice to have a URL format that supports N bridges. But I can't think of a why to do that without sacrificing having semantic URLs. I guess there could be one format that lets one bridge be sematically mapped to URLs, but then have some kind of flag, like a standard path or query string, that flags it as containing multiple bridges. Then all the data would be in the fragment.

In relation to DNS leaks, I don't think there can be one single format. Some use cases should never leak DNS (bridge://) and other use cases require the link be clickable in standard apps (https://bridge.torproject.org). I think we need to define:

1. how bridges map to URL semantics (host, path, query, fragment)
2. a standard scheme, e.g. bridge: with blob or bridge:// with path, etc.
3. a standard domain name, e.g. https://bridge.torproject.org
4. maybe potentially a fake domain name for clickable links without DNS leaks
5. recommendations for where each should be used

This can be done incrementally and gives us the option to change our minds in the future. The first step is pretty close to done.

The QR code up there contains 4 bridge lines. We could scan it with a Thinkpad laptop camera. UX for scanning multiple codes will be ugly.

yup, and unscannable QR Codes are also ugly...

The QR code up there contains 4 bridge lines. We could scan it with a Thinkpad laptop camera. UX for scanning multiple codes will be ugly.

I don't think it is possible to make this decision based on testing on a single device.

I recognize that once you support multiple bridges in a QR code, nothing prevents you from creating a QR code for a single bridge anyway.

I think we could do so in Tor Browser, since we had bridge cards and we show QRs also for default bridges (which are far too many to be shown in a single QR, and possibly even to generate one, and in general we have small QR codes).

Also, I don't like the URI with an almost plain bridge string. I feel it's very non semantic.

However, this seems not relevant if use HTTPS links with an existing domain, which might be preferrable for a few reasons:

1. apps can register also for domains, in some platforms like Android
2. Tor-enabled apps will be able create a bridge line from this link, without even making the HTTP request, and must do so, if we decide to use HTTPS links
   • we don't want them to send data to the censor
   • we don't want the censor to be able to block this mechanism
3. the custom scheme can be registered at OS level, but apps such as instant messaging apps won't support it
4. if we use a real domain, we can show a page with a few additional info:
   • the decoded bridge line (possibly in giant font), with a nice copy button
   • what's Tor, how you can download Tor-enabled software and how you can add bridges (e.g., Tor Browser, Tails, Onionshare, with the relative screenshots)
   • try also to redirect to the custom bridge scheme to automatically open the relative app (like what t.me does)

apps can register also for domains, in some platforms like Android

I think that the opposite is true in Linux desktop. Your redirect trick will still make it work, at the cost of a DNS query which will reveal they want to use a Tor bridge.

the custom scheme can be registered at OS level, but apps such as instant messaging apps won't support it

do you mean that if a user receives a tg://share?url=www.example.com?t=12&text=test link over Signal, they cannot successfully click on it? This would be so surprising to me! But I'm definitely ignorant about Android.

I think that the opposite is true in Linux desktop. Your redirect trick will still make it work, at the cost of a DNS query which will reveal they want to use a Tor bridge.

True. But aren't all links opened in Tor Browser, in Tails?

I think we can't expect all users to open the bridge URL in Tor Browser, on desktop .

do you mean that if a user receives a tg://share?url=www.example.com?t=12&text=test link over Signal, they cannot successfully click on it? This would be so surprising to me! But I'm definitely ignorant about Android.

It depends on the regexp used to detect link.

I think many apps look for https?://.

There‘s also some which look for stuff like „www“ and „.com“ and similar.

Probably depends highly on what lib the respective app uses. May work or may not.

True. But aren't all links opened in Tor Browser, in Tails?

In Tails, yes, but it's actually irrelevant: if you can open the https link, it means you're already connected to Tor, so why do you want to fiddle with bridges?

Elsewhere, where opening the URI is actually relevant, no. Oh, and a censor now just need to block that domain in order to "block" bridges (not really of course, but if we expect that this URI is used, than there will be user effectively blocked by this very simple censorship).

do you mean that if a user receives a tg://share?url=www.example.com?t=12&text=test link over Signal, they cannot successfully click on it? This would be so surprising to me! But I'm definitely ignorant about Android.

It depends on the regexp used to detect link.

oh, I thought this was much more standard system-wide. I can just tell you that I sent exactly that link over Conversations (not Signal) and it works. I can't generalize that this approach always works from this one very simple try.

added Backlog label and removed Next label

added Q4 label

mentioned in issue #40062 (moved)

added UX label

removed Q4 label

added Roadmap::Future label and removed Backlog label

marked this issue as related to team#117 (closed)

Fun idea of the day: Encode bridges or bridge URIs as "Ecoji" plain text as emoji to make copy and paste and sharing in social mechanism more fun, slight safer, and slightly more resilient to censorship

https://github.com/keith-turner/ecoji

obfs4 178.27.102.182:40771 7080F2280EE04AE94F2792D569E0362192674202 cert=cz5iBFFkdUxFJ4HLLElPcjWCb/RU+aL4JGj1d/fkJQRbs3mH/TLTee9oGY1mlJI9XCVIMw iat-mode=0

base64: b2JmczQgMTc4LjI3LjEwMi4xODI6NDA3NzEgNzA4MEYyMjgwRUUwNEFFOTRGMjc5MkQ1NjlFMDM2MjE5MjY3NDIwMiBjZXJ0PWN6NWlCRkZrZFV4Rko0SExMRWxQY2pXQ2IvUlUrYUw0SkdqMWQvZmtKUVJiczNtSC9UTFRlZTlvR1kxbWxKSTlYQ1ZJTXcgaWF0LW1vZGU9MA==

ecoji: 🧷🦿🪫🪬🧝🥎🪪🪑🧞🧵🫄🦿🩼🦻🪫🫃🧺🫡🧝🧏🫃🪲 🫢🧴🧠🦽🧸🪬🪅🥹🧞🧢🪱 🪐

marked this issue as related to team#126

mentioned in issue rdsys#185