Turn mail requests into ’subscriptions’

Turn mail requests into ’subscriptions’: People mail ’subscribe bridges’ to us, we put them in a database and send them bridges periodically. To not send mails to users that long have forgotten about their subscription, make them re-subscribe periodically by putting a ”Reply to this mail or you won’t get any more bridges” text somewhere in a mail we send them with fresh bridges

added bridgedb-email component::circumvention/bridgedb owner::isis priority::medium resolution::wontfix status::closed type::enhancement labels

Trac:
Component: Tor - Distribution to Tor - BridgeDB

Assigning as a child ticket to the project ticket that replaces the "BridgeDB Upgrades Phase 1" milestone.

Trac:
Parent: N/A to #4380 (moved)
Actualpoints: N/A to N/A
Points: N/A to N/A
Milestone: BridgeDB Upgrades Phase 1 to N/A

Trac:
Keywords: N/A deleted, SponsorL added

Is BridgeDB a good place to have a database of email addresses (more than it already is)? Would having a subscription system make it more of a target for an adversary?

Replying to sysrqb:

Is BridgeDB a good place to have a database of email addresses (more than it already is)?

Yes, I think so. Otherwise we have a separate place that has a database of email addresses, and we add some protocol for it to speak to bridgedb to learn what it should give out.

Would having a subscription system make it more of a target for an adversary?

Also yes.

Replying to phobos:

Turn mail requests into ’subscriptions’: People mail ’subscribe bridges’ to us, we put them in a database and send them bridges periodically.

We could get smarter about 'periodically' and only mail them when a threshold of the bridges they know about (based on what we've sent them) have gone away.

Without current bridge churn, that could be quite frequent. But all the more reason to do it.

Replying to arma:

Without current bridge churn, that could be quite frequent. But all the more reason to do it.

S/Without/With/

Replying to arma:

Replying to sysrqb:

Is BridgeDB a good place to have a database of email addresses (more than it already is)?

Yes, I think so. Otherwise we have a separate place that has a database of email addresses, and we add some protocol for it to speak to bridgedb to learn what it should give out.

My question was actually a misleading one (which you answered, thanks!). What I really should have asked was:

Should BridgeDB really be storing email addresses at all? There are ways that it can link requests from an email address without comparing the actual email addresses. However, by not storing the real email address, this makes it difficult to have a subscription-based system.

I guess this is another security vs usability issue :)

Note that these days, this ticket isn't really about adapting to censorship.

It was an idea from a time where the arms race was "change IP addresses quicker than the adversary can enumerate them". The arms race these days is "do some trick to be able to recognize bridges when they're used". This new arms race scales a lot better, and would result in this subscription approach basically sending you a mail saying "oops, no bridges left for you".

That doesn't make it totally pointless though -- it is still useful to send an automated follow-up when your current bridge addresses churn away naturally.

Trac:
Parent: #4380 (moved) to N/A

I am against the idea of sending plaintext subscription emails to users for several reasons.

1. I don't want a database of bridge users on the server. I would prefer not to have any information at all on BridgeDB's users. The SocialDistributor, a.k.a. rBridge, (see #7520 (moved)) would be a significantly safer way -- for the bridges, bridge users, and for me maintaining the BridgeDB server and service -- to implement automatic bridge retrieval.

2. In light of the recent revelations of XKEYSCORE targeting of BridgeDB and various torproject.org servers, I would prefer to send less emails. Not more. The idea now is "send only enough emails to get the user's Tor working, then encourage them to use the web interface".

3. As arma [comment:9 pointed out], we don't really churn bridges like we used to, so with this approach, all the bridge in the email hashring would likely eventually get emailed to everyone, and they'd have the entire hashring. (And due to point !#2 (closed), so would the NSA and several other intelligence agencies.)

Trac:
Owner: N/A to isis
Status: new to accepted
Cc: N/A to isis
Keywords: SponsorL deleted, bridgedb-email added

I'm closing as "wontfix". However, feel free to continue arguing for adding this feature, and I might listen if there's some new, compelling rationale.

Trac:
Type: task to enhancement
Resolution: N/A to wontfix
Status: accepted to closed

closed

mentioned in issue #4380 (moved)

mentioned in issue #7520 (moved)

mentioned in issue #7522 (moved)

moved to tpo/anti-censorship/bridgedb#1610 (closed)

mentioned in issue tpo/anti-censorship/bridgedb#7522 (closed)