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