A cookie is a piece of data stored by a website in your web browser and made available to that site when you use the site. (see [[HTTP cookie]] for more info)
For a while people have thought it would be useful to use cookies as part of our blocking system. The idea is that when a user is blocked, mediawiki would give them a cookie to indicate that they are blocked. This would then inhibit them from editing even if they changed IPs. The primary limitation to this approach is that any terminologically savvy user could easily remove the cookie.
There is a request filed for this feature (http://bugzilla.wikimedia.org/show_bug.cgi?id=3233) along with a patch, but this patch has not yet been merged into mediawiki.
Because interest for this feature keeps reoccurring, I threw together a quick hack using javascript. This method of implementation allows us to experiment and gauge the value of the approach without distracting the core developers with more code to merge and support.
This could be implemented by any admin on an of our wiks. http://commons.wikimedia.org/w/index.php?title=MediaWiki:Monobook.js&dif...
Like all cookie based solutions, it is easy to bypass. Its primary disadvantage compared to the mediawiki patch is that it is not integrated with the block page, to activate a cookie based block you must make a separate edit to the target user's javascript.
The current behavior blocks all uploads and edits by the impacted browser, but it would be fairly trivial to make the function more like regular blocking... or even more fine grained with per-namespace or per article blocks. The current behavior also renews the block for 24 hours every time the user *views* a page while logged in as the blocked user. This too could be trivially changed.
If anyone tries this out or improves it, please let me know. I pretty much learned javascript in order to do this.. and it only took about 15 minutes to do, so don't expect it to work miracles but it should work as advertised.
A better solution is to embed the MAC address of the workstation into the cookie itself, so you can track someone no matter what account or IP they use.
Jeff
Gregory Maxwell wrote:
A cookie is a piece of data stored by a website in your web browser and made available to that site when you use the site. (see [[HTTP cookie]] for more info)
For a while people have thought it would be useful to use cookies as part of our blocking system. The idea is that when a user is blocked, mediawiki would give them a cookie to indicate that they are blocked. This would then inhibit them from editing even if they changed IPs. The primary limitation to this approach is that any terminologically savvy user could easily remove the cookie.
There is a request filed for this feature (http://bugzilla.wikimedia.org/show_bug.cgi?id=3233) along with a patch, but this patch has not yet been merged into mediawiki.
Because interest for this feature keeps reoccurring, I threw together a quick hack using javascript. This method of implementation allows us to experiment and gauge the value of the approach without distracting the core developers with more code to merge and support.
This could be implemented by any admin on an of our wiks. http://commons.wikimedia.org/w/index.php?title=MediaWiki:Monobook.js&dif...
Like all cookie based solutions, it is easy to bypass. Its primary disadvantage compared to the mediawiki patch is that it is not integrated with the block page, to activate a cookie based block you must make a separate edit to the target user's javascript.
The current behavior blocks all uploads and edits by the impacted browser, but it would be fairly trivial to make the function more like regular blocking... or even more fine grained with per-namespace or per article blocks. The current behavior also renews the block for 24 hours every time the user *views* a page while logged in as the blocked user. This too could be trivially changed.
If anyone tries this out or improves it, please let me know. I pretty much learned javascript in order to do this.. and it only took about 15 minutes to do, so don't expect it to work miracles but it should work as advertised. _______________________________________________ foundation-l mailing list foundation-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/foundation-l
Jeffrey V. Merkey wrote:
A better solution is to embed the MAC address of the workstation into the cookie itself, so you can track someone no matter what account or IP they use.
It should be obvious that you can't obtain the MAC address using any documented Java or JavaScript interface, that would be a privacy issue. I once suggested a browser plugin, "click yes at the security dialog box to allow editing from AOL", but for some reason the response from those present was not positive... You might expect some anti-spyware advocates to get annoyed, since in essence that's what it would be. Then there's the issue of trusting data from the client: if you want to add anti-debugger and anti-disassembly measures then it becomes a significant development task, and no such measure is perfect anyway.
-- Tim Starling
Tim Starling wrote:
Jeffrey V. Merkey wrote:
A better solution is to embed the MAC address of the workstation into the cookie itself, so you can track someone no matter what account or IP they use.
It should be obvious that you can't obtain the MAC address using any documented Java or JavaScript interface, that would be a privacy issue.
I think you can, but yes, this is an intrusion of peoples privacy.
Jeff
I once suggested a browser plugin, "click yes at the security dialog box to allow editing from AOL", but for some reason the response from those present was not positive... You might expect some anti-spyware advocates to get annoyed, since in essence that's what it would be. Then there's the issue of trusting data from the client: if you want to add anti-debugger and anti-disassembly measures then it becomes a significant development task, and no such measure is perfect anyway.
-- Tim Starling
foundation-l mailing list foundation-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/foundation-l
Hi!
I think you can, but yes, this is an intrusion of peoples privacy.
*grin* http://forum.java.sun.com/thread.jspa? threadID=615562&messageID=3424234
Quote for lazy ones: "Java has no native way of finding a MAC address, because there's really nothing you can do with it." Some workarounds are on that page. I doubt anyone would run (or want to code) such java bits.
wikimedia-l@lists.wikimedia.org