2009/6/4 Daniel Kinzler <daniel(a)brightbyte.de>de>: If putting that on the toolserver passes privacy policy muster, that'd be an excellent solution. Then external site loading can be blocked. (And if the toolservers won't melt in the process.) - d.

2009/6/4 Michael Rosenthal <rosenthal3000(a)googlemail.com>om>: I understand the problem with stats before was that the stats server would melt under the load. Leon's old wikistats page sampled 1:1000. The current stats (on dammit.lt and served up nicely on http://stats.grok.se) are every hit, but I understand (Domas?) that it was quite a bit of work to get the firehose of data in such a form as not to melt the receiving server trying to process it. OK, then the problem becomes: how to set up something like stats.grok.se feasibly internally for all the other data gathered from a hit? (Modulo stuff that needs to be blanked per privacy policy.) - d.

On Thu, Jun 4, 2009 at 17:00, Gregory Maxwell <gmaxwell(a)gmail.com> wrote: On top of views/page I'd be interested in keywords used, entry&exit points, path analysis when people are editing (do they save/leave/try to find help/...) #edit starts, #submitted edits that don't get saved. henna -- "Maybe you knew early on that your track went from point A to B, but unlike you I wasn't given a map at birth!" Alyssa, "Chasing Amy"

On Fri, Jun 5, 2009 at 1:00 AM, Gregory Maxwell<gmaxwell(a)gmail.com> wrote: A good question. Related questions are: 1) what can't be built into stats.grok.se (or other services built on the same data)? 2) is there anything that really needs to be done by javascript? Don't forget all of the currently available traffic analysis here: http://stats.wikimedia.org/EN/VisitorsSampledLogRequests.htm -- Stephen Bain stephen.bain(a)gmail.com

Michael Rosenthal wrote: If Javascript was used to serve the bug, it would be quite easy to only load the bug some small fraction of the time, allowing a fair statistical sample of JS-enabled readers (who should, I hope, be fairly representative of the whole population) to be taken without melting down the servers. I suspect the fact that most bots and spiders do not interpret Javascript, and would thus be excluded from participating in the traffic survey, could be regarded as an added bonus. -- Neil

2009/6/4 Mike.lifeguard <mikelifeguard(a)fastmail.fm>fm>: Because having the data go outside Wikimedia at all is a privacy policy violation, as I understand it (please correct me if I'm wrong). - d.

On Thu, Jun 4, 2009 at 11:01 AM, Mike.lifeguard <mikelifeguard(a)fastmail.fm> wrote: Because: (1) External loading results in an uncontrolled leak of private reader and editor information to third parties, in contravention of the privacy policy as well as basic ethical operating principles. (1a) most external loading script usage will also defeat users choice of SSL and leak more information about their browsing to their local network. It may also bypass any wikipedia specific anonymization proxies they are using to keep their reading habits private. (2) External loading produces a runtime dependency on third party sites. Some other site goes down and our users experience some kind of loss of service. (3) The availability of external loading makes Wikimedia a potential source of very significant DDOS attacks, intentional or otherwise. Thats not to say that there aren't reasons to use remote loading, but the potential harms mean that it should probably be a default-deny permit-by-exception process rather than the other way around.

2009/6/4 Mike.lifeguard <mikelifeguard(a)fastmail.fm>fm>: I can't think of any time when we would need to load anything from an external site, so why not block them completely and eliminate the privacy concern entirely?

2009/6/4 Brian <Brian.Mingus(a)colorado.edu>du>: Detailed analysis of how users actually use the site would be vastly useful in improving the sites' content and usability. - d.

2009/6/4 Brian <Brian.Mingus(a)colorado.edu>du>: Yep. They'd dive on this stuff with great glee if we can implement it without breaking privacy or melting servers. - d.

2009/6/4 Gregory Maxwell <gmaxwell(a)gmail.com>om>: Is it feasible to allow admins to use raw HTML as appropriate but not raw JS? Being able to fix MediaWiki: space messages with raw HTML is way too useful on the occasions where it's useful. - d.

Daniel Kinzler wrote: Not if you sanitize the HTML after the fact: just cleaning out <script> tags and elements from the HTML stream should do the job. After this has been done to the user-generated content, the desired locked-down script code can then be inserted at the final stages of page generation. -- Neil

On 04/06/2009, at 4:08 PM, Daniel Kinzler wrote: When did we start treating our administrators as potentially malicious attackers? Any administrator could, in theory, add a cookie-stealing script to my user JS, steal my account, and grant themselves any rights they please. We trust our administrators. If we don't, we should move the editinterface right further up the chain. -- Andrew Garrett Contract Developer, Wikimedia Foundation agarrett(a)wikimedia.org http://werdn.us

On Thu, Jun 4, 2009 at 12:04 PM, Andrew Garrett &lt;agarrett(a)wikimedia.org&gt; wrote: 90% of possibly malicious the things administrators could possibly do is easily un-doable. Most of the remainder is limited in scope to impacting few users at a time. Site wide JS can cause irreparable harm to users privacy and do it to hundreds of thousands in an instant. Outside of raw html and JS no other admin feature grants the ability to completely disable third party sites. And forget malice— there is no reason for admins to add remote loading external resources. Any such addition is going to violate the privacy policy. Yet it keeps happening. You don't have to be malicious to be completely unaware of the privacy implications or of the potential DOS risks. You don't have to be malicious to use the same sloppy editing practices which are used on easily and instantly revertible articles while editing site messages and JS (Caching ensures that many JS and message mistakes aren't completely undone for many hours). Though we shouldn't preclude the possibility of occasional malice: It isn't as though we haven't had admin's choose easily guessable passwords in the past, or admins flip their lids and attempt to cause problems. In places where the harm is confined and can be undone softer security measures make sense. As the destructive and distractive power increases the appropriate level of security also increases. We impose stiffer regulation for access permissions like checkuser… even though an admins ability to add webbugs is significantly more powerful a privacy invasion tool than checkuser. (Checkusers can't see typical reader activities!) Raw HTML and JS have drastically different implications than most other 'admin' functions. Accordingly the optimal security behaviour is different. When there are few enough admins the problems are infrequent enough to ignore, but as things grow... The number of uses of site-wide JS and Raw HTML are fairly limited. As are the number of users with the technical skills required to use them correctly. Arguably every instance of user manipulation of raw HTML and site-wide JS is a deficiency in mediawiki. Regarding HTML sanitation: Raw HTML alone without JS is enough to violate users privacy: Just add a hidden image tag to a remote site. Yes you could sanitize out various bad things, but then thats not raw HTML anymore, is it? I think the biggest problem to reducing accesses is that far more mediawiki messages are uncooked than is needed. Were it not for this I expect this access would have been curtailed somewhat a long time ago.

Actually you can take a lesson from Google, and every once in a while prefix all links e.g., "http://en.wikipedia.org/url?http://en.wikipedia.org/wiki/Norflblarg". (some kind of recording redirector). How do I know Google does this every so often in their search results pages? I use DontGet{:*://*.google.*/url?*} in my wwwoffle.conf file, so the alarm bells ring, whereas the average user would never notice the difference.

On Thu, Jun 4, 2009 at 2:32 PM, David Gerard &lt;dgerard(a)gmail.com&gt; wrote: See bug 212[1], which is (sort of) a tracker for the wikitext-ification of the messages. -Chad [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=212

You don't have to inject javascript to do user tracking. This is possible with all kind of raw html that leads to inclusion of external elements, including style defs for ordinary markup. John Daniel Kinzler skrev:

K. Peachey wrote: eswiki doesn't allow Fair Use images. It doesn't even allow loacl uploads. I could upload it at commons, but would be deleted in hours. Uploading at enwiki might be an option, but not a good one. English Wikipedia images are not there to serve other projects, and although they could survive more time would finally be deleted. Another option would be the toolserver but: a) I don't have an account there (yet). b) I was afraid of producing too much load for the toolserver. Also, it might need a special provision, per Duesentrieb's email (that may need to be clarified at the rules page).

Gregory Maxwell wrote: That's a reasonable point. It's a matter of discussion for the community, though. I agree that those remotely loaded images are undesirable. But the inline images at the search page are conceptually different from those at articles. The images at the search page "belong" to the skin. Not to mention that uploading into a wiki where they shouldn't otherwise be allowed, will inevitably lead to someone trying to use them on articles.