8 ms·

Chrome Bugs Allow Sites to Listen to Your Private Conversations

138 points by lelf 13y ago

fem 13y ago
His demonstration video is suspect: he hides a popup of the same domain authorized to access the mic behind the main chrome window, which is convenient because in real life popup windows usually appear in the foreground and are quite noticeable, if they weren't blocked by chrome’s popup blocker all together. He is misrepresenting his personal disagreements about UI/UX decisions as exploits or bugs in chrome which is disingenuous, especially as he edits his video to hide the safeguards (mainly the popup blocker). Also the speech API does not send audio to authorized site only machine transcription of the audio which is not as pertinent, which also speaks to the misrepresentation of the author.
- poopsintub 13y ago
  I've experienced pop-ups occurring that go behind. It's not like you don't notice it or anything though. Should this be considered a chrome security flaw? You did, after-all, grant privileges to that site. Revoke and report the site?
  - fem 13y ago
    I don't think it's a flaw, as the UI evolves with the specs this hypothetical might be eliminated. But since as you mention the user would first have to grant permission, and the option to revoke is available "revoke and report" is the best course of action, I doubt Google SafeSearch would even let you land on said hypothetical malicious site.
  - freshchilled 13y ago
    The problem is that you don't expect a pop-under to continue collecting information from you, especially when you intended to close the connection!
  - sil3ntmac 13y ago
    I would say yes. Pop-unders should be blocked, and modern browsers work pretty hard to, but it is often viewed as a "low priority" sec issue, and so workarounds are found, ignored, used in the wild, and patched. Here is one implementation, I have seen working versions up to Chrome ~30: https://github.com/tuki/js-popunder https://github.com/tuki/js-popunder Another serious security issue is when the popunder waits for a while as the parent frame navigates itself to e.g. "java.com", then the child navigates the parent to a malicious drive-by download. This can make it appear to "spoof" a drive-by download. This attack vector has been known and ignored forever (I think Zalewski published about this years back). IE9 and 10 actually do a good job preventing this, but I know it works in most modern browsers.
- alternize 13y ago
  I find it quite reasonable to expect that all window belonging to the same domain would stop listening to speech once the user indicates she wants recognition to stop. the main window, which started the speech recognition, indicated that the listening stopped, yet it continued on a spawned window. is it a bug? not sure. but it definitely could lead to some bad UX, even if the window isn't spawned as a fishy popunder.
  - taf2 13y ago
    I sure hope it's not a bug, I can imagine real world applications where this feature would be useful. There are two obvious issues here. 1. the video presented this in a very biased light the popup was already open and behind as the main window. 2. chrome should provide an indicator in a more global way to indicate a recording is taking place... additionally, just like the camera on your computer lights up when it's on, it would make sense for your computer to have a similar light indicator for when the mic is on?
- acqq 13y ago
  Did you see the same video as I? The current implementation is obviously very wrong. You press the button to stop the listening and the listening continues(!) and the browser doesn't even give any visual cue that it's still listening. It's the Google answer that is suspect: 'there was an ongoing discussion within the Standards group, to agree on the correct behaviour - "Nothing is decided yet."' What, what?
uptown 13y ago
If you're interested in blocking microphone access, you should be able to do so using this user-script: http://userscripts.org/scripts/show/110566 http://userscripts.org/scripts/show/110566 And TamperMonkey to enable the script: https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo?hl=en https://chrome.google.com/webstore/detail/tampermonkey/dhdgf...
- deleted 13y ago
  [deleted]
- magicalist 13y ago
  You can just go to settings and search for "Microphone" (or look in "content settings"), then switch it from "Ask me" to "Do not allow".
  - rdudek 13y ago
    ^ This! No need for 3rd party scripts to do the same, especially all the fiasco going around with adware folks getting into extensions.
nthj 13y ago
tl;dr: When you explicitly grant a website access to your microphone, the site may keep listening in a popunder window after you close the original tab.
- yincrash 13y ago
  without any visual cue that it is listening, while normal chrome tabs show a visual cue.
  - nthj 13y ago
    Fair enough. When I saw the title I first thought any random website could start silently listening, NSA-style—the real story isn't nearly that crazy.
    - coldtea 13y ago
      Well, given how Chrome's "implementation" works, all it takes is a Chrome exploit for that to happen too...
  - Sidnicious 13y ago
    That's not true, a camera icon is in the address bar in the popup — though it's not obvious.
- elwell 13y ago
  "When you explicitly grant a website access to your microphone" is the key though
Spone 13y ago
NSA backdoor uncovered!
- deleted 13y ago
  [deleted]
program 13y ago
Let's read the spec: https://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi.html#security https://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi.htm... "To minimize the chance of users unwittingly allowing web pages to record speech without their knowledge, implementations must abort an active speech input session if the web page lost input focus to another window or to another tab within the same user agent." Given this the actual Chrome implementation is wrong.
- falcolas 13y ago
  Hmm. Thinking about how I use google hangouts, this "standardized" behavior would actually make hangouts virtually useless. For example, I would be unable to share my screen in any meaningful fashion, or hold a conversation while multitasking (I program as part of a distributed team, so I do both frequently). I'm not entirely sure this spec creates a useful environment for webapp developers; in fact this limitation would encourage non-standardized implementations so they could actually be used by normal people. Interesting to think about, either way.
  - robert-wallis 13y ago
    Maybe there should be a secondary option to allow a site to use the mic in the background.
  - kelnos 13y ago
    We're talking about the Speech API here, which isn't something an app like Hangouts would use. WebRTC, which is more suitable, does not have that restriction codified into its spec.
  - magicalist 13y ago
    I agree with you, though the speech to text API is different than just microphone access. Something like video conferencing may not fall under the same rules. One interesting thing is that web specs don't usually go into that much detail about UI, or at least that used to be the case. It was generally considered outside of the spec's purview, and it boxes in future browser interfaces that could be something very different than tabs and windows. If you needed something, I would think something like there must be a visible notice to the user that their sound is being recorded, and if that notice becomes obscured, cease recording. But I'm not entirely sure it should be enforced on the spec level; instead it could have a non-normative security section and leave it up to the browsers to implement it well.
pasbesoin 13y ago
Progressions: Browser --> Sandbox (within browser) --> "Operating system" (within browser) Pages --> (Dynamic) Ads, "tracking", "web apps" --> Pervasive, intrusive monitoring via exploitation If you are going to turn your browser into an operating system, you'd better get the security right -- and spend some time reflecting on the ongoing Java fiasco. And maybe stop calling it a "browser" -- unless you mean that I'm now the one being browsed.
Sven7 13y ago
Unrelated but anyone know when the Speech API gets into other browsers? Is Mozilla going to be hosting recognition servers?
taivare 13y ago
I hear Google is coming out with 'Goggles' they record your surroundings in both audio and video.
ndesaulniers 13y ago
bug, or feature? nudge nudge, wink wink.

138 points by lelf 13y ago

fem 13y ago

His demonstration video is suspect: he hides a popup of the same domain authorized to access the mic behind the main chrome window, which is convenient because in real life popup windows usually appear in the foreground and are quite noticeable, if they weren't blocked by chrome’s popup blocker all together. He is misrepresenting his personal disagreements about UI/UX decisions as exploits or bugs in chrome which is disingenuous, especially as he edits his video to hide the safeguards (mainly the popup blocker). Also the speech API does not send audio to authorized site only machine transcription of the audio which is not as pertinent, which also speaks to the misrepresentation of the author.

poopsintub 13y ago
I've experienced pop-ups occurring that go behind. It's not like you don't notice it or anything though. Should this be considered a chrome security flaw? You did, after-all, grant privileges to that site. Revoke and report the site?
- fem 13y ago
  I don't think it's a flaw, as the UI evolves with the specs this hypothetical might be eliminated. But since as you mention the user would first have to grant permission, and the option to revoke is available "revoke and report" is the best course of action, I doubt Google SafeSearch would even let you land on said hypothetical malicious site.
- freshchilled 13y ago
  The problem is that you don't expect a pop-under to continue collecting information from you, especially when you intended to close the connection!
- sil3ntmac 13y ago
  I would say yes. Pop-unders should be blocked, and modern browsers work pretty hard to, but it is often viewed as a "low priority" sec issue, and so workarounds are found, ignored, used in the wild, and patched. Here is one implementation, I have seen working versions up to Chrome ~30: https://github.com/tuki/js-popunder https://github.com/tuki/js-popunder Another serious security issue is when the popunder waits for a while as the parent frame navigates itself to e.g. "java.com", then the child navigates the parent to a malicious drive-by download. This can make it appear to "spoof" a drive-by download. This attack vector has been known and ignored forever (I think Zalewski published about this years back). IE9 and 10 actually do a good job preventing this, but I know it works in most modern browsers.
alternize 13y ago
I find it quite reasonable to expect that all window belonging to the same domain would stop listening to speech once the user indicates she wants recognition to stop. the main window, which started the speech recognition, indicated that the listening stopped, yet it continued on a spawned window. is it a bug? not sure. but it definitely could lead to some bad UX, even if the window isn't spawned as a fishy popunder.
- taf2 13y ago
  I sure hope it's not a bug, I can imagine real world applications where this feature would be useful. There are two obvious issues here. 1. the video presented this in a very biased light the popup was already open and behind as the main window. 2. chrome should provide an indicator in a more global way to indicate a recording is taking place... additionally, just like the camera on your computer lights up when it's on, it would make sense for your computer to have a similar light indicator for when the mic is on?
acqq 13y ago
Did you see the same video as I? The current implementation is obviously very wrong. You press the button to stop the listening and the listening continues(!) and the browser doesn't even give any visual cue that it's still listening. It's the Google answer that is suspect: 'there was an ongoing discussion within the Standards group, to agree on the correct behaviour - "Nothing is decided yet."' What, what?

uptown 13y ago

If you're interested in blocking microphone access, you should be able to do so using this user-script: http://userscripts.org/scripts/show/110566 http://userscripts.org/scripts/show/110566 And TamperMonkey to enable the script: https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo?hl=en https://chrome.google.com/webstore/detail/tampermonkey/dhdgf...

deleted 13y ago
[deleted]
magicalist 13y ago
You can just go to settings and search for "Microphone" (or look in "content settings"), then switch it from "Ask me" to "Do not allow".
- rdudek 13y ago
  ^ This! No need for 3rd party scripts to do the same, especially all the fiasco going around with adware folks getting into extensions.

nthj 13y ago

tl;dr: When you explicitly grant a website access to your microphone, the site may keep listening in a popunder window after you close the original tab.

yincrash 13y ago
without any visual cue that it is listening, while normal chrome tabs show a visual cue.
- nthj 13y ago
  Fair enough. When I saw the title I first thought any random website could start silently listening, NSA-style—the real story isn't nearly that crazy.
  - coldtea 13y ago
    Well, given how Chrome's "implementation" works, all it takes is a Chrome exploit for that to happen too...
- Sidnicious 13y ago
  That's not true, a camera icon is in the address bar in the popup — though it's not obvious.
elwell 13y ago
"When you explicitly grant a website access to your microphone" is the key though

Spone 13y ago

NSA backdoor uncovered!

deleted 13y ago
[deleted]

program 13y ago

Let's read the spec: https://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi.html#security https://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi.htm... "To minimize the chance of users unwittingly allowing web pages to record speech without their knowledge, implementations must abort an active speech input session if the web page lost input focus to another window or to another tab within the same user agent." Given this the actual Chrome implementation is wrong.

falcolas 13y ago
Hmm. Thinking about how I use google hangouts, this "standardized" behavior would actually make hangouts virtually useless. For example, I would be unable to share my screen in any meaningful fashion, or hold a conversation while multitasking (I program as part of a distributed team, so I do both frequently). I'm not entirely sure this spec creates a useful environment for webapp developers; in fact this limitation would encourage non-standardized implementations so they could actually be used by normal people. Interesting to think about, either way.
- robert-wallis 13y ago
  Maybe there should be a secondary option to allow a site to use the mic in the background.
- kelnos 13y ago
  We're talking about the Speech API here, which isn't something an app like Hangouts would use. WebRTC, which is more suitable, does not have that restriction codified into its spec.
- magicalist 13y ago
  I agree with you, though the speech to text API is different than just microphone access. Something like video conferencing may not fall under the same rules. One interesting thing is that web specs don't usually go into that much detail about UI, or at least that used to be the case. It was generally considered outside of the spec's purview, and it boxes in future browser interfaces that could be something very different than tabs and windows. If you needed something, I would think something like there must be a visible notice to the user that their sound is being recorded, and if that notice becomes obscured, cease recording. But I'm not entirely sure it should be enforced on the spec level; instead it could have a non-normative security section and leave it up to the browsers to implement it well.

pasbesoin 13y ago

Progressions: Browser --> Sandbox (within browser) --> "Operating system" (within browser) Pages --> (Dynamic) Ads, "tracking", "web apps" --> Pervasive, intrusive monitoring via exploitation If you are going to turn your browser into an operating system, you'd better get the security right -- and spend some time reflecting on the ongoing Java fiasco. And maybe stop calling it a "browser" -- unless you mean that I'm now the one being browsed.

Sven7 13y ago

Unrelated but anyone know when the Speech API gets into other browsers? Is Mozilla going to be hosting recognition servers?

taivare 13y ago

I hear Google is coming out with 'Goggles' they record your surroundings in both audio and video.

ndesaulniers 13y ago

bug, or feature? nudge nudge, wink wink.