Devlin: Mostly a duplicate of bug 394518, but handing over to you to decide about delaying for the first time vs every time.

I thought bug 394518 had already been fixed given I reported  bug 544573  (which was marked as duplicate) and later on the delay was added and my duplicate made public.

Despite the allpublic label,  bug 544573  isn't public yet because of the Restrict-View-SecurityTeam. Is that what you meant?

Yeah, sorry. Got confused by it.

No problem. Not sure why we allpublic was added in the first place to that bug.

Why is issue 394518 Low severity? Being able to trick people into installing extensions is quite bad?

https://codereview.chromium.org/2716353003 landed and is in 59.0.3064.0 onwards, so can you re-test on dev channel and tell us whether you think this 500ms is enough mitigation?

#9 - I tested on 69.0.3461.0 and still was able to reproduce the attack described in #0. It seems the delay is only being applied once (when the inline dialog is invoked) instead of being applied every time the dialog loses and regains focus.

Correct - the delay only applies on first instance.

That said, the idea that our security and privacy dialogs should react to refocusing, resurfacing, etc was reported back in 2010 (7.5 years ago) in issue 63773 (which is fully public).  I'm not sure this describes anything different than the combination of that and issue 394518.

Additionally, inline installation is now publicly deprecated [1].

I'm not sure there's much to do here that isn't described in existing bugs (with the remaining work primarily dupe-able into issue 63773).

wfh@, meacer@, palmer@: any objections to duping into that issue?

[1] https://blog.chromium.org/2018/06/improving-extension-transparency-for.html

#12 wasn't directed at me but I want to share things from my perspective:

Around July 2014, bug 394518 was filled about the possibility of clickjacking on the inline extension dialog. On Oct 18 2015, I filled  bug 544573  about the same issue, in which meacer@ duped into bug 394518 and said he would propose a fix to it.

On Apr 05 2017, 1 year and 5 months after my report being duped, a fix was merged that added a delay only on the first instance of the dialog.

On Jun 04 2018 (1 year and 2 months after the fix), I noticed that the delay was added, but that it was still possible to perform clickjacking using a popup and then decided to submit this bug.

So my question is:
Would you have added the delay every time the dialog loses and regains focus if I hadn't reported this issue? If so, why wasn't that done when the first fix was implemented?

It seems a bit unfair to me to leave a catch-all report from years back open, which isn't being actively looked over and has no prospect of being resolved, and then go around fixing concrete security issues relating to that only when an external reporter outlines a specific case of attack.

What do you guys think?

The NextAction date has arrived: 2018-06-18

A few clarifications:

> Would you have added the delay every time the dialog loses and regains focus if I hadn't reported this issue? If so, why wasn't that done when the first fix was implemented?

We have not added any such mechanism, and, to be clear, my recommendation here is that we not do so in an ad-hoc manner for the inline install dialog (given inline install is deprecated).  Additionally, the origin bug from 2010 outlined this exact approach:

> * Disable download items' buttons for the first one second of their existence
> * Disable download items' buttons for the first one second after the hosting Chrome window regains focus
> * Modify the second item above to only occur if the window losing focus was a Chrome window, and only for buttons at least partly overlapped by that Chrome window

(Note that the original report there was just for download items, but was later applied to all security/privacy related UI.)

I think that we *should* fix this for all security/privacy dialogs, even though the inline installation one won't be the driving force since it's going away soon.

> It seems a bit unfair to me to leave a catch-all report from years back open, which isn't being actively looked over and has no prospect of being resolved, and then go around fixing concrete security issues relating to that only when an external reporter outlines a specific case of attack.

I can empathize with this.  On the other hand, issue 63773 has been filed and public for eight years, and describes a lot of the concerns here.  Given the exploit pattern is almost identical for any dialog (i.e., you could take your PoC and just trigger a different dialog) and we already have a meta bug filed to track the issue, I don't think it's beneficial to file different bugs for each potential dialog (especially since when we fix this, it should be a change to the dialog code, rather than any specific dialog).  I think the biggest thing is that we really should prioritize fixing issue 63773, fixing all the dialogs in a comprehensive way.

meacer@, do you think you'll have the cycles to be able to work on this soon?  If not, should we see if we can wrangle someone else to dive into it?

There is now more interest in adding delays to sensitive dialogs in general (dialogs etc), so I might look at it in Q3, but can't make any promises. There is a chance that the cost of fixing all dialogs (i.e. issue 63773) might outweigh its benefits.

We discussed this internally, and agreed that we're going to close this bug out, due to the prior bugs filed at issue 394518 and issue 63773.

Hi, I would like to know if you are ok with me talking publicly about this issue given bug 63773 and  bug 544573  are already public, and also if this bug could be made public.

Thanks!

I personally have no objections (given the other issues are), but I'd like to know what meacer@ thinks.  Please wait for him to chime in.

It saddens me that we don't have much to show for bug 63773 yet, but I don't have any objections either.

Hi, can someone remove the Restrict-View-SecurityTeam label? Thanks!

+awhalley for #24