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.orgwrote:
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
