Chris Steipp schreef op 2015/03/10 om 7:23: 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.

On Tue, Mar 10, 2015 at 7:45 AM, Kevin Wayne Williams < kwwilliams(a)kwwilliams.com&gt; wrote: 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.

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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Tue, Mar 10, 2015 at 10:39 AM, Risker &lt;risker.wp(a)gmail.com&gt; wrote: 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? I was originally thinking that if something happened (forgotten password, etc.), you could start over. But not a hard requirement. the 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 &lt;glavagetto(a)wikimedia.org&gt; > 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(a)lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

<snip> 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

On Tue, Mar 10, 2015 at 2:58 PM, Risker &lt;risker.wp(a)gmail.com&gt; wrote: Tor, to 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. responding privileges is obtain - The new, unlinked account will edit Wikipedia in the same manner as a removed 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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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.

On Tue, Mar 10, 2015 at 5:40 PM, Chris Steipp &lt;csteipp(a)wikimedia.org&gt;

> I'm actually envisioning that the user would edit through the third

> 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,

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

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

from the IP address of the proxy so it would not be subject to Tor

Wikitech-l mailing list Wikitech-l(a)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: gtisza(a)wikimedia.org)&gt; wrote: (mailto:csteipp@wikimedia.org)> special block on the process, set an learn OAuth I who page them _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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 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.

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.

On Mon, Mar 16, 2015 at 5:08 PM, Daniel Friesen &lt;daniel(a)nadir-seen-fire.com&gt; 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?

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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l