[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #7520 [BridgeDB]: Design and implement a social distributor for BridgeDB
#7520: Design and implement a social distributor for BridgeDB
-------------------------+--------------------------------------------------
Reporter: aagbsn | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: BridgeDB | Version:
Keywords: SponsorZ | Parent:
Points: | Actualpoints:
-------------------------+--------------------------------------------------
Comment(by asn):
Replying to [comment:10 sysrqb]:
> (I'll post more later, but for now...)
>
> After reading rBridge, Proximax, Kaleidoscope, Tor's blocking resistance
paper:
>
> some thoughts on a future system:
I also agree that cherry-picking features we like from all these schemes,
might be a good way to design a decent future BridgeDB. Adding some notes
on my own:
>
> - We will want multiple pools (possibly three, to start off: Automated
distribution, manual distribution, reserve)
> - Use of a credential system that awards users via allocation of credits
seems like a good idea
> - Awarding credits based on a bridges user-hours value seems like a good
idea
You mean based on bridge uptime (like the rBridge paper)? I also like this
idea.
> - We should try to add the "intrinsic risk" of a bridge into the
reputation calculations
> - Without the use of NIPK and OT, the BridgeDB operators MUST be trusted
Yeah, the threat model of BridgeDB will have to remain the same on this
matter.
I'd also like BridgeDB to have all those fancy rBridge cryptowan^Wfeatures
(ZKP/OT/etc.), but I really doubt we can implement them
efficiently/securely/in the next 5 years. I don't know a single widely
used application with oblivious transfer capabilities.
BTW, as far as the BridgeDB threat model goes, note that all these
reputation-based systems probably require BridgeDB to keep accounting logs
for users ("user X got bridges at TIMESTAMP", "user X invited user Y",
etc.). This is not the case with the current BridgeDB.
> - Reputation should not only be based on a social tree
> - We can use the bridge's geoip stats to *help* determine when the
bridge has been blocked within a zone
> - Bridges can be selected based on the user's identity rather than
location. (Really, how bad is random selection?)
> - Do we want to maintain an ID system (ex. Persona)?
By ID system, you mean some kind of identifier per user other than an IP
address? I guess we will need such a system, if we want to build the whole
invitation/credential-based idea.
Will the bridge selection happen based on the ID of the user, or the IP
address of the user? For example, Persona is based on a single email
address; will a user who creates multiple Persona IDs be able to get more
than a single bunch of bridges?
> - We need reachability testing...yesterday
> - When we determine (within a reasonably high probability) that a user
is a censor and/or in cohorts with one, only supply blocked bridges
> - GEO IP tracking by a bridge needs to distinguish between direct
connections and connections via PT
> - Can we use standalone PT nodes within a censored zone to obscure a
connection between a PT client and bridge?
> - How do we prevent sybils when we have registered users?
> - If we don't track the social graph, can we somehow factor it into our
calculations? (assuming a registered users may distribute her bridges to
friends)
> - Is the use of FQDN as bad an idea as I think it is?
FQDN? What do you mean?
> - Low plausible deniability that you don't have credentials if you use
Tor
>
What do you mean on this one?
Thanks for looking into this! I like where it's going.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7520#comment:12>
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