Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Firefox 57 delays requests to tracking domains

janbambas.cz

Post reply on HN
Print view View original

111–120 of 266 posts

Re: Firefox 57 delays requests to tracking domains

#111

Post by yjftsjthsd-h »

peterwwillis wrote: post #84
mehrdadn wrote: post #34

Earlier quoted context omitted.

I understand the complaint. Let me put it this way: how would you feel if your ISP was delaying your connections to a subset of websites for a few seconds? It wouldn't violate any specs, as far as I know. But a lot of people have expressed the sentiment that they don't want middlemen messing with websites. It's not clear to me that Firefox qualifies as an exception to the rule, especially if this becomes something ot…

It's not even a NN-type middlemen issue for me, though that is exactly what's going on here. The bigger problem for me is causing regressions for users. On top of that they're causing regressions just because they don't like X traffic, and they're not even exclusively affecting X traffic - they're affecting unrelated traffic too. It's just an incredibly arrogant, annoying, bad thing to do to users who never requested…

Should only affect pre-broken code. Like complaining that a compiler is doing something with undefined behavior than you wanted: I get that it's annoying, but maybe fix your code so it's not a problem?

Re: Firefox 57 delays requests to tracking domains

#112

Post by yjftsjthsd-h »

mehrdadn wrote: post #89
testvox wrote: post #48

Earlier quoted context omitted.

Linux breaks backwards compatibly all the time. Just not for userland programs. But if you are expecting your kernal module to be low maintenance you are in for a surprise...

Do you know what the reason for this distinction is? On Windows, it seems kernel-mode APIs seem to stay quite stable as well... there are exceptions mostly on the device driver side because hardware tends to evolve (e.g. display/graphics drivers), but generic drivers (= kernel modules) generally seem to be able to rely on backwards-compatibility too.

My understanding is that it's to intentionally discourage trying to keep things out of tree, where they will inevitably break in worse ways. It also makes the GPL enthusiasts happy, but I doubt that was Linus's big goal.

Re: Firefox 57 delays requests to tracking domains

#114

Post by mehrdadn »

yjftsjthsd-h wrote: post #112
mehrdadn wrote: post #89

Earlier quoted context omitted.

Do you know what the reason for this distinction is? On Windows, it seems kernel-mode APIs seem to stay quite stable as well... there are exceptions mostly on the device driver side because hardware tends to evolve (e.g. display/graphics drivers), but generic drivers (= kernel modules) generally seem to be able to rely on backwards-compatibility too.

My understanding is that it's to intentionally discourage trying to keep things out of tree, where they will inevitably break in worse ways. It also makes the GPL enthusiasts happy, but I doubt that was Linus's big goal.

I see, thanks. I'd be curious as to why he feels it would "inevitably break in worse ways", seeing as how that's not really the case on other platforms.

Re: Firefox 57 delays requests to tracking domains

#116

Post by pbhjpbhj »

Crespyl wrote: post #37
pbhjpbhj wrote: post #23

Earlier quoted context omitted.

>The browser is irrelevant to net neutrality. // It's not the currently spoken of Net Neutrality, but it's relevant to the neutral carriage of data over the internet. If browser companies pick and choose whose data to delay (or otherwise alter) then they have the power to bias the web - Firefox could always delay scripts from other companies than Google, for example, in order to preference their business associate. T…

There's something to be said for being wary of browser makers influencing the web unduly, which we already see to a much greater and more damaging degree from IE/Microsoft and Chrome/Google; but mixing user-agent policy with transport neutrality only serves to muddy the water around the very important and really quite straightforward issue of IP endpoint neutrality for ISPs. They are two separate, important issues, b…

They could, in theory, have logical equivalence. If my ISP retains neutrality wrt transport between YouTube and my client [eg to comply with legislation] they can _in_theory_ pay Mozilla instead to throttle the connection at the UA for any user with an IP on the ISPs network, delay transfer, limit total data, etc. - the effect would surely be close to identical to ISP interference wrt the traffic carried between YT and my client browser.

Because of the possibility of such an equivalence it strikes me that the issues are not _separate_, though obviously not identical either. If Firefox blocked/throttled sites but allowed others [in the same category] for money, then Mozilla through my client would be enacting the same effects as net non-neutrality. They could charge for an add-on to remove all/some blocks, or charge the server endpoint company to remove the block just for them.

The point is that for a user the important endpoint is their sensory input, and that a browser manufacture can filter/throttle/block that consumption in the way that an ISP can.

Legislation could be written that would encompass preventing a browser manufacturer from covertly interfering in data transfer, whilst equally demanding ISPs carry data regardless of origin. Equally poorly drafted legislation targeting ISPs could impact browser makers ability to implement black-/grey-/white-listing of malware, etc..

Whilst we're focussing on such bias that can interfere in our web/internet consumption I think it's the perfect time to make sure we don't solve the problem in one place only to leave a gaping hole that allows the same corporations to enact the same controls.

Re: Firefox 57 delays requests to tracking domains

#117

Post by pbhjpbhj »

nasredin wrote: post #39
notatoad wrote: post #31

Earlier quoted context omitted.

it's an issue with similar consequences to net neutrality, but it's very much not the same issue. The network is one layer, the client is a different layer. Let's not start forcing clients to conform to network rules, or vice versa. additionally, the reason net neutrality is so important is because there is no consumer choice in the ISP market for many users. Even when one browser is dominant, there's a lot more choi…

I think the anti-net-neutrality people are running out of fresh, not yet discredited arguments. In OSI model IIRC: Application (software) is layer 7. Physical connection is layer 1. I am sure somebody will correct me.

Not sure who you're claiming is anti Net Neutrality, but if that's levelled at me it's quite wrong.

See my other comment in thread, but in short I don't think a user cares really that action is at a different level of the conceptual OSI model, they care if they can consume given media, if NN legislation shifts things so that the browser blocks the media from a particular server instead of that servers upstream ISP I don't think users are going to be applauding too much.

Re: Firefox 57 delays requests to tracking domains

#118

Post by peterwwillis »

yjftsjthsd-h wrote: post #111
peterwwillis wrote: post #84

Earlier quoted context omitted.

It's not even a NN-type middlemen issue for me, though that is exactly what's going on here. The bigger problem for me is causing regressions for users. On top of that they're causing regressions just because they don't like X traffic, and they're not even exclusively affecting X traffic - they're affecting unrelated traffic too. It's just an incredibly arrogant, annoying, bad thing to do to users who never requested…

Should only affect pre-broken code. Like complaining that a compiler is doing something with undefined behavior than you wanted: I get that it's annoying, but maybe fix your code so it's not a problem?

This isn't even a broken code issue. This is a totally unnecessary functionality regression issue. Instead of just loading a page, they're waiting four seconds to load the page, because the page uses an asset on a domain they flag as a tracking domain.

This is like if the compiler generated loops with 4000ms sleeps because the app links a library the compiler thinks is annoying.

Technically the compiler never said it wouldn't add random sleeps into loops. It's totally in spec! What's the big deal?

Meanwhile, my app is slow now. Or in the case of some apps, actually broken for active use cases where it used to work fine. Which, again, is totally regression by any QA standard.

Re: Firefox 57 delays requests to tracking domains

#119

Post by anfedorov »

Sophistifunk wrote: post #74
codezero wrote: post #68

I work for an analytics company, this will affect my snippet – I don't think it is a big deal, but I'm going to benchmark it on a few sites. From what is described here, it may actually help us. When folks throw tons of tags into their site, we're all competing against each-other as well as the site's own loading – it makes sense to prioritize the site's rendering. I think of this as no more invasive than pre-caching…

It's a grey area. But I am interested, do your ToS forbid your customers from on-sharing the data with cross-site aggregators?

"on-sharing the data with cross-site aggregators"?

The ToS and Privacy Policy of an analytics company discloses what the that company may do with their client's users' data, not what the client can do with their own users' data.

There's another Privacy Policy between the client and the user where the client discloses what they may and may not do with user data and the user decides whether to become / remain a user.

There are also laws which dictate the data handling further on behalf of large groups of users, e.g. GDRP for EU citizens and, on this side of the pond, interesting Supreme Court cases being decided about what kind of data users could have property rights to: https://en.wikipedia.org/wiki/Carpenter_v._United_States

Re: Firefox 57 delays requests to tracking domains

#120

Post by fishmeat »

notyourday wrote: post #104
marten-de-vries wrote: post #2

Interesting approach. I hope more browser vendors will adopt it. It comes with an additional advantage: if a website still needs to function when tracking domains are delayed a second or so, they likely will function too with said domain completely disabled (e.g. using extensions). Sounds like a win from a user perspective.

I have an even better approach: uBlock origin + noscript

Is there much different between uBlock origin vs Ad Block Plus?
Post reply on HN