https://www.kolide.com/blog/is-grammarly-a-keylogger-what-can-you-do-about-it

[kolide-log] [hamburger-]
Product
[house-208f] Home [credit-car] Pricing [slack-d949] Slack App 
[gold-lock-] Security
Resources
Blog Help Center Changelog Honest.Security Company Terms of Use
Talk To Sales Try Kolide Free Sign In
[kolide-log] Product Pricing Company Resources Talk To Sales Try For
Free Sign In
[self-remed]
Self Remediation
Engage end-users on Slack to self-remediation issues
[endpoint-m]
Endpoint Monitoring
Monitor your entire Linux, Mac, and Windows fleet
[honest-sec]
Honest Security
Device management that doesn't erode your values
[compliance]
Compliance
Measure, achieve, and maintain your compliance goals
[fleet-visi]
Fleet Visibility
Gain visbility across Linux, Mac, and Windows devices
[service-de]
Service Desk
Real-time insight to quickly profile service desk issues
Help Center Changelog Security What is Honest Security?
From the blog

     
  * [blog-new-b]
    Is Grammarly a Keylogger? What Can You Do About It?
     
  * [blog-top-b]
    Is Grammarly a Keylogger? What Can You Do About It?
     
  * [blog-hot-b]
    Announcing Kolide's $17MM Series B

Blog

All Engineering Inside Kolide Tutorials Deep Dives Perspectives News
Categories

Categories

All Engineering Inside Kolide Tutorials Deep Dives Perspectives News
[cover]
[twitter-3e] [linkedin-a] [hacker-new] [reddit-e95] [url-link-a]

Contents

Kolide
Endpoint Security for Teams that Slack
Try Kolide
 
Perspectives

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

[jason-mell]
Jason Meller

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, every. single. bit. of. text. you want
improved 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

A graphic that displays Grammarly's apps.

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:

A screenshot of the installation screen for the macOS version of the
Grammarly app. The screenshot asks the user to add Grammarly to the
list of apps with accessibility permissions and offers a button to
kick off that process.

And then helpfully pops up the following screen:

A screenshot of the System Preferences app showing the Security pane.
On the bottom of the app Grammarly has anchored its own window with
arrows that direct the user to unlock the pane and check the box next
to Grammarly which will instantly grant it the accessibility
permissions.

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:

 1. Capturing all of the text inside any application used by the
    user.
 2. Capturing new keystrokes entered into any other app.
 3. Augmenting/Manipulating the UI of other apps 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.

The Notes.app with various grammatically incorrect sentences.

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

The same Notes.app with the various grammatically incorrect sentences
now with the Grammarly widget activated and the text marked up by
Grammarly.

Grammarly processes text that was already entered in the window

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:

A cropped screenshot of a form-field that shows a social security
number entered into a text-area with the Grammarly widget active.

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)

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.

---------------------------------------------------------------------

User Content Can Be Accessed And Reviewed By Humans For Many Reasons

    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

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.

A screenshot of Grammarly's web-based word processor.

The web-editor is the safest bet because you can control what is
entered.

As a result, any company with users who use Grammarly should react
swiftly to educate users about the above risks. 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.

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 think in
shades of gray. Instead of using automated blocking software to
enforce these decisions (and falling into the Security Obstructionism
trap), we need to find a way to have conversations with end-users
about these policies. We should allow them to provide input back to
us and find compromises so that people like Nelson can have access to
the valuable parts of the tools they rely on.

Grammarly and tools like it can make a world of difference for users
with disabilities. Dismissing these uses cases means failing to show
end-users empathy. This doesn't mean making decisions that compromise
security in a way the IT team is uncomfortable with--instead having a
conversation with users that shows genuine interest in finding a
solution that works for all sides.

This is one of the reasons we built Kolide for IT teams to message
end-users directly on Slack. This allows IT teams to communicate to
an end-user running a tool like Grammarly why it may be an issue,
tell them how to remove it, and more importantly, offer a reasonable
alternative solution so they can still enjoy a significant portion of
the benefits.

A screenshot of Slack showing a message about Grammarly sent to an
end-user.

We think this is a much better, honest, and user-first approach than
barring the use of a potentially practical application like
Grammarly.

Share this story:

[twitter-3e] [linkedin-a] [hacker-new] [reddit-e95] [url-link-a]

More articles you
might enjoy:

 
News
Honest Security: One Year Later
December 8, 2021
 
Perspectives
What You Do Is Who You Are
Harry Robinson
 
Perspectives
Three Myths About Honest Security
Jason Meller
[kolide-whi] Try Kolide Free
[kolide-whi]
Endpoint Security
Powered By People
Try Kolide Free
[closing-ct]
[kolide-log]
   

Product

Home Pricing Slack App

Community

Blog Open-Source Slack Channel

Resources

Help Center App Security Changelog Honest.Security

Company

About Us Careers Press Contact
[gdpr-04554] [soc-logo-8]
(c) Copyright 2022 Kolide, Inc. All Rights Reserved.
Sign In Privacy Policy Terms