[vlc-devel] [PATCH 2/2] playlist/fetcher: do not ignore metadata scope when downloading art

[Filip Roséen]

Hi Remi,

On 2016-12-11 12:05, Rémi Denis-Courmont wrote:

> Excuse nme, just WTF dude? This is a gross and blatant misrepresentation of my 
> opinion.

I never stated that you agreed with my opinion, nor did I put any
words in your mouth (as you just did towards me with the email this is
a reply to).

I mentioned our conversation bacause it discusses the issues related to
whether an entities is to be considered network or local.

> I never agreed to *this* patch. I only commented on the other patch in the 
> series.

Where did I say that you did?
 
> In fact, I completely agree with Pierre. This patch is completely wrong. It 
> redefines the meaning of the metadata fetch flag in a way that was definitely 
> not originally intended, and is not what I want as a user.
>
> The goal of the flag is to turn off VLC looking for art automatically. The 
> goal was never to prevent VLC from fetching already known art.
>
> > I cannot see any other way to interpret the flag, and the intent has
> > always been to block metadata lookup and access for the desribed set
> > of entities (when the flag is enabled).
> 
> Well, I do see another way: how it was before.
> 
> Don´t go asking the Googles for potential art, but fetch art URLs that are 
> already known (from the playlist or from the file metadata).

Given the diagnostic that the Qt-interface issues when the user is yet
to decice whether or not `--metadata-network-access` should be
enabled, it does not look like what you describe.

Even since I first started using VLC I've interpreted the flag in the
way which I have described. Given the divided opinion that is now
being discussed, I asked a few friends (not a leading question), and
they agree with me.

It could be that we are hanging in vastly different circles, but to me
*metadata* that require a *3rd party* to be queried is pricesely what
an embedded, remote, art URI is.
 
> > > I agree that privacy leaks are to be taken seriously, but even in the
> > > M3U example, you could argue the appropriate and intuitive behavior is
> > > to still download the art, if the URL of the main media and/or of the
> > > M3U is already on the network.
> > 
> > The `m3u`-example is simply an example, the same would happen for
> > entities that has a remote resource embedded directly within the
> > media; the reason I choose `m3u` to demonstrate the issue is that it
> > is easily edited, and easily reasoned about.
> 
> I call bullshit on this.

 - Care to elaborate instead of just leaving comments leaving the rest of
   us (or at least just me) guessing about what you actually mean?

 - Are you calling bullshit on the way I choose to explain the issue?

> VLC fetching images from art URls metadata is like the browser retrieving 
> external image tags. It should happen even if the playlist or the HTML page 
> are stored locally.
>
> In fact, a playlist file (including MP4 format, by the way) can still force 
> the player to fetch a remote resource to track the user. Just include an empty 
> resource between each and every playlist item:
> 
> https://bigbrother.example.com/report=Music1&type=start
> music1.flac
> https://bigbrother.example.com/report=Music1&type=end
> https://bigbrother.example.com/report=Music2&type=start
> music2.flac
> https://bigbrother.example.com/report=Music2&type=end

Of course, though those intermediate resources would not qualify as
*metadata* given that it is an entity supposed to be played; part of
the playlist. Those entities are not additional data that belongs to
some input.

> > > I don't know well enough the playlist and art code to make
> > > recommendations, but I'll suggest to adjust the scope flags if the
> > > original request already has a larger scope than the metadata setting;
> > > or maybe just a check comparing the URL protocols would be an easy way
> > > to offer a lot of functionality.
> > 
> > The option, `--no-metadata-network-access`, is there to precisely do
> > what the name implies; to not fetch metadata (such as artwork) over
> > the network.
> 
> I think the name was changed at some point. But in any case, the name implies 
> not to look for metadata on the Internet, referring to input item meta fields. 
> So don´t go asking the Internet who the author is, or what the art URL could 
> be.
>
> That does *not* imply not fetching art at an already known URL.

I hope this section is answered by my previous replies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20161211/94c83e7d/attachment.html>