> Bridge URIs do not address the problem of multiple bridges in the same QR. An > idea could be to separate them by newlines.
QR-codes from BridgeDB are already big enough I can't scan them reliably on my phone. I think even if multiple bridges per QR-code is supported, BridgeDB (and anything allowing to export bridge lines) should provide a way to export bridges as QR codes one at a time. This would become even more important if some additional metadata like a signature is added. Regards, Trinity Le mar. 2 août 2022 à 13:23, Michael Rogers <[email protected]> a écrit : > > > On 20/07/2022 18:15, Nathan Freitas wrote: > > > > > > On Wed, Jul 20, 2022, at 8:01 AM, meskio wrote: > >> Quoting Torsten Grote (2022-07-19 14:54:01) > >>> On Monday, 18 July 2022 13:47:21 -03 meskio wrote: > >>>> What do you think of the proposal? How can we improve it? > >>> > >>> A slightly unrelated question: > >>> > >>> Was there any consideration about deanonymization attacks by giving > the user a > >>> bridge controlled by the attacker? I worry that those get more likely > when > >>> getting bridges via links and QR codes becomes normalized. > >>> > >>> Apart from the source IP address of the user and their Tor traffic > pattern, is > >>> there anything else an attacker can learn from operating the bridge? > >> > >> At least from my side there was not consideration on this topic yet. > Thank you > >> for bringing it, I think is a pretty valid concern and we should do some > >> planning on it. > >> > >> I wonder if we should only accept bridge URIs/QR codes when the user > >> clicks on > >> 'add bridges' inside the tor related app. Or will be enough to accept > >> bridge > >> URIs on any moment but communicate to the user clearly what is > >> happening and ask > >> them for confirmation. We should never change the bridge configuration > >> silently > >> from a bridge URI without any user intervention. > >> > >> I think we should add something about it to the "Recommendations to > >> implementers" on the proposal. > > > > I believe in Orbot today we do promote the user after they scan a code > or click on a bridge link. Definitely agree there should be that step. > > Another thing that would be useful for this scenario would be for > BridgeDB to publish some kind of signed record saying "the bridge with > such-and-such a fingerprint was known to BridgeDB at such-and-such a > time" - similar to what can already be queried via the API, but in a > form that could be distributed offline. > > If users were able to distribute these records alongside the > corresponding bridge lines then apps might decide to treat BridgeDB > bridges differently - for example, showing a warning if the bridge > entered by the user was *not* signed by BridgeDB. This would provide a > useful second layer of trust when finding bridges from sources like > Telegram bots, where the provenance isn't always clear. > > However, including these signatures in a bridge URI might make the URI > quite long, which in turn might cause issues with scanning QR codes. So > there might be tradeoffs here. > > Cheers, > Michael > _______________________________________________ > tor-dev mailing list > [email protected] > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev >
_______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
