this post was submitted on 21 Mar 2024
27 points (100.0% liked)
askchapo
22762 readers
391 users here now
Ask Hexbear is the place to ask and answer ~~thought-provoking~~ questions.
Rules:
-
Posts must ask a question.
-
If the question asked is serious, answer seriously.
-
Questions where you want to learn more about socialism are allowed, but questions in bad faith are not.
-
Try !feedback@hexbear.net if you're having questions about regarding moderation, site policy, the site itself, development, volunteering or the mod team.
founded 4 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
By default Firefox does not allow sites to access cookies they have not created. So a non hexbear site will not be able to see that you have cookies from hexbear stored on your browser.
https://blog.mozilla.org/en/products/firefox/firefox-rolls-out-total-cookie-protection-by-default-to-all-users-worldwide/
That's not really how that works, if that was how cookies worked then session hijacking would be a constant problem and the fabric of society would be ripped in half.
Here's a video explaining how Firefox's state partitioning thingy works
how so? I literally get prompted when microsoft.com subdomains want to use a cookie from microsoftonline.com, so it seems to be pretty strictly enforced
This feels like a Renge and Shiori talking about ball physics moment
I mean, the way I interpreted Lemmygrabber's comment was that it implied that on other browsers, websites can just read cookies from other websites. So I go to, like, sketchysite.xyz and it loads in a YouTube video and then all of a sudden my Google account is stolen because the website could read my cookies for YouTube/Google, and that meant that it could copy them. On the other hand, the type of thing where microsoft.com wants to use cookies from microsoftonline.com seems pretty different to me, because that's basically just making a regular request to microsoftonline.com, right? It just happens to be that that request includes a cookie in the header.
That's how I understand it at least.
oh I didn't see your video link before. Yeah, that was already not a thing of course, it would break the security of basically every site, I guess it just didn't cross my mind. At a glance when I read his comment I didn't register it as saying "ff does this (and chrome doesn't at all)", but I see what you mean now.
And no, its not too different, the video you linked covers the single-sign-on use case pretty well (which is effectively what MS is doing even though they could have just used the same domain lol) at around 5:40. The page I've loaded is microsoft.com, but it is trying to read a cookie that belongs to microsoftonline.com because that's where the sign-in page is so that's where the cookie is. Firefox prompts me to allow it, rather than blanket block or blanket allow, so that SSO can still work but I can't be silently tracked.
At the risk of revealing my own illiteracy, I thought that for single sign on it was like, you load the web page and it includes a request to microsoftonline, and the request that your computer sends to microsoftonline includes the sign-in cookie, and then microsoftonline responds to this by sending a unique session token and probably some other stuff to microsoft.com, and then microsoft.com sends the new session token to get stored on your computer.
I'd honestly just kinda assumed that that was more or less how SSO worked so maybe that's wrong though. If it is and I've been talking out of my butt the whole time then please go easy on me.
No you're right, but thats also how tracking cookies would work, including a request back to facebook, or an ad network, or whatever. So that is what firefox is blocking, by partitioning cookies by what site you are actually on, not just what site a request is going to.
Chrome is finally slowly rolling out something similar this year (like they made a big fuss about rolling it out to 1% of users)
So basically we both understood everything from the start but were bad at communicating it?
sounds about right 😅
That's true but third party cookies exist and could hypothetically be used tp track your activity on hexbear by a third party.
why are you replying to yourself? Also, no they can't.
Then what's the deal with third party cookies?
the deal with third party cookies, is that you go to example.com, and example.com loads in code, or assets like images, from another site: say, a facebook like button. Up until the last few years, since that secondary request was going to facebook.com not example.com, it would be able to set/view cookies on your browser that belonged to facebook.com, not example.com.
That allowed them to identify your browser individually (and tie to your user account if you had one) across all sites on the web that embedded a facebook like button, building a profile of what sorts of sites you go to. But it couldn't detect your entire browsing history, just when you went to sites with embedded bits from facebook. Hexbear doesn't embed that stuff
Thanks