[vlc-devel] [PATCH 2/2] playlist/fetcher: do not ignore metadata scope when downloading art
filip at atch.se
Sun Dec 11 12:24:43 CET 2016
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
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
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:
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
> > > 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
> 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...
More information about the vlc-devel