Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Prompt to accept identity server policies before inviting them to a room #10093
Prompt for accepting IS terms before inviting a user by email address (if you haven't already agreed to that IS's policies)
There's another beat on which we need to capture accepting the IS's policies - before associating a new email address with your account _and choosing to publish that association on the IS - but that's tracked in #10159 (comment)
referenced this issue
Jun 18, 2019
Talking this through with Dave yesterday, we identified that it might not be desirable or appropriate for the IS to track users' acceptance of policy terms itself, since it would then need to support Open ID.
It might be preferable for the IS to mandate that calls to its APIs are provided with a 'policy-accepted' header representing the URI(s) of the latest policy documents the user has indicated their acceptance of - if this doesn't match the latest docs the IS has published, it can respond with an error (and the URI(s) of the new docs).
This approach could work for the IM, too.
This approach allows us to state with confidence that either the user accepted the terms, or (worst case scenario) the client they were using made a false attestation on the user's behalf.
Is there a reason to do this here rather than at registration or when changing IS? I'm worried that we may have other places where we need to talk to ISes (e.g. for displaying bound 3PIDs in settings), and having each UI control prompt for GDPR flows will be cumbersome versus doing them up front.
If someone has disagreed with the TOS originally, you now want to spam them with the TOS?
Instead you could add some programmatic way of sharing a registration link that would direct the invitee into a room once registered?
Or simply stating in human terms some simple steps to take out of band to invite them to a room?
This looks like dark pattern territory as it is.
"Take the terms or nothing"
This is EXACTLY where cognitive load should be added so that you don't submarine people into taking a TOS they disagreed with already.
A lot of users will have agreed to the ToS as per #10167, for those who haven't, this lets them review and optionally agree ToS when they need to.
There is absolutely no 'spam' as you put it— users are presented with ToS contextually in order to achieve an action they've initiated, and can review and optionally agree if they like.
This is polishing the UX for users that have clicked on [Invite to this room] in the member list. We do have plans to improve, polish and then prioritise link based invites in future in the UX, but until then this issue pertains more to iterating on existing features, not greenfield development.
No dark patterns here, just improving existing features before developing or polishing future ones.
Without being able to review the design comps these quips are entirely baseless. Feedback is more productive, and well appreciated, when responding to the full picture, so please wait on that before piling on with unfounded comments.
The privacy work is complex, spanning everything from UX to technical architecture and we're working hard at it.