Re: w/r/t Privacy

On Tue, 4 Nov 2008 14:49:44 +0000, Andrei Popescu <andreip@google.com> wrote:
> 
> > So in effect users of that platform are screwed either way. The either get an 
> > inconsistent UI that will be confusing, or are misled as to what will happen with 
> > their data.
> 
> Ah, with this I disagree. What you are saying is true only for the case where:
> 
> 1. The platform implements a mechanism that misleads the users about
> what will happen to their data,
> 2. The Web UA on the same platform decides to implement a different mechanism.
> 
> But how about a case where the platform implements a privacy mechanism
> that is not misleading? In such a case, the UA will implement / use
> the same mechanism, which is both not misleading and not confusing :)
> So the point I am trying to make is that the Geolocation specification
> should allow an implementation to make its own choices, essentially
> making it possible for UAs to actually achieve the optimal
> non-misleading and non-confusing scenario.
> 

I disagree with your point (1). Let me try to illustrate with an example. Say there's a company that makes mobile devices. These devices have a GPS unit but no internet connectivity. The platform on the mobile device is proprietary and closed. Third-party apps are allowed, but in order to use the location information from the GPS unit they are *required* to follow the user-specified usage rules. (For the sake of simplicity, let's say the usage rules consist of a duration, which is how long the app can hold on to the location data). The platform enforces this requirement by a relatively simple mechanism: the third-party developers are subject to source code audits by the mobile device manufacturer to ensure their code complies with the requirement. If it does not, or if they refuse the source code audit, their app is banned from the platform.

When an app requests user location information, the platform pops up a dialog asking the user whether or not they would like to provide their location, as well as for how long they would like their location to be kept for. The app receives the location along with the duration (i.e. the usage rules), respects those rules (or it wouldn't be on the platform in the first place), and everything works great. Agree so far?

Fast forward a few years, and users of this platform are begging the manufacturer to provide access to this new-fangled "Internet" thing. So they stick on a radio and throw in a web browser. That part's easy. However, when it comes to location-enhanced web pages, they are in quandary. Every app on their platform that uses location information gets usage rules along with the location information. The browser can do this too on behalf of the web page, but it has no way of actually communicating those usage rules to the web page. So in effect, if they chose to do this, it would be misleading to the user *only in the web browser*. In all other apps where this dialog is displayed, it is not misleading at all because the requirements are actually enforced.

The other option is to display a new dialog that only allows the user to confirm/deny location info access, but does not allow them to specify how long that information can be kept. While this is in keeping with what the web-facing API allows, it is different from what the rest of the platform supports (this is the "confusing" case).

Does this situation make sense? This is a platform that *actually enforces* user-provided usage rules to the extent that they can (which is in all app except the web ones). The web is open by nature, and so is fundamentally different. Random web pages are not subject to source code audits, and cannot be checked for compliance with the platform requirements. Creating a whitelist of every page that complies with their requirements is infeasible for obvious reasons. This is what I meant by "an artifact of how the web works" - the web is a platform with fewer constraints than the one in my hypothetical platform above, and when you try to merge the two you end up with a mismatch.

> > 
> > Given the choice between confusing users and misleading users, it seems that CDT is 
> > advocating the "misleading users" approach and everybody else is advocating the 
> > "confusing users" approach. Both seem pretty bad to me, but I can't think of any other 
> > solution that makes sense either.
> > 
> 
> How about the third alternative, which has been suggested several
> times in various threads: allowing for the implementation to pick the
> best choice for their users?
> 

If you can point out a choice in my example above that is neither misleading nor confusing, I'd be much obliged. I think that at best, it's a choice between the lesser of two evils.

Cheers,
kats

Received on Wednesday, 5 November 2008 03:13:42 UTC