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

[Rémi Denis-Courmont]

Le lauantaina 10. joulukuuta 2016, 15.09.14 EET Filip Roséen a écrit :
> Hi Pierre,
> 
> On 2016-12-10 01:08, Pierre Ynard wrote:
> > > Previously the implementation would unconditionally download art,
> > > these changes make sure that we respect the scope of the fetcher being
> > > used.
> > 
> > Does this mean that the Art URL returned by any lua playlist script
> > suddenly gets ignored? There will be complaints about that, and it
> > hardly makes sense since typical scripts parse a web page resulting from
> > deliberate network access, and are allowed by design to make secondary
> > network requests to fetch the media URL and other metadata.
> 
> It will be "ignored" if the user has specified
> `--no-metadata-network-access` and the URL for the art specified is
> not considered "local" (see previous discussion with *Remi* for
> further information on the matteR).

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

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

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

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

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

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

-- 
Rémi Denis-Courmont
https://www.remlab.net/