[tor-dev] bridge:// URI and QR codes

[trinity pointard]

> 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 <michael at briarproject.org> 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
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20220802/700f9a59/attachment.htm>