Hacker News Reader

Comment by lini | Hacker News Reader

It's a cat and mouse game. Every couple of months FB tries a new version of the HTML layout with slightly changed elements and every time someone writes a CSS selector that manages to find the appropriate tag for the sponsored story and hide it. Currently with the new FB redesign it's:

div[data-pagelet^="FeedUnit"]:has([role^=button]:has(> span:has-text(S)):not(:has-text(1)):not(:has-text(2)):not(:has-text(3)):not(:has-text(4)):not(:has-text(5)):not(:has-text(6)):not(:has-text(7)):not(:has-text(8)):not(span:has-text(9)):not(span:has-text(w)))

View on HN

I find this so crazy! It says "Promoted" right there. I can use my browser's inspector to click on the element to select the div and then delete it.

Is there no simple way to accomplish the same in a browser extension without bringing in some crazy AI solution? Just read the webpage as it is rendered to an actual human, identify the x/y coordinates of the element, pass that to Firefox/Chrome/Safari's element selector, and delete. Voila!

I'm sure there's a very good reason why this exact solution just doesn't work, but I'd love to hear it explained, because it seems so simple to me. Then again I'm a backend guy, and I just don't even know frontend.

> Just read the webpage as it is rendered to an actual human

Humans read web pages using their vision. So what you’re proposing is to look at the final rendered image of text instead of the DOM tree. The only way to do that would be to perform OCR (https://en.wikipedia.org/wiki/Optical_character_recognition) on a screenshot of the whole web page. This would be possible, but I think nobody’s tried because it feels overly complicated, and many OCR libraries can’t understand text 100% reliably, not even computer-rendered text. Also remember that the OCR library would have to run in JavaScript. Would it run fast enough to block the ad before the user sees it? Would it annoy the user by spinning up their computer’s fan?

> identify the x/y coordinates of the element

This wouldn’t be too too hard to implement using `document.elementsFromPoint(x, y)`. This part isn’t the problem.

You could replace OCR with a CNN trained to predict bounding boxes of ads. You could generate the training data by looking at the visual diff between a page rendered with an ad blocker enabled, and the same page rendered with the ad blocker disabled.

I don't want a badly trained CNN accidentally removing relevant content from the page, though. The CSS selector solutions are deterministic, and you can't just throw ML at every damn thing you see.

Also, the problem with OCR/CNN solutions are that you have to render ahead (i.e. parts of the page that you haven't scrolled to yet) to remove ads without being disruptive to the website's content flow.

I'm not sure that facebook does it for the "promoted" text, but they have been known to mess with layout to make text difficult to detect. For example each character of a word might be in a separate <div> and be strangely offset so as to line up. The divs might not have the mutually common parent element that you would expect.

The browser has no context for what it is rendering. Should it ban every element containing "promoted"? Even posts by people?

The word "promoted" might not even appear as text, it might be simply a series of divs with one letter each (out of order, of course) and then visually defined with CSS.

The browser doesn't know it's rendering a word, it only knows it's rendering a series of divs with one letter on each, and it absolutely can't know what the visual representation of the divs spell.

What you are proposing is another crazy AI solution, OCR.

Which would mean to render the document, using pattern recognition delimit the area with the sponsored post, then pass those coordinates to the browser in order to select the currently visible element, then delete it.

Even then I could think of a thousand ways to beat this, because OCR can't see invisible things and you can do all sorts of fun stuff with invisible styling, and it'd be the same game of cat and mouse the ad blockers are currently running but at a higher level of abstraction.

I think the issue isn't finding the text "Promoted", but coming up with a way to figure out exactly which element containing that text to remove (because simply removing the text itself would not be a good solution). I imagine that Facebook could be doing something like generating a CSS class names on based by using a different seed or producing different element configurations that visually appear the same for each page load (or worse, for each ad on the page...)

I think, the uBlock Origin context menu does that?

Similar tactic on Twitter as well. I'm not even doing it for ad blocking necessarily, just to hide features I don't want like "who to follow" or all those nonstop COVID updates.

In case anyone interested: https://github.com/dawnerd/ublock-filters/blob/master/sites/...

How can they get away with these deceptive obfuscatory practices without breaking web accessibility standards (e.g. screen readers parsing alt text and meta data for the visually impaired/blind) without opening themselves up to serious liability and class action lawsuits?

Reply on news.ycombinator.com