John at Darkstar wrote: > > Alex skrev: >> John at Darkstar wrote: >>>> 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. >>>> >>> A very typical code fragment to make a stat url is something like >>> >>> document.write('<img scr="' + server + digest + '">'); >>> >>> - server is some kind of external url >>> - digest is just some random garbage to bypass caching >>> >>> This kind of code exists in so many variants that it is very difficult >>> to say anything about how it may be implemented. Often it will not use a >>> document.write on systems like Wikipedia but instead use createElement() >>> Very often someone claims that the definition of "server" will be >>> complete and may be used to identify the external server sufficiently. >>> That is not a valid claim as many such sites can be referred for other >>> purposes. >> Other purposes that have valid uses loading 3rd party content on a >> Wikimedia wiki? Like what? > > If you don't trust other sites you also has to accept that you can't > trust ant kind of «toolserver» where you don't have complete control. > That opens a lot of problems
Its not just a matter of trust, its a matter of use. Why would people be loading content from or linking to servers used to collect website stats in the sitewide JS on a Wikimedia wiki? >>> Note also that the number of urls will be huge as this type of >>> service is very popular, not to say that anyone that want may set up a >>> special stat aggregator on an otherwise unknown domain. >>> >>> Basically, simple regexps are not sufficient for detecting this kind of >>> code. >> 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. And anything more complex would likely be too complicated and/or too inefficient to be worthwhile. > John > > _______________________________________________ > foundation-l mailing list > foundation-l@lists.wikimedia.org > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l > -- Alex (wikipedia:en:User:Mr.Z-man) _______________________________________________ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l