<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<meta name="generator" content="pandoc" />
<title></title>
<style type="text/css">code{white-space: pre;}</style>
</head>
<body>
<p>Hi Remi,</p>
<p>On 2016-12-11 12:05, Rémi Denis-Courmont wrote:</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> Excuse nme, just WTF dude? This is a gross and blatant misrepresentation of my
opinion.</code></pre>
</blockquote>
<p>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).</p>
<p>I mentioned our conversation bacause it discusses the issues related to whether an entities is to be considered network or local.</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> I never agreed to *this* patch. I only commented on the other patch in the
series.</code></pre>
</blockquote>
<p>Where did I say that you did?</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> 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.</code></pre>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> 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).</code></pre>
</blockquote>
<pre><code> 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).</code></pre>
</blockquote>
<p>Given the diagnostic that the Qt-interface issues when the user is yet to decice whether or not <code>--metadata-network-access</code> should be enabled, it does not look like what you describe.</p>
<p>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.</p>
<p>It could be that we are hanging in vastly different circles, but to me <em>metadata</em> that require a <em>3rd party</em> to be queried is pricesely what an embedded, remote, art URI is.</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> 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.</code></pre>
</blockquote>
<pre><code> 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.</code></pre>
</blockquote>
<pre><code> I call bullshit on this.</code></pre>
</blockquote>
<ul>
<li><p>Care to elaborate instead of just leaving comments leaving the rest of us (or at least just me) guessing about what you actually mean?</p></li>
<li><p>Are you calling bullshit on the way I choose to explain the issue?</p></li>
</ul>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> 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</code></pre>
</blockquote>
<p>Of course, though those intermediate resources would not qualify as <em>metadata</em> 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.</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> 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.</code></pre>
</blockquote>
<pre><code> 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.</code></pre>
</blockquote>
<pre><code> 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.</code></pre>
</blockquote>
<p>I hope this section is answered by my previous replies.</p>
</body>
</html>