Reliably Send an HTTP Request as a User Leaves a Page

How sure are we about this? I'm pretty sure it depends on which market specifically you're in, and the data I'm about to show is of course not perfect, but it seems that not so many users actually do use adblockers today. Although I don't know a single developer who doesn't, and in some web applications I'm running, the majority of users do use adblockers as they are focused on developers.

Chrome is assumed to be the most popular browser (by a large margin last time I checked, so I won't bother to check again) and a quick search puts the user base around 2-3 billion users. Searching for "adblock" in the Chrome Web Store (https://chrome.google.com/webstore/search/adblock?hl=en&_cat...) shows that the most popular adblocker has a user base of ~300,000 users.

That makes 0.015% to 0.01% of Chrome users having the "AdBlock" extension installed. Not that substantial.

If someone has some more accurate numbers than my slightly-educated guess, I'd be happy to be proven wrong.

Edit: The above user base of the adblock extension is wrong. As Jabbles pointed out, I was seeing the number of reviews, not number of users.

So instead, the page lists "10,000,000+ users" so we can assume the true number to be above that, but below "100,000,000+ users" users.

That would put the amount of Chrome users using the "AdBlock" extension between 0.3% and 5% more of less. Closer to "substantial", but not sure if it would impact businesses choice regarding ads/tracking or not.

Interesting. Are there tools we can install to send malicious payloads to surveillance companies?

And for this one, you could. Native applications might seem like you'll "submit the form when you click on the submit button, but something else entirely happens" because it's a general computing environment, just like the web.

So in reality, it seems you're just against "modern" computing in general, not specifically the web. Because you can have that behavior anywhere, not just in the web platform.

Then again that would be fun to send enough nice bogus log information... As clearly that is what they want.

Popups exchange long-term trust in your brand for short-term profits. Of course it's the case that if you pop a modal in front of everyone, your conversion stats will go up. But potential life-time customers who have faith in your brand and believe in your mission will lose trust in you quickly and probably never sign up in the first place.

For me, it always comes down to the primary rule of UX: if you wouldn't do it IRL, don't do it online.

You can ask for someone's email if they look like they're interested in something you're selling, but don't ask for it the moment they enter your store!

What you don't realise is that x number of people join the list and x number of people tolerate being spammed with 'did you know we sell stuff' emails every day for the rest of their lives. x number of those people actually do buy something; likley the thing they intended to buy originally but joined the email list in case a discount code would be the subject of the first 'welcome' email because this is what they have been trained to expect.

All this has been A/B tested and, thus, has been 'proven' to be great business practice.

Another example is trimming referrer URLs (just keeping the domain).

There's Chrome and there's Safari. Rest of browsers are rounding errors. And even those rounding errors are mostly chromiums. Sad indeed.

Social services where users want to signal if they are online/offline

Users who want to know how much time they've spent on a platform.

Closing down sessions for things that can be expensive to just run "forever". Think VMs and similar that gets started when the user visits the page, that you want to turn off when they leave.

The use cases are many, and there are also many other alternative solutions, this is obviously not the only one. But as always, all of them come with their own tradeoffs, so this technique might be the best for some of them.

Closing off cached resources when a user vanishes is a good thing, it saves resources for other users and could, if I may stretch a little, have environmental impact. Noting that sessions tend to end after a particular set of circumstances could mean spoting something in your application that is annoying people, something that particularly in an SPA you might otherwise not easily detect.

Sometimes tracking is legitimately benign. It is only when unnecessary PII is included, and kept to track each specific user over time rather than just over a session, that it gets stalky to the point of begin in my "I won't do that" list (sharing the PII around further gets you on my "you are morally wrong for doing that" list).

> surprised they didn't even mention it as a possibility

The article is focused on detecting when a user leaves. While a fair amount if that will be detectable because they've clicked a link, it doesn't cover the large case set that is closing tabs and windows.

Something I might have to investigate (or search to see if someone else has): do any of these techniques work reliably on controlled OS shutdown.

What evil things were we doing? Well, I wanted to know if people were using the links I put inside popups, like to Google Scholar. Was anyone using them? If not, they were just so much clutter and should be removed for the users' benefit. I also wanted to get a list of outbound links by popularity, so I could write summaries/annotations for the most popular unannotated links, and rank dead links by priority for fixing (there are too many unannotated or dead links to 'just fix', so a ranking would've helped a lot).

But the link tracking never worked, so, I couldn't do any of that.

I agree that it's all about trust. Why would you ever enter information on a website you don't trust? What extra information can be gathered using JS that can't be otherwise? Or what is the exact harm done if they send extra requests to a tracking API?

My point is that once you access a specific website you consent with that website sending HTML/CSS/JS to your computer and executing it. The biggest problem those days is when that website is sending your information to other entities, 3rd parties, for other purposes than improving your experience. I think having "tracking" to detect errors, loading time issues and improving the user experience is perfectly reasonable if implemented in a proper way.

Actually I think that's the whole reason of introducing this attribute.

On a general level, locking is a subpar solution for distributed systems. You should try to build support for automatic resolution of (most) edit conflicts instead, and forego locking altogether. If that's not possible, try to make the locks smart, e.g. so they auto expire unless periodically renewed.

Oh wait, not on mobile, unless you're willing to deviate from stable releases or download a fork.

I feel tempted to write an addon that will catch tracking like this and just repeat every ping a thousand times across the rest of the day, perhaps with some permutations of the data these sites are trying to collect. If I can't stop you from collecting my data, I'll make my data useless to you instead.

A client browser can crash, the computer can lose power, the network can be unplugged, the router can crash, the internet connection can go down.

It doesn't matter why, there are many common reasons why you can't rely on an unlock signal, so must be able to deal with that situation. If you realize that from the beginning and design accordingly, it's usually easier to handle than realizing it later and trying to add special cases to catch it later.

For example, if you know the above is a problem, you might just opt to make a lock for a record the I'd of the locking user and the last lock update time, and update the lock every few seconds during normal operation when locked. If there's a problem, that user can pick up the lock without problem when reconnecting, but if any other user attempts to lock the record and the lock hasn't been updated in a minute or two, then consider it invalid and let the new user lock. Anyone attempting to edit a record with a lock that isn't too old is told it's actively locked and to try back in a few minutes. All of a sudden your lock release problems are automatically cleaned up by normal use, can be easiest found as needed by searching for old timestamps, and the person that has to deal with problems is the person with the behavior/system causing the problem.

There are obviously more complicated (and for some cases better) solutions, but the takeaway is to look at the problem and constraints as a whole and find a solution with the right trade offs given your needs, and not let the constant accretion of small features lead you to a suboptimal solution what doesn't work.

Other people have recommended CRDTs and Optimistic Concurrency control, which is great if you are designing an app from the ground up. If you have an existing large app that just needs locks, though, I recommend following the Chubby paper: https://research.google.com/archive/chubby-osdi06.pdf

Section 2.4 Locks addresses how Chubby thinks about locking in a distributed system:

It is costly to introduce sequence numbers into all the interactions in an existing complex system. Instead, Chubby provides a means by which sequence numbers can be introduced into only those interactions that make use of locks. At any time, a lock holder may request a sequencer, an opaque byte-string that describes the state of the lock immediately after acquisition. It contains the name of the lock, the mode in which it was acquired (exclusive or shared), and the lock generation number. The client passes the sequencer to servers (such as file servers) if it expects the operation to be protected by the lock. The recipient server is expected to test whether the sequencer is still valid and has the appropriate mode; if not, it should reject the request. The validity of a sequencer can be checked against the server’s Chubby cache or, if the server does not wish to maintain a session with Chubby, against the most recent sequencer that the server has observed. The sequencer mechanism requires only the addition of a string to affected messages, and is easily explained to our developers.

Although we find sequencers simple to use, important protocols evolve slowly. Chubby therefore provides an imperfect but easier mechanism to reduce the risk of delayed or re-ordered requests to servers that do not sup- port sequencers. If a client releases a lock in the normal way, it is immediately available for other clients to claim, as one would expect. However, if a lock becomes free because the holder has failed or become inaccessible, the lock server will prevent other clients from claiming the lock for a period called the lock-delay. Clients may specify any lock-delay up to some bound, currently one minute; this limit prevents a faulty client from making a lock (and thus some resource) unavailable for an arbitrarily long time. While imperfect, the lock-delay protects unmodified servers and clients from everyday problems caused by message delays and restarts

Check here: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/s...

> However, this is extremely unreliable. In many situations, especially on mobile, the browser will not fire the unload, beforeunload, or pagehide events.

    navigator.sendBeacon = undefined

At a minimum, this kind of information is relevant to the people creating products like Heap or Amplitude.

You get incomplete, inaccurate data.

It's also fun and good for curiosity to do something on your own rathern than rely on a service and never think about what browsers can do.

Mammon is the only thing that matters to a lot of primates.

We are rich in compute and we don't feel the need to optimize anymore. Optimization is an afterthought or a never thought and features run the world.

0: https://spcodex.wiki/wiki/Billy_Corgan_2022-02-06_(early_sho...

We have competent design tools running in the browser now… we’re doing fine.

You can't expect everyone to reverse engineer your browser to make your reader mode experience better. Reader mode is explicitly a client side algorithm, parsing and displaying a document for you, the user. If reader mode doesn't work right for you, you should file an issue with your browser maker. After all, they're the ones that designed the algorithm to partially hide the contents of the web page for you.

For what it's worth, I have no issue viewing the images in Firefox's reader mode.

I can't see any super distracting content on this page anyway. There's a black side bar and the text is almost black on white. Perhaps you're referring to the header, but even that's mostly white and black. There are definitely some places where accessibility can be improved, but this is hardly "not acceptable".