Web Storage APIs


Maximiliano Firtman

Maximiliano Firtman

Independent Consultant
Web Storage APIs

Check out a free preview of the full Web Storage APIs course

The "Origin" Lesson is part of the full, Web Storage APIs course featured in this preview video. Here's what you'd learn in this lesson:

Maximiliano provides a brief overview of essential core concepts of browser storage, including origin, web client, device, and user. An origin is an internet domain composed of the protocol, host, and port.


Transcript from the "Origin" Lesson

>> So concepts that we need to understand, and probably you know, but let's declare these concepts again to understand then the consequences of what we're going to do. We have origin as one of the most important concepts. We have a web client. Then you say, okay, what's a web client, is it a browser?

Well, a browser is a web client, but there are other web clients available. I will talk about that in a second. A device, that's simple. And a user, that's also simple to understand, okay, we are users. So we are going to get deeper with origin and web client, I think that device is straightforward, the same as user, okay?

But have in mind that when I'm talking about the user, I'm talking about the person that is using the computer. And you say, yeah, I know what you're saying Max. But have in mind that there are a couple of operating systems where on the same device, you can login with different users.

So it can be a multi-user experience, so just remember that, okay? Sometimes you can share your laptop with your partner at home. And maybe each of the persons have a different user, or maybe not. Or maybe they are sharing the OS user, okay, so it can be even a guest user.

So getting deeper with the origin, okay? Quick and dirty definition, it's the domain, so our domain. But technically it's more than that, okay? If you wanna remember just one thing from the origin, it's just the domain. So frontendmasters.com, that's the origin, okay? But actually, it's more than that, it's protocol + host + port.

So different protocols, for example, HTTP and HTTPS on the same host, the host can be the domain or it can be an IP address. So if you have the same IP address, the same domain but different protocols, you have different origins, okay? So, for example, firt.dev on HTTP, firt.dev on HTTPS, www.firt.dev, our firt.dev column 4000, that's the port, all of these origins are different, okay, completely different origins.

So it's the same domain but on different contexts, okay? We need to be careful with, first, the www prefix, okay? We don't use it too much today, but it's still there, okay? But have in mind that when you have a www prefix, you have a different origin. And to make things more complicated from a user's perspective, sometimes today modern browsers, such as Safari, they are hiding that prefix by default.

So when you're browsing a website you don't see it, okay, until you click in the URL bar and then you can actually see the details and see the full domain. So have in mind that, okay? So another issue is country TLDs, Top Level Domains. For example, Amazon, they have amazon.com, they have amazon.es from Espana, that's Spain, or amazon.co.uk.

So is it the same origin? No, it's actually a different domain, okay? So if you have a PWA or a website where you have different country TLDs, you need to understand what will happen with your storage because it's not going to be so simple, okay? Mostly if you wanna share the storage between those domains.

So another thing is subdomains, okay? So if you have a third lever, a fourth lever domain, so different hosts, technically they are different origins. Okay, so just have in mind that. So I'm talking about this because as a spoiler and probably you already know this, so our storage is origin-based.

So when we're storing data, who can actually access that data, any other codes running on that same origin. So not on subdomains, not on other country top level domains. Yeah?
>> It's kind of an opinion question.
>> Go ahead.
>> But regarding protocol, I'm thinking back to that discussion of one request, pull the zip, etc.

In your kind of background in recent years, have you encountered many use cases for, maybe not IPFS, but FTP protocol or other protocols, or is it pretty standard these days that HTTP, to use HTTPS?
>> Well, when we are talking about web clients, at least, when we are talking about web clients these days, it's HTTP and HTTPS.

And I will say that today it's HTTPS. So we are targeting 70% of the web today is HTTPS, of the domains at least. And we are going there because of many reasons, not just because of security but because of evolving the web. So today, to evolve the web protocols, to evolve HTTP, for example, to HTTP/2 and now HTTP/3, the only way to do that safely worldwide was actually to wrap those TCP packages in HTTPS.

So in SSL, using SSL. Without that, there are a lot of routers out there in the backbone infrastructure of Internet that were actually dropping the packets because they were saying, what is this, HTTP/3? No, that doesn't exist. So they were dropping the packet. Because of that, that's why in the past five years, six years, we were pushing the whole web to HTTPS, okay?

But FTP, do you have other protocols, like old gopher, if you have ever heard about that, so they're not actually there for the web. Even modern ideas, for example, right now there is an API kind of a solution available only on Chrome that lets you package a web app in a package, okay, and then it can distribute that package offline.

For example, I can give you a USB key with a website, or you can download that through a Bluetooth beacon. So you can get into a room without connection, like you're in a black box without any Internet connection, and using Bluetooth you could download a website and run the website.

So it's a different protocol internally, but it's on top of HTTPS. So the browser when you open that, it will look like HTTPS. So even with new modern ideas, okay, that's web packaging, by the way. So even with new modern ideas, we're still making or keeping the HTTPS as the main protocol for everything.

So the only real situation where you may have two different origins changing the protocol is HTTP versus HTTPS. But if you're creating your website these days, you won't have that problem, it will be HTTPS only and that's all. In case you have a legacy app and you have maybe half of your server still running on HTTP and for some reason, you can't upgrade.

Well, you may have a problem there. But I think in the future, I don't see that as a problem. So changing the protocol is not really something that will happen.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now