Working Through Questions in EFF’s “Spying on Students” Report

Recently the Electronic Frontier Foundation (EFF) released Spying on Students, a report that presents the results of a long running survey that encouraged parents, students, teachers, administrators and other individuals to submit privacy concerns about the use of education technology in schools. The concerns identified include:

  • Lack of transparency:
  • Investigative burden [on parents and students] :
  • Data collection and use:
  • Lack of standard privacy precautions:
  • Barriers to opt-out:
  • Shortcomings of “Privacy by Policy”:
  • Inadequate technology and privacy training for teachers:
  • Digital literacy for students

In their introduction, the Electronic Frontier Foundation states that its findings “cannot be considered generalizable or representative,” but given that the document makes statements about “key themes” and references to “average people” it is hard not to imagine that is how it might be perceived.

The report also comes more than three years after a much more rigorous study of edtech privacy policies and contracts by Fordham University. Given the number of state student privacy laws passed since 2013, I read the report and was left wondering what a more “scientific” approach might look like.

My day-to-day work is as a technology analyst for a large school district, this often involves testing edtech applications and reading policies. I also spend much of my own time as an volunteer for various K12 privacy organizations, including co-chair of  CoSN’s Privacy Toolkit and a contributor to Common Sense Media’s Privacy Evaluation  project. So, when I read the EFF report it raised a lot of questions that were not answered.

This is my attempt to look for answers to some of the questions that I felt should have been asked and my focus is primarily on questions raised by the EFF’s analysis of the 152 application’s privacy policies.

152 Applications

The EFF included the list of 152 applications as an appendix to the document and I was able in all but a few cases to identify the vendor, a testable login URL, privacy policies and terms of service links. Of the 152 products, it seems likely that an individual with a practitioner’s level of knowledge of the K12 industry would suggest eliminating or separately noting at least 19 of these applications (12.5% of the total) from the analysis so as not to improperly skew the results. Some reasons for suggesting omitting include,

  • application name too vague to be identified and determine the correct privacy policy,
  • application is a page of content on a specific district’s website, not an application,
  • application does not collect student data and is not used by students (e.g. JAMFnation, a system admin support forum for their MDM product),
  • application is a locally install tool that does not require internet connectivity.

The most perplexing example of one that should be omitted was Audacity, a locally installed and stand-alone Open Source audio editing product where the existence of a privacy policy does not seem relevant. Audacity is ironically an example of tool that a school might offer as an alternative to using an online audio editor. The Canadian district SD43 lists audacity as such an opt-out alternative and their Web tools page provides a useful approach to alternative options.

The complete annotated list of suggested omits appears at the end of this document.

Privacy Policies

The report states that of the 152 applications, only 118 had published privacy policies online. In my brief investigation of the 152 applications, after eliminating the 19 applications mentioned, I identified 126 Privacy Policies from the remaining 133. Of the remaining 7, several were Student Information Systems (SIS) which can be hosted (and controlled) locally by the vendor, or by the district and where in that case the districts, not providers, would be responsible for the privacy policy. I verified this assumption is reasonable by identifying examples of the application’s use in specific districts and running nslookup to obtain the ip address and a geolocation lookup to confirm that the SIS and the district’s public website were in the same ip range and location.

Since the EFF did not provide details on how they scored specific policies there is no way to know if a policy scored simply on the presence or absence of information on encryption, retention etc. or if they looked at these issues in the context of the whole policy. To get a better understanding I looked at several of the privacy policies and one that highlighted the importance of this question was Gingerlab’s (Notability) . The policy states that:

“Ginger Labs does not collect any personal information in Notability or on the website. Ginger Labs does not have access to content you create in Notability or to files you import into Notability.”

This would seem to significantly impact how one would score the policy for encryption, retention aggregation and sharing. Tallying notability in the “does not have language about these” would likely be a false positive, but there is no way to know how this was scored as there is no discussion in the report of differentiating applications that by their nature does not/cannot collect any student data (e.g. JamfNation), ones that say in their policy that they do not (e.g. notability) and applications that collect and manage student data.

The report notes that “Some applications note that schools may implement their own privacy policies to govern personal data submitted to the services by student users.”. The EFF lists this as one of their recommendations for school stakeholders (“Don’t accept Terms of Service when you can get a contract”).

Given this recommendation, it would be fair to point out that the EFF’s analysis would not have been able to consider if schools had contracted with these vendors.

To get a better understanding of potential impact of this omission, I attempted to categorize the list of applications using conventions similar to the Colorado Student Data Transparency and Security Act described in the report (contract vs “on-demand” providers). Some providers could have business plans that offered both modes.


Including privacy and security specific language in contracts or contract addenda has become a more common district practice in recent years. One example is the use of statewide privacy contracts promoted by A4L and in use in Massachusetts and California. A4L maintains a publicly searchable database of contract addenda (and vendors that have refused to sign) and  46 of the 152 applications appear in the database (see end of document for details.)

The report paints a dire picture of what is wrong in privacy policies, so it seems reasonable to question if there were any  examples of good practices. In my brief investigation I identified several vendors that provide additional policies including: compliance with California AB 1584 (e.g. See Saw, and Prodigy) and detailed data security policies (e.g. Schoolloop  and eBackpack).

Data Retention

The document lists two providers (Haiku Learning, and Lexia Learning) where “the schools, rather than individual students, retain the authority and ability to delete information from the application.” Given the description of the FERPA school official exception in the report, This is likely because these are contracted services where the provider is acting as a school official, managing the student’s education record. Schools that use external providers are required to maintain direct control. Also Schools may be required to maintain records under state specific records retention schedules.

The report points out that “Storyboard retains student data for up to four years of inactivity”, however when I read the privacy policy it seemed like this is a misleading characterization. The full paragraph, in context reads as follows:

“At any time, any school administrator can delete students and their storyboards off of our systems. We can also delete all of your data upon explicit request. After 4 years (or less at our discretion) of inactivity we will delete student data.”


The report says that “only 46 state [in the privacy policy] that the vendor uses encryption. That means that only about 30 percent of the 152 services reported to us make any statement about encryption. This lines up with previous reports on the lack of support for encryption in edtech.”

I wanted to get a better understanding of this, and found that the report referenced is a study by Common Sense Media (CSM) which not an evaluation of privacy policies as the EFF did, but was a study in which CSM performed an actual test of a site’s encryption.

To provide a more balanced, apples-to-apples comparison and go “beyond the privacy policy”, I identified the login URLs for 114 of the non-mobile applications and tested using the methodology and code developed by Common Sense. In March 2017, Common Sense documented that 56.21% of sites require encryption, in my testing encryption was required on 82% of the sites listed in the EFF report.


I did not include the mobile-only apps in this SSL scan, but I did perform a proxy analysis on two of the apps using the technique described in Common Sense Media’s InfoSec primer, and verified the use of encryption.

Additionally I ran the list of login URLs through a command line tool from SSL Labs that grades the quality of a site’s SSL certificate. The results for the EFF applications (73% with a grade of A) were significantly better than has been my experience for the average for products used in schools based on my regular use of this tool in my day to day work.


To understand the context of this results relative to internet traffic as a whole, I looked at  trustworthyinternet, a site run by SSL labs that is a “Survey of the SSL Implementation of the Most Popular Web Sites” . The score for the EFF application list was significantly better than this list of 150,000+ sites.


This disparity between the EFF’s evaluation of privacy policies and these empirical tests raises a question.  Is it reasonable to evaluate an application’s encryption based on their privacy policy? The data suggest perhaps not.  It also caused me to wonder if the listing of encryption specifics in a privacy policy was an industry norm. It seemed reasonable to look at how EFF addresses this in the privacy policy for their software applications. The policy makes no mention of encryption, and has only this to say about reasonable security.

“Security: Although we make good faith efforts to store information collected by EFF in a secure operating environment, we cannot guarantee complete security. Information collected by EFF will be maintained for a length of time appropriate to our needs.”

Lastly, it is worth noting that many other groups have been working in the student privacy space for the last several years. As shown in the table below, many of the 152 applications have been reviewed by these organizations, and Schools regularly look to these sources and others in addition to relying on “privacy by policy”.

Providers that have signed the Student Privacy Pledge


Providers that have iKeepSafe certifications


Providers that have a Common Sense Privacy Evaluation


The EFF wrote the report to highlight their concerns and advocate for change, and I believe that their advocacy is invaluable. My takeaway from this exercise is a fresh reminder that there is a difference between research and  investigative reporting, and advocacy reporting. I believe all of us in the ed tech ecosystem have a responsibility both to try to understand and to question a variety of  viewpoint, include ones from those we tend to agree with.

I am posting my complete annotations on the EFF list of apps here <appList_EFF> for anyone else to review, comment on, or correct. This work was conducted over the a few evenings and I am sure there are points I have not had time to consider.  I welcome all constructive feedback.


Disclaimer: While I work for a large public school district, this reflects my own opinions and not the opinions of my employer.




Appendix A: Discussion of Potential Applications to Omit from Analysis

Product Reason to Consider Omitting or Qualifying in Findings
Audacity Locally Installed Open Source audio editing product. Audacity is ironically an example of tool that a school might would could offer as an alternative to using an online audio editor. The Canadian school district 43 does this, and provides a useful example of alternative options see
Barracuda Hardware (Network Firewall)
Bluecoat Hardware (Network Content Filter)
CAPE Unable to Identify with certainty, could be for CAPE charter schools or some system on
CaSecureBrowser This is the locally installed client for the California Assessment of Student Performance and Progress
CERAN This is not an edtech product, it is a web page on a St. Vrain Valley Schools district website that lists multiple online tools that are used in the district, but the individual tools do not appear to have been broken out and added to the EFF list.
eCampus Unable to identify with certainty, this name is used to describe many things including a doe website, also used by multiple virtual schools, and for schools brand of blackboard, by powered by Edgenuity. Also is an e-tailer that offers new and used textbooks (, e-books, study materials, and bookstore management solutions
Encore Was SIS from Encore from Spectrum K12 School Solutions (Acquired by Scantron on July 22, 2010 and it is not listed in any form on the Scantron product site) , district locally hosted (San Diego, Clark county) district specific and likely local install see they all seem to be migrating off the product
Geometer’s Sketchpad Locally Installed Executable that does not require Internet Access
Global Protect Palo Alto Networks VPN/endpoint security/policy enforcement see
Jamf Nation JamfNation is the user forum for system administrators of the jamf mobile device management platform and not a system that is used by students or that would store student data.
Logger Pro Windows and Mac locally Installed client software for the Vernier data probes.
Magister Non-US based LMS, Privacy policy and terms are in Dutch
Moodle Open Source Learning Management System, Can be installed locally, for hosting evaluation of privacy policy ins only able to be done when a hosting provider is identified
MyBigCampus Discontinued: SIS from Lightspeed, My Big Campus was scheduled for end of life and support on July 31, 2016
Rapid Identity Identity Management System, District locally installed and cloud application
Sakai Like Moodle (see above) open source, hostable by a district or provider and policy evaluation only relevant in the context of specific hosting instance. This appears to be a Swedish LMS on a Moodle server for one teacher at
Subtext Discontinued: “Beginning on July 1st, 2015, Subtext will become part of Accelerated Reader 360”.
SynchronEyes (SMART Technology) Correct product name is SMART Sync software, locally installed, not an internet product see

Appendix B: Applications/Contract Riders listed in the Massachusetts and California Student Privacy Alliance Database


  1. Accelerated Reader
  2. Achieve 3000
  3. ALEKS
  4. BrainPOP
  5. Canvas
  6. ClassDojo
  7. Clever
  9. Discovery Education
  10. Dreambox Learning
  11. Edgenuity
  12. Edmodo
  13. Educreations
  14. Google Apps For Education
  15. iReady
  16. Its Learning
  17. IXL
  18. Kahoot
  19. Lexia Reading Core5
  20. MindMup
  21. MobyMax
  22. Naviance
  23. Nearpod
  24. NoRedInk
  25. Padlet
  26. Pear Deck
  27. Pearson SuccessNet
  28. Prezi
  29. Quizlet
  30. Raz-Kids
  31. Socrative
  32. Storyboard That
  33. Sumdog
  34. Turnitin
  35. Typing Pal
  36. Weebly
  37. XtraMath


  1. Abcya
  2. Accelerate Learning (STEMscopes)
  3. Acquia Administrative Software Applications (ASAP)
  4. ALEKS
  5. BrainPOP
  6. Canvas
  7. ClassDojo
  8. Clever
  9. Collections Core5
  10. Discovery Education
  11. Dreambox Learning
  12. Edgenuity
  13. GoGuardian
  14. Hapara
  15. iReady
  16. IXL
  17. MobyMax
  18. Naviance
  19. Nearpod
  20. Padlet
  21. Pear Deck
  22. Prezi
  23. Prodigy
  24. Quizlet
  25. Raz-Kids
  26. Rosetta Stone
  27. Seesaw
  28. Socrative
  29. ST Math
  30. Storyboard That
  31. Study Island
  32. Turnitin
  33. Typing Pal

Reporting of 3rd Party Authentications in Google Apps for Education


Unlike Federation technologies like SAML, CAS or Shibboleth that are centrally controlled and must be established by the identity provider, social sign-ons such as Open ID Connect in Google Apps for Education are initiated by the end user. This means that while an institution has a high degree of awareness and control over 3rd party systems that authenticate via SAML, there is much less control or visibility into social sign-ons such as “Login with Google” for Google Apps for Education (GSuite) institutions.

There are several commercially available tools that will report on this data, and this can also be done via the free command line tool GAM with the  domain report which includes much more than just 3rd party authentications.

For anyone looking for a simple way of auditing 3rd party authentications, this Google Apps script, which needs to be run by an account with google administrator privileges, produces a report of all of the 3rd party tools (websites, apps, extensions) that the users in the domain have granted authentication to (e.g. via a “login with Google” button). The report lists the total number of users in the domain that have authenticated to that tool, the tool name and the tool id.

To run the report:

  • Login to an account with Google Admin rights and create a new folder.
  • Get the Folder ID (the long GUID in the URL).
  • From Google Drive, create an new Google Apps script and  paste in the code below, replacing  with the folder ID.
  • From the Resources> advanced services menu, enable the Admin Reports API.
  • From the   Resources> Developer Console menu, enable  the Admin SDK API.
  • Run the Script (or use the “current project’s trigger” menu to run the script on a set schedule)
function createAppReport() {
  var today = new Date();
  var oneWeekAgo = new Date(today.getTime() - 7 * 24 * 60 * 60 * 1000);
  var timezone = Session.getTimeZone();
  var date = Utilities.formatDate(oneWeekAgo, timezone, 'yyyy-MM-dd');
  var rows = [];
  var parameters = [
    var pageToken, page;
   // var ss = SpreadsheetApp.getActiveSpreadsheet();
   // var sheet = ss.getSheets()[0];
   // sheet.clear();
//create a new spreadsheet
  var my_ss = "3rd Party Apps_" + oneWeekAgo;
  var files = DriveApp.getFilesByName(my_ss);
  var file = !files.hasNext() ? SpreadsheetApp.create(my_ss) :;
  var ss = SpreadsheetApp.openById(file.getId());
  } catch (e){;} 
  var sheet = ss.getActiveSheet();
    var response = AdminReports.CustomerUsageReports.get(date, {
     parameters: parameters.join(','),
     pageToken: pageToken
  var activities = response.usageReports[0].parameters[0].msgValue;
      for (i = 0; i < activities.length; i++) {
          var activity = activities[i];
             var row = [
     // Append the headers.
    var headers = ['num_users', 'client_name', 'Login client_id', 'Date'];
     // Append the results.
    sheet.getRange(2, 1, rows.length, headers.length).setValues(rows);
// Sorts the sheet by the first column, descending
    sheet.sort(1, false);
//Moves the file into the Reports folder
  var fileID= ss.getId();
function fileMove(fileID) {
  var file = DriveApp.getFileById(fileID);
  var folder= DriveApp.getFolderById('REPLACE FOLDER ID HERE');
  // Remove the file from all parent folders
  var parents = file.getParents();
  while (parents.hasNext()) {
    var parent =;

Describing the Privacy of Complex Things is Complex… so is testing black box behavior of same, both could do better.

Recently the Mississippi Attorney General sued Google, revisiting some of the same claims that the EFF made in late 2015, alleging that Google is mining student data in violation of agreements and the student privacy pledge.

The title of this post is my TL|DR summary of an excellent post by Bill Fitzgerald, the Privacy Initiative Director at Common Sense Media. It raises  an important point, which is that it is important that the vendors that provide EDTech services be accurate, transparent and comprehensible, about what is happening with use data, it is equally important to hold those that criticise, advocate, lobby, and enforce privacy to similar standards.

Based on the information currently available, the Mississippi AG lawsuit does not appear to meet this standard.

1.The lawsuit lacks specific evidence of any actual evidence of data mining. This was pointed out in the ED Week article about this by Benjamin Herold , where he says

“The Mississippi attorney general’s office, meanwhile, has provided only limited information about how it determined that Google is tracking students, using their data to build profiles, and targeting them with ads. Officials “tested” …[but] declined to provide any details about the nature of those tests, citing their ongoing investigation. The lawsuit itself contains no information demonstrating that any of Google’s allegedly deceptive practices actually occur.” 

This is also born out in the FAQ which says:

Q: What information is Google collecting?
A: It is unclear at this time exactly what information Google is collecting from its GSFE users. Through this lawsuit, the Attorney General seeks to uncover exactly what information Google is accessing and collecting. The lawsuit also seeks information as to how Google is using that data.

2.The allegations about Chrome Sync are both technically incorrect and refers to functionality (sync passwords, browser history, bookmarks etc.) that is similar to functionality that exists in nearly every modern browser/operating system. For reference see both Google’s response to Sen. Franken and the Chrome help page for adding a “trust no one” passphrase that prevents Google from reading sync data (see ) the descriptions of what does not work if this is done make it very clear what it is used for.

3. The references to non-core services ignore the clear statements that Google makes to schools (in the terms and in the admin console) that schools are responsible for obtaining parental approval for all users under 18 prior to enabling a non-core service . One question that has not been answered in Mississippi is if the student accounts the AG used had YouTube enabled for students, and if so, did the school obtain the parental permission.

4.On the claim that the Google policies are complex and in places contradictory. I’d point folks to the EDU privacy notice  which is a short (<1200 word), easy to read document that summarizes the policies provides answers to that would lead one to believe the Miss. lawsuit got the facts wrong and very clearly addresses the concern about multiple conflicting polices by saying…

“Where there are terms that differ, as with the limitations on advertising in G Suite for Education, the G Suite for Education agreement (as amended) takes precedence, followed by this Privacy Notice and then the Google Privacy Policy.”

As far as them being complex, yes, that is a fair point, because it is a complex system and yes there are areas for improvement, but one very clear area I’d point to is where the word “privacy” links to depending on consumer or GSuite accounts.


5.In a video clip of an interview with journalist Anna Wolfe, Hood make the claim that his office looked at “some other class action lawsuits that Google settled where they were in fact mining data of children”. No details were provided, but I cannot identify what “Class action settlements” he was referring to. The most likely one (Matera v. Google) appears to have been modified so that it does not include Google Apps for Education. The settlement document says

“Subsequently, on October 17, 2016, Plaintiff Matera filed an Amended Complaint (ECF No. 58), …… eliminating allegations pertaining to Google Apps”

6. As long as we are on the subject of court settlements and prior bad acts, it is worth remembering that a federal court shut down AG Hood’s abuse of authority in a prior case against Google after a series of Pulitzer prize winning articles on how the influence of lobbyists can sway congressional leaders and state attorneys general.

Some privacy and transparency areas that Google could improve on include:

  1. Disabling all non-core Google services by default for newly created GSuite for Education domains.
  2. Specifically clarifying what takes precedence for schools the ADmin notice that it is the schools responsibility to get permission from parents for students under 18 (and therefore under 13) to use services such as YouTube, Google + etc..) or the terms corresponding language that prohibits the use by under 13 in these services 9e.g. YouTube, Google + and the Google Chrome Store).
  3. Requiring developers to post links to terms and privacy policies in their listing in the Chrome Apps Store, and conspicuously displaying the link.
    • Require the same for Apps found apps discovered through Google Drive’s “connect more apps” feature.
    • Require the same for 3rd Party “google add-ons” for sheets, docs and forms. This last is particularly important as the user interface presents access to these 3rd party services from a menu within a document or spreadsheet. This has the potential to  create confusion over what is a Google product. Also since these services are listed with a tool (Google Drive) that is provided by the school it may create the impression that these tools are recommended, vetted, sanctioned or approved by the district.
    • This is shown below-the Drive App Pear deck has a link to policies, the Docs Add-on EasyBib does not.

  4. Clarifying the behavior of data collection for GSuite EDU users that are:
    1. Logged into GSuite but have YouTube disabled by the Admin
    2. Logged into GSuite but have YouTube enabled by the Admin

An example that raises this question is the network traffic when a non-logged in user searches YouTube and traffic appears to be going to google search services.


Non-Core Services Enabled by Default in GSuite EDU

As part of a an attempt to do a methodical test of the “claims” recently made by the Mississippi AG I started from what should be the logical first step, creating a new GSuite for Education domain. One important thing to note is that when doing this (as of 1/17/17), 25 of the non-core 52 services are turned on by default (list attached). A fair criticism might be that the better privacy by default practice would have been to default all of these to OFF and require the Admin to enable them.

The flow looks like this, As soon as an admin signs up, they must verify the domain (creating a DNS entry to prove they have control). As soon as they do this they get the following message


It is worth noting that YouTube is enabled by default on new GSuite EDU domains (as of testing on /19/17) , despite the under 13 prohibition in the terms], though location, web history and google + are not. Blogger is on by default for all users.

An example of the “notice and consent” for Admin when enabling new services can be seen below.




A fair point could be made about contradicting terms and it is reasonable to think that Districts might be confused about how to determine what take precedence between the pop up dialog the admin clicks overrides and the general prohibition on under 13 in the youtube terms (the same is true for chrome web store which prohibits under 13)

Also the default setting for new products is to enable them



The following table lists the default status of non-core services in a new EDU GAFE domain upon domain activation (as of 01/22/2017)



Blogger On for everyone
Quickly post thoughts, interact with people, and more
Chrome Management On for everyone
Configure policies for Chrome browsers
Chrome Web Store On for everyone
Marketplace for Chrome Web Apps.
FeedBurner On for everyone
Analyze, optimize, publicize, and monetize your RSS and Atom feeds.
Fusion Tables (experimental) On for everyone
Share, discuss, merge, and visualize your datasets
Google Bookmarks On for everyone
Create bookmarks you can access anywhere
Google Books On for everyone
Search the full text of books (and discover new ones)
Google Chrome Sync On for everyone
Sync your Google Chrome bookmarks across multiple computers
Google Developers Console On for everyone
Develop applications using Google APIs and the Google Cloud Platform.
Google Finance On for everyone
Google Finance
Google Groups On for everyone
Create mailing lists and discussion groups
Google in Your Language On for everyone
Volunteer to translate Google’s services into various languages
Google Map Maker On for everyone
Google Map Maker
Google Maps On for everyone
Find local businesses, view maps and get directions
Google My Maps On for everyone
Easily create, share, and publish custom maps.
Google News On for everyone
Create your own customized Google News
Google Photos On for everyone
Store and share photos online with Google Photos and Picasa Web Albums
Google Play Developer Console On for everyone
Distribute your Android content to Google Play
Google Public Data On for everyone
Public Data
Google Search Console On for everyone
Get Google’s view of your site
Google Takeout On for everyone
Copy content in Google accounts for use in another service or account
Google Voice On for everyone
Google Voice
Mobile Test Tools On for everyone
Mobile Test Tools – A set of HTML5 test suites along with supporting tools for browser compatibility.
Panoramio On for everyone
Share photos of your favorite places.
YouTube On for everyone
DART for Publishers Off
DART for Publishers
DoubleClick Campaign Manager Off
DoubleClick Campaign Manager
DoubleClick Creative Solutions Off
DoubleClick Creative Solutions is a rich media production and workflow tool designed for creative agencies to streamline their rich media processes and take control of their turnaround times.
DoubleClick DART Enterprise Off
Enterprise class software ad serving solution
DoubleClick for Publishers Off
DoubleClick for Publishers
DoubleClick Search Off
Manage and optimize pay-per-click advertisements and keywords across all major search engines
Google AdSense Off
Earn money by displaying ads on your site
Google Advertising Professionals Off
Become a Qualified Google Advertising Professional
Google AdWords Off
Find buyers searching for what you sell
Google Analytics Off
Google Analytics
Google Code Off
Google’s home for developers
Google Custom Search Off
Create a search engine tailored to your needs
Google My Business Off
Get your business on Google for free with Google My Business
Google Payments Off
A faster, safer and more convenient way to shop online
Google Play Off
Google Play
Google Shopping Off
Shop smarter with wishlists of your favorite products
Google Translator Toolkit Off
Google Translator Toolkit
Google Trips Off
Google Trips – Your mobile travel assistant
Google+ Off
Individual storage Off
Individual storage
Location History Off
Location History and Reporting
Merchant Center Off
Post your products on Merchant Center, find them on Google.
Partner Dash Off
Partner Dash
Play Books Partner Center Off
Provide access to administrative interface for publishers to sell ebooks on Google Play and make them discoverable in Google Books.
Web & App Activity Off
Access and manage your web activity from any computer
YouTube CMS Off
YouTube Content Management System
YouTube Promoted Videos Off
Promote your content on YouTube


GSuite, O365 & eMail Protection in K12: A Large Scale DNS Record Analysis


This post looks at a large scale dataset of school district DNS records (more than 10,000) and offers two take aways. First it provides some quantitative evidence on the use of cloud mail and collaboration tools in K12 (specifically of Google and Microsoft) and second, it looks at how districts are (or are not) using the  simple measure available in DNS to lower the risk of  Phishing email attacks, like those that compromised computer systems at the DNC.

It is important to note that this was based on the “domain of record” and districts, and even individual schools may have have set up one or more of these systems on domains other than their primary domain. Additionally this looks at districts only and does not attempt to estimate the total number of users of either system by extrapolating District student and staff counts.

School Districts that use  GSuite (Google Apps for Education) and Microsoft Office 365 (O365) must make specific changes to their domain’s DNS entries in order to verify and use these tools. This means it is possible to estimate the general adoption of these two tools by examining the DNS records of K12 school districts.

A programmatic scan of school district domains of record (based on information from all 50 State Departments of Education)  in December 2016 found that for 10,915 domains 48% were using Google, 15% Microsoft Office 365, with less than 1% using both.


This analysis was previously conducted in November 2013 using the same source data. At that time the % of Goggle Apps domains was essentially the same and the % of Office 365 domains was 5%.

Domains using Microsoft Office 365 showed a much higher rate of employing DNS record measures (SPF and DKIM) to reduce the risk of “spoofed” email than Districts using Google Apps.

O365            1,641          1,161 98.17%                193 1.76%
Google Apps            5,229          3,133 59.92%                31 0.59%


School District domain addresses were identified and collected from their respective state Department of Education websites . While there are more than 14,000 school districts in the US, not all districts were listed with a domain, and in some cases where a domain was listed it was a only a web domain that did not correspond to a district’s email domain.  11,093 records were identified from which invalid URLs and domains with no MX record were eliminated, resulting in 10,915 domain addresses. This approach only looks at the domains of districts, not individual schools and only at what was determined to be the district’s primary domain. Actual use of either Google or Microsoft are greater due to the use of secondary district domains and individual school domains.

The DNS records for these domains were programmatically queried to look for specific entries that are required for the configuration of GSuite (Google Apps for Education) and for Microsoft Office 365 (O365).

Domain Verification:

Both Google Apps and Microsoft Office 365 require that the owner of a domain make a specific change to their DNS records in order to prove that they have control of the domain.

Microsoft Office 365 typically has a MX record entry that uses the format

 MS=msXXXX  (where XXXX is a long alpha numeric string)

GSuite (Google Apps for Education) typically uses a TXT record with the format:

google-site-verification=XXXX (where XXXX is a long alpha numeric string)

MX Records:

MX records control the routing of email and are a strong indicator that a domain is actively using a particular service (Google, Microsoft or other)

Microsoft Office 365 typically has a MX record entry that uses the format


GSuite (Google Apps for Education) typically has a MX record entry that uses the format: or  alt<#>


DNS Scan Results:

Approximately  25% of districts had started the setup process (verification) and did not complete the set up to the point of routing email through that system, of these, about half  ~12% also completed the verification and are routing mail with the other of the two tools. And only 25% of districts had no evidence of any Google Apps of Microsoft Office 365 DNS entries.

Count Percentage*
O365 MX Record      1641 15.03%
Google MX Record            5,229 47.91%
Both MX Records                  78 0.71%
No Google or O365 MX Record            3,967 36.34%
Google Verification, No MX Record            1,487 13.84%
O365 Verification, No MX Record            1,252 11.65%
O365 MX & Google Verification                535 4.98%
Google MX & O365 Verification                748 6.96%
No Google or O365 Entries 2,691 25.05%


*Categories overlap, so the total adds up to more than 100%

Securing eMail through DNS

Given the risk of  malware,  ransomware and worse that can be the result of spoofed email

SPF Records

Sender Policy Framework (SPF) is a simple email-validation system designed to detect email spoofing by providing a mechanism to allow receiving mail exchangers to check that incoming mail from a domain comes from a host authorized by that domain’s administrators.(source: Wikipedia).

Enabling SPF is done by adding a DNS record. The chart below show the percentage of domains scanned that had enabled SPF. The O365 districts showed a much higher rate of configuring the SPF setting.

Count SPF SPF%
O365 MX Record            1,641          1,161 98.17%
Google MX Record            5,229          3,133 59.92%
Other System (No Google or O365 MX Record)            3,967          1,790 45.12%
Both MX Records                  78                78 100.00%
Totals          10,915          6612 60.58%


DomainKeys Identified Mail (DKIM) is an additional email authentication method designed to detect email spoofing. It allows the receiver to check that an email claimed to come from a specific domain was indeed authorized by the owner of that domain.It is intended to prevent forged sender addresses in emails, a technique often used in phishing and email spam. (source: Wikipedia)

DKIM use among K12 districts was negligible.

O365 MX Record           1,641                193 1.76%
Google MX Record             5,229                31 0.59%
No Google or O365 MX Record            3,967              5 0.13%
Both MX Records                78                  3 3.85%
Totals          10,915              232 2.13%

How to add these DNS settings in Google Apps and O365

School districts  using Google and Office 365 (and other email systems) can take simple measure to improve email security by enabling SPF, DKIM and DMARC.

  • Google settings can be found here for SFP, DKIM and DMARC
  • Microsoft Office 365 settings can be found here for SFP, DKIM and DMARC

Clarifying the District Responsibility for “Other” Google Services in GAE

Earlier this year I posted some thoughts about some concerns that the EFF had raised about Google’s responsibilities with regard to non-Google Apps google services. My take was that the majority of the responsibility is really on the school Google Administrator (and the District). I thought it would be illustrate this perspective by showing the “behind the scenes”  view of what Google Admin has to do to turn on one of Google’s Non-Google Apps services, and point out some extra steps they added in the last few months to make it even more clear.


The admin consoled makes a clear distinction between Google apps services (covered by the agreement),  other Google services, Marketplace apps, which are 3rd party tools that can be installed domain wide by the Admin, and SAML apps, 3rd party tools that the Admin can set up to use Google as the authentication provider for services that support the SAML 2.0 federated authentication standard.

SAML blog

The majority of non-core services are OFF for Google Apps for Education (GAFE) customers.



But it is also important for K12 schools to make sure that they set the option for releasing new products  to manual



Clicking thru to the settings for a “non-core” service there are notices that the service is not covered by the Google for Work agreement (of which Google for Education is a part). It also included a notice to make it clear that the admin needs to have the authority in their organization to accept the terms if they do turn it on.


In the last few months Google added an additional check box and very detailed wording to make it very clear what a school Google Admin’s responsibilities are  when they turn on a service that is not covered by the “core” GAE agreement






Critical Thinking and the Student Privacy Debate

In my work at a large school district I spend much of my time testing education technology products to make sure that they are safe, secure and private. I read a lot of privacy policies and regularly push back on vendors to hold them accountable for what their policy say and their products do. In recent years privacy advocacy groups have played an important role in keeping the conversation about the importance of student data privacy in the public eye, but sometimes it is also necessary to apply the same “critical thinking” to the claims of both sides.

On December 1st, the Electronic Frontier Foundation (EFF) submitted a complaint* to the Federal Trade Commission (FTC) alleging ( ) that Google had violated assurances that it made when signing the Student Privacy Pledge As an advocacy group the EFF has been a strong voice for privacy for all, including students and provided information to teachers on a balance approach to copyright ( and produced important privacy enhancing technologies (HTTPS Everywhere, Privacy Badger, Lets Encrypt).

The EFF complaint raises three allegations but for this discussion the first and third are best considered together, and they are that…

  1. When students are logged in to their Google for Education accounts (GAfE), student personal information in the form of data about their use of non-educational Google services is collected, maintained, and used by Google for its own benefit, unrelated to authorized educational or school purposes.
  1. Google Collects Student Personal Information Through Changeable Administrative Settings In Chrome and Google Apps for Education Accounts

Regardless of IF the privacy pledge just covers education tools (as the creators of the pledge have indicated, and is the case with SOPIPA, widely regarded as the best of the current crop of student privacy laws),

I think it is important to ask whose responsible (and accountable) for the decision to enable or disable a service outside of the “core” google apps for Education tools. For me it is not Google, it is the school. That is our job, and our responsibility.  When I log into the Google Admin Console, it is very clear what is and is not part of google apps as shown in  this image from Google’s help section

SAML blog


And even more clear when I drill down into a specific service (Chrome Sync), which it the one that is the 2nd of the 3 complaints.





This concept, that the school has “direct control”, in this case the ability to turn on and off services, seems to be fundamental to the idea of outsourcing specific technical functions to Google, as a “school official”. So in the absence of a solid assurance from Google that an “additional google service” is not collecting, using or sharing data for purposes other than providing a service to a user, schools should turn off (or not turn on) the tool, OR get parent permission before turning it on, as some schools do for a variety of “web 2.0” tools . So let’s see if we focus on what is needed., which is…


  1. Making sure the people in schools that have the responsibility for this, have the training (and the backing from school leadership) to do this, and
  2. Making sure that that vendors (all vendors, not just the ones the media, legislators, advocacy groups and competitors fixate on) provide accurate, clear information about what information is collected, used and shared, (not just if it is used for ads). Senator Franken’s letter ( to Google is a good example of questions some school leaders may have, and that should be asked of ANY EdTech vendor.