Cookies, and who/what can read them and what do they contain
Stu H said, 1714366479
That's a whole new avenue of hard learning that I'm not sure I want to go down ...
I've seen some of the Pi chat on here - I think normally between Unfocussed Mike and waist.it and to say it goes over my head would be a slight understatement.
I'm more a 'turn it on, turn it off, turn it on and hit it kinda guy' ...
Stu H said, 1714366690
If I can ask a supplementary question ...
How do tracking cookies work?
Stuff that I've [skim] read seems to indicate that they read where you have been.
Could Shitebook be using the same technique?
As a layman, this kinda stuff is both interesting [if kept in simple terms] and worrying
Dabhand16 said, 1714371962
Have you tried using a browser that does not spy on you? Try Firefox and see if there is any difference. I don;t get that content when on Faceache.
TheFuntographer said, 1714381053
Stu H said
That's a whole new avenue of hard learning that I'm not sure I want to go down ...
I've seen some of the Pi chat on here - I think normally between Unfocussed Mike and waist.it and to say it goes over my head would be a slight understatement.
I'm more a 'turn it on, turn it off, turn it on and hit it kinda guy' ...
In this respect - I'm a set it and forget it type of guy. I'm not sure about fiddling with my ISP router - but a pocket money box of tricks is techy enough to impress me, but seems respected enough to use.
Unfocussed Mike said, 1714387308
Stu H said
If I can ask a supplementary question ...
How do tracking cookies work?
Stuff that I've [skim] read seems to indicate that they read where you have been.
Could Shitebook be using the same technique?
As a layman, this kinda stuff is both interesting [if kept in simple terms] and worrying
All cookies are kind of for tracking, in a way. The most important things to know here are:
====
- HTTP(S) is "stateless". If a browser requests a web page, then the user clicks on a link back to the same server, the server essentially does not know that the second request has anything to do with the first, which makes web apps difficult!
- Before cookies, we established state by dynamically adding a session ID into all the links on a page, so it would come back as part of the next request, e.g.: http://foo.bar/session/43534bcvh636565/the/page/
- This is *really* insecure (because when you share a link with someone else, you share your own session!)
- So the idea of a cookie was repurposed from elsewhere (X Window system authentication)
- Servers send cookies with pages or other things (like images, or javascript, or stylesheets)
- Javascript on a page can create or delete cookies associated with the site/domain that sent the page.
- And the browser always sends the cookie back with any request matching the cookie's original site.
====
So they are used by the web site to:
- thread requests together into an identifiable session,
- or recognise a returning user,
- or store a small amount of preferences data for the site locally, like whether you wanted large type, or what theme you prefer on a site, or whatever.
- or all three at once.
(There are also other newer "local storage" concepts than cookies for storing larger amounts of data in a browser, per site)
====
Now, how can this be used for tracking?
Well, Google Analytics uses it in the following way for tracking users *within* a site:
- Website developers add a request for a small piece of Javascript into the pages on their sites, with a custom tracking ID embedded that identifies their site
- That script is requested by each browser accessing the site
- And because it is requested from/sent by Google, it gets a google.com cookie, even though it was added to a page on foobar.com.
So Google will get sent that cookie on their own pages, and can also use it across sites, for tracking whether users see an ad and then working out whether they click through to the connected site.
Facebook provides a similar ads network, but also "tracking pixels" and the like.
A tracking pixel is just an image you add to your page, but served from Facebook. And because it came from Facebook, it gets a facebook.com cookie, basically.
So when requesting it, a browser will send any relevant Facebook cookies with the request. Including the one that identifies the user's Facebook session ID.
So this connects the page request on foobar.com to the user who is currently logged into Facebook from that browser. They know who visited the page with the tracking mechanism.
So if website developers can be persuaded to add tracking pixels, or Facebook ads, or Facebook share link widgets, then *they* can be given more information about their users, and Facebook in return can collect vastly more information about users, as they visit all the sites with these things embedded.
====
Sorry this is really wordy. I did try.
Edited by Unfocussed Mike
Stu H said, 1714392873
No worries about it being wordy ... thank you for taking the time to explain your craft in simple terms.
I'm going to read it again later when I'm on a bigger screen and not in my own work mode.