{"id":330184,"date":"2020-12-17T08:07:33","date_gmt":"2020-12-17T16:07:33","guid":{"rendered":"https:\/\/css-tricks.com\/?p=330184"},"modified":"2020-12-22T13:04:19","modified_gmt":"2020-12-22T21:04:19","slug":"i-learned-to-love-the-same-origin-policy","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/i-learned-to-love-the-same-origin-policy\/","title":{"rendered":"I learned to love the Same-Origin Policy"},"content":{"rendered":"\n

I spent a good chunk of my work life this year trying (in collaboration with the amazing Noam Rosenthal<\/a>) to standardize a new web platform feature: a way to modify the intrinsic size and resolution of images. And hey! We did it!<\/a> But boy, was it ever a learning experience<\/em>.<\/p>\n\n\n\n

This wasn’t my first standardization rodeo, so many of the issues we ran into, I more-or-less anticipated. Strong negative feedback<\/a> from browsers. Weird, unforeseen gotchas<\/a> with the underlying primitives. A complete re-think<\/a> or two<\/a>. What I didn’t anticipate though, was that our proposal \u2014 which, again, was \u201conly\u201d about modifying the default display size of images \u2014 would run afoul of the fundamental privacy and security principles of the web. Because before this year, I didn’t really understand those principles.<\/p>\n\n\n\n

Let me set the table a bit. What were we trying to do?<\/p>\n\n\n\n\n\n\n\n

By default, images on the web show up exactly as big as they are. Embedding an 800\u00d7600 image? Unless you stretch or shrink that image with CSS or markup<\/a>, that’s exactly how large it’s going to be: 800 CSS pixels across, and 600 CSS pixels tall. That’s the image’s intrinsic (aka “natural”<\/a>) size<\/em>. Another way to put this is that, by default, all images on the web have an intrinsic density<\/em> of 1\u00d7.<\/p>\n\n\n\n

That’s all well and good, until you’re trying to serve up high<\/a>-, low<\/a>-, or ✨variable✨<\/a>-density images, without access to CSS or HTML. This is a situation that image hosts like my employer, Cloudinary<\/a>, find themselves in quite often.<\/p>\n\n\n\n

So, we set out to give ourselves and the rest of the web a tool to modify the intrinsic size and resolution of images. After a couple of re-thinks, the solution that we landed on was this:<\/p>\n\n\n\n

  1. Browsers should read and apply metadata contained within image resources themselves<\/em>, allowing them to declare their own intended display size and resolution.<\/li>
  2. Following in the recent footsteps of image-orientation<\/a><\/code> \u2014 by default, browsers would respect and apply this metadata. But you could override it or turn it off with a little CSS (image-resolution<\/a><\/code>), or markup (srcset<\/code>\u2019s x<\/code> descriptors<\/a>).<\/li><\/ol>\n\n\n\n

    We felt pretty good about this. It was flexible, it built on an existing pattern, and it seemed to address all of the issues that had been raised against our previous proposals. Alas, one of the editors of the HTML spec, Anne van Kesteren<\/a>, said: no. This wasn’t going to work<\/a>. And image-orientation<\/code> needed an urgent re-think, too<\/a>. Because this pattern, where you can turn the effects of EXIF metadata on and off with CSS and HTML, would violate the \u201cSame-Origin Policy<\/a>.\u201d<\/p>\n\n\n\n

    Uh… what?<\/p>\n\n\n\n

    Aren’t we just scaling and rotating images??<\/p>\n\n\n\n

    Confession time! Before all of this, I’d more or less equated the Same-Origin Policy with CORS<\/a> errors, and all of the frustration that they’ve caused me over the years. Now, though, the Same-Origin Policy wasn’t just standing between me and handling a fetch<\/code>, it was holding up a major work initiative. And I had to explain the situation to bosses who knew even less about security and privacy on the web than I did. Time to learn!<\/p>\n\n\n\n

    Here’s what I learned:<\/p>\n\n\n\n