[tor-talk] Why does requesting for bridges by email require a Yahoo or Gmail address?

[isis]

Matthew Finkel transcribed 5.0K bytes:
> On Sun, Jul 27, 2014 at 02:09:52AM -0400, The Caped Wonderwoman wrote:
> > The difficulty of obtaining a Riseup account may be prohibitive for a lot
> > of people, especially if they need a bridge quickly for whatever
> > reason. Anecdotally, I requested one under a different identity over a
> > week ago and have yet to hear back. In some situations, that's an
> > eternity, and while I'm sure it would go more quickly with an invite, that
> > presupposes knowing someone who has one to offer.
> 
> An important point, that I don't think was mentioned previously, is that
> Riseup cannot be a substitute for gmail and yahoo mail. The latter
> are two service providers which place very few restrictions on the
> users. Riseup, on the other hand, only accepts people who either
> honestly have similar political and social ideals or they lie. Granted,
> if an adversary is trying to surveil or track users then they probably
> won't have any problem with deception and lying during the application
> process. However, this does raise the bar for entry into retrieving
> the specific bridges which are only distributed to riseup users.
> 
> > As a side note, I'm always slightly surprised by how few mentions Zoho
> > gets. They're nowhere near perfect, but compared to Google, Yahoo, and
> > such, at least they don't mine your email for targeted advertising, they
> > have a business model where the user is the customer, and their privacy
> > policy is readable and honest ("we'll log your IP and fingerprint your
> > browser to see where you go and what you do on our site, but we won't read
> > your mail or follow you around the
> > Internet"). http://www.zoho.com/privacy.html
> 
> I hadn't heard of them. The account creation process seems simple,
> sadly the captchas are not very difficult, either. I'm not saying
> they're not usable, only that this seems like an easy target for
> powerful adversaries. They also have offices in the US and China,
> which could cause other problems.

Nor had I, but they look and feel like a rebranded Google, and I appear to
have caused them a series of server errors when I attempted to make an account
just now, so I'm also not very impressed with their rebrading/coding skills.

> Before we start whitelisting many new email providers, we should
> define exactly which criterion we are looking for and what
> percentage of the bridges we should allocate to the provider based
> on which criteria they meet. We need a system that is usable by the
> masses but also one that doesn't render the majority of the system
> useless because someone/something was able to enumerate most of the
> bridges.

Interesting. I like this idea. The requirements that I listed earlier for an
email provider to be acceptable were just requirements, and obviously don't
take into account features which are better for users.

Do you have a suggestion for some point values to assign to certain desirable
features?

Should we take off points if something is missing? I.e. if ProviderX doesn't
have DKIM, they get penalised -20 HP, and so pretty much no matter what they
have 0 bridges in their hashring until they fix DKIM.

I kind of don't want to do all the research for all this, nor check up on
ProviderX a year down the line when it appears that some feature/requirement
of theirs is borked. What if there was, on https://bridges.torproject.org,
some sort of "Don't see an email provider that you think is appropriate?"
link, which goes to a wiki page where people can say, e.g. "I checked Zoho and
they appear to get a score of 17 out of 25 in this arbitrary point system, so
they should be supported."

-- 
 ♥Ⓐ isis agora lovecruft
_________________________________________________________
GPG: 4096R/A3ADB67A2CDB8B35
Current Keys: https://blog.patternsinthevoid.net/isis.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1154 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20140727/b556a2ca/attachment-0001.sig>