Re: Network Information API

Thanks, Frederick, for highlighting these privacy concerns. A couple comments inline. —Nick

On December 9, 2013, at 1:18 PM, Josh Soref <jsoref@blackberry.com> wrote:
>> a couple of privacy questions:
> 
>> does this API enhance fingerprinting possibilities by allowing
>> enumeration of interfaces?
> 
> Technically you can find this by abusing network requests (both triggering
> magic dns requests to determine dns provider, and making arbitrary ip
> based connections to figure out local topography).
> 
> I think that for the average web page, instead of providing ³network
> added² or each new network, instead, browsers could simply provide
> ³network changed² when the primary network link changes. This should avoid
> fingerprinting / enumeration of interfaces for the average app.

I echo what others have said on this thread, that it seems like for the most common use cases, much less granular information suffices, and doesn't have the fingerprinting side effect of enumeration. While elaborate methods could accomplish fingerprinting via a series of requests and timings, preventing trivial and hard-to-detect fingerprinting is still worthwhile.

I think there's a privacy concern in using the pattern of fired events, too. If we expect background access to these events (because your podcast web app needs to know whether it should stop downloading into localStorage or not), simultaneously firing an event across frames/tabs/windows allows for potentially unexpected correlation across different browsing contexts.

>> does exposing a  persistent uuid provide user identifying information to
>> applications enabling correlation of activity across applications thus
>> creating a privacy risk?
> 
> So, this is a bit of a disaster of course, I¹m quite happy for it to be a
> randomly generated number which is only meaningful for a single session of
> a single web page - just enough so that a web site can distinguish between
> the current one and the previous one or something like that.

Right, using a universally unique identifier doesn't improve functionality and does negatively impact privacy. This has come up in enough different situations that we should come up with a common solution. I think a sequential integer where each new interface is assigned the next number during a particular browsing session would work just as well; there seems to be no advantage to randomness, uniqueness-beyond-a-session or persistence. (This is probably moot in this case, since per above, it seems like this level of granularity isn't necessary for most use cases.)