10 min read
I probably spend more time than recommended browsing the web and reading privacy policies and terms of service, looking for patterns. When I encounter a new app, the first thing I do is find the terms and read them. Terms are useful in a range of ways. First, what they say matters. Second, how they say it can provide insight into the service, and how the company views themselves. Third, terms can indicate the business plan (or possible business plans) of a company. Finally, the degree to which the terms align (or not) with the product can indicate how coherent the planning within a company has been. There are other elements we can glean from terms, but the points outlined here are some of the more common items that can be inferred from terms.
Last week, I encountered the terms of service at characterlab.org. They offer an application to support character growth. The terms discussed in this post were updated in August; 2015. I downloaded an archive version this morning (April 4, 2016).
The target audience of Character Lab is teachers, but they also get information about children (to set up accounts) and from children (once accounts have been set up).
Account Creation and Parental Consent
In the process defined by the terms and reinforced via their user interface, teachers create accounts for students.
The information we collect varies based upon the type of user you are.
(i) Teachers: In order to use the Service, you will need to register for an account. In order to register, we will collect your name, login name, and institution you are associated with, grade level, years of experience, along with your telephone number and email address.
(ii) Students: Students will not be asked to provide Information. Teachers will create accounts for students by providing their name. Students and teachers will both input information related to student character assessment tests and other Services-related functions.
In the terms, parental consent is mentioned, but only in passing, in the "Eligibility" section:
You must be at least 18 years old, an emancipated minor, or possess legal parental or guardian consent, and be fully able and competent to enter into and abide by these Terms to access the Service. If you are under 13 years of age, you may only access the Service with the express permission of your legal parent or guardian.
Given the account creation workflow in place with this site, a teacher is binding a student to these terms, potentially without any parental consent. In the case of a student under the age of 13, the way the eligibility terms are written ("If you are under 13 years of age, you may only access the Service with the express permission of your legal parent or guardian.") the onus for understanding and obtaining the need for parental consent appears to be on the student, who my or may not be aware that the terms exist, and who has no role setting up their account.
At the very least, the terms should require that the teacher or school creating student accounts obtain and maintain verifiable parental consent.
A suggestion for vendors looking to avoid this circular setup: read your terms from the perspective of each of your target users. If likely scenarios exist where a person would have data in your system before that person had any opportunity to interact with your system, you should consider revising your terms, your onboarding process, or both.
From the "Protecting Children's Information" section, we are given text that fails to meet basic standards for clarity.
If you are a student, please note that your parent can view request a copy of your character report, and any and all other information associated with you, on this Site, including without limitation messages between. If you are a parent, you may request a copy of your child's character report (whether self-reported or reported by any and all other information associated with your child) on this Site by either submitting an email request to Character Lab at firstname.lastname@example.org.
A couple things jump out here: first, as highlighted above, students play no role in creating their account, so the chances they would be informed that parents can request a copy via these terms is slim. Second, both sentences in the "Protecting Children’s Information" section contain grammatical errors and word omissions that make them less than comprehensible.
If you are putting out an application that collects data, read your terms. Have a good editor read your terms. Have a good lawyer read your terms. Have your lead developer read your terms. If you are the company founder, read your terms. If terms contain basic grammatical errors, or sentences riddled with omissions, it raises the question: in how many other places do similar weaknesses exist?
Data collection and minimization
In looking at the data that is collected, several areas exist where the terms claim the right to collect more data than is needed to run the service.
Your browser type, language, plug-ins, Internet domain and operating system;
This service has no need to collect information about browser plugins. Collecting this information is a component of browser fingerprinting, which is a precise method of tying a specific browser to a specific machine - which can often lead to uniquely identifying a person without collecting data traditionally considered Personally Identifiable Information (or PII). Additionally, tracking "Internet domain" seems excessive as well. While the term is pretty vague, one common definition could mean that the service tracks the domains from which requests originate, so the vendor would know if someone was connecting from the network of a specfic school or university. This information replicates a lot of what can be inferred from collecting an IP address (which characterlab.org also connects), but connecting an IP address to a domain seems unnecessary - especially because teachers are required to state a school affiliation when they register.
Moving on, the terms also claim the rights to collect and store device IDs and physical location.
Unique identifiers, including mobile device identification numbers, that may identify the physical location of such devices;
This service does not require a device ID or physical location to run. If they actually collect and retain this information, it creates a much more valuable dataset that could be compromised via a data breach or human error.
If this data is actually needed to run the application, then the terms need to clarify how and why it is used. I suspect that this is an example of something we see pretty regularly: the terms are out of sync with what the app actually does. CharacterLab is not alone in claiming the rights to obtain device IDs. Many other EdTech companies do this. While it is easy to get a device ID, it is generally not necessary, and many EdTech companies could eliminate this practice with no negative effect on their service.
Data collection and retention should be minimized to reflect the specific needs of the app. When a vendor thinks about these details, they can build better software that is easier to maintain. By making sound technical decisions as a regular part of the development process - and by verifying that the terms of service reflect actual practice - vendors can have confidence that they understand their product, and how it runs.
This issues with data collection and retention are highlighted by how data will be treated in case of a merger or an acquisition.
(d) in the event that Character Lab goes through a business transition, such as a merger, divestiture, acquisition, liquidation or sale of all or a portion of its assets, your Information will, in most instances, be part of the assets transferred;
This provision creates the very real possibility that data can be sold or transferred as part of a larger deal. This is a very problematic clause. As we saw with ConnectEdu and Corinthian (where student data was included in a sale to a student loan collection agency), these sales happen. Given the rate of churn in the education technology space, terms that allow student data to be sold or transferred create significant risk that data will be used in a range of ways that are completely unrelated to the stated goals of Character Lab.
The ability to transfer data, paired with the data that can be collected, could be mitigated to an extent by a good deletion policy. However, Character Lab does not deliver on that either.
Please note that certain Information may remain in the possession of Character Lab after your account has been terminated. Character Lab reserves the right to use your Information in any aggregated data collection after you have terminated your Account, however Character Lab will ensure that the use of such Information will not identify you personally.
When data is deleted, it should be deleted, full stop. Given that Character Lab claims the right to collect browser plugins or device ids - either of which can be used to precisely identify an individual - the claim that they will ensure that their data set won't identify you personally rings hollow.
This problem is exacerbated because the terms contain no language banning recombination with other datasets.
To be clear, the reason that they include this claim over deleted data is to support research. However, they could support their research needs and respect user intent by specifying that they will delete all user data, and not incorporate that data into aggregate data sets moving forward, but that any data used in aggregate data sets created before the data was deleted will not be affected.
Their provisions here would also be less problematic if the app minimized data collection, as outlined above.
Changes to terms
Finally, this app contains the poison pill for terms of service.
The ability to change terms with no notice is always problematic, but it is especially problematic given that this site contains student information, and that the site has limited the ability of people to fully delete their information.
If terms are substantially modified, users should be notified via email, and via notice on the site - ideally as a banner, and as added text on the login page. The updated terms should also be posted for a specified period (generally around 30 days) before they become active.
The issues outlined here are a summary - there are other things in these terms that could be improved, but in the interests of brevity I kept a narrow focus.
These terms have issues that appear frequently across many terms in both educational and consumer technology. My sense in reading these terms is that the terms of using the service have drifted from the intent of the people creating the service. This is a common issue - building an app and releasing it into the world is a lot of work, and it's easy to overlook the need to clarify the terms of service. Imprecise or poorly written terms are rarely a sign of bad intent.
However, given that the terms provide the legal basis and rights of both vendor and users of a service, getting them right is essential. For a vendor, ensuring that the terms align with the practice and intent of the application is a very practical way to ensure that you have organizational clarity about the goals of your organization, and the role technology plays in reaching them.