Security

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.”

Yet another great example of why browser diversity matters and why Chrome’s overwhelming presence in both mobile and desktop use is harmful to the open web: some developers mistake Chrome’s adoption of an API as a web standard, when both Mozilla and Apple have serious concerns about the security of said API:

In issue #509 of JavaScript Weekly, Chrome’s new File System Access API was mistakenly referred to as an “open standard.” The author probably assumed that a feature with a specification and an implementation in Chrome must therefore be a web standard, but that is not necessarily the case.

The API in question is currently hosted by the Web Incubator Community Group (WICG), a place where browser vendors can propose, discuss, and develop new web platform features, and receive feedback from the wider community.

[…]

Google has been developing the File System Access API for at least the past two years and decided to ship it in Chrome in October (last month). As part of this process, Google asked both Apple and Mozilla for their official positions on the API. So far, their responses have not been positive (Apple, Mozilla).

It seems that Google decided to ship the File System Access API in Chrome without endorsement from Apple or Mozilla because it believes that this feature “moves the web platform forward”:

Interoperability risk is the risk that browsers will not eventually converge on an interoperable implementation of the proposed feature. … If a change has high interop/compat risk but is expected to significantly move the web forward, Chromium will sometimes welcome it.

Standardization and support from Apple or Mozilla is not a requirement for shipping a web platform feature in Chrome. However, because of Chrome’s large market share, there is a risk of such a feature becoming a de facto standard:

Changes to Chrome’s functionality create de facto standards. Market participants must adhere to these standards or risk their technology no longer being compatible with most websites.

I’ve talked about this before: As web designers, we can’t trust the network. Sure, we have to contend with mobile data “dead zones” and dropped connections as our users move about throughout the day, but there’s a lot more to the network that’s beyond our control.

Here’s a roundup of some of my “favorite” network issue related headlines from the last few years:

• Sky Broadband misclassified the jQuery CDN as a malware site and broke much of the web for their users.
• Comcast admitted to injecting self-promotional advertising into web pages served by their Xfinity routers. (They have also been called out for artificially inflating subscriber bandwidth usage with their own crap.)
• United was recently called out for blocking access to the New York Times on their in-flight Wi-Fi.
• Someone discovered AT&T was injecting CSS, images, and JavaScript into pages served via their airport hotspots.
• Samsung smart TVs were found to be injecting video ads into video streaming apps.
• Sprint injects JavaScript into pages served via its data connections.
• Browser add-ins can inject their own advertisements. They can also alter the DOM, load conflicting versions of JavaScript libraries, and more. Awesome, I know. (This is being addressed, but is a persistent issue when add-ins have the ability to manipulate the DOM.)

Some of these issues can be avoided by serving content over HTTPS, but that still won’t enable you to bypass things like firewall blacklists (which led to the jQuery outage on Sky). Your best bet is to design defensively and make sure your users can still accomplish their goals on your site when some resources are missing or markup is altered.

We can’t control what happens to us in this world, we can only control our reaction to it.

Portier (pronounced “Por-tee-ay”) is a self-hostable login service that you can use instead of passwords. Portier sits between your website and third-party services like Google Sign-In to provide your users the fastest and easiest login experience, without ever needing a new password.

Best of all, Portier works for everyone, because it can fall back to traditional “click the link” methods of email confirmation.

• Email-first: Email addresses are decentralized, self-hostable, and useful on their own, so Portier uses email addresses instead of usernames to identify users.

• Connected: Whenever possible, Portier integrates with major APIs like Google Sign-In to provide seamless, in-browser identity verification.

• Decentralized: Anyone can host their own Portier Broker; there are no centralized dependencies.

• Open and Transparent: Because Portier uses email addresses, there is never any lock-in.

Portier is inspired by many projects and considers itself a spiritual successor to Mozilla Persona.