Google Adds Chrome Sync to gSuite for Education Core Services

Recently Google quietly made a change to include “Chrome Sync” in the list of “Core” tools in gSuite for Education. Chrome Sync provides the ability (when you sign in to Chrome or by default on a Chromebook), to sync Chrome data to your Google Account and to any other supported ChromeOS/browser that is signed in. Synced data includes chrome apps, autofill settings, bookmarks, chrome extensions, browser history, passwords, chrome settings, themes, wallpaper, open tabs and google payment data*

This change should provide official clarity as to how data in Chrome Sync is used, as described in the Education Privacy Notice.

This change also provides an opportunity for District g Suite Admins to remind users that they have the option to add an additional layer of privacy by setting a Chrome Sync passphrase. A sync passphrase encrypts all synced data at rest. If you set a passphrase, you can use Google’s cloud to store and sync your data without letting Google read it.

Users also have the ability to selectively disable syncing of some or all of elements that are synced.

The G Suite Services Summary page now includes the following text:

G Suite for Education” is an edition of G Suite comprised of the G Suite Core Services, excluding Google+ and Google Cloud Search. …. This edition also includes Classroom and Chrome Sync as G Suite Core Services.

  • Classroom” is a web-based service that allows End Users to create and participate in classroom groups. Using Classroom, students can view assignments, submit homework, and receive grades from teachers.
  • Chrome Sync” is a feature that allows End Users to synchronize bookmarks, history, passwords, and other settings across all the devices where they are signed in to Chrome.

And the G Suite for Education Core and Services Admin help page is updated to say:

G Suite Core Services are Gmail (including Inbox by Gmail), Calendar, Chrome Sync, Classroom, Contacts, Drive, Docs, Forms, Groups, Sheets, Sites, Slides, Talk/Hangouts and Vault.

Prior to this change, Google offered this statement, about the use of Chrome Sync data in response to a request for information from Sen. Al Franken.

Users who have Chrome Sync enabled (whether on a Chromebook or using the Chrome
browser) will have additional information about their browser settings stored in their Google Account, including browsing history, any saved apps, extensions, bookmarks, and passwords. ….. If any of this data is associated with a student’s GAFE account — which is the case when a student is logged into a Chromebook with Chrome Sync enabled with their GAFE account — we consider this data to be the student’s personal information and do not use it to target ads.

Google stated that it “collects, maintains, and uses information via Chrome Sync (in aggregated and anonymized form) for the purpose of improving Google products”. For context, this is comparable to similar language and use by Apple who states that …

“We may collect and store details of how you use our services, including search queries. This information may be used to improve the relevancy of results provided by our services”

And with Microsoft’s Cortana service, which states that

“Microsoft uses your voice data to improve Cortana’s understanding of how you speak to keep improving Cortana’s recognition and responses, and to improve other Microsoft products and services that use speech recognition and intent understanding”


*Google payment data is a non-core service, only available to users 13 and older. Schools are required to get parental permission if this is enabled for users 13-18.


Google Notifies K12 Admins of Upcoming Changes to enabled “Additional Google Services”

I have previously written about gSuite for Education and the number of non-core services that are enabled by default when a school sets up their domain. I have not had a chance to retest what services are still enabled by default when creating a new domain, but I did want to acknowledge that Google recently notified existing K12 admins that unless they opt out, Google will change their settings and turn off approximately 1/2 of the non-core services on August 1st, 2017. Admins can re-enable the services manually.

The list of services to be turned off appears to correspond with the list I noted in Jan. 2017 and is good partial step to helping K12 admins tighten down their domains for apps outside the core set of gSuite tools and it provides a end of school year reminder that schools need to be getting permission, and I would also add,  going back to parents to get permission for services that were turned on by default.



Services settings changing for G Suite for Education on Aug 1, 2017

In addition to our core G Suite productivity tools like Gmail, Docs, and Classroom, Google makes some of our Additional consumer services available to our G Suite for Education users. These services are used by our G Suite for Education customers to support their educational missions. We want to ensure that other Google services that are not designed for students, such as advertising management services, are not accessible to these users without careful consideration from administrators and parents. You can read more about our commitment to privacy and security here.

To keep G Suite for Education focused on the right services for most schools, we will disable the set of Additional services below on <your domain’s> G Suite for Education account on Aug 1, 2017, unless you choose to control your users’ access to these services yourself below.

Note that you are receiving this message because you are either a K-12 school in our system or your domain has no school type in our system. In order to receive better-targeted communications in the future, please set your school type here. Learn more

Here are the services that will be disabled for your domain:


Note that some of these services may already be disabled for your users. See your configuration.

If you choose to control services yourself and opt-out of having these services disabled automatically, your institution must ensure, for each of these services you choose to keep on, that:

  • you are enabling the service for educational purposes;
  • you are not enabling the service for any user under the age of 13 (learn more about using managing access for different users in our Help Center);
  • your organization has obtained parental consent for any users between 13 and 18 years old to use the service. Our Help Center has more information and resources for Getting consent for G Suite for Education.

Note that there might be other requirements in countries and communities around the world. Learn more.

You may choose to keep these services enabled for specific organizational unit, and disable them for others, depending on your needs. For new services that are added by Google in the future, please see the ‘New Products’ setting on the Company Profile page. Learn more

Choose what is right for you:



Testing – New Google Search “Personal” Tab absent in gSuite for Education

This weekend Google rolled out a change to search to add a “personal” tab described by cmswire as…

“results come directly from your Google accounts. According to reports, personal ads may also appear in these results. The tab can be found under the ‘More’ option on the search page and surfaces everything related to a keyword in email messages, calendar events and photos.”

Recently I’ve been testing the differences between Consumer Google Accounts and gSuite for Education accounts, so I thought it would be good to check if this feature was rolled out to gSuite users.

Short answer, it is currently not. 

Google features often appear the consumer version first and move to gSuite but Google has to announced any plans to move the feature into gSuite for Education.

Here is my consumer gmail account, with the “personal” tab highlighted and the “more” menu shows videos, shopping, books and flights

consumer google search

Here is my gSuite for Education account, with  videos highlighted, no “personal” tab and the drop down only shows books and flights

gSuiteGoogle search

Tracking Google and Microsoft Adoption in Higher ED

Earlier this month, New York Times columnist Natasha Singer wrote How Google Took Over the Classroom, a detailed look at the rise of Google in primary and secondary education. (Also worth a listen is the NPR interview on All Sides with Ann Fisher).

The article did not address Google at the post-secondary level, but Joshua Kim of Inside Higher ED asked “I’ve been looking for recent data on the Google vs. Microsoft enterprise e-mail battle – but I can’t find anything recent. Can you help?”

Challenge Accepted.

I have a history (or a mild obsession) of tracking edtech. Back in 2010 and for a few years after, Forbes blogger Eric Lai and I tracked the growth of the iPad in K12, Higher Ed and the enterprise. I have been tracking the growth of Google Apps (now gSuite) and Office 365 in K12 and to a lesser extent Higher Ed since 2014.

Back in December, I posted a domain / DNS analysis of adoption in K12 for O365 and gSuite, so I thought it would be a good time to update the numbers for Higher ED.

The methodology is the same as I used for K12 districts, a scan of DNS records, looking for specific known markers in MX, TXT and other records. However, for Higher Ed the data is likely more accurate given that the root domains are well know (.EDU)

For this analysis, I pulled the US based listing from a list of EDU domains on GitHub. The list included only the root EDU domain, and individual colleges or campuses (sub-domains) may run different email systems than what is used on the primary domain but this approach of  using a large data set provides an overview of the adoption of Google and Microsoft email systems.

I scanned the DNS records of 2,276 US EDU domains and got the following results for domains that had DNS MX records that indicated they were routing mail directly through Google or Microsoft servers. The Google numbers are lower than I had expected.

Google MX Records  18.31%
Microsoft MX Records  40.84%


One result worth noting was that 30.96% of the sites returned DNS markers that were indicative of a domain that had started the process of verifying domain ownership with Google . Take together with the 18.31% of domains that are actively routing mail through Google, this would strongly indicate that  12.65% of root EDU domains had either started or were using Google and are now not using Google for mail. 


Google’s Response to gSuite Admins in Phishing Incident

[Updated: as Doug Levin notes, Google was warned about the potential of this problem in 2011]

On May 3rd, a small percentage (~.1%) of Google users were hit with a sophisticated phishing attack (it used at least 13 different application “clientIds”) . The phishing took the form of a link that directed users to an application  claiming to be “Google Docs” and routed users to Google’s login/permission pages (Oauth2) to grant access to gmail and contact scopes.

For districts using gSuite for Euducation, it was impressive to see how quickly the EDU user community jumped on this issue. AmplifiedIT crowd-sourced the collection of clientIds and posted remediation steps. Google shut down the applications within an hour and Admins of impacted domains received an email similar to the one below late on the evening of 5/4/17.


Dear G Suite Administrator,

On Wednesday, May 3, we identified, investigated, and resolved an email phishing campaign . This issue was addressed within approximately one hour from when Google became aware of it. Please note that we have already taken action to protect all users, and no further action is necessary. To assist you in understanding what happened and better educating your users on email security, we are sharing details on how the campaign worked and how we addressed it.

What happened:

The affected users received an email that appeared to be from a contact offering to share a Google doc. Clicking the link in the attacker’s email directed the user to the attacker’s application, which falsely claimed to be Google Docs and asked for access to the user’s account. If the user authorized the application, it accessed the user’s contacts for the purpose of sending the same message to those contacts. This access only retrieved contacts and sent the message onward—customer data such as the contents of emails and documents were not exposed.

Upon detecting this issue, we immediately responded with a combination of automatic and manual actions, including removing the fake pages and applications, and pushing updates through Safe Browsing, Gmail, and other anti-abuse systems.

We have taken the following steps to protect your users:

  • Disabled the offending Google Accounts that generated the phishing link
  • Revoked any access that the affected users authorized to the attacker
  • Disabled the malicious projects and apps that sought access

In addition, Google is taking multiple actions to combat this type of attack in the future such as updating our policies and enforcement on OAuth applications, updating our email filters to help prevent campaigns like this one, and augmenting the monitoring of suspiciously behaving third-party apps that request consent from our users.

As a general precautionary measure, you may choose to take the following actions regularly for your users:

We thank you for your continued business and support. If you have any questions, please let us know by contacting Google Support and referencing the issue number [removed].


The G Suite Team



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 =;