Sensor Location Obfuscation

[keenanjohnson]

In #19 we started discussing whether the precise location of the sensors should be obfuscated. Let's continue that discussion here.

[spestana]

I found this article when looking for if anyone already had guidance on managing location data within citizen science.

Recommendations include:

• Determine which data points you can and cannot compromise on in terms of precision ... clearly state these decisions
• Give ample notice of privacy choices...
• Give volunteers the option to hide certain data points and locations from public view...
• Allow volunteers to delete and modify their data...
• Require only minimum personal data about volunteers...

Another resource to take a look at is PurpleAir's privacy policy:

Metadata. Metadata is unique technical data that is generally associated with User Content. Metadata allows one to make their User Content more searchable when interacting with our Service. An example of metadata would be a hashtag or some form of geotag that would allow others to more readily find your submitted content and/or its given location.
Location Based Information. Use of the PurpleAir services, permits us to collect precise information about the location of your particular device. Location may include but is not limited to background location information between Users. We may use your location information to provide requested location services and to allow tagging of files. You may opt out by changing your geo-location settings consistent with your device protocol.

Other citizen-science examples:

• Spotteron Privacy & Data Safety
• Accounting for Privacy in Citizen Science: Ethical Research in a Context of Openness (Bowser et al., 2017) (pdf)

[spestana]

For some context about spatial resolution and location precision, NOAA's High-Resolution Rapid Refresh (HRRR) model which is used to make those smoke maps you may have seen, is at 3 km spatial resolution.

Another high resolution data product is NASA/ORNL's DayMet which is 1 km spatial resolution.

To get 1 kilometer spatial resolution, that is about 0.01 degrees of precision.

Another advantage to "snapping" sensor locations to a 0.01 degree (or whatever level of precision) grid, is that we won't have to see location drift as the GPS quality changes over time. That would make using archived data easier if a true stationary sensor actually has fixed coordinates rather than showing a bunch of noise (and therefore false movement) due to GPS signal quality.

[keenanjohnson]

Wow @spestana this is really helpful to have numbers to ground this conversation and decision. It definitely seems like a 1 km spatial resolution is adequate for the state-of-the-art science at the moment based on your research. As you've also pointed out, quantizing (snapping) the GPS coordinates to a grid-like that definitely resolves the drift issue as well!

It seems like that level of obfuscation would be a nice way to alleviate any privacy concerns as well.

@spestana do you think it would be adequate to just round the GPS Lat / Long to that 0.01 degrees of precision? I would vote for keeping the altitude at the highest precision we have available :)

If that seems good to you @spestana and @brianstrauch this should be trivial to implement on the sensor itself, so more precise GPS data never hits a database anywhere :).

[keenanjohnson]

@yuzhang0302 fyi

[yuzhang0302]

Adding to this discussion: if we are rounding to the nearest 0.01, should we be taking average of datapoints that are within the same 1km square? For instance, you have 2 sensors located on the same block, should we be displaying multiple sensors on the map or would we want to take the average of these sensors' readings?

We might not need to address this right away, it would be an edge case, hopefully the sensors are more spread out.

[keenanjohnson]

Yeah that is a great point @yuzhang0302 ! Perhaps we should do both, display the average of the sensors on that grid point, but show that the UI is doing that and allow the option to dig into a specific sensor if you'd like? Would you like to document that in an issue as a new feature for us to tackle eventually?

[keenanjohnson]

FYI I've created Issue 41 in the sensor repo to implement this change.

[keenanjohnson]

I've just deployed this change all. You can see here that the coordinates are now rounded to 2 decimal points:

[keenanjohnson]

The distance is about 318 meters away from the actual location of my sensors here. I'm wondering if that's a bit too far? Perhaps 3 decimal places would be sufficient?

That would be about 111 meters of drift vs the 1 km of accuracy right now. What do you all think?