search

e-mission / e-mission-docs

Repository for docs and issues. If you need help, please file an issue here. Public conversations are better for open source projects than private email.
https://e-mission.readthedocs.io/en/latest
BSD 3-Clause "New" or "Revised" License
15 stars 34 forks source link

Have a sandbox environment to play with the app before a full deployment #326

Open shankari opened 5 years ago

shankari commented 5 years ago

From @PatGendre there was a request to have a sandbox server where users can play with the app before committing to a full deployment.

We are currently thinking of this as having two main steps:

  1. the ability to spin up a temporary server that users can interact with
  2. the ability for the phone app to connect to the temporary server and upload their data
shankari commented 5 years ago

Current thoughts on the two requirements:

  1. we can spin up an instance of the server using https://github.com/e-mission/e-mission-docker/#try-in-pwd but:
    1. it will only last for 4 hours
    2. it does not run the pipeline by default
  2. the UI currently does not allow direct server configuration, the mechanism is to configure the server through the connectionConfig.json that is downloaded as part of the UI channel
    1. however, the connection settings module does support setting the values from javascript (https://github.com/e-mission/cordova-connection-settings/blob/master/www/connectionsettings.js#L40)
    2. so theoretically, the "test it out" phone app would allow users to specify the host as they "force sync" for example, and they could specify their temporary server.

It is not clear if this is the flow that would work best, and it would definitely need some significant testing, but I am documenting this for the record. Hopefully @PatGendre + the FabMob team will put in their thoughts as they get feedback from other deployers.

PatGendre commented 5 years ago

Hi @Shankari, thanks for creating the issue, we don't if/when can do this but we consider it a good way of promoting e-mission and facilitate testing and adoption with limited resources to start with. Your 2 points describe well the requirements :

shankari commented 5 years ago

for point 2, it may be better not to use UI channels and find another means for the user to specify the server host. If possible also, the app could have minimum personnalisation such as color, name, logo... but it is not absolutely necessary of course.

You can of course, choose whatever method you want to accomplish this, but the idea behind the UI channels was to have an easy way to customize all this. Basically, you can publish a white label app and then have people select the channel that customizes color, logo, server, auth, etc.

PatGendre commented 4 years ago

@shankari I add here the description of a potential project and your remarks inline.
The need is not exactly the same but the global intention is similar : providing a generic app not linked to a particular site or project or survey and easy to install and test.
The second goal is related to standardising diary trip data and providing data viz and edition tools for this kind of data

With our experience from last year at fabmob, our idea would be to release a public app focused entirely on self data : we've found the private beta app quite cumbersome to manage. The terms of use would state that the app editor would not send the data to any one, nor use it for any purpose. So there should not be many privacy issues, even if there is a server and even if data is not fully encrypted.

The goal would be : -1- to bring a service for the users interested in measuring their personal mobility (so as to limit the server load, the app could be limited for say 2 weeks, and then the data would deleted) and to ask the user how they've found the app and if they intend to do something with data (and what!)

-2- to work towards standardizing diary trips data and developing nice tools (online or libs) for looking at it (or even editing it) : the users wishing to do so would be invited to upload some of their data as public tracks on a server where they could visualise the tracks in various ways, much like you can uploads tracks on openstreetmap.org

For the moment it is only an idea (already dating from a few months), the project would have no commercial goals so it should be quite limited on resources.

I have been running tripaware.damajash.org on a 10-year old laptop in my house along with a bunch of other servers such as nextcloud, email, etc. So any recent server or laptop or cloud equivalent should work for ~ 1000 people.

if you think you can get ~ 1000 people to participate, you should definitely consider partnering with researchers at a university to make it a long-term study and to publish the results

I wonder if it would be worthwhile to just partner directly with openstreetmap. I have long felt that we have complementary goals. We already use them extensively (e.g. for GIS matching) and I am sure that they would like the kind of data we collect. And I know that there is a very extensive OSM community in Europe. They could even be one of the skins – they could have a phone app that prompts people to fill in OSM tags for places that they encounter on their daily routines. Wrt uploading and visualization, instead of having people upload their tracks directly, we could also create synthetic data based on the existing travel patterns, similar to the work in the travel simulation world. Nick R. has done this as part of the UPC thesis.

I’m still working out NREL’s restrictions – apparently there might be issues with publishing apps based on NREL projects. And in general, NREL work is related to specific funded projects. Once we get this to work, I can propose it as part of the next funding cycle. No guarantees that it will be funded though.

shankari commented 4 years ago

@PatGendre @nlehuby @lefterav @laem I am going to spend some time on this in the next couple of weeks to have something to showcase as I start talking to cities about Agile Urban Planning.

Can we brainstorm a bit about what this should actually involve?

High level decisions:

UX questions:

Thoughts?

PatGendre commented 4 years ago

Hi @shankari thanks for the propositions, a few remarks:

we should have a server that the data gets sent to.

Yes that would be great if DFKI can host it. I'd have question: if we get a lot of users (sometimes we can have good surprises;-), what can we do : limit the max number of users? limit the number of days a user can have an account? scale up the server?

we should allow users to choose the UI or to switch between UIs for experimentation

at least we should have a default UI, which existing UI would it be? Would it need to be adapted?

we should have the ability in all UIs, for users to change the server URL so that they can connect to their own server

Definitely it would a nice feature to be able to choose the server, either for the user, or by changing the UI (scanning a new qr code)

which is the base app? the easiest option is to start with emTripLog

Yes, so we wouldn't have to re-apply to the Stores for a new app. I fear there is a risk of being rejected when applying for an app with a modifiable UI if the editor is not a well known academy such as UC Berkeley.
But emtriplog has been registered by UC Berkeley, would they still be Ok to remain the editor? Besides, I think there is a fee for the Ionic Channels, who would pay for it?

which authentication should we use? the problem with both these options is that it is somewhat challenging to allow users to download data to their laptop.

I don't have the expertise to solve this issue, actually I don't even see the issue : the server could send the data by email to the user, why would this not work? maybe because if we have an openid / auth0 solution we don't need the user e-mail ?
Anyway I agree that we can "hold off on that until we have the basic system working".

what consent document should we use? the easiest option is to say that we will not use the data for anything, either research or monetization

Yes I agree, we should really inspire trust that this a purely "self data" app. In that respect, I suggest that we deactivate features using other people's data : in the dashboard, not show the aggregated scores (at least for the basic UI), and on the server, deactivate the heatmap.
On this question, I have found also that several users are interested in a "serverless"/"pipelineless" app, either for users having no data plan, or because the need is quite basic (e.g. only compute the time/distance on bicycle each day like this app : this only a fraction of e-mission's feature but if e-mission could also provide a very basic but battery-efficient open source and uptodate "serverless" mobility tracker SDK, I believe there would be use cases for it.

shankari commented 4 years ago

@PatGendre Thanks for the feedback!

Yes that would be great if DFKI can host it.

@lefterav communicated with me offline and agreed in principle to hosting the server as long as I maintained it. I replied and committed to maintaining the server as long as the committee felt that the sandbox was needed.

I'd have question: if we get a lot of users (sometimes we can have good surprises;-), what can we do : limit the max number of users? limit the number of days a user can have an account? scale up the server?

This is a great question, and one that is responsible for my delay in replying. I have gone back and forth multiple times on this, but right now, I think that the answer is to limit the number of days that a user has data for. The goal of setting up this server is to allow the maximum number of users to experiment with this kind of data collection and the insights it can enable. Really enthusiastic users can download their own data, both raw and analysed.

at least we should have a default UI, which existing UI would it be? Would it need to be adapted?

Why? With emTripLog, the default UI asks you to scan a QR code to select a UI.

Definitely it would a nice feature to be able to choose the server, either for the user, or by changing the UI (scanning a new qr code)

Since we want to allow users to change the UI, we should have the default server be the DFKI server, but also potentially allow users to manually type out the URL of their own server. I may back off on this if it turns out to be too complicated.

But emtriplog has been registered by UC Berkeley, would they still be Ok to remain the editor? Besides, I think there is a fee for the Ionic Channels, who would pay for it?

emTripLog has been registered by me. See the author - it is "K. Shankari". I will also pay for the Ionic Channels for now. I do want to publish a new version of emTripLog with some native code bug fixes, internationalized native code error messages, supporting app store updates etc. I am still working with NREL on how best I can do this as part of my NREL work.

I don't have the expertise to solve this issue, actually I don't even see the issue : the server could send the data by email to the user, why would this not work?

If you are talking about the existing "Download JSON dump", it is not easily automateable via a script. If we want to potentially keep only a limited amount of user data, it would be good to also give users a script that would allow them to download their data automatically to their own computer, and potentially upload it to their own nextcloud, etc. The easiest way to support such a script is by having the user type in a secret that they know.

In that respect, I suggest that we deactivate features using other people's data : in the dashboard, not show the aggregated scores (at least for the basic UI), and on the server, deactivate the heatmap.

I agree that we should deactivate the heatmap. Not sure if we should also deactivate the comparisons with other users - let's see what the rest of the committee says.

On this question, I have found also that several users are interested in a "serverless"/"pipelineless" app, either for users having no data plan, or because the need is quite basic

So by "serverless", do you mean that the analysis pipeline should run without storing the data, or that the analysis pipeline should never run? The manual sync option (https://github.com/e-mission/cordova-server-sync/issues/39) should enable the second mode. But in order to get the benefits of the analysis pipeline, such as section segmentation and mode inference, the analysis pipeline needs to run and it currently runs only on the server.

If people want to port the python-based analysis pipeline to run natively on android and iOS, that would be great, but I won't be able to work on it myself unless it is an Agile Urban Planning priority.

PatGendre commented 4 years ago

@shankari thanks for the answers, great if DFKI can host the server :-)

If you are talking about the existing "Download JSON dump", it is not easily automateable via a script. The easiest way to support such a script is by having the user type in a secret that they know

Ok, got it.

right now, I think that the answer is to limit the number of days that a user has data for.

Ok, that seems reasonable.

Why a default UI? With emTripLog, the default UI asks you to scan a QR code to select a UI.

Ok I meant which UI (i.e. default QR code) could proposed by default to the user to select? It would the NREL flavour of the app? Which features would this UI include?

by "serverless", do you mean that the analysis pipeline should run without storing the data, or that the analysis pipeline should never run?

I meant "never run the analysis pipeline" because it would be much simpler to deploy, and could be good enough for certain basic use cases. But manual sync can be useful too.
I would be nice to have the pipeline ported to the phone, but I don't think there are resources now for such a project!

shankari commented 4 years ago

I will probably get to this only next week because this week all my technical time will go to adding license information to all the files and submitting the project to the Berkeley Technology Transfer Office to get formal approval of the license. That is required to get formal approval from NREL to publish the apps through NREL.

Paperwork, paperwork!

laem commented 4 years ago

Basically, you can publish a white label app and then have people select the channel that customizes color, logo, server, auth, etc.

I'm not sure about this from the user perspective. Having to "configure" the app, even if it's just selecting the server from a menu, would be strange, I've never seen something like this except for developers. The app would have a different name than the city or organisation prompting the user to download it, it looks confusing (but I don't really know how UI channels work :) ).

Why not upload to the store a single and simple UI, that would serve as a demo for those interested in the project that whish to see it running, and a mainstream application if by chance more people start downloading it ?

I've installed EmTripLog from Google Play, and those are my notes as a user that is happy to move again and see some "self data" after being locked for 3 months 😄 :

Today : 🚲9km 🚶‍♂️2km June : 🚄 200km 🚲150km 🚶‍♀️ 30km 🚌 5km and a button that directs me to the list of trips per day (the current calendar view).

does anybody have the design skills to make a good-looking website?

Not sure it's great looking, but I've sketched this website for a similar app that I had in mind : https://kilometre.app. It's a very simple React open source website, and I'd be happy to see it used / forked. Sorry, the content is in french 😅 .

@shankari what do you think about the name, kilometre.app, from the french "kilomètre" ? Is it understandable by a native english speaker, or is "tre" considered a mistake, "ter" being the only understood terminaison ?

authentication

As a user I don't feel the need to have my data kept if I uninstall the app, or if I loose or change my phone : a simple id would suffice. If I loose my records, well I'll start logging them again and build data today, tomorrow, etc :) If people love the app and request an account, it could be added later. Think of whatsapp : this app downloaded billions of times, looses your data by default when you loose access to your phone. You need to setup backups later in the experience, if you want to.

if e-mission could also provide a very basic but battery-efficient open source and uptodate "serverless" mobility tracker SDK, I believe there would be use cases for it.

Yes ! I believe it would be a great way to build trust and accomadate with the fact that some users don't care at all about privacy, while some others would be ready to write a blog post about how wrong it is to collect location data.

The message could be :

If people want to port the python-based analysis pipeline to run natively on android and iOS, that would be great, but I won't be able to work on it myself unless it is an Agile Urban Planning priority.

@shankari what's the best ressource for me to start looking into this ? Is there a summary of all the steps that would not be easy to port (e.g. needs a numpy function hence numpy would need to be pacakaged in the app; needs an overpass request, etc.). Should I explore the entry.py ?

so as to limit the server load, the app could be limited for say 2 weeks, and then the data would deleted

Data, once processed, would only weight a few mb per user, right ? If so, I'd advise not to erase data, at least while the user is still active.

What's the bottleneck to the number of users ? Is it processing batches that could raise a memory error ? Or the overpass API request rate limits ? Isn't the processing "stateless" between users ? What I mean is : if one server got too busy, could we not start a new server and proxy the following app downloads to the newer server ?

lefterav commented 4 years ago

As I told Shankari, hosting in DFKI seems a good perspective. I am currently investigating the final details of opening up the DFKI server and awaiting for some permissions; hopefully they will be positive. The legal aspect concerning data privacy will be the most tricky one. Although we can leave many aspects of the development open, we have to be already pretty clear with what is going to happen with the data. Because as Shankari said, for the server to run, we need a privacy policy and a user agreement approved by our legal department and I would (barely) happy to do that once, definitely not more than that.

I like the idea of various interfaces. This could be done by offering pre-compiled app packages (e.g. apk) for each interface. Of course, as DFKI we would be very happy if we can promote our fork/interface which is focusing on CO2 emissions. demo here the alpha version is uglier :-)

PatGendre commented 4 years ago

Hi @lefterav , I hope the privacy policy and User Agreement can be approved, that would super if DFKI can host the server:-)

Thanks for the link to the mockup, I see that you implemented a way to delete a trip or segment and edit a segment, I didn't know, this is a great feature! would it be easy to add to another app ? How does it impact the server code? (e.g. how does this feature interact with the pipeline? Can you only delete/edit processed trips? are the modified/deleted segments tagged as such?

lefterav commented 4 years ago

The mockup includes some wanted features that are not in our alpha implementation. Maybe it is not the right thread to discuss this, but as far as I remember, in the alpha version the interface includes the option to edit the detected transportation mode. Nevertheless our developers had issues with synchronizing that with the server and it may have been left unfinished. Editing the kilometers of a segment was not possible in the alpha version and I am not sure about deleting segments or trips.

PatGendre commented 4 years ago

Ok thanks for the explanations. If it is implemented later on, it'll better indeed to discuss it in another thread.

laem commented 4 years ago

@lefterav very interesting mockup ! What about using a bar chart instead of the pie chart ? Just a suggestion, I'm not sure which is better :) image Can we install the alpha on an android phone yet ?

shankari commented 4 years ago

@laem Thanks so much for the detailed feedback. Some responses inline.

I'm not sure about this from the user perspective. Having to "configure" the app, even if it's just selecting the server from a menu, would be strange, I've never seen something like this except for developers. The app would have a different name than the city or organisation prompting the user to download it, it looks confusing (but I don't really know how UI channels work :) ).

Wait, I am confused. Is the plan that cities or organizations would prompt users to download the app, or that users would organically decide to download the app for self tracking? If a city wants to users download the app, then my expectation is that they will build their own app which sends data to their own server.

Also, themes and skins are super popular, at least in the OSS world :)

Why not upload to the store a single and simple UI, that would serve as a demo for those interested in the project that whish to see it running, and a mainstream application if by chance more people start downloading it ?

Because then we would need to debate what that single and simple UI should be. Should it look like the current e-mission UI? Should it look like the DFKI UI? Should it look like the TripAware UI? IMHO, the strength and power of e-mission is that it is configurable and allows deployers to customize it to their needs. So any demo for those interested in the project should have a way of showcasing the ability to customize the core platform.

The e-mission (not emTripLog) app is an example of a single UI app, and every time people see it, the first thing they tell me is how they want to change it 😄 Of course, you (or FabMob) can publish a single UI app based on e-mission to the stores going forward.

I've installed EmTripLog from Google Play, and those are my notes as a user that is happy to move again and see some "self data" after being locked for 3 months 😄 :

You have installed emTripLog with one particular skin (the emotion skin)

* I'm only interested, for now, by the first tab; If I want to compare my scores to friends, well the mobile screen capture + send to friend via Whatsapp has been proven and tested.
* I'd like a very straightforward landing "dashboard" that tells me how much I've travelled, something like that :

It seems like you have specific ideas for a different skin. That's great! Build it and submit it to the gallery. As I said earlier, you can also publish a simple app based on it to the stores if you are willing to take on the burden of keeping it maintained. You may find this other channel to be closer to what you want. https://e-mission.eecs.berkeley.edu/#/client_setup?new_client=martanetworksp18

Just click on it to switch the UI to one that you might like better :)

* the app doesn't let me correct some wrong classifications (e.g. plane because I took a very deep subway and the GPS jumped far away for a short time), which is quite frustrating. I know that the FabMob beta version did let me correct trips

This was a choice that the TripAware skin developers made because they didn't want people to cheat in the game by reclassifying their trips to look more sustainable. The martanetworksp18 channel above does have that functionality. Note that the corrections will currently show up in the diary but not the dashboard (https://github.com/e-mission/e-mission-docs/issues/476). If you are familiar with python, making the relevant changes would be a very impactful contribution.

* the server requests are quite slow, and the fact that I can't look at the trips in real-time or close is quite a problem for a self data app : it's 11am, I'm having a cofee, I open the app and can't see the trip I did this morning, it looks like it's not been processed yet. If it is a hard limitation, one way to mitigate the problem would be to get notifications like "Bravo : your daily trip journal is ready".

Server requests are slow because the tripaware server is running on a 10-year old laptop in my house. Once we move to DFKI, it should be faster. And the new skin (above) supports displaying unprocessed trips as well.

@shankari what's the best ressource for me to start looking into this ? Is there a summary of all the steps that would not be easy to port (e.g. needs a numpy function hence numpy would need to be pacakaged in the app; needs an overpass request, etc.). Should I explore the entry.py ?

The current pipeline is at intake.py. I would strongly encourage you to read my thesis for a description of the pipeline steps and a high level idea of their implementation.

if one server got too busy, could we not start a new server and proxy the following app downloads to the newer server ?

We could definitely start a new server and load balance between the two servers. But I haven't yet seen anybody step up to host such a server when needed. Even though DFKI plans to host this server, they have not yet finished provisoning it :)

shankari commented 4 years ago

@lefterav very interesting mockup ! What about using a bar chart instead of the pie chart ? Just a suggestion, I'm not sure which is better :)

@laem Aha! This is why it is important to, at least right now, support multiple UIs. Because everybody who looks at any UI can immediately think of a way to change it, and we don't have any data on which is better.

And there might not be one "better" - @laem may prefer a bar graph and @PatGendre may prefer the polar bear UI.

Which is why I suggest for now that we offer a gallery of potential skins for users to choose between.

What would be really cool would be to also capture usage information (e.g. number of launches, time interacting with the app, etc). Note that those are not personally identifying. We could publish a dashboard of the usage information so we know objectively which is more popular and deployers who do want to build a single UI app know where to start :)

shankari commented 4 years ago

@PatGendre

How does it impact the server code? (e.g. how does this feature interact with the pipeline? Can you only delete/edit processed trips? are the modified/deleted segments tagged as such?

I don't think this has been implemented, but I would recommend using the approach in https://github.com/e-mission/e-mission-docs/issues/476. IMHO, you don't want to mix analysed and input data for all the reasons outlined in that bug.

shankari commented 4 years ago

@laem

Not sure it's great looking, but I've sketched this website for a similar app that I had in mind : https://kilometre.app. It's a very simple React open source website, and I'd be happy to see it used / forked. Sorry, the content is in french 😅 .

There have been requests for the plugins to support React Native/Flutter in addition to cordova (https://github.com/e-mission/e-mission-docs/issues/499). I have not had time to build this yet. But I have also been blocked by the lack of UI support for the other platforms. I don't have the resources to build and maintain a React Native UI and a Flutter UI, and my UI design skills suck. But if you wanted to port the existing Angular UI to React Native, I would be open to adding a RN interface to the plugins when I next have some spare time.

@shankari what do you think about the name, kilometre.app, from the french "kilomètre" ? Is it understandable by a native english speaker, or is "tre" considered a mistake, "ter" being the only understood terminaison ?

British English uses kilometre, US English uses kilometer. Since I was raised in India (British English) and have lived in the US for > 20 years now (US English), both of them look right to me 👍 But if you can avoid a word with er/re ending it would be better since it will work universally.

shankari commented 4 years ago

@lefterav

for the server to run, we need a privacy policy and a user agreement approved by our legal department and I would (barely) happy to do that once, definitely not more than that.

Given that we don't want to modify the privacy policy and user agreement multiple times, we should keep it simple. I propose two option:

🎉 We will never use the data for anything. We will not share it with anybody, and we will not even attempt to analyse it ourselves.

This is the most privacy preserving, but I wonder if it is too restrictive. What if we could use the data to help in a potential second wave of the pandemic? Should we just sit on the data and not use it for public good? On the other hand, users can download their data and upload it if it is needed for public good. Thoughts?

👀 We will use the data only for aggregated research.

We will not share it with anybody other than academic collaborators who sign an agreement to not republish the data. Collaborators will have to demonstrate a clear project for which they want the data. Data will be shared primarily to improve app functioning - e.g. for better mode detection.

This is more on the utility side of the tradeoff. But it gives us more flexibility if there is an urgent need to use the data in a crisis situation.

We will not monetize the data or sell it to third party brokers in either case.

@PatGendre @laem Please vote 🎉 or 👀 using the reactions for the comment ☝️ I am torn between the simplicity of 🎉 and the ability to respond to crises inherent in 👀

PatGendre commented 4 years ago

@shankari I would vote for the simplicity.
In the end the user can then decide to send the data to whomever he/she likes, this can be decoupled from the individual data collection.
But I would send the user a questionnaire before they leave and ask them if they think the data is useful and would agree to send it e.g. the city, to researcher, etc.

As for aggregation, the terms of use should clearly state how the data is aggregated. For instance, sending the daily total of kilometers by mode (as in mael kilometre app) could be ok, but not the heatmap.

And I have a question : as emtriplog is designed to have a configurable UI, the user consentment is done after installing the UI, right? So we could have the "default" UI / QrCode with purely self data terms of use, and another UI with other terms, authorizing aggregation (and possibly routing to another server) ?

shankari commented 4 years ago

But I would send the user a questionnaire before they leave and ask them if they think the data is useful and would agree to send it e.g. the city, to researcher, etc.

Unfortunately, we don't know when the user leaves. Other researchers have asked whether we can detect when the user uninstalls the app, and we cannot. https://stackoverflow.com/questions/2874412/get-application-uninstall-event-in-android and any loopholes to this are caught and fixed https://stackoverflow.com/questions/19475765/listen-to-own-application-uninstall-event-on-android

If we have the user email, we can send them an email if they haven't uploaded data for a while, but with the token based approach that we are discussing, we can't. Once the user uninstalls the app, the data is effectively unusable.

As for aggregation, the terms of use should clearly state how the data is aggregated. For instance, sending the daily total of kilometers by mode (as in mael kilometre app) could be ok, but not the heatmap.

First, I agree that we should ditch the heatmap for this. wrt metrics, there are at least two aggregation scopes:

  1. viewing only the user's own metrics
  2. viewing user's metrics + aggregated metrics from other users
  3. publishing aggregated metrics without needing a login

I can see the argument against (3), but I don't see the argument for prohibiting (2). Also, many of the current UIs (master, DFKI, TripAware) support (2) and I don't have the time to go through and modify them to remove that functionality.

And I have a question : as emtriplog is designed to have a configurable UI, the user consentment is done after installing the UI, right? So we could have the "default" UI / QrCode with purely self data terms of use, and another UI with other terms, authorizing aggregation (and possibly routing to another server) ?

That's a great idea! We could give people a choice between sharing and not sharing their data (e.g. between options 🎉 and 👀) above.

Let's see what @lefterav thinks about asking DFKI legal for two different consent documents :)

PatGendre commented 4 years ago

Thanks for your reply.

Unfortunately, we don't know when the user leaves.

We discussed earlier the idea of "limiting the number of days that a user has data for", so in practice the app would work only for a certain number of days (like a free demo version of a commercial software ;-) Or how do you think this limitation will So in principle we know when the user leaves : after say 15 days, then the user would have to download the data, and create a new account if he/she wants to use the app again, and we could send him/her a questionnaire before he/she leaves?

I can see the argument against (3), but I don't see the argument for prohibiting (2).

Ok, I don't see the argument either. But there may be a legal reason.

shankari commented 4 years ago

We discussed earlier the idea of "limiting the number of days that a user has data for", so in practice the app would work only for a certain number of days (like a free demo version of a commercial software ;-) Or how do you think this limitation will

I was thinking of just deleting any data that is more than 15 days old. So the users would continue to collect data, they would be able to view their new data in real time, but their old data is gone unless they have set up the script to auto-download it.

PatGendre commented 4 years ago

deleting any data that is more than 15 days old.

Ok, this a simple and as such a good way of doing it :-) But you may end up after a year or two after with a very large number of accounts if there is no policy for cleaning up the database say every month and ask dormant users to close their accounts. And wrt to asking the users what they think of the app and what they would do with the data, we can send a survey say after 2 weeks, irrespective of their usage.

shankari commented 4 years ago

But you may end up after a year or two after with a very large number of accounts

Not really. If there is no data left for a particular user, we can just delete their "account", which is an entry in the profile DB as well.

ask dormant users to close their accounts.

I want to reiterate that with the current proposal of using a user-specified string as the auth, we have no way of contacting users who don't have the app installed. We will not have their email address or any other contact information.

And wrt to asking the users what they think of the app and what they would do with the data, we can send a survey say after 2 weeks, irrespective of their usage.

This would have to be an in-app survey because again, we won't have their email address.

If we do want to get their email address, maybe we need to use the FabMob OpenID auth server instead.

PatGendre commented 4 years ago

@shankari thanks for the answers you're right, setting up an proper auth like openid may be too complicated and the user specified string should be ok.

shankari commented 4 years ago

Maybe we can revisit this after we set it up and experiment a bit within ourselves.

lefterav commented 4 years ago

Let's see what @lefterav thinks about asking DFKI legal for two different consent documents :)

I can ask DFKI legal for anything we want, although I don't see a reason to not ask for the more permissive of these two. I am already a bit lost how to start concerning GDPR and privacy statements. That's totally not my expertise. If anybody can give me a hint, please do so.

Edit: I am looking again at Shankari's intro consent text and it seems pretty good.

I guess we have to

shankari commented 4 years ago

@lefterav I believe that the e-mission platform currently supports GDPR as long as we commit to delete data manually on request, which I can commit to do. It has been deployed in France, so @ericafenyo could tell you concretely if there was anything else

wrt the three points:

I think that's it!

shankari commented 4 years ago

@lefterav right now, it seems fine to list me with my NREL affiliation. Do you need any other information before you ask for permission?

shankari commented 3 years ago

With the energy iCorps interviews, and the recent publication of the NREL news article on the eBike project, it looks like some people have searched for the e-mission app in the stores and installed it. Unfortunately, the e-mission app has not been updated since 2018.

AWS has also notified me that there is degradation of the underlying hardware for the currently running instances, and they will be shut down on the 11th. I can restart the server, but then EECS Berkeley needs to reconfigure the DNS for the server to point to the new IP, and I am not sure if they are comfortable doing so.

Due to the acquisition by NREL, and the focus on customizable and extensible user interfaces, we are unlikely to have a single app going forward; instead we are likely to go with an approach similar to emTripLog.

So I decided to make the following changes this weekend:

I've attached the logs from the push. migrate_push.log.gz migrate_push_copypaste.log.gz

shankari commented 3 years ago

It looks like we had two iOS phones and 213 android phones

{'ios': {'multicast_ids': [1858071715375154513], 'success': 2, 'failure': 0, 'canonical_ids': 0, 'results': [{'message_id': '1620605045477335'}, {'message_id': '1620605045449490'}], 'topic_message_id': None},
'android': {'multicast_ids': [8405604262067973781], 'success': 213, 'failure': 596, 'canonical_ids': 0, 'results':

At least some of the failures were due to {'error': 'MismatchSenderId'} so they are probably because of emission instead of embase. We can retry with the other appid to see if we get a different result.

shankari commented 3 years ago

Also backed up all the data as of now and stored on kundavai's backup.

$ ls -alh /tmp/backup_may_9_2021.zip
-rw-r--r--  1 shankari  wheel   6.0G May  9 16:42 /tmp/backup_may_9_2021.zip
shankari commented 3 years ago

Changed the appid and retried.

migrate_push_copypaste_emission.log.gz

DEBUG:root:firebase push result for ios: success 2 failure 0 results [{'message_id': '1620611799094433'}, {'message_id': '1620611799092346'}]
DEBUG:root:firebase push result for android: success 185 failure 624 results
shankari commented 3 years ago

I got the notification both times on android, so the difference is primarily for iOS. And the difference between the 213 and the 185 probably reflects the uninstalls after getting the first notification, from people who probably didn't realize that they had it installed 😄

shankari commented 3 years ago

The reason for the mismatch between iOS and android is that we are not able to convert the tokens for iOS. Since the FCM code is pretty stable and seems to work fine for CanBikeCO, I assume this is a problem caused by trying to map too many tokens at a time.

DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): iid.googleapis.com:443
DEBUG:urllib3.connectionpool:https://iid.googleapis.com:443 "POST /iid/v1:batchImport HTTP/1.1" 400 None
DEBUG:root:Response = <Response [400]>

Aha! From https://developers.google.com/instance-id/reference/server#manage_relationship_maps_for_multiple_app_instances

we need "Maximum 100 tokens per request."

shankari commented 3 years ago

Fixed (will link PR here). Now the iOS result is

DEBUG:root:firebase push result for ios: success 255 failure 6 results

migrate_push_ios_only.log.gz

shankari commented 3 years ago

So overall, we had 213 (android) + 255 (iOS) = 468 total apps still installed. Not too shabby for a research project with no recruiting or marketing budget. Maybe we should have figured out a way to migrate them over transparently instead of making them reinstall.

But it was never going to work anyway, since the app itself would need to be published by NREL. Could I have transferred the app over? Maybe I should check how many installs it still has and do it anyway...