Hacker News new | ask | show | jobs
by rsj_hn 3260 days ago
The thing is, the software does suck some of the time. Here too, I'm not saying your software sucks, but web developers have developed several bad habits that put users at risk for no particular reason other than sheer laziness.

here are some examples:

1) Instead of putting third party scripts under your own version control and hosting them yourself, you host them from a "free" CDN which then stores tracking cookies in the origin of the user loading the script. How hard is it to serve all the js libraries you need from your own server?

2) You like some nice widget, like Google Maps. But hey, to use this widget, you need to load a third party script in your origin. No biggie, it's better than paying for a maps widget, right? Except now the user has a tracking cookie in your origin and you didn't disclose this or give the user an option to opt out. What you could have done is loaded that map inside an iframe that is served from a content domain or throwaway domain, so that there is a separation between your cookies and your scripts and the third party cookies and their scripts. This goes for all other widgets as well.

In the above two examples, the developers aren't being paid or are receiving revenue in exchange for installing tracking cookies in their origin, they are just letting it happen because they don't care and they want things to be easier on them.

I get that there are ad supported websites, and if this is your business model, then you are free to give it a go -- but I get upset when the justification for the tracking cookie is developer convenience rather than any kind of business decision to drive revenue.

1 comments

WRT #1, while it certainly isn't difficult to serve libraries from your own server taking advantage of a CDN allows you to take advantage of browser caching and offloads bandwidth.

I'm not saying that CDNs should be setting tracking cookies, mind - I'm just pointing out that as a developer a CDN helps me improve the experience of my users and as a user a CDN helps you reduce my costs to provide whatever value I am to you.

Honestly, if browsers were able to quickly determine that my "reactXX-X.min.js" was the same as Facebook's I would probably just eat the occasional edge costs.

Well, that's the thing -- there are good CDNs out there, but they expect you to pay. But why is the developer making the decision of making the user pay for it with their privacy? Without any kind of notification or agreement, or even discussion, really, with the people who should be deciding this stuff.

Now perhaps I'm wrong, and this is not a developer decision at all but a decision from the business side, where they weighed the privacy issues against the slower performance against the cost of paying for a CDN, and decided this was the right way to go, then they instructed their developers to start loading all these scripts from third party free CDNs.

Except, I've been doing this thing for over a decade, and developers keep sneaking this shit in, and then acting surprised that it's not OK to pull jQuery from ye-favorite-free-CDN, but they need to stick the thing into static resources where it will be served from our CDN. And I keep finding devs doing this also when I do pentests of third party sites, and the response from the security POC is usually "we had no idea this was being loaded from the free CDN. We even have a contract to use Akamai, we just didn't know".

At the same time, I keep seeing this in open source software, even in examples and tutorials, where supposedly the user speed is not so crucial, as well as stackoverflow, and I also know there is a lot of cut and paste going on, so I still think this is just bad hygiene on the part of the developer community, where people are just very cavalier about letting third parties inject javascript into your origin.

But you do have a fair point. End of rant.