Element-web: Present an aggregated terms of service dialogue at registration if possible

[lampholder]

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]

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]

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

[ara4n]

Uploading a snapshot here for the visibility of Joe Public.

[aaronraimist]

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]

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]

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

[afonari]

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

This is correct, thanks.

[afonari]

Here is a config.json that should disable IS, matrix box and analytics (piwik: False part):

{
    "default_server_config": {
        "m.homeserver": {
            "base_url": "https://matrix.org",
            "server_name": "matrix.org"
        },
        "m.identity_server": {
            "base_url": "https://localhost"
        }
    },
    "disable_identity_server": true,
    "disable_custom_urls": false,
    "disable_guests": false,
    "disable_login_language_selector": false,
    "disable_3pid_login": true,
    "brand": "Riot",
    "integrations_ui_url": "https://localhost",
    "integrations_rest_url": "https://localhost",
    "bug_report_endpoint_url": "https://riot.im/bugreports/submit",
    "defaultCountryCode": "GB",
    "showLabsSettings": false,
    "features": {
        "feature_groups": "labs",
        "feature_pinning": "labs",
        "feature_reactions": "labs",
        "feature_message_editing": "labs"
    },
    "default_federate": true,
    "default_theme": "light",
    "roomDirectory": {
        "servers": [
            "matrix.org"
        ]
    },
    "piwik": false,
    "enable_presence_by_hs_url": {
        "https://matrix.org": false
    }
}

[jryans]

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]

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.

[jryans]

Current design:

[jryans]

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]

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

[neilisfragile]

@jryans https://github.com/vector-im/riot-web/issues/10167#issuecomment-518308756 is my understanding of what needs doing, is there anything further you would need to mark this unblocked?

[jryans]

@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]

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.

[jonaharagon]

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]

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]

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.