Live data from Hacker News

React Armor: Protect your DOM from third-party tampering

github.com

11–20 of 55 posts

Re: React Armor: Protect your DOM from third-party tampering

#11
post #4

Hooray, get ready for broken websites with modal overlays, CSS popups, ads, and tracking built-in, and no way to disable them!

Hm, why wasn't this possible before though? seems like something every ad company would have built already, given the presence of ad-blockers, etc.

From my understanding: if the page as a whole is not obfuscated then irrespective of how much messed-up html and JS you couch the ad in, then the ad blocker can just remove the base element.

If the entire page is obfuscated it becomes a more difficult problem.

Re: React Armor: Protect your DOM from third-party tampering

#12
post #3

I know this is malicious to those who want the web to be open, but I love it. Not because I particularly agree with the motive, but it's just such a cool demonstration of the power of React. Doing this has never been so easy. Google has been doing this for a while for a few of their products (Google Plus is one of them, I believe), but they've got large engineering teams who can commit time and resources to protectin…

The class-name obfuscation on Google+, GMail, etc. is for latency reasons, not security. When Google wants security they serve content out of a seamless iframe on https, because obfuscation doesn't give it to you.

Re: React Armor: Protect your DOM from third-party tampering

#18
What they thought this will achieve is: people will stop using scripts that changes "ul li .Bar".

What it will actually achieve is: people will spend more scripts to heuristically check which element under "ul li" could be ".Bar" based on the layout, attributes, and contents. Then they'll change "ul li .whatever", sometimes mistaking the class and getting a broken website. Or worse, they'll select on "ul li @background-color='red'" (or whatever the syntax is), which you can't obfuscate any further, but is almost guaranteed to randomly be incorrect.

I get where they come from (user extensions affecting how the website works), but I'd say the alternative it worse :/

Re: React Armor: Protect your DOM from third-party tampering

#19

What they thought this will achieve is: people will stop using scripts that changes "ul li .Bar". What it will actually achieve is: people will spend more scripts to heuristically check which element under "ul li" could be ".Bar" based on the layout, attributes, and contents. Then they'll change "ul li .whatever", sometimes mistaking the class and getting a broken website. Or worse, they'll select on "ul li @backgrou…

user extensions affecting how the website works

That's really the point of having them, isn't it? To make the site work the way the user wants. In fact I'd say what it will actually achieve is less visitors to your site... they're just going to leave and go somewhere else.

I classify this along with the anti-right-click, disabling select/copy/paste, changing the status bar, resizing windows, and other general "DO NOT WANT" aspects of sites.

Re: React Armor: Protect your DOM from third-party tampering

#20

What they thought this will achieve is: people will stop using scripts that changes "ul li .Bar". What it will actually achieve is: people will spend more scripts to heuristically check which element under "ul li" could be ".Bar" based on the layout, attributes, and contents. Then they'll change "ul li .whatever", sometimes mistaking the class and getting a broken website. Or worse, they'll select on "ul li @backgrou…

user extensions affecting how the website works That's really the point of having them, isn't it? To make the site work the way the user wants. In fact I'd say what it will actually achieve is less visitors to your site... they're just going to leave and go somewhere else. I classify this along with the anti-right-click, disabling select/copy/paste, changing the status bar, resizing windows, and other general "DO NOT…

What do you do if you create a website which modifies the dom, but find out what your users have extension XYZ which completely breaks are our assumptions about what the dom is? For example you just received a server-rendered page which should have "ul/li/span.Foo", but find out that the span is a link now instead, so your JS breaks down.

All of the things you mentioned are websites trying to break your expected behaviour. This is the exact opposite - your extension is breaking the expected behaviour and the website wants you to leave it alone.

Post reply on HN