Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I want to send a link to a client with some work I am doing for them but they are rather informed about IT and that would lead me to think that they know how to copy and paste some HTML and CSS. How would I go about stopping them from seeing the HTML, CSS and JS of the page I want to send them?
Unfortunately this is not effectively done. While it is true that HTML and CSS can be minified there are a large number of free utilities out there that are designed to reverse the minification, or "beautify", whatever you have minified.
There are a range of other methods which are used on occasion but don't really do anything to protect the source from anyone except those who wouldn't care about the source anyway.
Source Code Padding
This is one of the oldest tricks in the book and involves adding a ton of white space before the start of the source so that when the user opens the view source window it appears blank, however almost everyone these days will notice the scroll bars and scroll down the page until they hit the source. This also has the extra negative effect of degrading performance for your site as it substantially increases the amount of data being sent to the client.
No Right Click Scripts
These sorts of scripts prevent the user from right clicking on the page and opening up the page context menu however they are notoriously hard to get working across browsers, annoy users who don't like the native functionality and usability of their browser being altered without permission, and don't make any difference as the source code window can be opened from the top menu.
Javascript "Encryption"
This is a very popular method to suposedly "protect" the source code of the page and involves taking the code and using a custom made function to encrypt the script before pasting it into the html file and then embedding javascript in that file to decrypt the markup at run time. This only works if the end user has javascript enabled and is not effective in protecting the page from other designers and coders as you need to embed decryption javascript in your page which the user can use to reverse your markup and see the plain text markup.
HTML Protection Software
There is software out there which is marketed as protecting HTML and CSS however these protection software packages generally use one of the above methods, and charge you for the privilege of having a false belief your code is actually safe.
Unfortunately the way the internet is designed to work with HTML and CSS this is not possible and won't be without such a drastic shift in the web landscape and the way websites are designed that I personally don't see it ever occuring.
Information sourced from http://www.htmlgoodies.com/beyond/article.php/3875651/Web-Developer-Class-How-to-Hide-your-Source-Code.htm
If your concern is that they'll steal your work, then maybe you shouldn't be working with them.
Also, if you have a good contract in place that specifies who owns the work at which stage of the process, this won't be an issue. In other words, if it's clear that you own the work until it's paid in full, you could sue them if they steal it.
Although it won't stop people stealing your code, you can make it harder to do so using minification - this will remove whitespace and translate variables to harder-to-read names, amongst other things. This will also reduce the footprint of your code, icnreasing the page load speed.
You can't do anything except obfuscate and minify it. There are several utilities to do this if you google it.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 months ago.
Improve this question
The company I work for has a requirement to protect some area where articles are rendered, I've implemented some procedures to protect web-scraping but the problem remains for manual scraping.
The anti web scraping bot protection mechanism seems to be working good so far, but I see clients trying the manual scraping.
What I have tried to protect the article contents:
Set a copy eventhandler on article's wrapper element to prevent copy.
-> Clients can make use of userscripts (greasemonkey, etc) to efficiently bypass this by removing the eventhandler or simply making scripts to copy the contents and save to a file
Developer console protection -> useless
Redirect if F12 pressed -> useless
Seems like protecting HTML is undoable (unless someone tells me otherwise) so I'd like to know other ways to display text and render it totally UNABLE to copy.
Things I've thought:
JS detection mechanisms to diagnose if the user has any sort of userscript running, in other words, if there's no malicious JS code being injected and executed to extract the text
Transforming the article's HTML into a PDF and displaying it inline with some sort of anti text-select/copy (if this even exists).
Transforming the article's HTML into chunks of base64 images which will render the text completely unable to select and copy
Are there any good ways to prevent my content from being stolen while not interfering much with user experience? Unfortunately flash applets are not supported anymore, it used to work charms that era.
EDIT: Cmon folks, I just need ideas for at least make end user's efforts a bit harder, i.e. you can't select text if they're displayed as images, you can only select image's themselves.
Thanks!
As soon as you ship HTML out of your machine, whoever gets it can mangle it at leisure. You can make it harder, but not impossible.
Rethink your approach. "Give information out" and "forbid it's use" somewhat clashes...
No, You Can't
Once the browser loaded your page, You can't protect the content from copying / downloading.
It can be text, image or videos, You can protect it from unauthorised access. But you can't protect from get scraped by the authorized person.
But you can make it harder using the steps that you mentioned in your question and restricting the copyright laws.
This issue still exists in many sites, Especially In E-learning platforms, such as udemy and etc... In those sites, The premium courses are still getting copied / leaked by the person who bought it.
From Udemy FAQ
For a motivated Pirate, however, any content that appears on a computer screen is vulnerable to theft. This is unavoidable and a problem across the industry. Giants like Netflix, Youtube, Amazon, etc. all have the same issue, and as an industry, we continue to work on new technology solutions to limit Piracy.
Because pirating techniques currently outpace protection, we hired a company who is specifically dedicated to enforcing the DMCA laws on your behalf and target violating individuals, hosting sites, and DNS servers in an attempt to get any unauthorized content removed.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Situation:
I have a website that is served dynamically. In order to optimize the website's speed, all the CSS and javascript is put directly into the HTML document.
Pros:
It cuts back on web requests
Less files need to be downloaded
Faster webpage download
Cons:
Possible caching issue
So apart from the caching part, is there a reason not to do this?
If you have your CSS in a separate stylesheet file your site will be more maintainable, even if your CSS is inserted into the outgoing document by an automated server-side process.
By having your CSS in a separate file you make each page downloaded smaller.
However the benefits of "less files need to be downloaded" and "faster webpage download" are false. With a separate CSS file (with an aggressive Expires:header) your webpages will load faster compared to in-lining the CSS because the browser won't re-request the stylesheet on every subsequent page request (though the first visit would incur this cost, it really is minor).
CSS was designed for separating content from presentation. The W3Schools maintain that it is a good practice to use html for your structure, and css for styling.
This will make it easier for you. If you are working with large files, it's better to have a separate stylesheet for your css, or better yet, multiple stylesheets. It can be pretty unreadable to have inline styles or style tags in your html document.
Set up both examples on a sub domain, and then test both at tools.pingdom.com
You'll see the differences between the two in how fast they load.
It's just tidier to keep files organised.
Front end users usually won't notice performance increases like that, they will notice when your code has a bug and you are taking forever to fix it because the code is unreadable and hard to debug.
Nice readable code > optimized unreadable code
Quite many factors.
If your application is SPA and uses relatively compact CSS and self-contained scripts then it is better to serve it as single file indeed.
In all other cases you'd better use tools to compare various combinations.
It might be a better question to ask.. why -wouldn't- you? Unless you have a single page, you probably want to use the same styles on every page. So, you don't want to have to write those over and over and over.
You're wasting time adding the CSS to the page (unless you are dynamically generating the CSS as well). I'd think in most cases, you can just put in the link to the CSS in your generated page, and it'll end up in almost all cases (except for the initial page load for a new user) be faster on both the server and client end.
Unless you're generating the CSS at the same time, as well.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
There are a lot of features and abilities of javascript that I am unaware of. I have developed a custom closed source CMS and I was thinking about adding a feature to allow for custom javascript that gets included on each page of their site (but not the backend system itself). I was curious of the risk involved with doing this? The CMS is built using PHP and there is javascript within the backend system of this CMS, but thats pretty much it.
If I allow custom javascript, can this be manipulated to retrieve all the php code, or to cause issues on the server itself?
I own the servers, so I can make any adjustments necessarily for safeguarding the server.
Again, this is purely for information and I appreciate any advice people can give me.
The javascript will be stored in a file and included using php on the page itself. I do have code that blocks anything inside to prevent the use of PHP within the code itself.
Can they steal my closed-source PHP code with JavaScript?
To answer your first question, no, your closed-source PHP code cannot be stolen by a user of your CMS software simply by uploading a JavaScript snippet.
This is because JavaScript runs on the client-side (the web browser).
If JavaScript is able to access your PHP code from the client-side, then they'd be able to access it without JavaScript. That would mean that you've configured something wrong on the web server side, like setting permissions on your files so that anyone can view them.
Is allowing JavaScript to be uploaded by a CMS user a good idea?
You'll get some folks who will scream ABSOLUTELY NOT UNDER ANY CIRCUMSTANCE. These are the same people who say things like:
Using eval() is always evil. It's not always evil, but it's almost always unnecessary.
Using global or $_GLOBALS in PHP is evil. Again, it's only evil if you don't know what you are doing. And again, it's almost always unnecessary.
You should read that as a WARNING. Don't treat this issue lightly, if you are careful, you can do it, but if you are not, it can really bite you in the a**. That's reason enough for most people to stay away from it.
Before you decide for sure if you should or shouldn't allow users of your CMS solution to upload JavaScript snippets, you should ask yourself the following question:
Who will be allowed to upload JavaScript snippets?
If the only people who have access to this feature of uploading JavaScript modules are trusted system administrators, then you should consider it safe. I put that in italics because it's not really safe, but it does, at that point, fall on these trusted users to ensure that they don't upload something malicious.
Maybe you get Mary Neophyte, webmaster(amateur) extraordinaire who decides she wants a cool scriptlet on her CMS front page that displays the current weather in Anchorage, Alaska. She goes to Google, types in "JavaScript weather script", and arrives at Weather Channel. She decides their implementation is just too hard to install. She keeps looking. She arrives at Boris' Weather Script at http:/motherrussia.ru/ilovehackingidiots/weatherscript.html.
This isn't your fault when her CMS starts compromising her end users. She was the trusted administrator who uploaded a malicious script purposefully (though ignorantly). You shouldn't be held responsible for this type of behavior.
Long story short, you should be able to trust the trusted users of your CMS to be responsible enough to know what they are uploading. If they shoot themselves in the foot, that's not on you.
Allowing non-trusted users to upload JavaScript
This absolutely, positively, without a doubt is never something that you should do. It is impossible for you to screen every possible obfuscation that someone could upload.
I'm not even going to get into this further. Don't do it. Period.
Regarding HTML/CSS
Don't assume that malicious code can't make it onto your website via HTML/CSS. While HTML is much easier to sanitize than JavaScript, it can still be exploited to deliver undesired JavaScript to a page.
If you are only allowing trusted users to upload HTML/CSS, then don't worry too much about it. I stress again, It is Mary Neophyte's fault if she uploads Boris' Weather Script to her site. However, don't let Boris himself come to your website and start uploading anything that will get displayed on a web page to anyone but ol' Boris himself.
TL;DR
I'll summarize everything into two rules:
Don't allow untrusted users to upload anything that will be displayed to anyone other than themselves.
Don't let anyone upload anything at all that gets executed server-side.
Allowing custom JavaScript would probably be a very bad idea. That would make your site vulnerable to cross-site scripting attacks and allow it to be a vector for cross-site request forgery attacks against other sites.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
The benefits of well-factored and modular code, in my understanding are re-usability and organization. Code written in a big chunk all in one file is difficult to read, and re-using small portions of the code requires careful copy-pasting, rather than include statements.
In particular, with regards to Javascript, I came across an example recently that got me thinking about this. A comment was made on SO to the effect that, if you are not including your javascripts conditionally on a page-by-page basis, this "represents a failure to modularize JS code properly". However, from a code re-use and organization point of view, there is no reason to consider what happens at page load time. The code will be just as readable if it is written in a bunch of separate files and then mashed together and minified before being served. The rails asset pipeline, for example, does just this.
When I first encountered the asset pipeline, my mind reeled and I started wondering "how do I make javascripts load only when needed?" I read a few SO questions and an article on the matter, and began to think that maybe I shouldn't worry about what happens to my code after it "compiles".
Is the purpose of writing modular code purely a human-level activity, should we stop worrying about modularity after the code starts running? In the case of Javascript, should we be concerned that our scripts are being mashed together before being included?
I think the one thing that you are not really talking about in this with regards to performance is actual HTML browser download behavior. I believe you have to walk a fine line between only displaying the javascript needed on a page by page basis and leveraging browser caching and download behavior.
For example, say you have 20 different javascript snippets that are going to be used on every page. In this case it is a no-brainer to compile/minify them into a single file, as the fewer files your browser needs to download, the better. This single file would also be able to be cached, that is assuming it is a static file or appearing to be static (via headers sent) if it is dynamically compiled.
Now say of those 20 snippets, 15 are used on every page and the others are used intermittently. Of course you put all 15 of the always used snippets into a single file. But what about the others? In my opinion you need to consider the size and frequency of use of the files. If they are small and used relatively frequently, I might consider putting them into the main file, with the thought that the extra size in the main file is outweighed by the need to have additional request to download the content later. If the code is large, I would tend to only use it where necessary. Of course once it is used, it should remain in cache.
This approach might best be suited for a web application where users are expect to typically have multiple page loads per session. Of course if you are designing an advertising landing pages or seomthing where the user only may see that single page, you might lean on keeping the initial javasciprt download as small as possible and only loading new javascript in as necessary based on user interaction.
Every aspect of this question boils down to "it depends".
Are you writing an enterprise-level application, which results in 80,000 lines of code, when you stuff it all together?
If so, then yes, compilation time is going to be huge, and if you stuff that in the <head> of your document, people are going to feel the wait time.
Even if it's already cached, compile time alone will be palpable.
Are you writing dozens of widgets which might never be seen by an end-user?
Especially on mobile?
If so, then you might want to save them the download/compile time, and instead load your core functionality, and then load extra functionality on-demand, as more studies are showing that the non-technical end-user expects their mobile-internet experience to be similar to their desktop experience, not only in terms of content, but in general wait-times.
Fewer and fewer people are willing to accept 5s-8s for a mobile experience (or a desktop experience on mobile) to get to the point of interactivity, just based on the "well, it's mobile, so it'll take longer" train of thought.
So again, if you've got an 80,000 line application, or a 300kB JS file, or are doing a whole lot of XML parsing, et cetera, prior to load, without offering a separate mobile experience, your stats on mobile are bound to hurt -- especially if you're a media site or a commercial/retail site.
So the correct answer to your question is to say that there is no correct answer to your question, excepting that there are good ideas and bad ideas, based on the target-devices, the intent of the site/application, the demographic, the code-base, the anticipation that users will frequent the site (and thus benefit from cached assets), the frequency of updates to the codebase (having one updated module, with 20 cached modules, versus a fully-invalid 21-module chunk, due to one updated line, with a client-base of 250,000 customers, is a consideration for several reasons)...
...and more...
Figure out what you're doing.
Figure out what you need to do to make that happen.
Figure out how to do it, while providing your customers a good experience.
Know how to combine files.
Know how to load on demand.
Know how to build a light bootstrap, which can intelligently load modules (and/or learn require/AMD).
Use these as tools to offer your users the best experience possible, given what you're trying to accomplish.
This question already has answers here:
Do web sites really need to cater for browsers that don't have Javascript enabled? [closed]
(20 answers)
Closed 8 years ago.
For the longest time, one of the basic technical requirements for website projects I've worked on was that the site should run with javascript disabled.
It actually caused a great design by-product: concerns were nicely separated between basic functionality and user-experience improvements. Beyond that, I don't know of any reason to do so anymore.
Assuming that I'm targeting the widest user base possible, are there any reasons not to make javascript required?
If a significant fraction of your user base (real or expected) — for whatever reason — browses with JS turned off, then of course your site should work well with JS disabled.
I'd say it depends upon your target audience and what portion of them you think might not have javascript or have it enabled.
And, you have to balance that with how useful/competitive your site could be without javascript. If your site wouldn't be all that useful without dynamic capabilities or it would be ridiculously time consuming to make a whole new implementation of your site that didn't use javascript, then it may not make sense for you to do so, even if you were potentially losing 10% of your viewers. It might make more sense to put all that development time into things that increase the value of your site for people that do have javascript.
So, it really depends upon tradeoffs that are particular to your specific site.
The one exception to all of this is that you typically need to make sure you can get good search relevance and most search bots that collect data for search indexing do not run javascript in any way so the data you want search indexed must be available without javascript.
One good reason is that it provides for fallback. If feature testing shows a particular feature can't be implemented, then you just don't implement it knowing that the site will still work.
Of course scripting allows for more features in the UI, but providing basic functionality without any scripting is always a solid base to start from.
For example, a web site recently had it's comments section disabled because some clever designer thought it was a good idea to disable the submit button by default and only enable it when the user starts typing a comment. An upgrade to the library they were using cased the script to fail, so the button was left disabled and users couldn't submit comments.
That error would likely not happen if the page was designed to work without scripting by default and extra features added later.