There's been some recent controversy over access to & control over site JS which I'd prefer not to wade into... but it does remind me of some ideas I've been mulling over related to sandboxed JavaScript execution.
Power users need to have an easy way to write, deploy, and use tools that integrate into the wikis: * custom editing tools * custom menu items * custom widgets for the sidebar * that can be enabled widely with a minimum of security worries
(We can make separate tools on Tool Labs already but that provides no UI integration beyond putting links in sidebars or wiki pages.)
JavaScript code can be isolated from the primary execution context by running scripts in an <iframe> based on a distinct domain, with a well-defined "safe" communication channel between it and the parent window over the window.postMessage interface.
I've experimented with this previously in Extension:EmbedScript https://www.mediawiki.org/wiki/Extension:EmbedScriptto try "interactive media"-like things such as graphs with dynamic components or graphical quizzes/games. But I think this could be generalized to utility scripts that hook up to a well-defined portion of the UI or a particular data pipeline.
For instance, a custom citation editor tool might add a toolbar button in the editor (via defined API), then accept input data and be given a chance to display its own UI on activation in a floating iframe, just as if it were a 'native' lightbox-style dialog; on completion it would send the modified text back into the editor through the defined postMessage API, and the editor would save it into the page.
Such a tool would be unable to, say, edit other pages on your behalf unexpectedly, and it would be unable to have side effects on the rest of the UI, but it could be safely selectable on-wiki through an interface like selecting Gadgets...
And that limited integration means much better security and stability controls than gadgets and user scripts can provide today -- a broken or malicious sandboxed widget would only be able to do things you explicitly permit it to.
This sort of clean/limited in-wiki script API might allow for a lot of the stuff that site scripts and auto-enabled Gadgets are used for today, without the related QA, security, and control/side-effect issues.
If folks think this is an interesting idea I'll pick it back up in my research time as I get some of the video stuff I've been working on finished up.
(Note I'm still in the UK for another week and a half, so I'll be reading/replying on lists intermittently until I get back to SF.)
Thoughts on specific classes of tools that might be easy or hard to do with this technique are welcome.
-- brion
Are you thinking about having a full permission system? Like: "This app wants to edit on your behalf." While this sounds cool, I'm not sure the problem this would solve actually exists. We already restrict the ability for editing site script to trusted users, and within this group (on the projects I'm active on) pretty good self control further limited the group that edits the scripts down to admins which actually know what they are doing.
BUT, sandboxed scripts would be an awesome addition to create additional content in article space. I'm thinking programmed animations [1,2,3], small simulation codes [4], which can even be interactive [5,6]. This would add a lot more value to the project than restricting our (imo) well working gadget system.
Cheers, Daniel
[1] http://www.schwen.de/japps/shear.html (Shear mixing of a solid) [2] http://www.schwen.de/japps/fpdemo.html (First passage events in a random walk) [3] http://www.schwen.de/japps/randomwalk.html (Random walk in 3D space) [4] http://www.schwen.de/japps/ising.html (Ising model spin flip Monte Carlo) [5] http://www.schwen.de/jsmd/matse401/ (molecular dynamics simulation) [6] http://www.schwen.de/japps/reciprocal.html (calculate reciprocal space vectors)
On Wed, Aug 13, 2014 at 9:20 AM, Brion Vibber bvibber@wikimedia.org wrote:
There's been some recent controversy over access to & control over site JS which I'd prefer not to wade into... but it does remind me of some ideas I've been mulling over related to sandboxed JavaScript execution.
Power users need to have an easy way to write, deploy, and use tools that integrate into the wikis:
- custom editing tools
- custom menu items
- custom widgets for the sidebar
- that can be enabled widely with a minimum of security worries
(We can make separate tools on Tool Labs already but that provides no UI integration beyond putting links in sidebars or wiki pages.)
JavaScript code can be isolated from the primary execution context by running scripts in an <iframe> based on a distinct domain, with a well-defined "safe" communication channel between it and the parent window over the window.postMessage interface.
I've experimented with this previously in Extension:EmbedScript https://www.mediawiki.org/wiki/Extension:EmbedScriptto try "interactive media"-like things such as graphs with dynamic components or graphical quizzes/games. But I think this could be generalized to utility scripts that hook up to a well-defined portion of the UI or a particular data pipeline.
For instance, a custom citation editor tool might add a toolbar button in the editor (via defined API), then accept input data and be given a chance to display its own UI on activation in a floating iframe, just as if it were a 'native' lightbox-style dialog; on completion it would send the modified text back into the editor through the defined postMessage API, and the editor would save it into the page.
Such a tool would be unable to, say, edit other pages on your behalf unexpectedly, and it would be unable to have side effects on the rest of the UI, but it could be safely selectable on-wiki through an interface like selecting Gadgets...
And that limited integration means much better security and stability controls than gadgets and user scripts can provide today -- a broken or malicious sandboxed widget would only be able to do things you explicitly permit it to.
This sort of clean/limited in-wiki script API might allow for a lot of the stuff that site scripts and auto-enabled Gadgets are used for today, without the related QA, security, and control/side-effect issues.
If folks think this is an interesting idea I'll pick it back up in my research time as I get some of the video stuff I've been working on finished up.
(Note I'm still in the UK for another week and a half, so I'll be reading/replying on lists intermittently until I get back to SF.)
Thoughts on specific classes of tools that might be easy or hard to do with this technique are welcome.
-- brion _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org