Extension talk:EmbedScript/Flow

Previous page history was archived for backup purposes at Extension talk:EmbedScript/LQT Archive 1 on 2015-07-10.

The phrase "the real sandbox page" is dificult to interpret. Is it an automatic generated page for the iframe or is it the javascript code for the iframe aka the worker code?

This post was posted by Peachey88 (Flood), but signed as Jeblad.

I'm starting this project back up; following up on some old comments. :)

'the real sandbox page' here refers to the original HTML that appears in the iframe before we inject script code into it. 'real' here is to distinguish from a malicious attacker.

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...
• In a while, it seems like users are going to need to know javascript, CSS, Lua, and parserfunctions in order to be able to edit all layers of the content, which is up from the current CSS, parserfunctions, magic words, and wikitext formatting. I'm not sure whether this is something to be concerned about.
• 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.
• Having part of the content dependent on actual javascript limits the potential reuse of Wikimedia projects. Printed pages, audio versions, Wikipedia readers, etc. won't be able to make use of embedded scripts, so no ES's can really be allowed to be vital to the article.
• 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.

More:

• There have been requests for expandable trees that can load further Wikidata content on-demand. It could be useful if the iframe could request that the parent frame retrieve Wikidata content via the API. (Things like Wikidata's d:Template:Tree can only load so much at once...)
• Not all users will be able to use the embedded scripts, either due to JS being disabled, certain features being unsupported, etc. This issue could be alleviated somewhat by adding the option to add fallback content.
• Using the sandbox attribute eliminates risks of plugins, along with certain other risks.
• Embedded scripts could allow for some very cool data visualizations, perhaps using things like the D3.js library.

I'm starting this project back up; following up on some old comments. :)

• Re: some of the potential issues with unexpected audio content, etc -- click-to-play might make sense, though currently I've got it running things 'live'.
• Related & re: printable/offline/no-JS content -- I'm thinking about reworking it from standalone JS scripts to a structured code tree including HTML scaffold, CSS, JS, and "fallback content" methods. The fallback content, or a variant of it, could also do a "snapshot" or "thumbnail" to be shown before we load the live code, if we do click-to-play.
• I'm VERY interested in being able to query data, but need to think about the security implications of doing things on the user's behalf
• Visualizations could kick butt -- reminds me need to provide some sort of library functionality maybe

There is a new iframe sandbox attribute that can be used to even further limit the code. There are also a blogpost at MSDN discussing this feature. Jeblad (talk) 15:36, 24 February 2012 (UTC)

I'm starting this project back up; following up on some old comments. :)

Yeah, looks like sandbox="allow-scripts" may be what we want; disables some things but still allows scripting. I'll want to make sure that doesn't break the postMessage though...