On Mon, Jun 29, 2009 at 7:56 PM, Aryeh Gregor<[email protected]> wrote: > I think this would be reasonable to consider implementing as soon we > have a significant number of users using it. It isn't a good idea to > make CSP policies that won't actually be effective immediately for a > lot of people, because then we'll probably use it incorrectly, break > tons of stuff, and not even notice for months or years (possibly even > harming uptake of the first version of Firefox to support it). > This does seem to be Mozilla-only, though. If it were an open > specification that multiple vendors were committed to implementing, > that would make it significantly more attractive. I wonder why > Mozilla isn't proposing this through the W3C from the get-go.
When to do it is a philosophical issue: Arguably it should be turned on early so that the early adopters of the technology (i.e. firefox devs!) will be test subjects. Support for audio/video tag in Wikipedia has been helpful in the development of firefox audio and video tag support. If the feature is turned on only once these clients are widely deployed then we'll have a situation where things may be broken for many users. So— turn it on early and have many things will broken for a small number of technically savvy users, up to the point potentially slowing the adoption of a future browser release. ... or turn it on later when it will likely cause a few problems but for 30% of the sites visitors? The latter sounds like too much of a flag-day. The stuff likely to stay broken after the initial implementation are things like userscripts. Those are just going to take a long time to fix no matter what. The best thing there would be to communicate the correct practices well in advance so that the natural development cycle picks them up, but I'm not aware of any way to communicate such a thing except by making the wrong ways not work. > We'd have to do some work to get full benefit from this, since we > currently use stuff like inline script all over the place. But it Right, though with all the minification interest I've seen here lately it sounds like a great time to hoist all that stuff out of the pages. > would be fairly trivial to use only *-src to deny any remote loading > of content from non-approved domains, and skip the rest. That would > at least mitigate XSS some, but it would stop the privacy issues we've > been having cold, as you say. I think one really compelling thing about it is that supporting clients can provide feedback to the webserver. This means that every supporting user will be an XSS test probe, a canary in the page-mine. So even if this doesn't become standardized and widely adopted by clients other than firefox it would reduce the damage of unintentional but well meaning privacy leaks since we'd get notice of them very quickly rather than months later. Hopefully this will be more widely adopted, because I think that the available knobs provide a level of functionality which we couldn't achieve any other way. (i.e. we could deny html/script injection completely in mediawiki, but limiting scripts to accessing particular domains isn't something mediawiki could reasonably do itself) I don't know enough to comment on the W3C path— but I have no particular reason to think it wouldn't happen: W3C activity is almost universally lagging rather than leading. Things like this aren't generally matters for discussion unless someone is thinking of implementing them. _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
