Re: Systematic access to media/plugin metadata

On 13 April 2011 14:05, Henri Sivonen <hsivonen@iki.fi> wrote:
> 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.

The rights to the metadata are orthogonal to means of access, and in
any case I'm not convinced it's a real issue - if you have permission
to use the image, why should the metadata it contains be excluded?

>> 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.)

Ok, poor example. Substitute "mpeg" for "pdf" and "frame" for "page".

Cheers,
Danny.


-- 
http://danny.ayers.name

Received on Wednesday, 13 April 2011 13:22:18 UTC