<!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-11 05:28, Pierre 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> 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> I disagree, the intent has been to prevent privacy leaks through
metadata lookup and access. Metadata lookup and access that don't
cause privacy leaks (e.g. getting the associated art from the same
video website that is already getting queried) are a grey area of
interpretation that you're now denying.</code></pre>
</blockquote>
<ul>
<li>Exactly what is it that I am <em>“now denying”</em>?</li>
</ul>
<p>I honestly cannot read <code>--no-network-metadata-access</code> and see your point, if it was meant to block <em>metadata lookups</em>; why is it not named <code>--no-network-metadata-lookup</code>?</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> There's at least me considering the feature that way, I sure as hell
don't want my local media to start leaking queries to the internet,
but I do appreciate getting the associated art from youtube video or
soundcloud tracks I'm playing.</code></pre>
</blockquote>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> If you can't see how I can think that, then you might as well call
me stupid.</code></pre>
</blockquote>
<p>I would never resort to such replies, not do I wish anyone to do the same towards anyone on <code>vlc-devel</code>. Hopefully those that do will stop soon enough.</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> Do I need to download art from within lua scripts and pass it as an
inline data URL to get my point across?</code></pre>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<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> Granted, but that's also part of the grey area; although metadata URLs
embedded in video file containers would rather be on the side of what
you don't want to automatically lookup.
However this is starting to be a different issue from privacy and
querying metadata, it's an issue of blocking untrusted input and attack
vectors. And I don't think that this was the concern in mind when the
feature was designed, so one could say that you're diverting the real
purpose of a loosely related feature to fix a proof-of-concept exploit.
It also seems that the patch is wrongly coupling the file caching
technical optimization concern with the privacy concern.</code></pre>
</blockquote>
<p>Could you elaborate this point?</p>
<p>I do not want to reply to something which I am not sure I completely understand (in terms of what is being expressed), as that will probably just make us walk down a discussion path that might be irrelevant to the underlying point.</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> file:// implies neither local, nor private, nor trusted. The attack
vector you highlighted is still exploitable after your patch, whether
--metadata-network-access is enabled or not.</code></pre>
</blockquote>
<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>
<p>Demuxers generally do not download any metadata, that happens in the affected code-path which the original patch modified.</p>
<p>As far as I know, we have no such demuxer.</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> The playlist core correctly handles meta fetchers, but seems to
provide only a poor, coupled handling of the other technical, trust and
privacy concerns. I think this patch is a misaimed attempt at improving
things.</code></pre>
</blockquote>
<p>No, it is not a <code>100%</code> fix related to the privacy concern; but as I think I expressed earlier, or at least on <code>#videolan @ freenode</code>; my opinion is that it narrows the concern to a more acceptable level.</p>
<p>Related to “correctly handling meta fetcher”, that is only somewhat true; I will try to create tickets for the issues I found during next week.</p>
</body>
</html>