W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > March 2010

Re: Javascript Security for Dummies

From: Ben Adida <ben@adida.net>
Date: Mon, 08 Mar 2010 14:19:31 -0800
Message-ID: <4B9577F3.8080604@adida.net>
To: Toby Inkster <tai@g5n.co.uk>
CC: RDFa WG <public-rdfa-wg@w3.org>
On 3/4/10 11:37 AM, Toby Inkster wrote:
> I volunteered to write a quick summary of how Javascript/JSON/JSONP/CORS
> relate to each other and the various security issues involved.

Awesome summary, thanks Toby, now I'm not the only security/paranoid 
freak in the group :)

> If we want such Javascript implementations of RDFa to be possible, this
> allows two solutions:
>
> 	1. Serve up the vocabulary document as JSONP; or
> 	2. Serve it up as something else plus CORS headers.
>
> #1 is problematic because as I said, JSONP is not nice, safe JSON,
> despite the similar names. JSONP is Javascript.
>
> #2 is problematic because CORS is a very new feature. Many of the newest
> browsers support it (including IE8), but if you want your script to work
> in downlevel browsers, this is not your solution.

I concur with #1, JSONP is really ugly, and as Mark said it just goes to 
show that 3rd-party JSON == 3rd-party JavaScript from the pov of security.

I am coming around to thinking that #2 is not too problematic, since the 
bookmarklet approach is really a "bootstrap" for RDFa parsing, and 
anyone who wants to *host* an RDFa parser could easily do the vocabulary 
proxying, or at least caching.

But, I would love to hear more about:

> In my next message I'll outline how my RDFa vocab proposal (which is
> slightly different to Manu's) makes this a moot point by saying that
> retrieval of the vocab document is optional - a SHOULD requirement
> rather than a MUST - and provides a fallback in the case, e.g. of
> browsers which don't implement CORS.

To me, the central issue with vocabulary indirection is *requiring* a 
third-party de-reference to get at any of the triples. I don't feel as 
strongly about this issue as I used to, but I'd love to see it resolved 
with a SHOULD rather than a MUST, and some functionality remaining in 
the interim.

So, tell us more!

Btw, one thing to add for the group: the same-origin limitations you 
describe are not limitations of JavaScript the language, they are 
constraints of the Web-browser security model that are passed on to the 
embedded JavaScript interpreter.

For example, if you write a Chrome extension in JavaScript, which is not 
constrained by the same-origin model since the extension is more trusted 
than your average web page, you can make cross-origin calls without CORS 
or any other special trick.

-Ben
Received on Monday, 8 March 2010 22:20:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:55:06 GMT