wow just wow while i can’t say i didn’t see this one coming it always amazes me where greed could lead someone

  • Manticore@lemmy.nz
    link
    fedilink
    English
    arrow-up
    56
    arrow-down
    1
    ·
    1 year ago

    And while I’m at it, here’s the filters to add to your uBlock Origin’s MY FILTERS settings to block YT’s blocker:

    youtube.com##+js(set, yt.config_.openPopupConfig.supportedPopups.adBlockMessageViewModel, false)

    youtube.com##+js(set, Object.prototype.adBlocksFound, 0)

    youtube.com##+js(set, ytplayer.config.args.raw_player_response.adPlacements, [])

    youtube.com##+js(set, Object.prototype.hasAllowedInstreamAd, true)

    • themoonisacheese@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      Wait, surely that doesn’t work? It might block the "disable your adblocker popup but there’s no way this is all it takes for yt to continue serving videos?

      • Manticore@lemmy.nz
        link
        fedilink
        English
        arrow-up
        13
        ·
        1 year ago

        It’s feasible that there are other variables that have been missed, but essentially this works. The server asks us a question, and we answer it. We just skip the bit where we provide evidence.

        It’s like looking up the answers in the back of the textbook on a test. The only thing the server sees is the paper we’re handing in, it has no idea if we cheated or not.


        Boring technical explanation:

        For a server (in this case, YouTube) to see what a client (your computer) is doing, it has to reach out and ask it. When a request is made, the two points will ‘handshake’ to confirm that they heard the request, then when they’ve done it. It looks something like this:

        • Client to server: are you prepared?
        • Server to client. Yes, I am prepared. (503 if failure)
        • Acknowledge. Client requests [data].
        • Request received.
        • (Server processes request.)
        • Server to client. Are you prepared for response?
        • Yes, I am prepared.
        • Acknowledge. Response sent.
        • Response received. Close connection.
        • Connection closed.

        These steps can be repeated any number of times in response to a single user mouseclick, depending on what you’re trying to do. A ‘request timeout’ error is what happens if client/server asks “are you prepared?” and it takes too long for the server/client to answer “yes, I am”, so you hang up the phone.

        For the server to treat clients differently at all, it needs to contact them for feedback. For adblocking, it has to ask your client if you’re adblocking. Usually the server does this by sending the client a request to serve an ad - if your client never answers back to confirm it was loaded, then the server knows you blocked the ad. The devs can tell the server that if it doesn’t get a certain answer, to enable the punishment effects. (They’ll technically be sent anyway; they’re just hidden/disabled by default if your client handshakes the ad.)

        What these scripts do is lie to the server. The server asks the client if we received the ad, we ignore the script that checks whether the ad is loaded and instead directly change the answer to claim it has. Since all the server sees is the confirmation, it doesn’t know the difference.