Re: Systematic access to media/plugin metadata

On Wed, 2011-04-13 at 13:19 +0200, Danny Ayers wrote:
> On 13 April 2011 12:49, Henri Sivonen <hsivonen@iki.fi> wrote:
> > On Wed, 2011-04-13 at 12:01 +0200, Danny Ayers wrote:
> >> > As far as I can tell, the use cases you included called for browser UI
> >> > features--not for an API.
> >>
> >> I don't think so...the UI parts for directing someone to a hotel or
> >> alerting them to something in a photo could be handled by regular
> >> DOM/HTML, <canvas> or SVG. The only bit that can't easily be fulfilled
> >> right now is access to the metadata.
> >
> > If the scenario is that someone puts a image with metadata on a server
> > and without the author doing anything else, the browser can alert the
> > user about stuff, then it's about a built-in browser feature that
> > doesn't have expose anything to JS.
> >
> > If the scenario is that someone puts an image with metadata on a server
> > *and* supplies a JavaScript program that uses DOM/HTML, canvas or SVG to
> > alert the user about the metadata, the author controls both the image
> > and the alert mechanism, so the author might as well extract the
> > metadata on the server side (like e.g. Flickr does) and transfer the
> > extracted data to the browser using whatever existing means.
> 
> Thanks - I see your point now.
> It was the second scenario I had in mind, but with the consideration
> that the originating server for the image/media object may not be the
> same as the one with the script.

In order to maintain the confidentiality properties that browsers now
provide, we can't allow metadata to be read cross-origin without *some*
participation of the server that serves the image. Even if an API for
reading metadata existed, the server hosting the images would need to
participate. At minimum, it would have to supply the appropriate CORS
headers for the image. Thus, you can't remove the participation of the
server that hosts the images in the scenario where a script reads
metadata.

> For popular formats it is commonplace to have other aspects of the
> data handling delegated to the client, e.g. PDFs are served as-is and
> the browser will take care of things like pagination within the PDF.
> You don't often see the pages of a PDF split and converted
> server-side. Why should the metadata be treated as a special case?

That analogy doesn't make sense. PDFs are prepaginated at the time of
creating a PDF file. Showing the pagination that the PDF creator made is
the native part of a PDF reader without scripting. Finally, PDF reading
is not a part of the interoperable browser platform. (Chrome and Safari
have it on some platforms, but it's not a built-in part of all
browsers.)

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Wednesday, 13 April 2011 12:06:20 UTC