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

Enhancement: hard location geofence capability #815

Open
nickswalker opened this issue Oct 17, 2024 · 2 comments
Open

Enhancement: hard location geofence capability #815

nickswalker opened this issue Oct 17, 2024 · 2 comments

Comments

@nickswalker
Copy link

I am interested in having a user-understandable guarantee that the client won't transmit data except for when it's within a predefined region. Wanted to start a discussion as I'd be interested in contributing toward this capability in the medium term (next 6 months).

The benefit would be to make users more comfortable when connecting to a broker they don't control. My specific use case involves many event participants downloading and using owntracks to share their location while participating in a particular area for e.g. a weekend. It is a difficult ask for some without guardrails so that they don't unintentionally broadcast more than they intended.

The closest that's possible now would be to use Region Monitoring with automatic monitoring mode change to switch into manual mode when leaving a region. This doesn't protect the user from manually flipping the mode, or pressing the "send location now" (though that button is fairly explicit 😄). The other issue is that the interface for this feature is currently somewhat obscure; new users do not know what the pipe and number tags on regions mean. The subtlety of what "quiet" means is also probably not clear to new users.

I think it would make sense to build from the existing region system to introduce some kind of "incognito" mode (to take a familiar term). When specified, these regions (or one special mega region?) would be checked as an allowlist before the device sends out any message. This would have to be thought through to ensure that it doesn't become a source of silent failure if misconfigured, but I believe could be made sense-able by e.g. rendering specially on the map. My use case calls for fairly granular fencing, like using 100s of point radius pairs to hone in to within a couple of block radius around a marathon course through the neighborhoods that participants live and work in.

Related: discussion on why it was useful to enhance a hook in the recorder to support a hard location filter
owntracks/recorder#458

@jpmens
Copy link
Member

jpmens commented Oct 17, 2024

This sounds to me like a bit of a niche use-case useful only in situations such as the one you describe. If I understand you correctly this would be for a group of people who meet for a weekend or so and who would a) need to install OwnTracks and b) correctly configure it. After using the app for a couple of days most would likely uninstall it.

(IIRC this has been done before -- for a race or marathon; a number of years ago...)

Furthermore, you are proposing this idea for our iOS app; do you plan on doing the same for the Android app, or is that beyond scope? (We try to attempt feature parity though to be honest we're far from it.)

Edit to add: I am of the opinion that our app is becoming too complicated with too many distinct scenarios which are not easy to understand.

@nickswalker
Copy link
Author

I think of this generically as "I want to share my location with a server but I don't trust it, so let me set the terms." I don't know how frequently this comes up. Perhaps others can chime in if they have ever needed/wanted this capability.

The particular scenario I described is definitely niche. Though it has attracted some closed solutions (RaceJoy, RaceID Spectate) that have no privacy guardrails.

I'm unsure how much complication would need to be introduced to support reduced trust in the server. A lot is already taken care of by the fact that configuration is fast, so the user can install and delete the app if they need to feel in total control. What's missing is basically some confidence should they install early, or later forget to delete the app. It's possible that it would be sufficient to clarify what "quiet" means, and to make the existing auto mode change UI more explicit (like, add informational rows about what mode changes will occur to the region detail tableview, or noting the mode change in the local notification when the user triggers the transition).

Would like to add it to both clients, but I'm only familiar enough with the iOS client features to know that it would plausibly fit in.

I agree that there's already a lot/too much in the app.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants