Do note, hu.wikipedia.org has external stats aggregator, 'stats.wikipedia.hu', which is hosted on vhost102.sx6.tolna.net - and all our traffic is sent there ( http://hu.wikipedia.org/w/index.php?title=MediaWiki:Lastmodifiedat&oldi… - as well as few other places )

Do note, hu.wikipedia.org has external stats aggregator, 'stats.wikipedia.hu', which is hosted on vhost102.sx6.tolna.net - and all our traffic is sent there ( http://hu.wikipedia.org/w/index.php?title=MediaWiki:Lastmodifiedat&oldi…

We need tools to track user behavior inside Wikipedia. As it is now we know nearly nothing at all about user behavior and nearly all people saying anything about users at Wikipedia makes gross estimates and wild guesses. User privacy on Wikipedia is is close to a public hoax, pages are transfered unencrypted and with user names in clear text. Anyone with access to a public hub is able to intercept and identify users, in addition to _all_ websites that are referenced during an edit on Wikipedia through correlation of logs. Compared to this the whole previous discussion about the Iranian steward is somewhat strange, if not completely ridiculous. Get real, the whole system and access to it is completely open! John Neil Harris skrev: _______________________________________________ foundation-l mailing list foundation-l(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

John at Darkstar wrote: As you say, there is no possibility of absolute privacy from anyone with access to the traffic stream, since the Internet was never engineered to give this kind of privacy. Wikipedia as "completely open" as any other non-https website -- and, even with https, as with any other website with publicly visible transactions, for anyone with access to the traffic stream, simple traffic analysis is generally enough to correlate user identities to IPs. A combination of http and Tor is probably as good as it gets in attempting to avoid this, but even this has its limitations. But it is simply unreasonable to equate this with no privacy at all. Most possible eavesdroppers do _not_ have access to the entire traffic stream, and those who do have access to traffic generally only have access to part of the traffic stream, and even then, most of them can't be bothered to eavesdrop, or are discouraged from doing so by privacy laws. Given this, it is quite reasonable to take appropriate technical measures that attempt to keep as much of that remaining privacy as secure as possible. -- Neil _______________________________________________ foundation-l mailing list foundation-l(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

John at Darkstar wrote: Indeed they could. But even so, they would still have great difficulty in getting more than a small fraction of Wikipedia's readers to both visit the honeypot and make an edit that links to it, and the vast majority of unaffected users will still avoid being bitten by this attack. And even then, they will still only have obtained a mapping between the user's current IP and their Wikipedia account, and will still have to correlate this back to a personal identity, which is often harder than it might seem to be in theory. The world is a dangerous place, but just because privacy and security can never be absolute is not a reason to make good faith efforts to preserve it as much of both as reasonably possible within the limits of time and resources available. Just because a door can be knocked down with a sledgehammer (or a wall demolished with a pneumatic hammer) is not a reason not to have a lock on it, or a door there in the first place. -- Neil

MediaWiki level Maybe if we set up Google Analytics in the first place (done by the Foundation office) and never used it; the foundation could set up analytics for all projects with a super secure password, and never use it. Will this work, or will somebody else be able to set up analytics still? Go Freedom! Unionhawk On Thu, Jun 4, 2009 at 6:01 AM, Neil Harris <usenet(a)tonal.clara.co.uk>wrote;wrote: > Tim 'avatar' Bartel wrote: >> Hi, >> >> recently the report of the KnowPrivacy [1] study - a research >> project >> by the School of Information from University of California in >> Berkeley >> - hit the German media [2]. >> >> It came to the conclusion that "All of the top 50 websites contained >> at least one web bug at some point in a one month time period." [3] >> which includes wikipedia.org. >> >> This is very troubleing and irritating for some of our (German) >> users >> who are very sensitive to data privacy topics. So I established >> contact to Brian W. Carver (University of California) who >> connected me >> to David Cancel, the maintainer of Ghostery, which was used to >> identify the web bugs. David wrote me today: >> >> >>> The following web bug trackers were reported to us, on the >>> following > subdomains: >>> Google Analytics - vls.wikipedia.org >>> Doubleclick - hu.wikipedia.org >>> Both were seen in yesterday's data so they're recent. We don't >>> receive > any page level information so that's as much detail as we have. > Hope that > helps. >>> >> >> I wasn't able to track down the Doubleclick web bug on the hungarian >> Wikipedia, but Google Analytics web bug is integrated in every >> page of >> the West Flemish Wikipedia via JavaScript [4]. >> >> Our privacy policy [5] states "The Wikimedia Foundation may keep raw >> logs of such transactions [IP and other technical information], but >> these will not be published or used to track legitimate users." and >> "As a general principle, the access to, and retention of, personally >> identifiable data in all projects should be minimal and should be >> used >> only internally to serve the well-being of the projects." >> >> I think we should stop the current use of Google Analytics ASAP. >> >> Bye, Tim. >> >> > MediaWiki level, by suppressing the generation of any HTML that > loads > any indirect resources (scripts, iframes, images, etc.) whatsoever > other > than from a clearly defined whitelist of Wikimedia-Foundation- > controlled > domains? > > Doing this should completely stop site admins from adding web bugs. > > -- Neil > > > _______________________________________________ > foundation-l mailing list > foundation-l(a)lists.wikimedia.org > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/ > foundation-l > _______________________________________________ foundation-l mailing list foundation-l(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

If I were to compile a wishlist of stats things: 1. stats.grok.se data for non-Wikipedia projects

3. Pageview stats at <http://dammit.lt/wikistats/> in files based on projects. It would be a lot easier for people at the West Flemish Wikipedia to analyze statistics themselves if they didn't have to download tons of data they don't need.

One idea is the proposal to install the AbuseFilter in a global mode, i.e. rules loaded at Meta that apply everywhere. If that were done (and there are some arguments about whether it is a good idea), then it could be used to block these types of URLs from being installed, even by admins.

Hmm? There's no reason to do anything like that. The AbuseFilter would just prevent sitewide JS pages from being saved with the particular URLs or a particular code block in them. It'll stop the well-meaning but misguided admins. Short of restricting site JS to the point of uselessness, you'll never be able to stop determined abusers.

John at Darkstar wrote: Other purposes that have valid uses loading 3rd party content on a Wikimedia wiki? Like what?

I don't think I said it would be perfect, the idea isn't to 100% prevent it, just to try to stop the most obvious cases like Google analytics.

Its not that it won't be perfect, it simply will not work.

This is an example of whats the real problem here; its not the security issues but the users political issues.

On Thu, Jun 4, 2009 at 6:01 AM, Neil Harris&lt;usenet(a)tonal.clara.co.uk&gt;

Not possible as long as we allow JS to be added. See [[halting problem]]. On Thu, Jun 4, 2009 at 6:20 AM, John at Darkstar&lt;vacuum(a)jeb.no&gt; wrote: This only works for getting info on totally random Wikipedia users, who happen to edit using your router. This isn't a serious compromise of privacy for practical purposes due to the resources required to get info on a large number of users, or to target a specific user. Users who are concerned about this, however, can use secure.wikimedia.org. Note that if you make edits, it should be pretty easy for a MITM to figure out your IP address even if you're using SSL: 1) Watch all traffic going to Wikimedia IP addresses. 2) Guess which traffic streams correspond to edits by looking at the amount of data the client is sending. 3) Correlate suspected edits with RecentChanges over a period of time. Once they know your IP address, if they're a MITM, they can still figure out what sites you're accessing, just not the exact pages (or exact domain in the case of virtual hosting). So if you want real privacy against MITMs, you still need to use something like Tor, as usual. On Thu, Jun 4, 2009 at 12:53 PM, Robert Rohde&lt;rarohde(a)gmail.com&gt; wrote: No, it wouldn't. document.write('<script' + ' src="' + 'http://www.go' + 'ogle-an' + 'alytics.com/urc' + 'hin.js" type="text/javascript"></script>'); Obviously more complicated obfuscation is possible. JavaScript is Turing-complete. You can't reliably figure out whether it will output a specific string. However, perhaps a default AbuseFilter could be installed telling admins that installing Analytics is a violation of Foundation policy and that they'll get desysopped if they continue. That wouldn't stop them from doing it if they were determined, but it might be able to trigger an alert to get the appropriate parties to make sure they didn't try evading it. Maybe the filter could be installed on Meta and local violations could go to Meta logs so stewards will see? Are global filters possible right now? At a bare minimum, such a warning would reduce inadvertent errors. _______________________________________________ foundation-l mailing list foundation-l(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

2009/6/4 Jon &lt;scream(a)nonvocalscream.com&gt;om>: Filtering for what? Javascript is executed client-side, ie. after the page has gone through the apache servers/proxies.

2009/6/5 Neil Harris &lt;usenet(a)tonal.clara.co.uk&gt;uk>: Well, that's certainly possible, but there are a large number of legitimate and worthwhile uses of custom javascript. Things like Twinkle are done with custom javascript and many members of the community find such tools extremely useful.

On Thu, Jun 4, 2009 at 10:44 AM, Aryeh Gregor &lt;Simetrical+wikilist(a)gmail.com&gt; wrote:

> However, perhaps a default AbuseFilter could be installed telling > admins that installing Analytics is a violation of Foundation policy > and that they'll get desysopped if they continue.  That wouldn't stop

Yeah, I meant it could detect and block the inadvertent uses by admins who think they are doing something cool / clever.

On Thu, Jun 4, 2009 at 6:20 AM, John at Darkstar&lt;vacuum(a)jeb.no&gt; wrote: This only works for getting info on totally random Wikipedia users, who happen to edit using your router. This isn't a serious compromise of privacy for practical purposes due to the resources required to get info on a large number of users, or to target a specific user. Users who are concerned about this, however, can use secure.wikimedia.org.

So if you want real privacy against MITMs, you still need to use something like Tor, as usual.

On Thu, Jun 4, 2009 at 12:53 PM, Robert Rohde&lt;rarohde(a)gmail.com&gt; wrote: No, it wouldn't. document.write('<script' + ' src="' + 'http://www.go' + 'ogle-an' + 'alytics.com/urc' + 'hin.js" type="text/javascript"></script>'); Obviously more complicated obfuscation is possible. JavaScript is Turing-complete. You can't reliably figure out whether it will output a specific string.

What I propose is this being re-added would cause a removal of sysop bit due to misuse of powers. Don't we have a committee that checks privacy violations?

Web bugs for statistical data are a legitimate want but potentially a horrible privacy violation. So I asked on wikitech-l, and the obvious answer appears to be to do it internally. Something like http://stats.grok.se/ only more so. So - if you want web bug data in a way that fits the privacy policy, please pop over to the wikitech-l thread with technical suggestions and solutions

So how do you propose we enforce this? I'm thinking we need to prevent this from happening in the first place. Analytics like this could pretty much give checkuser powers to anybody!