I’ll just point out that any other system that’s not a school system doesn’t really solve their problems. 
We can definitely talk about it in Heidelberg but generally when a school allows it, SSO is still much less effort than bulk account creation for the individual instructors.
Also Google accounts for schools are much less evil than normal accounts. There’s no ads and no targeting for most services. We can even restrict google SSO to educational Or work accounts only if we wanted. Google even changes schools for some services now, which is a step in the right direction... sorta.
Definitely a step in the right direction, because it means their promises are backed up by contract law. If you don't pay, their promises are just hot air.
P.S. The thing about SSO is that we can decide to add it later, but once it's in there, we can't undecide, because people will be depending on it.
Thats a very reasonable point. And it’s true that we can always add SSO later.
Technically, losing access if we remove SSO is only true if we don’t store emails. Then the “recovery” is relatively easy. But more generally, we need to think about account recovery mechanisms for when students lose access to a school account. SSO or not, the challenge is a system for proving ownership (Which thus far we are quite trusting), and secondarily a process that we as a small team can actually support. That’s the even harder bit.
Yeah, I've been worrying about that. :~(
Maybe this should be a separate post, but why not support integration of snap into e.g. moodle or an other platform that might already exist at a school. Do authentication against that portal and also save everything there. No saving to the snap! cloud, only on the platform. No data privacy issues that way. There would be no sharing outside of the schools platform though.
Yeah we're talking about that. If you save projects on the moodle, there's no need for authentication with us at all! You don't need an account to program in 
, just to save your work in our cloud. What I don't want is for students to log in with us using an ID assigned to them by the school, because that counts as PII. My goal in life is for us never to get anywhere near any PII.
It depends on what you mean by "log in". An opaque user ID (e.g. a GUID) is not PII. Submitting to Moodle, as was suggested as an integration would still require some authentication, but the resulting data could be stored in Moodle. (or it could be stored attached to a GUID that no one ever actually sees and that you can only get to by going through your Moodle (or other LMS) course.)
If students' projects are stored in the Moodle, I don't understand why they need to authenticate with us at all. It'd be just like using not logged in, and saving to your local disk.
Think of it as more like saving to your Google Drive. If you want to export and XML, but if you want something integrated where when you hit Save in Snap! the right thing happens, then that requires authentication.
Remember, we've changed the open dialog so it has a local disk option that switches to an OS open dialog, so can't we have Save do the right thing, remembering that you saved to a local file?
I mean, we can make Snap! do whatever we want. The point is that if you were to integrate in an LMS ideally hitting save would trigger a submission. If you have authentication that’s possible.
Of course sporting still works. And it always will. I really think that legally, that should cover us... since the cloud is merely a convenience but everyone really does want it.
sporting?
Anyway, could we get Brian-style anonymous bulk accounts (the teacher isn't anonymous...) up quickly? Lots of people are beating on me about it.
That's what I imagined. No saving to Snap! cloud, but (re)submitting to an LMS on clicking save and also being able to either choose submitted projects in the open dialog, or opening them from a link within the LMS. Ideally you wouldn't have to run a copy of Snap! on the LMS-Server, rather just a plugin, that interacts with Snap! on the Snap!-Servers; That way updates would be available at once...
Michael keeps pushing for that solution. I'm terrified about us storing school-assigned login names, because that's PII. I'd be much happier if the LMS would store our randomly assigned usernames, and when the kid logs in through the LMS, it sends us our username instead of the school's for this kid. And that way, the kid wouldn't have to remember our username, so it wouldn't be harder to use -- the kid would still log in with the school's student ID number, but we'd never see it.
Brain... do you read what I said?! We don’t get school assigned login names. We get opaque unique IDs that are not names or SIDs.
But also not so quick since we haven’t really figured a bunch of things out. And we have far more pressing stuff still like all the extensions breaking in new chrome on Tuesday.
I seriously don’t think we should be building any features until we actually figure out funding and support for the back end. We are having people rely on system for which there is not really support. I mean, things shouldn’t break but we have too many long standing needs that only get more complex the more features we add.
Oh, cool. I like that. Same for Google Classroom?
I guess I'm remembering an earlier discussion in which you were advocating that we let teachers give us a spreadsheet with IDs.
Maybe we can talk about this Wed if we're efficient about the storing-solutions discussion. But I think this
is kind of a red herring. If we lose the back end we're dead. So that's not going to happen. And, I really am getting bunches of anxious messages from the BJC Piazza, from TEALS people, from Mary, etc etc. Yes, okay, eventually we should support everyone's favorite grading software. But we need bulk accounts in some form yesterday.