3 ms·
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
by 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 agoI'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 agoI 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 agoThe 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 agoI 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 agoI 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 agoI 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 agoDid 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?