<!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 Pierre,</p>
<p>On 2016-12-10 01:08, Pierre Ynard wrote:</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">
<pre><code> Previously the implementation would unconditionally download art,
these changes make sure that we respect the scope of the fetcher being
used.</code></pre>
</blockquote>
<pre><code> 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.</code></pre>
</blockquote>
<p>It will be “ignored” if the user has specified <code>--no-metadata-network-access</code> and the URL for the art specified is not considered “local” (see previous discussion with <em>Remi</em> for further information on the matteR).</p>
<p>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).</p>
<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>
<p>The <code>m3u</code>-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 <code>m3u</code> to demonstrate the issue is that it is easily edited, and easily reasoned about.</p>
<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>
<p>The option, <code>--no-metadata-network-access</code>, is there to precisely do what the name implies; to not fetch metadata (such as artwork) over the network.</p>
<p>Best Regards,<br />
Filip Roséen</p>
</body>
</html>