new terms of service

[zven]

With the new version of the openSenseMap, we want to introduce new terms of service (e.g. including a more explicit mentioning of the applied license for the sensor data). We should handle this change in some way on UI side (in addition to just sending out an information email to our users).

Some first ideas:

• We should explictly mention and link the terms of service (and privacy policy) for new users upon registration.

Open questions:

• How do we handle our existing users?
• Shall they simply be informed upon login via a info box / popup?
• Shall we give them the option to delete their account if they are not happy with the new terms of service? Is their sensor data then also deleted? If that is the case, inform them that their sensordata will be retained X years in the archive.
• Should we, by default, de-activate all the accounts that have not yet agreed to the terms of service? What would that imply? Would their data / senseboxes be "hidden" somehow?

[scheidtdav]

Regarding your idea:
Do you mean in the email users will receiver or somewhere during signup?
I think we should definitely link both privacy policy and terms on the signup page and make people agree to it (e.g. using a checkbox).
The email would just be a plus.

Additionally I think there should be a permanent link to both documents from the landing page.

Open questions:
If we do nothing, the existing license and privacy policy apply (so there is no need to deactivate anyones account). I think if we have changes, we should prompt users.
Via mail should probably also be possible, because a lot of users might not even use the map but only use the api.

I don't think you will need a "if you don't want that, delete your account" button. You can always agree and delete afterwards right away.
Data is retained after a user deletes their account.

[zven]

Regarding the email: As soon as we roll out the new openSenseMap, we want to send out an email to our users to inform them that the whole infrastructure has changed. I would mention the new terms of service in that email.

Signup process: I agree that new users would need to agree to the terms of service during the signup process and that we should link to the terms of service and privacy policy pages there as well.

[scheidtdav]

I have created #747, please check if that is sufficient?

Another discussion point: API usage without agreement? Should this be allowed? Are we thinking about a grace period?
Would that be an extension to #747?

[zven]

After trying to describe the "new / updated terms of service" case over here: #780
we might want to simplify the whole process a bit. To not clutter the ticket too much, I will write down a slimmed down version here, that we can discuss. I am trying to describe our whole workflow.

Some considerations:

• simplify the orphaned state.
• When should we block API calls from devices?
• Simplify the additional grace period for accepting the tos?

Here we go!

Upon releasing the new OSEM:
Once we clearly know when we are going to release the new OSEM-version, we are informing our current OSEM users via email about the upcoming new version of OSEM, including the release date (X).
Once we have successfully migrated, another email is send out with the information that the new OSEM version is now usable (Hooooray! 🎉 ) and that we have new TOS that must be accepted until X + transition period (14 days?). -> ** 2 weeks transition period? **

During those two weeks, the users have time to log in and accept the new terms of service. Usability is not restricted in any way. Upon logging in, users are presented with a popup in case they have not yet accepted the new terms of service (including a link to the TOS page). The popup also contains the information their accounts will be deleted at a certain date. After that date, we will delete their accounts and unlink their devices from their account. Old (but active) devices will still be able to send data to OSEM (orphaned).
We also inform the user that they have the option to delete their account (including their linked devices) from the settings menu.

When the transition period is over and the user has not accepted the new TOS, we assign the orphaned devices to orphaned@opensensemap.org and delete the user account.

TL;DR

• orphaned = assign to orphaned@opensensemap.org user account
• no blocking of API calls during initial transition period
• no extra grace period

[zven]

We could consider blocking API calls for some time for those users who have not yet accepted the new TOS in order to disturb them: If their devices are suddenly not working anymore, they might check their emails or log into OSEM? 🤔

[scheidtdav]

This comes with the problem that after the account is deleted it should work again. Which is very weird. I'd say we skip this for now.

[zven]

For the case when we introduce new terms of service after introducing the new OSEM, we could consider a similar approach:

When the TOS are about to change, we inform users some weeks beforehand via email about new TOS from date Y. When the then log in, they can accept the new TOS that will be valid with date Y or simply close the window. Whenever the log in anew, the window will be presented again (similar window as the one above). If the new TOS come into effect, we orphanize their boxes and delete their accounts.

Caveat:

• We would need to have the current TOS and the new TOS on OSEM.
• What happens if someone signs up during such a period: Do they have to agree to the current (soon outdated) TOS and the new TOS or simply to the new TOS? 🤔

[scheidtdav]

Nice edge case. Easiest but probably weird UX is to have people accept the TOS that are currently in effect and then make them accept the new ones on first login.
Probably thats also kind of legally required, because you shouldn't be using the platform without having agreed and also not with having agreed TOS that only take effect in two weeks, right?

[jona159]

But there were no formally defined ToS on the OSEM or am i missing them somewhere? Since the users never actually agreed to some ToS i guess the new ToS should just start to take effect right away?

[scheidtdav]

No you got that right. With the new version, TOS should take effect immediately. My point from above was more for some future changes to TOS. Maybe not something we should worry about now.

[zven]

Indeed, I was referring to the future case™️ here and thought we might want to discuss the implications already now since they might have an impact on our first implementation.