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
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Reply via email to