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

Re: DOM Tampering

From: Mark Birbeck <mark.birbeck@webbackplane.com>
Date: Fri, 26 Nov 2010 12:01:58 +0000
Message-ID: <AANLkTi=tseUBi3Nvo48qN9HbvxO2fA7w_C1hAAPKozf9@mail.gmail.com>
To: nathan@webr3.org
Cc: RDFA Working Group <public-rdfa-wg@w3.org>
Hi Nathan,

> The other approach is to try and get the unmodified DOM back from the
> browser, if HTTP cacheing is in place then one could simply GET it again and
> leverage document.implementation or xhr.responseXML to get an untouched DOM
> to parse.

That seems overly complicated, doubles up on HTTP requests, is still
probably not that safe (request methods may get overridden), but
mainly, it's not a generic solution; the 'DOM tampering' issue that
Tom raises is a specific example of the more general case of not
knowing whether some RDFa has been modified before you process it.


> There will probably be more approaches, but probably something we want to
> keep a watch on advise on.
>
> Worth raising a bug / action?

Since it's exactly the same problem as arises in any other information
that is sent over the internet it's certainly not a bug in RDFa.

But also, since it's a common problem we should look at other
solutions, which is why I mentioned getting inspiration from the way
XML documents are signed. However, I think it's worth doing the
signing at the level of the RDF (i.e., with a predicate that becomes
part of the graph) rather than at the level of the document itself.
That way the same solution could be used to 'sign' triples delivered
via N3, RDF/XML, JSON-LD, and so on.

I should stress again though that I don't think this is an issue for
RDFa or the API, so I don't see this going into either spec; it's just
an interesting, general problem that someone might want to solve with
a W3C note or something, and we could then perhaps make a reference to
it.

Mark
Received on Friday, 26 November 2010 12:03:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:19:50 UTC