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!”
Basically, session recording refers to, well, recording a person’s browsing session, usually including all mouse and 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.
Could you point at such services?
AFAIK browser session is usually referred to cookie session. Various web applications use sessions storage to store parameter configurations and other various states. This storage is also extremely limited and often wouldn’t even store anything but references to server database.
I’ve heard of fingerprinting and tracking but session recording seems awfully complex for the same results you’d get from the former.
Could you point at such services?
Here is a demo from one of those companies, Mouseflow: https://mouseflow.com/demo/
You go on the site, scroll up and down, move your mouse, click a few dummy buttons, and then get a literal video of everything you did. Keep in mind that there is no delete button on that video if you do try it though, and anyone with the link can access them. Shows how scummy these companies are.
Fortunately it’s being blocked by every ad block on my machine but it is trully disgusting. Another reason why javascript is a mistake - why on earth it would need such access? I’m struggling with coming up with legitimate uses for this.
I’m struggling with coming up with legitimate uses for this.
I think it’s supposed to be an insight into how users behave on the site and how intuitive it is, but it’s far too invasive to deserve to exist.
As someone who worked on similar QA issues - that’s way too much but I definitely see how this would be useful. Outsource QA to the userbase! It’s definitely too far though, like by a long margin.
I’d be less hateful of this tech (though still NOT fully accepting) if every single website made absolutely sure that no personally identifiable information was captured (like if the recordings showed mouse movements on a page with only dummy content in place of real user generated content), the recordings anonymized, and were truly deleted after a set time, oh and no keylogging, just mouse movements.
Unfortunately, that’s not happening, ever, so it’s a moot point.
Shit is very scary. Who knew we had to be this wary of what we type in a text box.
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?
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 :)
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.
Some session recording platforms tell you to configure it so it blanks out any “personally identifiable information”. They won’t do it for you, mind you, you have to manually configure it specifically for your site.
Yeah, that’s like a YouTube ripping site/app telling users to “not use this for piracy and copyright infringement”. They know that it’s ignored but they have to cover their asses.
