jQuery Lock Plugin – prevent some users from changing content in your page | Hacker News Reader

jQuery Lock Plugin – prevent some users from changing content in your page

cnova.github.io

29 pointskauegimenes48 comments

Welcome to the rebirth of the "right-click blocking" scripts. Please, take a trip with me down memory lane, to the glorious days of DHTML in 1998, when there were serious attempts to use JavaScript to "prevent people from stealing your images and code!" http://www.java-scripts.net/javascripts/No-Right-Click.phtml

What is old is new, what is new is old.

My first thoughts when reading the title. Jeez, those were the days.

Yeah, just yesterday I ran into an image that I couldn't right click and save and so I just grabbed the src href out of the source.

The most interesting methods I've seen to prevent image downloading is to slick up the image into multiple parts and put them together using HTML.

That means, you have 10+ parts to each image. If you want to download it, you'll have to grab each part individually and put them together in an image program.

That, or you can just take a screen shot but you'll lose out on some resolution.

You can remove the DOMSubtreeModified event listener first, then you are free to modify "locked" content as desired. I hope to not see a day where the Web Inspector lacks proper facilities to inspect and modify a page.

You can also block the script. Really - most people who'd know to modify the content via the DOM inspector tools can probably figure out trivial ways around the script.

http://i.imgur.com/CHkLlR4.png

I recall when early developers would make it so you couldn't right click and view the source. You'd get some silly alert() dialog saying hey your not allowed. You even had users who would attempt to "obscure" the html by converting it to a encoded string that anyone could easily decode because it had to be for your average browsing user to actually see the page.

If this trend were to come back I would hope to see it quickly fade away because it'll just become a game of cat and mouse in which ultimately if you want your average user to see the content you have to give them the keys. Hopefully this type of locking becomes a thing of the past like it has before.

Unfortunately, since the W3C caved on EME and DRMs apis for videos (i.e. plugins), there is a possibility of seeing that scheme being extended to images or text content. They caved once, there is absolutely no guarantee they wont cave again in the future and put the interests of a few companies before the idea of a free web.

That is worrisome but as always it's a standard thus not all browsers will implement on top of most browsers now have some way of configuring deeper settings like this to be disabled.

In the end the data goes to the user so a way would be found with or without Chrome or any of the other big wigs. What they should do is focus on how to brand it better so users know where it comes from - this would create a way to spread free idea's while giving credit where due and hopefully pushing the idea of the free web further.

Visited the page and ran this in the console:

    $("code.locked").after($("<code class=\"locked\">I circumvent you!</code>")).remove()

Clearly this doesn't prevent scripts from changing it, nor does it prevent users from deleting the locked elements and replacing it with something else.

What's the point of this cat and mouse game?

I'd agree that this provide a false sense of security to the developer. Here's another example of how to modify the text:

    $('h1.locked').clone().replaceAll('h1.locked').text('sucka')

It's cool, but I guess I don't see the point because I'm not sure how big the intersection is between users that can use Chrome developer tools, and those who can't disable this [0].

[0]: http://i.imgur.com/jvExNWT.png

Reminds me of sites that disable text selection or right clicking. Annoying enough to satisfy the client, but no actual copy protection.

Yah... it took me all of 30 seconds to get past. Those doing this without understanding what they're doing are likely following an online how-to, and this wouldn't be that hard to explain in one.

This sort of brings me back to the days where you would obfuscate your javascript or entire page by hexing it (or even AES in one of the scripts I've seen!) and writing a javascript interpreter. One of the more clever ones I've seen was just inserting a tonne of newlines so that the actual page contents was way below the view-source window fold. I felt mighty stupid when I fell for that one.

EDIT: tone =/= tonne

Anyone who knows better won't use this, as they know it offers no real protection. Anyone who thinks that can protect their site using this probably won't understand why it won't work, creating a false sense of security.

Most of the comments here are bashing this for ease of defeat and not having a useful reason for it's existence.

While I agree that it's easy to defeat, it could be interesting in test cases to make sure there aren't any DOM side effects to an operation. You could also use it to ensure that there are proper side effects. Probably not the best way to do it, but still a cool idea in my opinion.

For those wondering, you can get around this globally by listening during the capture phase and stopping propagation.

    document.addEventListener('DOMSubtreeModified', function( e ) {
      e.stopPropagation();
    }, true );

This also works for stopping a NYT article from locking you out of the article when you over the limit.

So we can safely assume anything these people build doesn't validate their inputs server side?

That would be a good Google dork for finding soft targets. Combine a search for the jQuery Lock plugin and PHP extensions and fire SQL injections at all forms on it.

Or don't bother, since a lot of sites that actually buy into this sort of thing don't bother doing any server side validation. Want to be somewhat alarmed? Look up those old 'Javascript HTML encryption' scripts, and Google the sites that use them. Some of them didn't even bother to do anything more than a Javascript prompt for 'security'.

alert("stop hacking us please");

So it's like those old scripts to stop right clicking/content selecting/other stuff then?

The ones that were (and still are) completely useless because the scripts are client side and trivially easy to 'bypass'? Yeah, I think I'll pass.

Funny enough, uBlock Origin doesn't seem to like this very much, since I just waltzed in and edited the 'protected' elements without so much as an alert:

https://dl.dropboxusercontent.com/u/67216205/jqueryunlocked....

What's next, a jQuery marquee plugin? Or maybe jQuery blinking text...

It might be more useful to silently report modifications to sensitive elements.

I could only really see this being useful for malicious browser plugins that aren't targeted at the specific site.

The `.lock` function takes two optional parameters: `alertMessage` and `customHandler`. `customHandler` is a callback invoked when a content change is attempted. `alertMessage` is a convenience function that calls `alert`; it could be trivially implemented by the client programmer using `customHandler`. The author is ostensibly suggesting that `alert` is a common use case. I think he's trolling us.

EDIT: Just saw that the author is a company. There goes my theory.

Does this not work on Firefox? I expected to not be able to change anything about the two "locked" elements, but I seem to be able to change the text, class, or even delete them with no issue.

Edit: Interestingly if I click "Edit as HTML" I can change them to my heart's content, but if I try just double clicking the text it won't let me make changes.

But why?

Banks? Any order system? Screenshots are very often used in customer problem resolution.

If you're looking to fake a screenshot you can certainly defeat this plugin to do so.

or just use photoshop...

Why use photoshop? The browser will make a pixel-perfect forgery with almost zero effort.

It was a hypothetical "even if this wasn't trivial to bypass..."

If a site trusts a screenshot to resolve a dispute then they've got bigger issues.

Sir the website clearly states I have 20 million in my account, attached is a screenshot with same.

I love Flickr's HTML: [span class="facade-of-protection-neue" style="width:618px;height:400px;"]

...this seems similar.

I would bet money this was for an extremely stubborn and ill-informed client.

"The idea of the plugin is to prevent users without technical background from changing the page HTML. For example. many eCommerce customers change the price of the product using dev tools and send a screenshoot."

Yeah, good luck with that.

well, didn't lock anything for me... uMatrix didn't allow it to run the JS

I feel like this is a band aid for core design flaws.

The idea of the plugin is to prevent users with no technical background from changing the page HTML. For example. many eCommerce customers change the price of the product using dev tools and send a screenshoot trying to get free discounts.

If they have no technical background, they wouldn't be using dev tools.

I believe that is not true.

Just blacklist the site from running javascript. Problem solved.

bug : after locking 'body' - i tried appending an element to a p tag and hit an infinite loop/maximum call stack exceeded error

Sure, it won't actually stop people from changing content. But I can see myself leaving some fun easter eggs with this.

I really don't see any other use. The page doesn't even mention an intended use; most of the comments make good points but I'm not sure if they are exactly germane or not. What was the author really trying to accomplish?

I think prophesi is suggesting it would be fun to use for something non-professional such as a single-player browser game. You could, for example, make it possible to hack the game by hacking the DOM, or unlock godmode by changing your player nametag to say "God".

some users = the ones that cannot find F12

Reply on news.ycombinator.com