See related  issue 659492  and  issue 659489 . There's a few potential solutions:

1. Sandbox to disallow download completely in a frame. Blocked downloads silently fail. This is issue 539938. This seems like a no-brainer.

2. FeaturePolicy to disallow download completely in a frame. Blocked downloads silently fail.

3. FeaturePolicy to allow download in a frame. By default, show popup-blocking-esque dialog when a download is initiated in a cross-origin frame, unless the outer page has granted it permission to do so via FeaturePolicy. Will likely break legitimate content.

4. Require the frame to have had a user gesture before it can initiate downloads. If the download is blocked, show popup-blocking-esque dialog. Open question: Whether to allow a FeaturePolicy directive so the top-page can allow downloads without a gesture. 

2-4 conflict a bit in their use of FeaturePolicy. 4 is a more permissive version of 3 that's less likely to hit back-compat problems. I've been surprised at what people use cross-origin frames for as we limit their capabilities. I suspect there are legit cases of people downloading via cross-origin subframes that we'd break.

Regarding UI, the current popup blocking UI is way too intrusive on mobile. I think we'd need to rework the UI eventually. An alternative would be to do #4 without showing any UI when downloads are blocked, but I worry that will lead to users seeing broken sites.