This isn't a security bug, insofar as it does not allow a site to do anything it cannot do in many other ways. Downloads triggered via this mechanism would still be evaluated by Safe Browsing download checks, etc. 

However, this does appear to be a standards-compliance issue, and something which may be easier to fix with changes made in M53 to ignore synthetic events on controls.

@mkwst: PTAL?

working on this issue

Yeah. Not a security bug. A web page is allowed to initiate a single download via script or otherwise without a user interaction.

Agree with #1 that this is a compliance issue.

Does this issue also apply to a JS-generated 'click' event?  If so then we should probably be restricting the download behavior to just trusted click events.  We could explicitly test for the presence of a UserGestureIndicator but it would probably be better to rely on explicit isTrusted if it's present.  +dtapuska who's the expert about that.

But +1 that this isn't a security issue.  Eg. the site can also set window.top.location to some URL which sets the right headers to force a download.

FYI, ignoring the click if !event.isTrusted is what we do in WebKit.

Ya we can likley do this as well. Should be a trival change https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/HTMLAnchorElement.cpp?sq=package:chromium&rcl=1474903310&l=428

FYI, there is a WIP CL: https://codereview.chromium.org/2371573002/ (jhwon0415 is working on this.)

There's some web compat risk here of breaking existing sites, but given that Firefox and WebKit already behave this way I think the risk is minimal and I'm OK treating this as just a bugfix.

But if, after landing, we get reports of this change breaking some real-world sites then we'll probably want to revert and treat this as an "intent to remove" (adding a UseCounter, etc.).  But like I said, I think the risk is low.

Although WebKit currently behaves this way (ignores untrusted events), we have not shipped the download attribute support in Safari yet so we don't know about web compatibility risks yet. However, shipping Firefox seems to behave this way already so I would agree the risk is hopefully low.

There may be some Web compatibility issue if relying solely on event.isTrusted. See https://bugs.webkit.org/show_bug.cgi?id=156056#c3.

This apparently breaks https://eligrey.com/demos/FileSaver.js/