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

Re: Not waiting on browser manufacturers for RDFa 1.1

From: Mark Birbeck <mark.birbeck@webbackplane.com>
Date: Fri, 16 Jul 2010 16:41:08 +0100
Message-ID: <AANLkTilDeVxB5qvTe6oh87iQFtBBEZ-AOIcaZckM3GoR@mail.gmail.com>
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: RDFa WG <public-rdfa-wg@w3.org>
Hi Manu,

Mmm...I think we need to roll back a little here.


SAME-ORIGIN PROFILES

Everyone is getting a little worked up about the whole question of
having a JSON format for profiles as if it automatically implies using
cross-domain JSONP. Whether we allow cross-domain profiles is entirely
up to us. If we wanted to we could specify that profiles are as much
subject to the same origin policy as IFRAMEs and XMLHttpRequests
(which particular limitation by the way makes at least part of your
doomsday scenario impossible...you couldn't post my bank details to
another server using XHR).


A JSON FORMAT FOR PROFILES

So, given that a JSON format for profiles does not immediately require
the use of JSONP, then whether we have such a format or not is
question in its own right; if we were to say that profiles /cannot/ be
cross-domain, then both JSON and HTML could be used safely to describe
the profiles -- the former could be loaded via XHR and parsed with a
JSON parser, and the latter could be loaded either via XHR or via a
hidden IFRAME.

And if profiles /can be/ cross-domain, then neither JSON nor HTML will
work with XHR, and HTML won't work with an IFRAME -- but they will
both work with CORS and the various other hacks that have been
mentioned.

So to reiterate: a /JSON/ syntax for RDFa profiles is no more or less
secure than an HTML version.


A JSONP FORMAT FOR PROFILES

However, alongside the advantages of not having to fire up a full RDFa
parser just to get prefix mappings, another advantage of providing a
JSON way to define a profile is that *trusted* users of RDFa could do
something with JSONP if they wanted to.

For example, just as *some* site-builders trust Google's CDN to
deliver the jQuery or YUI libraries to their web-pages, and *some*
site-builders trust Google or Yahoo! Maps libraries to have access to
the DOM, so too they *could* trust Google or Facebook or Yahoo! to
deliver some well-known profiles, in whatever way works.

But then that becomes up to people to decide in the same way that they
decide everything else with security. It's really taking things a bit
too far to say that we shouldn't have a JSON format, just in case
someone uses it for JSONP.


LOCAL PROFILES

One final point to make though, is that anyone who wants complete
security on their site will take the same approach to profiles as they
do to anything else. Just as they will almost certainly put jQuery on
their own servers, so too with profiles; if I'm a bank I could take
the Rich Snippets, Facebook Like and Good Relations profiles and paste
them together into one document, which I then deliver from my server,
in the same domain as my documents.

A CMS platform like Drupal could go one step further and do this
automatically for developers, retrieving remote profiles that have
been set in the configuration settings, and then combining them
together to be served up as one local profile for the site.

There are many more scenarios that you could think of, but the main
point I'm getting at here is that since limiting profiles to only
coming from the same domain would not be so bad, the whole
cross-domain issue isn't that important for us.

But I believe that having a JSON format for profiles could turn out to
be quite significant.


CONCLUSION

I'm arguing for a JSON version of profiles. I think it is better than
using HTML+RDFa, since it doesn't require us to create a vocabulary or
run a full RDFa parser before we even get to do any parsing on the
primary document.

I realise people are against this, and the opposition to this seems to
be based on two things:

* a for defining our own vocabulary, and then using that via HTML+RDFa,
  rather than using name/value pairs;

* the belief that using JSON to express the prefix mappings necessarily
  requires the use of JSONP in order to deliver these profiles.

The first point boils down to preference, and certainly is not
sufficient to rule out a JSON format, even if it should co-exist with
an HTML+RDFa format.

The second point is simply wrong.

Regards,

Mark

--
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)


On Fri, Jul 9, 2010 at 10:12 PM, Manu Sporny <msporny@digitalbazaar.com> wrote:
> On 07/09/10 13:44, Mark Birbeck wrote:
>> Yes, you're probably right...all the people who campaigned long and
>> hard against using JSON in Flickr, Google Maps, Twitter, Yahoo!, and
>> so on, will no doubt be so buoyed by their success that they will
>> switch their attention to us.
>
> I'm assuming that you're being facetious, but there is a point that is
> left un-made in your remark.
>
> Toby and Shane are absolutely correct - we didn't use JSONP because it
> is a massive security hole to do so. Executing /any/ RDFa vocabulary as
> Javascript is an unacceptable security risk. I don't know if you know a
> way around this, because if so, please do let us know.
>
> The difference between Flickr, Google Maps, Twitter, Yahoo! and other
> large establish companies that people trust and some random vocabulary
> developer should be self-evident.
>
> There are certain URLs that you can trust most of the time (like
> well-known URLs for jQuery caching provided by Google) and there are
> URLs that you can't trust - like trojan vocabularies that people have
> developed and tricked others into using.
>
> Here's the nightmare scenario, if it wasn't evident already:
>
> Your bank has RDFa information in your account page - account details,
> balances, etc. They're using a 3rd party RDFa parser that loads
> vocabularies via <script> tags and JSONP. Their developers include an
> extra vocabulary via @profile that loads a profile from a 3rd party site.
>
> The 3rd party site gets compromised in some way, still provides the
> correct term mappings, but also sniffs which site you're on and what
> content is on the page. If it detects that you're on your bank's
> website, it encodes your account details in a URL and does an
> XMLHttpRequest GET to a site that collects all of your banking data.
> Worse, it puts a window on the page that says that you've been logged
> out and to enter your username and password to log back into the site.
>
> This was the reason we rejected JSONP as a solution for RDFa Profiles -
> it is a massive security hole. We have a duty to the Web community to
> create solutions that are not only useful, but also secure and that
> won't violate their trust in the Web.
>
> As I mentioned previously, perhaps you have a solution for this
> particular attack... I'd love to hear it if you do. :)
>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny)
> President/CEO - Digital Bazaar, Inc.
> blog: Myth Busting Web Stacks - PHP is Faster Than You Think
> http://blog.digitalbazaar.com/2010/06/12/myth-busting-php/2/
>
>
Received on Friday, 16 July 2010 15:41:41 GMT

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