I hate, hate, HATE session recording, yet it’s absolutely everywhere on websites, as well as applications.
Basically, session recording refers to, well, recording a person’s browsing session, usually including all mouse and possibly keyboard activity. Most session recording services I’ve seen literally generate a video of the user’s interactions with the web page, much like a screen recording.
The amount of data this gives the website is enormous, and enormously invasive. They can see literally everything that is showing up on your screen on a second by second basis, albeit only the parts that are displaying the website, including what content was there, where your mouse hovers, what you thought about clicking but didn’t, everything.
They quite possibly also know everything you typed, especially if it was typed into a text field. I hope you didn’t accidentally enter your username and password because thought you were switched into the other browser instance. Did you type out half a post but decided that you’d rather not have the internet know that? They have that now. Did you hit control-V but forgot that your social security number and not some mundane thing was in the clipboard? Now it’s theirs. Did you delete an image that you posted? Even assuming that the original file was deleted, it still exists in the form of session recordings.
There are also ways of fingerprinting a person’s “browsing style” by analyzing how they interact with UI elements. This can be used to identify a person, not just a browser or a computer.
Worst of all, session recording is often provided by a third party, so not only does the site itself have this data, a third party does too, possibly forever. That’s to say nothing about what happens if either company gets hacked.
Session recording is the bane of the web surfer’s existence, and there is no way to completely block it without outright disabling JavaScript. You can block the events associated with mouse and keyboard activity, but that breaks websites and they can still session record the initially visible page.
So, if you run a company that provides session recording, I just want to say: “FUCK YOU! You are ruining the internet!”
Also, based on the fact that my JavaScript events blocker does not detect the typical event handlers that are symptomatic of session recording on Lemmy, good on you for not using it!
Good to hear. I know a lot of noscripts are blocking this entirely, because it is a single page web app.
In the future, I want to contribute to making Lemmy JavaScript-optional at least for viewing the forum.
I would love a JS free/optional Lemmy! I currently have two browsers installed. One with JS off with specific exceptions, configured so tracking me is an enormous pain, and a bunch of add-ons that make browsing better, and another browser for all the sites I can’t use with my other browser.
Also, just curious, why not just install uMatrix and have websites default to no JS, and temporarily enable scripts (and other features) on a site by site basis? That’s what I do.
That’s what I used to do, but uMatrix hasn’t been doing its job perfectly. It’d let some JS that isn’t supposed to execute execute anyways under odd circumstances. I now use LibreJS with site-by-site exceptions. LibreJS is also kind enough to tell sites if JS is being blocked, so they can load nonJS alternatives. uMatrix does no such thing, so the site tries to push JS and uMatrix ignores it. LibreJS seems to always block blocked JS under all circumstances.
Are you talking about triggering <noscript> tags? uMatrix does that just fine now, at least I haven’t found any problems with it. When did you stop using it?
Besides, LibreJS does what I’d like just fine, and even notifies the specific website when I’m blocking JS, so it has the opportunity to behave accordingly.
I haven’t been paying attention to the specific HTML tags, I’ve just used it long enough to notice that it didn’t always work. I stopped using it somewhere probably between 4-6 months ago.
What we can do is not touch the single page web app at all, and automatically fall back to a server-side client that pre-renders the Lemmy page when a
<noscript>tag is triggered. It can even be read-only at first. This server side client can make the exact same API calls as the JS client itself, just on the server side (which, if you run it on the same server and just use the loopback IP, probably wouldn’t cause much overhead at all), and can even be written completely separately from Lemmy itself. In a different language even.The classic approach however would be kind of like making a website in PHP (not literally, that’d be a nightmare) where the Lemmy server side code sends static HTML when a page is initially loaded, and from there it can load JS that turns it into a single page web app if it’s enabled, and make API calls from then on. That way, if you click a link on the non-JavaScript page, instead of the single page web app hooking into the browser history/URL APIs it’s literally just an
<a href="">tag, and the browser just jumps to the next statically rendered page. However this would require that the HTML templates be integrated directly into the server side logic.Thats basically what this issue is about. It seems pretty tricky to get working though. Contributions welcome :)
https://github.com/dessalines/lemmy/issues/226
I feel like the classic approach would be better. I’ve actually written web sites in PHP before, I’m pretty familiar with it, though I’m not perfect.
Me too, and honestly, as someone who started out making websites by self-learning PHP, I actually find dynamic server-side HTML pages and template languages kind of charming. I still use the latter all the time with my Django projects, because I design all my websites to be JavaScript-optional.
Once me and /u/nutomic have the http api done (should be a week or so), then some simple read-only html clients should be easy to make.
If the goal is to send static html pages directly from Lemmy, then the http api wouldnt be needed at all.
If we were going to build a “static / non-js” lemmy client, I’d wanna stay in rust and use Yew or something like that. But ya a non-dynamic client IMO should be lower priority than android, unless someone else wants to make it.