Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Case: Privacy-preserving background geofencing without server-side geotracking #253

Open
prushforth opened this issue Jul 19, 2021 · 1 comment
Labels
discussion: use case a possible use case: should it be included? what should it say? status: suggestion this issue discusses a suggested addition to the report, that is not yet in the draft

Comments

@prushforth
Copy link
Member

prushforth commented Jul 19, 2021

Geofencing is a large and growing requirement for the Web community, and yet browser makers are reluctant to implement, in particular, background geofencing, which is currently envisioned to be tightly coupled to the geolocation API because of privacy considerations.

In the classic sense of the Web, a browser is a "user agent". Today's user agents have no implied knowledge of space/location, because there is little / no motivation to have that, since there is no semantic way to represent locations/maps on the Web. This is a major gap, not only for accessibility needs, but also for mobile Web technology.

In today's technological environment the concept of user agent could (should) be extended to whole vehicles and other mobile devices. And it makes little sense to assert that those user agents have no need to understand location.

Consequently, the Web needs a way (a model) to represent geographic features that allows to preserve/implement spatial operations semantics on feature geometries, such that the user agent can process features' geometries as "geofences", and potentially notify the user in an accessible way when a desired interaction occurs. Such interactions should be detectable, perhaps as a starting point, by application of spatial relations operations. I believe these interactions could be valuable for accessibility users as well.

An example use case might be:

Driving an electric vehicle with proprietary charging requirements, I would like to be notified when I am within range of a charging station that matches my vehicle's characteristics. In my in-vehicle browser, using an interactive map dialog, I select the area I will be driving in, as well as other criteria of importance to me. The device accesses the charging station layer and caches the stations of interest, for offline use. As I drive, the browser continuously compares my vehicle's location, and charging status, with the charging station cached data. If conditions established in the original dialog are met, the browser notifies me of that fact.

One of the major considerations here is that it isn't the web site's code that is doing the spatial operations, but the browser code, which can be trusted to efficiently run in the background without disclosing your location to the web site; not without your say so, at least. When conditions were met, a notification could be generated that re-loads or loads a given web site if user permission is granted.

@Malvoz Malvoz added discussion: use case a possible use case: should it be included? what should it say? status: suggestion this issue discusses a suggested addition to the report, that is not yet in the draft labels Jul 19, 2021
@Malvoz
Copy link
Member

Malvoz commented Nov 26, 2021

This seems closely related to #75.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion: use case a possible use case: should it be included? what should it say? status: suggestion this issue discusses a suggested addition to the report, that is not yet in the draft
Projects
None yet
Development

No branches or pull requests

2 participants