Give me 25 minutes and ill join

On Monday, December 30, 2013, Thomas Gries wrote:

Am 30.12.2013 23:01, schrieb John:

...

Editing via tor is possible on WMF wikis if the account / user is

trusted

Can you explain this briefly, or send me a pointer ? This single info can be a help for him and others. (Honestly, I do not know, what a "trusted" account/user is.) I am on #mediawiki now

...

On Monday, December 30, 2013, Thomas Gries wrote:

...

Hi,

during the 30C3 Congress [1] in Hamburg - where neither Wikipedia Foundation nor MediaWiki were formally present this year (but should be next year)- Jacob Appelbaum [2] - core member of the TOR project - complained in one of his numerous talks that the (edit) access to Wikipedia via TOR is not possible.

He requested that a way should be found to enable the TOR access including edit access to Wikipedia.

I am just the messenger of this message.

Regards, Tom

[1] https://events.ccc.de/congress/2013/wiki/ [2] https://en.wikipedia.org/wiki/Jacob_Appelbaum

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org javascript:; javascript:; https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org javascript:; https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus

Schutz ist aktiv.

...

http://www.avast.com

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org javascript:; https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Thank you all, I expected such an explanation, it matches my understanding who MediaWiki currently works. I think, it is worth to start a formal bugzilla about that topic, so that it can be better tracked and commented.

Am 30.12.2013 23:10, schrieb Tyler Romeo:

On Mon, Dec 30, 2013 at 5:03 PM, Thomas Gries mail@tgries.de wrote:

...

Can you explain this briefly, or send me a pointer ? This single info can be a help for him and others. (Honestly, I do not know, what a "trusted" account/user is.) I am on #mediawiki now

There is a special permission that allows specific accounts to not be affected by IP blocks. It is granted by application on a case-by-case basis. You can find more information here: https://en.wikipedia.org/wiki/Wikipedia:IP_block_exemption. I am not sure whether similar processes exist on other wikis.

As for the original topic, this has been thoroughly discussed before, and every time I forget what the result of the discussion is. I know for sure that since MediaWiki is fundamentally centered around knowing users' IP addresses in order to stop sockpuppets, simply allowing Tor users to edit will not happen. We need a solution that allows us to know a Tor user's IP address without actually known their IP address. If that sounds like a difficult problem, it's because it is. One suggestion was to use a type of token authentication, where we use RSA blinding in order to give anonymous exemption tokens. Another suggestion was to simply abandon IP blocks, since users can easily enough change their IP addresses anyway.

*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com

I understand Jacob's remarks as a welcome call to the TOR

community to work more intensively with Wikipedians to understand the actual issues that motivated Wikipedia's TOR block.

This is, why we (or some core) MediaWiki developers should also attend such congresses like the C3 regularly.

I opened https://bugzilla.wikimedia.org/show_bug.cgi?id=59146 -Enabling access and edit access to Wikipedia via TOR for discussions

T.

On Mon, Dec 30, 2013 at 6:08 PM, Rjd0060 rjd0060.wiki@gmail.com wrote:

Shouldn't the discussion *not* be happening on Bugzilla, but somewhere where the wider community is actually present? Perhaps Meta?

Well the issue is not whether we want Tor users editing or not. We do. The issue is finding a software solution that makes it possible.

*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science

On Mon, Dec 30, 2013 at 6:49 PM, Risker risker.wp@gmail.com wrote:

I disagree fundamentally with your position here. It's technically possible for Tor editors to edit; all we have to do is unblock Tor nodes (or for them to disable Tor), and they can edit. It is the social and policy-based processes that prevent Tor users from using Tor to edit. I happen to agree with those processes (having cleaned up major messes from unblocked Tor nodes on enwiki), but it's not a technical problem, really.

I'm confused exactly what you are disagreeing with? The consensus currently is that Tor users should not be able to edit raw. Thus the issue at hand is that there is currently no technical solution for allowing Tor users to edit while still being able to block them. If you want to change the consensus and unblock Tor users from editing, then it is indeed a social/policy issue.

*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science

On Mon, Dec 30, 2013 at 4:06 PM, Risker risker.wp@gmail.com wrote:

On 30 December 2013 18:59, Tyler Romeo tylerromeo@gmail.com wrote:

...

On Mon, Dec 30, 2013 at 6:49 PM, Risker risker.wp@gmail.com wrote:

...

I disagree fundamentally with your position here. It's technically

possible

...

for Tor editors to edit; all we have to do is unblock Tor nodes (or for them to disable Tor), and they can edit. It is the social and

policy-based

...

processes that prevent Tor users from using Tor to edit. I happen to

agree

...

with those processes (having cleaned up major messes from unblocked Tor nodes on enwiki), but it's not a technical problem, really.

I'm confused exactly what you are disagreeing with? The consensus

currently

...

is that Tor users should not be able to edit raw. Thus the issue at hand

is

...

that there is currently no technical solution for allowing Tor users to edit while still being able to block them. If you want to change the consensus and unblock Tor users from editing, then it is indeed a social/policy issue.

I have no desire to change the status quo. But the solution of being able to isolate and block individual accounts through Tor would require a change in Tor's software and principles, not MediaWiki's. One of its core characteristics is to render accounts technically indistinguishable, and to seek alternate routes when an account is prevented from editing/accessing.

I think there may have been some progress on this since the last time it was brought up, since we now have OAuth in place. It might be a way to help bridge this gap.

I was talking with Tom Lowenthal, who is a tor developer. He was trying to convince Tilman and I that IP's were just a form of collateral that we implicitly hold for anonymous editors. If they edit badly, we take away the right of that IP to edit, so they have to expend some effort to get a new one. Tor makes that impossible for us, so one of his ideas is that we shift to some other form of collateral-- an email address, mobile phone number, etc. Tilman wasn't convinced, but I think I'm mostly there.

We probably don't want to do that work in MediaWiki, but with OAuth, anyone can write an editing proxy that allows connections from Tor, ideally negotiates some kind of collateral (proof of work, bitcoin, whatever), and edits on behalf of the tor user. Individuals can still be held accountable (either blocked on wiki, or you can block them in your app), or if your app lets too many vandals in, we'll revoke your entire OAuth consumer key.

So I'm not claiming to have solved this, but if other people want to experiment with ways to do this, I think they can do it without a change to the current blocking policy, or getting any code deployed on the WMF cluster.

Risker _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Mon, Dec 30, 2013 at 6:10 PM, Tyler Romeo tylerromeo@gmail.com wrote:

On Mon, Dec 30, 2013 at 7:34 PM, Chris Steipp csteipp@wikimedia.org wrote:

...

I was talking with Tom Lowenthal, who is a tor developer. He was trying to convince Tilman and I that IP's were just a form of collateral that we implicitly hold for anonymous editors. If they edit badly, we take away the right of that IP to edit, so they have to expend some effort to get a new one. Tor makes that impossible for us, so one of his ideas is that we shift to some other form of collateral-- an email address, mobile phone number, etc. Tilman wasn't convinced, but I think I'm mostly there.

This is a viable idea. Email addresses are a viable option considering they take just as much (if not a little bit more) effort to change over as IP addresses. We can take it even a step further and only allow email addresses from specific domains, i.e., we can restrict providers of so-called "throwaway emails".

Email is pretty shallow collateral, esp if you actually allow email providers which are materially useful to people who are trying to protect their privacy. Allowing e.g. only email providers which require SMS binding, for example, would be pretty terrible... This is doubly so because the relationship is discoverable: e.g. you only really wanted to use the email to provide scarcity but because it was provided it could be used to deanonymize the users. (Even if you intentionally didn't log the email-user mapping, it would end up being deanonymized-by-time in database backups; or could be secretly logged at any time, e.g. via compromised staff)

FAR better than this can be done without much more work.

Digging up an old proposal of mine…

A proposal for more equitable access to ipblock-exempt.

In the "Jake requests enabling access and edit access to Wikipedia via TOR" thread on wikitech-l[http://lists.wikimedia.org/pipermail/wikitech-l/2013-December/073764.html] the issue of being able to edit Wikipedia via TOR was highlighted.

Some people appear to have mistaken this thread as being specifically about Jake. This isn't so— Jake is technologically sophisticated and has access to many technical and social resource. Jake-the-person can edit Wikipedia, with suitable effort. But Jake-as-a-proxy-for-other-tor-users has a much harder time.

Ipblock-exempt as implemented today doesn't— as demonstrated [http://lists.wikimedia.org/pipermail/wikitech-l/2013-December/073773.html] —even work for Jake. It certainly doesn't work for more typical users.

Many people believe that Wikipedia has become so socially important that being able to edit it— even if just to leave talk page comments— is an essential part of participating in worldwide society. Unfortunately, not all people are equally free and some can only access Wikipedia via anti-censorship technology or can only speak without fear of retaliation via anonymity technology.

Wikipedia must balance the interests of preventing abuse and enabling the sharing of knowledge. Only so much can be accomplished by prohibiting access to tor entirely: Miscreants can and do use paid VPNs and compromised hosts to evade blocks on a constant basis. Ironically, abusive users who are unconcerned about breaking the law have an easier time editing Wikipedia then people simple concerned with unlawful surveillance. That isn't a balance.

In order to better balance these interests, I propose the following technical improvement:

A new special page should be added with a form which takes an unblocked username and which accepts a base64 encoded message which contains a random serial number and a RSA digital signature with a well known Wikimedia controlled private key, we'll call this message an exemption token. If the signature passes and the serial number has never been seen before, the serial number is saved, and Ipblock-exempt is set on the account.

Additionally, the online donation process is updated with some client side JS so that for every $10 donated the client picks a random value, cryptographically blinds the random value [https://en.wikipedia.org/wiki/Blind_signature#Blind_RSA_signatures.5B2.5D:23...], and submits the blinded values along with the donation. When the donation is successful, the donation server signs the blinded values and returns them and the clients unblind them and present the messages to the users.

[RSA blinding is no more complicated to implement than RSA signing in general. It requires a modular exponentiation and multiply and a modular inversion]

The donor is free to save the messages, give them out to friends, or press some button to give them to the tor project. Each message entitles one account to be exempted, and Wikimedia is unable to associate donations with accounts due to the blinding.

Finally, the block notice should direct people to a page with instructions on obtaining exemption tokens.

This process would provide a guaranteed bound on the amount of abusive use of ipblock-exempt. If an account is abused it can simply be blocked, the abuser may obtain another exemption token, but only at the cost of making another $10 donation.

Non-donation-based exceptions would continue to be available as they are now, to anyone who can figure out how to get one.

This would be a strict improvement over not allowing the access at all, or only handling out to people with political connections and the time to figure out how to get it activated. Right now the cost of access is basically hours of work figuring out how to do it, getting to know the right people, and begging for a flag— all with no guarantee of success. Or the cost is the cost of illegally using a compromised host, etc.

This isn't perfect— it creates a bias towards people in wealthier nations which can afford the tokens, but most people don't need their tokens and so it would be reasonable to expect substantial token charity to exist. The existence of IP blocking at all creates a bias towards editors with an agenda or copious free time to blow which probably dwarfs any biases created by any particular exemption process.

A key point here is that the idea is fully general— I suggest the donation mechanism as one I hope would be appealing to vandal-fighters: Every time a "bad guy" gets through and you waste your time banning them at least you get the warm-glow of knowing you induced another donation if they want to try again. But some people immediately freak out at "paying for accounts"— I think the argument is bogus because any requirement is a "payment"— but, whatever, if you don't like that one you can use _any_ scarce process to issue exemption tokens...

If you like— you could also support multiple issuers of blinded tokens instead of just the wikimedia ones simply by adding public keys to the set of allowable keys, perhaps configurable as just a mediawiki space message. Then instead of donations-to-wikimedia being the scarce resource, other parties (e.g. the tor project, EFF, or otherwise) could issue blinded tokens... and then you could just have a community decision over if any particular scarce token source was scarce enough to be acceptable.

If the exemption process logged which token authority was used, you could retroactively revoke all the tokens from a particular issuer if it turned out to be issuing too many trouble making ones... though I expect simply no longer accepting that issuer for new exceptions would be sufficient.

Even if you only bothered supporting a single issuer who issued one token per email address— basically getting you the email address functionality that I'm responding to— the blinding process has the advantage of making it infeasible to use this process to deanonymize users... so all you would really learn is that an email address (meeting whatever criteria the issuer demands) got expended to get the exemption, and nothing more. And even if someone compromised the infrastructure and started secretly logging things they couldn't learn anything more than timestamp correlations (which might be pretty fuzzy if there is a long delay between the token getting issued and the account using it, esp if the issuer is a third party).

On Mon, Dec 30, 2013 at 9:48 PM, Gregory Maxwell gmaxwell@gmail.com wrote:

Digging up an old proposal of mine…

Relevant: https://bugzilla.wikimedia.org/show_bug.cgi?id=3729#c3

I've attempted implementing this proposal before (about a year ago). The inherent issue, though, is that unless you make is so that each account can get one and only one token, you're not actually solving the problem: making sure Tor users have a one-to-one relation to a real IP address (or collateral, as Chris calls it).

Also, I don't know the specifics, but the fundraising team has a whole bunch of requirements they go through in order to be certified for security and whatnot (somebody correct me if I'm wrong). They have a very strict set of software policies they must follow. Implementing a system like this to work with donations would be extraordinarily difficult, if it's even possible.

*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science

Chris Steipp wrote:

I think there may have been some progress on this since the last time it was brought up, since we now have OAuth in place. It might be a way to help bridge this gap.

I was talking with Tom Lowenthal, who is a tor developer. He was trying to convince Tilman and I that IP's were just a form of collateral that we implicitly hold for anonymous editors.

Explicitly, no? We actively record and retain the associated IP address indefinitely if a user makes an edit without logging in. If those edits are disruptive, there's usually a permanent public record.

The collateral idea is interesting, though it should really be "verifiable collateral," I believe. You have to round-trip with the mobile number, e-mail address, credit card number, etc. to ensure that it's legitimate. Spoofed IP addresses (whether through open proxies or Tor) are generally disallowed due to the abuse vector. Presumably in part because of the weak verifiability of IP addresses as compared to other forms of Identification.

And then of course there are projects like the XFF project, which like the Tor exemption, seek to strike a balance between liberty and anarchy. Lar used to say that you could nearly eliminate socking if you required everyone to verify with a credit card. Which is true, but....

Given the current rewrite of the privacy policy, it may not even be possible to collect other forms of identification without a Board resolution. Everyone will read the draft privacy policy's "we try to collect as little as possible" language differently, though.

At Wikimedia's size, any potential collateral solution is proportionately difficult to scale and secure. Wikimedia gets a lot of requests, so it would subsequently be verifying a lot of data (we already send out X e-mails per day and growing). In terms of security, you have to prevent the verification system from abuse. Similar to how the donation system has been used to make it easier to steal credit cards, mobile phone number and other types of verification can make nefariousness easier. So you need to implement hard and soft rate-limiting and other anti-abuse mechanisms. Bleh.

MZMcBride

On 12/30/2013 06:49 PM, Risker wrote:

I disagree fundamentally with your position here.

I have to agree with Risker here (Oy! Twice in one year!)

The problem isn't that it is technically difficult to allow edits through TOR, but that the vast majority of edits coming in from TOR are abusive, and impossible to prevent or mitigate since blocking is a noop.

This is why, /as a social mechanism/, the English Wikipedia has long established that TOR editing must be limited to the very few editors who (a) have established a positive track record and (b) actually /need/ the extra privacy.

Discussing this in a bugzilla will - at best - be pointless because you need to convince the community first.

-- Marc

On Tue, Dec 31, 2013 at 1:08 AM, Martijn Hoekstra martijnhoekstra@gmail.com wrote:

Does Jake have any mechanism in mind to prevent abuse? Is there any possible mechanism available to prevent abuse?

"Preventing" abuse is the wrong goal. There is plenty of abuse even with all the privacy smashing new editor deterring convolutions that we can think up. Abuse is part of the cost of doing business of operating a publicly editable Wiki, it's a cost which is normally well worth its benefits.

The goal needs to merely be to limit the abuse enough so as not to upset the abuse vs benefit equation. Today, people abuse, they get blocked, they go to another library/coffee shop/find another proxy/wash rinse repeat. We can't do any better than that model, and it turns out that it's okay. If a solution for tor users results in a cost "cost" (time, money, whatever unit of payment is being expended) for repeated abuse comparable to the other ways abusive people access the site then it should not be a major source of trouble which outweighs the benefits. (Even if you do not value freedom of expression and association for people in less free parts of the world at all).

On Sun, Jan 12, 2014 at 6:36 PM, Jasper Deng jasper@jasperswebsite.com wrote:

This question is analogous to the question of open proxies. The answer has universally been that the costs (abuse) are just too high.

No, it's not analogous to just permitting open proxies as no one in this thread is suggesting just flipping it on.

I proposed issuing blind exemption tokens up-thread as an example mechanism which would preserve the rate limiting of abusive use without removing privacy.

However, we might consider doing what the freenode IRC network does. Freenode requires SASL authentication to connect on Tor, which basically means only users with registered accounts can use it. The main reason for hardblocking and not allowing registered accounts on-wiki via Tor is that CheckUsers need useful IP data. But it might be feasible if we just force all account creation to happen on "real" IPs, although that still hides some data from CheckUsers.

What freenode does is not functionally useful for Tor users. In my first hand experience it manages to enable abusive activity while simultaneously eliminating Tor's usefulness at protecting its users.

The only value it provides is providing a pretext of "tor support" without actually doing something good... and we already have the "you can get an IPblock-exempt (except you can't really, and if you do it'll get randomly revoked." if all we want is a pretext. :)

On Sun, Jan 12, 2014 at 11:46 PM, Gryllida gryllida@fastmail.fm wrote:

On Mon, 13 Jan 2014, at 15:29, Gregory Maxwell wrote:

...

What freenode does is not functionally useful for Tor users. In my first hand experience it manages to enable abusive activity while simultaneously eliminating Tor's usefulness at protecting its users.

The "register at real IP, then only use TOR through an account" flow implies trust in some entity (such as freenode irc network opers or Wikipedia CheckUsers). I currently believe that requiring such trust doesn't "eliminate TOR's usefullness at protecting its users".

I rather think it does. Assume a person under continual surveillance. If they have to reveal their true IP address to Wikipedia in order to register their editor account, the adversary will learn it as well, and can then attribute all subsequent edits by that handle to that person *whether or not* those edits are routed over an anonymity network.

To satisfy Applebaum's request, there needs to be a mechanism whereby someone can edit even if *all of their communications with Wikipedia, including the initial contact* are coming over Tor or equivalent. Blinded, costly-to-create handles (minted by Wikipedia itself) are one possible way to achieve that; if there are concrete reasons why that will not work for Wikipedia, the people designing these schemes would like to know about them.

zw

On Mon, Jan 13, 2014 at 11:43 AM, Marc A. Pelletier marc@uberbox.org wrote:

On 01/13/2014 11:32 AM, Zack Weinberg wrote:

...

Assume a person under continual surveillance. If they have to reveal their true IP address to Wikipedia in order to register their editor account, the adversary will learn it as well, and can then attribute all subsequent edits by that handle to that person *whether or not* those edits are routed over an anonymity network.

If you start with that assumption, then it is unreasonable to assume that the endpoints aren't /also/ compromised or under surveillance.

Not true. Tor's threat model already includes protecting clients against malicious exit nodes. The client endpoint can be secured by using trusted hardware (Snowden notwithstanding, I feel relatively comfortable assuming that attacks on the integrity of computers bought off the shelf and never let out of one's sight since are rare and expensive, even for nation-state adversaries) and a canned Tor-centric client operating system executing from read-only media (e.g. Tails).

What TOR may be good at is to protect your privacy from casual or economic spying; in which case going to some random Internet access point to create an account protects you adequately.

That is exactly the wrong advice to give the sort of people who want to be able to edit Wikipedia over Tor (you should be thinking of democracy activists in totalitarian states). Random publicly-accessible internet access points are *more* likely to be under aggressive surveillance, including thoroughly-bugged client OSes which one may not supplant.

zw

On 01/13/2014 12:15 PM, Faidon Liambotis wrote:

What do you mean by "endpoints"?

The computer from which the edit is made is the salient one. Or, indeed even visual observation of the person of interest coupled with rubber hose crypto.

The scenario I am trying to explain is that which starts from the given premise: "Assume a person under continual surveillance." TOR offers no protection against that scenario, privacy pundits notwithstanding.

Plus, it sounds a bit like a variation of the "I have nothing to hide" argument to me, to which I couldn't disagree more with.

No, it does not.

What I *am* saying is that if you place your freedom or life in danger by editing Wikipedia then TOR only provides very limited protection at best, and the scenarios where that is not the case are already adequately covered with IPBE.

It it worthwhile to try and give as much privacy as possible for people under repressive regimes? On moral grounds, without doubt. But those are rare an exceptional circumstances, and the cost of opening the door to abuse is high. By definition, any real solution will be involved, hard to get right, and expensive (in time and resources).

-- Marc

On 01/13/2014 12:55 PM, Greg Grossmeier wrote:

That's a strawman (both your statement and mine).

That wasn't /my/ statement, I was just pointing out its straw nature myself. :-) My point was exactly that trying to use emotional statements as rationale for change won't lead to anything good.

Can we look into ways of making it more practical to edit through TOR without causing damage to the projects? Yes. It it useful to start throwing around the "OMG think of the repressive regimes" thing around? No.

-- Marc

I started that thread.

1. Please refer to https://bugzilla.wikimedia.org/show_bug.cgi?id=59146 "Enabling also edit access to Wikipedia via TOR" which much better allows tracking of this issue towards to find a practical solution.

2. Recommended reading:

Peter Wayner "Disappearing Cryptography" Third edition pages 225-227, 2009. ISBN 978-0-12-374479-1

Pages 225-227 Chapter 10.7.3 "Stopping Bad user":

"bad users of the onion routing network can ruin the reputation of other users. The _/*Wikipedia*/_, for instance, often blocks TOR exit nodes complete because some people have used the network to hide their identities while defacing the wiki's entries..."

In the further passages Peter Wayner explains a "one straight-forward solution is to use some form of certificates with a /_*blind signature*_/, a technique that borrows from some of the early solutions for building anonymous digital cash" (A typical example with "Alice" follows - must read this).

On Tue, 14 Jan 2014, at 3:32, Zack Weinberg wrote:

On Sun, Jan 12, 2014 at 11:46 PM, Gryllida gryllida@fastmail.fm wrote:

...

On Mon, 13 Jan 2014, at 15:29, Gregory Maxwell wrote:

...

What freenode does is not functionally useful for Tor users. In my first hand experience it manages to enable abusive activity while simultaneously eliminating Tor's usefulness at protecting its users.

The "register at real IP, then only use TOR through an account" flow implies trust in some entity (such as freenode irc network opers or Wikipedia CheckUsers). I currently believe that requiring such trust doesn't "eliminate TOR's usefullness at protecting its users".

I rather think it does. Assume a person under continual surveillance. If they have to reveal their true IP address to Wikipedia in order to register their editor account, the adversary will learn it as well, and can then attribute all subsequent edits by that handle to that person *whether or not* those edits are routed over an anonymity network.

Doesn't it get solved if, despite the "surveillance", the trust entity ("freenode opers" or "wikipedia checkusers") reveals the user's IP only under a court order?

To satisfy Applebaum's request, there needs to be a mechanism whereby someone can edit even if *all of their communications with Wikipedia, including the initial contact* are coming over Tor or equivalent.

Rubbish. This makes a vandal inherently untrackable and unblockable.

On Mon, Jan 13, 2014 at 2:51 PM, Gryllida gryllida@fastmail.fm wrote:

On Tue, 14 Jan 2014, at 3:32, Zack Weinberg wrote:

...

I rather think it does. Assume a person under continual surveillance. If they have to reveal their true IP address to Wikipedia in order to register their editor account, the adversary will learn it as well, and can then attribute all subsequent edits by that handle to that person *whether or not* those edits are routed over an anonymity network.

Doesn't it get solved if, despite the "surveillance", the trust entity ("freenode opers" or "wikipedia checkusers") reveals the user's IP only under a court order?

No. The adversary doesn't need to talk to the "trust entity" to get the user's IP. The adversary learns the IP by eavesdropping on the initial, uncloaked network traffic between the user-to-be and the trusted entity.

Equally, in some contexts it is unacceptable for the trust entity to be able to reveal the user's IP even under legal compulsion or threat of force.

...

To satisfy Applebaum's request, there needs to be a mechanism whereby someone can edit even if *all of their communications with Wikipedia, including the initial contact* are coming over Tor or equivalent.

Rubbish. This makes a vandal inherently untrackable and unblockable.

This isn't necessarily so. In my previous message I mentioned one technique that *should* be adequate to preventing vandals even when the administrators do not and have never known their IP address of origin. There are others in the literature, and if there are concrete reasons why none of those techniques will work for Wikipedia, people want to know about it.

zw

FWIW, I set IP block exempt on Jake's account a few years ago, but to my frustration it looks like someone removed it because of inactivity.

(Editorializing a bit, I don't see much value in the removal; while it is true that an inactive user's account could be broken into, the permission extends to a single account, which can be blocked like any other if it starts to act unproductively.)

-Kat

On Mon, Dec 30, 2013 at 2:01 PM, John phoenixoverride@gmail.com wrote:

Editing via tor is possible on WMF wikis if the account / user is trusted

On Monday, December 30, 2013, Thomas Gries wrote:

...

Hi,

during the 30C3 Congress [1] in Hamburg - where neither Wikipedia Foundation nor MediaWiki were formally present this year (but should be next year)- Jacob Appelbaum [2] - core member of the TOR project - complained in one of his numerous talks that the (edit) access to Wikipedia via TOR is not possible.

He requested that a way should be found to enable the TOR access including edit access to Wikipedia.

I am just the messenger of this message.

Regards, Tom

[1] https://events.ccc.de/congress/2013/wiki/ [2] https://en.wikipedia.org/wiki/Jacob_Appelbaum

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org javascript:; 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