[css-shapes] Consider ways to make the CORS limitation in CSS Shapes easier for authors

[jensimmons]

User agents must use the potentially CORS-enabled fetch method defined by the [HTML5] specification for all URLs in a shape-outside value. When fetching, user agents must use "Anonymous" mode, set the referrer source to the stylesheet’s URL and set the origin to the URL of the containing document. If this results in network errors such that there is no valid fallback image, the effect is as if the value none had been specified.
— https://drafts.csswg.org/css-shapes/#shape-outside-property

When using a image file to define a shape, shape-outside: url(foo.png);, the specification requires browsers to restrict this feature so that it only works with CORS-enabled files.

I can tell you from experience — my own, and the people I talk to who are attempting to use Shapes — this causes problems. It's likely that shape-outside:url() will not work, even when working locally with a very simple setup. In fact, it seems to fail most of the time. Trying to teach people Shapes while expecting them to know how to dig into SysAdmin level debugging is terrible.

I do not understand why this limitation was put into place. I can see how people might wish to get into a time-machine and restrict all uses of images on the web to such a security standard, but that would in fact require a time machine. Putting this restriction on one part of CSS while not having it on any other doesn't seem to do anything to increase the security of the web. If I want to attack a website, and can find a way to do with a reference to an image file in CSS — I could just use background instead of shape-outside.

This seems to me to be a case where theoretical purity was put before authors, in violation of the Priority of Constituencies. I think we should reconsider.

[dbaron]

Other ways of using cross-domain images don't allow introspection into the contents of the image -- I think they only get access to the size. With a url-defined shape, the page gets access to a good bit of detail about the pixel data. There are pretty substantial security mechanisms in other parts of the Web platform (e.g., canvas tainting) to prevent this sort of information leakage from happening elsewhere.

It's possible the details here need to be tuned (e.g., use of anonymous mode vs other existing options vs. the proposal in whatwg/fetch#517), but I think a CORS check does need to happen for cross-domain images.

[meyerweb]

Looked for the +1 button on mobile but didn’t find it. Consider this a vote in Jen’s favor.

[jensimmons]

I'll quickly admit, I don't know the details here. I just know how often people stumble over this, and usually give up on Shapes URL altogether. Perhaps there is a way to refine the security so that people encounter the problem less often. That would be a bug help.

It seems this happens when working locally, when it's not a crossdomain situation at all. The person I was just helping had a failing project in Chrome / Opera while it worked in Safari — both locally. Then when she pushed to a server it worked in all browsers. Could "…use of anonymous mode vs other existing options vs. the proposal in whatwg/fetch#517" help here?

[jensimmons]

I should ask, what's different between the Blink and Webkit implementations in this regard?

[astearns]

Copying a response I sent a while back to the www-style list:

I did not understand the [security] implications either, at first. While you can fairly promiscuously display an image with its alpha data on a web page, what you don't get is scripted access to the data. For the same reason that cross-origin images can taint a Canvas such that you cannot retrieve the pixel information, you should not be able to use shape-outside on untrusted pages to use cross-origin images. You can wrap arbitrarily-small text lines around the shape, allowing scripted access to the alpha data contours. Combined with filters that map arbitrary image data to the alpha channel, you'd get scripted access to all of the pixel data. It's that scripted access that we need to avoid exposing.

[tabatkins]

And long experience has taught us that, most of the time, there's no clever way to avoid exposing data like this. It's ban or nothing.

It seems this happens when working locally, when it's not a crossdomain situation at all.

Browsers have different treatment of local files. In particular, I think Chrome treats sibling files/folders as cross-domain. This sucks for local dev, but it's required because of how people download things; when sibling files are treated same-domain, it means your entire Downloads folder is accessible to any .html page that can convince you to download and run it. Safari treats this differently, I think.

Like I said, this sucks, but the only way to reliably do local dev is to start a local server. There are a lot of turn-key solutions for this.

---

End result is that, while I understand the ergonomic problems with it, I'll hard-reject any attempt to loosen the restrictions. CORS should have applied to every resource on the web from the beginning, and we're doing fairly decently at applying it to new ways of fetching resources.

[AmeliaBR]

I agree with Tab that shape-outside is equivalent to scripting access. The only other option would be to "taint" access to the offset positions and size of all elements in the same flow-root as the floated object.

But maybe the spec could gain an informative note helping authors avoid issues? For example, clearly warning that many browsers treat file: URLs as cross-origin.

From my own experience, the biggest problem with CORS and shape-outside is that it can fail even if the server is set up to enable CORS. If you are using the image for something else that doesn't require CORS (e.g., as an <img>, background image, or mask image), the browser requests the file without CORS permissions, and then when it gets to shape-outside (or another property that does need CORS) it looks at the HTTP headers for the already-downloaded file & determines that it doesn't meet CORS.

Unfortunately, the nature of HTTP CORS doesn't make this easy to solve. The server is only allowed to give permissions for one domain at a time, so most server settings only provide permission on request.

So... one way to make things easier would be to push ahead with the url() modifier to allow authors to upgrade all image requests to ask for cross-origin permissions (which I'm sure I've seen specified somewhere, but I can't find it anymore). That way, a background-image reference wouldn't break a shape-outside reference.

[astearns]

I do think that @AmeliaBR's suggestion of adding a modifier to url() will help people be consistent with their images, but that won't require any change to the shapes spec.

@jensimmons @meyerweb I'm going to close this issue no change, as the CORS requirement is from a long-standing working group resolution for the reasons stated above.

Please comment/reopen if you have a strong objection to this decision, or have any new ideas on how we could make things easier to use without opening the security problem.

[frivoal]

I've stumbled upon this today again. Made the simplest HTML document, with an image and a paragraph, tried to use shape-outside from the image, loaded it from the local file system, and failed. I was stratching my head for a little while until I remembered about CORS. Dev-tools didn't even warn.

Is there really nothing we can do about file system access? Requiring a CORS configured web server to do the most basic of css development seems silly.

If not, could dev-tools show a warning, and maybe let you tick a box or something to allow-list things while you're developping the page?

Also, how does the CORS requirement play out with EPUB files? I could be wrong, but I think the inside of an EPUB isn't particularly CORS aware (or origin aware). Having shape-outside be unable to work in EPUBs would be unpleasant, and having it work based on ignoring the spec would be better for users, but should tell us something is off with the spec(s).