In the fall of 2016, we conducted a survey of over 1,100 tech products used in schools or by youth. We tested login locations because that's where sensitive information gets handled. A more comprehensive survey would also include the account-creation location, and we will likely expand the scope of this survey in the future. As we describe in the write-up that summarizes the results of our initial survey, we performed three actions at each login location:
- sent an https request to the login URL and checked the http status code (i.e., asked whether https was supported);
- sent an http request to access the login URL to see if the site redirected to https (i.e., asked whether https was required);
- and inspected the site header for the presence of HTTP Strict Transport Security (HSTS) directives.
However, we want people to be able to run these tests themselves. School district staff, parents, students, people in STEM classes, people learning how to code, and vendors all can do this work. It's not complicated -- and if you're putting a project out in the education space, this type of testing is a critical part of product development. We go into more detail about additional tests in our information security primer, but this basic test script is an easy starting point. To make our work both more transparent and more accessible, we are happy to release this script publicly under an open-source license. The repository contains documentation that describes how to check individual URLs and how to batch-process hundreds or thousands of URLs. If you're a vendor, we strongly recommend that you use this script to check the login URLs of your products. If you're in a school or district, use this script as part of a quick triage when you're evaluating technology. We have incorporated these checks as part of our evaluation process and will continue to expand automated checks in the future.
As an interesting side note, as Jeff Graham, the lead developer of the Privacy Evaluation Initiative, was preparing this script for release, he noted that on some sites, different user agents were treated differently on some sites. In practical terms, this allows sites to use encryption with some browser agents and not use it in others. When we do more work looking at connected devices and the internet of things, we need to keep this in mind: This is one reason the security of connected devices lags behind many other services. Some sites explicitly allow connected devices to send information via unencrypted connections. Supporting these tests is on our road map.