[css-images] image-orientation:none violates same-origin policy

[annevk]

As I realized in whatwg/html#5603, this leaks an additional bit of information for opaque responses.

cc @heycam

[annevk]

An alternative to consider is to act as if images generated from opaque responses never have EXIF data (or any kind of metadata other than width/height/ratio). Requiring each feature that can disable or override some EXIF data to take such images into account feels very brittle to me.

[noamr]

An alternative to consider is to act as if images generated from opaque responses never have EXIF data. Requiring each feature that can disable EXIF data to take such images into account feels very brittle to me.

I think that that would create a requirement that would make people enable CORS when they didn't otherwise have to - just to have their images display correctly.

I think there's no reason why this requirement should be on the usage of EXIF, instead on the feature that overrides (and thus exposes) EXIF, such as image-orientation and image-resolution CSS properties.

Otherwise, it feels like we're trying to prevent a threat of a hypothetical future API. Is that a necessary thing to do?

[annevk]

They're not hypothetical, this API (image-orientation) already exists, whatwg/html#5603 adds another. Making the APIs enforce the policy violates the principle of least privilege and will likely lead to numerous bugs.

[heycam]

cc @stephenmcgruer

[heycam]

If we do have to prevent image-orientation from working on images that came from opaque responses, it would be nice if we could unconditionally apply the orientation (and I guess pretend from the whatwg/html#5603 APIs that there was no orientation metadata), so that we can try to treat orientation as an implementation detail of the image file representation. But that would make it tricky for authors wanting to use image-orientation: none to turn off the new re-orientation effects for their pages that rely on it not being applied.

[noamr]

If we do have to prevent image-orientation from working on images that came from opaque responses, it would be nice if we could unconditionally apply the orientation (and I guess pretend from the whatwg/html#5603 APIs that there was no orientation metadata), so that we can try to treat orientation as an implementation detail of the image file representation. But that would make it tricky for authors wanting to use image-orientation: none to turn off the new re-orientation effects for their pages that rely on it not being applied.

I think that's a better approach... the threat comes from the "overriding" feature, not from the implementation detail of using EXIF. An image format may similarly have an internal representation of orientation/resolution supported internally in the decoder - would that also be limited to same-origin/CORS images?

EXIF is not the issue here - it's the mixing of image-originated data and markup-originated data, which is something that currently occurs only for naturalWidth/naturalHeight.
If we want to take a more generic approach - I think it should tackle those blurred boundaries between content and markup.

[annevk]

@noamr again, it's not just overriding, it's also reading as linked above. There's various different ways this will end up being exposed.

@heycam how do we model it in such a way that we don't need security checks all over?

I guess what we could do is that we take the orientation into account for decoding purposes, but don't store it as a field on the resulting image if it was generated from an opaque response. So it appears rotated, but if you query its metadata it'll return the default orientation values.

The tricky aspect is when metadata can be overridden, as it can be here. If the internal representation still has non-default metadata you would need to take that into account somehow. I.e., if an image was rotated 90 degrees and an API asked for it not to be rotated, it would have to remain rotated at 90 degrees. Model-wise that follows from the preceding paragraph, but in implementations that might be a bit trickier.

[noamr]

@noamr again, it's not just overriding, it's also reading as linked above. There's various different
ways this will end up being exposed.

Sure, I meant reading/overriding - anything that enables reading directly or indirectly.

The tricky aspect is when metadata can be overridden, as it can be here. If the internal representation still has non-default metadata you would need to take that into account somehow. I.e., if an image was rotated 90 degrees and an API asked for it not to be rotated, it would have to remain rotated at 90 degrees. Model-wise that follows from the preceding paragraph, but in implementations that might be a bit trickier.

I think that the overriding features in this case should be disabled for the opaque resource. E.g. CSS image-orientation would simply not apply, maybe even regarded as invalid style. I think that would be reasonable implementation-wise.

[annevk]

I think the model we end up with shouldn't require each new feature to check whether the image was generated from an opaque response. So if some theoretical feature allowed setting EXIF rotation to 90 and the opaque image already had it 90 (exposed as 0 per the above model), it should be as if it was 180 and be exposed to the world as 90.

[noamr]

I think the model we end up with shouldn't require each new feature to check whether the image was generated from an opaque response. So if some theoretical feature allowed setting EXIF rotation to 90 and the opaque image already had it 90 (exposed as 0 per the above model), it should be as if it was 180 and be exposed to the world as 90.

I like that. Makes metadata "embedded" into the image for opaque images, but still working as expected if there's nothing that tries to override/read it.

[heycam]

I guess what we could do is that we take the orientation into account for decoding purposes, but don't store it as a field on the resulting image if it was generated from an opaque response. So it appears rotated, but if you query its metadata it'll return the default orientation values.

I think this would be the right approach. The intrinsic orientation spec concept for opaque images would be "zero degrees, no flip", and the image dimensions (whether the image is opaque or not) would have the orientation taken into account. image-orientation's behavior would then be written in terms of the image's intrinsic orientation.