Is Grammarly a Keylogger? What Can You Do About It?

Sometimes when I sit down and try to write, the words don’t flow. The sentences are clumsy, the words bump into each other, and I always have the sneaking suspicion that there is a more straightforward way to get my point across. I just can’t always get there on my own.

Enter Grammarly.

Their pitch? Forget that D+ you got in 9th Grade English 20 years ago; we will make you sound compelling, concise, —and let’s face it— smarter. Their cheerful videos provide persuasive examples of this value proposition in action, as pithy phrases (which all too closely resemble my writing skills) are transformed like Cinderella into glamourous ball-room dancing maxims for the ages.

But just like Cinderella, there’s always a catch. The problem, it seems, is that Grammarly is only willing to perform this magic trick on their cloud. That means, the text you enter into an app when the Grammarly widget is visible is sent to them.

As an individual, you may be all too willing to agree to that bargain. But what about businesses and IT teams? How do they evaluate Grammarly? On the one hand, it’s a tool potentially beloved by your users, but on the other, it’s a potential nightmare for keeping your secrets, well… secret! Is this any different than the same bargain offered by other cloud-based word processors or chat tools?

Let’s figure it out.

Is Grammarly a Keylogger?

No one wants their product to be called a keylogger. The term evokes images of creeps installing malware on devices for the express purpose of surveillance and password harvesting. Yet, by explicit definition, any tool that logs a user’s keystrokes and sends them to a third party is technically a keylogger.

This must come up a lot for Grammarly because they have an official response to the question right on their support page.

Here is a direct quote (emphasis mine)

Grammarly does not record every keystroke you make on your device. Grammarly accesses only the text you write when you are actively using a Grammarly product offering: The product checks only the text you want it to and provides writing suggestions. Additionally, Grammarly’s product is blocked from accessing text in fields marked “sensitive.” This means that Grammarly’s desktop applications and mobile keyboards do not see anything typed in credit card forms, password fields, URL fields, email address fields, or fields where similar private information is provided.

Sure, this is an answer, but as we will see later, it vastly oversimplifies how Grammarly captures text in practice. Grammarly is essentially saying that it is not a keylogger because the user chooses when Grammarly can receive text, and Grammarly provides value. It’s an answer carefully built around a technicality.

Sebastian breaks it down much better:

Grammarly *IS* a keylogger. They try to dodge it by saying “Grammarly accesses only the text you write while using our product” https://t.co/50BXX9r6uu

— Sebastian (@sebmck) March 8, 2019

Here’s the problem: Grammarly’s framing of the question isn’t helpful. When people ask, “Is Grammarly a keylogger?” they are really asking, “Am I going to regret using this service?” To answer that question as a security practitioner, here are some things I would want to know:

1. What methods does Grammarly use to capture text I write?
2. What sensitive data could be captured inadvertently?
3. What is Grammarly allowed to do with the text that they capture?

Let’s find out.

What Methods Do Grammarly Products Use To Capture Text?

Grammarly offers a variety of products under their branding. If I want to use Grammarly, the options include:

• A web-based document editor
• A web-browser extension
• An app-specific add-in (ex: Microsoft Word)
• A custom installable keyboard (for mobile devices)
• An app running on your OS

Each one of these methods comes with different risks and tradeoffs. Today I want to focus on what is likely the most popular method of utilizing Grammarly, running it as an app on your device. Since I run macOS, let’s dig into that one.

On macOS, when you install Grammarly, you are first presented with a screen that looks like this:

And then helpfully pops up the following screen:

Grammarly is briskly moving you through this process because their app cannot function as designed unless it has these specific accessibility permissions.

But why would a grammar app need accessibility permissions? It turns out that accessibility permissions are like the Holy Grail of permission entitlements. Accessibility permissions allow approved apps to fully control the entire computer as if they were sitting next to you, watching your screen, and holding their hand on top of yours while you typed on the keyboard and moved the mouse.

Based on my brief usage of the app, in practice, this means: capturing the user-editable text inside any application brought to the foreground by the user and augmenting/manipulating the UI of the app in focus.¹

Once this permission is granted, Grammarly can now capture text and send it back to its servers without any further user interaction. No other permissions or extensions are needed.

Grammarly captures text that you already typed before you installed it

Revisiting the keylogger answer from earlier:

“…Grammarly accesses only the text you write when you are actively using a Grammarly product offering.”

In my reading, Grammarly heavily implies that users have a fair degree of control over what Grammarly can access. But in practice, this is very misleading. Let me show you why.

Below, I have composed a new note in Notes.app riddled with grammatical errors. I did not have Grammarly running while writing the document, so there isn’t any possibility that keystrokes have been sent to them.

After running the Grammarly app, re-granting the accessibility permission, and then putting the app in focus, the screen looks like the following:

Grammarly parsed and marked up my document without me typing a single keystroke. All I needed to do was bring the window into the foreground. This makes sense; Grammarly would not be easy to use if it could only provide grammar advice on the documents and words you typed when it was running. I’m not even sure how much Grammarly even cares about the keystrokes you’re typing; if it can read what was written previously, it does not need to.

That being said, I believe it is stretching credulity when they say, “Grammarly accesses only the text you write when you are actively using a Grammarly product offering.”

This is a big problem when it comes to claims that users have control. As a user, I had no way to know that the instant I opened the Notes.app Grammarly would swoop in, scrape all the text, and send it to their servers. Now that I know a document was scraped, I can tell Grammarly to stop doing that in the future, but the cat is already out of the bag. As far as I can tell, there is no easy way to preemptively block Grammarly from accessing apps without you first allowing it to activate in the app and performing the block in-situ.

How do I know when and where Grammarly will even activate? It’s impracticable (perhaps impossible?) to tell until it’s already happened. This lack of consent is fundamentally dishonest.

What Sensitive Data Can Grammarly Capture?

Now that we know Grammarly can capture text by reading the content of the apps in focus, how do we know it won’t collect sensitive information? From their support page:

…Grammarly is blocked from accessing anything you type in text fields marked “sensitive,” such as credit card forms or password fields. You can deactivate Grammarly at any time if you don’t want it to check a particular piece of text.

Sounds great on the surface, but let’s dig in. First, what in practice constitutes a sensitive field? Their support only offers two obvious examples password fields and credit cards, but what about Social Security Numbers?

Here I’ve constructed a simple form with the following markup:

<div class="input text optional marketing_sales_contact_request_ssn">
  <label class="text optional" for="marketing_sales_contact_request_ssn">
    Please enter Social Security Number (SSN)
  </label>
  <textarea
    class="text optional"
    name="marketing_sales_contact_request[ssn]"
    id="marketing_sales_contact_request_ssn"
  ></textarea>
</div>

Here is what happens when I click into the resulting form in my browser with the Grammarly app installed on macOS:

See that Grammarly widget? That means despite the words “Social Security Number” and “SSN” appearing multiple times in the markup, Grammarly instantly activates as soon as I put focus into the text area. It seems as long as something is a <textarea> and not a single-line input field, Grammarly is all too eager to activate and pull down something potentially sensitive.

The above example may be contrived (unless you use many poorly programmed sites from local governments), but it demonstrates a more significant point. There is no way to know when and why Grammarly will activate. And when it does, it’s already too late.

What Can Grammarly Do With the Data It Collects?

Grammarly’s support page Q&A is helpful, but there are no guarantees (or likely even consequences) if it’s inaccurate. That’s not true in the Privacy Policy, a legal document that they enter with each user of their service. Because of this, we are far more likely to get an accurate picture.

Here are some salient excerpts (emphasis mine)

Yes, user content is collected

User Content. This consists of all text, documents, or other content or information uploaded, entered, or otherwise transmitted by you in connection with your use of the Services and/or Software. For more information about how we care for and protect your User Content, please see our User Trust Guidelines.

Yes, user content can be accessed and reviewed by humans at Grammarly

As a rule, Grammarly employees do not monitor or view your User Content stored in or transferred through our Site, Software, and/or Services, but it may be viewed if we believe the Terms of Service have been violated and confirmation is required, if we need to do so to respond to your requests for support, if we otherwise determine that we have an obligation to review it as described in the Terms of Service, or to improve our algorithms as described in the User Content section of our Terms of Service

[…]

Finally, your Information may be viewed where necessary to protect the rights, property, or personal safety of Grammarly and its users, or to comply with our legal obligations, such as responding to warrants, court orders, or other legal processes

Data is retained for an undisclosed amount of time even after account deletion

How long is Personal Data retained? You can remove your Personal Data from Grammarly at any time by deleting your account as described above. However, we may keep some of your Personal Data for as long as reasonably necessary for our legitimate business interests, including fraud detection and prevention and to comply with our legal obligations including tax, legal reporting, and auditing obligations.

It’s clear that once Grammarly has its hands-on “User Content,” it stores it, makes it accessible to certain privileged employees, and can share that information with others (like law enforcement) if compelled via legal means. Also, interestingly, since they claim they may need to access “User Content” during support interactions, it heavily implies that this data is associated with your account.

Putting my Corporate Governance cap on, imagine a competitor suing you. They ask the judge to subpoena all available information related to conversations about them and your resulting strategy. Even if you only retain logs/emails for a short period, if the opposing counsel believed a few key employees had Grammarly, they could produce copies of documents (conversations, emails, papers) that were not accessible through any other means. That’s a huge deal.

The Safest Way to Use Grammarly (and Grammarly Alternatives)

There are many ways to use Grammarly, the browser extension, the app, and even a web-based tool. Except for the web-based tool, they all suffer from the same underlying problem, lack of ongoing consent to collect the data they need to perform their service. As a result, any company with users who use Grammarly should react swiftly to educate users about the above risks.

Use the web editor

If users don’t want to lose the benefit, the web editor is your safest bet because they can ensure that the program can’t access any data or content except what the user types or pastes onto the web pages. This method gives you the most control over what the application can record.

Use an open-source alternative

After initial publication of this article, a few folks reached out to me to let me know about a company called LanguageTool. They provide a similar experience to Grammarly, but with one key difference. If you wish, you can run your own server.

In theory, a concerned IT team could setup a server to ensure data isn’t being sent to a third-party and direct their team to make the switch. That said, in practice, the perceived impact of this change on users could be extreme, especially if the quality of the suggestions isn’t as good. Therefore the other alternatives above might be a better compromise.

Is the browser extension any safer?

One commenter on Hackernews suggests:

“This article misses the way I use it, which is much safer. I am security minded but also a terrible writer. I have Grammarly as a browser extension that is OFF BY DEFAULT, except, when I am writing on Medium, and a few times when I click to enable it temporarily. Problem solved! […]”

So while we didn’t do a deep-dive into the extension, this comment piqued my interest. When we looking briefly at the privacy information in the Google Chrome Web Store, we certainly are not off to a promising start.

After installing the extension and viewing its permissions, you can see the following:

While I expected the extension to be able to modify webpages, the need to read my browser history was a surprise. The key question though is, can Grammarly see any web browsing history that Chrome recorded prior to a user activating the extension?

To answer this, I found the extension on my device and looked at the manifest.json file. This file contains a lot of important metadata about the extension, but the section we care about is the permissions array. I have reproduced it below:

  {
    "name": "Grammarly for Chrome",
    "permissions": [
      "http://*/*"
      "https://*/*",
      "tabs", // <--- this is the culprit
      "notifications",
      "cookies",
      "storage"
    ]
  }

As it turns out, the tabs permission is what causes the history access warning. Google’s own documentation clears this up:

…adding the “tabs” permission results in a seemingly unrelated warning: the extension can Read your browsing activity. Although the chrome.tabs API might be used to only open new tabs, it can also be used to see the URL that is associated with every newly opened tab by using their tabs.Tab objects.

So where does this leave us? Essentially, no, Grammarly cannot search your pre-existing browsing history, it only has the permissions to record the history of the pages you are viewing while the extension is activated.

Here’s my take on what this commenter is suggestion; I think if you have the discipline to turn off Grammarly after every use, this is a valid way to get the UX benefits that you really can’t get with the web-editor, while still minimizing the privacy risks. With that said, enabling and disabling an extension can be a real hassle, and I believe it would be just a matter of time before many users forgot to turn it off.

Removing the Grammarly App: Not As Easy As You Might Think

Already took the plunge with the Grammarly app and want to remove it? First, let me direct you to the official support documentation which for macOS states:

1. Click on Finder.
2. Select Applications in the Finder sidebar.
3. Drag the Grammarly app from the Applications folder to the Trash (or Bin).

Unfortunately, if you are running macOS you still aren’t done. When I followed the instructions in the above article, I noticed a major problem; all of the built-in spell checking in macOS was still disabled! I combed through all my settings, but couldn’t find anything to restore the original functionality.

That’s when I found this very helpful blog post.

We get a lot of support requests because, on installation, @Grammarly for Mac kills system spell-checking in all other apps (including iA Writer). Deleting Grammarly won’t restore the spell-checking. You have to manually do it using Terminal.

So to fix the issue I had to open Terminal.app and run…

defaults write -g NSAllowContinuousSpellChecking -bool true

Bingo! After restarting a few of my apps, the original behavior appears to be restored. It makes sense why this feature must be disabled when Grammarly is active, but to not change it back when the user disables or removes the app? That feels like a major oversight for a company that gets so many other UX things right.

Don’t Just Ban Grammarly and Expect Folks To Listen

As I imply as part of my Honest Security guide, banning employees from using tools that can help them do their job better is not an approach that works in practice.

If you ban popular tools like Grammarly, people could be moving their work to personal devices. Then, you’ll have less visibility into what’s happening within your fleet, which can quickly turn into an IT nightmare.

Shedding the security role for a moment, let’s think empathetically. For some, a tool like Grammarly is just a nice-to-have capability that allows them to write more professionally. Still, for others, it’s an essential tool that will enable them to do something they could not do by themselves. Grammarly has a great guest blog article about this by Nelson Lauver, who is diagnosed with dyslexia.

In my twenty-one years as a writer, I have found Grammarly to be the single most valuable tool for making me a better writer. I recognized its benefits instantly.

This is genuine praise that should not go ignored. Imagine what could happen if the IT team blocks access to this essential tool. Now we have an employee who cannot do their job and perhaps feels much less confident communicating. This could be the push they need to start looking for a new job or, worse, drive them to start using a personal laptop without this restriction.

This is why IT leaders in charge of these decisions need to balance employee experience with security when dealing with apps like Grammarly.

The most effective way for keeping untrusted applications from accessing your data is automated blocking software, and there’s plenty to choose from, including Kolide. Kolide gives IT and Security teams the ability to detect Grammarly’s app or browser extension on a device, and prevent that device from authenticating via SSO.

But simple blocking doesn’t really solve the problem, especially for users like Nelson who rely on these tools. Grammarly and tools like it can make a world of difference for users with disabilities, and dismissing these use cases fails to show end-users empathy.

Of course, I’m not saying you should make decisions that compromise security in ways the IT team is uncomfortable with–just that you should have a conversation with users that shows genuine interest in finding a solution that works for all sides.

Involving users in security is one of Kolide’s defining values, and it’s just as important to our product as the ability to block unsecure devices. That’s why every security issue we detect comes with a message for the user. This gives IT teams a chance to explain why a tool like Grammarly is problematic, tell them how to remove it, and offer a reasonable alternative solution. That might mean allowing certain users to be exempt from a blocking policy as long as they commit to using a tool responsibly, or it might mean finding a different tool that accomplishes the same thing.

You can see what our blocking process looks like in action here.

We think this is the most honest and user-first approach to managing the use of potentially practical applications like Grammarly.