- Ability to 'act as the editor' without their consent.
- Ability to re-write the mediawiki user interface, as vandalism, as advertising, for tracking users, for misinformation, censorship, DDOS attacks, bitcoin-mining, invasion of privacy.
Scratch and SNAP appear to be able to offer a programming language for animations that is sufficiently safe, and moreover is suitable for children. Programs are written and shared, and it is expected that people will run and adapt each others code.
In the context of children, the Scratch and SNAP environment designers must additionally be alert to inappropriate content and also guard against bad actors creating private online communication channels to minors.
- Scratch and SNAP DO operate safely.
- Code that might allow 'sandbox escape' is easy to identify, easy to analyse and only in a small part of the code.
- Visual design (of the frame around a diagram) is needed to ensure that diagrams can't fake it as other user interface elements.
- New vandalism risks can be addressed by extending existing template policy to diagram subroutines, and by ethos of 'No Easter Eggs'.
- External communication outside Wikipedia should be barred for diagram scripts, and internal communications, e.g. to fetch more data, rate-limited.
- Long complex scripts are suspicious, and rarely needed (they can be broken down into approved subroutines). Complex, hence suspicious, scripts can be automatically detected and flagged for admin attention.
- Any 'writing to the dom', as with the .innerHTML property must be 'cleaned', since it would otherwise allow code to be injected.
The high level primitives available must operate on the diagram and not bridge to global scope. Variables in the block based language, for example, are properties of the diagram, not properties 'at global scope'.
These technical measures are relatively easy to verify. There are many well known hacking techniques designed to thwart code that 'cleans' text of potentially dangerous content. The part of the code that needs to be carefully checked for these dangers is very small - for example the code that provides the text in the large tooltips. The security risk is mostly from future revisions that invalidate the analysis. For example, someone adds more flexibility to the tooltips in code that comes after the 'cleaning', or adds a new and convenient block type, that uses eval() or .innerHTML.
Apple prohibit programming apps on their iPhones/iPads unless the programs running in the programming app use less than 80% of the screen area and have a clear boundary or frame indicating that a script is running in a software development environment. They do this to prevent a program passing itself off as some other program, e.g. to capture passwords.
For Wikipedia the diagrams would need to be similarly restricted. A standard 'frame' is needed to indicate an interactive diagram.
Future revisions risk eroding that safeguard. It may become tempting to re-use the diagram interface for user interface in Wikimedia, so that later extensions to the current diagram code expose user parameters and preferences. Part of security planning then is a style guide to prevent erosion of the distinction in look between diagrams and built-in interface features.
The existing template mechanism of mediwiki already creates a vandalism risk. Modification of one popular template can affect a very large number of pages. This risk is handled by protecting popular templates.
Interactive diagrams will create an additional risk. The vandalism may not be obvious at time of review. For example vandalism could trigger on a particular day, e.g. to coincide with an IPO.
To counter that, long complex scripts will be discouraged. The templates/subroutines mechanism will be used more, so as to keep code short, clear and understandable. This will make it easier to review code, with the side benefit of lowering the barrier to using interactive features.
There will also need to be an ethos of 'No Easter Eggs' in diagrams. That is, no hidden features that only show in special circumstances.
Although Scratch and SNAP offer date and time of day, the diagram language shouldn't. This rules out some nice diagrams, such as a real-time sundial, moon phase or time zones map. Perhaps if 'blessed by an admin' a diagram could be allowed access to the time functions. I think it's wiser to not do so, and table it as a possible future enhancement.
URLs in interactive diagrams should be Wikimedia controlled, otherwise: a) Scripts can bring in content that is not reviewed/checkable. b) Scripts can exfiltrate information, e.g. by accessing custom URLs. c) Scripts become a vehicle for ad fraud. d) DDOS atacks against external sites are likely.
There will be similar problems to those OpenStreetMaps experiences. Like maps, some diagrams may be backed by a lot of data. These problems can be addressed in the same ways OpenStreetMaps does - by limiting preloading of data and caching 'lower resolution' data.
Restricting external communications goes a long way towards preventing bad actors using Wikipedia viewers' processing power for their own purposes. Even so, a bitcoin mining script could be invisible most of the time, and show a message such as 'One bitcoin mined! Scan this QR code to claim your half of $9,469 USD Today!', if it found a bitcoin.
Google monitor their servers to look for characteristics of bitcoin mining on their free introductory offer servers. Bitcoin mining looks likely to be a minor problem, and probably suspicious scripts can be easily automatically flagged for closer inspection by an admin.