Opened 6 years ago

Closed 5 years ago

#10239 closed project (user disappeared)

Payment for bridges (and effects this would have)

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

Description

It is theoretically possible to accept payment (e.g. via bitcion) and use this payment to set up a custom bridge. This bridge would then only be shared with the identity that has made payment for it.

There are a few advantages to handing out bridges in this way:

  • This method of handing out bridges is non-exhaustive. The more bridge requests come in, the more bridges will be created.
  • The bridge will be shared with one identity exclusively and will be used at their discretion. It becomes more difficult to block the user of a bridge.
  • Bitcoin is being traded in Iran, China, etc.
  • No need to search for a working bridge every week. (I assume this is an issue?).

Some disadvantages:

  • This method is undemocratic. Privacy would become better for those with more resources.
  • This method centralizes power when it becomes the main method to get a bridge. In the event that this method becomes popular, more parties might implement this scheme. Some state might start to issue payed-for bridges (at a competitive rate) to a significant amount of users, and then kill all the bridges at their discretion. Not sure how much of an issue this would be in practice.

Possible side-effect:

  • More capital control. Although in the case of China, bitcoin will probably not be blocked.

Open questions:

  • Can it be automated to create unique bridges? (That are not all in the same block).

Child Tickets

Change History (4)

comment:1 in reply to:  description Changed 6 years ago by sysrqb

Replying to tmp:

There are a few advantages to handing out bridges in this way:

  • This method of handing out bridges is non-exhaustive. The more bridge requests come in, the more bridges will be created.

Non-exhaustive except for finding cheap hosting and adequate address space. #7207 might be potentially useful for this.

  • The bridge will be shared with one identity exclusively and will be used at their discretion. It becomes more difficult to block the user of a bridge.

Yes, but only in some circumstances. At this point only obfs3 seems to be successful with respect to blocking resistance (and scramblesuit, etc). In some places it only requires single use of a bridge for it to be detected and blocked, so user count isn't really a factor - not including the nefarious BridgeDB users.

  • Bitcoin is being traded in Iran, China, etc.
  • No need to search for a working bridge every week. (I assume this is an issue?).

Possibly, I think many bridges are stable, though. (I need to fix the stability tracking code, though.)

Some disadvantages:

  • This method is undemocratic. Privacy would become better for those with more resources.

I think it depends on how you define privacy. The user's anonymity will likely decrease because they will be the only user of that bridge, thus all traffic into and out of that bridge will be from a single user, not including traffic due to consensus/descriptor fetches.

  • This method centralizes power when it becomes the main method to get a bridge. In the event that this method becomes popular, more parties might implement this scheme. Some state might start to issue payed-for bridges (at a competitive rate) to a significant amount of users, and then kill all the bridges at their discretion. Not sure how much of an issue this would be in practice.

Users should only use providers that they trust, for some degree of trust. This is a potential problem, but it seems like the availability of the bridge is outside the control of the user.

Open questions:

  • Can it be automated to create unique bridges? (That are not all in the same block).

Someone just has to spend the time to write it. My main question is: what is the appeal of this? I've heard there is a market for a system like this, but if bridgedb provides a sufficient number of unblocked bridges then is there a need? (I'm not saying it does, but ideally it should). If this is true, then would a system such as this mainly benefit the providers rather than the users?

comment:2 Changed 6 years ago by tmp

I viewed this video some time ago: "How governments have tried to block Tor [28C3]" https://www.youtube.com/watch?v=GwMr8Xl7JMQ (Flash, sorry)

From what I understood, there are some 'sensitive' times when many Chinese state people are breaking captcha's etc, to block as many bridges as possible.
So it sounds like there might be quite a population that could benefit from this (when obfs3 is used and the only way to block is to request a bridge).
There are only so many bridges that are donated when you would like to have a million people using these. That can be improved.

So for your main question "What is the appeal of this?":
Suppose obfs3 or 4 won't be distinguishable from ssl. The only mechanism that is left to block these bridges is to request as many as possible, and filter them. However, every request spawns a new bridge and will therefore not block anything.

Will it benefit providers? Well, if it works at scale then there should be competition (and it is a competitive industry), so it won't fill their pockets. It it might be profitable, who knows.

So the main question is whether there is sufficient demand for it. Maybe that someone with on-the-ground knowledge can tell us.

I just wanted to put this out there as a possibility.

Version 1, edited 6 years ago by tmp (previous) (next) (diff)

comment:3 Changed 6 years ago by isis

Cc: isis added
Priority: normaltrivial

comment:4 Changed 5 years ago by isis

Resolution: user disappeared
Status: newclosed

I don't hear anyone hollering. I'm closing this ticket; feel free to reopen if you wish.

Note: See TracTickets for help on using tickets.