6 ms·

If only Google Chrome would adopt this too! Sarcasm aside, sites breaking or not working when analytics scripts are blocked is nuts. Is there a Wall of Shame f

If only Google Chrome would adopt this too! Sarcasm aside, sites breaking or not working when analytics scripts are blocked is nuts. Is there a Wall of Shame for such sites (it may probably be the size of a search engine index)?

gruez 6y ago
FWIW it's usually not malicious. What usually happens is that the analytics script provides some API for the developers to add additional logging functionality[1]. The developer then sprinkles calls to those APIs throughout their code, assuming that those functions will be available. If the scripts are blocked then you get an error like "ga is not defined" and the rest of the code doesn't execute, causing the page to be broken. [1] https://developers.google.com/analytics/devguides/collection/analyticsjs/sending-hits https://developers.google.com/analytics/devguides/collection...
- sanxiyn 6y ago
  Not malicious but sloppy.
  - Spivak 6y ago
    I mean kinda. I wouldn’t bother to check if jQuery was defined if I explicitly included it in a script tag.
    - edoceo 6y ago
      But, we, as web-devs, know, KNOW, that blockers a) exist and b) are used by clients. It's like missing a test case that covers 15% of your user base.
      - jameshart 6y ago
        Is it 15%? I have no idea. They don't show up in my analytics...
        edoceo 6y ago
        Looks, it's Friday, I kinda made that up. A system I operate has rate higher than that but a trusted associate has a site with numbers like 2%. Check your own metrics. It's for sure not zero.
        Spivak 6y ago
        It’s a joke because ad blockers block the analytics they would show up on.
        jameshart 6y ago
        I mean, it's a joke-but-not-a-joke. It's actually reasonable for sites to be able to estimate the proportion of their population who block their analytics by looking at say, the proportion of signups or conversions or sales or whatever that come from 'untracked' sessions. But that is confounded by the fact that the population who uses ad and script blockers is not necessarily similar in behavior to the population who don't. If 2% of signups to my newsletter come from sessions that don't show up in google analytics, does that mean 2% of my site traffic is using an ad blocker, or are they actually 10% of my site traffic - but those users are just 5 times less likely to give me their email address?
        ddalex 6y ago
        Why not? Log analytics are a thing, you know ....
    - pushrax 6y ago
      If you load jQuery as part of your first party bundle, sure. But if you load it from a 3rd party CDN, you can assume it will independently fail at some point. If you’re making something important, the proper resiliency practise would be to gracefully handle it. Obviously if jQuery is critical to your site working at all there’s not much you can do, but for any dependencies that are not critical or only critical to a small portion of features, it’s a much better UX to degrade only those features.
  - viraptor 6y ago
    It's not even sloppy. When people write code with dependency X, they don't check if X is available before every call. The website works as designed. The user decided to change the environment behaviour in an unexpected way.
    - jasonkester 6y ago
      It's not even sloppy It’s the definition of sloppy. Rule One of Javascript is that you check every 3rd party dependency before every call. window.ga && ga(“user likes socks”); For exactly this reason: because often all you get is what you sent down the wire yourself. You still need to work with that.
  - underwater 6y ago
    To be honest the web is a pretty hostile environment to program in. Imagine if calling into a library randomly failed in Python. Or random apps directly inserted data into your SQLite database. Or users regularly injected code into your iOS at runtime to remove or change views. One classic example we ran into was DOM that we'd just rendered suddenly had a different structure because Google Translate would insert new DOM nodes. So after a.appendChild(b); b.parentNode would be some random value instead of a. As a coder that's hard, you need some certainty to build on top of. Experienced devs can develop intuition about stuff that breaks. But it's hard to be exhaustive. And there isn't a great deal of tooling available for fuzz testing this kind of stuff.
    - bikeshaving 6y ago
      > One classic example we ran into was DOM that we'd just rendered suddenly had a different structure because Google Translate would insert new DOM nodes. Gosh, this continues to be one of the problems I have with all of the major frameworks. Rather than assuming the DOM is a mutable, shared resource like it actually is, they treat unexpected DOM changes as undefined behavior, and will usually break at the slightest attempts by browsers or extensions to help the user. The Google Translate issue is still largely unsolved, and I’m always frustrated whenever I attempt to translate a blog post on development from Chinese and find out that it’s not working because they’ve decided to render in client-side with React.
      - underwater 6y ago
        React does make this worse, but even with vanilla JavaScript, having a third party make arbitrary changes to the DOM means that there may be no way to safetly perform certain operations. Expecting every website developer to code defensively for every single operation is unsustainable. A better solution might be to just build APIs for common cases; like creating new nodes that are anchored to existing DOM nodes.
    - banana_giraffe 6y ago
      > Or users regularly injected code into your iOS at runtime to remove or change views That used to be more of a thing. A big iOS app I was indirectly involved in eventually added jailbreak detection. Not because they wanted to block it, but to log it so they could track down some fun bugs caused by random tweaks that changed the UI in impressively hacky ways.
sneak 6y ago
You'd be astounded how many sites break when you turn off cookies. I'm not just talking "can't log in"/"add to cart" break (obvs), but like, fail-to-catch-the-exception-thrown-by-localStorage-in-render()-so-completely-blank-white-page break. https://sneak.berlin/20200211/your-website/ https://sneak.berlin/20200211/your-website/ Now I work around the terrible exception-throwing behavior of localStorage by leaving cookies on, but using the Cookie Autodelete extension.
grishka 6y ago
As a Russian, I sometimes encounter sites that break when Yandex.Metrica is blocked. It's basically the same thing as GA, just from Yandex. And uBO didn't have a shim for it. Not sure if it does now.

gruez 6y ago

FWIW it's usually not malicious. What usually happens is that the analytics script provides some API for the developers to add additional logging functionality[1]. The developer then sprinkles calls to those APIs throughout their code, assuming that those functions will be available. If the scripts are blocked then you get an error like "ga is not defined" and the rest of the code doesn't execute, causing the page to be broken. [1] https://developers.google.com/analytics/devguides/collection/analyticsjs/sending-hits https://developers.google.com/analytics/devguides/collection...

sanxiyn 6y ago
Not malicious but sloppy.
- Spivak 6y ago
  I mean kinda. I wouldn’t bother to check if jQuery was defined if I explicitly included it in a script tag.
  - edoceo 6y ago
    But, we, as web-devs, know, KNOW, that blockers a) exist and b) are used by clients. It's like missing a test case that covers 15% of your user base.
    - jameshart 6y ago
      Is it 15%? I have no idea. They don't show up in my analytics...
      - edoceo 6y ago
        Looks, it's Friday, I kinda made that up. A system I operate has rate higher than that but a trusted associate has a site with numbers like 2%. Check your own metrics. It's for sure not zero.
        Spivak 6y ago
        It’s a joke because ad blockers block the analytics they would show up on.
        jameshart 6y ago
        I mean, it's a joke-but-not-a-joke. It's actually reasonable for sites to be able to estimate the proportion of their population who block their analytics by looking at say, the proportion of signups or conversions or sales or whatever that come from 'untracked' sessions. But that is confounded by the fact that the population who uses ad and script blockers is not necessarily similar in behavior to the population who don't. If 2% of signups to my newsletter come from sessions that don't show up in google analytics, does that mean 2% of my site traffic is using an ad blocker, or are they actually 10% of my site traffic - but those users are just 5 times less likely to give me their email address?
      - ddalex 6y ago
        Why not? Log analytics are a thing, you know ....
  - pushrax 6y ago
    If you load jQuery as part of your first party bundle, sure. But if you load it from a 3rd party CDN, you can assume it will independently fail at some point. If you’re making something important, the proper resiliency practise would be to gracefully handle it. Obviously if jQuery is critical to your site working at all there’s not much you can do, but for any dependencies that are not critical or only critical to a small portion of features, it’s a much better UX to degrade only those features.
- viraptor 6y ago
  It's not even sloppy. When people write code with dependency X, they don't check if X is available before every call. The website works as designed. The user decided to change the environment behaviour in an unexpected way.
  - jasonkester 6y ago
    It's not even sloppy It’s the definition of sloppy. Rule One of Javascript is that you check every 3rd party dependency before every call. window.ga && ga(“user likes socks”); For exactly this reason: because often all you get is what you sent down the wire yourself. You still need to work with that.
- underwater 6y ago
  To be honest the web is a pretty hostile environment to program in. Imagine if calling into a library randomly failed in Python. Or random apps directly inserted data into your SQLite database. Or users regularly injected code into your iOS at runtime to remove or change views. One classic example we ran into was DOM that we'd just rendered suddenly had a different structure because Google Translate would insert new DOM nodes. So after a.appendChild(b); b.parentNode would be some random value instead of a. As a coder that's hard, you need some certainty to build on top of. Experienced devs can develop intuition about stuff that breaks. But it's hard to be exhaustive. And there isn't a great deal of tooling available for fuzz testing this kind of stuff.
  - bikeshaving 6y ago
    > One classic example we ran into was DOM that we'd just rendered suddenly had a different structure because Google Translate would insert new DOM nodes. Gosh, this continues to be one of the problems I have with all of the major frameworks. Rather than assuming the DOM is a mutable, shared resource like it actually is, they treat unexpected DOM changes as undefined behavior, and will usually break at the slightest attempts by browsers or extensions to help the user. The Google Translate issue is still largely unsolved, and I’m always frustrated whenever I attempt to translate a blog post on development from Chinese and find out that it’s not working because they’ve decided to render in client-side with React.
    - underwater 6y ago
      React does make this worse, but even with vanilla JavaScript, having a third party make arbitrary changes to the DOM means that there may be no way to safetly perform certain operations. Expecting every website developer to code defensively for every single operation is unsustainable. A better solution might be to just build APIs for common cases; like creating new nodes that are anchored to existing DOM nodes.
  - banana_giraffe 6y ago
    > Or users regularly injected code into your iOS at runtime to remove or change views That used to be more of a thing. A big iOS app I was indirectly involved in eventually added jailbreak detection. Not because they wanted to block it, but to log it so they could track down some fun bugs caused by random tweaks that changed the UI in impressively hacky ways.

sneak 6y ago

You'd be astounded how many sites break when you turn off cookies. I'm not just talking "can't log in"/"add to cart" break (obvs), but like, fail-to-catch-the-exception-thrown-by-localStorage-in-render()-so-completely-blank-white-page break. https://sneak.berlin/20200211/your-website/ https://sneak.berlin/20200211/your-website/ Now I work around the terrible exception-throwing behavior of localStorage by leaving cookies on, but using the Cookie Autodelete extension.

grishka 6y ago

As a Russian, I sometimes encounter sites that break when Yandex.Metrica is blocked. It's basically the same thing as GA, just from Yandex. And uBO didn't have a shim for it. Not sure if it does now.