Privacy consideration about tracking location

[jyasskin]

If an app has the "system" lock or higher, it can send network requests to track the user's current IP address, and can probably use geolocation.watchPosition() to track the user's physical location directly. Users must consent to this when the wakelock is active.

[thecodingdude]

You already need permission to use geolocation anyway, for example:

navigator.geolocation.getCurrentPosition(loc => { console.log(loc) });

Will show a prompt for access. Websites can already track a visitors IP simply by loading the page (web server logs, for example). An IP address is not considered sensitive/personal information for this reason.

[jyasskin]

The issue is about when this information is exposed. If it's exposed while the user's actively looking at the site, that's what the user has consented to. If it's exposed while the user's walking around maybe not even looking at their phone, we can't assume they've consented using the normal geolocation prompt.

(An IP address is usually PII, not SPII.)

[xfq]

Should we move this issue to https://github.com/w3c/system-wake-lock ?

[samuelweiler]

@xfq @jyasskin where did this issue originate?

[jyasskin]

I think I first filed it here, when this spec covered both "screen" and "system" wake locks. Now that the spec has split, I agree it applies to the system wake lock and not the screen wake lock.

[xfq]

Thanks. I have transferred the issue.

[EricMwobobia]

@jyasskin You raise a valid point - given the app requires the IP for network connection purposes, would limiting the data sent out by the geolocation.watchPosition(); success callback to only the features with customer consent to help preserve user privacy. Is this feasible?

[jyasskin]

I think there's a privacy worry about even giving out the IP address (e.g. https://whatismyipaddress.com/ probably shows your city), although it's clearly less than the geolocation API. I could imagine having the system wakelock end if the system's IP address changes, but that could break use cases, so an explicit dialog might still be useful.

[EricMwobobia]

@jyasskin True, let's explore further. It's interesting how we'll tackle the privacy concerns on the IP as the app server will require the IP in order to exchange information with the user. It's a delicate balance.

[hadriann]

All things aside, the spec for system wake lock seems stagnant. And with no spec, there will be no implementation. @anssiko any idea why is this happening and what is needed to get the things moving?

[anssiko]

@hadriann, I opened a separate issue to address your question, please see https://github.com/w3c/system-wake-lock/issues/4 and follow up there as appropriate.