gabrielbezerraMar 4
Julia Evans

I'm back to thinking about CSRF: why is it useful for sites to be able to embed resources (like <img src="othersite.com/whatever.jpg">) and for the browser to send the user's cookies to the third-party site?

There's "ads" and "tracking" obviously but I feel like there's another actually-useful-to-users reason I'm not thinking of

Mar 4 at 7:55pmWeb
Show threadBen 🏳️‍⚧️🍉Mar 4
@b0rk When half of your infrastructure was set up by another company on a separate domain it can be pretty handy. It's the situation at my current work but that must be pretty rare really.
Show threadEvan ProdromouMar 4
@b0rk A pretty common one is interaction buttons -- Facebook like or share buttons, for example.
Show threadJulia EvansMar 4
@evan this is making me realize i don't know how those buttons work, I should look into them
Show threadEvan ProdromouMar 4
@b0rk yeah, it's been a while since I messed with them. We made one for StatusNet a long time ago, and I think it was an <iframe> or something similar. This was back when browsers were pretty blasé about passing cookies around; a lot has tightened up since!
Show threadGlyphMar 4
@b0rk consider a service like S3. If I host my images there, in *principle* I really ought to be able to point my URLs there without intermediate faff beyond "yes, you're allowed to host stuff here". Cookies could be used for billing quotas or other other sorts of tracking that are not necessarily surveillance or advertising.
Show threadJulia EvansMar 4
@glyph huh I thought S3 just does billing through your S3 account, I'm having trouble imagining why it would need cookies from the user's browser
Show threadGlyphMar 4
@b0rk it does, but one could *imagine* a world where the user were tolled micropayments rather than the bucket owner just being charged and then figuring out auth & payments for the downloader on their end
Show threadJulia EvansMar 4

@glyph do you think there's a service that actually works this way today?

(i'm trying to come up with an explanation of why browsers work this way and it definitely has to be based on "things people very commonly do on the web already", not "things you could hypothetically do")

Show threadMad EngineeringMar 4

@b0rk @glyph A lot of forums allow public posting but won't host images, so any desires images must be hosted by third party services like photobucket or image shack.

...both of which recently purged their archives, breaking the entire thing.

Show threadJulia EvansMar 4
@madengineering @glyph do users have to be logged in to photobucket in order to view the images?
Show threadMad EngineeringMar 4
@b0rk @glyph No, the images were publicly hosted for everyone to see, that was the whole point.
Show threadGlyphMar 4
@b0rk Given how heavily it's discouraged now (SameSite=None is already entirely broken in a lot of contexts, many of which are enumerated here <https://privacysandbox.google.com/cookies/prepare/overview>) I can't imagine anything could work like this today.
Third-party cookie restrictions  |  Privacy Sandbox

Provide a great experience for your users, whether or not third-party cookies are available.

Privacy Sandbox
Show threadGlyphMar 4
@b0rk Anything that would would have to have big "this won't work on Safari, or on any Apple device, or on most enterprise deployments of Chrome" which would pretty severely limit its audience.
Show threadGlyphMar 4
@b0rk I remember *using* this functionality back in the day for stuff like federated sessions, but that boils down to the “tracking” you mentioned previously, and there are better mechanisms available now anyway (not least of which are just “CNAMEs”)
Show threadcthos 🐱Mar 4
@glyph @b0rk You actually can force the downloader to cover the costs via the S3 command line, but that's never used in the CDN use of S3.
Show threadDDRMar 4
@b0rk On the old forums, hosting often didn't want to do images... too large? It was handy to be able to link them in from a dedicated hoster, like imagebin or something.
Show threadJulia EvansMar 4
@ddr do you need to send the user's imagebin cookies to do that?
Show threadDDRMar 4
@b0rk Hmm, I think there were some that would only let you see images if you were logged in, but I might be wrong.
Show threadDDRMar 4
It's been a long, long time. And I think it was mainly a hostage-taking tactic anyway.
Show threadgroxxMar 4

@ddr I think I remember a couple things like this quite a long time ago, so I think you are remembering correctly. Relatively insular free community hosting, basically, with tight quotas for people who are not part of the community to prevent widespread hotlinking.

You could do this with an iframe nowadays too, but sizing it correctly is still basically unsolved, I think? And it would probably use more resources, though not by much.

But then again, I haven't heard of or thought about hotlinking as an issue for a long time now. I kind of wonder what changed. Maybe everyone just uses CDNs? Or sites copy files a whole lot more?

Show threadDDRMar 6

@groxx. I think disk storage became like 100x cheaper or something, so the cost of hosting them yourselves basically went away. It was always a usability/reliability mess anyway.

To some extent, it's also been a while since I've been on a forum at all, as well... 🤔

Show threadJulia EvansMar 4
@ddr that seems very possible!
Show threadkeeferMar 4

@b0rk any time you have a different origin for a backend.

Eg api.example.com vs www.example.com

Example Domain

Show threadJulia EvansMar 4
@keefer i think i'm explaining it badly, I'm not trying to talk about CORS
Show threadgroxxMar 4

@b0rk afaict almost any "need" can be solved by an oauth-like redirect to construct a local cookie, an iframe, or links that contain the content (e.g. for share buttons).

and having disabled them completely for many years: very nearly the only problems come from companies which are a conglomerate of many companies and can't ever get their infrastructure to work together.

Show threadJulia EvansMar 4

@groxx thanks, it's really useful to hear that almost nothing breaks when you disable them completely. I should try it and see what happens.

do you use a browser extension to do that?

Show threadgroxxMar 4

@b0rk there used to be more issues when browsers started clamping down on third party cookies, but it has been mostly smooth sailing for at least a few years now. The GDPR cookie banners have always struck me as weird because a reasonable browser simply doesn't store them at all, and that's also your way of opting out *without* the site's consent.

(it does nothing for server-side collection, of course, so that part of it is still useful (if it actually does anything at all, I doubt it does usually))

Show threadChristine Lemmer-WebberMar 4
@b0rk There was a debate within the W3C Technical Architecture Group that I was pointed to at one point by Jonathan Rees, former member of the TAG, there was a debate between whether to go a capability security approach for the web or a perimeter security approach. The TAG, per my understanding, was leaning towards ocaps but some of the big web players said "well we are already doing the perimeter security approach" and so, alas, that won by default, and we got CSRF :\
Show threadRenaud BerthierMar 4
@b0rk At web browsing dawn, maybe preferences on pictures, like idk, preferred size, preferred format (though that could be deduced with User Agent)? Maybe auth with session id, as pictures may be protected? I think that's how Facebook did at first: without login you could not see (or hotlink) a private picture.
Show threadMichael HansonMar 4
@rberthier @b0rk Preferred format is supposed to be handled by the Accept header, which has been around since the just-a-little-past-dark-ages. Per-user authentication was really the big one.
Show threadRenaud BerthierMar 4
@michaelrhanson @b0rk You're right about Accept!
Show threadstep  Mar 4
@b0rk ist das nicht Ajax-irgendwas?
Show threadTheMagicalCMar 4
@b0rk the third party site could be hosting files available by authenticated access only, and allowing the first site to issue auth tokens. I’m not sure I can think of a specific use case where I’d want to do this. Maybe corporate trainings getting licensed from providers and then served from the licensee’s site?
Show threadOndřej ŽáraMar 4
@b0rk Generally speaking, to enable loading authenticated content from other sites.
Show threadTomáš JanoušekMar 4
@ondras @b0rk But how do you know the user is authenticated on that other site? Can you rely on it?
Show threadOndřej ŽáraMar 5

@liskin @b0rk Do I need to?

I mean -- the typical use case here is to be able to sign in to "google.com" and have your google avatar shown at "youtube.com".

Alternatively, visit "myeshop.cz" and include a per-product discussion embed iframe from "we.provide.forums.net".

Show threadTomáš JanoušekMar 5
@ondras @b0rk Oh, right, so stuff where you're always getting some content back, it just might or might not be personalised. Got it!
Show threadNiels AbildgaardMar 4

@b0rk I always thought it was just people mapping domains to servers (pre-LB), pointing directly to files on self-managed but perhaps authenticated services.

Like documents.example.com may hold the corporate PDFs and require authentication to reach, but the site is navigated at www.example.com.

Before CSPs it was all or nothing, right? Not sure it's a good reason, but I recalm hearing of these single-URL-pr-server setups as a reason to use subdomains even.

Show threadGlenjaminMar 4

@b0rk the one case that I can recall was for Single-Sign-On with an actual shared session (instead of just central credentials)

I forget all of the details now, but recall we had a sign out page that included a resource of each service - so it was single sign out too

Show threadryanMar 4
@b0rk back in the day, it let you tune your serving workload so static assets could be served from boxes with ram and fs cache away from the dynamic/server-side page rendering (php, cold fusion, mod_perl, etc)
Show threadBen BerryMar 4
@b0rk (Not how I understand it to be used, but I could imagine a use case for it working this way)
Something like Venueless, a conference software, where video streams from third-parties are embedded.
I could imagine a case where the third-party uses some cookie authentication.
Show threadDion WilliamsMar 4

@b0rk Not _quite_ matching your question but the Stack Exchange network uses cross-domain image requests while you're signing in on one domain to sign you in across the whole network.

This relies on the cross-domain image *response* setting third party cookies, instead of the image *request* sending cookies.

I'm not sure how reliable this works since browsers got stricter about third party cookies. More info here: https://meta.stackexchange.com/a/376333 (first couple links in the answer have even more info)

Did something change with Stack Exchange's cross-domain login process? (no longer working)

I have my web browser set to block all third-party cookies. The only place where this is an issue is on Stack Exchange sites, where it prevents a log in action on one site from successfully loggin...

Meta Stack Exchange
Show threadSean CoatesMar 4
@b0rk I read through the replies here and I think maybe one key idea was missed: early browsers did this because it’s the simplest thing to do. Then people built interactions based on this (such as the FB Like button). Then browsers couldn’t remove it without breaking things so they didn’t. Then ad tech weaponized it.
Show threadJulia EvansMar 4
@sean yeah what i’m trying to work out is what specifically the “things” are in “Then browsers couldn’t remove it without breaking things”
Show threadShadSterlingMar 4
@b0rk that kind of thing is needed for centralized SSO to third-party hosted services. Where you log in via auth.myorg, to use a service at some.provider/myorg which makes use of myorg.other.provider. Each provider’s page/HTTP resource has to check with auth.myorg to validate your login, for which auth.myorg has to get your login cookies. The scripts loaded from some.provider/myorg send a request to auth.myorg to get a token to send to myorg.other.provider
Show threadShadSterlingMar 4
@b0rk (this is why all the login forms have email and password on separate pages now; they need your email address to look up which auth service to use so they can have the appropriate service ask for your password)
Show threadShadSterlingMar 4
@b0rk … I would much rather impose the requirement that cookies only be shared within subdomains of the same domain, so it would only work if some.provider/myorg lived at some.provider.myorg, and myorg.other.provider at other.provider.myorg. That would make a whole bunch of things a whole lot easier. (It should also apply to the thing I can’t remember the name of, where subdomains are rented, so providers I use for mysite.geocities would have to be at *.mysite.geocities not *.geocities)
Show threadEvan DowerMar 5
@b0rk
Maybe badge sort of things where it shows a different image depending on user info, like an image button for subscribing/unsubscribing that shows whether you're currently subscribed (for another service like Facebook, YouTube, etc.)
Show threadRogan DawesMar 5

@b0rk I may have missed other explanations, but I just wanted to clarify one thing:

When Site A embeds an image from Site B, your browser includes only Site B’s cookies that you may already have when requesting that image, not any of Site A’s cookies. This is according to the Same Origin Policy.

And the SameSite flag when setting the cookie allows the site to control whether this actually happens or not.

Show threadRogan DawesMar 5

@b0rk and then to answer the original question:

There are some sites that retrieve user-specific (or authenticated) images from other sites. It therefore requires that site B be able to verify the identity of the user, however that is bootstrapped. Ie log on to Site A, site A passes the identity to site B (oauth, etc), site B sets its own cookies based on that identity, then site A can refer to site B’s images.

Show threadzakiusMar 5
@b0rk for regular image tag? not much
for iframe? say it's a yt embed, the premium status makes a difference
Show threadSergei SmaginMar 7

@b0rk I don't know! Speculation: looking at the other things that are allowed to be embedded (scripts, styles, video, iframes) these are pieces of content that are black boxes for the page. Like, you can see it, js on the page can't.

So, as long as it's safe-ish, it's also handy, who wants to serve their video directly from the site when CDN exist.

https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Same-origin_policy#cross-origin_network_access

Same-origin policy - Security | MDN

The same-origin policy is a critical security mechanism that restricts how a document or script loaded by one origin can interact with a resource from another origin.

MDN Web Docs
Show threadÖlbaumMar 9
@b0rk I’m logged in on a web site. It shows me a graph of my company’s revenue. I’m the only one allowed to see it, but it’s served from a different domain, for architectural reasons. My session cookie is needed. Does that apply?