search

sipb / uplink

SIPB's integrated chatroom project
GNU Affero General Public License v3.0
6 stars 1 forks source link

Consent/terms and conditions #37

Open gabrc52 opened 1 year ago

gabrc52 commented 1 year ago

Original comment: https://github.com/sipb/uplink/issues/7#issuecomment-1382676450

Terms and conditions when signing up

Moving from https://github.com/sipb/uplink/issues/7

Matrix/Synapse have an optional feature where users have to accept terms and conditions when signing up:

image

Write those terms and conditions. These should probably not be legal terms, just some general guidelines like don't harass people, respect MIT policies, end-to-end encryption is a thing and use it otherwise we can't guarantee the privacy of your messages:

Welcome to Matrix. This is how Matrix works. This service is provided "as-is" with no warranty. We will try our best to keep it running smoothly and you should feel free to reach out if you have any issues. The maintainers plan to rely on it, so it should be available 24/7 or really close. However, we also can't legally guarantee there won't be hiccups. You agree that your username will be set to your kerberos/athena username (i.e. your email). If you wish to use a different username, please do not accept and instead email us at [insert email] here so we can manually create your account with the desired username. Your messages are only end-to-end encrypted, and hence protected, if they say so. Public channels are not end-to-end encrypted because it wouldn't make sense to do so (also clients expect only private channels to be so). If a conversation isn't end to end encrypted, just like Messenger and Discord ones, we can't guarantee it's private. We promise not to look at it, and we promise to have a good security that guarantees we won't get hacked. But we can't guarantee it won't get hacked or that someone won't break into the SIPB office and steal your non-end-to-end encrypted messages. If you use bridges, we are not responsible if your account gets banned, since they may violate their terms of service.

This is tied to #6.

Consenting to Moira list integration

In the linked terms and conditions, add that you agree to give permissions to the moira list integration.

I was originally thinking 2 things: agree to being added for the other moira lists, and one for the Canvas lists. But now I think the former isn't needed for 2 reasons:

  1. if the mailing list is not hidden, other people can already see the list of members through WebMoira, so this doesn't change anything
  2. when using Slack, people just add you to workspaces and no one asks you if you want to be in them (i.e. Orientation workspace). We are simply allowing mass-adding based on Moira lists, so the feature is still the same. nvm apparently you do get email invites. Either way, if they are sent as Matrix invites, it should be equivalent. The matrix invites are public, but this isn't an issue because of 1.

So I would just add one more checkbox: "Automatically add me to the group chats of the classes I'm in", and make it OFF by default.

Now for implementation, there are 2 options, both by editing the sso_new_user_consent.html template:

❌ 1. Send the opt-in via JavaScript ✅ 2. Change the POST endpoint, and write some code that captures the consent and saves it somewhere. I think this is more reliable, because the JavaScript may fail (unlikely, but what if the user clicks the checkbox and then instantly submits before the JS runs? or if there is a JS error it will just go to the console and silent etc). Then do a 307 redirect to the original endpoint.

❌ a) Use PHP ❌ b) Use some Python CGI thing ✅ c) Synapse plug-ins are allowed to get their own endpoints. This would require knowing how to use Twisted (the framework that Synapse uses for web stuff)

  1. Record it from the Synapse source code itself (I'd rather avoid forking the source code at all costs because I am not willing to maintain a fork)

^ Still on the question because we don't know if we'll be able to change the display name from the plug in... (can combine with previous method)

Hmmm what if: Make an event spam checker and if the user changed their name, mark the initial name set event as spam. Might not work necessarily tho. If the source code must be changed, it is best to do so but make a pull request so that everyone can have this. As a test pull request but also helpful, it should not be hard to do one that lets you change the name "SAML" into something like "Touchstone" or "kerb" or "MIT account", and set an icon, and set confirm_localpart because it is customizable for OIDC but not SAML or CAS.

gabrc52 commented 1 year ago

https://ux.stackexchange.com/a/94662

This might be best. It is more transparent. I'd like to autoselect yes for classes, but the best thing to do is no, but if someone just clicks next without reading then they won't, which is also not ideal.

Also: https://ux.stackexchange.com/questions/141170/are-enabled-checkboxes-and-radiobuttons-dark-pattern