On 22/07/12 11:41 AM, ptheriault wrote:
(bcc security & privacy, please keep discussion on dev-webapi)
In the Idle API bug (https://bugzilla.mozilla.org/show_bug.cgi?id=715041),
there was discussion around the privacy threat of websites correlating two
anonymous identities by comparing system idle times. In response a 'fuzz'
factor was introduced to make this attack less effective. It occurred to me
that this sort of threat occurs anywhere we fire global events such as screen
orientation, sensor events, power levels, network connection information etc,
since a webpage could compare the timing or values of these events to correlate
two anonymous identities.
Personally I feel the privacy risk is low (likely, but low impact) - this is
basically just an extension of fingerprinting, and there isn't a lot we can
meaningfully do to reduce the attack. Adding 'fuzz' to these sensor events
often directly reduces their usefulness. But I wanted to put this question to
the list to get more viewpoints?
Apart from reducing the resolution of these events, the only other mitigation I
can't think of is restricting event delivery to foreground content, which may
impact valid use cases.
Thoughts?
Some thoughts - not necessarily comforting.
If one follows Web2.0 and the marketingification of the net, then it's a
concern. But it is also hard to see how to deal with it because there
are so many measurands, so many ways to do this.
Another factor is things like SSL-everywhere & PKI. If we do start
using SSL everywhere and also SSL client certs (which remain the best
easily available way to do authentication) there is a surprising feature
- the use of client certs means reliable tracking. Not only is one
client cert useful in this respect when used "properly", the SSL
protocol is built to allow the server to request information from the
client to provide multiple identities, further allowing data mining.
There isn't any easy way out of this because PKI is so limited in its
focus to a particular (less relevant) threat model.
(PS in any case, I think this is probably too low a risk to be worrying about
for base camp, but just wanted to have the discussion.)
Possibly. It might be McNealy's "get over it" result.
iang
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
