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]
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-project mailing list tor-project@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project