Opened 7 years ago

Closed 5 years ago

#5485 closed task (not a bug)

Think about ways to give out non-blocked bridges without making it too easy to enumerate all bridges

Reported by: karsten Owned by: aagbsn
Priority: Very Low Milestone:
Component: Circumvention/BridgeDB Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

There are at least three approaches for giving out non-blocked bridges to users: a) exclude blocked bridges from results, b) replace blocked bridges with non-blocked once, or c) include blocked bridges in results and write "maybe blocked" next to them. We're currently doing a), but we should do c) to improve usability. There are variants of b), e.g., b1) Christian suggests to give out exactly one non-blocked bridge if otherwise we’d give out zero bridges and b2) Roger suggests to give out the first three non-blocked bridges in a fixed set of five bridges. One part of sponsor F deliverable 17 should be to discuss these alternatives and agree on one of them that shall be implemented.

Child Tickets

Change History (6)

comment:1 Changed 7 years ago by aagbsn

We have code that does a, and code that does c.

To my knowledge we are not doing a or c (on bridges.tpo).

It isn't clear to me what b means, but solutions (b1, b2) will be tricky to integrate with the current implementation of a.

I think we should do a, and figure out what rate of bridge-burning is acceptable. BridgeDB only knows a bridge is blocked when we tell it so; so we can control the rate (unblocked) bridges get exposed via this knob.

We should spend our time figuring out how to get lots more bridges, because at best all we can do is slow down our adversaries, not stop them forever.

Thoughts?

comment:2 Changed 7 years ago by aagbsn

Owner: set to aagbsn
Parent ID: #5484
Status: newassigned

Removing parent relationship to #5484.

BridgeDB excludes blocked bridges from results, and reduces the number of bridges in its response (determined by the number of available bridges the query returns. #6175)

Bridge reachability data would be handy in thinking about this problem.

comment:3 Changed 6 years ago by sysrqb

(I'll come back to this later :) )

Possibly related to #6396

comment:4 Changed 6 years ago by sysrqb

(This is actually unlikely related to #6396)

How are blocked bridges currently being determined? I know they're listed in a file that BridgeDB parses.

I think from a usability point of view, b) and c) aren't mutually exclusive. I'm not clear about how the "fixed set of five bridges" would be decided. Is it per /24? Per email address? I think b1 is a reasonable fall-back, if we can't find any that are unblocked.

In order of end-user expectation (I'm assuming here):
1) Three usable bridges
2) Three possibly reachable bridges, but note the ones that may be blocked
3) Inform the user there are no available bridges for their use
4) Three likely blocked bridges

comment:5 Changed 5 years ago by isis

Priority: normaltrivial

I'm inclined to close this, for now I'm marking as "trivial" priority.

comment:6 Changed 5 years ago by isis

Resolution: not a bug
Status: assignedclosed

I'm not sure what exactly I am supposed to do with this ticket, and it's been bitrotting for forever.

I'm closing it, but feel free to reopen for whatever reason!

Note: See TracTickets for help on using tickets.