Lee989

On the back of this thread, I've already started wireframing an IT admin setup wizard that I think could be used during onboarding. It's pretty clear now that we need to do better onboarding and not just throw it all on a teacher to deal with. The first screen being "this bit needs completing by your IT admin" and "here's a fact sheet to help fill in the most common DPIA questions, contact dpo@ if you need anything else" and includes questions like login type, SSO setup, a web filter test to check our app & cdn domain isn't blocked, confirming device platforms used in school (web vs native app). Get all the technical stuff out of the way before a member of staff starts the product configuration & setup. I'll see how it goes down with the rest of the team, but I can't see their being objections to providing a better first impression! Thanks to all who commented, diverted off topic, but really insightful. Hopefully I can make your lives easier if you ever come across us in the wild

Wouldn't work for everyone, we have quite a few schools with the same domain, but yeah it's an idea we could allow the IT admin to say they have a unique school domain and to allow automated access from it. Hash the email on first login to act as a username (because i'm not storing pupil email addresses... ever!). I've already put it on my list to investigate further

Yeah I think one thing i've already realised from being forced to look outside-in, is we need to do more pre-setup with IT admins. People who know what we're asking for. I suspect because passwords are so ubiquitous a teacher is asked the "how do you want pupils to login" and "password" is just the obvious, no thinking required, "i use passwords all the time" choice. I also need to setup some kind of non-intrusive comms channel with our schools' IT admins, where I can ask for feedback and thoughts on stuff. I've always taken the view of it being pointless, they're too busy to bother responding to you, but it's the usual "don't ask, don't get".

IT are always involved to some degree, not sure why SSO uptake is so low, there's so many edtech products in schools these days, surely most, if not all have an SSO provider rather than managing 10 different logins per child. Possibly we have a UX issue to address to promote SSO more heavily. Part of the setup wizard asks if they want to login with Wonde/Google/etc or use passwords, but that is usually completed by the teacher who is acting as the "Product admin" (usually a subject lead). Maybe we need to split that wizard up so IT admins are asked some Q's first, then it goes to the teacher for the other stuff like enabling / disabling the features they want to use with the pupils. Food for thought, thanks!

Absolutely, and to be clear I am very against this, hence why i'm here. I have never in my 10+ years of programming ever stored a plaintext or encrypted password. I'm fully aware of the implications, and I hate it. But money talks, and if I can say "hey, we do this, and we'll never close a sale again" with a screenshot of the poll proving it's not going to go down well, it's a bit more impactful than "hey, if we get hacked, which none of you think will happen, we're done for". On the flip side, i'm also verifying that i'm not being super anal about it. If contrary to my expectations the poll swings to "its fine", I'll have to revaluate my own stance on it.

Disclaimer: I'm a software dev working for a UK edtech. Here to ask questions to make sure we're not causing unnecessary issues for School IT Admins. Like most products, we support pupil login via various SSO's (Wonde/Google/etc), but we also support username & password combo's, and currently, the latter appears to be the preferred sign-in method of most of our schools at the moment, and the one we are having a lot of support issues with. Teachers setup pupils, then either forget to hand out the login cards with the details on, they get lost, or a child leaves it at home. This then requires resetting passwords, which inevitably leads to problems where the old login creds are "somewhere" and they try to use them later, or they forget to send the new details home, parent shouts at the teacher about our app not working, and they then shout at us. Our product manager already had us add a "you may want to save these in your One/Google Drive in case you lose 'em" note, but I don't need to tell you... people don't read (not that I love the idea of saving passwords in a shared drive anyway). We have now been told to explore options for password recovery over resetting. Which essentially means encrypt it, instead of hashing it. So we can decrypt and regenerate the same login cards. These passwords don't protect a great deal of personal data, pupil name, school they go to, and their progress in our app (homework basically, nothing that special), this is the justification being used internally for the reduction in password security, it's not protecting all that much anyway. My concern is, that every new school customer starts with an IT admin tasked with doing a DPIA and setting a few bits up, and the minute they see "pupil passwords are encrypted, teacher passwords are hashed" in our DPA information sheet, they are going to push back hard, possibly even convincing the school to cancel the sale as "we don't know what were doing, cant even get basic password security right". So what are the thoughts of IT admins here? Is this "encrypt don't hash" pupil passwords a major issue you'd fight, or do you just not care that much given the limited pupil info your sharing. Poll for convenience, extra gratuity for anyone that says they don't care, but can explain what they'd want to see to make them reach that decision. For clarity: What i'm trying to avoid is creating a fight match , where we do this, teachers love it and want it, IT admins hate it and have to argue with staff. It's not good for you, the other staff or for us.

Thanks Steve All our stuff is on AWS, I can't imagine any of our domains or endpoints would contain strings that are on lists, most are generic like "/config" and "/homework", but i'll see if I can dig up some filter lists online and run some checks, maybe there's some abbreviations i'm unaware of. The only schools we know of that have had the issue and persisted enough to fix it, seem to be managed by one of the "grid for learning" providers like LGFL, so whenever we've enquired about resolutions we just get told to speak to them instead, and they never reply to us. I guess they just whitelist our domains for the school on request, but not sure yet what the initial block reason is. But good point, we just need to keep asking every time until we start getting more feedback. Some bits for me too look into at least, so thanks for responding

Disclaimer: I'm not a school IT admin, I'm a software developer for a company that is releasing learning software into schools... I hope you don't mind me infiltrating the collective. We have a tablet app on iOS and Android (web browser version coming soon). The app is downloaded to the tablet, and the student signs in, no extra required installation steps from IT admins. The teachers add students via a web-based management system. We collect very little personal info, just a students name is required, which can just be initials or even aliases if the teacher doesn't mind remembering Purple Heart is actually Melissa Brown. No interest in collecting student's personal info whatsoever. However, we are hitting roadblocks where a teacher gets the app on a device, and it's blocked by the content filter. Some persist, contacting you guys to fix it, but some also just give up or think our app is broken. I have some questions about IT admin stuff I don't have experience with, which i'm hoping you could educate me on... Is this common? Do you find you're always getting support tickets about opening up new software and it's something we have to live with? Is there some centralised pre-approved lists we could apply to that would reduce the number of you seeing our app in your support tickets? I have a document of the 4 domains (2 if you allow wildcard subdomains) we rely on and what they are for. Anything else I can provide to make your life easier when you get a support ticket about our application? If I built a web app that tested connectivity between the device and our backend services, would this be a good "check if you need to speak to your IT admin" tool? Or do you apply content filtering rules for web browsers differently to installed iPad/Android tablet applications? Our backend services the app uses, run on a separate domain to our public facing stuff. We rarely have issues with teachers not being able to access the student management portal hosted on "teachers.acme.com", but the app that uses "api.acme-tech.com" frequently needs whitelisting. Is this a coincidence do you think? Or is there some heuristic filtering allowing 1 and not the other? Thanks in advance for any help. At least it's not a printer question!