• https://www.mediawiki.org/wiki/User:Brion_VIBBER/Secure_code_modules_through_iframe_sandboxing
• https://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/

Discussion:

Galder:
As a staff job there is a student who wonders if they can add interactive content to a wikipedia article in order to augment prose.
Examples of interactive content:

• Compare https://en.wikipedia.org/wiki/Moons_of_Jupiter with observation guide for Jupiter's moons on https://www.skyandtelescope.com *
• pages in eswiki that use wikiwidgets (https://es.wikipedia.org/wiki/Hormiga_de_Langton and https://es.wikipedia.org/wiki/Juego_de_la_vida)
• jupyter.org used for physics simulations (https://myphysicslab.com/)
• wdqs output can be interactive, but can't be embedded in wikipedia

Question: what are the main things preventing us from having this kind of interactive content in wiki pages?

TheDJ: One of the reasons: javascript is executing code which has security considerations. MediaWiki has no protections by default, and if we allowed arbitrary javascript on a page it could access session cookies and perform actions as a user
iframes could be used to solve some issues, but it's an inefficient and complicated way in its own.
Also there are problems to do with the amount of computation the browser is required to do - had probelms in the past with animated gifs, where 50 gifs on a page would crash it

Dan Andreescu: It is possible in limited scope to do some things. Graph extension exists that allows some interactivity in some data-driven documents, uses Vega.
We also have lua. We can do a lot of things using those 2 technologies. Render data as text in some cases until we can find a way to sandbox it.

Daniel Kinzler: PAWS is a jupyter instance we host in labs. It allows us for now to visualize our own metadata/data. Maybe when we can have machine readable data in wikipages, maybe we can have something in toolforge that interacts with it and it's pretty safe. But we couldn't have it directly within the wikipage.
Animations wise, there is 2 different things. Antimations sounds like an arbitrary code running and we will never allow it. Very specific use cases (maybe have a planetary orbits plugin that we provide data to) could be ok.

Bryan Davis: Linking to PAWS to provide interactive visualizations to all logged-out users is currently unfeasible. PAWS is supported by a single developer.
For javascript it's the isolation that's the key problem. Un-sandboxed code. Fears, well founded ones in fact, about cookies that allow code to interact as if they were you. Arbitrary javascript in the production sites. Years ago, Brion spent time investigating ways to use a combinnation of iframes and other features to embed content in the page, that looks like it's part of the page but is actually an isolated part. I think that's the direction to focus in. Dan is talking about intermediary solutions, find a language [?] we trust and source we can trust, to allow arbitrary interaction.

DK: JS is unsafe yes, but currently in gadgets, so... why not allow the same thing. Trusted volunteers being able to do that. But this is in constrast to us trying to figure a way to cut down on javascript.

BD: That's also an accessbiliy problem, because anyone currently needs to go via an Interface Admin to get any code updates done to gadgets (because in MediaWiki namespace).

Timo: Gadgets is indeed one of the things we want to reduce on and want things per page, with more than the people that can do that today.
What is the floodgate of JS code that the current people that handle Gadgets can't work with?

TheDJ: That's another problem. Technology problem mixed with the usability problem. We saw examples of web applications, e.g. the physics demos, but it's completely different from any animation anyone else has written. This is why Yuri used Vega when he started Graphs. Instead of having everyone write the interactive controls. Portable and reusable foundation. Simple and exchanageable. But these physics demos do not use that foundation
Just like it is hard to write a good 3d model, it's a complex technical skill to write a good physics demo. Or even a good graph in Vega.

DK: Histropedia is a bad example as it is very very related to wikidata.
Questions about wdqs being exposed in Wikipedia. Whether it c/sh/would be live (cache issues). Static embed is currently possible [?].

DK: Graphoid is one of the first attempts and it's currently unmaintained and kind of hacked in and it's to be undeployed. Data driven interactions are feasible and should doable. Example shown of live interactive graph: https://en.wikipedia.org/wiki/Obesity#History

Timo: A potential middleground is that while vega is powerful but it can be very difficult to handle if you want interactivity. Perhaps we can abstract it in some lua code that generates some JSON code. We could allow a subset of javascript in a not so "secure" gadget to try to blur the line between the two.

Galder: Appreciation for all these good details about why it is complicated, and how it could potentially move forward.

DA: Medium Term Planning supposedly has rich media in it.

@Theklan / @Cparle: Thank you for hosting this session. This open task only has the archived project tag Wikimedia-Technical-Conference-2019.
If there is nothing more to do in this very task, please change the task status to resolved via the Add Action... → Change Status dropdown.
If there is more to do, then please either add appropriate non-archived project tags to this task (via the Add Action... → Change Project Tags dropdown), or make sure that appropriate follow up tasks have been created and resolve this very task. Thank you for helping clean up!