I've forwarded these questions on to the working group: http://lists.w3.org/Archives/Public/public-web-perf/2011May/0102.html
In the meantime, we'll hold off on landing anything until we have satisfactory answers. -Tony On Fri, May 20, 2011 at 6:51 PM, Maciej Stachowiak <m...@apple.com> wrote: > > On May 20, 2011, at 10:10 AM, Tony Gentilcore wrote: > >>> Presumably the embedding application would need to require explicit user >>> consent to enable the feature. >> >> My conclusion was different. Given that the timing based privacy >> attacks are demonstrable without the interface, I thought it >> reasonable to enable-by-default with a hidden pref to disable. But >> this is based on the assumption that we aren't actually exposing any >> new private information. Am I missing an exploit here? > > I understand that we have to keep a balance, and statistical fingerprinting > is already dismayingly effective without any new features. However, > "enable[d]-by-default with a hidden pref to disable" sounds like an extremely > weak approach to protecting user privacy. > > Is it possible to find experts on the topic of statistical fingerprinting, as > well as security experts in general, who could review this API? Things I'd > really like to know are: > > - Does this feature, as designed, increase the effectiveness of user > fingerprinting, assuming the user is running something like private browsing > or incognito mode, or is regularly deleting site data? The relevant question > here is marginal increase in effectiveness - are things worse with this > feature than without? > > - Presumably some known statistical fingerprinting techniques can be > mitigated, if not always than at least in private browsing mode. If that was > done, then would this timing feature provide an additional fingerprinting > vector? > > - Could this feature directly reveal otherwise hard-to-guess information > about users? > > - Can this feature be used to aid timing-based security attacks? > > I would really like to see this kind of review done ahead of time and > delivered to the Working Group. My worry here is that the feature may have > fatal flaws as currently designed, or perhaps even in the basic concept of > its functionality. If that's the case, then we'd certainly want to find out > before we get locked into it. Perhaps some of the privacy risks can even be > mitigated, such as by returning fake or random data in private browsing mode. > I can ask some of Apple's security experts to review with a mind to these > questions, but I'm wondering if there are other independent experts we could > ask. > > My preference would be to tread very carefully around anything that could be > perceived as a privacy risk. > > Regards, > Maciej > > _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
