On April 1, the LCPS Department of Digital Innovation sent out an email with the subject line, “Reminder: Information Regarding LCPS Google Accounts.” The information in question regarded a “new data security protocol” that would be put into effect the following day. Starting April 2, all third-party applications that use the “Sign in with Google” functionality have to be reviewed and approved by DDI. 

DDI works throughout Loudoun County addressing all things technology. They provide hardware and software support teams, report on technology purchases, support internally developed and purchased applications, and most importantly — in the case of the new policy — deal with all information security efforts. 

In addition to the new Sign-in with Google policy, the DDI Information Security branch is also responsible for other well-known tech facets like online monitoring and filtering. This is primarily done through two main avenues. The first is Gaggle, a software that monitors students’ Gmail, Google Drive, and more. If it discovers certain flagged words, it reports students to their counselors. The second is blocking access to inappropriate or harmful websites.

The new Sign in with Google policy, however, is separate from both of these avenues, in the sense that even if a website is affected by the new policy, it could still be accessible. It does not fully block students from accessing certain websites; it just blocks students from using their LCPS email to sign in.

To see how it affects student accounts, let’s look at an example.

At first glance, the issue is easily understood: LCPS doesn’t want staff’s or students’ info being shared with unauthorized sites. The reasoning behind this, however, is less obvious. Firstly, what info is being shared in the first place? And second, why has the info sharing been stopped via the new policy?

Pertaining to the first, according to Google’s own help page, the data shared is a minimum of three things: your name, your email, and your profile picture. In addition, other applications can ask for other info. Online PDF editor DocHub, for example, also takes in your language preference.

It doesn’t end there, though; third-party applications can still request other data. How? Short answer, OAuth 2.0 Scopes. Long answer, a set of URIs that developers can integrate into their programs. Even longer answer:

To help software developers, Google provides a specific code framework that they can use, part of which is called “OAuth 2.0 Scopes.” The “OAuth” part stands for “Open Authorization” and means that this code deals with resource (i.e. user data) access. The “2.0” comes from the fact that this code framework is based on a set of industry standards called OAuth 2.0, created by the Internet Engineering Task Force. Finally, “scopes” are what Google calls Uniform Resource Identifiers that describe exactly what data is being accessed. Uniform Resource Identifiers are similar to Uniform Resource Locators, more commonly known as URLs, and both are groups of characters that point to some resource.

An example of an OAuth 2.0 Scope is “https://www.googleapis.com/auth/drive.” (Notice how it looks just like a URL!) Adding this in a specific place in your code will cause the Sign in with Google feature to ask users if they can “see, edit, create, and delete all of your Google Drive files.” Other scopes allow programs to do anything from viewing your Google Calendar settings to managing your advertising data.

Admittedly, it all sounds a little scary, but remember that the data shared when you Sign in with Google is what you let it be. Third-party applications only have the power to request data; you are free to respond as you wish. And, developers’ appropriate and accurate use of scopes is required by Google’s code policies. 

With the first question answered, we now move on to the second: why does data sharing, and thus Sign in with Google, need to be stopped?

To find this, we turn to the link provided in the pop-up. It offers some expansion on the April 1 email, a table of approved applications, a link to some FAQs, and — most relevant for us — the following statement:

“Reducing third-party application providers’ access to LCPS staff and student data improves our exposure should a third party have a data security incident.”

In other words, by sharing less data with other applications, LCPS is in less danger if/when those applications have data breaches. It is a reasonable answer, of course, but we wanted to learn more. However, after multiple messages to a dysfunctional email, one message sent to a functional email, and a call sent straight to voicemail, we were left empty-handed.

One thing we did learn though, looking back at Google’s help pages, is that third-party applications retain access to data you’ve previously shared, even if you remove your consent. This does point to some danger that staff and student data could be in. In this sense, the new Sign in with Google policy is helpful to protecting LCPS.

That isn’t to say that the new policy doesn’t have downsides, though. Mainly, it’s simply inconvenient. When users create new accounts, they are forced to enter their information manually, and signing in becomes more of a hassle. For what it’s worth, students now have to reconnect their Google accounts every time they want to access Schoology documents. And, there’s always the possibility of harmless programs being unnecessarily restricted.

All in all, the concerns surrounding data privacy and security outweigh the minor inconveniences. In an era where data breaches are not just possible, but increasingly common, institutions like LCPS are taking proactive steps to safeguard the personal information of their staff and students. The new policy is a testament to their commitment to data security, even if it means adding an extra step or two for users when signing into various applications.