[webkit-dev] New Feature - Resource Timing

[Tony Gentilcore]

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 <mjs at 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
>
>