• he/him

I occasionally write long posts but you should assume I'm talking out of my ass until proved otherwise. I do like writing shit sometimes.  

 

50/50 chance of suit pictures end up here or on the Art Directory account. Good luck.

 

Be 18+ or be gone you kids act fuckin' weird.

 

pfp by wackyanimal


 

I tag all of my posts complaining about stuff #complaining, feel free to muffle that if you'd like a more positive cohost experience.

 


 
Art and suit stuff: @PlumPanAD

 


 
"DMs":
Feel free to message as long as you have something to talk about!


Can someone please explain what CORS replaces, because I know sites can load things from other sources, and why everyone wanted to do this instead? To me it seems like it'd be less secure option if anything, but again I Am Not A Web Dev and I only know enough to be Dangerously wrong about things.


You must log in to comment.

in reply to @plumpan's post:

the "default option" is the same-origin policy. with that, you can load images, audio/video and full well-formed javascript scripts from other websites. you can also POST arbitrary forms to other websites without confirmation, but you can't read the result of that. one thing you can notably not do is make remote API requests that return JSON/XML/etc responses; you can use the form sending technique for historical reasons but you can't read the response in any way. you're sent the user elsewhere, they are no longer on your website if you do that

most of the 2005-2010 dynamic web was built with those assumptions, so things got in an interesting position: restricting things further breaks web apps, which had already had to make sure they're secure with those assumptions (and would have to because existing browsers wouldn't be updated for years - this was when people were still running 10 year old IE versions). meanwhile, adding new capabilities on top would potentially break the security of existing web apps

so CORS is what you use if you want other apps to call your API, basically. if you're running cool-weather-api.example.com and you set Access-Control-Allow-Origin: * then someone on isitrainingtoday.example.net can make requests to your weather API and actually read the results. otherwise, they can sort-of-make requests, but they have no way of getting at the results

So previously it would have been possible on the backend to route API calls from the same domain to a different server or group of servers based on the path, but now one can just use a completely different domain? Obviously that's more flexible and I assume is the main point?

Again sorry if this sounds dumb, I only know a smattering of web dev so I feel like I'm missing some fundamental objectives behind this. Obviously CORS means it could be pulled from a different website rather than just "my api server", I don't know if that's as significant as I assume it is. How would a site like say, Twitch, operate without CORS? It loads in video data via HLS which I assume just falls outside of the "JSON and XML response data", but also chat messages. I don't think those all run through the primary origin?

but now one can just use a completely different domain

yep. back in the day, if you had an app running on thing.example.com you couldn't even talk to api.example.com, you had to set up proxy stuff so that thing.example.com/api would end up making calls to the right server, or you could start pulling from the bucket of rather cursed techniques to achieve cross origin communication anyway (JSONP or iframe postMessage depending on the era)

How would a site like say, Twitch, operate without CORS?

so, for livestreaming, you essentially need media source extensions; that basically means that javascript is responsible for downloading video parts and individually feeds them to the browser, hopefully just in time so the video doesn't stutter. with MSE, javascript can get those parts in any way. this has to go via fetch/xmlhttprequest, so it needs to either be allowed by the cross-origin policy or CORS

so without CORS but assuming the site was built like it is now, twitch's video player would only be able to fetch from https://twitch.tv/*. not even subdomains would be allowed. they'd be forced to do one of three things:

  1. keep using flash, which had CORS before CORS existed (via crossdomain.xml files), and hope browsers would keep flash forever because of this
  2. set up some kind of massive CDN that handles ALL things twitch; the website, the api used for all kinds of stuff, the gigantic video parts, the chat, nearly everything, all on https://twitch.tv. they could probably split out payments to a separate subdomain which would be one massive headache lifted, just send people to payments.twitch.tv when they have to put in their credit card info (i think they do this even now?)

...and 3: because twitch is in control of their full stack, they could use iframes, which you can embed from somewhere else and then follow their own policies based on where they are loaded from. (iframes were a very bad idea, but well, it'd seriously break the web if removed now. instead, webmasters can block it nowadays and that's common security advice. it's even in the thing i copied from somewhere for my own perpetually unfinished website)

anyway, that would mean they load the video player itself in an iframe loaded from for example https://newyork1.twitchvideocdn.example/examplestreamer and the chat in another. the iframe would be in charge of playing the video and would only be able to load from https://newyork1.twitchvideocdn.example/* but that's ok because the video HLS fragments would also live there. likewise, chat would be loaded from https://newyork1.twitchchat.example/examplestreamer or whatever, and that server would have to handle all the stuff. if you wanted a chat command that plays confetti on the client side, things would get very annoying quickly, but it'd be... doable

It took me a bit to digest this.

Actually, loading up twitch I think it might be using iframes? It's not using CORS but all of the video data seems to come from twitchcdn and ttvnw. Not sure how it loads chat messages...

... but this is all getting a bit deep in the hole. I think I'd need to actually learn some web dev to understand why a site is structured how it is.

Thank you for taking the time to explain all of that.

yeah ok, this is all kind of complicated stuff, as is the rest of the web. unfortunately it's really dang hard to explain without knowing everything that led up to it. everything vaguely security-related on the web is like that

for what it's worth, i'm seeing basic CORS headers on ttvnw responses, but i dunno if they're trying anything new with it