Content Filtering Policy questions from "the other side"

[Lee989]

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...

 

 

1. 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?
   
2. 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?
   
3. 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?
   
4. 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?
   
5. 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!

[Steve21]

If the app is as simple as it sounds and you’re getting blocked that often I’d assume it’s going to be one of a few cases

 

Either you aren’t using “standards” (as in likely to be unblocked) systems, eg azure/Amazon hosting that’s likely to already be unblocked by most schools for some system, compared to Bob running this from his own office server/domain we never heard of (or you’re using one of the hosts that often get flagged for illegal/adult/spam content etc)

 

- Edit - another example would be if you’re doing one of those “helpful” ideas like log in with Facebook rather than email - which then gets hit by social media blocks etc

 

There is something odd in your content/transfer that’s likely to be hitting filters, for example we had one before where one of the abbreviations being used was on the child protection filtering list, so they obviously kept hitting it while traffic went through

 

Regarding the app query, I guess that’s a question to you really. If you’re building the app using ports/sockets etc compared to just HTTPS that’s likely to need different work on the school end as again one is likely to already be allowed compared to the other

 

 

Generally if it’s an IT related reason and you’ve got in contact with their IT they’d be able to tell you the reason it’s being blocked, as they would have had to make some change to get it working, and might be able to spread light on it

 

Steve

Edited January 27, 2023 by Steve21

[Lee989]

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

[Davit2005]

I've had experience of apps using 443 and not getting on with decryption before now. Solution was to exclude the destination IPs for specific staff members that needed access (who also needed to be local admins for the software to update, not so much issue on a phone app), took a month to troubleshoot/workaround.

[DavidYoung]

Hi, I work for LGfL and look after some aspects of the web filtering. Can you drop me a DM with your email address and we'll take a look to see what we can do.

 

Our schools have full control of their own filtering so are able to make exceptions for your app if it uses standard web protocols (i.e. https over TLS), however, if it uses non-standard ports then the school would need to make a firewall request for the port to be opened.

 

Also, are you using your own domain name or an Amazon ones for all your communications? It's best if you have your own domain with subdomains as it only takes a single entry to allow the app.

 

Drop me a message with your contact details and a link to the app and we can take a look.

 

David

[ibpalle]

With apps and software using HTTPS it's often HTTPS inspection that gets in the way. Applications often do not use certificate validation via CA, sometimes they just use pinned certificates, which causes them to break when subjected to HTTPS inspection.

[pete]

It's worth pointing the SSL Labs checker at your domains: https://www.ssllabs.com/ssltest/index.html

 

Proxies that perform HTTPS interception, even if they're just checking for a valid cert, will apply a stricter standard than a web browser. Make sure you don't have any chain issues.