Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Present an aggregated terms of service dialogue at registration if possible #10167

Closed
lampholder opened this issue Jun 25, 2019 · 19 comments
Closed

Comments

@lampholder
Copy link
Member

lampholder commented Jun 25, 2019

If the owners of the homeserver, the identity server, the integration manager and the analytics platform are legally able to provide a unified terms of service then Riot should let them.

(@jryans: Removed older design from @lampholder to avoid confusion.)

@lampholder
Copy link
Member Author

If it is not possible to provide a unified terms and conditions, we need to think about what we offer instead. This might vary from service to service:

IS is needed for registration if you want to publish your public association between your email/msisdn and your mxid. So we should probably direct users to provide their acceptance of the IS terms of service as part of registration.

IM is not needed for registration, so we might consider leaving this until the user first tries to interact with or use a widget (or a sticker pack). There are a couple of... surprising UX moments to avoid here - we don't want to punch new users in the face with too many t's and c's hoops to hop, but likewise nobody expects a sticker picker to prompt for t's and c's before you can send a sticker :\

@nadonomy
Copy link
Contributor

nadonomy commented Jul 5, 2019

After validating today, latest comps are in Zeplin: https://zpl.io/brMdWo3

@ara4n
Copy link
Member

ara4n commented Jul 8, 2019

Uploading a snapshot here for the visibility of Joe Public.
Privacy

@jryans jryans self-assigned this Jul 10, 2019
@jryans jryans removed their assignment Jul 10, 2019
@aaronraimist
Copy link
Collaborator

Thanks for the screenshot. It would be nice to be able to disconnect the integrations manager.

Also the email discovery section is a bit confusing to me. I can't tell if [email protected] is currently being shared or if it is hidden and I need to click share to make it public. Instead of a button that says what you want to do, maybe it would make more sense it to say the current status. Or list them in two groups

People can find you using these addresses

[email protected]

These email addresses are hidden

[email protected]
[email protected]

@afonari
Copy link

afonari commented Jul 15, 2019

Hopefully this will get fixed soon. From the screenshot, user cannot opt-out from analytics from settings, only at sign up? This should be fixed.

@turt2live
Copy link
Member

@afonari the toggle for analytics is under the Security & Privacy tab, and not going anywhere I don't believe.

@afonari
Copy link

afonari commented Jul 15, 2019

@afonari the toggle for analytics is under the Security & Privacy tab, and not going anywhere I don't believe.

This is correct, thanks.
Screen Shot 2019-07-15 at 11 22 32 AM

@afonari

This comment has been minimized.

@jryans
Copy link
Collaborator

jryans commented Jul 26, 2019

We've realised it's currently unclear how to implement the design for this, as it wants to say something like "This service is provided to you by provider", but the name of the provider is not programmatically available via an API. Either we need to extend the MSCs to add such a thing or update the design without this.

@ara4n
Copy link
Member

ara4n commented Aug 5, 2019

It feels like a no-brainer to have the API say what legal entity is providing the service for UI purposes. Can we just add it to the API & the MSCs?

Shipping the privacy project is not blocked on waiting for the MSCs to pass FCP ftr, assuming there's generally positive review on the MSCs.

@ara4n ara4n removed the X-Blocked label Aug 5, 2019
@jryans
Copy link
Collaborator

jryans commented Aug 5, 2019

Current design:

2019-08-05 at 17 23

@jryans
Copy link
Collaborator

jryans commented Aug 5, 2019

Current thinking is to tweak the above design so that it can work for both matrix.org and all other deployments as well by changing the text "This service is provided to you by ..." near the top to say something like "This service is provided to you by the homeserver administrator" which is generic and doesn't require knowing the legal entity name for the UI.

@jryans
Copy link
Collaborator

jryans commented Aug 5, 2019

Re-adding blocked until we reach a final resolution on how to proceed here.

@neilisfragile
Copy link
Member

@jryans #10167 (comment) is my understanding of what needs doing, is there anything further you would need to mark this unblocked?

@jryans
Copy link
Collaborator

jryans commented Aug 9, 2019

@jryans #10167 (comment) is my understanding of what needs doing, is there anything further you would need to mark this unblocked?

I hadn't seen any guidance from @ara4n or others on whether the text change described there was okay or not. It sounds like you're saying it is, so I'll remove the label.

@jryans
Copy link
Collaborator

jryans commented Aug 9, 2019

Marking this as phase 2, as we've discussed doing it after all other phase 1 items are done, so phase 2 seems like a good way to track that intent.

@jryans jryans added phase:3 and removed phase:2 labels Sep 18, 2019
@jonaharagon
Copy link

Will these settings be configurable with .well-known on the HS? I should be able to display my own ToS and privacy statement on any Riot clients and not just ones I control.

We've realised it's currently unclear how to implement the design for this, as it wants to say something like "This service is provided to you by provider", but the name of the provider is not programmatically available via an API.

This is the kind of stuff that could be moved to .well-known as well. I don't know what the technical requirements would be, I feel like a lot of configuration could be moved there to provide a more consistent experience for users based on the homeserver they choose rather than the client they choose. Even client configuration options like enable_presence_by_hs_url could probably be homeserver defined. Maybe this should be a separate issue...

@ara4n
Copy link
Member

ara4n commented Oct 10, 2019

hang on - we already support displaying our own ToS & privacy policies for the homeserver to all clients, and have done for over a year. We also display configurable policies for the identity manager & integration manager, if used, too. These policies are all configurable by the admins of the respective services, and get enforced upon all clients.

AIUI, this bug is purely about whether we also want to display the full range of policies at the initial GDPR click-through when you register on the server, rather than popping up the policies on demand as you use the identity service & integration manager. Personally, I think the current approach of prompting for the additional policies on demand works better than having them all up front - the users are more likely to read them, and be less scared by a flight-console of policy documents to read.

@jryans
Copy link
Collaborator

jryans commented Oct 29, 2019

Since we've agreed that we actually prefer the terms prompts appearing on use over this "all at once" style, I'll go ahead and close this issue as something we don't intend to implement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants