Using Emacs as a web browser

I want to make a serious deep dive into understanding cookies (as in web cookies). I'm wondering if using Emacs as my web browser while I do this would work. I've not tried it at all. The thought is that I will be able to dig out and look at the cookies more easily and rig up triggers for various events such as when particular cookies are fetched or changed, etc. Along those lines, are there any Emacs packages you would recommend to help facilitate this adventure?

https://github.com/emacs-eaf/eaf-browser

I'd take a look at https://browser.engineering/security.html#cookies for reference, and the `url-cookie-list` function is a good starting point if using eww (and maybe other emacs browsers?) but if you're looking for a hackable browser I'd try [nyxt](https://github.com/atlas-engineer/nyxt/)

Thank you. This looks very interesting. I read a big chuck of it but need to go back and re-read it as well as finish reading it.. I knew much of it but there it has examples of the different exploits which helps to clarify why things are done the way they are. My quest is to see if browsers can be taught to spew out disinformation to the trackers. Rather than blocking cookies, browsers could actively corrupt them to mislead the trackers. Passively blocking cookies doesn't close down the game since there are still people out there that don't block them. Actively corrupting the cookies I think would have a bigger impact. If 25% of the tracking cookies gave back misinformation, then the whole idea (possibly) could collapse. It is something that I've been wondering about for years now and decided to take a peek into it for real.

I haven't looked in to cookies specifically, but I have done browsing with both EWW and W3M. Both have big upsides, but I generally choose W3M because it is a bit snappier and more polished, and doesn't bind up my emacs thread; however, I EWW has a great reader-mode for eliminating cruft. Of course, both of those are textual browsers, which may not be what you are looking for. My primary browser for when I need non-textual stuff (which is most of the time) is FireFox (I am using exwm, so that is still technically in emacs)

Also, do not forget this: https://www.gnu.org/software/emacs/manual/html_node/emacs/Embedded-WebKit-Widgets.html and this https://www.reddit.com/r/emacs/comments/jyowe0/introducing_emacswebkit_a_successor_to/?utm_source=share&utm_medium=ios_app&utm_name=iossmf

I'm really looking forward to trying Nyxt once it works with WebExtensions and WebRTC. I use *way* too many extensions to even consider re-implementing all of them (especially Bitwarden and RES) in Common Lisp.

Wow, I took the course that accompanies this text book! Funny seeing it posted here. (Fun class and a great book)

Maaaaaaybe? Most cookies are hash blobs that are effectively keys to serve-side databases. All the data that you’re interested in is kept on the server; the cookie just says, effectively “I’m the same browser that came here the last time someone sent you $meaningless-but-unique-garbage.” You could send them back actually random data, but that’s very close to the same as getting a new cookie every time. The information that is used to “fingerprint” users mostly doesn’t come from cookies, but from other data the browser sends. You **can** bypass a bunch of those with highly programmable browsers, but that mostly just gets you put in the “non-standard/non-supported browser” code path for most web sites, and it doesn’t do anything for tracing at the network level.

This is one of my mid-term project — to get a superior browser in Emacs and ditch chromium/firefox. It's heavy WIP, take a look at my https://github.com/BlueFlo0d/xwwp. (My current progress is on the revamp branch but is not usable yet). I want to copy some ideas from Nyxt, but that will also require more complete xwidget API from Emacs core so I'm working on some patches to upstream. I'm super busy laterly unfortunately, hopefully I can make it usable this winter!

I like the idea, I wonder if not using Xlib would be better, maybe it is possible to embedded a browser engine directly. It would be great to still use Emacs on Wayland.

Thank you for your reply. I've done some Ruby on Rails development so I sorta knew some of what you said but I am lacking any real in depth real world knowledge. In particular, what data does the browser send in its "fingerprint" -- and why does it send it in the first place -- seems like a Microsoft Bill Gates stellar bad idea to me. But here is my idea: Lets assume there is a finite number of advertisers that you want to attack. Lets say there is Google and Facebook. So, two advertisers. These two advertisers would have a set of domains. I'm making tons of assumptions which may not be valid. That is part of what I need to explore. The first step would be to create a web site as well as a browser extension. Once an hour (lets say), the browser extension will go contact the web site and off load a packet of cookies and other browser fingerprint data based upon the domains. The key here is this will be a set of information and the set will be kept as a set -- not individual cookies or pieces. While it uploads its set of data, it also downloads a random set of sets of data that has been uploaded previously by another browser. Lets say it downloads 100 sets. Then, as the user surfs the web, one of the 100 sets of data is randomly picked and the browser sends and (if needed) updates that set of data. Perhaps the random selection changes as the user moves from web site to web site or it could change based upon time. The net result is that each browser that is using the web site / browser extension combination appears to the advertisers as someone else. Each browser would be impostures for other browsers. The surf history will get mingled together and ultimately would be totally worthless. The danger here might be mixing up cookies of, for example, banks. I don't know the consequence if the cookies from my bank end up in someone else's browser. But, it seems like it would be easy to filter out AND I assume there are already projections, like Rail's authentication_token, to secure bank interactions (or anything done via post, put, patch, or delete). Again, I'm not real sure about most of this.

The web site sends the client an arbitrary string. The client sends it back. There is no inherent meaning to the arbitrary string. Although each site *might* assign special meaning to any part of the arbitrary data, there is no pattern that other sites (or even parts of the same site) will follow. If a client uploads the same random blob as some other client, the web site might think that it’s the same user as that other client, but given the other data the browser sends (IP, browsers version, os, etc.) the server might also not believe it. The key thing that you’re missing is that sites use these arbitrary strings to verify that the user is “logged in”. If there isn’t such a blob, or if it doesn’t match, then the site will not treat the user as logged in, which will usually either bounce you to a login screen or just not show you anything. You can try this out by disabling cookies entirely and seeing how much of the web doesn’t work.