On Feb 18, 2008 2:25 AM, tstarling@svn.wikimedia.org wrote:
- Removed nonsense warning about the output of wfMsg() not being safe for inclusion in HTML.
I assume what Erik meant there is that it may output arbitrary HTML, and we're trying to move away from allowing sysops to insert arbitrary HTML into pages.
Simetrical wrote:
On Feb 18, 2008 2:25 AM, tstarling@svn.wikimedia.org wrote:
- Removed nonsense warning about the output of wfMsg() not being safe for inclusion in HTML.
I assume what Erik meant there is that it may output arbitrary HTML, and we're trying to move away from allowing sysops to insert arbitrary HTML into pages.
It's safe to allow sysops to insert arbitrary HTML into pages. This is because we trust sysops. If it's unsafe to allow them to add arbitrary HTML, we should immediately remove their equally dangerous ability to edit MediaWiki:Monobook.js. But we don't, because we trust them.
A security model has to be derived from a threat model. There is no threat which would be eliminated by removing all HTML messages. There is also no threat which would be eliminated by scaremongering in source code comments for several years.
-- Tim Starling
On Feb 18, 2008 9:46 PM, Tim Starling tstarling@wikimedia.org wrote:
It's safe to allow sysops to insert arbitrary HTML into pages. This is because we trust sysops. If it's unsafe to allow them to add arbitrary HTML, we should immediately remove their equally dangerous ability to edit MediaWiki:Monobook.js. But we don't, because we trust them.
A security model has to be derived from a threat model. There is no threat which would be eliminated by removing all HTML messages. There is also no threat which would be eliminated by scaremongering in source code comments for several years.
Well, I've said all that to Brion, but he didn't agree. :) He wants to get rid of all HTML-permitting messages. Actually, I think part (most? all?) of his concern is that sysops shouldn't be expected to know HTML, or to be capable of outputting remotely valid HTML, and so formatting should always be achieved via wikitext. Or something like that. It's been a while.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Simetrical wrote:
Well, I've said all that to Brion, but he didn't agree. :) He wants to get rid of all HTML-permitting messages. Actually, I think part (most? all?) of his concern is that sysops shouldn't be expected to know HTML, or to be capable of outputting remotely valid HTML, and so formatting should always be achieved via wikitext. Or something like that. It's been a while.
It sounds like (and I don't know what Brion is thinking, but here's my humble opinion) Brion is calling for a separation Wikitext and HTML/JavaScript, although not for security reasons. Monobook.js must be written in JavaScript--that's the nature of the beast; however, a system message should not have JavaScript or HTML, using Wikitext when possible. (Note that Wikitext contains HTML-like constructs, but they're guarded by validation routines).
Edward Z. Yang wrote:
Simetrical wrote:
Well, I've said all that to Brion, but he didn't agree. :) He wants to get rid of all HTML-permitting messages. Actually, I think part (most? all?) of his concern is that sysops shouldn't be expected to know HTML, or to be capable of outputting remotely valid HTML, and so formatting should always be achieved via wikitext. Or something like that. It's been a while.
It sounds like (and I don't know what Brion is thinking, but here's my humble opinion)
Well, to speak for myself... :)
There are several basic issues which lead me to prefer a minimization of raw HTML messages:
* Consistency (principle of least surprise)
Some messages are raw HTML, some are wikitext, some are plain text... it gets confusing when you're trying to customize something and you didn't know ahead of time what did what.
Reducing/eliminating at least one of those possibilities makes it easier to predict what will happen when you customize a message, and that's a good thing.
* Correctness
HTML is fragile, and when mistakes are made customizing the raw HTML, things can break in... interesting ways. :) Worst case, in full XHTML mode you just won't be able to see the site in your browser anymore after breaking the markup.
In theory, wikitext messages are more robust. In practice, we currently skip some of the HTML validation on wikitext messages for performance reasons, so this is presently limited.
* Security (principle of least privilege)
The number of sysops continues to grow on large sites like Wikipedia; the trouble of an admin account run amok also increases. One of the potential dangers is injecting JavaScript into the HTML that all other users load.
Reducing the ability to edit raw HTML/JS/CSS editing to a smaller user group would decrease the attackable surface. As long as we use raw HTML messages, the privilege to customize those UI translations implies the ability to inject global JavaScript.
If we separate the customization and translation of UI strings from the customization of global CSS and JavaScript, it would then become possible to separate those two privileges to differently-sized and differently-vetted groups.
-- brion vibber (brion @ wikimedia.org)
In general, yes. But when dealing with things like checkuser or oversight, where JS injection could release info that sysops could not otherwise have, it makes me a bit worried, so I try to escape HTML, such as via wikitext. I suppose it is not *likely* to matter, but still, it is another gap filled.
-Aaron Schulz
To: wikitech-l@lists.wikimedia.org From: tstarling@wikimedia.org Date: Tue, 19 Feb 2008 13:46:51 +1100 Subject: Re: [Wikitech-l] [MediaWiki-CVS] SVN: [31044] trunk/phase3
Simetrical wrote:
On Feb 18, 2008 2:25 AM, tstarling@svn.wikimedia.org wrote:
- Removed nonsense warning about the output of wfMsg() not being safe for inclusion in HTML.
I assume what Erik meant there is that it may output arbitrary HTML, and we're trying to move away from allowing sysops to insert arbitrary HTML into pages.
It's safe to allow sysops to insert arbitrary HTML into pages. This is because we trust sysops. If it's unsafe to allow them to add arbitrary HTML, we should immediately remove their equally dangerous ability to edit MediaWiki:Monobook.js. But we don't, because we trust them.
A security model has to be derived from a threat model. There is no threat which would be eliminated by removing all HTML messages. There is also no threat which would be eliminated by scaremongering in source code comments for several years.
-- Tim Starling
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_________________________________________________________________ Helping your favorite cause is as easy as instant messaging. You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join
wikitech-l@lists.wikimedia.org