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

Re: Not waiting on browser manufacturers for RDFa 1.1

From: Shane McCarron <shane@aptest.com>
Date: Fri, 09 Jul 2010 11:22:35 -0500
Message-ID: <4C374CCB.6030205@aptest.com>
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 GMT

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