Comment on What is Firefox supposed to do?

• orclev@lemmy.world ⁨1⁩ ⁨month⁩ ago

  That’s fine but it should have been opt-in or at least asked before enabling it. 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. If I hadn’t read about it and gone in and disabled it I would be providing data to ad companies without even knowing it and that’s unacceptable.

  source

  • mke@lemmy.world ⁨1⁩ ⁨month⁩ 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 ⁨1⁩ ⁨month⁩ 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 ⁨1⁩ ⁨month⁩ 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

        • -> View More Comments
  • Zarxrax@lemmy.world ⁨1⁩ ⁨month⁩ ago

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

    source

    • orclev@lemmy.world ⁨1⁩ ⁨month⁩ 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
• okwhateverdude@lemmy.world ⁨1⁩ ⁨month⁩ ago

  This take is so naive. You really think the advertisers will give up their current, rich sources of data for Mozilla’s watered down crap? Given the current market share, no one is going to pay a premium for this little data. Or do you think the people that came up with everything creep.js does in order to track you will suddenly grow some ethics and stop doing that just because Mozilla is selling my data in aggregate? Not only is this a dumb idea that won’t even work (like just about every other non-browser thing they have tried), but then they also felt selling my data was within their right.

  Mozilla Corp was never entitled to my data to sell in aggregate or to stay in for-profit business.

  source