Extension talk:EmbedScript

From MediaWiki.org
Jump to: navigation, search
Start a new discussion

Contents

Thread titleRepliesLast modified
Some thoughts122:33, 20 March 2014
Iframe sandbox attribute015:36, 24 February 2012
On the section "Security"007:51, 8 January 2012

Some thoughts

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.

Yair rand14:42, 14 February 2012

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.
Yair rand (talk)22:33, 20 March 2014
 

Iframe sandbox attribute

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

Jeblad (talk)15:36, 24 February 2012

On the section "Security"

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?

Jeblad 05:07, 3 January 2012 (UTC)07:51, 8 January 2012