Woah. This is serious. Let's triage this as a security vulnerability.

Classifying this as Medium because it requires user interaction (keystroke). I know that's extremely easy to get, so I could see an argument for it being High. Either way, let's get this fixed immediately and merged if possible.

+juberti as FYI.

It's worth noting that this information is public since it was posted on Reddit.

FYI, there is a more general and older bug for mitigations against UX attacks like this: bug 63773

It would be nice to fix the overarching problem on other permission/confirmation dialogs too.

Potentially also of interest: This discussion on GitHub for the Permissions API: https://github.com/w3c/permissions/issues/77#issuecomment-225066518

To clarify my comment #4, the root cause of the problem is that we don't have heuristics to distinguish if a confirmation action on a security UI is a genuine one initiated by the user or accidental. We also don't have anything that prevents accidental clicks / keypresses and ensures the user has seen the UI for a certain amount of time.

 Issue 619437  has been merged into this issue.

+tommi as FYI

How do you want to proceed here?

raymes@ suggested doing a quick fix (maybe by Ben, or me?) of switching the button that is the default target, so that this would only cause people to hit 'Deny'. That would resolve the immediate security issue, and then we can investigate the underlying issue more generally.

juburti: I don't think any immediate action is needed from your team, aside from being aware that it may come up in public discussions before it is fixed because this issue was posted publicly on Reddit.

FYI: The post has been deleted from Reddit (not sure when).

I think benwells is traveling. 

I guess the change to set the default focus target might go in:
chrome/browser/ui/views/website_settings/permissions_bubble_view.cc ?

felt@ do you know how to do this or do we need someone with more views experience (mgiuca may know or we can loop in others).

I have an idea of how to fix it, I'll take a stab at it.

Thanks!

Thanks Adrienne.

I can't repro this on Mac. Can anyone else?

I can't repro it on Linux either (the dialog pops up as you would expect). Can repro on Chrome OS. Changing the OS flags to reflect that.

I also can't repro on Mac. nparker mentioned he couldn't repro on linux either.

felt: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Is it an option to not allow dismissing the dialog via a keyboard shortcut?
(I'm guessing accessibility would be a concern, but this might be an easy thing to do while a proper fix is being implemented)

felt: Uh oh! This issue still open and hasn't been updated in the last 29 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

felt@: any update on this?

Ping :)

felt- I'm happy to look at this. Let me know if you don't want me to, otherwise I'll try and get a fix up this afternoon.

Note: I can't repro this on Windows 8, in dev or in ToT. It could just be timing dependent. Regardless I think it is a problem and the fix is very simple.

I think a better fix than switching the default button to Deny is to just remove the default button entirely.

Thanks for picking this up Ben!

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/914c24f03eafaf4043867923166e6dc78f41437f

commit 914c24f03eafaf4043867923166e6dc78f41437f
Author: benwells <benwells@chromium.org>
Date: Fri Aug 05 06:32:40 2016

Remove default action in permission bubbles

This prevents accidental acceptance of permissions, and also works around websites timing permission requests in a way to always get the permission.

BUG= 619429 

Review-Url: https://codereview.chromium.org/2206903002
Cr-Commit-Position: refs/heads/master@{#410004}

[modify] https://crrev.com/914c24f03eafaf4043867923166e6dc78f41437f/chrome/browser/ui/views/website_settings/permission_prompt_impl.cc

The default action has been removed. The dialog is still accessible as you can use tab to move the focus.

I think this is enough. If someone thinks we should do more, please reopen.

 Issue 640624  has been merged into this issue.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Security>UX component is deprecated in favor of the Team-Security-UX label