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?Edit: Let's take a longer time than 2 weeks (better: 1-2 months).

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.

[zven]

Another topic regarding the terms of service, that @mariopesch has brought up: How about a token based system for accepting the TOS?

If we send out an email to inform our registered users about the new TOS, we would also include an individual link. Clicking on the link, the user would be prestented with the terms of service (in the version that needs to be accepted), can read it through and in the end of the document there is an Accpet button. Since the user token / link is bound to a user account internally, we can then store the acceptance for that user account. No login needed. :-)

@scheidtdav We could recycle some existing mechanisms, right? 🤔

[scheidtdav]

Yes, I think we could repuporse our email confirmation mechanism a little.
It already generates a token that can be considered a one time password.
We would need to extract that from the table it currently lives in (its either user or profile, not sure) and move it to its "service" that e.g. email confirmation and TOS accepting can then use to validate the token.
We should probably specify a type for those OTPs to link it to certain actions and have TTLs on it, to ensure it doesn't become a security issue.

Leaves the question how long a token for TOS acceptance should be valid. A week or two maybe?

[zven]

I'd say we take the same time frame that our users have to accept the TOS via the regular UI. For example, two, four, or six weeks.

[zven]

First bunch of features implemented here: #747

• accept TOS upon registration
• accept TOS when already registered via popup
• block certain API calls when current TOS are not accepted after certain date / time (configurable which routes are blocked)
• accept TOS via token that is send around via email

Open:

• TOS not accepted after deadline: delete user account and orphanize devices
• handle case when TOS are about to be updated and a user signs up during that transition time (Which TOS are presented and need to be accepted?)