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

[Georg Koppen]

Arturo Filastò:
> On 22/11/2016 17:14 +0000, isabela wrote:
> 
>> On 11/22/16 10:10, Georg Koppen wrote:
>>> Roger Dingledine:
>>>> 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.
> 
> Yes I agree this would be useful, though we think the first step would
> be to just do a simple TCP connection scan. We are actually going to be
> pushing this test to all users of ooniprobe and we currently don't list
> obfsproxy (or obfs4proxy) as a hard dependency of ooniprobe which would
> be a requirement to have the full test run there.
> 
> We can change that in future version, but we should first do the simple
> thing so we can get it out soon and start being useful, rather than wait
> more to have something more fully featured.
> 
> This is part of the following ticket:
> https://github.com/TheTorProject/ooni-probe/issues/614
> 
> There are pending pull requests for adding testing via a simple TCP
> connect and we will be rolling this out as part of the 2.1.0 release due
> and the end of this month.
> 
> The relevant pull requests are:
> https://github.com/TheTorProject/ooni-probe/pull/682
> https://github.com/OpenObservatory/ooni-resources/pull/1
> 
> Question for Tor Browser team:
> This is the list of bridges we are going to be testing as part of this
> first iteration:
> https://github.com/OpenObservatory/ooni-resources/pull/1/files#diff-4534a6062fbf50f7e59b953fb772d809
> 
> This list is based on what David gave us to test and I think it includes
> most bridges from the current TBB (though it doesn't seem to include all
> obfs3 bridges) plus some other bridges that I believe you plan to start
> using in the future.
> 
> Is there something else you would like to have tested and added to this
> list?

That's quite a large list. What the Tor Browser team needs are the
bridges specified in

https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/Bundle-Data/PTConfigs/bridge_prefs.js

(which is subject to change). It seems your list is missing items from it.

>>>> * 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.
>>>
> Yes I agree that it would be great if we had some way of notifying
> bridge users directly, however we currently don't have support for
> notifications inside of our data processing pipeline.
> 
> It is something we have planned, but it will not be available immediately.
> 
> I guess we should understand what should be done based on these results
> once the first iteration is done.
> 
>>>> 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.
> 
> Something also to consider is that certain bridges may not be working
> only from specific locations. That is OONI tests will not just tell you
> if a bridge is DOWN, but will actually tell you in which countries a
> certain bridge is or is not working.
> 
> I wonder if it would make sense to at some point consider integrating
> this knowledge into Tor Browser itself. That is we could have some logic
> as part of tor launcher that makes the user input their country and
> depending on the country they input we know if we should advise them to
> use bridges (because we know vanilla tor to be blocked there) and if so
> which bridges are OK to be used there.

Maybe? I think this is definitely an idea worth thinking about.

>>> 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
>> I really like the idea and I agree OONI is in the best place to perform
>> these tests.
>>
>> Like Georg pointed out we have to think what to do once the test detect
>> a bridge is not working. From the above I think we have two paths:
>>
>> 1. operator - we should notify the operator for sure, if we can do it in
>> an automate way that would be great. If not, we should centralize such
>> notifications in a place and have a person in charge of reviewing those
>> and sending a note to the operator.
> 
> My suggested step 0 is that we first get these measurements out and
> somebody looks at the results and checks to see how useful they are and
> actionable.

Yes, indeed. Who should that somebody be (ideally)?

Georg

[snip]

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