- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 27 Jul 2020 22:43:25 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-images] image-orientation:none violates same-origin policy`, and agreed to the following: * `RESOLVED: Do not expose orientation data for cross-origin images` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-images] image-orientation:none violates same-origin policy<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/5165<br> <dael> heycam: We have image-orientation. Ignoring print processors it's used for authors to opt out of what we're moving to with exif orientation honored. It's really that orientation is impl detail on how image is represented in file<br> <dael> heycam: We have image-orientation:none which lets authors opt-out<br> <dael> heycam: In Gecko and Chrome image-orientation:none applies to same and cross origin images<br> <dael> heycam: Ana pointed out that applying to cross-origin it's a leak of one bit of info. For images cross origin you can look at width and height. B/c you can tell if it's re-oriented 90 deg you can get an extra bit of info to know if image meta was one set of value or another<br> <TabAtkins> q+<br> <TabAtkins> s/Ana/Anna/<br> <TabAtkins> s/Anna/Anne/<br> <AmeliaBR> q+<br> <dael> heycam: Shouldn't add more leaks in theory. Perhaps arguable if it's super important if this makes a difference and weigh it against value for authors<br> <dael> heycam: It's something to discuss<br> <Rossen_> ack TabAtkins<br> <cbiesinger> q+ doesn't angle have the same problem<br> <cbiesinger> q+ to ask doesn't angle have the same problem<br> <dael> TabAtkins: All this makes sense to me. Image-orientation and the image resolution which you can observe via src set is info leaks. Way through is make cross-origin images behave like it's information was baked in so they can't turn off orientation. It would mean cross-origin would act as if exif was it's native. Similar would apply to resolution where you could select correct but it would act baked in<br> <dael> TabAtkins: Regardless of how you look at image you get same data.<br> <dael> TabAtkins: Sounds good, happy to adopt<br> <Rossen_> q?<br> <dael> TabAtkins: Not sure if it's css or html but happy to figure it out<br> <dael> fantasai: It was in css<br> <fantasai> s/It was/I think it lives/<br> <Rossen_> ack AmeliaBR<br> <dael> AmeliaBR: Support what TabAtkins said. One proposal in issue was do reverse where cross origin ignores exif and I don't want. Render it as the image format is supposed to be rendered incl exif but don't make it inspectable how it was generated.<br> <Rossen_> ack cbiesinger<br> <Zakim> cbiesinger, you wanted to ask doesn't angle have the same problem<br> <dael> cbiesinger: Two comments. Seems like angle is a possible value with same problem.<br> <dael> cbiesinger: IN response to TabAtkins I think a lot of websites are images from different host. Seems like not supporting would make chrome exif a lot less useful.<br> <dael> cbiesinger: Don't have a good solution but it's not ideal<br> <dael> AmeliaBR: THis would be normal http cross-origin so if you have full control over cdn and can give correct headers that's one way to turn off exif<br> <dael> TabAtkins: This should continue to work as normal for cdn but you wouldn't be able to turn exif off. It would always be on<br> <dael> heycam: Possible you're using images from cdn and relying on orientation not being applied. I don't think there's anything special about iamges from cdn<br> <dael> TabAtkins: In general our research has shown better for web if we do respect exif at all times<br> <Rossen_> q<br> <dael> cbiesinger: I'm in favor of model TabAtkins desc. Had one person contact me where he would like it to comeintue to apply to cross origin b/c they have tool to present image and get user to annotate and then they hand over annotation to another tool. Without being able to tell the tool the orientation they can't tell if they have to process.<br> <dael> s/ cbiesinger /heycam<br> <dael> heycam: THey can work around that<br> <dael> TabAtkins: Or preprocess to turn on cors stuff they'll be fine<br> <dael> Rossen_: Where do we go from here?<br> <dael> TabAtkins: Unless there's objections proposal is do not expose orientation data from cross origin images. Do it by having the maskarade as their exif orientation being the native<br> <dael> TabAtkins: 2 resolutions. One we want one is impl strat<br> <dael> Rossen_: Prop: Do not expose orientation data for cross-origin images<br> <dael> Rossen_: Comments or objections?<br> <dael> RESOLVED: Do not expose orientation data for cross-origin images<br> <dael> Rossen_: Question; for things like cloud functions are they cross-origin?<br> <dael> Rossen_: cloud functions your source has an image call<br> <cbiesinger> q+<br> <dael> TabAtkins: Don't know but definition of cross-origin is stable so I'll rely on that. It's very precise and I don't want to manipulate it<br> <dael> cbiesinger: Question is do we have use counter data for how often we have image orientation that's not from exif?<br> <Rossen_> ack cbiesinger<br> <heycam> s/THey can work around that/They can work around that by fetching the image on the server side/<br> <dael> TabAtkins: Don't think we do yet. We know in general honoring exif is the better way to go so even if there are cases that are specifically needing to care it's a smaller subset of the subset we consider is okay to break<br> <dael> cbiesinger: Okay it's better, curious about how big the number is<br> <heycam> s/Or preprocess/Or proxy the image request/<br> <dael> Rossen_: Have the resolution on record. Add anything about impl direction or in the minutes is enough?<br> <dael> TabAtkins: Minutes is enough<br> <cbiesinger> looks like image-orientation in general is only used on 0.13% of pageloads so this is probably OK<br> <dael> heycam: Anna raised a separate issue about who defines this and have a spec which can be referenced. That's something for later.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5165#issuecomment-664675478 using your GitHub account
Received on Monday, 27 July 2020 22:43:27 UTC