Spike: Determine Best Location Service for Proof of Concept

[iamjoshfrank]

Background

This Issue may become unnecessary if we discover by way of Spike: In/validate Significant Locations Theory (#4) that we can in fact access iOS's Significant Locations feature.

However, assuming we cannot use Significant Locations, we need to quickly identify the most appropriate way to gather and save each a user's location history locally to the device.

Resources (Technical)

• One suggestion already on the table is to use the Significant Change Locations API.
• Other options might include other first-party location APIs within iOS:
  • Getting the User's Location, which includes Significant change location service as well as Visits location service and Standard location service
• Also, third-party libraries to assist with location tracking could be a good fit

Resources (Experts / Epidemiologists)

• If we have questions regarding location accuracy, granularity, timescale, or other, we can reach out to @Scott Teesdale in the #nightingale Public Slack. Scott can connect us with experts in the field to answer questions we might have.

Goals of this Issue

• Determine, within a short timebox, the most appropriate location service for the Nightingale iOS Proof of Concept.
• The location service (or combination of the location service and additional services) should enable us to deliver a list of user-friendly (human readable) locations to the end user, not just lat/long coordinates.
• We should prioritize the users' privacy above all else. Trust is paramount to Nightingale and we shouldn't risk breaking that trust by way of a poor choice in location service.
• We're assuming that if we are tracking locations, those locations are only stored locally unless or until a user opts in to sharing their location history to the Nightingale server due to a positive COVID status.

Scenario: Decide on Location Service

Given we have ruled out Significant Locations (#4) as a viable solution

• [ ] When I have reviewed the goals of this Issue
• [ ] and When I am satisfied with a location service recommendation (via research and/or quick proof of concept)
• [ ] Then I share my recommendation with the team in a Comment below
• [ ] and the team makes a decision based on the recommendation

[DejaTrudeaux]

@iamjoshfrank Here's some of our findings from our Zoom call, and this is the Google Doc we've been hashing it out on since >> https://docs.google.com/document/d/1TUgPYizBos2mcHIBgcPdJ5e_C4cJtYeb0YDoHYnQ8hc/edit

Limitations: Using Apple’s Signification Locations, we are unable to get location history from weeks before. We talked a little bit about using another API to get previous locations but decided that as a user, doing so might prove a bit unsettling anyway.

Plan: To establish trust with our users, we think it would be helpful to have an onboarding process to ask a user for their cooperation in establishing previous locations in the past 20(?) days. This way, the user would be eased into accepting the contact tracing thing, which is a new experience for most people.

Loosely, we would want onboarding to look like:

• Notify them of hotspots in their parish (I think we’re just focusing on Louisiana) and add them if they’ve been to those hotspots recently.
• Ask for permission to collect location data starting now, and probably express the importance of their cooperation and of us collecting this data.
• We think we could use the Visits Location Service (apple specific? But probably ok for mvp since only focusing on iOS right now) Link: https://developer.apple.com/documentation/corelocation/getting_the_user_s_location/using_the_visits_location_service
  • “Each update includes both the location and the amount of time spent at that location. This service isn’t intended for navigation or other real-time activities, but you can use to identify patterns in the user’s behavior and apply that knowledge to other parts of your app.“

Next steps:

We will need to figure out as soon as possible what the hotspots are and how we are going to get those based on parish and use them in the onboarding process. - (We could leverage public health data for cases in LA).

[iamjoshfrank]

tl;dr

• move forward with Visits Location Service approach to gathering user's own location data by way of #6 (unless you get further technical review from outside your research team that says "stop")
• hold on proposed onboarding flow outside of friendly, informative prompt for location permissions

@DejaTrudeaux et al.:

I love, love, LOVE that y'all are putting your user-first thinking hat on when trying to solve for this problem.

What I think we need to do in order to fit within the scope of this week (and because it unlocks the rest of what we might consider the "core loop" of the prototype) is to focus on the first implementation of Visits Location Service to start generating a list of the user's locations, stored locally, and displayed to the user in the app interface.

I will gladly split out the task(s) of the "progressive onboarding" into a separate Milestone for consideration / prioritization.

Off the top of my head, one of the largest blockers to your proposed onboarding flow:

Notify them of hotspots in their parish (I think we’re just focusing on Louisiana) and add them if they’ve been to those hotspots recently.

is that easy-to-use, public data from which we can pull existing hotspot information doesn't exist (to our knowledge). Gerard is working on gathering some existing data samples and I might have a blind spot to existing, public datasets. But we can't let that outstanding question stand in the way of starting to track and store location data for our users, assuming that we have the ability to track locations as you suggest.

[HauwaAguillard]

Leveraging public health data we could start here: http://ldh.la.gov/coronavirus/. You could download and sort data via parishes, so it seems

[DejaTrudeaux]

@iamjoshfrank I wonder if, given the limitation of not knowing our exact "hot spots" at this moment, we can just have some type of autocomplete form situation that allows someone to type places in and choose from a dropdown whichever one they meant, and add as many as they'd like?

Eventually with enough users doing this it would become more obvious where the hot spots are at...? Just thinking out loud here. So instead of us saying "Have you been to these specific places" the user would enter that information and that leaves us with less guesswork as to which locations we should constitute as hot spots worth asking about.

[iamjoshfrank]

@HauwaAguillard - possibly. But I feel strongly that there are too many unknowns to include this onboarding approach for this week, because:

• there's no indication we can get a live feed via API of the LDH data, and so we might have to build a feature to download and ingest the data on a regular time interval (expands the scope)
• based on a quick review of the data points at http://ldh.la.gov/coronavirus/, they don't appear to be granular enough to help a user know if they've potentially come in contact with someone that tested positive (parish level isn't enough; and "tract" isn't identifiable enough at first glance)
  • doesn't get specific enough to achieve this aim that you've outlined: "Notify them of hotspots in their parish"

[iamjoshfrank]

I wonder if, given the limitation of not knowing our exact "hot spots" at this moment, we can just have some type of autocomplete form situation that allows someone to type places in and choose from a dropdown whichever one they meant, and add as many as they'd like?

This sounds more like, "ask the users to supply their own understanding of where hotspots exist," which isn't what we're trying to achieve.

Happy to hop on Zoom to clarify further if needed.

What I'm proposing is we focus our efforts after the first bullet point y'all outlined:

Loosely, we would want onboarding to look like:

• Notify them of hotspots in their parish (I think we’re just focusing on Louisiana) and add them if they’ve been to those hotspots recently.
• Ask for permission to collect location data starting now, and probably express the importance of their cooperation and of us collecting this data.
• We think we could use the Visits Location Service (apple specific? But probably ok for mvp since only focusing on iOS right now) Link: https://developer.apple.com/documentation/corelocation/getting_the_user_s_location/using_the_visits_location_service
  • “Each update includes both the location and the amount of time spent at that location. This service isn’t intended for navigation or other real-time activities, but you can use to identify patterns in the user’s behavior and apply that knowledge to other parts of your app.“

[DejaTrudeaux]

Oh, I see what you're saying. I may not have explained well enough. What I meant was that a user would be able to type in their previous locations from the past couple weeks, disregarding what a hot spot is in the onboarding process and just leaving it up to the user to provide their recent whereabouts.

But sounds good, I will switch gears and start thinking about next steps on second bullet point!

[iamjoshfrank]

Great, and I'll keep in mind the suggestion re: manually creating a list of locations during or after onboarding.

Carry on! (and try to update status on kanban when you can)

[Samkeer1]

To use location services in the first place, there's a location services authorization prompt in which we are required(I think) to specify the reason we're using a user's location data. https://developer.apple.com/documentation/corelocation/requesting_authorization_for_location_services

[DejaTrudeaux]

I've been having a gander at this: https://developer.apple.com/documentation/corelocation/getting_the_user_s_location trying to decide which seems best for our purposes. I think we can rule out Standard Location Service as it seems to do much more than we need.

Between Visits Location Service and Significant-change location service I think Visits location service would probably work best.

• Visits location service
  • provides both the location and time spent in that location, only updates when a user has spent a significant amt of time in that location. It's used to identify patterns which I think is what we're trying to do. vs
• Significant-change location service
  • doesn't rely on GPS, but as a result is not as precise. This one also only updates with significant movement of a user as well

I think both have their perks but it'd probably be good to get more accurate locations and use GPS, right? One question I'm thinking about though is whether or not we can configure what is considered "a significant amount of time spent" in both cases.

[jwietelmann]

@DejaTrudeaux Do any of those provide access to history, though? If so, that's our most important differentiator.

[DejaTrudeaux]

@jwietelmann I don't want to be the one to make the final call, but I think we realized that none of these allow access to previous location history bc of a privacy concern. So we talked about taking a different approach which involves an onboarding process asking the user to provide that information. see here: https://github.com/revelry-foundation/nightingale/issues/5#issuecomment-634242685

please let us know if you disagree

Edit: Just poking around and saw this potential alternative in google maps api https://support.google.com/maps/thread/40110147?hl=en I mean idk who that guy is but if a user can download their own timeline then submit it to us that would provide accurate data, however i don't know if people would be willing to do that.

also https://support.google.com/maps/thread/34604814?hl=en

[jwietelmann]

If engineering has completed the research to figure out if/how we can get history (sounds like we have), and we don't have big engineering concerns about any which of these ways we end up going (sounds like we don't), then it's time to present your findings to product for them to pick from (cc @iamjoshfrank)

(Also, keep in mind that pinpoint GPS accuracy may not in fact be the most important thing, and the approximation of significant locations to, well, significant locations, might be better. IDK.)

[jwietelmann]

If anyone ends up liking the "manually download from google" route, one can go here to download their entire location history: https://takeout.google.com/settings/takeout

[iamjoshfrank]

Yep, this all confirms my assumptions (re: Apple doesn't provide a way for a newly-installed app to access existing location history that might already reside on the phone). As I prepped over the weekend for this week's Spring, and after reviewing the documentation and the Stack Overflow question I linked to in #4, I absolutely came into today with the assumption there would be no good way to get the user's pre-app-download location history. But I wanted to have the team validate or invalidate those assumptions.

1. I'm tagging @gerardramos to make sure that we're good with moving forward given lack of access to location history. Again, this puts us at a common disadvantage with any other solution - even the Apple-Google Bluetooth API.

2. My called shot is we move forward with one of the standard location libraries (or a React Native alternative?) and prove out we can safely, securely, and privately store location history locally; unless Gerard pulls the emergency break.

Then we have to take on the task of really "selling" to the user that we're doing it privately and only using it when the user takes action to specifically share it. Regardless of having access to the history or not, we were always going to have to make the pitch to the user re: trust and privacy.

---

Any other approaches to getting prior location history, either manually input location-by-location by the user (ugh) or by offering to import it from Google (if the user has a Google account) I would deem outside the scope of this week's prototype unless we end up with people that have available cycles to experiment with it.

---

I'm not sure I'm equipped to speak to the differences and advantages/disadvantages of Visits location service vs Significant-change location. Based on @DejaTrudeaux 's comment / description above, I'm inclined to suggest we move forward with whatever helps to best achieve the following goals as stated in #6:

• User privacy is paramount. We're assuming at this point that storing the location history locally best serves this purpose. If other recommendations exist, please make them and advocate for them in the Comments.
• Any location tracking should be as minimal as is effective. This includes granularity and timescale.
• We should verify with experts the timescale that is appropriate to store locations for the purposes of contact tracing. Our assumption currently is for a period equal to today minus 14 days.

My gut tells me Visits location service is the way to go, if indeed Significant-change location distance cannot be fine-tuned to less than 500 meters (which is ~546 yards, or the equivalent of 5 +football fields). My assumption is that 500 meters isn't specific enough to be meaningful. If we need to verify this further, someone please shout so we can cue up an expert for answers.

It then delivers location updates to your app only when the user’s position changes by a significant amount, such as 500 meters or more. Source: Apple documentation

[Samkeer1]

@iamjoshfrank Regardless of which service we use, it looks possible to set a 'distanceFilter' to determine how far a user needs to move before location updates happen.

[jwietelmann]

Correct @Samkeer1 - And we should use it no matter what because of battery considerations, at a minimum.

[jwietelmann]

If either option gives us things like addresses/business/pubic space names, then as far as I'm concerned it's kind of a coin toss unless there are implications one way or the other for, say, background usage. I somewhat suspect it won't matter that much and we can pivot fairly easily if the first one we try turns out not to be the ideal.

[Samkeer1]

I agree. It might not even matter, but Visits seems to provide a specific location. Background usage-wise, they're both pretty efficient. Here are the documented breakdowns of the two services:

[jwietelmann]

Let's just start with Visits and go from there. Find us a popular React Native lib that can do it in the background.

[iamjoshfrank]

Agree! Get this closed and move over to #6 to start design/implementation.