[Building Sakai] Proposal: User Content / Markup and Security Meeting

[Noah Botimer]

John,

Thanks. I agree with everything you say here and it adds helpful detail. My summary was perhaps too brief.

To your introduction, I think it is fair. I've been considering most specifically the plain/rich text fields, seeing security and technical sustainability of 2.x at the core for this round (noting a number of stumbling blocks in 2.6/2.7). I see that this could be artificially limiting of the most appropriate strategic discussion.

I see the up-front research as a prerequisite. There is no sense in wasting a meeting on rehashing this summary and opinions therein, which is perfectly efficient asynchronously.

My mind is on the application of the findings for realtime discussion. Any research and ideas on the format of the compilation are more than welcome.

I do see that there has to be a pretty technical discussion (in your second part) about policies, storage, processing in different UI toolkits, best practices, and a migration mechanism. There are a lot of tools that use what's there now and a graceful transition has to have some negotiation. I bring it up now because this is the kind of thing that should start happening at the beginning of a release cycle (2.8, and Sakai 3 if you squint). We know that there are enough contextual forces to make this a good idea; this is just a rallying effort to try to make it go.

I'll give it a couple more days to gauge interest and start rough-sketching the homework and agenda. Help is very welcome.

Thanks,
-Noah

On Apr 9, 2010, at 4:51 AM, John Norman wrote:

> Hi Noah
> 
> I have the impression that you have something quite specific in mind that I am not seeing clearly. I would like to unpack a bit. I *think* I am hearing: Sakai accepts user input in a number of places. There are different expectations in different settings regarding the need for user control over text formatting and other products (such as blogs) are setting expectations that user input should no longer be limited to text, but should readily include video, images and other sorts of unpredictable content elements. If we respond to this demand by enabling very flexible editing tools to create the user inputs, or even accept pasted-in markup, then we open ourselves up to all sorts of security attacks. We may also undermine the goals of other users for consistency of style and presentation.
> 
> So in terms of user goals for markup, we are not so much talking about why I want to include (say) video in my blog post, but that in general in some parts of Sakai we know that there is a reasonable expectation to include video. The user goals part may be about determining how many distinct scenarios there are (e.g. "we allow video in a blog post because we see it as reasonable but we don't allow video in a site description because we want a fixed amount of text to make scanning across many site descriptions easier" vs "we allow video anywhere a user is allowed to create input"). In other words, is it as simple as plain text in some places, free form in others (and then what does free form look like), or are there useful intermediate requirements profiles? I see most current RTE's as some form of intermediate offering, depending on plugins installed. The on-list discussion about markup languages *may* have revealed some other potential intermediate offerings.
> 
> So a lot of the conversation in the first part of the meetings is about surfacing and 'classifying' these scenarios and determining how many distinct situations need to be addressed. 
> 
> The second part of the meeting would be about the trade-offs between flexibility and adaptability to user expectations vs. security (and maybe control over presentation?)
> 
> If I have this right, then I think a lot of the homework will be about researching what other sites allow and how they deal with the security implications. Collecting this together in a comprehensive library (assuming we don't find a place where someone else has already done it), seems like a valuable resource. IF we succeed in creating such a resource, a meeting to discuss how we apply the resulting knowledge to Sakai would be very useful.
> 
> OTOH, a meeting in which we hadn't managed to do the research, but merely exchanged opinions on how things should work (expert or otherwise), would be less valuable.
> 
> Best, John
> 
> On 8 Apr 2010, at 17:30, Noah Botimer wrote:
> 
>> Hello everyone,
>> 
>> I am writing to introduce a proposal for a virtual meeting. The topic is user generated content (text and markup) and security therein.
>> 
>> Proposed Format:
>> 
>> 	* 2-day (or 2 half-day) virtual working meeting
>> 	* Late April / Early May
>> 	* Supported by tele- / video-conference
>> 
>> Objectives:
>> 
>> 	* Understand user goals for markup (e.g., styling, images, video)
>> 	* Develop an initial set of technical best practices for supporting the user goals securely
>> 	* Develop a plan for evolving the Sakai 2 platform to support and employ the best practices
>> 	* Consider how compatible the findings are with Sakai 3
>> 
>> 
>> This material and significant background are in Confluence. Please feel free to discuss here or as comments on the page.
>> 
>> I would like to hear from all interested in participating -- this includes user specialists, developers, and security experts. The specific agenda and homework leading up to the proposed meeting are left for discussion, though I expect the first day would be more functional and the second more technical.
>> 
>> http://confluence.sakaiproject.org//x/soAYB
>> 
>> Thanks,
>> -Noah
>> 
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>> 
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> 
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> 
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> 
>