Snippets

Before all of this, I’d more or less equated the Same-Origin Policy with CORS 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, 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!

Here’s what I learned:

• The Same-Origin Policy isn’t a single, simple, rule. And it certainly isn’t == CORS errors.
• What it is, is a philosophy which has evolved over time, and has been inconsistently implemented across the web platform.
• In general, what it says is: the fundamental security and privacy boundary of the web is origins. Do you share an origin with something else on the web? You can interact with it however you like. If not, though, you might have to jump through some hoops.
• Why “might?” Well, a lot of cross-origin interactions are allowed, by default! Generally, when you’re making a website, you can write across origins (by sending POST requests off to whoever you please, via forms). And you can even embed cross-origin resources (iframes, images, fonts, etc) that your site’s visitors will see, right there on your website. But what you can’t do, is look at those cross-origin resources, yourself. You shouldn’t be able to read anything about a cross-origin resource, in your JavaScript, without specially-granted permission (via our old friend, CORS).
• Here’s the thing that blew my mind the most, once I finally understood it: cross-origin reads are forbidden by default because, as end-users, we all see different world-wide webs, and a website shouldn’t be able to see the rest of the web through its visitors’ eyes. Individuals’ varied local browsing contexts – including, but not limited to, cookies — mean that when I go to, say, gmail.com, I’m going to see something different than you, when you enter that same URL into your address bar and hit “return.” If other websites could fire off requests to Gmail from my browser, with my cookies, and read the results, well – that would be very, very bad!

So by default: you can do lots of things with cross-origin resources. But preventing cross-origin reads is kind of the whole ballgame. Those defaults are more-or-less what people are talking about when they talk about the “Same-Origin Policy.”

Developers, designers, and strategists, here’s something you can do for the health of the web: 

Test all your sites in Firefox.

Yes, we should all design to web standards to the best of our ability. Yes, we should all test our work in *every* browser and device we can. Yes, yes, of course yes. 

But the health of Firefox is critical now that Chromium will be the web’s de facto rendering engine. 

Even if you love Chrome, adore Gmail, and live in Google Docs or Analytics, no single company, let alone a user-tracking advertising giant, should control the internet.

[…]

When one rendering engine rules them all, well, many of us remember when progress halted for close to ten years because developers only tested in IE6, and more than a few of us recall a similar period when Netscape was the only browser that mattered.

[…]

When one company decides which ideas are worth supporting and which aren’t, which access problems matter and which don’t, it stifles innovation, crushes competition, and opens the door to excluding people from digital experiences.

I found this quite useful in learning the basics of XPath:

CSS custom properties are commonly known as CSS variables, and judging by the main web development blogs and resources, most people likely use the terms “custom property” and “variable” interchangeably[.]

[…]

The reason for this could be that the CSS spec itself uses both terms. ”Custom properties” and “variables” both appear in the spec’s text dozens of times and even in the spec’s own title (“CSS Custom Properties for Cascading Variables”).

However, the spec distinguishes the two terms: A custom property is not a variable, but it defines a variable. Any property can use variables with the var() function whose values are defined by their associated custom properties.

[…]

This distinction is useful because it allows us to talk about “variables with fallback values” (a custom property like any other property cannot have a fallback value) and “properties using variables” (a property cannot use a custom property) […] as well as “declaring a custom property on an element” (a variable isn’t declared but assigned to a property) and “the computed value of a custom property” (a variable doesn’t have a computed value but draws from the computed value of its associated custom property).