On Thu, Jun 4, 2009 at 12:04 PM, Andrew Garrett <[email protected]> wrote: >>> 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. >>> >> >> Possible yes, sensible no. Because if you can edit raw html, you can >> inject >> javascript. > > > 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.
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. _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
