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

Re: Possible issue w/ @profile and http vs. https

From: Nathan <nathan@webr3.org>
Date: Wed, 03 Nov 2010 21:31:50 +0000
Message-ID: <4CD1D4C6.5050401@webr3.org>
To: Manu Sporny <msporny@digitalbazaar.com>
CC: RDFa WG <public-rdfa-wg@w3.org>
Manu Sporny wrote:
> Just noting this here as it popped into my head while dealing with some
> SSL-related browser issues.
> When a web page and its associated resources are loaded over TLS, the
> browser will provide a graphical warning (usually in the URL bar website
> icon) if there are some resources that were loaded over a non-TLS
> connection into the page. This is usually triggered whenever there are
> images, or CSS files that were loaded over an HTTP vs. and HTTPS
> connection. The browsers do this because an image or CSS file might
> trick the person browsing into doing something that is unsafe.
> @profile falls into this category, if a @profile is compromised, it may
> generate the wrong triples in a page. If one is operating on RDF triples
> via the RDFa API on a page that was loaded via HTTPS, and the @profile
> was loaded via HTTP, there is a possible security vulnerability there.
> I can't think of an attack that could do a serious amount of damage at
> this point, as the RDFa API does not exist and RDF page data is probably
> not used to drive logic at this point in time.
> Just throwing this out there as I do think that we would want to ensure
> that the browsers that implement RDFa Core "fail to load a profile" when
> a profile is loaded from an HTTPS page in non-HTTPS mode. It's really
> implementation guidance, but perhaps something that should be placed
> into the RDFa API spec or the RDFa Core spec?
> Thoughts?

Agree that it's an issue which needs noted in some form, probably 
offering some guidance for both Profile authors and users; and probably 
within the RDFa API.

Personally if I was creating an RDFa Profile then I would publish it at 
both http:// and https:// locations, and encourage authors to reference 
it by a URI-reference of the following form:


Thus negating the issue.


Received on Wednesday, 3 November 2010 21:32:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:05:22 UTC