Jacob Applebaum made another remark about editing Wikipedia via tor this morning. Since it's been a couple months since the last tor bashing thread, I wanted to throw out a slightly more modest proposal to see what people think.
This is getting some interest from a few people: https://zyan.scripts.mit.edu/blog/rate-limiting-anonymous-accounts/
Which lays out a way for twitter to use an external, trusted identity provider to verify identifies / throttle requested, and then create an account in a way that neither twitter or the identity provider can link the account to the request (as long as you mitigate timing attacks).
What if we turn this around a bit and let the wiki establish identity and throttle, and open up an editing proxy that is accessible via tor which consumes the identities?
Basically: * Established wiki user who wants to use tor makes a blinded request (maybe public, maybe a private queue for some group with appropriate rights) for a tor-based account creation token. * User gets that blinded token signed if they're in good standing, and are limited to some number (3 total, not less than 6 months since the last request, or something like that). * User creates an account on the editing proxy via tor, and gives their unblinded token to the proxy. The proxy creates an account for them, and allows edits via OAuth token using that new account.
If the use turns it to be a spammer: * The anonymous account can be blocked like a normal account. The user is throttled on how many requests for accounts they can make. * If the proxy generates to much spam, a steward can revoke the key, and we all go home to think up the next experiment.
To make this happen, we need: * a light editing proxy (I already have a couple of those as demo OAuth apps) which is run by a *non-wmf* entity * something for normal users to download and run that does the blinding for them * work out how to address timing attacks if the volume of requestors is low enough that we can correlate request to first edit by the proxy.
Anyone interested in helping?
Is this conservative enough for those worried about the flood of tor spam, while being simple enough that the average editor would be able to understand and go through the process?
Chris Steipp schreef op 2015/03/10 om 7:23:
Jacob Applebaum made another remark about editing Wikipedia via tor this morning. Since it's been a couple months since the last tor bashing thread, I wanted to throw out a slightly more modest proposal to see what people think.
The easiest way to prevent a series of Tor bashing threads is to not make Tor promoting threads. At least for English Wikipedia, there is no reason now or in the conceivable future to permit, much less endorse or formalise, editing via Tor.
KWW
On Tue, Mar 10, 2015 at 7:45 AM, Kevin Wayne Williams < kwwilliams@kwwilliams.com> wrote:
Chris Steipp schreef op 2015/03/10 om 7:23:
Jacob Applebaum made another remark about editing Wikipedia via tor this morning. Since it's been a couple months since the last tor bashing thread, I wanted to throw out a slightly more modest proposal to see what people think.
The easiest way to prevent a series of Tor bashing threads is to not make Tor promoting threads. At least for English Wikipedia, there is no reason now or in the conceivable future to permit, much less endorse or formalise, editing via Tor.
I believe there is a strong reason for it.
Even if you use https for every connection to Wikipedia, traffic analysis currently makes finding out what you're reading fairly easy. From a risk perspective, if a user wants to edit Wikipedia on a subject and from a location that could endanger themselves, I would much prefer they edit via tor than rely on the WMF to protect their identity. We spend a lot of effort protecting the privacy of our users, but all it would take is compromising the right server in our cluster, and correlating which IP is editing as which user becomes very easy. Promoting the user of Tor lets us push some of the risk onto the Tor team, who are both experts in this and have a strong motivation to make it work correctly.
So I think there is both a responsibility and a benefit (to the WMF) in allowing editing via Tor.
On 10/03/15 16:00, Chris Steipp wrote:
On Tue, Mar 10, 2015 at 7:45 AM, Kevin Wayne Williams < kwwilliams@kwwilliams.com> wrote:
Chris Steipp schreef op 2015/03/10 om 7:23:
Jacob Applebaum made another remark about editing Wikipedia via tor this morning. Since it's been a couple months since the last tor bashing thread, I wanted to throw out a slightly more modest proposal to see what people think.
The easiest way to prevent a series of Tor bashing threads is to not make Tor promoting threads. At least for English Wikipedia, there is no reason now or in the conceivable future to permit, much less endorse or formalise, editing via Tor.
I believe there is a strong reason for it.
Even if you use https for every connection to Wikipedia, traffic analysis currently makes finding out what you're reading fairly easy. From a risk perspective, if a user wants to edit Wikipedia on a subject and from a location that could endanger themselves, I would much prefer they edit via tor than rely on the WMF to protect their identity. We spend a lot of effort protecting the privacy of our users, but all it would take is compromising the right server in our cluster, and correlating which IP is editing as which user becomes very easy. Promoting the user of Tor lets us push some of the risk onto the Tor team, who are both experts in this and have a strong motivation to make it work correctly.
So I think there is both a responsibility and a benefit (to the WMF) in allowing editing via Tor.
Aye, even if people don't like something, that doesn't mean it should be avoided. For whatever it's worth, personally I think this sounds pretty awesome, and even if it doesn't work, it would be worth the risk to try it, because if it does the benefit could be enormous.
-I
Chris Steipp schreef op 2015/03/10 om 9:00:
On Tue, Mar 10, 2015 at 7:45 AM, Kevin Wayne Williams < kwwilliams@kwwilliams.com> wrote:
Chris Steipp schreef op 2015/03/10 om 7:23:
Jacob Applebaum made another remark about editing Wikipedia via tor this morning. Since it's been a couple months since the last tor bashing thread, I wanted to throw out a slightly more modest proposal to see what people think.
The easiest way to prevent a series of Tor bashing threads is to not make Tor promoting threads. At least for English Wikipedia, there is no reason now or in the conceivable future to permit, much less endorse or formalise, editing via Tor.
I believe there is a strong reason for it.
Even if you use https for every connection to Wikipedia, traffic analysis currently makes finding out what you're reading fairly easy. From a risk perspective, if a user wants to edit Wikipedia on a subject and from a location that could endanger themselves, I would much prefer they edit via tor than rely on the WMF to protect their identity.
Wikipedia isn't worth endangering oneself over, and we shouldn't encourage the delusion that any technical measure will change that. KWW
On Tue, Mar 10, 2015 at 5:06 PM, Kevin Wayne Williams < kwwilliams@kwwilliams.com> wrote:
Wikipedia isn't worth endangering oneself over, and we shouldn't encourage the delusion that any technical measure will change that.
How do you know today what topics are going to endanger you next week?
Hi Chris,
I like the idea in general, in particular the fact that only "established" editors can ask for the tokens. What I don't get is why this proxy should be run by someone that is not the WMF, given - I guess - it would be exposed as a TOR hidden service, which will mask effectively the user IP from us, and will secure his communication from snooping by exit node managers, and so on.
I guess the righteously traffic on such a proxy would be so low (as getting a token is /not/ going to be automated/immediate even for logged in users) that it could work without using up a lot of resources.
Cheers,
Giuseppe
Unless the status quo has changed recently, or there was some cryptographic achievement that provides a solution not already provided, I doubt this thread is going to make any progress beyond reiteration of the same back-and-forth that happens every time this thread pops up.
(Also, I don’t think relying on SMS verification is going to provide much faith for users competing against governments to hide their identity.)
-- Tyler Romeo 0x405D34A7C86B42DF
A few questions on this:
- So, this would result in the creation of a new account, correct? If so, most of the security is lost by the enwiki policy of requiring linking to one's other accounts, and if the user edited in the same topic area as their other account, they're likely to be blocked for socking. (This is a social limitation on the idea, not a technical one.) - Why would we permit more than one account? - It's not usually experienced editors who seem to have an issue on English projects; most of the huffing and puffing about Tor seems to come from people who are not currently registered/experienced editors, so the primary "market" is a group of people who wouldn't meet the proposed criteria. - On reading this over carefully, it sounds as though you're proposing what is essentially a highly technical IPBE process in which there is even less control than the project has now, particularly in the ability to address socking and POV/COI editing. Am I missing something?
Risker/Anne
On 10 March 2015 at 13:16, Giuseppe Lavagetto glavagetto@wikimedia.org wrote:
Hi Chris,
I like the idea in general, in particular the fact that only "established" editors can ask for the tokens. What I don't get is why this proxy should be run by someone that is not the WMF, given - I guess - it would be exposed as a TOR hidden service, which will mask effectively the user IP from us, and will secure his communication from snooping by exit node managers, and so on.
I guess the righteously traffic on such a proxy would be so low (as getting a token is /not/ going to be automated/immediate even for logged in users) that it could work without using up a lot of resources.
Cheers,
Giuseppe
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Mar 10, 2015 at 10:39 AM, Risker risker.wp@gmail.com wrote:
A few questions on this:
- So, this would result in the creation of a new account, correct? If
so, most of the security is lost by the enwiki policy of requiring linking to one's other accounts, and if the user edited in the same topic area as their other account, they're likely to be blocked for socking. (This is a social limitation on the idea, not a technical one.)
Registering a pseudonym through this process implies that you are an existing editor (we could even limit the process to only one pseudonym per existing account, so you know there's a 1-1 mapping), just not linking to which one you are. Do you think enwiki be open to considering that?
- Why would we permit more than one account?
I was originally thinking that if something happened (forgotten password, etc.), you could start over. But not a hard requirement.
- It's not usually experienced editors who seem to have an issue on
English projects; most of the huffing and puffing about Tor seems to come from people who are not currently registered/experienced editors, so the primary "market" is a group of people who wouldn't meet the proposed criteria.
There may not be enough intersection between users who we have some trust in and those who want to edit via Tor. I'm hopeful that we can define "established" to be some group that is large enough that it will include productive editors who also should use Tor, but small enough to preclude spammers. I'm assuming if we start with some guideline, then we can adjust up (if there's too much spam) or down (if there aren't enough users) depending on the results.
- On reading this over carefully, it sounds as though you're proposing
what is essentially a highly technical IPBE process in which there is even less control than the project has now, particularly in the ability to address socking and POV/COI editing. Am I missing something?
In a way it is, but there are couple advantages over IPBE as I see it: * Neither the WMF nor checkusers can correlate the identities, whereas with IPBE, it's possible that a checkuser can still see the IP that created the account requesting the IPBE. This is less control, but also less risk if the wmf/checkuser is coerced into revealing that information. * Hopefully it will be a less manual process, since the only manual (which could be automated if the right heuristics were found) step is confirming that the requesting user is "established". There's no further rights that have to be granted and maintained.
It also give slightly more control in that: * We're not giving out the IPBE right * The whole system can be blocked (hopefully temporarily) with a single block or revoking the OAuth key, if there is ever a sudden flood of spam
Admittedly, we could do all of this (except making the identities unlinkable) by having an edit-via-tor right that is different from IPBE, but the unlikability I think is important for our users.
Risker/Anne
On 10 March 2015 at 13:16, Giuseppe Lavagetto glavagetto@wikimedia.org wrote:
Hi Chris,
I like the idea in general, in particular the fact that only "established" editors can ask for the tokens. What I don't get is why this proxy should be run by someone that is not the WMF, given - I guess - it would be exposed as a TOR hidden service, which will mask effectively the user IP from us, and will secure his communication from snooping by exit node managers, and so on.
I guess the righteously traffic on such a proxy would be so low (as getting a token is /not/ going to be automated/immediate even for logged in users) that it could work without using up a lot of resources.
Cheers,
Giuseppe
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Thanks for your responses, Chris. Regardless of what processes are proposed, I suspect that the strongest objections will be socially based rather than technically based. Bawolff has a valid point, that success on a smaller wiki may have an effect on the social perception of the use of Tor on enwiki - but if it is started on another wiki, please ensure that there is actual community agreement and that there are sufficient administrators who are willing and able to promptly address any problems. We may have 700 wikis, but really only about 50-60 of them have sufficient daily activity and editorial community size to be able to manage any problems that might arise from this.
To my experience, the majority of experienced editors who are asking for IPBE or something similar tend to be editing through VPNs that are hard-blocked for various reasons (most commonly spamming and/or heavy-duty vandalism - and if it's spamming, it's usually blocked at the global level). There are some exceptions - particularly related to users working from countries where there are entirely valid security concerns (we could probably all recite the list). And IPBE does permit editing through Tor now. Whether continuing with IPBE or providing an alternative, the user would still have to persuade the same administrators/community members of the legitimacy of their request.
I cannot speak for the entire enwiki community (let alone any other community) about whether or not there would be acceptance for the idea of a user having two unlinked accounts, one "regular" account and one "Tor" one - given my role as a Checkuser I'm exposed to a much higher frequency of socking complaints than most community members - but given it's been darn hard to keep the community from flat-out banning multiple unlined accounts, I have my doubts it will be greeted with open arms, even if it "works" on other wikis. (Pretty much the only exception that has received support is "editing in a high risk topic area", so there *may* be some support). Unfortunately, there's been plenty of history on enwiki of experienced users having multiple accounts that were used inappropriately, including administrator accounts, so that raises the bar even higher.
Also....I'm a little unclear about something. If a "Tor-enabled" account creates new accounts, will those accounts be able to edit through Tor, too?
Risker/Anne
On 10 March 2015 at 14:33, Chris Steipp csteipp@wikimedia.org wrote:
On Tue, Mar 10, 2015 at 10:39 AM, Risker risker.wp@gmail.com wrote:
A few questions on this:
- So, this would result in the creation of a new account, correct? If
so, most of the security is lost by the enwiki policy of requiring linking to one's other accounts, and if the user edited in the same topic area as their other account, they're likely to be blocked for socking. (This is a social limitation on the idea, not a technical one.)
Registering a pseudonym through this process implies that you are an existing editor (we could even limit the process to only one pseudonym per existing account, so you know there's a 1-1 mapping), just not linking to which one you are. Do you think enwiki be open to considering that?
- Why would we permit more than one account?
I was originally thinking that if something happened (forgotten password, etc.), you could start over. But not a hard requirement.
- It's not usually experienced editors who seem to have an issue on
English projects; most of the huffing and puffing about Tor seems to come from people who are not currently registered/experienced editors, so
the
primary "market" is a group of people who wouldn't meet the proposed criteria.
There may not be enough intersection between users who we have some trust in and those who want to edit via Tor. I'm hopeful that we can define "established" to be some group that is large enough that it will include productive editors who also should use Tor, but small enough to preclude spammers. I'm assuming if we start with some guideline, then we can adjust up (if there's too much spam) or down (if there aren't enough users) depending on the results.
- On reading this over carefully, it sounds as though you're proposing
what is essentially a highly technical IPBE process in which there is even less control than the project has now, particularly in the ability to address socking and POV/COI editing. Am I missing something?
In a way it is, but there are couple advantages over IPBE as I see it:
- Neither the WMF nor checkusers can correlate the identities, whereas with
IPBE, it's possible that a checkuser can still see the IP that created the account requesting the IPBE. This is less control, but also less risk if the wmf/checkuser is coerced into revealing that information.
- Hopefully it will be a less manual process, since the only manual (which
could be automated if the right heuristics were found) step is confirming that the requesting user is "established". There's no further rights that have to be granted and maintained.
It also give slightly more control in that:
- We're not giving out the IPBE right
- The whole system can be blocked (hopefully temporarily) with a single
block or revoking the OAuth key, if there is ever a sudden flood of spam
Admittedly, we could do all of this (except making the identities unlinkable) by having an edit-via-tor right that is different from IPBE, but the unlikability I think is important for our users.
Risker/Anne
On 10 March 2015 at 13:16, Giuseppe Lavagetto glavagetto@wikimedia.org wrote:
Hi Chris,
I like the idea in general, in particular the fact that only "established" editors can ask for the tokens. What I don't get is why this proxy should be run by someone that is not the WMF, given - I guess - it would be exposed as a TOR hidden service, which will mask effectively the user IP from us, and will secure his communication from snooping by exit node managers, and so on.
I guess the righteously traffic on such a proxy would be so low (as getting a token is /not/ going to be automated/immediate even for logged in users) that it could work without using up a lot of resources.
Cheers,
Giuseppe
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mar 10, 2015 12:05 PM, "Risker" risker.wp@gmail.com wrote:
Thanks for your responses, Chris. Regardless of what processes are proposed, I suspect that the strongest objections will be socially based rather than technically based. Bawolff has a valid point, that success on a smaller wiki may have an effect on the social perception of the use of Tor on enwiki - but if it is started on another wiki, please ensure that there is actual community agreement and that there are sufficient administrators who are willing and able to promptly address any problems. We may have 700 wikis, but really only about 50-60 of them have sufficient daily activity and editorial community size to be able to manage any problems that might arise from this.
To my experience, the majority of experienced editors who are asking for IPBE or something similar tend to be editing through VPNs that are hard-blocked for various reasons (most commonly spamming and/or heavy-duty vandalism - and if it's spamming, it's usually blocked at the global level). There are some exceptions - particularly related to users working from countries where there are entirely valid security concerns (we could probably all recite the list). And IPBE does permit editing through Tor now. Whether continuing with IPBE or providing an alternative, the user would still have to persuade the same administrators/community members of the legitimacy of their request.
I cannot speak for the entire enwiki community (let alone any other community) about whether or not there would be acceptance for the idea of
a
user having two unlinked accounts, one "regular" account and one "Tor" one
- given my role as a Checkuser I'm exposed to a much higher frequency of
socking complaints than most community members - but given it's been darn hard to keep the community from flat-out banning multiple unlined
accounts,
I have my doubts it will be greeted with open arms, even if it "works" on other wikis. (Pretty much the only exception that has received support is "editing in a high risk topic area", so there *may* be some support). Unfortunately, there's been plenty of history on enwiki of experienced users having multiple accounts that were used inappropriately, including administrator accounts, so that raises the bar even higher.
Also....I'm a little unclear about something. If a "Tor-enabled" account creates new accounts, will those accounts be able to edit through Tor, too?
The account creation would come from the proxy, so the wiki would have to trust that the proxy is only handing out accounts to users who have been
Risker/Anne
On 10 March 2015 at 14:33, Chris Steipp csteipp@wikimedia.org wrote:
On Tue, Mar 10, 2015 at 10:39 AM, Risker risker.wp@gmail.com wrote:
A few questions on this:
- So, this would result in the creation of a new account,
correct? If
so, most of the security is lost by the enwiki policy of requiring linking to one's other accounts, and if the user edited in the same topic
area
as their other account, they're likely to be blocked for socking.
(This
is a social limitation on the idea, not a technical one.)
Registering a pseudonym through this process implies that you are an existing editor (we could even limit the process to only one pseudonym
per
existing account, so you know there's a 1-1 mapping), just not linking
to
which one you are. Do you think enwiki be open to considering that?
- Why would we permit more than one account?
I was originally thinking that if something happened (forgotten
password,
etc.), you could start over. But not a hard requirement.
- It's not usually experienced editors who seem to have an issue on
English projects; most of the huffing and puffing about Tor seems
to
come from people who are not currently registered/experienced editors,
so
the
primary "market" is a group of people who wouldn't meet the
proposed
criteria.
There may not be enough intersection between users who we have some
trust
in and those who want to edit via Tor. I'm hopeful that we can define "established" to be some group that is large enough that it will include productive editors who also should use Tor, but small enough to preclude spammers. I'm assuming if we start with some guideline, then we can
adjust
up (if there's too much spam) or down (if there aren't enough users) depending on the results.
- On reading this over carefully, it sounds as though you're
proposing
what is essentially a highly technical IPBE process in which there
is
even less control than the project has now, particularly in the ability
to
address socking and POV/COI editing. Am I missing something?
In a way it is, but there are couple advantages over IPBE as I see it:
- Neither the WMF nor checkusers can correlate the identities, whereas
with
IPBE, it's possible that a checkuser can still see the IP that created
the
account requesting the IPBE. This is less control, but also less risk if the wmf/checkuser is coerced into revealing that information.
- Hopefully it will be a less manual process, since the only manual
(which
could be automated if the right heuristics were found) step is
confirming
that the requesting user is "established". There's no further rights
that
have to be granted and maintained.
It also give slightly more control in that:
- We're not giving out the IPBE right
- The whole system can be blocked (hopefully temporarily) with a single
block or revoking the OAuth key, if there is ever a sudden flood of spam
Admittedly, we could do all of this (except making the identities unlinkable) by having an edit-via-tor right that is different from IPBE, but the unlikability I think is important for our users.
Risker/Anne
On 10 March 2015 at 13:16, Giuseppe Lavagetto <
glavagetto@wikimedia.org>
wrote:
Hi Chris,
I like the idea in general, in particular the fact that only "established" editors can ask for the tokens. What I don't get is
why
this proxy should be run by someone that is not the WMF, given - I guess - it would be exposed as a TOR hidden service, which will mask effectively the user IP from us, and will secure his communication from snooping by exit node managers, and so on.
I guess the righteously traffic on such a proxy would be so low (as getting a token is /not/ going to be automated/immediate even for logged in users) that it could work without using up a lot of resources.
Cheers,
Giuseppe
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
<snip> > > Also....I'm a little unclear about something. If a "Tor-enabled" account > creates new accounts, will those accounts be able to edit through Tor, > too?
The account creation would come from the proxy, so the wiki would have to trust that the proxy is only handing out accounts to users who have been
Sorry Chris, I seem to have been unclear. For the purpose of responding
to this, let's call the account created by the third party the "Special Account". What I wanted to verify was whether or not child accounts created by the Special Account would also be conferred with the privileges of the Special Account (i.e., the ability to edit through Tor) or if they would be treated as any other newly created account. Remember that all autoconfirmed accounts can create child accounts (I believe on enwiki it is throttled to 5 accounts per day, absent special permissions).
To summarize the proposal as I understand it:
- In addition to the existing process for experienced editors to obtain IPBE, which may vary from project to project, they could also request the creation of a new account, unlinked to their existing accounts, that will have the ability to edit viaTor. - The community will develop the process for approving which accounts will have this ability. When granted, the user will be given a token - The user will take the token to a third party which will create for them a new account that has the requisite permissions to edit via Tor - The new, unlinked account will edit Wikipedia in the same manner as a regular user, subject to the same policies - There will be a process by which the token can be "broken" or removed from the account (still to be determined)
In other words, the difference between the existing process and the proposed process is the addition of the third party and the deliberate separation of the two accounts. (I'm trying to put this into plain language so that it can be explained to a broader audience on a project.)
Do I have this right?
Risker/Anne
On Tue, Mar 10, 2015 at 2:58 PM, Risker risker.wp@gmail.com wrote:
<snip> > > Also....I'm a little unclear about something. If a "Tor-enabled"
account
creates new accounts, will those accounts be able to edit through Tor, too?
The account creation would come from the proxy, so the wiki would have to trust that the proxy is only handing out accounts to users who have been
Sorry about that, meant to hit save instead of send.
What I was going to say is that no, there shouldn't be a way for the "Special Account" to even create child accounts through Tor. We can limit that via OAuth, and we'll also have to trust the proxy to behave correctly. If it looked like the "Special Accounts" were creating child accounts through the proxy, I think that would be a reason to block the proxy.
I think we had different ideas about how the user would edit, which I've addressed below. Happy to clarify if that doesn't make sense.
Sorry Chris, I seem to have been unclear. For the purpose of responding
to this, let's call the account created by the third party the "Special Account". What I wanted to verify was whether or not child accounts created by the Special Account would also be conferred with the privileges of the Special Account (i.e., the ability to edit through Tor) or if they would be treated as any other newly created account. Remember that all autoconfirmed accounts can create child accounts (I believe on enwiki it is throttled to 5 accounts per day, absent special permissions).
To summarize the proposal as I understand it:
- In addition to the existing process for experienced editors to obtain
IPBE, which may vary from project to project, they could also request the creation of a new account, unlinked to their existing accounts, that will have the ability to edit viaTor.
- The community will develop the process for approving which accounts
will have this ability. When granted, the user will be given a token
- The user will take the token to a third party which will create for
them a new account that has the requisite permissions to edit via Tor
- The new, unlinked account will edit Wikipedia in the same manner as a
regular user, subject to the same policies
- There will be a process by which the token can be "broken" or removed
from the account (still to be determined)
I'm actually envisioning that the user would edit through the third party's proxy (via OAuth, linked to the new, "Special Account"), so no special permissions are needed by the "Special Account", and a standard block on that username can prevent them from editing. Additionally, revoking the OAuth token of the proxy itself would stop all editing by this process, so there's a quick way to "pull the plug" if it looks like the edits are predominantly unproductive.
In other words, the difference between the existing process and the proposed process is the addition of the third party and the deliberate separation of the two accounts. (I'm trying to put this into plain language so that it can be explained to a broader audience on a project.)
Do I have this right?
Almost! The accounts are deliberately separated so they can't be linked, like you said. My proposal goes a little further by also restricting what the accounts can do via this third-party proxy. For example, the proxy could run each edit through the abuse filters, or another spam-scoring service, before it even submits the edit, if we want to try and push spam detection further up stream. It could have it's own rate limits, and refuse to service users it feels might be be seen as spammers and could get the whole system shut down.
If the user tries to edit using the "Special Account" directly via Tor (skipping the proxy), Torblock will correctly prevent them from doing anything, just like it currently does.
Thanks, Chris. But if the account is obviously not a normal account, I'd suspect that this special kind of user account would quickly become very obvious to those who snoop and would actually increase the level of scrutiny on the account, both internally and externally. I'm not really all that sure it's an overall improvement in safety.
Risker/Anne
On 10 March 2015 at 20:40, Chris Steipp csteipp@wikimedia.org wrote:
On Tue, Mar 10, 2015 at 2:58 PM, Risker risker.wp@gmail.com wrote:
<snip> > > Also....I'm a little unclear about something. If a "Tor-enabled"
account
creates new accounts, will those accounts be able to edit through
Tor,
too?
The account creation would come from the proxy, so the wiki would have
to
trust that the proxy is only handing out accounts to users who have
been
Sorry about that, meant to hit save instead of send.
What I was going to say is that no, there shouldn't be a way for the "Special Account" to even create child accounts through Tor. We can limit that via OAuth, and we'll also have to trust the proxy to behave correctly. If it looked like the "Special Accounts" were creating child accounts through the proxy, I think that would be a reason to block the proxy.
I think we had different ideas about how the user would edit, which I've addressed below. Happy to clarify if that doesn't make sense.
Sorry Chris, I seem to have been unclear. For the purpose of
responding
to this, let's call the account created by the third party the "Special Account". What I wanted to verify was whether or not child accounts created by the Special Account would also be conferred with the
privileges
of the Special Account (i.e., the ability to edit through Tor) or if they would be treated as any other newly created account. Remember that all autoconfirmed accounts can create child accounts (I believe on enwiki it
is
throttled to 5 accounts per day, absent special permissions).
To summarize the proposal as I understand it:
- In addition to the existing process for experienced editors to
obtain
IPBE, which may vary from project to project, they could also request the creation of a new account, unlinked to their existing accounts, that will have the ability to edit viaTor.
- The community will develop the process for approving which accounts
will have this ability. When granted, the user will be given a token
- The user will take the token to a third party which will create for
them a new account that has the requisite permissions to edit via Tor
- The new, unlinked account will edit Wikipedia in the same manner as a
regular user, subject to the same policies
- There will be a process by which the token can be "broken" or
removed
from the account (still to be determined)
I'm actually envisioning that the user would edit through the third party's proxy (via OAuth, linked to the new, "Special Account"), so no special permissions are needed by the "Special Account", and a standard block on that username can prevent them from editing. Additionally, revoking the OAuth token of the proxy itself would stop all editing by this process, so there's a quick way to "pull the plug" if it looks like the edits are predominantly unproductive.
In other words, the difference between the existing process and the proposed process is the addition of the third party and the deliberate separation of the two accounts. (I'm trying to put this into plain language so that it can be explained to a broader audience on a project.)
Do I have this right?
Almost! The accounts are deliberately separated so they can't be linked, like you said. My proposal goes a little further by also restricting what the accounts can do via this third-party proxy. For example, the proxy could run each edit through the abuse filters, or another spam-scoring service, before it even submits the edit, if we want to try and push spam detection further up stream. It could have it's own rate limits, and refuse to service users it feels might be be seen as spammers and could get the whole system shut down.
If the user tries to edit using the "Special Account" directly via Tor (skipping the proxy), Torblock will correctly prevent them from doing anything, just like it currently does. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mar 10, 2015 10:21 PM, "Risker" risker.wp@gmail.com wrote:
Thanks, Chris. But if the account is obviously not a normal account, I'd suspect that this special kind of user account would quickly become very obvious to those who snoop and would actually increase the level of scrutiny on the account, both internally and externally. I'm not really
all
that sure it's an overall improvement in safety.
Risker/Anne
That's going to depend on your threat model
If secret agents are watching you through binoculurs then nothing is going to save you.
If gov wants to track down all users who are "suspicious" (not very far fetched in the current political climate), then yes using tor may make you stand out. This is probably the case already for anyone using tor at all (esp. If not using a bridge if i understand things correctly)
If your use case is you want to upload pictures of a pro democracy protest in some fascist country where the pictures are likely to get you arrested, and fascist gov has a list of all ips accessing wikimedia servers for the specific time period, then tor might help you (emphasis on the maybe. If you are the only person in the country at that time using tor and they are able to detect your using tor then your dead. or if you are in the picture, or the rest of a long list of operational security details the paranoid have to deal with)
re kevin's comment about worth the risk
Whether or not its worth the risk is the perogative of the person taking the risk. Maybe they even consider whatever they are doing important enough that they would still do it even without the protection of tor if tor is not an option. Not that long ago thousands of people were taking "risks" by buying illicit drugs on the silk road using tor for protection. I find it easy to imagine that many people in repressive places would consider spreading information a much more neccesary risk than what silk road patrons thought was an acceptable risk in using that service.
Or perhaps tor users have nothing to hide and simply feel that what they do online is nobody's bussiness. Or maybe they want to increase the annonyminity pool for those who really do have legitament reason to hide.
--bawolff
On Tue, Mar 10, 2015 at 5:40 PM, Chris Steipp csteipp@wikimedia.org wrote:
I'm actually envisioning that the user would edit through the third party's proxy (via OAuth, linked to the new, "Special Account"), so no special permissions are needed by the "Special Account", and a standard block on that username can prevent them from editing. Additionally, revoking the OAuth token of the proxy itself would stop all editing by this process, so there's a quick way to "pull the plug" if it looks like the edits are predominantly unproductive.
I'm probably missing the point here but how is this better than a plain edit proxy, available as a Tor hidden service, which a 3rd party can set up at any time without the need to coordinate with us (apart from getting an OAuth key)? Since the user connects to them via Tor, they would not learn any private information; they could be authorized to edit via normal OAuth web flow (that is not blocked from a Tor IP); the edit would seemingly come from the IP address of the proxy so it would not be subject to Tor blocking.
On 11 March 2015 at 05:23, Gergo Tisza gtisza@wikimedia.org wrote:
On Tue, Mar 10, 2015 at 5:40 PM, Chris Steipp csteipp@wikimedia.org wrote:
I'm actually envisioning that the user would edit through the third
party's
proxy (via OAuth, linked to the new, "Special Account"), so no special permissions are needed by the "Special Account", and a standard block on that username can prevent them from editing. Additionally, revoking the OAuth token of the proxy itself would stop all editing by this process,
so
there's a quick way to "pull the plug" if it looks like the edits are predominantly unproductive.
I'm probably missing the point here but how is this better than a plain edit proxy, available as a Tor hidden service, which a 3rd party can set up at any time without the need to coordinate with us (apart from getting an OAuth key)? Since the user connects to them via Tor, they would not learn any private information; they could be authorized to edit via normal OAuth web flow (that is not blocked from a Tor IP); the edit would seemingly come from the IP address of the proxy so it would not be subject to Tor blocking. _______________________________________________
Those kinds of services are probably already range blocked or are likely to be range blocked, because they're one of the main vectors through which we get spam particularly, and abusive harassment-type vandalism secondarily. The user would still need IPBE or similar permissions to edit through that service.
Risker/Anne
On Mar 11, 2015 2:23 AM, "Gergo Tisza" gtisza@wikimedia.org wrote:
On Tue, Mar 10, 2015 at 5:40 PM, Chris Steipp csteipp@wikimedia.org
wrote:
I'm actually envisioning that the user would edit through the third
party's
proxy (via OAuth, linked to the new, "Special Account"), so no special permissions are needed by the "Special Account", and a standard block on that username can prevent them from editing. Additionally, revoking the OAuth token of the proxy itself would stop all editing by this process,
so
there's a quick way to "pull the plug" if it looks like the edits are predominantly unproductive.
I'm probably missing the point here but how is this better than a plain edit proxy, available as a Tor hidden service, which a 3rd party can set
up
at any time without the need to coordinate with us (apart from getting an OAuth key)? Since the user connects to them via Tor, they would not learn any private information; they could be authorized to edit via normal OAuth web flow (that is not blocked from a Tor IP); the edit would seemingly
come
from the IP address of the proxy so it would not be subject to Tor
blocking.
Setting up a proxy like this is definitely an option I've considered. As I did, I couldn't think of a good way to limit the types of accounts that used it, or come up with an acceptable collateral I could keep from the user, that would prevent enough spammers to keep it from being blocked while being open to people who needed it. The blinded token approach lets the proxy rely on a trusted assertion about the identity, by the people who it will impact if they get it wrong. That seemed like a good thing to me.
However, we could substitute the entire blinding process with a public page that the proxy posts to that says, "this user wants to use tor to edit, vote yes or no and we'll allow them based on your opinion". And the proxy only allows tor editing by users with a passing vote.
That might be more palatable for enwiki's socking policy, with the risk that if the user's IP has ever been revealed before (even if they went through the effort of getting it deleted), there is still data to link them to their real identity. The blinding breaks that correlation. But maybe a more likely first step to actually getting tor edits?
_______________________________________________
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I share Risker’s concerns here and limiting the anonymity set to the intersection of Tor users and established wiki contributors seems problematic. Also, the bootstrapping issue needs working out and relegating Tor users to second class citizens that need to edit through a proxy seems less than ideal (though the specifics of that are unclear to me).
But, at a minimum, this seems like a useful exercise to run if only for the experimental results and to show good faith.
I’m more than willing to help out. Please get in touch.
Arlo
On Wednesday, March 11, 2015 at 9:10 AM, Chris Steipp wrote:
On Mar 11, 2015 2:23 AM, "Gergo Tisza" <gtisza@wikimedia.org (mailto:gtisza@wikimedia.org)> wrote:
On Tue, Mar 10, 2015 at 5:40 PM, Chris Steipp <csteipp@wikimedia.org (mailto:csteipp@wikimedia.org)>
wrote:
I'm actually envisioning that the user would edit through the third
party's
proxy (via OAuth, linked to the new, "Special Account"), so no special permissions are needed by the "Special Account", and a standard block on that username can prevent them from editing. Additionally, revoking the OAuth token of the proxy itself would stop all editing by this process,
so
there's a quick way to "pull the plug" if it looks like the edits are predominantly unproductive.
I'm probably missing the point here but how is this better than a plain edit proxy, available as a Tor hidden service, which a 3rd party can set
up
at any time without the need to coordinate with us (apart from getting an OAuth key)? Since the user connects to them via Tor, they would not learn any private information; they could be authorized to edit via normal OAuth web flow (that is not blocked from a Tor IP); the edit would seemingly
come
from the IP address of the proxy so it would not be subject to Tor
blocking.
Setting up a proxy like this is definitely an option I've considered. As I did, I couldn't think of a good way to limit the types of accounts that used it, or come up with an acceptable collateral I could keep from the user, that would prevent enough spammers to keep it from being blocked while being open to people who needed it. The blinded token approach lets the proxy rely on a trusted assertion about the identity, by the people who it will impact if they get it wrong. That seemed like a good thing to me.
However, we could substitute the entire blinding process with a public page that the proxy posts to that says, "this user wants to use tor to edit, vote yes or no and we'll allow them based on your opinion". And the proxy only allows tor editing by users with a passing vote.
That might be more palatable for enwiki's socking policy, with the risk that if the user's IP has ever been revealed before (even if they went through the effort of getting it deleted), there is still data to link them to their real identity. The blinding breaks that correlation. But maybe a more likely first step to actually getting tor edits?
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org (mailto:Wikitech-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org (mailto:Wikitech-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I think pretty much anything is better than the current situation. I'd support this proposal.
The timing is right too with the WMF vs NSA lawsuit just happening.
On Mon, Mar 16, 2015 at 1:29 AM, Arlo Breault abreault@wikimedia.org wrote:
I share Risker’s concerns here and limiting the anonymity set to the intersection of Tor users and established wiki contributors seems problematic. Also, the bootstrapping issue needs working out and relegating Tor users to second class citizens that need to edit through a proxy seems less than ideal (though the specifics of that are unclear to me).
But, at a minimum, this seems like a useful exercise to run if only for the experimental results and to show good faith.
I’m more than willing to help out. Please get in touch.
Arlo
On Wednesday, March 11, 2015 at 9:10 AM, Chris Steipp wrote:
On Mar 11, 2015 2:23 AM, "Gergo Tisza" <gtisza@wikimedia.org (mailto:
gtisza@wikimedia.org)> wrote:
On Tue, Mar 10, 2015 at 5:40 PM, Chris Steipp <csteipp@wikimedia.org
(mailto:csteipp@wikimedia.org)>
wrote:
I'm actually envisioning that the user would edit through the third
party's
proxy (via OAuth, linked to the new, "Special Account"), so no
special
permissions are needed by the "Special Account", and a standard
block on
that username can prevent them from editing. Additionally, revoking
the
OAuth token of the proxy itself would stop all editing by this
process,
so
there's a quick way to "pull the plug" if it looks like the edits are predominantly unproductive.
I'm probably missing the point here but how is this better than a plain edit proxy, available as a Tor hidden service, which a 3rd party can
set
up
at any time without the need to coordinate with us (apart from getting
an
OAuth key)? Since the user connects to them via Tor, they would not
learn
any private information; they could be authorized to edit via normal
OAuth
web flow (that is not blocked from a Tor IP); the edit would seemingly
come
from the IP address of the proxy so it would not be subject to Tor
blocking.
Setting up a proxy like this is definitely an option I've considered. As
I
did, I couldn't think of a good way to limit the types of accounts that used it, or come up with an acceptable collateral I could keep from the user, that would prevent enough spammers to keep it from being blocked while being open to people who needed it. The blinded token approach lets the proxy rely on a trusted assertion about the identity, by the people
who
it will impact if they get it wrong. That seemed like a good thing to me.
However, we could substitute the entire blinding process with a public
page
that the proxy posts to that says, "this user wants to use tor to edit, vote yes or no and we'll allow them based on your opinion". And the proxy only allows tor editing by users with a passing vote.
That might be more palatable for enwiki's socking policy, with the risk that if the user's IP has ever been revealed before (even if they went through the effort of getting it deleted), there is still data to link
them
to their real identity. The blinding breaks that correlation. But maybe a more likely first step to actually getting tor edits?
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org (mailto:Wikitech-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org (mailto:Wikitech-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
At the end of the day, the key is communicating with communities to work things out with them - and that may well have to happen on a project-by-project basis. Finding a mid-size project with a very active admin corps that would be willing to try out whatever you folks come up with is probably a place to start: if it goes well there, it will raise the chances of acceptance elsewhere. What needs to be demonstrated is that permitting editing through Tor under (to be specified) controlled conditions results in improvements to the targeted project without increased vandalism and spamming - and yes, it's entirely reasonable to expect that there will be active participation by those who are advocating this change to monitor and evaluate the change. Ensure that the processes for evaluating edits through those accounts are set up before activating the access, and have a pre-arranged set of conditions where the access would be withdrawn.
Risker/Anne
On 16 March 2015 at 01:29, Arlo Breault abreault@wikimedia.org wrote:
I share Risker’s concerns here and limiting the anonymity set to the intersection of Tor users and established wiki contributors seems problematic. Also, the bootstrapping issue needs working out and relegating Tor users to second class citizens that need to edit through a proxy seems less than ideal (though the specifics of that are unclear to me).
But, at a minimum, this seems like a useful exercise to run if only for the experimental results and to show good faith.
I’m more than willing to help out. Please get in touch.
Arlo
On Wednesday, March 11, 2015 at 9:10 AM, Chris Steipp wrote:
On Mar 11, 2015 2:23 AM, "Gergo Tisza" <gtisza@wikimedia.org (mailto:
gtisza@wikimedia.org)> wrote:
On Tue, Mar 10, 2015 at 5:40 PM, Chris Steipp <csteipp@wikimedia.org
(mailto:csteipp@wikimedia.org)>
wrote:
I'm actually envisioning that the user would edit through the third
party's
proxy (via OAuth, linked to the new, "Special Account"), so no
special
permissions are needed by the "Special Account", and a standard
block on
that username can prevent them from editing. Additionally, revoking
the
OAuth token of the proxy itself would stop all editing by this
process,
so
there's a quick way to "pull the plug" if it looks like the edits are predominantly unproductive.
I'm probably missing the point here but how is this better than a plain edit proxy, available as a Tor hidden service, which a 3rd party can
set
up
at any time without the need to coordinate with us (apart from getting
an
OAuth key)? Since the user connects to them via Tor, they would not
learn
any private information; they could be authorized to edit via normal
OAuth
web flow (that is not blocked from a Tor IP); the edit would seemingly
come
from the IP address of the proxy so it would not be subject to Tor
blocking.
Setting up a proxy like this is definitely an option I've considered. As
I
did, I couldn't think of a good way to limit the types of accounts that used it, or come up with an acceptable collateral I could keep from the user, that would prevent enough spammers to keep it from being blocked while being open to people who needed it. The blinded token approach lets the proxy rely on a trusted assertion about the identity, by the people
who
it will impact if they get it wrong. That seemed like a good thing to me.
However, we could substitute the entire blinding process with a public
page
that the proxy posts to that says, "this user wants to use tor to edit, vote yes or no and we'll allow them based on your opinion". And the proxy only allows tor editing by users with a passing vote.
That might be more palatable for enwiki's socking policy, with the risk that if the user's IP has ever been revealed before (even if they went through the effort of getting it deleted), there is still data to link
them
to their real identity. The blinding breaks that correlation. But maybe a more likely first step to actually getting tor edits?
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org (mailto:Wikitech-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org (mailto:Wikitech-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Mar 11, 2015 at 9:10 AM, Chris Steipp csteipp@wikimedia.org wrote:
Setting up a proxy like this is definitely an option I've considered. As I did, I couldn't think of a good way to limit the types of accounts that used it, or come up with an acceptable collateral I could keep from the user, that would prevent enough spammers to keep it from being blocked while being open to people who needed it.
Well, the obvious collateral is always money; and with bitcoin going mainstream, untraceable money transfers are now accessible even to nontechnical users (although I don't know Not sure if the mere act of buying bitcoins could endanger someone in certain oppressive regimes). Something like $10 is probably not a serious hurdle to anyone intent on avoiding censorship but enough to deter spammers. The money could be donated to the Tor project, or retained and returned after a certain number of edits.
To make blocks more granular, some identifier such as the bitcount transaction ID could be exposed via XFF so administrators would still be able to assign blocks based on collaterals. That seems to me like a significantly easier setup than using the reputation of an existing user as collateral - that becomes really difficult if you want to both keep the association hidden and punish users who vouch for spammers.
Maybe the proxy is not even necessary (it would certainly bring a host of usability issues) and all that's needed is a gateway to buy editblocked rights for users.
The blinded token approach lets
the proxy rely on a trusted assertion about the identity, by the people who it will impact if they get it wrong. That seemed like a good thing to me.
I don't think it's the most practical solution for this specific use case, but if it could be generalized, the ability to create a limited number of tokens per user which are anonymous but assert that the creator passed some condition (e.g. >1000 edits) and can be used up in some way would be exciting as it would allow proper voting systems. No idea if that can be fit into the OAuth framework, though (or if it's even possible without having two independent authorities both of which have only partial access to the data).
On 2015-03-16 2:30 PM, Gergo Tisza wrote:
On Wed, Mar 11, 2015 at 9:10 AM, Chris Steipp csteipp@wikimedia.org wrote:
Setting up a proxy like this is definitely an option I've considered. As I did, I couldn't think of a good way to limit the types of accounts that used it, or come up with an acceptable collateral I could keep from the user, that would prevent enough spammers to keep it from being blocked while being open to people who needed it.
Well, the obvious collateral is always money; and with bitcoin going mainstream, untraceable money transfers are now accessible even to nontechnical users (although I don't know Not sure if the mere act of buying bitcoins could endanger someone in certain oppressive regimes). Something like $10 is probably not a serious hurdle to anyone intent on avoiding censorship but enough to deter spammers. The money could be donated to the Tor project, or retained and returned after a certain number of edits.
Bitcoin is not untraceable.
An adversary capable enough to eavesdrop on dissidents' communication making them need Tor should be capable of tracing the publicly available bitcoin transaction logs back from the payment to the proxy owner to the originating non-anonymous financial transaction used to purchase the bitcoins.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
On Mon, Mar 16, 2015 at 5:08 PM, Daniel Friesen daniel@nadir-seen-fire.com wrote:
Bitcoin is not untraceable.
An adversary capable enough to eavesdrop on dissidents' communication making them need Tor should be capable of tracing the publicly available bitcoin transaction logs back from the payment to the proxy owner to the originating non-anonymous financial transaction used to purchase the bitcoins.
I'll admit not knowing much about bitcoin security, but isn't that what mixers are for?
On 2015-03-16 7:55 PM, Gergo Tisza wrote:
On Mon, Mar 16, 2015 at 5:08 PM, Daniel Friesen daniel@nadir-seen-fire.com wrote:
Bitcoin is not untraceable.
An adversary capable enough to eavesdrop on dissidents' communication making them need Tor should be capable of tracing the publicly available bitcoin transaction logs back from the payment to the proxy owner to the originating non-anonymous financial transaction used to purchase the bitcoins.
I'll admit not knowing much about bitcoin security, but isn't that what mixers are for?
Assuming those work, they make bitcoin even less accessible to the nontechnical users and many of the users of the proxy would likely not do so, endangering themselves.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
On 17 March 2015 at 02:55, Gergo Tisza gtisza@wikimedia.org wrote:
On Mon, Mar 16, 2015 at 5:08 PM, Daniel Friesen daniel@nadir-seen-fire.com wrote:
Bitcoin is not untraceable. An adversary capable enough to eavesdrop on dissidents' communication making them need Tor should be capable of tracing the publicly available bitcoin transaction logs back from the payment to the proxy owner to the originating non-anonymous financial transaction used to purchase the bitcoins.
I'll admit not knowing much about bitcoin security, but isn't that what mixers are for?
Pretty much nothing about Bitcoin works as advertised in the hype, except irreversibility of transactions (which works all too well). Everything will apparently be fixed later.
- d.
On Mon, Mar 16, 2015 at 2:30 PM, Gergo Tisza gtisza@wikimedia.org wrote:
Well, the obvious collateral is always money; and with bitcoin going mainstream, untraceable money transfers are now accessible even to nontechnical users (although I don't know Not sure if the mere act of buying bitcoins could endanger someone in certain oppressive regimes). Something like $10 is probably not a serious hurdle to anyone intent on avoiding censorship but enough to deter spammers. The money could be donated to the Tor project, or retained and returned after a certain number of edits.
In some jurisdictions Bitcoin is outright prohibited, with penalties for end users for mere ownership of any amounts. Would be very funny to require people to expose their asses to more problems in order to edit Wikipedia.
On Tue, Mar 10, 2015 at 10:16 AM, Giuseppe Lavagetto < glavagetto@wikimedia.org> wrote:
Hi Chris,
I like the idea in general, in particular the fact that only "established" editors can ask for the tokens. What I don't get is why this proxy should be run by someone that is not the WMF, given - I
It's due to a known issue with the scheme that Yan suggested-- if the same person knows both the blinded and unblinded signatures, they can brute force the blinding and correlate the identities. Splitting the two is needed to prevent that.
guess - it would be exposed as a TOR hidden service, which will mask effectively the user IP from us, and will secure his communication from snooping by exit node managers, and so on.
I guess the righteously traffic on such a proxy would be so low (as getting a token is /not/ going to be automated/immediate even for logged in users) that it could work without using up a lot of resources.
Cheers,
Giuseppe
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Mar 10, 2015 at 11:23 AM, Chris Steipp csteipp@wikimedia.org wrote:
Jacob Applebaum made another remark about editing Wikipedia via tor this morning. Since it's been a couple months since the last tor bashing thread, I wanted to throw out a slightly more modest proposal to see what people think.
[..]
If enwiki doesn't like this, lets start with other wikis. We run something like 700 wikis, I'm sure at least some of them would like the idea. Having some other wiki then enwiki go first and demonstrate that this is workable without vandals taking over may help alleviate enwiki fears.
--bawolff
wikitech-l@lists.wikimedia.org