Ain't no party like a third party | Hacker News Reader

Ain't no party like a third party

adactio.com

97 pointspmlnr54 comments

> I know, I know. If you refuse to add that third-party script, your boss will probably say, “Fine, I’ll get someone else to do it. Also, you’re fired.”

I’ve been on two ends of this during my brief time in media. I once worked on a team that had nothing to do with ads, but the manager who replaced my original one basically told me I’d be overlooked for any promotions because I would not pivot to work on adtech. I left pretty soon after.

At a separate company, I made it clear from the start that I would not work on ads or tracking of any kind and I had some proposals to reduce invasive tracking that were actually heard and implemented. Unfortunately, in media, it’s a losing battle if you approach it from an engineer / IC level. Many partners expect you to have all types of scripts to measure engagement, bot detection/fraud, etc… and the voice that’s heard is the one giving the company the most money.

> I left pretty soon after.

That's it, we work in a pretty privileged market where we can more easily vote with our feet, generally speaking.

Of course, we also work in one where wages can end up being pretty exorbitant, and where there's plenty of people who are morally flexible depending on their own conscience, compensation, or whether the ad tech is wrapped in hype-driven development.

> This tactic will only work if everyone agrees to do what’s right.

I do not know who said it first, but: "If your solution to some problem relies on “If everyone would just…” then you do not have a solution. Everyone is not going to just. At no time in the history of the universe has everyone just, and they’re not going to start now."

More companies need to take a stand and not use any third-party scripts or third-party cookies. We do that with our search engine and it works without Javascript.

There are plenty of historical examples of "everyone" in a union "just" going on strike to get a problem fixed.

Earliest instance I can find (where it is presented as if original): https://squareallworthy.tumblr.com/post/163790039847/everyon...

The reason people add third-parties is the same why big companies outsource cleaning to a cleaning company: pay someone else to own a subproblem of yours. Even the analogy is similar: evil cleaner can steal secret documents and wreak havoc in your office.

In media, there are a handful of third-parties that you de facto must load, because this is the only way to compare various metrics between different websites (number of views etc.); you can't rely on companies to self-report the numbers; even if they acted in good faith, the small details of how they collect the data would lead to discrepancies.

I hate third-parties like everyone else (and especially since I used to be a perf engineer and had my hands tied with bloated unremovable 3p libs), but they're just not going away.

Well if you are a somewhat serious company you probably have a clean-desk policy, workstations that lock themselves after a couple of minutes inactivity and encrypted hard-drives. Also there are probably areas where you don't let the cleaner go, like that closet with all the switches. And the cleaner has in some form been vetted. You see that person a couple of days every week and start building a relationship. You can see if he/she suddenly shows up drunk every day.

With security and risk it works like this. You can accept some risk if you at the same time find solutions to mitigate any dire consequences. With third-party javascripts you are giving away all control. Now if you are in an nonsensitive business maybe it's okay to use some third-party javascripts here and there, but is it reasonable to have those on an e-commerce checkout for example? Also Subresource Integrity has been mentioned a couple of times already here to mitigate the risks of third-party javascripts.

> And the cleaner has in some form been vetted.

Oh, you sweet summer child, I admire your optimistic view of life. Please never lose it.

I have this facepalm discussion with people who want to "upgrade" our security by moving something into the office. "So, you want to trust our cleaning staff who regularly fail to lock our front door more than having it in a locked colocation cage with monitoring?"

Even if the cleaning staff were "vetted" (which they are not), humans gonna human.

For personal sites? Sure, why not.

For anything commercial though, especially in media publishing, this is just insane.

I'm beginning to think the old generation of "celebrity" web devs (the ones that became famous in the 2000s - now around in their 50s) has really lost touch with the modern web for some time now. And this comes from someone who's actually bought all of Jeremy's books.

The fact that Google is switching away from third party cookies is surely not a matter of "resisting the tide" as Jeremy writes. It's actually about more control. Whoever controls the web platform (=the browser) can now control the ad landscape [1]. See how Google used AMP to promote a supposedly "faster" web (and it's now being sued for for preferencial ad placement) [2].

[1] https://www.reuters.com/technology/googles-browser-cookies-p...

[2] https://www.theregister.com/2021/10/26/google_deliberately_t...

Your reaction is in line with this speculation about reactions from the article: "On today’s modern web it sounds like advice from a tinfoil-hat wearing conspiracy nut."

Your post doesn't address any details from the article; it reads like a gut reaction.

I spent a good chunk of my career working in software security.

I'm fairly damn well convinced at this point that a WHOLE LOT of modern security practices are actually technical run-arounds on missing legislation.

Modern security practices intentionally silo users into a single domain - Usually a large tech firm (Facebook, Google, Apple, etc) and then try as DAMN HARD as they can to lock users there - all in the name of security, of course.

We can't let the user LEAVE our site! How can we know for sure they'll do what we want if they go somewhere else (oh, and also - that thing they do that we don't approve of? It might be DANGEROUS! - think of the children!)

It turns out small sites can make a pretty compelling web experience when they can coordinate and work together (links to each other, shared preferences, decentralized identity) and it's absolutely NOT a mistake that many large orgs are now using every technical lever than can to prevent that sort of organization.

I see "Security" as filling the same space as union busting right now - make it impossible for those smaller than you to become threatening by banding together. When you keep them divided you can eat them at your leisure.

> Modern security practices intentionally silo users into a single domain - Usually a large tech firm (Facebook, Google, Apple, etc) and then try as DAMN HARD as they can to lock users there - all in the name of security, of course.

> We can't let the user LEAVE our site! How can we know for sure they'll do what we want if they go somewhere else (oh, and also - that thing they do that we don't approve of? It might be DANGEROUS! - think of the children!)

I don't think I've ever seen a walled garden justified in the name of security. Generally, it seems to be more about keeping the user within your ecosystem, so you can capture the value of their attention (i.e. show them ads).

Apple requires all apps to be installed through the App Store. Google requires all in-app payments to go through Google Play. The obvious reason for these requirements is that it's profitable for them. But how do they justify it to their users? More convenience? A unified experience? No, their most prominent argument is that it's safer that way.

Those examples are not applicable. The context of the article, and the comment I was quoting from, clearly indicate a web environment.

Well, you wrote “a walled garden”, which could reasonably be interpreted as any walled garden in software generally.

But if we are charitable and limit ourselves to web site “walled gardens”, how do YouTube and Facebook, etc. justify their “oops, you clicked on an external link! If might lead anywhere! Are you really, really sure you want to continue?”, if security is not their argument?

Ads. They want to introduce friction into the process of leaving their site so they can keep showing you ads.

Ad revenue is obviously the motive. Nobody is denying that. The argument they actually present to the user, though, is about security. Both in politics and in online business, security is an extremely convenient excuse for forcing people to do what you want and hiding your true motives. That's the whole point of the current thread.

Citation needed.

He seems to have addressed your point already (I think. "just insane" is a little vague, so it is hard to tell what your objection is).

> Easier said than done, right? Especially if you’re working on a site that currently relies on third-party tracking for its business model. But that exploitative business model won’t change unless people like us are willing to engage in a campaign of passive resistance.

> I know, I know. If you refuse to add that third-party script, your boss will probably say, “Fine, I’ll get someone else to do it. Also, you’re fired.”

> This tactic will only work if everyone agrees to do what’s right. We need to have one another’s backs. We need to support one another. The way people support one another in the workplace is through a union.

True though this may be, I don't see unions gaining any real mindshare among developers. Whenever the subject comes up, you get the standard straw man arguments against unions, and that either ends the discussion, or turns it into some extended shit show that ultimately goes nowhere.

While you might be able to easily "vote with your feet" in this industry, not everybody can afford to stand up for a principle like this on penalty of getting fired.

I don't know what the real solution here is. I'd like to see unions make gains among software engineers, but there's a lot of animosity from people who think they'll be "held back" if they have to join a union. I don't see that kind of attitude going away anytime soon.

The IEEE code of ethics and the ACM code of ethics both have language in them about privacy, so I think those software engineers are not living up to the standards of their professional societies.

I don't know what industries you've been working in but in any sensitive business third-party javascripts are under the same tight controls as any other code, and changes in javascripts are going through the same change management controls as any other code before entering production.

Even Google have had issues with malware being distributed via adsense: https://www.businessinsider.com/google-has-shut-down-a-malic...

Not to speak of the Megacart hacks: https://www.riskiq.com/blog/external-threat-management/magec...

You can't put third party javascript through change management. Unless you download and host it yourself, in which case it's not really third party.

Well we can absolutely talk semantics. Code written by a third-party is third-party code however it is hosted. Your conclusion is right however. If you are serious with your security and change management you host all scripts yourself. Or use sub-source integrity:

https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

Of course it's third party code. I meant that it's not really third party in the context of this article advocating for a same origin policy for javascript.

I only came across SRI while dealing with CSP, and I didn't quite understand why anyone would subject themselves to that until just now. Thanks for pointing it out.

To get this through what you have to do is

a) create a Chrome clone that rejects third-party scripts and has other security enhancements by default (do browsers really still need http support?). Then, you can say "Your site doesn't work with SuperChrome!" and shame until they fix it, to reach also the SuperChrome users (hopefully growing in number). SuperChrome cannot be a loose set of extensions, it has to be a well-defined thing.

b) have other services treat sites preferentially: higher throughput, better caching, higher ranking in search results, better user retention. I think this can easily be achieved, because the load-time will be shorter on such sites, therefore users will stay longer, and faster sites are already preferred by Google. This is the "AMP route" btw.

Yes. Browsers really should maintain HTTP support. There’s no reason to require every static site in the world to be encrypted in transit. And in particular, there’s no reason to block off all the actual good websites that are old static sites still serving their purpose.

Stick an SSL proxy in front of them and be done with it. This was a solved problem 15 years ago.

> There’s no reason to require every static site in the world to be encrypted in transit.

Yes, there is. Encryption doesn't just provide privacy, it also provides authentication. Being able to tamper with downloadable code (i.e. javascript) in transit is a nonstarter. Everything needs to be authenticated, and the way we authenticate data from a webserver in 2021 is by using TLS.

Ban port 80.

Here [1] is an interesting article that advocates for not blindly enforcing SSL everywhere as it makes deliberate mitm caching impossible. Also discussed in 2018 [2]

[1] https://meyerweb.com/eric/thoughts/2018/08/07/securing-sites... [2] https://news.ycombinator.com/item?id=17707187

> do browsers really still need http support?

There are some legitimate resources I use that are http only (eg the Dungeon Crawl Stone Soup wiki). I turned Firefox over to auto-error/alert on http, and it bugs me every time I go there

> On today’s modern web it sounds like advice from a tinfoil-hat wearing conspiracy nut.

Has this become common? I’ve been developing “modern web” SPAs for years now and still never load scripts from 3rd parties. Maybe I don’t understand the meaning of “modern web” in this context?

If you want to sell your product/look for investors you need analytics. The easiest way is to just slap Google snippet in there. If you decide not to do it you're off to self hosted analytics solutions which are just not comparable to google. Building small sites, blogs, informational sites is pretty easy without 3rd party scripts but when you're going into mid size ecommerce (by mid size I mean company that have decent advertisement and sales research budget) it's getting way harder to stay away from 3rd party analytic and marketing tools.

Hmm, I checked some local e-commerces. They have more trackers than people actually fulfilling orders, that I don't understand.

That's actually skew in another direction. If marketing is not generating sales they're generating job for them self instead.

> If you want to sell your product/look for investors you need analytics.

Most meaningful analytics don't need these trackers. They can be done server-side with info you already have such as orders, logins, active users. If an investor bases their decision primarily based on how many users Google Analytics reports the probably aren't the most critical.

A few years ago, it was widespread advice that you shouldn't host a copy of jquery on your own server, and instead you should include it from cdnjs or jsdelivr in the hopes users would have it cached, having needed it on another website.

This advice is now obsolete, because it was realised sharing caches between sites was a privacy problem. Evil.com can request example.com/logo.png and if it loads instantly, know that you've visited example.com before.

Yeah at best that'll break your site when the library has the next update, changing random things that nobody asks for. And you'll get a swapped malicious file at worst.

Well, back when that was common you'd import a numbered version, like "https://cdn.example.com/js/library-v1.2.3.js" which, unless the CDN was evil, would be immutable.

Someone even came up with a standard for "subresource integrity" [1] where you could specify a checksum of the thing you were importing from a CDN, so it couldn't be replaced by an evil CDN. I don't believe it ever achieved widespread use.

[1] https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

It doesn't need widespread use since you get the benefit of using by just using it on your own site.

3rd party JS is pretty much unavoidable if your main source of income is ads. It's particularly true for almost all media pages.

That's of course not the whole web, but it's a huge chunk. If you do anything that does not require ad funding, you have a much easier time to do without 3rd party JS.

If a site is small enough, it's going to use 3rd party sources for convenience. If a site is large enough to have it's own cdn, etc it's going to have 3rd party sources for ads.

https://almanac.httparchive.org/en/2019/third-parties

It's over 90%

> still never load scripts from 3rd parties

Hm, maybe you and I are reading this differently, but I read it as not using React or Angular or Ember or Vue or jQuery or whatever is fashionable until next Tuesday. You don't eschew all of those as well do you?

People who have been saying things like this all along don't get to say "I told you so," tho, because we gave up on this issue years ago, and are currently involved in incessant bitching about the next society wide stupidity currently being perpetrated that will take decades to fix when the error id finally recognized.

Oh crypto you mean ? I resist the call of the incessant exchanges and crypto startups stealing all my colleagues, I must resist even if they pay double arrrgl

Browsers are now beginning to block third-party cookies.

I assume that means by default? I remember having that option like twenty years ago or something like that.

Edit: Navigator had the option to block 3rd party images. Blocking 3rd party cookies might be more recent, but not "now beginning" by any means.

Without searching for a timeline of Safari development, I recall that Safari has had the option to block 3rd-party cookies for a number of years. Last year Safari started blocking those cookies by default:

https://www.pcmag.com/news/safari-now-blocks-all-third-party...

And now that I look, there is no longer an option in Safari Preferences that mentions anything about 3rd-party cookies. It's either "all cookies", or "no cookies".

Google isn't dragging their feet and pushing the timeline for their "Privacy Sandbox" update because their ad business will be hurt - likely these changes will help them.

It's because EU/UK regulators are blocking this move as anti-competitive, and the FLoC/FLEDGE/Whatever cohort targeting gives Google essentially a monopoly on targeted ads since they have the best look with 1st party data of almost any company (except maybe FB).

My prediction - it'll get pushed back another 2 years to 2025 since the industry can't figure out what to do. There's hundreds of billions at stake and Google wins no matter what.

I tried the request mapper link, with two URLs.

http://news.ycombinator.com

http://cnn.com

Warning, the second one takes a while. I remember hand-coding HTML and "bloat" was a page that took annoyingly long to load on dialup. Has it really been worth it?

Coincidentally, last time I used dialup, Hacker News worked just fine.

Wouldn't this make ad blocking much harder for end users?

I'm not sure whether it’s silly or genius for this post to lead with “don't load 3rd party scripts” and end with “by the way we all need to unionize for this to work kthxbye”.

Not sure I'd go so far as to call it "genius", but it is certainly clever (and possibly effective).

Oh now I will read the article.

Reply on news.ycombinator.com