121–130 of 266 posts
Earlier quoted context omitted.
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…
The bazillion tracking scripts loaded by pages is slowing down time to view/interaction on the page. Firefox is taking scripts that are _already_ being marked as loadable asynchronously/delayed, and delaying them until the page is otherwise loaded. That's it. It's not an arbitrary 'sleep', it's an attempt to prioritize UI responsiveness over tracking scripts.
To the extent it breaks or _slows down_ pages, that's an undesired side effect, not the goal. If it does that to a lot of pages, the feature won't be succesful and will be rolled back, I bet.
Earlier quoted context omitted.
I'm not sure what article you read, but this change in Firefox is simply a change in the timing of requests to certain domains that are known to be for tracking/analytics in an attempt to improve the load time of websites. If anything this move is anti-Net Neutrality since it's prioritizing non-tracking domains over tracking domains as opposed to treating all domains equally.
A good point, although I read the article that this comment-chain is geared towards. Be more forthright with your condescension please ^_^. The article was put out by mozilla, so of course their stated point is to make everyone's experience better. I'm in marketing, so I tend to ignore a good portion of the text in marketing/PR-blogs such as this one. Aside from that, I hadn't thought of this. You're right that if an…
The _intention_, if we believe the statement (I understand you may not) is actually the opposite of this. To _improve_ perceived load times (time to display/interactability) of sites that use lots and lots of tracking scripts. If a site does not use many or any tracking scripts, it actually won't effect it at all.
There are sites that use lots and lots of tracking scripts, and it actually slows down UI. The intent of this change is to _speed it up_ again.
If it doesn't do that, and instead makes lots of sites load more slowly to the user's perception, it will not have been succesful at it's claimed goal.
Ive wondered if it would be possible to tumble the requests via P2P network. Completely destroy the analytics
Use TOR?
EDIT: Judging from the low quality of online marketing, it isn't hard to do.
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.
Does anyone know where I can find the list of sites that are affected? EDIT: Seems to be here: https://github.com/mozilla-services/shavar-prod-lists
Ive wondered if it would be possible to tumble the requests via P2P network. Completely destroy the analytics
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
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…
> My company doesn't share or sell data with third parties (it's in our TOS – and could obviously change in some Orwellian future, but we'd have to update the TOS), it's the customer's data, they can use it in the same way they'd use any other data they collect. We don't do cross-domain tracking, or aggregate behavioral information across customers, and the way we've built it, it makes it pretty hard to tie any two v…
(a) he would be fired on the spot by the company itself ( as he is not authorized to speak on behalf of the company )
(b) he would be laughed out the room because he does not control company decisions
The same applies to every single company. Every single one.
Earlier quoted context omitted.
I have an even better approach: uBlock origin + noscript
uMatrix is also great. It does a lot of the same things NoScript does, but at a greater granularity. I still use NoScript for its XSS protection features but have the main JS-blocking feature disabled because it's redundant.