Comment on What is Firefox supposed to do?

• mke@lemmy.world ⁨3⁩ ⁨months⁩ ago

  I have ad blockers and anti-tracking extensions, but they don’t do anything against this new feature because it’s the browser itself doing it.

  I don’t think that’s the case. If you have e.g. uBlock, the API for this new feature won’t be called, even if enabled, according to Colin (developer for Multi-Account Containers) in the Mozilla General matrix chat. I’d lean towards trusting Colin over you, here.

  I get your point, and your frustration, but please don’t talk so confidently about things you aren’t actually certain of.

  source

  • orclev@lemmy.world ⁨3⁩ ⁨months⁩ ago

    Maybe, but I’m not seeing anything that suggests that would be possible.

    Here is the technical documentation for how this feature works. The short version is that it exposes some new JS functions that sites can invoke to register various ad related activities. That data in turn gets forwarded by the browser to a 3rd party using a protocol called DAP which can be considered out of band for the purposes of website interactions. I see no evidence at all that uBlock would be able to block the DAP calls, and limited evidence it could effectively block the JS functions.

    uBlock works primarily by blocking network requests using a series of rules. Here is the syntax supported by uBlock for defining its blocking rules. It primarily works by inspecting hostnames, although there is some capability to match on things like HTTP headers, or raw text. There is the capability of blocking an entire script element if it matches specific text E.G. navigator.privateAttribution, however doing so is likely to break sites quite drastically. There is very limited ability to surgically remove such things. Maybe if you injected some JS into each page that overwrites the navigator.privateAttribution namespace with stub functions that do nothing (I believe this is actually what the browser does when you opt-out of that feature), but I’m not sure if that’s even possible or if the browser would simply ignore attempts to write to that namespace.

    It’s possible Firefox is being “smart” and if it sees you have uBlock or similar ad blocking extensions loaded it disables this feature. It’s possible that there’s some extra tricks uBlock or other extensions can pull to block this at a more fundamental level that just aren’t obvious from looking at their documentation. But nothing in the documentation for this feature seems to guarantee any of that, and it’s frustratingly vague in several areas. Regardless none of that changes the fact that this should have been opt-in from the start instead of opt-out. Mozilla argues that they made this opt-out because they wanted to insure a large enough user base to anonymize the collected data, but that alone suggests there might be privacy problems with this entire thing. This wouldn’t be the first time that a supposedly anonymized data set could be at least partially de-anonymized.

    source

    • mke@lemmy.world ⁨3⁩ ⁨months⁩ ago

      If I understand this properly, I believe you’re missing the point. I’ll explain my reasoning so you can point out any flaws you perceive in my reading of your comment or my argument.

      You’ve focused too much on how uBlock could theoretically (or not) block outgoing DAP calls and JS code execution. This is way past the point where UBo would’ve done its job. You need to consider the order in which these events may happen and how they depend on one another.

      From the explainer:

      At impression time, information about an advertisement is saved by the browser in a write-only store. This includes an identifier for the ad and whether this was an ad view or an ad click.

      A site can register ad impressions, either when the ad is shown or when the ad is clicked, at their discretion.

      If the ad is never downloaded, something UBo is great at guaranteeing using filter lists, the user could never reach impression time. The JS code is likely never downloaded. An impression is never generated. There is no point in generating impressions for nonexistent, unseen ads. That would be garbage data, which is actually worse for advertisers. No impression data is ever generated, thus there’s nothing to send to the aggregate either.

      The user does not participate in the system, at all, because it depends on actually engaging with its components, and UBo users have freed themselves from this system completely long ago.

      Remember, this is not a privacy enhancer targeted at people who use UBo, but at people who don’t, which is still most people, sadly.

      There is very limited ability to surgically remove such things.

      There is no need to do so. UBo removes ads with prejudice.

      Regardless none of that changes the fact that this should have been opt-in from the start instead of opt-out.

      I’m still on the fence about this. Currently, the way I see it, Mozilla’s biggest sin is being awful at effective communication. Worse than Google, but Google has intent to deceive, while Mozilla seems like they’re actually trying to do it properly and just… not getting it right. Spectacularly. Multiple times in a row.

      Assuming user consent really stinks, though.

      but that alone suggests there might be privacy problems with this entire thing.

      I’m not sure if this is a good argument. This is by design, aggregate anonymization works with quantity. I don’t think that means it’s necessarily a bad design. We use lots of faulty, problematic tools everyday—so long as this one is better than what it’s trying to replace, I believe it deserves a chance.

      This wouldn’t be the first time that a supposedly anonymized data set could be at least partially de-anonymized.

      Yes, that’s true. I’m choosing to both hope all these experts make it work, while also keeping a careful eye on the project, to the extent of my ability. Maybe you could call it a lazier version of trust, but verify.

      source

      • orclev@lemmy.world ⁨3⁩ ⁨months⁩ ago

        Assuming both the ad and the JS to track said ad are served from a 3rd party (or at least a different domain) that would hold at least so far as recording impressions goes. On the other hand there’s still the conversions part of this to consider, although without recordings of impressions the utility of that (and privacy risk) is debatable.

        Ultimately I don’t like being opted into anything that collects data, theoretically anonymized or not. I don’t like that this DAP process is running in the background and randomly sending data to some 3rd party (once I figure out that hostname it’s absolutely getting blackholed at the network level).

        Ads are a plague, you give them even an inch and they’ll eventually take everything. It started with broadcast TV, then ads overran it. So they introduced cable. Sure it was expensive, but no ads! Then ads started creeping in and before you knew it cable was a complete ad infested shitshow. Then along comes streaming, a breath of fresh air. Watch what you want, we you want, and best of all no ads. Where are we now? The ads are slowly creeping back in and before long it will be just as bad as cable, 40 minutes of ads in every hour of video.

        For a while we’ve been winning the war on the internet, able with some effort to hold back the tide, and Firefox was one of the last bastions that seemed to be working with us instead of against us. This though looks like a crack in the armor. It’s the first step along a path we don’t want to go down. I don’t want Mozilla wasting development time pandering to ad companies, I want them improving the browser for us the users. The only ad related content I want to see from Mozilla is improved ad blocking.

        source

        • -> View More Comments
• Zarxrax@lemmy.world ⁨3⁩ ⁨months⁩ ago

  You may wish to disable automatic updates and follow release notes.

  source

  • orclev@lemmy.world ⁨3⁩ ⁨months⁩ ago

    I do follow release notes which is how I knew to disable it, but the point is that I shouldn’t need to. The reason Mozilla didn’t ask before enabling this “feature” is because they know most people would disable it. That should be a pretty big clue that this isn’t something their users want.

    source