PROPOSAL - Allow containers to require HTML content sanitization on output

2 views
Skip to first unread message

Louis Ryan

unread,
Feb 24, 2009, 7:31:00 PM2/24/09
to OpenSocial - OpenSocial and Gadgets Specification Discussion
All

With the introduction of proxied content and server side templating application developers have a greater ability to generate and display personalized content without needing to run client side Javascript. Containers that want to very tightly control the behavior of applications on certain views should be able to require that only HTML markup is displayed and that no third party scripts are run. Containers can provide OS tags to allow those applications to have interactive behavior in-browser without allowing third party script. This feature allows containers to choose the level of control they want over 3rd party content they display. This feature is not a replacement for Caja which allows client-side third-party code execution but in a strictly controlled sandbox.

Containers which are highly latency sensitive can benefit from a santized rendering model by virtue of the fact that applications must be able to render in a single HTTP response and should essentially no Javascript. Containers can also choose to inline this content to eliminate rendering round-trips if they have a high degree of confidence in the sanitization.

A new gadget feature would be introduced called "html-sanitize". If this feature is present for a gadget the container can assume that the gadget works when it has been HTML santized and so can render its content with santization on. When a container requires sanitization for a view but a gadget does not support it the container can decide how to present the gadget. Common policy choices in this scenario may be to:
- Not show the gadget at all
- Show a link to the gadget on another surface which can be rendered
- Allow the gadget to be rendered on the view unsantized in response to a user action (e.g 'Click to expand')
- Render the gadget and force sanitize it and accept the risk of broken content

A working prototype of this proposal is available in Shindig today and can you can test its effect on a gadget running on the Orkut sandbox by appending &gadgets-sanitize=1 to the Orkut URL. E.g. http://sandbox.orkut.com/Main#Application.aspx?uid=861823821820140844&appId=831537538723&gadgets-sanitize=1

Id personally like to see something like this adopted in the 0.9 timeframe so I'd also like to get some feedback if people thought that was feasible.

-Louis





Charlie Jiang

unread,
Feb 24, 2009, 8:02:14 PM2/24/09
to opensocial-an...@googlegroups.com

Hi Louis,

 

Glad to hear this. Almost exactly same concept was raised very early in the 0.9 process by us at Yahoo. In stead of calling it “html-sanitize”, we called it “html-simple”. This is not necessarily only for proxied content though. In line content should also support this.

 

At that time, only us required this feature and we didn’t hear much echos. As a result it was pulled off temporally from the spec.

 

You have my +1 to put this back into 0.9 spec especially considering the implementation is already in the Shindig.

 

-Charlie

 


Scott Seely

unread,
Feb 25, 2009, 1:45:41 PM2/25/09
to opensocial-an...@googlegroups.com

+1.

 

Because this is a significant security constraint it does make sense to place it in the initial release.

Adam Winer

unread,
Feb 25, 2009, 3:27:37 PM2/25/09
to opensocial-an...@googlegroups.com
I'm concerned about the precedent of rushing features into a spec
release when we're nearing the end.

Why not define a de-facto spec outside of the formal spec process, and
get it formally standardized in 1.0? Containers all have extensions,
this can be one.

-- Adam Winer

Evan Gilbert

unread,
Feb 26, 2009, 11:58:59 AM2/26/09
to opensocial-and-gadgets-spec
I'm concerned about the precedent of adding features late as well. I'm also being strongly motivated to see this feature launch in the 0.9 timeframe.

So I agree this should be an extension. I'd like to propose a common naming convention for extensions that aren't container-specific - prefix them all with "x-". This can be used for view names, feature names, field names, etc.

So +1 on <Require feature="x-html-sanitized">.

Also, a request for this feature - the developer should also be able to define both a sanitized and non-sanitized version of a view in the same XML. Not sure of the best syntax for this - possibly a separate view name so that containers unaware of sanitization will work properly.

Evan

2009/2/25 Adam Winer <awi...@gmail.com>

Adam Winer

unread,
Feb 26, 2009, 12:02:04 PM2/26/09
to opensocial-an...@googlegroups.com
On Thu, Feb 26, 2009 at 8:58 AM, Evan Gilbert <uid...@google.com> wrote:
> I'm concerned about the precedent of adding features late as well. I'm also
> being strongly motivated to see this feature launch in the 0.9 timeframe.
>
> So I agree this should be an extension. I'd like to propose a common naming
> convention for extensions that aren't container-specific - prefix them all
> with "x-". This can be used for view names, feature names, field names, etc.
>
> So +1 on <Require feature="x-html-sanitized">.

+1 for x-html-sanitized.

> Also, a request for this feature - the developer should also be able to
> define both a sanitized and non-sanitized version of a view in the same XML.
> Not sure of the best syntax for this - possibly a separate view name so that
> containers unaware of sanitization will work properly.

We really need per-view features in v.Next.

-- Adam

Lane LiaBraaten

unread,
Feb 26, 2009, 12:05:19 PM2/26/09
to opensocial-an...@googlegroups.com
Seems like most feature add JavaScript to the iframe for the gadget to use.  This isn't the case for html sanitization though.  Would <Content type="x-html-sanitized"> be a viable solution?  I think this also addresses the per view issue.

-Lane

Scott Seely

unread,
Feb 26, 2009, 12:14:32 PM2/26/09
to opensocial-an...@googlegroups.com

The concern here seems to be based on whether or not a given container supports sanitized Home/Profile views. If this is the case, can’t the developer use manifests handle presenting the gadget for Ning and then present another bit of markup for Orkut?

 

My assumption is that, as a developer gets to the point where they target multiple containers, they have built up the expertise to write a script that properly assembles a gadget.xml based on the types of views/containers they support.

 

Finally—are we in agreement that this particular item is not a CORE feature, it is an extension?

Louis Ryan

unread,
Feb 26, 2009, 12:23:49 PM2/26/09
to opensocial-an...@googlegroups.com
I'm fine with it being an extension in 0.9. Lanes suggestion to use <Content type=html-sanitized is interesting but I think per-view features is probably the right direction to go, its something we've needed for a while anyway

Scott Seely

unread,
Feb 26, 2009, 12:33:26 PM2/26/09
to opensocial-an...@googlegroups.com

Technically, it isn’t in 0.9. It’s outside, right?

Charlie Jiang

unread,
Feb 26, 2009, 1:00:14 PM2/26/09
to opensocial-an...@googlegroups.com

I am for <Content type=”x-html-sanitized”…

 

This enables overloading view definition with different types.

Lane LiaBraaten

unread,
Feb 26, 2009, 5:37:21 PM2/26/09
to opensocial-an...@googlegroups.com
On Thu, Feb 26, 2009 at 9:23 AM, Louis Ryan <lr...@google.com> wrote:
I'm fine with it being an extension in 0.9. Lanes suggestion to use <Content type=html-sanitized is interesting but I think per-view features is probably the right direction to go, its something we've needed for a while anyway

Yeah - I definitely see the need for per-view features in general.  However, for this particular case specifying html-sanitized as a Content type seems to be appropriate (since it's not adding any functionality that the developer can use).

-Lane

Louis Ryan

unread,
Feb 27, 2009, 3:24:26 PM2/27/09
to opensocial-an...@googlegroups.com
Ok Im persuaded <Content type="x-html-sanitized". I will create a prototype for this in Shindig.
Reply all
Reply to author
Forward
0 new messages