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(a)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:EmbedScript>to 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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l