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
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Linked items
0
Link issues together to show that they're related.
Learn more.
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?
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?
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.
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.
I am against the idea of sending plaintext subscription emails to users for several reasons.
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.
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/Ato isis Status: new to accepted Cc: N/Ato 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/Ato wontfix Status: accepted to closed