Chrome Can Be Used to Listen In on Everything Happening Around Your Computer

Updated October 2026: This post has been expanded from its original January 2014 version from a one-line link into a full account of Tal Ater’s Chrome speech-recognition disclosure, Google’s response, and how to check which websites and apps can use your microphone today. It is a historical account; details describe the time it covers, not today.

Close-up of the built-in microphone holes on a laptop bezel

In January 2014, an Israeli web developer named Tal Ater published a blog post with an unsettling title: Chrome is listening. He had found a way for a malicious website to keep using a computer’s microphone through Google Chrome’s speech-recognition feature long after the visitor thought the site had stopped listening. This blog shared the link at the time with a one-sentence summary.

This expanded version explains what Ater found, how the attack worked, why Google initially declined to treat it as a security flaw, and what has changed since. It ends with practical steps you can take today to see which websites and apps have access to your microphone and to switch that access off.

Background: speech recognition comes to the browser

Chrome 25, released to the stable channel in February 2013, added support for the Web Speech API. This JavaScript interface lets a web page ask the browser to turn speech into text, so a site could accept voice commands or dictation without any plugins. It was an exciting feature for developers, and Ater was one of them: he was building annyang, a small open-source library that made it easy to add voice commands to a website.

Because speech recognition needs the microphone, Chrome asked the user for permission before a site could start listening, and showed an indicator while it was active. For sites served over HTTPS, Chrome remembered that permission, so a returning visitor would not be asked again every time. That convenience turned out to be part of the problem.

What Ater found

While working on annyang, Ater noticed that he could chain together several separate Chrome bugs into one exploit. The scenario he described went like this:

A visitor goes to a site that legitimately offers voice control and grants it microphone permission. Because the site uses HTTPS, Chrome remembers that decision.
Behind the scenes, the site opens a hidden pop-under window, which could be disguised as an ordinary banner ad.
The visitor finishes, turns off voice control or closes the main tab, and sees the listening indicator disappear.
The pop-under, still open behind other windows, starts speech recognition on its own. Chrome showed its recording indicator in regular tabs, but not for pop-under windows, and it did not ask for permission again.
Anything said near the computer could then be transcribed and sent back to the site’s operator for as long as the hidden window stayed open.

Ater stressed that HTTPS only proved a site had a valid certificate, not that the site was trustworthy. He published a demonstration video and released the exploit’s source code on GitHub so others could verify the problem.

The disclosure timeline

Ater followed responsible-disclosure practice: he reported the issue privately first and waited months before going public. According to his own account, Google’s engineers acted quickly on the technical side.

Chrome speech-recognition disclosure, 2013–2014

February 2013
Chrome 25 ships with Web Speech API support.
September 13, 2013
Tal Ater privately reports the exploit to Google’s security team.
September 19, 2013
Google engineers identify the bugs and suggest fixes.
September 24, 2013
A patch is ready.
September 27, 2013
The report is nominated for Chromium’s security reward panel.
Late October 2013
Ater asks why the fix has not shipped; Google says the matter is still under discussion with the standards group.
January 22–23, 2014
Ater publishes his findings, video, and code; tech press picks up the story.
January 23–24, 2014
Google says the feature is not an immediate threat and complies with the W3C specification.

Sources: Tal Ater, “Chrome is listening”; Dark Reading; The Hacker News; Security Affairs; Phoronix.

The patch was ready within about eleven days of the report. What it did not do was ship. When Ater followed up roughly six weeks after his report, Google told him the fix was waiting on a discussion within the standards group about how the feature should behave, and that "Nothing is decided yet." After nearly four months, he went public.

Google’s response

After the story spread, a Google spokesperson said the company had re-investigated and still did not consider it an immediate threat. Google’s reasoning was that a user must first enable speech recognition for each site that requests it, so a site cannot listen without having been granted permission at some point. The spokesperson also said Chrome’s implementation complied with the current W3C specification and that Google would keep working on improvements. Dark Reading reported that Google considered the issue ineligible for a bug bounty.

Ater and others pushed back. The Web Speech API was not yet a finished W3C standard at the time, so pointing to the specification did not settle the question. And the core concern was not whether permission had ever been granted, but whether users could reasonably understand that a site might keep listening after its tab was gone. An unnamed security source quoted by Dark Reading countered that newer versions of Chrome already showed a microphone indicator in pop-up windows and did not allow hidden pop-ups, which may have limited the attack in practice.

What happened next

The 2014 episode became an early example of a debate that has continued ever since: how browsers should communicate when a website is using your camera or microphone, and how long a permission should last.

A similar argument in 2017

In May 2017, web developer Ran Bar-Zik reported a related issue. Once a site had camera and microphone permission, its JavaScript could record using the MediaRecorder API from a context that did not show Chrome’s red recording dot, such as a pop-up window. Google again said it did not consider this a true security vulnerability. It described the recording indicator as a best-effort signal that appears on desktop when there is room in the interface, and said the permission prompt itself was the real protection.

Operating systems added their own indicators

The larger change came from the operating systems underneath the browser. Apple added a microphone privacy indicator to the Mac with macOS Monterey: an orange dot appears in the menu bar when an app is using the microphone, and opening Control Center shows which app it is. Windows 11 gives each app its own microphone permission under Settings. These indicators work regardless of which browser or app is doing the listening.

Permissions that expire

Chrome itself has also moved away from the "remember forever" model that made Ater’s attack possible. Starting with Chrome 116 in 2023, desktop users asked for camera, microphone, or location access can choose Allow this time. A one-time grant ends when all of the site’s pages are closed, after the site has been in the background for five minutes (counted from when the camera or microphone stops), or after 16 hours at most. Google’s help pages also note that a site can only start recording while you are on it, not while you are in another tab or app.

How to check your microphone permissions today

It takes a few minutes to review which sites and apps can use your microphone. Menu names change between versions, so the paths below reflect current documentation from Google, Apple, and Microsoft.

Where	Path	What to do
Chrome (desktop)	Three-dot menu > Settings > Privacy and security > Site settings > Microphone	Set the default, review allowed and blocked sites, and remove any you no longer use.
Mac	Apple menu > System Settings > Privacy & Security > Microphone	Turn off access for apps that do not need it, including browsers you rarely use.
Windows 11	Start > Settings > Privacy & security > Microphone	Control overall access, app access, and desktop app access.

Paths from Google Chrome Help, Apple Mac User Guide, and Microsoft Support.

Good habits

Use "Allow this time" when it is offered. For a one-off video call or voice search, a temporary permission is usually all you need.
Choose "Never allow" for sites that have no reason to hear you. A news site or online store rarely needs a microphone.
Watch for indicators. On a Mac, an orange dot in the menu bar means something is using the microphone; open Control Center to see what.
Close windows you do not recognize. Ater’s attack depended on a hidden window. If an unexpected pop-up or pop-under appears, close it.
Keep your browser updated. Many permission and indicator fixes arrive through ordinary browser updates.
Review permissions occasionally. Sites you allowed years ago may still be on the list.

The bottom line

Tal Ater’s 2014 disclosure did not prove that anyone was being secretly recorded, and Google was right that a site needed the user’s permission first. But it showed how a remembered permission, a hidden window, and a missing indicator could combine into something users would not expect. Browsers and operating systems have since added one-time permissions and system-level microphone indicators that make that kind of quiet listening much harder to hide. The simplest protection is still the oldest one: grant the microphone sparingly and check the list now and then.

Sources

Top image: "Laptop Microphone Array" by Zvsmedia, CC BY-SA 4.0, via Wikimedia Commons (resized). Charts by Thank You Robot.

Chrome Can Be Used to Listen In on Everything Happening Around Your Computer

Background: speech recognition comes to the browser

What Ater found

The disclosure timeline

Google’s response