React Armor: Protect your DOM from third-party tampering
github.com
github.com
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
<script src="http://example.com/malware.js"></script>
But it did it badly, so it changed: <script src="/legitimatescript.js"></script>
to <script src="/legitimates<script src="http://example.com/malware.js"></script>cript.js"></script>
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...
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?
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.
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!
WTF, really?
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."
Pretty sure this is why we need shadow dom.
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!
if you're looking to prevent Ad Blockers, this is not your solution.
EDIT: But if you really want to make this a useful lib, bake in a way to disable the `armor` for debugging/development.
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!
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.
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."