- From: Shane McCarron <shane@aptest.com>
- Date: Fri, 09 Jul 2010 11:22:35 -0500
- To: Toby Inkster <tai@g5n.co.uk>
- CC: RDFa WG <public-rdfa-wg@w3.org>
Which is EXACTLY why we rejected it as a required format. If it's something you want to support in your implementation, I say go for it. But I think it is way too high a risk. I would MUCH rather have this flash hack coupled with a CORS-aware proxy as a backup service. At least this way we are only delivering (X)HTML files that are then being parsed. No room for random stuff to be injected into my Javascript runtime environment. On 7/9/2010 11:16 AM, Toby Inkster wrote: > On Fri, 2010-07-09 at 14:46 +0100, Mark Birbeck wrote: > >> But as I said way back during the discussions on profile, if you allow >> profiles to be defined using JSON then you don't have this problem. >> > Mark, I know you know this, but it's good to be clear... JSON does *not* > allow you to circumvent browser cross-origin policies; JSONP does. > > Why is this an important distinction? Because JSONP is essentially a > profile of Javascript. You bypass browser cross-origin policies because > instead of fetching the profile, you embed (and thus execute) the > profile as a script. > > While in practise there may be situations where this is a reasonable way > to operate, executing unchecked third-party scripts carries a pretty big > risk. > > I imagine that if we recommended this technique in the spec, there'd be > a lot of pushback. > > -- Shane P. McCarron Phone: +1 763 786-8160 x120 Managing Director Fax: +1 763 786-8180 ApTest Minnesota Inet: shane@aptest.com
Received on Friday, 9 July 2010 16:23:19 UTC