There are ways to automate account creation, but we don't have an easy one yet... There is an API for individual account creation. It would let you provide passwords to each account created. Email addresses don't even need to be unique in our system.
As far as FERPA -- there's not much we can do to help here, sorry! Because there's no set of standards, we can't be compliant with FERPA without signing an agreement between each school, and in this case UC Berkeley. The University really isn't in a position to sign those agreements either.
The thing is I'm not sure teacher access of student accounts is the best thing either. While institutions has rights and the ability to inspect student work, in most systems it's not individual teachers who have that control. It's not that I don't trust teachers in general, but who a "teacher" is can be broad and there's not exactly a way for us to verify accounts.
Students who use Snap! should be encouraged to do so outside of class and after the class ends. This isn't like some LMS, and we really don't want it do be either. We want students to explore on their own.
As far as other bits go:
No we don't have a way of doing LDAP and I don't expect we will. I have experience building SAML2 / Shibboleth integrations and it's a pain, plus all these things require plenty of back and forth with IT staff. If we're going to be talking to IT staff then we can probably get them to change whitelists. This has happened in the past...
I will happily accept / review / test code that enables federated login support, though. I'm just not going to build it, and I'm not going to chase down IT staff either. I do this during the week already, and if I did it for Snap!, I'd never build anything useful. Certainly students do forget their passwords, and this is why encouraging the use of federated systems is the right answer, but we just can't support that without funding.
Google SSO (and Microsoft): These are standard OAuth flows, and I think we're interested in at least doing Google SSO. G Suite for Education can fall under FERPA and we have a number of teachers who would be able to use it. Of course it won't work for everyone, but it's a relatively easy win compared to all the other options.
As far as general account things: We are trying to avoid storing user first and last names and other personal identifiers, including student id. That means the only uniquely identifying info is email, and the students' body of work. (Which is in a bit of a gray area with code. It's not handwriting, and stuff like lab work has very similar solutions).
So despite my concerns, what I think we'll probably do is this:
A bulk account feature that we slowly roll out, which will take username, email, password, confirm and track the account creator.
Give those accounts the ability to associate a personal email if they want.
Overtime, possibly, figure out linking between multiple accounts.
Also, as an aside -- schools deeply concerned about student accounts should know that students never need an account to do anything on Snap!. They're free to just use the tools and export files. The software is also all open source, so nothing stops people from hosting their own sites either.
I think we are going to do a dirt simple teacher support system. Let's say a teacher has a Snap! account named TeacherSam, and is starting a class of 34 students, and this is the third such class TeacherSam has set up. We'll generate accounts TeacherSam-3-1 to TeacherSam-3-34, all associated with TeacherSam's email address. This means that the power to change a password, delete an account, etc. lies with the teacher. We also make TeacherSam-3 which will hold student submissions. We send the teacher an email with two attachments: a spreadsheet with two columns--account name and initial password--and a pdf with 34 account signin pages to hand out to the students. Each page has the account name, the initial password, and instructions on how to connect to Snap!.
If you're the teacher and you want more columns in the spreadsheet, knock yourself out. Your copy of the spreadsheet can have all the PII you want. Ours has no PII at all, not even a student email address; we just have the teacher's email address, which we already had from the teacher's own account.
That's all we need. If the teacher wants the pages in the pdf to have more in them (the school's code of online conduct or whatever), there are software tools that'll do that for you.
Oh, one more thing. If you're logged into a student class account, there'll be a SUBMIT button in the save dialog that saves a copy of your project in TeacherSam-3 (the class master account) named projectname-studentaccount-dateandtime. You can submit as many times as you want; it's up to the teacher to determine which submission to read. Neither the student's original nor the teacher's copies need to be shared. We might go so far as to prevent sharing or publishing of class-account projects. (We need to do that anyway; if you look at the "recent projects" list on our home page while school is in session it's always five or six versions of the same assignment!)
So, that's it. The bulk creation, and the SUBMIT feature. I'm thinking we might store student passwords hashed with the account name as well as the random number, so that we can get away with simple passwords (five lower case letters not including l or i or o, say) so that students don't spend all of the first day trying to log in, but that's not a user-visible feature.
I'm pretty sure this takes care of FERPA and COPPA and GDPR problems. We'll have no student PII, so there's nothing for us to protect, or to agree to protect.
ugh, maybe... Doing that is way more work than a basic bulk account creation system. I'm trying to get the NCSU folks to build the bulk API for us, because we can do that fairly simply. But anything like "PDFs" increases the complexity a lot. Eh, we'll probably get there at some point but it makes supporting the software more complex.
And we're not gonna be screwing weird password hashing, unless that's to finally start moving away from the old MIOSoft hashing algo.
Nothing technically "takes care of" FERPA for us. FERPA isn't about us. FERPA is about the school - and what they do with their data. Parental consent to use Snap! gets around FERPA. If schools publish email lists (hopefully not in high school, but universities do), then sharing emails are OK. PII that's "directory" information can be disclosed to 3rd parties without consent.
Otherwise, the data in Snap! that's potentially problematic are the submissions themselves. Handwriting falls under PII with FERPA. As far as I know, there's no one that's yet litigated whether the ability to fingerprint a student's code submission falls under PII, but it's likely that it does if the ability becomes easy enough. If students are turning in unique projects then it's quite possible that those projects are PII either through contents directly included in the project, or via the ability to reverse engineer an author. For Snap! projects, there's likely not enough data to map submissions to students, but who knows...that may change.
(And there's lots of other considerations about a submission system. We should at some point have one, but doing so will dramatically increase our storage needs, especially when it involves making copies.)
... except that when the class ends we can delete them all. Or maybe we wait a year in case parents sue a school over the grading.
My point was that we can work bulk accounts in a way that doesn't involve the school giving us any student records at all.
Okay, fine, the school can make the PDFs themselves, just give them the spreadsheet. In CSV form.
Well, that sounds problematic, except that the students are only going to use these accounts for classwork. (That's a reason for PDFs: We can put our message to students in it, including not posting personalized projects with their names etc. If a student is told not to do something, and does it anyway, does that make the school liable under FERPA?)
Anyway, the point is, I don't think this is hard, I think it's dead simple, and it's respectful of students' needs, parents' needs, and schools' needs. The only thing that's a slight back-end change is that we have to have two flag bits per account, student-account and teacher-account.
And we get our lawyers to write a form the teacher and/or the principal has to sign to be enabled as a teacher account, in which they agree to police student projects and to be the contact person for GDPR requests, including account deletion. But we don't let the lawyers put in unnecessary stuff in which we own all their refrigerators.
All parent are "asked" to sign a district "AUP", by which covers the district for limited release of information for its own uses (without the AUP students are not given network access or an email account - they work as a guest). No district that I have ever worked with would get into app by app parental approval since it it too time consuming and they don't have the staff to manage such functions. And no district would ever publish student email addresses in any form, directory or highway billboard! ... a clear FERPA violation! BH's suggestion is a good start, and avoids the issue of FERPA altogether.
Although this is a grey area, Districts are aware that students must be instructed not post identifying information on forums or other message boards (in my District, 8th grade students participated in a State-wide MOOC run by the State supported online high school. They were given very specific guidance on what they could post and what they couldn't).
And since Snap! is controlled app (i.e. other ordinary users cannot see the work of others), it seems to meet FERPA well (there will be need for a privacy statement somewhere, I'm sure)
Thank you! This is really helpful. I would be interested in helping in the development, if it would help. One of the districts I am working with (60,000 students) has a well staffed and very capable Information Technology department, and they would be very willing to allow district testing of alpha and beta code, and work with you to provide feedback, etc.
Plus, if we want to do anything with FERPA, the conversations have to be with school officials, not teachers. If we're already at a place to talk to school officials, we're close to being able to direct those folks to work on other sources. Snap! will never be able to tell an instructor that "we are FERPA compliant" unless we've already agreed to something with their school.
But as far as what Snap! allows, we already have the ability to create accounts with email addresses that don't belong to the student. We don't yet have a bulk way to do that, but it would be fairly easy to automate by reading our docs (https://snap.berkeley.edu/static/API) and writing a function in a Google Sheet that makes an API call for each row.
That said, I do really want a bulk account creation feature. I'm certainly not suggesting every teacher go and write out some JavaScript, for lots of reasons.
If schools have a process which covers email addresses, then this should be acceptable for sharing basic data with Snap!. That combined with the policies around directory info mean, that a school should be covered.
So here's the thing that I still don't understand: If students get email addresses from schools, why can't they whitelist Snap!? We send email from 1 address (noreply@snap.berkeley.edu), which matches the website domain and they're sent from a reliable sender (AWS SES). We've had plenty of schools need to whitelist the website, and a few in past years have whitelisted email addresses, too. Whitelisting does require some work, but it's a bit of upfront effort for a lot of saved pain. Especially if there's multiple courses or multiple years...
(Note that the forums currently use a different email setup, but that's a separate piece, and will eventually change. I don't know what schools are going to want us to do about that...)
Let me clear about why I'm pushing back, though -- and mostly to bh, but more on the general idea of what's needed:
People want bulk account creation which makes sense. No one is asking for the ability to have them now manage individual access for dozens of students. When it's schools / districts / etc that manage access, there's staff to do so, logging of who does what actions, and often protocols to support decision making. At the point where we have 1,000 teachers who have managerial access to 20,000-50,000 accounts, something is bound to go wrong. We know there's wide appeal for bulk creation, so I don't think a scenario like that is super far off. (And there's hundreds of classes using Snap! each term.)
There are all sorts of work-arounds we can build in or tell people, but each have a cost. "Personal and School Accounts": That means students have 2x passwords, will likely mix them up and will probably start doing work when logged into another account.
My point is: I want to understand what teachers do in a classroom before trying to just build too much. A general API will give us the flexibility in creating names however the user desire, and rather than relying on complex email flows, we can even generate passwords on the front-end and download a file.
Actually, I think it would be quite fun to provide the account generation functionality as a Snap! project that builds and make the request for you! (Obviously, we do want a real webpage, but if you want "complex" stuff, then do it in Snap!)
Some general thoughts about such features. I'm posting these generally so I can refer to this post for future feedback. I especially want to hear from active teachers. Beyond the bulk creation, I haven't heard much about in-classroom use or comparisons to other services instructors use that work well. It concerns me that we'd be inventing something new.
Does anyone here use KhanAcademy? They have a bulk-account creation flow which gives initial passwords, but not allow teachers to reset passwords for accounts. It's a setup tool. Look at these resources...
LOL, they don't even have general bulk CSV account creation.
The idea of emailing passwords seems scary to me...I really do not like this.
Do schools use Clever?
Clever is OAuth based and would be relatively easily to support logins from.
We could even do their course integration stuff at some point, but definitely much further down the line.
Why has no one asked about LTI? I want to know whether this would be helpful.
We definitely not going to have an LTI integration anytime soon. LOL. (We would have to write one from scratch because of the framework we use.)
Aside from the hassle of building LTI (I do this already), it would reduce the need for submissions, assignments, grades, etc. I would be interested to hear perspectives on this.
What other apps to teachers use that need individual students accounts?
If other tools are going through LMS's / SSO / institutional systems, then what protocols are being used?
Is this always preferable?
To helping us build something: Yay!
This is our repository: http://github.com/bromagosa/snapCloud
The Snap!Cloud is an API-first app written in Lua directly on top of nginx. It's small, lightweight, and low on resources. Compared to, say, Rails or Node, there's not as many pre-built solutions for things like LDAP and SAML, though there's likely enough examples to get started!
If we're discussing specific code issues, it'd be great to do that on GitHub or in a separate thread.
Clever: We are relying on a third-party .com platform over my dead body.
LTI: Maybe, although it was invented at Google, so we would have to have our lawyers go over their privacy policy with a fine tooth comb.
But, I don't understand why you want to have a complicated system for handling PII instead of just not handling PII! The totally right solution is that as far as we're concerned the teacher just has 30 accounts.
About password security: We're not a bank. We're not collecting anyone's credit card number or SSN. Why on earth would anyone want to break into some kid's class account? I'm almost tempted to give them all the same initial password!
Every time you say "API" I'm thinking "Does he expect schools to write software?" How does having an API for account generation help? One thing we don't want is for the pornographers to make thousands of accounts from which to post pornographic projects. No, we have to make the accounts, and no one else.
I would like for you to answer the question I keep asking and you keep ignoring: Why is it better for us to have a FERPA-third-party agreement with a school district allowing us to collect student PII, instead of just not collecting student PII? If we get into the FERPA business we need lawyers on hand, we need to vet our own third party suppliers (Digital Ocean, SAP, etc.), it's just a nightmare.
The way we help students keep their accounts separate is that we don't allow student accounts to share or publish projects. Teachers will want that, so that they can use online assignments for grading purposes. (We do have to invent the feature that allows two accounts to own a project jointly, though. But we want that anyway.)
All "manage individual access" means is that if the kid forgets their password, the teacher has to get a reset token and forward it to the student over their in-school email system. And I guess if they're in Europe the teacher has to forward GDPR erasure requests from parents to us, but there aren't going to be any, since the class account is only for classwork and the parent let the kid sign up for the class.
I suppose this is a worry, but much less of one than a workflow in which kids do classwork on their regular account. We want the classwork to be private, but to allow submission to the teacher. That's so much easier to handle if the account name tells us who the teacher is. One thing we should do is make it obvious when you're logged into your class account, e.g., by putting a red box labelled "class account" on the title bar between the menu buttons and the project name.
I suppose I'm thinking that if the kid has a personal account in addition to a class account, the kid is smart enough and motivated enough to keep them separate. Although I confess that if I were the kid, I'd set both passwords the same.
But if the kid starts doing classwork on the outside account, they can just log into the class account and open the project, which the outside account will share for this purpose.
If it turns out that schools really want us to implement "log in with your Google account" I guess we'll have to do that. If they ask us to do that for Facebook accounts we just say "are you kidding?" and refuse.
We should work toward a world in which everyone on Earth carries around a flash drive containing an identity token that works with a single password processed on the local computer. But that's a longer-term solution. :~)
I learned in Internet class that distributed management is what makes the net scalable and reliable. "Managerial access" sounds like a big deal, but all it means is that the teacher can get a password reset token. I don't especially want anyone logging what students do! Not even us. Especially not us!
A nice feature for someday would be the ability to store an ssh-style key pair in a student's private file storage, not storage on the specific computer the kid is using today, that will allow password-free login. We have the "stay logged in on this computer" feature but that's a little too broad. That would be perfect because the key pair on the school fileserver will be the one for the class account, and the one on the kid's home computer/phone will be the one for the personal account.
Oh oops I take back the no-sharing feature. U1L1 has them put their game on their phone, and to do that the class account has to be able to share. Which tells me that eventually we want to invent sharing with particular users only. But for now it has to be sharing ok, but no publishing.
We would never be relying on anything. We'd be giving people the choice to use something if they wanted. Clever doesn't really gain much from us using an open standard -- but we gain the ability to store less about users. This is the same thing with Google Auth and any other auth. Schools who have already chosen to use Clever would gain the ability to keep using a system they chose to use. Schools/students/etc not using Clever would not even be able to do anything with the integration and Clever never gets data about what happens in Snap!. Of course, they'd be able to know who logged into Snap!, though any 3rd party system would know that. We would know that Clever validated this person, and we get a unique ID. We could get additional data back, but we don't need to.
What?! LTI was not invented at Google! It was invented by the guy who leads the IMS consortium that develops the standard. He was sort of sponsored by Google for a summer, but the work is entirely independent. (See https://imsglobal.org for their other stuff or the actual spec)
There is no privacy policy for LTI. It's a data transfer spec.
Again...what?! Using a 3rd party reduces our need to store anything. The entire purpose of something LTI is that what we get an identification value that is unique and opaque to us. We rely on an external system to store that data. We should treat submissions as PII and using something like LTI would enable us to never need to store that data -- it would go straight back to whatever school system the student came from.
But regardless, I've already said how it's possible to not store PII when creating user accounts today.
I seriously don't understand why you are making this argument now when you're the one advocating for perfect encryption of project data. Why would we need encryption if there is nothing to encrypt? Is that really the same argument you're making?
But that's beside the point: kids take advantage of other kids. Some "teacher" might be overzealous about what students do. Again, the vast majority of kids and teachers are perfectly fine, but we don't need to encourage bad habits.
We teach kids about good internet hygiene! We should also be following those practices.
I'm not saying that's better. I'm saying the argument we don't have PII isn't guaranteed. Besides, what I have already described is a system that would allow teachers to create accounts with no PII in the account info if they wanted. But an account named TeacherName123 is pretty darn close to PII even if not exactly PII.
Besides that fact, if teachers are indeed using Snap! to do course management, they will want the ability to see real data - making sheets the match up random IDs to real people is a mess.I'm happy for us to provide a system that allows fake ids -- we do already essentially, but it's not like this is necessarily easier on the teacher.
And yeah, I guess we sort of need to vet "sub-processors" but it's pretty standard. Definitely, not something we want to do, but that honestly seems much more manageable. I've read plenty of school contracts for tools in the past few years.
Again, multiple accounts has challenges. And joint ownership is one option, but it makes the whole process for the student much more complex.
And here's the thing: Once we have anything remotely resembling grades we're subject to all the same stuff whether it's directly identifiable or not.
Really? I mean sure, plenty of kids can manage that. But these things add up in complexity and they make it more challenging for students who want to be engaged to do so. Honestly, that's the most annoying part!! You're taking someone who is already interested in the material and might want to explore on their own and say "hey go deal with this...". I mean, most kids will probably just use their school account for personal stuff, and I think that's probably fine but then we can't just delete/reset things automatically and need a way of "reclaiming" ownership or something.
No school is going to ask for Facebook. Google accounts for schools work differently than regular google accounts. Same for Microsoft. They give schools a lot more control than normal accounts, and for things like passwords and management there's a lot of reassurances that go with using a system like that.
Well, let's be very clear here: Supporting federated login systems gets us MUCH close to that world. Are we going to build support for auth tokens and 2 factor codes and things? Probably not, but I do have plenty services which essentially allow me to have 1 password.
What? There's server logs already. And when someone else does something like reset a password for another student that should be logged. Otherwise, people can just get away with anything.
I'm honestly not sure if I exactly understood what you want, but it sounds very close to cookies -- cookies on a properly setup networked user account are stored on the network. But there's nothing that helps with non-networked accounts.
And this is really my frustration with all these features. There's a lot of "We must do these things" without thinking through what the challenges are!
As to my actual view of what v1 is: When I say "API" I mean an API endpoint like the rest of the cloud uses, and one that is essentially pretty dumb. It will take a spreadsheet (though formatted as JSON) and for each row make a new account. It will require passwords, because that's how the Snap!Cloud works, and it will require emails.
But what a teacher puts into that spreadsheet is up to them. So when we have a function like this, we can make a webpage that does whatever overtime to format or create the request the way. Maybe there's a button for "Make N accounts of the same name", maybe there's not. But the point is that we can do something simple at first and figure out what works.
I have yet to hear from an active teacher that they want 30 sequential accounts. I have heard that they want bulk account creation, and that IT depts sometimes block emails.
I guess you and I have very different metrics for what's simple and what's complicated. I think not having any PII, not having any grades, not having any anything, is simpler than having all that stuff and going through contortions to make it okay for us to have it. You think throwing a lot of technology at a non-problem is simple, I guess. :~(
We have now totally conflated PII, bulk accounts and many things... Sorry.
Seriously, what?! I'm not advocating for storing any of that. I'm certainly not the one who started talking about "submissions", which really might as well be equivalent to grades.
NO. I'm arguing that we start with a bulk function that lets instructors decide what they provide us.
All I am advocating for is what essentially amounts to CSV → Snap! Accounts, except that very importantly, I'm advocating we not make any restrictions about how usernames, emails, passwords get put in that CSV. If we want something easy, then this is it. Give users the choice.
I guess I am not making myself clear. Because we should treat any student data as PII whether
it has a name or not. A set of projects are very likely to be uniquely identifying. If you have only 10 or 20 students, and your care about PII, then "MrSmith8" is likely to narrow down to 1 or 2 students very easily. De-anonymization is a thing. I'll repeat that I am not saying we shouldn't have this ability to have anonymous accounts, because we already do. But it does not really sound like people have thought through what this data looks like. I am concerned that people feel like they are agreeing to / asking for something that appears safer and more secure than it actually is.
Ok, thank you! This is helpful to understand, because half the use for bulk accounts is simply to help students get in. Dealing with PII is not necessarily the same function.
Teacher accounts are part of a solution, though I think they create lots of complexities that we might not be ready to support.
Regarding PII: Let me back up. My point about external systems is not that they are easy...they're not. But I do have lots of experience building them, and using them and configuring them with dozens of universities. (No high schools yet...)
External systems reduce the need for PII because we are able to delegate authentication (knowing who someone is) to the school. We can get PII and store it if we need, but they all have the ability to give us an opaque id that we use instead. They also have the benefit of being well understood by IT departments because there's 1 path where information is shared. Plus, if it were something standard like OAuth or LTI, the protocols are well understood and have standard configuration paths. It sucks/it hard/time consuming to get to that point, it can be worth the investment.
Nothing is a panacea, but standardized tools can be huge help. Integrations are not creating only a single way to do something, they're giving users the option to use something that they already use. I'm asking about them because they exist at many schools and (ostensibly) do address many of same concerns. Sure we probably can't build a ton of integrations, but I want to know what options are out there.
Otherwise, my point is that I haven't heard of teachers who want to do all that management work. I haven't heard story about how other tools like Snap! get used in a classroom where this is a concern. Look at the stuff Khan Academy has. It solves most of the challenges, but it is fairly complex. No one has yet told me how we prevent or monitor abuse on these various systems. (Look at KA's setup structure. It's very clearly trying to address points of abuse. And to be clear: I don't really like their setup, but they've gone into it at least considering all the possibilities.)
And, yes, the dead-simple give users choice option does have plenty of room for user error, and concerns about privacy, but at least by slowly rolling it out we have the option to monitor and talk to people who are using it.
(Fundamentally, a bulk account tool creates N accounts owned by one person. We already support that today, just the slow way.)
I was asking questions about protocols not to say that we should build them but to understand needs. I don’t expect teachers to know about the various protocols and tools that exist, but I do expect people developing educational software to do their research before inventing special snowflake solutions.
Snap! does not exist in a vacuum. It’s not the only app to run into this.
To bring this back to a specific point of PII:
Also, why don’t teachers just tell students to sign up all using the same email (like one the teacher controls)? And, maybe teachers can tell students what username to use if they want.
Have we told people to do this? If so what’s their response? Obviously, it’s not as fast as bulk creation, but it can still be done in 5-10 minutes. Other than the time part, their responses would be instructive to how they will feel about other options we could have.
Let's solve the problem of a simple bulk creation process, and not invent more problems, or invent solutions that are more complex than the problem warrants.
If you have a BE process (that's the impression I got about 5000 lines ago in this never ending debate), then let's fine tune it and try it out with some teachers. I have some who will try this out today!
Again, you misunderstand the point of asking why. Obviously, this is not an end goal, but asking these questions helps understand what people really want.
I am asking this because it separates PII from bulk creation. And it's not "inventing" some system. It's taking a process that 300,000 students have done and telling them how do it in a way that does use their personal data. I am also using that example to illustrate what is (and is not) different about account creation and what they solve.
I do this during the week already, and if I did it for Snap!, I'd never build anything useful. Certainly students do forget their passwords, and this is why encouraging the use of federated systems is the right answer, but we just can't support that without funding.
(Obviously, we do want a real webpage, but if you want "complex" stuff, then do it in Snap!)
Sorry.