Thanks for the report.

Considering this as Feature request, marking as Untriaged and requesting Dev team to look into this issue.

What is your use case for this feature?

NextAction set for feedback.

The use case details
====================

In many cases, we want to render a part of HTML content to images for printing or other purposes. The most convenient way is to take advantage SVG as described in the https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Drawing_DOM_objects_into_a_canvas. Due to the SVG security restriction, images (even from the same origin) will not be downloaded!

Thus, if web-security flag can change the behavior of SVG image security restriction, it should be more convenient for developers.

P.S. Now the Electron and many other communities also depend on the core of Chromium, so we'd better also keep those cases (Web context, desktop context etc.) in mind as well.

Thanks.

I think this is WontFix. The --disable-web-security flag is intended to disable same origin checks, it is not intended to disable spec defined restrictions on SVG-as-image.

What does the security team think?

Thank you for your information.

I would like to add more comments for the "security". (Please forgive me if I said something wrong since I am not a security expert.)

1: If --disable-web-security flag is intended to disable same origin checks, then is it more meaningful to change the flag name to --disable-same-origin?

2: I wish the security team can keep Electron and other cases in mind, now the core of Chromimum is used widely beyond the classic "Web". In the desktop environment, some Web security restrictions sometimes become unnecessary and painful for developers.

Thank you.

I do think it's important to keep electron usecases in mind, but we should still fix things at the correct layer to prevent fragmenting the platform. Both web developers and electron users want this functionality.

Is this an example of what you're trying to do?
https://pr.gg/sameorigin.html

@pdr, yes, https://pr.gg/sameorigin.html is a good example. Thank you. 

I think this may just be a bug. It's curious that Firefox has the same issue though.

@Fredrik, can you double-check me? We have several security restrictions when going from svg to canvas, but in this case all content is on the same origin.

Sorry, I was mistaken. Data uris create a "opaque origin" and should not be able to load resources from the page's origin by default. CORS could potentially be used for this on the open web (https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_enabled_image).

I think it would be reasonable to have --disable-web-security override this check.

Technically speaking you have a blob URL in your example, which I believe differ slightly from data URLs (origin for a blob: is the origin of the effective script or somesuch.) That doesn't really matter for SVGs embedded in an image context, since we explicitly disallow anything but data URLs in those cases.

So, do we want to relax that to "same-origin only" or just disregard it altogether? (With --disable-web-security, or SecurityOrigin::isGrantedUniversalAccess which is what I assume we'd use here in practice.)

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

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