Sorry for taking so long to get back to this. I'm planning to start working on it again, so it's time to close the loop here.
The main concern earlier in this thread was the ability to take advantage of the extra timing information. We forwarded these concerns to the W3C security group as well as Google's and Microsoft's security teams. Tony's summary of the discussion on the W3C security list is here: http://lists.w3.org/Archives/Public/public-web-security/2011Oct/0019.html Everyone agreed that this spec makes timing attacks more explicit. But, since the timing attacks are already possible, this is not a concern. The only concern was that if the prior timing attacks could be patched, then this new spec would still leave us vulnerable. But, since nobody knows how to close the existing attacks, this wasn't considered an issue. So, they all are okay proceeding with Resource Timing. Are there any other concerns? As for spec updates... part of the Resource Timing spec was split out and generalized into the Performance Timeline spec [1]. It provides a uniform API for accessing the collected timing data. It'll include data from Navigation Timing, Resource Timing, and User Timing (to be discussed later). I'll land Performance Timeline before Resource Timing. Ports that wish to expose these APIs should enable: WEB_TIMING, PERFORMANCE_TIMELINE, and RESOURCE_TIMING. James [1] http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/PerformanceTimeline/Overview.html On Fri, May 20, 2011 at 12:17 PM, Tony Gentilcore <to...@chromium.org>wrote: > 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 >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
