Re: [tor-bugs] #7550 [BridgeDB]: BridgeDB email responder is not interactive

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#7550: BridgeDB email responder is not interactive
----------------------+-----------------------------------------------------
 Reporter:  aagbsn    |          Owner:                   
     Type:  defect    |         Status:  needs_information
 Priority:  normal    |      Milestone:                   
Component:  BridgeDB  |        Version:                   
 Keywords:            |         Parent:                   
   Points:            |   Actualpoints:                   
----------------------+-----------------------------------------------------

Comment(by asn):

 Replying to [comment:7 sysrqb]:
 > Replying to [comment:6 aagbsn]:
 > > Replying to [comment:5 sysrqb]:
 > > > Replying to [comment:4 asn]:
 > > > > Also, what is the point of rate limiting in BridgeDB? A user with
 a single IP shouldn't be able to get more than a bunch of bridges anyway,
 right?
 > > >
 > > > Right, maybe aagbsn (or arma, nickm, Karsten) have a better answer,
 because within a single time period we should return the same bridges.
 That being said, maybe the rate limiting is to reduce the number of emails
 bridgedb needs to process by disincentivizing users spamming it? I don't
 see a reason for bridgedb to respond to multiple emails within the time
 period if it will be responding with the same bridges each time.
 > >
 > > This. We also see a barrage of requests over HTTPS.
 > >
 > > Sadly, the attackers/scrapers simply register "creative" names
 (somename0001@xxxxxxxxx, somename0002@xxxxxxxxx .. somename0020@xxxxxxxxx)
 and keep at it.
 > >
 > > Any ideas? Text CAPTCHA? ASCII-art cats?
 > >
 > > --Aaron
 >
 > Hrm, I do like the ASCII-art catz idea, that might do the trick.
 >

 I'm still not sold that rate-limiting is necessary for BridgeDB to be able
 to process mails. I would have thought that a _huge_ amount of mails is
 needed to bloat a modern computer (especially without expensive crypto
 happening during processing). But there was probably a reason that the
 rate-limiting was introduced in the first place, so I guess it's fine.

 > OTOH, I think if we make some progress with #7520 (however it's
 designed) and require some sort of earned token/credit, then I think this
 is a step in the right direction. If we assume accounts for this social
 distributor are a limited resource, then (short of compromised
 account/impersonation/malicious users) we'll be able to drop all
 unauthenticated requests and spamming/abuse will be linkable. Originally,
 restricting requests to specific domains *was* an okay solution, but the
 justification really is not as applicable anymore, afaict. I feel like
 this is veering OT for this ticket, however. (sorry)
 >
 > So, thoughts? More interactive email responder is good/bad? (choose one)

 Like, aagbsn, I also see #7520 as a long-term project (my guess is that it
 won't be deployed in the next 6 months).

 I'd say that the interactive email responder might be easy-ish to
 implement, and it will greatly improve the experience of its users, so
 it's probably worth pursuing IMO.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7550#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs