7 ms·

Say Bye with JavaScript Beacon

75 points by moebrowne 1y ago

righthand 1y ago
Can I disable this in my Chrome browser? I don’t want tracking companies to have more convenience. In Firefox you can disable it by beacon.enable = false.
tux3 1y ago
If you'd like, you can also Say Bye to Say Bye with JavaScript Beacons in about:config by setting beacon.enabled to false
- bilekas 1y ago
  This would be nice but I can't see any option for Chromium/Brave inside the chrome://flags .. Do you know if there is one ?
- ravenstine 1y ago
  This mostly works, but I have come across a minority of sites that break because of this. Whether that's a good thing or not is up to interpretation (I keep it disabled).
bilekas 1y ago
So this is kind of interesting, and I had a look at the spec. > The data parameter is the BodyInit data that is to be transmitted. However I couldn't find any information in the Spec itself about the size of the data until it said this : > The user agent imposes limits on the amount of data that can be sent via this API: [...] If the amount of data to be queued exceeds the user agent limit [...] , this method returns false; a return value of true implies the browser has queued the data for transfer. However, since the actual data transfer happens asynchronously, this method does not provide any information whether the data transfer has succeeded or not. Am I missing something or does this seem as unreliable as any other method for achieving this ? How about, and this might be a crazy idea, letting the users leave without annoying them ?
- lifthrasiir 1y ago
  Technically speaking a conforming agent can ignore every single sendBeacon call by always returning false. And that's a point: beacons are opportunistic asynchronous requests. You can't do anything when they error anyway, so they should be regarded as hints that agents may or may not honor.
  - bilekas 1y ago
    Okay so it's basically just a baked in implementation of what people did already but instead of using onUnload they have more visibility into the client context. Seems dirty in a way, the agent could basically internally call the same thing and send any data to their own server on every page? For example, firefox, If they wanted, could record all your browsing history without notifying you? For any bad actor this seems like an amazing attack point.
    - swiftcoder 1y ago
      Firefox could do that anyway, whether or not this API exists. Browser implementors need to be at least moderately trustworthy, or no one will use them.
andrewstuart 1y ago
Where has this been hiding how did I not know about this?
tuzemec 1y ago
Major hm... analytic tools... like MixPanel support this.
Zealotux 1y ago
You may not want to rely too much on `beforeunload` events though as it is unreliable on mobile, a good practice if you want to send analytics if to listen to the page visibility: document.addEventListener('visibilitychange', () => { if (document.visibilityState === 'hidden') { navigator.sendBeacon(...); } }); Of course it can't strictly be considered a "page leave" but for mobile users it's often your best bet: https://developer.chrome.com/docs/web-platform/page-lifecycle-api#legacy-lifecycle-apis-to-avoid https://developer.chrome.com/docs/web-platform/page-lifecycl...
meindnoch 1y ago
>Sometimes we want to send a piece of data to our servers when user leaves our website or webapp. I've never. >Maybe it’s for for analytics or even auto-logout when they leave the website. Just don't persist the auth token? Analytics is blocked at the DNS level anyway.
- can16358p 1y ago
  There might be some sensitive applications where server might want to immediately revoke credentials server-side though.
  - meindnoch 1y ago
    And what will this hyper-sensitive application do if I yank the power cable from the computer? Or if I quit the browser with kill -9? See, this is one of those "features" that clueless PMs ask their developers to implement, not having the technical knowledge to realize that their idea is unsalvageable. My other favorite is email address "validation" with ad hoc string format checks.
    - can16358p 1y ago
      It's just an extra measure, not protecting the server from a malicious user, but an honest user's potential mismanagement of credentials.
DanielHB 1y ago
This is neat, but don't service-workers persist for like 5s (non-deterministic) before being unloaded?
Arch-TK 1y ago
Surely if you want to reliably do some action when a user leaves your page then some persistent connection which dies is by far the most reliable option...? I'm no frontend expert but cant you just open a websocket and when the websocket dies from the server's perspective, you have your cue to do whatever cleanup you wanted to do? I also agree with the others here that there shouldn't really be a _need_ for this kind of feature.
- bilekas 1y ago
  > I'm no frontend expert but cant you just open a websocket and when the websocket dies from the server's perspective, you have your cue to do whatever cleanup you wanted to do? If I'm not mistaken, and I very well might be, it's kind of the same, however a WS connection here may be less reliable, infact if the user has a spotty connection, when you think "That user left", in the case of a local cleanup, okay that could run on the client side, however this beacon seems to be aimed at sending data back to the server when you leave, in the case of a dropped connection, you wont be able to send the data back anyway to the server. For this 'browser' based implementation under the hood, the browser *should* have more insight into the real intention of the users exit.
  - Arch-TK 1y ago
    I really wouldn't want to be doing anything that requires reliability on the back of either solution as user agents can just opt to never send beacons.
- Etheryte 1y ago
  Keeping a websocket alive would work, but then you're stuck holding a websocket for all of your users for the full session. Fine if you need a socket anyway, pretty wasteful if you don't. Sockets are pretty cheap these days, but I wouldn't really give this serious thought for a page with a lot of users.
  - Arch-TK 1y ago
    Holding a socket is very cheap. Unless websockets introduce some overhead I am not aware of.
azangru 1y ago
I remember when beacons were recently discussed here, someone mentioned the fetchLater API: https://developer.mozilla.org/en-US/docs/Web/API/fetchLater_API https://developer.mozilla.org/en-US/docs/Web/API/fetchLater_...
Brysonbw 1y ago
One of my favorite Web APIs
AndrewStephens 1y ago
The beacon API has exactly one use - reliable analytics. Sending a ping on leaving the page is a pretty contrived example - the beacon API is useful at any time. I use the beacon API in my homebuilt hit-counter. It means that even if the user navigates away before the hit is registered, the request will still have a fair chance of being received by my server. Of course there are other ways of doing this, but who wants to muck around with service workers or websockets when there is a simple, well-supported API that does exactly what you want?
- Thorrez 1y ago
  Could you count hits on the server when serving the page? I guess caching might break that depending on cache settings. And for SPAs, it might not work as desired.
  - dspillett 1y ago
    Calling out as the page closes, assuming you called out at out listed too, tells you how long the user was there. Not entirely reliable of course as they could have opened it in the background so had it open a while before dismissing it without looking at it at all.
    - Thorrez 1y ago
      I should have been clearer. I was replying to the "I use the beacon API in my homebuilt hit-counter." part.
  - AndrewStephens 1y ago
    There are several reasons that you cannot just count the number of times your server has served the page. The biggest is bots - on my site (and I assume most others), legitimate requests are far, far outweighed by bots. Sometimes you can tell that they are bots but it is very common for bots to pretend to be real users. Oftentimes you can't tell from a single request but only but looking at the pattern of requests. Some bots do take the trouble of running scripts on the page but thankfully they are in the minority so far. Caching would certainly break the system as well, in the other direction.
lapcat 1y ago
[self-promotion:] My Safari extension StopTheMadness Pro disables the Beacon API.
- srameshc 1y ago
  Interesting. Could you elaborate on the rationale behind disabling the Beacon API?
  - vinnymac 1y ago
    Not OP. It’s mostly used for tracking user behavior, and is rarely critical functionality for a given web page.
  - snickerdoodle12 1y ago
    It's solely created for advertisers to be able to implement their tracking more reliably. There is almost no way to use it in a way that benefits the user.
    - Chabsff 1y ago
      Yes, but you could also say that it was created so that advertisers stop doing complete nonsense like tracking pixels and other roundabout ways of accomplishing the same thing in ways that are sometimes (often?) detrimental to the user. Sure, it's a form of capitulation to advertisers, that doesn't necessarily mean that it doesn't benefit the user. If advertisers are going to be doing that stuff no matter what, corralling them has advantages. If anything, it makes creating an extension like OP's a lot easier than playing whack-a-mole with a litany of random techniques.
      - snickerdoodle12 1y ago
        Sure, which is exactly the rationale for disabling it.
- zenethian 1y ago
  You're a hero, and I love your extension. Thank you for all of your hard work.
paultopia 1y ago
How about don't instead
junon 1y ago
> Maybe it’s for for analytics or even auto-logout when they leave the website. Yeah, don't do either of these things. Don't log me out when I close the tab. Don't spy on me after I close the tab. Very simple!
- hdjrudni 1y ago
  > Don't log me out when I close the tab. What about being logged out of a real-time chat with your friend? Wouldn't you like them to know you are no longer connected? Or do you prefer to trick them with a little green 'connected' bubble that can no longer update?
- afavour 1y ago
  > Don't spy on me after I close the tab. Maybe a small nit but it isn't spying on you after you close the tab. It is spying on you the moment you close the tab and no later.
  - junon 1y ago
    If it's performing a request upon closing the tab, only two options are available: 1. it delays closing until it completes, which is a performance hit, or 2. it's performing more website specific background work when I've told the browser not to by hitting the Close Tab button.
    - subscribed 1y ago
      Interrupt the request, clean up after the tab. That's all. The second option is garbage collector. Not sure why the website is entitled to execute any code when I decided to close it.
  - 01HNNWZ0MV43FF 1y ago
    Don't spy on me
vince14 1y ago
Their fetch call is missing `keepalive: true`. When set to true, the browser will not abort the associated request if the page that initiated it is unloaded before the request is complete. This enables a fetch() request to send analytics at the end of a session even if the user navigates away from or closes the page. https://developer.mozilla.org/en-US/docs/Web/API/RequestInit#keepalive https://developer.mozilla.org/en-US/docs/Web/API/RequestInit...
Hnrobert42 1y ago
Could you send the beacon every five minutes? When the beacon stops coming in for 30 minutes assume that the tab closed or the user went off-line.
- ivanjermakov 1y ago
  > every five minutes This is tricky in JavaScript, because timers are asleep/throttled in inactive tabs: https://developer.mozilla.org/en-US/docs/Web/API/Window/setTimeout#description https://developer.mozilla.org/en-US/docs/Web/API/Window/setT... And if onbeforeleave analytics is not evil, doing stuff in inactive tabs is certainly is.
- hoppp 1y ago
  You could just have a websocket open then. But its unreliable because if the user's internet cuts out maybe they still on the tab, so watching websocket disconnect is not perfect either
daveoc64 1y ago
I was thinking this might be useful for locking records while users are looking at them, but that's probably better served with a periodic ping that ends when the user leaves the page.
afavour 1y ago
Interesting to see so much resistance to the Beacon API. I think it's great. I've gotten a lot of useful data over the years via user analytics and routing all analytics requests through a dedicated API makes it trivial for users who care to disable it.
- wrsh07 1y ago
  Something many people refuse to believe is that "understanding your users" doesn't have to be nefarious or about serving ads. It's important to realize that key assumptions your app makes (nobody is accessing my b2b saas app from a phone) are incorrect. It's important to understand user workflows. There are higher touch ways to do this (user research is great!), and you should let users opt out, but someone trying to improve the user experience also needs to understand how users are defying their expectations
RShackleford 1y ago
[dead]
dmvjs 1y ago
this isn't new at all, ten years ago I used it to open an Android app without a user gesture https://paul.kinlan.me/deep-app-linking-on-android-and-chrome/ https://paul.kinlan.me/deep-app-linking-on-android-and-chrom...
chaz6 1y ago
In networking, there is a similar concept called "dyinggasp" in which a device will send a signal when power is lost. This can help the operator determine if a service is likely to be down due to a power failure or a signal interruption.
hoppp 1y ago
I didn't know it existed, it is handy
stevage 1y ago
I tried to figure out how much data you can send exactly. It's not very clear from the spec: > If the amount of data that can be queued to be sent by keepalive enabled requests is exceeded by the size of transmittedData (as defined in HTTP-network-or-cache fetch), set the return value to false and terminate these steps. Does anyone know?
mediumsmart 1y ago
Bye JavaScript.

75 points by moebrowne 1y ago

Can I disable this in my Chrome browser? I don’t want tracking companies to have more convenience. In Firefox you can disable it by beacon.enable = false.

tux3 1y ago

If you'd like, you can also Say Bye to Say Bye with JavaScript Beacons in about:config by setting beacon.enabled to false

bilekas 1y ago
This would be nice but I can't see any option for Chromium/Brave inside the chrome://flags .. Do you know if there is one ?
ravenstine 1y ago
This mostly works, but I have come across a minority of sites that break because of this. Whether that's a good thing or not is up to interpretation (I keep it disabled).

bilekas 1y ago

So this is kind of interesting, and I had a look at the spec. > The data parameter is the BodyInit data that is to be transmitted. However I couldn't find any information in the Spec itself about the size of the data until it said this : > The user agent imposes limits on the amount of data that can be sent via this API: [...] If the amount of data to be queued exceeds the user agent limit [...] , this method returns false; a return value of true implies the browser has queued the data for transfer. However, since the actual data transfer happens asynchronously, this method does not provide any information whether the data transfer has succeeded or not. Am I missing something or does this seem as unreliable as any other method for achieving this ? How about, and this might be a crazy idea, letting the users leave without annoying them ?

lifthrasiir 1y ago
Technically speaking a conforming agent can ignore every single sendBeacon call by always returning false. And that's a point: beacons are opportunistic asynchronous requests. You can't do anything when they error anyway, so they should be regarded as hints that agents may or may not honor.
- bilekas 1y ago
  Okay so it's basically just a baked in implementation of what people did already but instead of using onUnload they have more visibility into the client context. Seems dirty in a way, the agent could basically internally call the same thing and send any data to their own server on every page? For example, firefox, If they wanted, could record all your browsing history without notifying you? For any bad actor this seems like an amazing attack point.
  - swiftcoder 1y ago
    Firefox could do that anyway, whether or not this API exists. Browser implementors need to be at least moderately trustworthy, or no one will use them.

andrewstuart 1y ago

Where has this been hiding how did I not know about this?

tuzemec 1y ago

Major hm... analytic tools... like MixPanel support this.

Zealotux 1y ago

You may not want to rely too much on `beforeunload` events though as it is unreliable on mobile, a good practice if you want to send analytics if to listen to the page visibility: document.addEventListener('visibilitychange', () => { if (document.visibilityState === 'hidden') { navigator.sendBeacon(...); } }); Of course it can't strictly be considered a "page leave" but for mobile users it's often your best bet: https://developer.chrome.com/docs/web-platform/page-lifecycle-api#legacy-lifecycle-apis-to-avoid https://developer.chrome.com/docs/web-platform/page-lifecycl...

meindnoch 1y ago

>Sometimes we want to send a piece of data to our servers when user leaves our website or webapp. I've never. >Maybe it’s for for analytics or even auto-logout when they leave the website. Just don't persist the auth token? Analytics is blocked at the DNS level anyway.

can16358p 1y ago
There might be some sensitive applications where server might want to immediately revoke credentials server-side though.
- meindnoch 1y ago
  And what will this hyper-sensitive application do if I yank the power cable from the computer? Or if I quit the browser with kill -9? See, this is one of those "features" that clueless PMs ask their developers to implement, not having the technical knowledge to realize that their idea is unsalvageable. My other favorite is email address "validation" with ad hoc string format checks.
  - can16358p 1y ago
    It's just an extra measure, not protecting the server from a malicious user, but an honest user's potential mismanagement of credentials.

DanielHB 1y ago

This is neat, but don't service-workers persist for like 5s (non-deterministic) before being unloaded?

Arch-TK 1y ago

Surely if you want to reliably do some action when a user leaves your page then some persistent connection which dies is by far the most reliable option...? I'm no frontend expert but cant you just open a websocket and when the websocket dies from the server's perspective, you have your cue to do whatever cleanup you wanted to do? I also agree with the others here that there shouldn't really be a _need_ for this kind of feature.

bilekas 1y ago
> I'm no frontend expert but cant you just open a websocket and when the websocket dies from the server's perspective, you have your cue to do whatever cleanup you wanted to do? If I'm not mistaken, and I very well might be, it's kind of the same, however a WS connection here may be less reliable, infact if the user has a spotty connection, when you think "That user left", in the case of a local cleanup, okay that could run on the client side, however this beacon seems to be aimed at sending data back to the server when you leave, in the case of a dropped connection, you wont be able to send the data back anyway to the server. For this 'browser' based implementation under the hood, the browser *should* have more insight into the real intention of the users exit.
- Arch-TK 1y ago
  I really wouldn't want to be doing anything that requires reliability on the back of either solution as user agents can just opt to never send beacons.
Etheryte 1y ago
Keeping a websocket alive would work, but then you're stuck holding a websocket for all of your users for the full session. Fine if you need a socket anyway, pretty wasteful if you don't. Sockets are pretty cheap these days, but I wouldn't really give this serious thought for a page with a lot of users.
- Arch-TK 1y ago
  Holding a socket is very cheap. Unless websockets introduce some overhead I am not aware of.

azangru 1y ago

I remember when beacons were recently discussed here, someone mentioned the fetchLater API: https://developer.mozilla.org/en-US/docs/Web/API/fetchLater_API https://developer.mozilla.org/en-US/docs/Web/API/fetchLater_...

Brysonbw 1y ago

One of my favorite Web APIs

AndrewStephens 1y ago

The beacon API has exactly one use - reliable analytics. Sending a ping on leaving the page is a pretty contrived example - the beacon API is useful at any time. I use the beacon API in my homebuilt hit-counter. It means that even if the user navigates away before the hit is registered, the request will still have a fair chance of being received by my server. Of course there are other ways of doing this, but who wants to muck around with service workers or websockets when there is a simple, well-supported API that does exactly what you want?

Thorrez 1y ago
Could you count hits on the server when serving the page? I guess caching might break that depending on cache settings. And for SPAs, it might not work as desired.
- dspillett 1y ago
  Calling out as the page closes, assuming you called out at out listed too, tells you how long the user was there. Not entirely reliable of course as they could have opened it in the background so had it open a while before dismissing it without looking at it at all.
  - Thorrez 1y ago
    I should have been clearer. I was replying to the "I use the beacon API in my homebuilt hit-counter." part.
- AndrewStephens 1y ago
  There are several reasons that you cannot just count the number of times your server has served the page. The biggest is bots - on my site (and I assume most others), legitimate requests are far, far outweighed by bots. Sometimes you can tell that they are bots but it is very common for bots to pretend to be real users. Oftentimes you can't tell from a single request but only but looking at the pattern of requests. Some bots do take the trouble of running scripts on the page but thankfully they are in the minority so far. Caching would certainly break the system as well, in the other direction.

lapcat 1y ago

[self-promotion:] My Safari extension StopTheMadness Pro disables the Beacon API.

srameshc 1y ago
Interesting. Could you elaborate on the rationale behind disabling the Beacon API?
- vinnymac 1y ago
  Not OP. It’s mostly used for tracking user behavior, and is rarely critical functionality for a given web page.
- snickerdoodle12 1y ago
  It's solely created for advertisers to be able to implement their tracking more reliably. There is almost no way to use it in a way that benefits the user.
  - Chabsff 1y ago
    Yes, but you could also say that it was created so that advertisers stop doing complete nonsense like tracking pixels and other roundabout ways of accomplishing the same thing in ways that are sometimes (often?) detrimental to the user. Sure, it's a form of capitulation to advertisers, that doesn't necessarily mean that it doesn't benefit the user. If advertisers are going to be doing that stuff no matter what, corralling them has advantages. If anything, it makes creating an extension like OP's a lot easier than playing whack-a-mole with a litany of random techniques.
    - snickerdoodle12 1y ago
      Sure, which is exactly the rationale for disabling it.
zenethian 1y ago
You're a hero, and I love your extension. Thank you for all of your hard work.

paultopia 1y ago

How about don't instead

junon 1y ago

> Maybe it’s for for analytics or even auto-logout when they leave the website. Yeah, don't do either of these things. Don't log me out when I close the tab. Don't spy on me after I close the tab. Very simple!

hdjrudni 1y ago
> Don't log me out when I close the tab. What about being logged out of a real-time chat with your friend? Wouldn't you like them to know you are no longer connected? Or do you prefer to trick them with a little green 'connected' bubble that can no longer update?
afavour 1y ago
> Don't spy on me after I close the tab. Maybe a small nit but it isn't spying on you after you close the tab. It is spying on you the moment you close the tab and no later.
- junon 1y ago
  If it's performing a request upon closing the tab, only two options are available: 1. it delays closing until it completes, which is a performance hit, or 2. it's performing more website specific background work when I've told the browser not to by hitting the Close Tab button.
  - subscribed 1y ago
    Interrupt the request, clean up after the tab. That's all. The second option is garbage collector. Not sure why the website is entitled to execute any code when I decided to close it.
- 01HNNWZ0MV43FF 1y ago
  Don't spy on me

vince14 1y ago

Their fetch call is missing `keepalive: true`. When set to true, the browser will not abort the associated request if the page that initiated it is unloaded before the request is complete. This enables a fetch() request to send analytics at the end of a session even if the user navigates away from or closes the page. https://developer.mozilla.org/en-US/docs/Web/API/RequestInit#keepalive https://developer.mozilla.org/en-US/docs/Web/API/RequestInit...

Hnrobert42 1y ago

Could you send the beacon every five minutes? When the beacon stops coming in for 30 minutes assume that the tab closed or the user went off-line.

ivanjermakov 1y ago
> every five minutes This is tricky in JavaScript, because timers are asleep/throttled in inactive tabs: https://developer.mozilla.org/en-US/docs/Web/API/Window/setTimeout#description https://developer.mozilla.org/en-US/docs/Web/API/Window/setT... And if onbeforeleave analytics is not evil, doing stuff in inactive tabs is certainly is.
hoppp 1y ago
You could just have a websocket open then. But its unreliable because if the user's internet cuts out maybe they still on the tab, so watching websocket disconnect is not perfect either

daveoc64 1y ago

I was thinking this might be useful for locking records while users are looking at them, but that's probably better served with a periodic ping that ends when the user leaves the page.

afavour 1y ago

Interesting to see so much resistance to the Beacon API. I think it's great. I've gotten a lot of useful data over the years via user analytics and routing all analytics requests through a dedicated API makes it trivial for users who care to disable it.

wrsh07 1y ago
Something many people refuse to believe is that "understanding your users" doesn't have to be nefarious or about serving ads. It's important to realize that key assumptions your app makes (nobody is accessing my b2b saas app from a phone) are incorrect. It's important to understand user workflows. There are higher touch ways to do this (user research is great!), and you should let users opt out, but someone trying to improve the user experience also needs to understand how users are defying their expectations

RShackleford 1y ago

[dead]

dmvjs 1y ago

this isn't new at all, ten years ago I used it to open an Android app without a user gesture https://paul.kinlan.me/deep-app-linking-on-android-and-chrome/ https://paul.kinlan.me/deep-app-linking-on-android-and-chrom...

chaz6 1y ago

In networking, there is a similar concept called "dyinggasp" in which a device will send a signal when power is lost. This can help the operator determine if a service is likely to be down due to a power failure or a signal interruption.

hoppp 1y ago

I didn't know it existed, it is handy

stevage 1y ago

I tried to figure out how much data you can send exactly. It's not very clear from the spec: > If the amount of data that can be queued to be sent by keepalive enabled requests is exceeded by the size of transmittedData (as defined in HTTP-network-or-cache fetch), set the return value to false and terminate these steps. Does anyone know?

mediumsmart 1y ago

Bye JavaScript.