Closed Bug 1027429 Opened 6 years ago Closed 6 years ago

duration = 0 Not Sent To Device- Device unable To Determine if Not Being tracked

Categories

(Firefox OS Graveyard :: FindMyDevice, defect)

x86
macOS
defect
Not set
normal

Tracking

(blocking-b2g:2.0+, b2g-v2.0 fixed, b2g-v2.1 fixed)

RESOLVED FIXED
2.0 S5 (4july)
blocking-b2g 2.0+
Tracking Status
b2g-v2.0 --- fixed
b2g-v2.1 --- fixed

People

(Reporter: kglazko, Assigned: ggp)

References

Details

Attachments

(1 file)

46 bytes, text/x-github-pull-request
vingtetun
: review+
Details | Review
This currently doesn't occur, but may need to in order for Bug 1000173 to land.

The code in 1000173 assumes that when duration = 0 is sent, the device is no longer being tracked. Otherwise, the device might assume that it is being eternally tracked even when it theoretically shouldn't be (i.e. disabling geolocation on device).
Blocks: 1000173
I don't think this needs to block bug 1000173 necessarily, but it's worth using this bug to consider when to stop tracking.

Apparently there's no way from the web interface to ask the phone to stop tracking.  Nick, is this correct?

The case in which geolocation is disabled while tracking was considered, but backlogged, some time ago (see item 4 at [1]). I don't know if a bug was filed, but I wouldn't worry too much about it now.

I do think we shouldn't track indefinitely -- either we guarantee that the server will send a zero-duration track eventually, or implement a client-side timeout.

1- https://etherpad.mozilla.org/FMDGeoUserStories
Flags: needinfo?(nchapman)
> there's no way from the web interface to ask the phone to stop tracking

ggp, that's correct. I think the ideal situation here is that the FxOS FMD client would respect the duration and period values in the track command and the web front-end could keep resending the track command periodically to keep tracking. For example: the web would send { t: { p: 10, d: 60 } } (send tracking info every 10 seconds for 60 seconds) and resend that once a minute. Once the web front-end was closed, the last tracking command would timeout and the device would stop tracking.

As a stopgap measure, we can have the server send a 0 duration to the device when the websocket connection closes to the web front-end. This is less than ideal since this would stop tracking the device for all sessions for that device (multiple browser windows), not just the one session that closed. More importantly this puts the onus on the server to "do the right thing" rather than having the device be concerned about protecting itself from oversharing or running down its battery. That's why, philosophically, I think something like the first solution is the better one long term.
Flags: needinfo?(nchapman)
Fair enough. As far as I know we deprecated the 'period' parameter, but I'm fine with respecting the 'duration' parameter.
Attached file gaia pull request
This patch depends on bug 1025193, which should land shortly. But for now, the PR contains patches for both bugs.
Attachment #8443001 - Flags: review?(21)
Rebased PR on current gaia master, it only contains a single commit now.
blocking-b2g: --- → 2.0?
Whiteboard: upliftneeded
Whiteboard: upliftneeded
Erin

Need user impact here
Flags: needinfo?(elancaster)
This is to make it so the device doesn't assume that it is being eternally tracked even when it theoretically shouldn't be (i.e. disabling geolocation on device). See Comment 2, as well.
Flags: needinfo?(elancaster)
blocking-b2g: 2.0? → 2.0+
Assignee: nobody → ggoncalves
Keywords: checkin-needed
Master: https://github.com/mozilla-b2g/gaia/commit/4ee910db5f32419b433e203b2b31cb0112bd85e3
Status: NEW → RESOLVED
Closed: 6 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → 2.0 S5 (4july)
You need to log in before you can comment on or make changes to this bug.