blink-dev@ intent thread triage report

[Eduardo' Vela" <Nava>]

Triaged 2016-12-25 -> 2016-12-30 (until row #964 (inclusive) in in https://bit.ly/blinkintents):

• <dialog>: add DialogShowParams to show()/showModal(): Proposes adding a parameter to avoid stealing focus of the client on opening a dialog. Not very interesting IMHO, as I don't see much of a difference between .show()/.close() and style.display=block/none; The backwards behavior (forcing the focus to be set even if the element wouldn't be focused otherwise) is a bit more interesting (example - that input wouldn't be focusable without autofocus, id or tabindex). I looked into whether this behavior also worked across iframes, and it didn't, so it's not so bad. I marked their launch as NA. While looking into this, I went into a long tangent around devicemotion being able to predict the user is "about" to type something, which could allow the user to shift the focus to an iframe, bringing back strokejacking to chrome.. However, I stopped as soon as I realized this has nothing to do with dialogs. That said, I think that probably works, but strokejacking is a bit lame, so.. whatever. If you think strokejacking is cool, and want to look further into it let me know.
  
• Asynchronous Clipboard API: Proposes adding an asynchronous interface to the clipboard API which allows stuff like permissions to be resolved, as well as modifications on the event data to be done asynchronously. This is an alternative to the current "API" which is a hack more than anything else. Anyway, this is a big deal! I think this actually does need to be looked at closely. The stuff they are suggesting include stuff like access from workers, clipboard modification notifications, and a bunch of other things. They have considered some of these abuse vectors but they depend a lot on permission dialogs. I marked their launch as Started. Although, that's not in the playbook. How should this be handled now? Is there a security review process? Am I the owner now?

Notes: This rotation needs better automation =). I thought the bit.ly/blinkintents spreadsheet was for us (seQrity), but apparently it's shared. Can we just have a new spreadsheet for ourselves? It should be trivial (eg, it should just be an =IMPORTRANGE). If this sounds useful, let me know, and I can implement it. Or is there a better way?

[Emily Stark]

On Fri, Dec 30, 2016 at 10:01 AM, 'Eduardo' Vela" <Nava>' via Security-dev <securi...@chromium.org> wrote:

Triaged 2016-12-25 -> 2016-12-30 (until row #964 (inclusive) in in https://bit.ly/blinkintents):

• <dialog>: add DialogShowParams to show()/showModal(): Proposes adding a parameter to avoid stealing focus of the client on opening a dialog. Not very interesting IMHO, as I don't see much of a difference between .show()/.close() and style.display=block/none; The backwards behavior (forcing the focus to be set even if the element wouldn't be focused otherwise) is a bit more interesting (example - that input wouldn't be focusable without autofocus, id or tabindex). I looked into whether this behavior also worked across iframes, and it didn't, so it's not so bad. I marked their launch as NA. While looking into this, I went into a long tangent around devicemotion being able to predict the user is "about" to type something, which could allow the user to shift the focus to an iframe, bringing back strokejacking to chrome.. However, I stopped as soon as I realized this has nothing to do with dialogs. That said, I think that probably works, but strokejacking is a bit lame, so.. whatever. If you think strokejacking is cool, and want to look further into it let me know.
  
• Asynchronous Clipboard API: Proposes adding an asynchronous interface to the clipboard API which allows stuff like permissions to be resolved, as well as modifications on the event data to be done asynchronously. This is an alternative to the current "API" which is a hack more than anything else. Anyway, this is a big deal! I think this actually does need to be looked at closely. The stuff they are suggesting include stuff like access from workers, clipboard modification notifications, and a bunch of other things. They have considered some of these abuse vectors but they depend a lot on permission dialogs. I marked their launch as Started. Although, that's not in the playbook. How should this be handled now? Is there a security review process? Am I the owner now?

+lgarron who has been involved in various clipboard APIs

 

Notes: This rotation needs better automation =). I thought the bit.ly/blinkintents spreadsheet was for us (seQrity), but apparently it's shared. Can we just have a new spreadsheet for ourselves? It should be trivial (eg, it should just be an =IMPORTRANGE). If this sounds useful, let me know, and I can implement it. Or is there a better way?

--
You received this message because you are subscribed to the Google Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev+unsubscribe@chromium.org.

[Eduardo' Vela" <Nava>]

Cool. I'll add lucas to their intent thread.

To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

[Lucas Garron]

The asynchronous clipboard API is partially due to me. I will be keeping a close eye on it.

The security considerations depend on what features we expose to the web (copy vs. paste vs. foreground listen, vs. background listen). An asynchronous API will at least allow us to use security approaches that were not possible with the current API.

»Lucas