an opinion on privatekit?

[PatGendre]

Hi @shankari
I've had a quick look at MIT's privatekit project, it may have been developed for contact tracing but it also includes location tracing, so do you think it's worth investigating? The app may not be opensource but the react native sdk is : https://github.com/PrivateKit

I was wondering if for instance it would make sense and would be easy to send locations from this privatekit app to an e-mission server so as to derive trip diary from it?

[shankari]

The last time I looked at PrivateKit, they were using the closed source transistorsoft plugin for location tracking. I spoke to them about switching to e-mission instead, and they were open to it if I built a ReactNative interface. I have not done so, so I did not follow up with them after that ....

Their location service usage example is:

// For LocationService usage
// Check and obtain the permissions first -
let locationPermission = LocationService.checkLocationPermission()
if (locationPermission == false) {
  LocationService.requestLocation();
}
LocationService.start();

So they are essentially reading the location continuously, no sophisticated, energy-aware tracking or anything. I believe they were reading data every 5 minutes, at least at the start.

I can reach out to them again and see if they want to use e-mission, but I am not sure they need the more sophisticated tracking if they are doing very coarse sampling.

[shankari]

I also see that their contributions have dropped off significantly in the past few days. Not sure if this is just because they are moving to a more mature model now, or whether the Apple/Google SDK announcements have shifted momentum away from them.

Note that around 15 days ago, Apple/Google announced that apps that use the BLE-based SDK will not be allowed to track location any more.
https://www.reuters.com/article/us-health-coronavirus-usa-apps-idUSKBN22G28W

[PatGendre]

Thanks a lot for the insight, so their focus is definitely not on location tracking.
What interested me a priori when reading the project homepage is "Private Kit’s trail generator logs your device’s location once every five minutes and stores 28 days of data in under 100KB of space – less space than a single picture. But what is truly exciting about Private Kit is its privacy protection. Data never leaves your device without your consent."
Which seems very in line with the goals of most cities I've talked to, when you to pay attention to the 5' too low sampling rate and to the absence of any trip segmentation and mode detection features.

Maybe they could "pivot" the privatekit project to a more mobility oriented goal is the contact tracing goal is not so relevant?

[shankari]

Which seems very in line with the goals of most cities I've talked to, when you to pay attention to the 5' too low sampling rate and to the absence of any trip segmentation and mode detection features.

Not sure what you mean by "you to pay attention". Can you articulate the city goals in a bit more detail? I'm not sure I have encountered them before.

Just to clarify: sensing location every 5 minutes and not dealing with automatic sync is the cheap and easy option that optimizes for getting an app out in a week.

• The app developer does not have to deal with complex local processing to start and stop sensing. It literally needs to make one simple call to the location sensing API. This is ~ 1 dev week.
• It does not need to build a robust batch syncing mechanism that will retry without losing data.

But there are real implications to those choices.

• With 5 minute sensing, the app can capture only limited information about travel - it can really only be used for place detection.
• It is going to be very challenging, without Apple/Google level engineering effort, to perform any sort of processing - segmentation, outlier detection, mode inference - on the phone.
• Similarly, the early location based systems did not support automatic upload. But what they found was that people would forget to upload their data. It is already a challenge to motivate people to collect data, it is likely to be even harder to motivate them to also remember to upload it.

Having said that, e-mission is a platform, not a system. If a deployer wants to support 5 minute sensing and manual uploads, they should be willing to do so.

• emission already supports 5 minute sensing through configuring the data collection plugin
• if you sense at that frequency, I would be very surprised if the data storage would be significant. Even at 30 secs, the e-mission app storage is fairly minimal.
• it already supports a lame-ish option to disable automatic sync. once I finish resolving Expand the config to support "manual only" sync cordova-server-sync#39, it will fully support manual sync
• if the motivation behind this is privacy, then @njriasan is finishing up his Masters' thesis on UPC, which will allow private, efficient and extensible processing of the collected data

Finally, we discussed exploring standardization of travel diary data. If PrivateKit does want to pivot to mobility, maybe they can participate in the common standard creation. Standards are only relevant if there are multiple interoperable implementations. If they want to spend the effort to create and maintain an mobility tracking app, more power to them!

[shankari]

Not sure what you mean by "you to pay attention". Can you articulate the city goals in a bit more detail? I'm not sure I have encountered them before.

@PatGendre any updates on this?

[PatGendre]

Not sure what you mean by "you to pay attention". Can you articulate the city goals in a bit more detail? I'm not sure I have encountered them before.

@shankari Hi, sorry I wrote the contrary of what I meant :-((
I meant "when you DO NOT pay attention". I've discussed with people from a few cities, and either they were mobility professionals looking for a survey tool (like Itinerum), either they were not so knowledgeable of tracking applications and were looking for a self data tools for organising participatory workshops with communities and making them aware of their actual mobility. I was thinking of the latter, they do not want to have any privacy issues to deal with and they have no precise idea of the tracking needs, so they are seduced by privatekit like pitch and do not pay attention the large 5 minute sampling time, or have no idea why a server would be needed for providing relevant mobility data.

If PrivateKit does want to pivot to mobility, maybe they can participate in the common standard creation.

Yes indeed I believe a widely used diary trip standard is an important goal. It could be a good idea to ask the privatekit team if they would interested in going in that direction.

[shankari]

looking for a survey tool (like Itinerum)

e-mission can function as a survey tool, although that is not all it can do 😄

What are the specific features of a survey tool that they are looking for?
@asiripanich has an R dashboard written using shiny (#536 (comment)), and there are multiple tools for survey authoring:

• you have lime survey,
• UNSW has a process for authoring surveys using enketotoolbox and embedding into the app

[PatGendre]

Yes, e-mission can also function as a Survey tool, I was giving Itinerum as another open source example ;-)

I dont know much about smartphone based mobility survey apps but this domain seems to be getting more mature, with several "products" on the "market" so feature lists can be found in public RFP documents. My impression is that cities first and foremost need support for the tool, they don't buy a product, they buy a survey (data and possibly analysis). So the clients for a mobility survey tool are not directly the cities, but transportation/mobility engineering firms. Currently I don't know exactly, I suppose part of the survey Tools are developed and maitained inhouse by the engineering companies, and part are true software products used by third parties; for the latter, except software support and maintenance, an important feature is certainly the backoffice for managing the survey, which Itinerum has (AFAIK) but is lacking from e-mission.