I think hexbear has them. Is it a connection thing where cookies spot other cookies? Do tracking cookies matter when it comes to insurance and therapy sites/apps? I’m thinking about therapy that I saw advertised on YouTube, and I bet they’re somehow sketchy. And their app requires the use of third party tracking and cookies.
I just don’t want these sites/apps to see I’m a communist.
So hexbear (like any site you log into basically) uses one cookie to store your login token, which lets you use the site without submitting your username and password every time you do anything and stay logged in between sessions. This is not a “tracking” cookie, and other sites are not able to access it. Browser security and privacy around cookies has improved a lot over the years.
tracking across the web by social networks and advertisers, afaik has been accomplished by having a little piece of the website you are on load in from an entirely unrelated server (like an embedded facebook like button, or an ad). when that code loads in, it can read its own cookie (from when you last browsed facebook or saw an ad from that ad network), and tell what site you are loading it from, keeping a record of your activity over time around the web.
Hexbear does not embed these sorts of malicious bits of code into the site, and scrubs the “referrer” header so that your browser doesn’t reveal you came from hexbear when you are linked to an outside site from here, so it is protected from other sites you browse being able to track you here
TL;DR: You have nothing to worry about. This is something the Hexbear developers have already considered.
To explain in full:
So as I understand it, a cookie is a part of the header of an HTTP request and response. To really sort of simplify things, this means that a cookie is basically just a little string of data that a website sends to you, which is then saved to your computer so that it can get sent back to the website the next time your computer requests something from that website. This can be used to store information long-term, so common uses of cookies include shopping carts, user preferences, saving progress in browser games, keeping users logged into websites, and so forth. Websites can at any time choose to stop recognizing your cookies and you can choose to delete your cookies through your browser’s settings at any time. Cookies are not shared between apps, so any cookies on your phone’s browser will not be seen by the therapy app. So all in all there’s no way that a website or app can magically know from its own cookies what other cookies that somebody has.
For cookies to be used for tracking across websites, i.e. the therapy app to know you were on Hexbear, your phone would need to be on Hexbear while also requesting a resource (e.g. an image) from the therapy app’s central server — or in other words, you would’ve had to have seen the ad for the app on Hexbear, and even this is assuming that (1) the ad was a third-party request and (2) your browser has third-party cookies enabled. More and more web browsers are disabling or heavily restricting third-party cookies by default, including Firefox and I think Chrome is planning on doing that soon. All the other forms of cross-site tracking that I know of and would be relevant here, like checking your IP address and user-agent string, would also require your phone to make a request to the unscrupulous website while browsing Hexbear. But these methods are less reliable than a cookie.
I do remember when I first joined Lemmy (this was when Blåhaj was my main instance) that there were two popular images that freaked people out because they SoMeHoW kNeW the users’ locations and what browser/app they were using. This was because the images were stored on third-party websites which had been programmed to serve anyone attempting to load that image, a different image depending on their IP address and user-agent string. This trick becomes a bit less magical when you toy around with a user-agent string editor and have a VPN, so that you can tell the third-party websites that you live in Bali and your web browser is called Ligma.
These two images did raise concerns with Lemmy users about privacy: the trick was only possible because Lemmy instances, at least as of four months ago, by default did not proxy images, and this very well could be used in more unscrupulous ways.
At the same time, Hexbear is unique among Lemmy instances I’ve seen by blocking third-party images in comments sections. This makes me think that the Hexbear staff are already aware of the possibilities of tracking on Lemmy and have acted accordingly to protect users’ privacy, and this seems to have been confirmed by opening up Firefox’s web developer tools and going to the “network” tab and browsing Hexbear: the only requests that Hexbear makes to other websites are to other Lemmy instances, which have been pre-approved. Nothing else.
So all in all, who knows you’re using Hexbear? Probably God, whoever handles your DNS requests (probably your ISP or mobile data provider), and if you’re using Google Chrome… Uhm, don’t?
there were two popular images that freaked people out because they SoMeHoW kNeW the users’ locations and what browser/app they were using
Oh hell yes that takes me back to the days of gamefaqs and people linking “this user sucks” to the profile of whoever clicks on it
Hexbear’s taglines also sometimes display the name of the logged-in user and that definitely freaked me out for a moment the first time I saw it
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.
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
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?
install privacy badger on your web browser
Is it good for Android?
deleted by creator
