<!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 14:02, 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> First, I don´t see the problem. The metadata is the album art URL, not the
resource that the URL represents.
Second, the difference between asking a third party for metadata and
retrieving a known resource from the second party is clear.</code></pre>
</blockquote>
<p>To me the second party is the file that is being played, any references to an external party is (to me) considered to be third-party.</p>
<p>One could of course argue that we should check whether the referenced URI belongs to the same domain as that of the media being played, to allow for such requests (kind of like the ‘’same-origin policy’’).</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> And third, album art retrieval used to have its own "album-art" tristate.
It´s rich of a VideoLabs employee to argue that the policy should be changed
because another VideoLabs employee changed the settings name.</code></pre>
</blockquote>
<p>I fail to see what <em>VideoLabs</em> have to do with this, though I do understand that my association with the company can make it look like all changes I propose are coming from the company.</p>
<p>I will change my contact information so that comments such as the above can be avoided in the future, making a clearer distinction between my personal development related to VLC and that which is done during office-hours.</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> Meta lua scripts have an explicit privacy scope, and their output can be
more or less trusted. The output of lua website demuxers can be trusted
and have no privacy impact. I'm not aware of any protection in other
demuxers from untrusted art URLs, nor from privacy leaks they might
incur.</code></pre>
</blockquote>
<pre><code> Demuxers generally do not download any metadata, that happens in the
affected code-path which the original patch modified.</code></pre>
</blockquote>
<pre><code> That is completely irrelevant. Demuxers (and previously stream
filters) routinely fetch referred resources automatically from the
network. From a privacy and security point of view, this is no
better or worse than fetching a cover.
Adaptive is a prime example of that.
If you want to prevent VLC from using the network, then firewall it. I cannot
see any sense for the sake of privacy in blocking the art fetcher, but letting
other forms of automatic network access.</code></pre>
</blockquote>
<p>What other forms of “automatic network access” are you referring to? I must be missing something since I cannot deduce this from your reply.</p>
<p>To me there is a vaste different between playing something that queries <em>data</em> that is supposed to be played, and fetching additional metadata that is not mandatory for the playback of the entity itself.</p>
</body>
</html>