Re: More thoughts on bridge distribution strategies

[Christian Fromme <kaner@xxxxxxxxxx>]

Hi Roger,

On Tue, Dec 8, 2009 at 2:12 AM, Roger Dingledine <arma@xxxxxxx> wrote:

> ---Part three--------------------------------------------------------
> But I have a better fix. Why not automatically mail out an update if
> the answer changes? There could be a new command 'subscribe bridges',
> and then it will remember which ones you've heard already, and if the
> best three answers include any you haven't heard before, it'll send you
> an email. Or we can batch them, or only mail if none of the ones you've
> heard are still up, or some other permutation. 'get bridges' could be a
> synonym for a one-week subscription.
>
> This approach means storing data about which gmail addresses are our users
> (boo), though hopefully they're using throwaway gmail addresses if that
> matters to them. But better, it brings in a host of new possibilities down
> the road when the arms race has moved to its next phase. Specifically,
> we can allocate persistent bridges to the gmail accounts that have been
> around a while, or the ones whose bridges didn't get blocked, etc. See
> "the sixth strategy" in the original blocking-resistance design doc for
> my original plans there:
> https://git.torproject.org/checkout/tor/master/doc/design-paper/blocking.html#tth_sEc7.4

I think the benefits outweighs the risk of keeping email addresses.

> It's kind of a shame that we can't demand proof-of-ongoing-work though.
> I fear the scenario where we just accrue more and more gmail accounts
> that we're mailing updates to but they've long since forgotten about
> Tor. Should we make them re-subscribe periodically? Alas, our proof of
> work on the gmail side is in creating a new account, not in receiving
> further emails. So maybe we need to start relying more on the social
> networking side as the arms race progresses here.

Why not mail the user periodically with a mail 'do you want more
bridges'? If he answers to that, he has effectively extended his
subscription, where otherwise (say, grace period of one week) we purge
his address from our database.

> ---Part four--------------------------------------------------------
>
> Conclusion #4 is that we need to automate some other distribution
> approaches. When the https approach got blocked, and we worried the gmail
> approach would get blocked soon after, we got a friend in China to set
> up a password-protected twitter account and sign up his 1000 closest
> friends. Then I manually fed him the list of "reserve" bridges for a
> few weeks, and he twittered a few bridges per day.
>
> We need somebody to automate the posting of them on the twitter side
> (anybody want to help write the scripts there?). And we need to automate
> the bridgedb side also, for example so it writes out an up-to-date new
> list of bridge addresses to various files that we can then export. As
> a simple example, I'd like to mail a daily list to this fellow in China
> with
> a) which bridges from the previous mails are still around today, and
> b) all the newly available bridges.

I don't know whether you already meant this, but we surely should
encrypt those mails.

> Next would be having bridgedb, or some associated scripts, track lists
> and write them out to different files by share (not just every reserved
> bridge at once). Then we can identify a few social hubs in each affected
> country and make sure they always have a good handle on some new (and
> otherwise unknown) bridges.
>
> Having alternatives to the gmail distribution strategy is particularly
> important these days in places like Iran, where they've shown little
> hesitation in blocking gmail when things get rough. Right now your
> best bet if you can't reach bridges.tp.o or gmail is to show up to IRC
> and hope that I'm around and can give you one of the reserve bridge
> addresses. That doesn't scale.

What about an IRC bot? With the same subscription parameters as an
email subscription? In theory, we could place that in every IRC net.
The only problem I see is usability. People hardly are able to follow
directions for email subscriptions, how harder would it be for them to
punch in IRC commands in a query?

Another thought: Couldn't bridges themselves offer a https server on
port XYZ and hand out bridges that way? On each request, they could
query bridgedb and get some addresses under the same restrictions as
usual? I'm sure someone came up with that already and there's a good
reason why we don't want that.

> ---Part five--------------------------------------------------------
>
> Where are we going to go in the future?
>
> It's hard to say how the arms race will progress on the attacker side, so
> it's hard to predict how we'll need to adapt. But here are two directions
> to keep in mind.
>
> First, as the arms race picks up we're going to want to think harder about
> ways to isolate good users on long-term bridges. One of the promising
> directions from the Kaist groups was the idea of splitting users into
> two groups each epoch: a large group and a small group. Each group
> gets its own bridge. If the bridge for the small group ends up blocked,
> break the small group in half and repeat. If it doesn't end up blocked,
> all of those users are known good -- leave them with their bridge, and
> they'll all be fine. Now, this approach has some remaining challenges
> (for example, what if it takes a while before the bridge gets blocked),
> but the basic idea of "separate users onto bridges such that you can
> cluster good users by themselves on the long-term bridges" is a good goal.

Good idea. In addition, if we have that database of users you spoke
about above, we can also tag users with something like "trusted user"
and "not so trusted user", depending on user-parameters like 'duration
of subscription', 'percentage of bridges blocked after handing them
out to the user' etc.

Best,
Christian