[Webkit-unassigned] [Bug 193946] Add a mechanism to provide geolocation information in background

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Jun 10 20:43:46 PDT 2019


https://bugs.webkit.org/show_bug.cgi?id=193946

--- Comment #4 from Richard Maher <thomasrichardtrinity at gmail.com> ---
> To me, the biggest question isn't so much whether this doesn't support 
> some use case but rather exposing background geolocation to a website
> is ever acceptable in terms of privacy at all.

I agree %110! Lots of work to do here but some ideas already suggested: -
https://github.com/w3c/ServiceWorker/issues/745#issuecomment-183159534

Sadly that thread is over 3 years old and parts outdated but it contains everything you want to know about Geolocation demand, W3C recalcitrance, and why Google Geofencing died. (And you have an hour of your life you never want to get back :-)

> Ordinary users don't really understand the implication of allowing 
> websites to get geolocation information in foreground, let alone in 
> background.

Again I agree, but these are Manifest driven. installable [P]WAs.

> Furthermore, keep running websites in background while the screen is 
> turned off is not something WebKit supports on iOS so there is also
> a practicality issue.


One advantage of the TravelManager design is *nothing* except the UA has to be running in the background until an "interesting" GPS reading is detected! Safari would listen/filter GPS readings and, when necessary, see if it needs to start a ServiceWorker or deliver a TravelEvent to an existing ServiceWorker. 


The ServiceWorker can then decide to foregrouound the APP (and/or pop up toast about background tracking) or, Far more likely, just send an travel update to the server who in turn can decide if a PushMessage is required.


Anyway thank you for engaging. Please feel free to mail me direct on maherrj at hotmail.com. I'm just worried about being blocked. Again :-(

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190611/a93f44a8/attachment.html>


More information about the webkit-unassigned mailing list