Collect: Extend audit log to include GPS coordinates

We can certainly include a note in the documentation that form designers should be aware of privacy regulations.

As far as the user, said user would have had to previously accepted that Collect will have access to their location. Additionally, the GPS icon on the top of the phone's UI will be active and blinking while their location is being collected (and I'm pretty sure the whole time the form is open). What other UI elements would you add to Collect to provide greater visibility into what is happening? Sketches or mockups are welcome!

1 Like

I think its less the issue that Collect is acquiring or using the GPS, but rather that the user's location is actively being tracked, and that this data will be reported back. Perhaps something a simple as a short read-only note at the beginning of the form saying "This form actively tracks and reports your location." Which could just be a recommended best-practice to form writers when using this feature. At the end of the day, Collect is just a general purpose tool, so the burden lies on the form creator to ensure it is used in accordance to local regulations.

What I dont want to see happen is for Collect to be inadvertently labelled a 'spyware' because someone deploys a GPS audit tracking form but never informs their users. This is the difference to, say, Google Earth - which is constantly using the GPS, but not actually reporting your location back anywhere to be processed for ulterior purposes.

1 Like

@Dr. Gareth,

I seem to see your concern.

Maybe at enumerator recuitement/hiring, a statement like "we trust you will collect data authentically and credibly. Inbuilt device features will be used to verify this" could be included in their terms of engagement. Metadata including GPS coordinates will have been taken care of.

I think it's a thin line working to make data collection as credible (researchers and data managers could understand what I mean) as possible and not "spying" on field staff.

Please let me know when the feature is ready for use. Hoping to try it ASAP.

Asante,
Paul Macharia

1 Like

It is a difficult question but I think manageable if what is proposed is to record the location when a question is answered. Ie using the audit log. When they are answering questions then presumably the enumerator is working and if they answer that question in a bar then its not unreasonable for the employer to know. If they spend their time in the bar playing candy crush then no location will be recorded?

It would be good to have an icon at the top of the phones UI displayed to indicate that the GPS location is being recorded while the form is completed. I take it the GPS icon that Yaw refers to just indicates that GPS is enabled ? Could an ODK specific icon be added to show that it is also being recorded?

[After cogitating on this for far too many days now, I think I've changed my mind... sigh].

As loath as I am to drag anything remotely resembling public policy into a technical discussion, I do feel strongly that ODK is a force for social good, through its facilitation of collecting (hopefully) accurate data about the world we live in. I would not want to see ODK exploited for ulterior purposes, but in this day and age there are many examples of cutting-edge technology being exploited without consideration of individuals' rights of privacy. At the end of the day I think we all have the right to know whether the devices we are carrying are actively recording and reporting our daily activities (including our precise whereabouts) so that we may at least respond accordingly. ie "informed consent".

Knowing how easy it is to subjugate, I also don't automatically trust those who provide me with technology to hold my privacy paramount. Providing a mobile device, along with some suitable forms, makes it too easy and attractive to covertly track a person's location, without their knowledge, at the flick of a switch ('justified' or not). My inclination might therefore be to have Collect always pop up an alert whenever starting any form that activates GPS audit tracking, of the ilk "This form actively tracks and reports your location. [OK] [Get me out of here]". eg this is much as Firefox does when encountering untrusted webservers, and seems more in keeping with the predominantly socially conscious nature of open-source: the user comes first.

Or to put it different way, what is the compelling argument against explicitly alert users when their location is actively being tracked and reported, and giving them a way out?

[OK. I'm going to shut up now, put my tinfoil hat back on, and retire to my fallout shelter... :slight_smile: ]

2 Likes

Apps request permissions upon install. Would it make sense to have an automatic screen at the start of filling a blank form that alerts the user as to what metadata is being collected (should users know that a form is recording start time and end time and logging the time spent on each question)? Do we make this optional. as it's certainly good practice but also there are circumstances where it might not be desirable... enumerators might be already briefed on what's being collected and be tasked with completing a large number of surveys in a limited amount of time and having them be required to swipe past another screen each time they start adds an unnecessary and ultimately burdensome amount of time to the data collection process? Could you make the screen show up only the first time a given survey form is opened... but what if a device is shared among multiple enumerators or the supervisor checks the device/form once before handing it off to an enumerator and they never see it? Would a warning upon just opening the ODK Collect app be enough? Generic such as "forms filled out with this device may be configured to collect X, Y, Z in the background" or somehow a custom message based on the survey forms that have been downloaded to the device?

1 Like

@danbjoseph Perhaps you have some insight here: to what extent do field surveys typically/atypically involve notions of anonymity of the subject(s)? For most practical purposes, taking a GPS fix in a survey eliminates any guarantee of anonymity (unless all your subjects travel to you). With an explicit geopoint question in the survey it is obvious to both the enumerator and subject that their exact whereabouts is going to be reported. But in a survey without such question, but with GPS audit tracking, there may be a mis-perception on the part of the subject that their responses are still anonymous. Thoughts?

1 Like

excellent point. however, i would also argue that geopoints may be frequently collected without the subject knowing as well. for example, after exiting a house the enumerator then records the location. pressing the button to record a geopoint can be done without saying anything to, or asking anything of, a respondent. i'm not sure how much of this can be solved with software design (short of just not implementing functionalities) and how much needs to be just following best/ethical practices when implementing surveys? other random side thought is that some forms may be only observational and there is no "subject".

1 Like

To add to what @danbjoseph said, I would guess most of the folks that collect GPS location of a participant (not the enumerator) don't tell the participant. It's not ideal, but there's not much we can do about that.

@Xiphware Form designers (who are also our users) do not want to give enumerators a way out. That is, if a form says you need an audit, then it is required and your options are to accept to have the audit log or the form doesn't load.

I'm not opposed to notifying on form load, but I want to make sure we aren't adding a burden to the common case: enumerators who are being hired and have been briefed on the terms for their hiring.

I propose we add dialog on form load that says, This form collects your location in the background (or something similar) on first load with an OK and Do not show again option. This adds more state that we have to track in the app, but so be it.

The caveat here is most enumerators will not see this message because they often aren't the ones that open the form first, but I think it's the best we can do.

2 Likes

I think this is reasonable. The 'user' is, in effect, acknowledging that they are installing an optional component to an app which will collect and report their location information. And the fact this acknowledgement itself is being audited, means we have a paper trial to prove they agreed, should they subsequently dispute their consent.

2 Likes

Hi everyone. I have started investigating this issue. Here is the doc I'm working on https://docs.google.com/document/d/1Xw4WOctVgg11ZfYwTnrL6qlTKSYwhn_pTc2GQ1OFaFM/edit?usp=sharing

Please review and comment if you have any thoughts.
Thanks!

1 Like

Hi All,

Under GDPR we would need to collect specific a priori consent to collect GPS data on the enumerators [opt-out is a key thing that GDPR precludes. all consent must be 'opt-in']. In a research study we would additionally require ethics board consent (both from lead institution and in country boards) to do the same. You would need only collect this once per enumerator per study, so a consent form signed by your team members at the start of the study would allow you to 'track' the enumerators throughout the study.

Possibly more important is that this form behaviour implicitly collects gps data on study participants in a study where the data being collected involves collection of data about living individuals. This also requires both a priori consent from the participant and ethics board approval, which I am confident that you would never get from any ethics board. They are very unlikely to allow any study to collect gps in the background for 'project monitoring' reasons because those data have no specific and direct contribution to the goals of the work but would make it possible to identify the location of individuals, their homes etc.

A standard requirement for any GPS data would also be encryption on the server. GDPR sees no legal difference between data that are fully identifying or pseudonymous (or actually encrypted) and GPS data are not considered to be anonymous whether names/ids are attached or not. Encryption is therefore the bare minimum for making it 'reasonably unlikely' [a GDPR term] that a malicious actor could identify individuals and their locations from any information in the data set, including 'background' metadata and audit information.

1 Like

@Jefferson_Francisco this feature is being track as a card on the project roadmap and is currently in the "Under Consideration" category

@chrissyhroberts thank you for your valuable and detailed input. this feature would be something that has to be enabled by the form administrator, and not a default part of the audit log. there are a wide variety of users of ODK and i think there are scenarios for this feature that are outside the use-case you outline (paid enumerators, that have signed consents about the tracking, that are surveying utility assets like light posts or agricultural features?). it is important that any user of the technology understands applicable legal issues around their activities. we would hope they would also consider what is generally good ethics, regardless of a legal framework to regulate it. even with just the geopoint question, it would be possible for an enumerator to collect location of a surveyed person without explicitly asking their consent. and even a basic text question collecting someone's name means you should encrypt and protect your data. while including the option to add location to the things tracked in the audit log is something people could use unethically and/or illegally, i'm not sure it increases the potential for unethical action that much when you consider the full range of functionality of any widely adaptable mobile data collection tool. but i would be interested in hearing arguments to the contrary. there's a huge breadth of experiences within the ODK community and the many different perspectives help make it a stronger, better project.

2 Likes

@Jefferson_Francisco && @danbjoseph : The point is not to only comply with GDPR but to consider as paramount that this is a data tool and that the way the developer community implements the tool's features is both a guide and functional limiter on best practise for data collection. I think it is very much the responsibility of the developers to consider how the feature implementation supports all users to make good decisions about how to collect their data in a responsible way

You make a strong point that ODK is an open tool, but open is about more than just the source code; it is also about behaviours. If you essentially want a tool that can surreptitiously check that your submitters were where they said they were (implicitly saying that you neither trust them nor the data they submit) then this is far from open and in the realms of the kind of intrusive tracking that Google, Facebook and co are rightly criticised for.

In my opinion if you want to know where your data was collected, then an open, front facing gps data collection that the operators are aware of is the simplest, most open tool for this. OK so it seems that the current gps widget might need to be altered so that data entry does not include the ability to change the gps data manually.

Finally, I think it is important to remember that many GPS modules will fill the last good fix data because the assigned variables may not be cleared out when the GPS is not feeding new NMEA sentences. This means that if the GPS signal goes down and the secret gps tagging collects an old gps signal, then it might look like your operator faked all their data and sat at home submitting forms; when in fact they were working with a dodgy signal. Are you going to fire them on the basis of this data? We've seen this GPS behaviour on lots of mapping tests. Would be very important in the least to collect data from the correct NMEA sentence and ensure that date and time were captured, as would support you not to make such mistakes.

Hi All. Data protection/privacy concerns are very real and an important thing to discuss. Please refrain from ad hominem attacks or comments that might appear to cast negative intentions on anyone here. This forum is an important place for the community to come together and discuss things like this, but please do so in a civil manner that takes into account that people from a wide variety of cultures/backgrounds/etc may be on here and what one person might interpret as simply "direct" might be interpreted differently by someone else. I've seen plenty of shouting matches erupt on forums and list-serves and I don't want this to devolve into that, as nothing productive usually comes out of those.

2 Likes

Thank you, @danbjoseph, for bringing us back to respectful discourse.

I'm not sure whether this was made explicit but this is very much not a theoretical requirement -- several large organizations already do this kind of background position capture with the full cooperation of their enumerators and in compliance with local regulation. Currently, they need to build custom applications or rely on existing third-party applications. This makes the analysis difficult and makes linking positions to events in the form quite difficult. Alternately, some other organizations have the enumerators manually request locations at different points in the form. This is tedious for enumerators and can slow them down significantly.

There is plenty of room for logs and checks even in a context where everyone is fully trusted because mistakes or misunderstandings can happen! @yanokwa, perhaps the goal statement could be reframed slightly because it really does place a lot of emphasis on "cheating" when that's not my primary understanding of why this feature is important.

First, please note that the collection is not intended to be secret. The current specification includes a UI-blocking dialog on the first load of a form to ensure someone who has installed Collect themselves will always be aware of the position logging. Additionally, every subsequent open of the form would result in a snack bar appearing at the bottom of the form to remind the user that their position will be logged by the current form. GPS access is NOT intended to be enforced. That is, an enumerator would always have the ability to turn off access to the GPS if for some reason their location should not be tracked at that time.

The current proposal includes the form developer specifying a window of time in which points are accepted. If no point is available in that time window, no point will be logged.

I have not heard anyone suggesting making personnel decisions purely on the basis of audit log information. Generally the location data is used as part of the data analysis in some way. If it is considered for monitoring purposes, I am sure that it would only be one piece of information considered. That said, as others have noted, if organizations want to fire their enumerators for something trivial like using the letter "q" too many times in their answers, there's unfortunately not much that can be done about that.

1 Like

[emphasis added]

I think this will go a long way towards satisfying informed consent and opt-out requirements. However we should also probably anticipate additional requirements - around checks-and-balances and privacy guarantees - coming in once deployers begin using this new feature in the field and actually have to look at whatever national/regional/local privacy laws they must operate under (eg GDPR).

It is worth noting that regulations around this do vary greatly, not just between countries but even between states, and there are quite different rules around GPS tracking of company assets (eg vehicles), company owned-mobile devices (eg phones), employee-owned phones, and single-purpose GPS trackers. Again, we should probably anticipate that what is proposed currently may well not suffice as a one-size-fits-all, and many deployers may want additional knobs in order to comply to local privacy regulations...

Please accept my sincere apologies @Jefferson_Francisco @LN and community members. Clearly I helped to push this discussion thread towards an outright argument, which was not my intention at all. Also apologies for glib terminology such as 'secret' which should probably have read 'background'.

@LN I absolutely get the point that having stuff happen in the background can be preferable for many reasons, including some that actively benefit the enumerator. I suppose that at the heart of this is the problem that whilst geopoint information is usually collected as data, it can also sometimes be metadata. I agree with you and @Xiphware that the use of the snack bar would basically solve the argument by making the process transparent. It's a half-way house between a foreground and background process.

I also think @Xiphware is right that data law complexity and diversity is massive and currently in a state of rapid change. This sort of thing may need to be continuously re-scoped. Flexibility in the functions of the software is clearly needed here as everywhere in the ODK ecosystem, but I would be concerned if that flexibility extended to options to do things like turn off the snack bar message.

Best wishes to all

2 Likes

@chrissyhroberts, you clearly have experience, knowledge, and opinions on the matter. Thank you for sharing and being willing to discuss. Important cues like tone of voice are lost when discussions are carried out via written word or missing when discussions are with people you haven't built a relationship with. Was just preemptively reminding everyone of that earlier. We're all in this together.

1 Like

This feature has shipped in ODK Collect v1.20 Beta. Please try it and offer your feedback in the beta topic.

1 Like