|Thread title||Replies||Last modified|
|Iframe sandbox attribute||0||15:36, 24 February 2012|
|Some thoughts||0||14:42, 14 February 2012|
|On the section "Security"||0||07:51, 8 January 2012|
I like this idea very much. A few points:
- It seems like this might blur the distinction between Wikipedia ("encyclopedic content") and Wikiversity ("learning resources", which I've taken to mean this kind of thing), if this is used on WP pages.
- Being able to feed Wikidata into an embedded script opens some interesting possibilities...
- Unless I'm mistaken, while using an off-domain iframe removes the most severe security problems, there could still be issues with the possibility of, say, having the script activate Special:UserLogout, which would be really annoying if it was vandalized onto a semi-protected page. I think it could probably also watch or unwatch pages without the user's consent (or were those changed to require tokens?).
- WebGL in Mediawiki pages. Awesome.
- I can think of lots of places being able to use js on pages could be useful outside the content space, such as in editing tutorials, demonstration of user scripts, easier explaining of certain things for people with good technical abilities but horrible language skills :) ,etc... Hmmm...
- I think this would open up the possibility of audio running without the reader's consent, which was previously impossible. I don't think that would be really considered a major issue, though. (And plugins running from unsafesubdomainofdoom.wikimedia.org are not safe, good for people to know :P )
- All iframes must be clearly iframes, if phishing is to be avoided (I think?).
- Is it likely enough that this is going to be enabled on Wikimedia wikis at some point that it would make sense for people to start creating ES's in advance? If so, it might make sense to publicize this somewhat.
Tl;dr JS in content, must have.