American schools' phone apps send children's info to ad networks, analytics firms

Get used to it, kid

The majority of Android and iOS apps created for US public and private schools send student data to assorted third parties, researchers have found, calling into question privacy commitments from Apple and Google as app store stewards.

The Me2B Alliance, a non-profit technology policy group, examined a random sample of 73 mobile applications used in 38 different schools across 14 US states and found 60 per cent were transmitting student data.

The apps in question send data using software development kits or SDKs, which consist of modular code libraries that can be used to implement utility functions, analytics, or advertising without the hassle of creating these capabilities from scratch. Examples include: Google’s AdMob, Firebase, and Sign-in SDKs, Square's OK HTTP and Okio SDKs, and Facebook's Bolts SDK, among others.

The Me2B's research project assigned three risk profiles to the SDKs it found: medium, high, and very high. Utility SDKs, which perform useful, expected functions, are considered medium risk.

Analytics SDKs, which collect behavioral data about app usage, are considered high risk because of the potential for fingerprinting, data abuse, and data transit to partners. Advertising SDKs are deemed high risk because they may gather unique identifiers and may be ranked very high risk if they're linked to an advertising platform, like Google's DoubleClick, or if they appear in state data broker registries, like AdColony and InMobi.

The study does not address whether these apps comply with the Children’s Online Privacy Protection Act of 1998 (COPPA), which governs how data for children under 13 should be handled. Nor does it address other privacy compliance questions, much on the minds of marketers since the recent settlement of three class actions lawsuits about mobile apps targeting children with ads. Rather its focus is simply on the lack of disclosure and the fact that students deserve better privacy protections.

The data that concerns Me2B includes: identifiers (IDFA, MAID, etc), Calendar, Contacts, Photos/Media Files, Location, Network Data (IP address), permissions related to Camera, Microphone, Device ID, and Calls.

About 49 per cent of the apps reviewed sent student data to Google and about 14 per cent communicated with Facebook, with the balance routing info to advertising and analytics firms, many among them characterized as high risk by the Me2B researchers.

Private schools and Apple users win out

Among the public school apps, 67 per cent sent data to third parties; private school apps proved less likely to send data to third parties (57 per cent).

"This finding is particularly troubling since public schools most likely utilized public funding to develop or outsource the apps – meaning that taxpayers most likely paid to fund apps that are sending student data to online advertising platforms," said Lisa LeVasseur, Me2B executive director, Zach Edwards, who heads Me2B's data integrity testing team, Karina Alexanyan, CEO of ed-tech consultancy Humanication, in an online post.

There was a significant difference across mobile platforms: 91 per cent of student Android apps sent data to high-risk third parties while only 26 per cent of iOS apps did so, and 20 per cent of Android apps piped data to very high-risk third parties while only 2.6 per cent of iOS did so.

The Me2B researchers credited Apple's recent introduction of its App Tracking Transparency (ATT) framework as further increasing the "respectfulness gap" between iOS and Android apps. In fact, Apple last month told developers that it would begin rejecting apps that contain advertising SDKs that implement fingerprinting. This may moderate SDK-based privacy concerns on iOS apps at least.

Nonetheless, the researchers expressed concern that 95 per cent of third-party data channels in the surveyed student apps are active even when the user is not signed in and that these apps send data as soon as the app is loaded.

They also noted that neither the Google Play Store nor the Apple App Store (despite the privacy disclosure improvement brought about by Cupertino's App Privacy labeling requirement) provides details about which third parties receive data from apps, "leaving users no practical way to understand to whom their data is going, which may well be the most important piece of information for people to make informed decisions about app usage."

The Register asked Zach Edwards whether naming SDK providers on app store listing pages might be sufficient to address privacy concerns or whether each SDK ultimately will need to have its own detailed data usage disclosure similar to App Privacy labeling.

"SDK labeling should start with merely disclosing who is receiving the data, this would be a huge improvement over the current opacity – everyone should know the names of companies who have SDKs installed within any apps before they install the app, and be able to use that information to make an informed choice about whether they want to use the app," Edwards replied.

He said that many app developers would probably prefer that existing privacy labels incorporate SDK disclosures because often it's not the apps collecting the data but one of the SDK partner firms.

"If Apple updated their privacy labels to both include SDK names installed in apps, and allow the SDKs to be included within privacy labels for accessing specific types of data, this would make it easier for app makers to explain their own practices, make it clearer for regular people what is actually going on and who is collecting their data, and it would make it easier to determine which SDKs should receive access or deletion requests if a user has concerns about the data they ingested and the portability of that data," he said.

The Register asked Apple, Facebook, and Google for comment. So far, no word. ®