Re: w/r/t Privacy

Hi Kats,

On Wed, Nov 5, 2008 at 3:13 AM, Kartikaya Gupta
<lists.geolocation@stakface.com> wrote:
> 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?
>

Agreed 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.

You mean it has no way of *enforcing* those rules, right?

> 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?

It does. But note that it's just one situation. It does not
necessarily follow that every platform suffers from the exact same
problem.

>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 agree that, in your example, the privacy mechanism of the Web
browser would probably have to be different to the one enforced by the
platform upon native applications and that some users may find this
confusing. I also agree that, in general, a UA may not be able to
enforce some sophisticated privacy rules that can only be enforced by
reviewing the actual source code of the application that is subject to
those rules. But it seems to me that this is not exactly the point you
are trying to make.

> I think that at best, it's a choice between the lesser of two evils.
>

I respectfully continue to disagree with this as I think this is a
false dilemma. Your reasoning is based on an example (please see
http://en.wikipedia.org/wiki/Proof_by_example), so that cannot imply
that all possible platforms where Geolocation API will be implemented
will suffer from the same problem. There will be platforms where the
privacy mechanism implemented by the UA will be neither confusing nor
misleading and I continue to believe that the only way to make this
possible is to allow them to chose what to implement.

All the best,
Andrei

Received on Wednesday, 5 November 2008 14:10:12 UTC