Ask for the user's consent before creating them a Slack account

[alexgleason]

I'm referring specifically to codeforphilly.org's install; I'm not sure how much the running version diverts from this codebase.

Basically, Slack has a privacy policy and terms of service that users implicitly agree to when they create a Slack account. codeforphilly.org creates the user a Slack account upon their registration for the site without warning or asking them.

I'm not actually sure if it happens upon registration or upon browsing to https://codeforphilly.org/chat while logged in. For the former, I suggest adding an opt-in or opt-out tickbox for Slack to the registration page which links to Slack's terms of service and privacy policy. For the latter, I suggest placing a intermediary page between /chat and the redirect which asks for the user's authorization, again linking to the Slack terms of service and privacy policy.

[themightychris]

Good suggestion. The slack account isn't created until you first try to access slack. Unfortunately we don't currently have a record of whether users have a slack account already or not, with the SSO integration we just tell slack who is authenticated when asked and it handles either creating a new account or authenticating an existing account from the data we send (name, username, and email). IIRC slack did make me agree to their terms the first time I accessed via SSO

I don't know that I want to get into tracking opt-ins on a per-service basis though. laddr implements a number of both proprietary and standard SSO protocols that each brigade may plug various services into

How would you feel about a blanket statement during laddr signup along the lines of:

This site may be configured to provide single sign-on to 3rd party services selected by your group organizers. When you initiate access to those services, your account details may be automatically shared with that 3rd party and you may be agreeing to their terms of use implicitly by doing so. Personal details that may be shared for sign-in purposes are limited to your name, email, and username. Contact your group organizers for details on what services may currently be integrated

[alexgleason]

IIRC slack did make me agree to their terms the first time I accessed via SSO

That didn't happen for me. I clicked the link (expecting to find more information about the chat) and instead it threw me directly into the application with an account made.

How would you feel about a blanket statement during laddr signup along the lines of:

I think this would solve the problem at a bare minimum level. If you force users to tick a checkbox acknowledging that they accept this, even better.

I don't know that I want to get into tracking opt-ins on a per-service basis though.

Okay, I can imagine why. That said, I don't think we need a complex permissioning system to solve the problem.

I suggest putting a splash page between /chat and the Slack auth that basically says "You are leaving myladdr.com. By continuing, you will be logged into Slack (an account will be created for you if you don't already have one). See Slack's privacy policy and terms of service" with a big "continue" button.

The obvious downside is that it's an extra click. Realistically, I don't think people will be bothered by this because they'll either visit the Slack channel directly, through the desktop app, or the mobile app. An extra click is like 2 seconds. Also if we really wanted we could save a cookie to not show that screen to the user again if they click "continue".

laddr implements a number of both proprietary and standard SSO protocols

What else is there, though? Meetup.com gets requested by the server, not the client. Does it send identifying information about the users to meetup.com when it does so? The SSO protocols are inherently opt-in because you can clearly see that you're doing it when it happens. Unless there's something else I didn't catch I think we could use the splash page approach instead of this warning on the registration screen.

Thank you!

[themightychris]

There's also Discourse integration that we use for http://forum.codeforphilly.org/

That's a proprietary protocol. We also support SAML2 which could be used for Google Apps and others but we're not yet using that. The user is not aware in any of the SSO flows what's happening unless we insert a screen and tell them. It is designed to be an entirely seamless and transparent process if they're already signed in with the identity provider (generally called the IdP, in this case laddr)

[alexgleason]

Why is the Discourse integration proprietary? Discourse is GPLv2+ licensed.

[themightychris]

Maybe proprietary isn't the best word, it's bespoke to discourse rather than using SAML

[alexgleason]

Okay, I'm not too concerned about Discourse. It didn't bother me at all when codeforphilly.org created me a Discourse account automatically. I'm assuming it's self-hosted and run by the same people who are running the laddr install. I mean, maybe it would be nice to include some sort of privacy policy that basically says you won't sell peoples' data, but I'd rather take my chances with a local civic community group than centralize every professional discussion in the world to a corporate monolith. P.S. I hate GitHub too but moving away from that seems somehow more difficult. 😕 For now it's the only proprietary web service I've conceded to.

Anyway, it seems like the only seamless SSO flows are Slack and Discourse, but I don't think Discourse is an issue. Doing a SSO with Google or whatever is going to be really obvious that it's happening (I'm assuming Google makes you authorize it), so I'm not worried about SSO against third party apps in the registration/login screen.