[tor-project] Cross-team OONI and Tor Browser project: default bridge checking

[Georg Koppen]

Roger Dingledine:
> On Sat, Nov 19, 2016 at 07:17:41PM -0800, David Fifield wrote:
>> There's also this recent ticket for reachability-only testing of default
>> bridges:
>> https://github.com/TheTorProject/ooni-probe/issues/652
> 
> Ah ha, right, your experiments with measuring blocking of default bridges
> totally tie into this one.
> 
> I think the things that I want beyond what you want are:
> 
> * Actually seeing if Tor works using the obfs bridge. In this case,
> the bridge address is accepting the TCP connection and then immediately
> hanging up -- it's like there's some proxy in front of the obfsproxy,
> so *something* answers, but it sure isn't obfsproxy. The goal here would
> be to learn if it's broken, rather than to learn if it's being interfered
> with, so maybe that will make measurement less complicated.
> 
> * I want the Tor Browser team to get involved with knowing how the tests
> work, knowing that they're happening, and having some way of noticing
> when the tests say that something has broken. Otherwise there will be
> knowledge inside some OONI data set somewhere that says a bridge stopped
> working, but we won't have anybody in place to close the loop and *do*
> something about it.

I am fine with getting to know how those tests work and that they are
happening. I think even getting a notice when something is broken is a
good thing. But I don't think we (Tor Browser team) should be the ones
hunting down folks to fix their bridges. Ideally the tests would show
the bridge is not working anymore and the operator gets directly a
notification about it. There should be no need to put the Tor Browser
team or a member of any other team in the middle.

> Though actually, there's some room for us to realize that it should
> instead be the Network team that steps in here. Or perhaps for both the
> Tor Browser team and the Network team to say that this topic isn't in
> their area. That outcome would be great to recognize and tackle too,
> since it needs to be in *somebody's* area.

Well, OONI seems to be in a good position to do the checking, if we want
to do that.[1] The question is what happens afterwards, in case a bridge
is down? As I said above notifying folks should not involve any other
team than the one that did the measurement.

I am not sure yet what to do if we get a report that a default bridge is
not working anymore and a Tor Browser release is about to get built. But
maybe that case can get discussed and decided when we have reliable and
continuous measurements and notifications in place.

Georg

[1] Ideally we would not need the measurement from anybody at all but
the bridge operator would set up the respective infrastructure to get
notified as soon as things are not working anymore. But I guess that
would raise the bar for deploying a respective bridge considerably to
the extent that we end up with less bridges we can ship in Tor Browser.
Which is not desirable.

> --Roger
> 
> _______________________________________________
> tor-project mailing list
> tor-project at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-project/attachments/20161122/d09fc02e/attachment.sig>