Restricting content - the options

Skip to first unread message

Gervase Markham

May 22, 2007, 10:40:15 AM5/22/07
to Ian Hickson
There have been several proposals and a fair bit of discussion in recent
months about allowing web authors to restrict the capabilities of
"their" content - for XSS mitigation or other reasons. Here are some:

Content Restrictions (CR)

Script Keys


(and other similar proposals using names like <sandbox>)

Browser Enforced Embedded Policies (BEEP):

Ian Hickson's summary of proposals posted to WHAT-WG:

As Ian said, this is a complicated area, and there are a lot of
proposals which may not be fully thought-through. (I include my own
suggestions in that.) For example, the flexibility of JavaScript means
that many suggestions for types of restriction actually do not restrict
anything. Please do not chime into this thread without a good
understanding of the issues and the documents above.

Here is my attempt to summarise the current status.

Possible Use Cases

- George is writing some blog software and wants to display user
comments safely, either without any HTML or with a limited subset. He's
worried his sanitiser might not be perfect.

- The developers of TOR want to show retrieved HTML content in the
browser without the content leaking any information about the user.

- The developers of eBay want to allow sellers to upload complex pages
with embedded script without sellers stealing buyers' eBay login
credentials or cookies.

Possible Goals

- Simplicity - reuse as much security infrastructure as possible

- Keep the restriction rules simple and easy to understand

- Make it possible to implement without needing access to webserver

Open Questions

* Restriction area - the whole of a page or just part?

Restricting the whole of a page allows us to leverage the <iframe>/page
security model.

CR: Restricts whole page
Script Keys: Restricts to only pre-approved script
<jail>: Restricts part of the content
BEEP: Can restrict different scripts in different ways
Hixie: Restricts everything inside an <iframe>

* Restriction scope - all script or only some actions? Just script or
other stuff too?

Different use cases require different types of restriction. So this
question is probably best answered by deciding which use cases we are
attempting to deal with.

CR: Restricts script location in page, script host, cookie access and
frame hierarchy traversal.
Script Keys: Restricts what script can run, but not what it can do
<jail>: Not clearly defined; restricts running of script and/or script
BEEP: Restrictions arbitrarily flexible
Hixie: Restricts whether script can run, frame hierarchy traversal, a
set of "annoying" APIs, style cascade through <iframe> boundary.

* Restriction mechanism - how to trigger restrictions?

CR: HTML header/meta tag
Script Keys: HTTP header matching a string inside script comments
<jail>: HTML tag
BEEP: installation of JS function
Hixie: <iframe> attributes

* Degredation - do we degrade to <noscript> or to full capabilities?

I believe all proposals degrade to give script full capabilities (as
that's what we have now).

Existing Work

There is a tracking bug for sanitizing content sinks:

There is a patch to allow <iframe> to size to content (required for
<iframe>-based solutions):

IE has the proprietary "security" attribute on <iframe> which restricts
script in various ways:

Is this a complete summary? It may not be the most helpful way of
looking at things; suggestions welcome. My analysis will follow in a
separate message.


Reply all
Reply to author
0 new messages