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

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:

   profile="//example.org/my/rdfa-profile"

Thus negating the issue.

Best,

Nathan

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