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

Quoting Torsten Grote (2022-07-19 14:54:01)

> 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.

···

On Monday, 18 July 2022 13:47:21 -03 meskio wrote:

--
meskio | https://meskio.net/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
My contact info: https://meskio.net/crypto.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Nos vamos a Croatan.

1 Like

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.

···

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.

_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

I meant *prompt* the user.

···

On Wed, Jul 20, 2022, at 1:15 PM, Nathan Freitas wrote:

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.

_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

···

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.

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@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@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev