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 protecting data.
If you have a justifiable business reason for doing this, then your life just got a little easier. I think this would also help against some forms of XSS too - so there's some silver lining for you.
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.
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.
This is such a horrendous idea. Apart from the fact that this does virtually nothing, this is a prime example of the difference between security and obscurity and how neither is the other.
This should be called React Obfuscate rather that React Armor.
I've done a fair amount of web scraping before and each of their tricks can be broken with enough care. Obfuscating html not only breaks many of the good things about the web but also makes things harder to debug.
We handle over 1600 Japanese institutions at the company I am working for in Tokyo (Moneytree.jp), and we haven't arrived at a situation where we were defeated by what React Armor is trying to prevent.
I'm sorry, I've reread your sentence several times, and I still don't understand what it's trying to say.
Does your company have the same goals React Armor has (this seems to be what your double-negative is saying), or is it the party React Armor is trying to protect against, or is it relevant to React Armor in some other way?
What kind of Japanese institutions are these and what does handling them entail? Are you scraping or modifying DOM, or are the institutions? Are you obfuscating DOM, or are the institutions?
In the context of moneytree.jp the institutes in question are most likely banks that are reluctant to offer APIs, so the only option for Software Integrators is Web-Scraping.
In Germany we have figo.io that allows the local startup scene to access german banks. From what i can gather from their API its also done in part by scraping.
Some Banks want to obstruct the scraping and the author claims that none of the tricks React Armor offers have thwarted his company so far.
The extra work needed to do this pretty makes it very unlikely to be implemented much. Additionally the DOM level obfuscating is just bad for performance.
if you're looking to prevent Ad Blockers, this is not your solution.
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 :/
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.
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.
So basically you're ok with randomly getting broken pages if you use content-modifying browser extensions? If yes, no problem. If it's an issue - something's got to give.
Longer answer: I install any such extension with full knowledge of their potential to cause breakage, and consequently my first reaction to a broken page is to issue a reload with the extension disabled.
The web being programmatically accessible and end-user-malleable is a strength, not a weakness.
But many (I'd put my money on "most") users' first reaction isn't to issue a reload with the extension disabled. A lot of users aren't even aware of what extensions they have installed, and their first reaction is to file a bug report to the website.
It would be nice if there was some way to prevent users from reporting bugs if they have extensions modifying the website in certain ways, or at least warn them to try disabling their extensions first. I wouldn't even mind a whitelist for certain well-behaved ad blockers, but certain extensions are well known for being bad (many extensions _inject_ ads, which is a recipe for website breakage).
Yes, but most users don't take responsibility for the extensions they install quite that way.
The problem comes if you install a browser extension (or acquire malware that installs a browser extension for you), forget about it, and then blame the website when the website stops working, often filing bug reports (increasing the support load of the website).
And don't forget the bad-mouthing on social media.
Just look at hacker news. Many posts have someone complaining how the site is broken only to find out they have disabled scripts or have a night mode extension, or disabled webgl but forgot about it, or they programed their router to drop all packets that were going to a url that included "google" anywhere in it (including mysite.com/google-blog-post, true story)
>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.
Perhaps you should move away from the "just throw some js at it" mentality and learn to design things in a more robust fashion, so that they don't depend on having to make assumptions about the dom.
Reality test - can you show me a single website which has rich client-side script, gets html or json from the server, and adds a failure path for every single element/property access which does not succeed? (with failure path that doesn't depend on the rest of that content) Because that's what you seem to be suggesting.
If only users were consistent and fair about what they wanted.
I wouldn't personally run something like this, but I've definitely experienced the frustration of having a user install an extension that changed my website, and then reported a bug in the extension to me.
Even when the extension is bug-free, it still adds a support burden. For instance, there's an extension that adds icons to usernames on my site. Users have asked me how to change their icon, and then gotten mad at me when I say I don't know.
It also adds a maintenance burden: Whenever I deploy various updates, I get complaints that the updates break one extension or another.
Not to mention, there are extensions not intentionally installed by users. For a while, there was some very common malware that rendered my website unusable. It added the text
If you want or need pixel perfect and all kinds of fancy javascript to run your site, maybe you should just make a program instead, even if it's a wrapper around some browser engine.
I actually do offer that too, for precisely that reason, but of course many people prefer the online version. And browser extensions and things like Stylish let people do some pretty neat things. It's just a support nightmare. :(
> How about explaining it better? Get them to show you a screenshot, and then you can point out the fact that it's not coming from code you served.
You presume users understand what the difference is. Not all users are technical enough for that sort of thing.
Someone also points out a related problem: if the user complains on social media instead of directly to me. I don't always have the opportunity to explain at all.
> Perhaps that was a good thing, because it made you aware of its presence quickly.
Unfortunately, being aware of its presence didn't help much. I considered alerting the user that they had malware, but generally the only time a website tells a user they have malware is to scam a user (see: MacKeeper), and I didn't want users to see my site as untrustworthy.
Widespread deployment of this will make a number of people's lives less fun. In response, pro-fun countermeasures will be created to solve their new problem.
Or, to quote a comment on a technology discussion site about this project:
Well, this is now a new problem. My new problem. Are you saying I should now devote time to solving this problem of mine? Oh. It doesn't sound very fun, though. Now what?
But why stop there? Compile Chrome in Emscripten and render to canvas, with flickering to prevent screenshots! No DOM, no problems, right?
Until someone just types the data into Excel and manipulates it themselves. If you don't trust your user with data, don't show it to them in the first place!
Yeah, I genuinely don't understand what they're going for here. Anything that happens client-side can be modified by the client. Because, you know... it's on their side. Front-end validation and stuff is nice for UI/UX, but nothing that comes from the client should ever be trusted just because you put an obfuscated property on an input or something.
At the end of the day, it all has to be valid HTML tags and javascript that runs without crashing. In terms of security, nothing on the front end even registers on the scale. Absolute worst case scenario, it's like solving a Wheel Of Fortune where I have most but not all of the the letters.
I'm pretty uncomfortable with the description of a user on their own machine, running their own browser running plugins they chose and installed as a "third party" that's engaging in "tampering."
The headline lead me to believe this was some kind of DOM integrity technology, which would be cool. I have a vague notion this is bad for both security and performance.
The tool is cool but in practice just detecting that DOM is violated and notifying the user in one way or another (like reducing functionality of the site) should work better. Also it is much harder to defeat especially if detection takes into account the layout.
Update: the detection-only also helps with accessibility as obfuscated DOM makes it impossible to use with screen readers etc.
54 comments
[ 3.7 ms ] story [ 111 ms ] threadIf you have a justifiable business reason for doing this, then your life just got a little easier. I think this would also help against some forms of XSS too - so there's some silver lining for you.
If the entire page is obfuscated it becomes a more difficult problem.
seriously. wtf.
Can't get in the way of that!
But the solution already exists for years: http://www.iab.com/guidelines/safeframe/
any publisher not using this is not worthy their salt!
EDIT: But if you really want to make this a useful lib, bake in a way to disable the `armor` for debugging/development.
Pretty sure this is why we need shadow dom.
I've done a fair amount of web scraping before and each of their tricks can be broken with enough care. Obfuscating html not only breaks many of the good things about the web but also makes things harder to debug.
Does your company have the same goals React Armor has (this seems to be what your double-negative is saying), or is it the party React Armor is trying to protect against, or is it relevant to React Armor in some other way?
What kind of Japanese institutions are these and what does handling them entail? Are you scraping or modifying DOM, or are the institutions? Are you obfuscating DOM, or are the institutions?
Would you rather these Japanese institutions not be handled in some other way?
In Germany we have figo.io that allows the local startup scene to access german banks. From what i can gather from their API its also done in part by scraping.
Some Banks want to obstruct the scraping and the author claims that none of the tricks React Armor offers have thwarted his company so far.
WTF, really?
if you're looking to prevent Ad Blockers, this is not your solution.
https://en.wikipedia.org/wiki/Security_theater
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 :/
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.
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.
I get to choose how this client-side Javascript runs because I get to choose how every kind of software runs on my own computer.
Longer answer: I install any such extension with full knowledge of their potential to cause breakage, and consequently my first reaction to a broken page is to issue a reload with the extension disabled.
The web being programmatically accessible and end-user-malleable is a strength, not a weakness.
It would be nice if there was some way to prevent users from reporting bugs if they have extensions modifying the website in certain ways, or at least warn them to try disabling their extensions first. I wouldn't even mind a whitelist for certain well-behaved ad blockers, but certain extensions are well known for being bad (many extensions _inject_ ads, which is a recipe for website breakage).
The problem comes if you install a browser extension (or acquire malware that installs a browser extension for you), forget about it, and then blame the website when the website stops working, often filing bug reports (increasing the support load of the website).
Just look at hacker news. Many posts have someone complaining how the site is broken only to find out they have disabled scripts or have a night mode extension, or disabled webgl but forgot about it, or they programed their router to drop all packets that were going to a url that included "google" anywhere in it (including mysite.com/google-blog-post, true story)
Perhaps you should move away from the "just throw some js at it" mentality and learn to design things in a more robust fashion, so that they don't depend on having to make assumptions about the dom.
I wouldn't personally run something like this, but I've definitely experienced the frustration of having a user install an extension that changed my website, and then reported a bug in the extension to me.
Even when the extension is bug-free, it still adds a support burden. For instance, there's an extension that adds icons to usernames on my site. Users have asked me how to change their icon, and then gotten mad at me when I say I don't know.
It also adds a maintenance burden: Whenever I deploy various updates, I get complaints that the updates break one extension or another.
Not to mention, there are extensions not intentionally installed by users. For a while, there was some very common malware that rendered my website unusable. It added the text
But it did it badly, so it changed: to Which, of course, rendered my site unusable.How about explaining it better? Get them to show you a screenshot, and then you can point out the fact that it's not coming from code you served.
For a while, there was some very common malware that rendered my website unusable.
Perhaps that was a good thing, because it made you aware of its presence quickly.
You presume users understand what the difference is. Not all users are technical enough for that sort of thing.
Someone also points out a related problem: if the user complains on social media instead of directly to me. I don't always have the opportunity to explain at all.
> Perhaps that was a good thing, because it made you aware of its presence quickly.
Unfortunately, being aware of its presence didn't help much. I considered alerting the user that they had malware, but generally the only time a website tells a user they have malware is to scam a user (see: MacKeeper), and I didn't want users to see my site as untrustworthy.
https://github.com/Zarel/Pokemon-Showdown-Client/commit/95f2...
Make things that solve your problems.
Have fun while doing it.
Continue.
Or, to quote a comment on a technology discussion site about this project:
"And so begins an arms race."
Until someone just types the data into Excel and manipulates it themselves. If you don't trust your user with data, don't show it to them in the first place!
At the end of the day, it all has to be valid HTML tags and javascript that runs without crashing. In terms of security, nothing on the front end even registers on the scale. Absolute worst case scenario, it's like solving a Wheel Of Fortune where I have most but not all of the the letters.
I'm pretty uncomfortable with the description of a user on their own machine, running their own browser running plugins they chose and installed as a "third party" that's engaging in "tampering."
Update: the detection-only also helps with accessibility as obfuscated DOM makes it impossible to use with screen readers etc.
ROFL, soon all the annoying garbage ads will be written in React. Yay!