11 ms·

React Armor: Protect your DOM from third-party tampering

64 points by npad 11y ago

anttiviljami 11y ago
The end of transparent web source code. I hate this. :(
- martindale 11y ago
  Don't be so sure. This will push the client authentication problem further up the stack.
iLoch 11y ago
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.
- nostrademons 11y ago
  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.
na85 11y ago
Hooray, get ready for broken websites with modal overlays, CSS popups, ads, and tracking built-in, and no way to disable them!
- ebola1717 11y ago
  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.
  - na85 11y ago
    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.
- gcb0 11y ago
  broken user scripts and styles. f-up accessibility and screen readers. seriously. wtf.
  - angersock 11y ago
    But think of the ads! Can't get in the way of that!
    - gcb0 11y ago
      not sure if you were joking, but ads messing up with page is a huge problem, and is in no way solved by this. But the solution already exists for years: http://www.iab.com/guidelines/safeframe/ http://www.iab.com/guidelines/safeframe/ any publisher not using this is not worthy their salt!
rajivtiru 11y ago
Performance would probably not suffer at all... EDIT: But if you really want to make this a useful lib, bake in a way to disable the `armor` for debugging/development.
tiglionabbit 11y ago
This is kind of gross. Pretty sure this is why we need shadow dom.
spoiler 11y ago
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.
trengrj 11y ago
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.
- dmak 11y ago
  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.
  - Zarel 11y ago
    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?
    - pandeiro 11y ago
      Oh come on, don't act like it isn't obvious. Do you think he isn't trying to be unclear? Would you rather these Japanese institutions not be handled in some other way?
    - Roritharr 11y ago
      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.
dmitrygr 11y ago
Sounds like a great way to make my browser waster more RAM & CPU on rendering your site (useless span-subtrees?!?!) WTF, really?
- baddox 11y ago
  It's not really a great way to do that. JavaScript loops are a much better way to do that.
tomlongson 11y ago
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.
mrchess 11y ago
Great example of security theater. https://en.wikipedia.org/wiki/Security_theater https://en.wikipedia.org/wiki/Security_theater
viraptor 11y ago
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 :/
- userbinator 11y ago
  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.
  - viraptor 11y ago
    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.
    - somesomesom 11y ago
      Why should I care about what the website owner wants? It's my computer running his shitty Javascript. 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.
blairanderson 11y ago
so many haters here... Make things that solve your problems. Have fun while doing it. Continue.
- chao- 11y ago
  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: "And so begins an arms race."
  - deleted 11y ago
    [deleted]
- Piskvorrr 11y ago
  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?
btown 11y ago
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!
Dr_tldr 11y ago
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."
jvoorhis 11y ago
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.
fpoling 11y ago
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.
christopher_ 11y ago
I thought this was a joke when I saw it at React Conf. Apparently not.
al2o3cr 11y ago
"Such third-party scripts include browser extensions (adblockers...)" ROFL, soon all the annoying garbage ads will be written in React. Yay!

64 points by npad 11y ago

anttiviljami 11y ago

The end of transparent web source code. I hate this. :(

martindale 11y ago
Don't be so sure. This will push the client authentication problem further up the stack.

iLoch 11y ago

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.

nostrademons 11y ago
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.

na85 11y ago

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

ebola1717 11y ago
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.
- na85 11y ago
  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.
gcb0 11y ago
broken user scripts and styles. f-up accessibility and screen readers. seriously. wtf.
- angersock 11y ago
  But think of the ads! Can't get in the way of that!
  - gcb0 11y ago
    not sure if you were joking, but ads messing up with page is a huge problem, and is in no way solved by this. But the solution already exists for years: http://www.iab.com/guidelines/safeframe/ http://www.iab.com/guidelines/safeframe/ any publisher not using this is not worthy their salt!

rajivtiru 11y ago

Performance would probably not suffer at all... EDIT: But if you really want to make this a useful lib, bake in a way to disable the `armor` for debugging/development.

tiglionabbit 11y ago

This is kind of gross. Pretty sure this is why we need shadow dom.

spoiler 11y ago

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.

trengrj 11y ago

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.

dmak 11y ago
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.
- Zarel 11y ago
  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?
  - pandeiro 11y ago
    Oh come on, don't act like it isn't obvious. Do you think he isn't trying to be unclear? Would you rather these Japanese institutions not be handled in some other way?
  - Roritharr 11y ago
    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.

dmitrygr 11y ago

Sounds like a great way to make my browser waster more RAM & CPU on rendering your site (useless span-subtrees?!?!) WTF, really?

baddox 11y ago
It's not really a great way to do that. JavaScript loops are a much better way to do that.

tomlongson 11y ago

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.

mrchess 11y ago

Great example of security theater. https://en.wikipedia.org/wiki/Security_theater https://en.wikipedia.org/wiki/Security_theater

viraptor 11y ago

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 :/

userbinator 11y ago
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.
- viraptor 11y ago
  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.
  - somesomesom 11y ago
    Why should I care about what the website owner wants? It's my computer running his shitty Javascript. 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.

blairanderson 11y ago

so many haters here... Make things that solve your problems. Have fun while doing it. Continue.

chao- 11y ago
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: "And so begins an arms race."
- deleted 11y ago
  [deleted]
Piskvorrr 11y ago
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?

btown 11y ago

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!

Dr_tldr 11y ago

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."

jvoorhis 11y ago

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.

fpoling 11y ago

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.

christopher_ 11y ago

I thought this was a joke when I saw it at React Conf. Apparently not.

al2o3cr 11y ago

"Such third-party scripts include browser extensions (adblockers...)" ROFL, soon all the annoying garbage ads will be written in React. Yay!