A bug in Google Chrome could let a site take over the mic and secretly listen to users.[/caption]
Update:While acknowledging the bug exists, Google spokespeople minimized its potential impact, but didn't address when or if the bug would be fixed.
"We've reinvestigated and still believe there is no immediate threat, since a user must first enable speech recognition for each site that requests it," according to a statement Google circulated late Jan. 22.
"The security of our users is a top priority, and this feature was designed with security and privacy in mind," the statement said. "The feature is in compliance with the current W3C standard, and we continue to work on improvements." Google's Chrome Web browser has a bug that would allow a malicious site to take control of a live microphone and listen to whatever happens on the other end of a Web connection, according to an Israeli researcher who just posted source code exploiting the flaw. Tal Ater, a Web-interface usability specialist whose previous efforts include making Facebook less promiscuous and an effort at crowdfunding charities by green-seeding Websites so any purchase on them will net a donation to environmental causes, didn't post the eavesdropping bug to promote the exploit. Ater discovered the bug while working on a Java library site owners could install to let users control the site by voice, and reported it to Google Sept. 13, 2013, Ater wrote in a blog describing the problem. Eleven days after he reported it, Google engineers had a fix ready; three days later Google nominated him for a bug-finder reward. But four months later, the Google Standards committees have still not decided what to do with the fix, or rolled it out in current versions of Chrome. "By the way," Ater wrote about his frustration at the delay, "the web's standards organization, the W3C has already defined the correct behavior which would've prevented this… in their specification for the Web Speech API back in October 2012." The bug itself is simple: when a user visits a malicious site, the site can use any trick to get the user to turn on a microphone and give Chrome the control – which is exactly what would happen on a site like Ater's, which demonstrates simple voice control of Web functions. Most sites using voice recognition also rely on HTTPS to encrypt the connection and make it more secure, Ater said. Chrome hangs onto the HTTPS certificates after the user leaves the site, however, and remembers that the user gave the site permission to control the microphone, so the site doesn't have to ask for permission next time the same user visits. If the site is more malicious than clever, it can launch a pop-under window that stays hidden and live after the main windows close. The pop-under window inherits the right to control the mic, allowing anyone at the malicious site to keep listening even after the mic is seemingly turned off. "To make matters worse, even if you do notice that window (which can be disguised as a common banner), Chrome does not show any visual indication that Speech Recognition is turned on in such windows - only in regular Chrome tabs," Ater wrote. Just to reinforce the point that the bug exists, that Google has it and that Chrome needs to be fixed, Ater posted code for it along with a video demonstration on GitHub. Image: Shutterstock.com/ Leifstiller Chrome Bug Lets Web Eavesdrop on Users
[caption id="attachment_16492" align="aligncenter" width="500"] A bug in Google Chrome could let a site take over the mic and secretly listen to users.[/caption]
Update:While acknowledging the bug exists, Google spokespeople minimized its potential impact, but didn't address when or if the bug would be fixed.
"We've reinvestigated and still believe there is no immediate threat, since a user must first enable speech recognition for each site that requests it," according to a statement Google circulated late Jan. 22.
"The security of our users is a top priority, and this feature was designed with security and privacy in mind," the statement said. "The feature is in compliance with the current W3C standard, and we continue to work on improvements." Google's Chrome Web browser has a bug that would allow a malicious site to take control of a live microphone and listen to whatever happens on the other end of a Web connection, according to an Israeli researcher who just posted source code exploiting the flaw. Tal Ater, a Web-interface usability specialist whose previous efforts include making Facebook less promiscuous and an effort at crowdfunding charities by green-seeding Websites so any purchase on them will net a donation to environmental causes, didn't post the eavesdropping bug to promote the exploit. Ater discovered the bug while working on a Java library site owners could install to let users control the site by voice, and reported it to Google Sept. 13, 2013, Ater wrote in a blog describing the problem. Eleven days after he reported it, Google engineers had a fix ready; three days later Google nominated him for a bug-finder reward. But four months later, the Google Standards committees have still not decided what to do with the fix, or rolled it out in current versions of Chrome. "By the way," Ater wrote about his frustration at the delay, "the web's standards organization, the W3C has already defined the correct behavior which would've prevented this… in their specification for the Web Speech API back in October 2012." The bug itself is simple: when a user visits a malicious site, the site can use any trick to get the user to turn on a microphone and give Chrome the control – which is exactly what would happen on a site like Ater's, which demonstrates simple voice control of Web functions. Most sites using voice recognition also rely on HTTPS to encrypt the connection and make it more secure, Ater said. Chrome hangs onto the HTTPS certificates after the user leaves the site, however, and remembers that the user gave the site permission to control the microphone, so the site doesn't have to ask for permission next time the same user visits. If the site is more malicious than clever, it can launch a pop-under window that stays hidden and live after the main windows close. The pop-under window inherits the right to control the mic, allowing anyone at the malicious site to keep listening even after the mic is seemingly turned off. "To make matters worse, even if you do notice that window (which can be disguised as a common banner), Chrome does not show any visual indication that Speech Recognition is turned on in such windows - only in regular Chrome tabs," Ater wrote. Just to reinforce the point that the bug exists, that Google has it and that Chrome needs to be fixed, Ater posted code for it along with a video demonstration on GitHub. Image: Shutterstock.com/ Leifstiller
A bug in Google Chrome could let a site take over the mic and secretly listen to users.[/caption]
Update:While acknowledging the bug exists, Google spokespeople minimized its potential impact, but didn't address when or if the bug would be fixed.
"We've reinvestigated and still believe there is no immediate threat, since a user must first enable speech recognition for each site that requests it," according to a statement Google circulated late Jan. 22.
"The security of our users is a top priority, and this feature was designed with security and privacy in mind," the statement said. "The feature is in compliance with the current W3C standard, and we continue to work on improvements." Google's Chrome Web browser has a bug that would allow a malicious site to take control of a live microphone and listen to whatever happens on the other end of a Web connection, according to an Israeli researcher who just posted source code exploiting the flaw. Tal Ater, a Web-interface usability specialist whose previous efforts include making Facebook less promiscuous and an effort at crowdfunding charities by green-seeding Websites so any purchase on them will net a donation to environmental causes, didn't post the eavesdropping bug to promote the exploit. Ater discovered the bug while working on a Java library site owners could install to let users control the site by voice, and reported it to Google Sept. 13, 2013, Ater wrote in a blog describing the problem. Eleven days after he reported it, Google engineers had a fix ready; three days later Google nominated him for a bug-finder reward. But four months later, the Google Standards committees have still not decided what to do with the fix, or rolled it out in current versions of Chrome. "By the way," Ater wrote about his frustration at the delay, "the web's standards organization, the W3C has already defined the correct behavior which would've prevented this… in their specification for the Web Speech API back in October 2012." The bug itself is simple: when a user visits a malicious site, the site can use any trick to get the user to turn on a microphone and give Chrome the control – which is exactly what would happen on a site like Ater's, which demonstrates simple voice control of Web functions. Most sites using voice recognition also rely on HTTPS to encrypt the connection and make it more secure, Ater said. Chrome hangs onto the HTTPS certificates after the user leaves the site, however, and remembers that the user gave the site permission to control the microphone, so the site doesn't have to ask for permission next time the same user visits. If the site is more malicious than clever, it can launch a pop-under window that stays hidden and live after the main windows close. The pop-under window inherits the right to control the mic, allowing anyone at the malicious site to keep listening even after the mic is seemingly turned off. "To make matters worse, even if you do notice that window (which can be disguised as a common banner), Chrome does not show any visual indication that Speech Recognition is turned on in such windows - only in regular Chrome tabs," Ater wrote. Just to reinforce the point that the bug exists, that Google has it and that Chrome needs to be fixed, Ater posted code for it along with a video demonstration on GitHub. Image: Shutterstock.com/ Leifstiller 
