RE: 答复: comments of Network Information API

The same concern over fingerprinting based upon connection type could apply to the bandwidth or metered attributes. You can also deduce things based upon them. But we either need to get over that risk or put the API access behind some type of user permission model ala GeoLoc. Otherwise we will be left with nothing in this API, at least no more than what we already have with the navigator.online attribute.

I would support a requirement to obtain user permission to access this API, if we were able to get the type attribute back, and get beyond these privacy concerns.

Thanks,
Bryan Sullivan

-----Original Message-----
From: Mounir Lamouri [mailto:mounir@lamouri.fr] 
Sent: Wednesday, March 28, 2012 5:24 PM
To: public-device-apis@w3.org
Subject: Re: 答复: comments of Network Information API

On 03/22/2012 10:05 AM, Poussa, Sakari wrote:
> I also want to have the 'type' attribute back. For the same reasons than
> the others.

I do not think the connection type should be exposed to content. It's
something that could be exposed to some content behind some permission
model but not regular content that doesn't require any permission.
As I said in my initial email about the Network Information API, there
are three major reasons:
- fingerprinting: it's adding a few bits of entropy;
- privacy: you can deduce a few things based on that information: 3G or
up would usually be in big cities, other mobile connections would be in
country side or some places with bad connectivity (like metro) and the
most important is that wifi usually means you are in a place you go
often (home, work, friend's place, ...);
- bad assumptions: people will assume your connection is slow if you are
using a mobile connection that is "2g" for example.

> I also think that the bandwidth attribute is hard to implement and will
> cause inconsistent behavior on WebApps depending on the UA/platform they
> run on. Finally, the .metered attribute is confusing and I don't see the
> value of it.

I'm open to alternatives.

--
Mounir

Received on Thursday, 29 March 2012 05:40:22 UTC