<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class=""><div class=""><fieldset style="padding-top:10px; border:0px; border: 3px solid #CCC; padding-left: 20px;" class=""><div style="padding-left:3px;" class="">Good thinking!<span class="Apple-converted-space"> </span> I summarized the methodology on the graph page as: The<br class="">graph above is based on sanitized Tor web server logs [0]. These are a<br class="">stripped-down version of Apache's "combined" log format without IP<br class="">addresses, log times, HTTP parameters, referers, and user agent strings.</div></fieldset></div></div></blockquote>...<br class=""><blockquote type="cite" class=""><div class=""><div class=""><fieldset style="padding-top:10px; border:0px; border: 3px solid #CCC; padding-left: 20px;" class=""><div style="padding-left:3px;" class="">If you spot anything in the data that you think should be sanitized<br class="">more thoroughly, please let us know!</div></fieldset></div></div></blockquote><br class=""></div><div>Interesting, thanks. Here are some thoughts based on looking through one of these logs (from <a href="http://archeotrichon.torproject.org" class="">archeotrichon.torproject.org</a> on 2015-09-20):</div><div> 1. The order of requests appears to be preserved. If so, this allows an adversary to determine fine-grained timing information by inserting requests of his own at known times.</div><div> 2. The size of the response is included, which potentially allows an adversary observing the client side to perform a correlation attack (combined with #1 above). This could allow the adversary to learn interesting things like (i) this person is downloading arm and thus is probably running a relay or (ii) this person is creating Trac tickets with onion-service bugs and is likely running an onion service somewhere (or is Trac excluded from these logs?). The size could also be used as an time-stamping mechanism alternative to #1 if the size of the request can be changed by the adversary (e.g. by blog comments).</div><div> 3. Even without fine-grained timing information, daily per-server logs might include data from few enough clients that multiple requests can be reasonably inferred to be from the same client, which can collectively reveal lots of information (e.g. country based on browser localization used, platform, blog posts viewed/commented on if the blog server also releases logs).</div><div><br class=""></div><div>I also feel compelled to raise the question of whether or not releasing these logs went through Tor’s own recommended procedure for producing data on its users (<a href="https://research.torproject.org/safetyboard.html#guidelines" class="">https://research.torproject.org/safetyboard.html#guidelines</a>):</div><div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• Only collect data that is safe to make public.<br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• Don't collect data you don't need (minimization).<br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• Take reasonable security precautions, e.g. about who has access to your data sets or experimental systems.<br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• Limit the granularity of data (e.g. use bins or add noise).<br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• The benefits should outweigh the risks.<br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• Consider auxiliary data (e.g. third-party data sets) when assessing the risks.<br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• Consider whether the user meant for that data to be private.</div></div><div>I definitely see the value of analyzing these logs, though, and it definitely helps that some sanitization was applied :-)</div><div><br class=""></div><div>Best,</div><div>Aaron</div></body></html>