Hi Anastasia, I think there are a few interesting questions we should consider beyond just, "how much of a concern should this be?" Obviously security is always an important concern. Let's see if we can unpack the potential risk and determine what tools we have available to us for mitigating it.
There's certainly a risk that, if sample code is embedded directly in another page, someone might post a script that could scrape data from the wiki or phish for user input and then send it back to another server via JSONP. That's the nature of mashups. There are a number of ways we could handle this, ranging from only displaying code snippets within an iFrame to reviewing all code examples and posting them as read-only. That said, we've already got some pretty good tools for monitoring changes to our wiki. As a community, there are many of us who keep an eye on every change to our documentation.This lowers the risk quite a bit. To put it another way, we are constantly reviewing all changes to our wiki in real time. As a result, we can probably afford to be welcoming. I think there are some nice low tech, social solutions to issues like this. A combination of isolating sample code in iFrames and ensuring that our community stays vigilant seems like a reasonable balance between openness and caution. Colin On 2011-02-08, at 3:56 PM, Cheetham, Anastasia wrote: > Our goals for the new documentation include (among others): > 1) community editing, and > 2) live demos within pages > > This seems to open up a security concern: Support for community editing could > allow editors to add malicious code to our documentation pages (not that > anyone in our community would do that, but...). > > Some of the proposed systems involve a review process that would prevent this > (source files in git requiring a pull, for example), but some wikis > (Confluence, for example) allow editors to embed HTML and JS right in the > page. > > How much of a concern should this be? Should a vetting provision for code be > a requirement of any system we adopt? Any other thoughts on this issue? --- Colin Clark Technical Lead, Fluid Project http://fluidproject.org _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
