Hacker News new | past | comments | ask | show | jobs | submit login

If your ad doesn't run any javascript code, doesn't place any cookie, doesn't do any kind of tracking, and is relevant to the content many wouldn't mind unblocking it in their adblocker. Especially if it is served from the same domain host the content is on. What kind of ads you serve also matter - small text ads (like Google Adsense / Adwords ads used to be a decade or two ago) was actually interesting when it was relevant to the subject content. Tiny tidbits of text are easy to scan and read or skip. I can also somewhat tolerate still-image banner ads as long as it is a few kbs lightweight and doesn't draw too much attention to itself. I absolutely abhor animated gifs, video, pop-up etc. ads of any kind. "Interrupt ads" (those placed in between the content) are also very irritating.



Thanks -- We actually maintain an exclude list of OSS ads that you can use with your ad blocker of choice: https://ads-for-open-source.readthedocs.io/en/latest/index.h...

Of note, we do run our own javascript client on the pages. Our users can opt into hitting our backend API instead of running JS code, but many just use our client directly.

We currently serve the ads on our own domain. We could implement the ability for our publishers to proxy the ad views to our domain (this is generally called "ad cloaking"), but it hasn't felt like the right thing to do.

We are also on the Acceptable Ads non-tracking list, so our domains are unblocked for people who choose that in their ad blocker. If we use a publishers domain, they will be unblocked for some period of time, but then their domain gets added to the ad blockers, and we lose this Acceptable Ads traffic.


I feel ad proxying and server side rendering would be a better fit for the brand identity you are trying to create. Why does one need javascript to serve some text or image, along side some content? One of the common reasons for blocking ads is they slowdown websites by using more resources and thus also reduce battery life. It also introduces another barrier to trust you more - how do I know that the Javascript code is not doing something unwanted (like browser fingerprinting, introducing some annoying animation etc.) - after all, it would be a pain to keep reviewing your javascript code and would be easier to just block it.


We do support publishers using an API directly, and running none of our code.

Our ad client is also open source, and pretty simple: https://github.com/readthedocs/ethical-ad-client -- we have publishers who use a published version with Subresource Integrity, but you can also just host the JS yourself if you want.


With no js the only option would be an iframe, wouldn't it? And that'd be super easy to game for the publishers. So there's gotta be some javascript involved.


Then they need to change their business model to not pay by impression or clicks.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: