Thanks for the report, but unfortunately I do not yet understand the exact vulnerability. 

"On some page it's blocked, But on a direct access it's not." --> how do you define a direct access? Are you saying that Chrome is allowing flash content to run by default when it should be blocked?

I have made a mistake saying on "Direct Access".

So, Here we go:

Check: 
data:text/html,<embed src="http://ANYTHINGHERE.SWF" quality="high" width="1" height="1" allowscriptaccess="sameDomain" type="application/x-shockwave-flash" /> It will be block anyway, sure?

- Depending of the HEIGHT the SWF content is being executed without ask the user permission(Really Weird); Like if it's height="1" it will be blocked, If it is more, it looks like every embedded content larger than 1 pixel is being executed without user permission.

- Local files of the same URL seems to don't need user permission, same for 1 pixel though.

Check this i have sent:

http://yay21sckthisnow0.website.tk/datthingylol0.html (Didn't asked for permission, Same for 1 Pixel). 

External files with 1 pixel are being blocked and asking for users permission. Not only the 1 pixel should have to ask permission, according to the browser settings. 

P.S: The content is only executed when the option ""Ask before allowing sites from executing flash content(Recommended)" Is active. Which demonstrates that there is a failure to execute these files without asking permission before.

------------------------------------------------------

+waffles@ who might know more.

I think it blocks 1 pixel Flash plugins by default as a policy against some invisible Flash plugins. As for it allowing other plugins without permission, can you confirm that you didn't set "Always allow flash content" on those pages? And please check the Flash section in chrome://settings/content

I also think it could be intended policy to allow a flash plugin from the local filesystem to execute automatically, but let's get someone on this bug with a definitive answer.

We have a same origin exception from Tiny (5x5 or below) Flash content.  The exception was meant to be a temporary relief for smaller developers, for features that are well now very supported by the web platform (e.g. clipboard access, audio streams, etc...).

We currently have an experiment running on Canary and Dev w/ the exception removed (1).  The plan is to ship that to stable in ~Chrome 60 timeframe.

(1) - https://www.chromium.org/flash-roadmap#TOC-PPS-Tiny---No-Same-Origin-Exceptions-Target:-Chrome-60---June-2017-

laforge@ -- it sounds like this is working as intended. Yes?

Thank you for providing more feedback. Adding requester "kerrnel@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Yeah, unless I'm missing something this appears to be a working as intended (WontFix).

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