-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Comments
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 :\ |
After validating today, latest comps are in Zeplin: https://zpl.io/brMdWo3 |
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 addressesThese email addresses are hidden |
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. |
@afonari the toggle for analytics is under the Security & Privacy tab, and not going anywhere I don't believe. |
|
This comment has been minimized.
This comment has been minimized.
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 |
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. |
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. |
Re-adding blocked until we reach a final resolution on how to proceed here. |
@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. |
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. |
Will these settings be configurable with
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 |
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. |
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. |
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.)
The text was updated successfully, but these errors were encountered: