I can't help but feel saddened that we learned how to code using View Source (indeed, it's a big factor in the web's success) and now we're trying to prevent others doing the same.
Also, this seems like a surprisingly naive generalisation to me: "... a first measurement for preventing evil business guys from stealing your code – developers who can figure the code out are (mostly) kind enough not to steal it."
ADD: Jeez, don’t get me wrong, I’m not really trying to hide my code from anyone, I actually love writing open source software, it was just a fun idea to do this experiment :)
"Developer tools" is the new View Source. Browsers should really just redirect View Source to the live DOM view of their developer tools, that's what most people want from it.
Developer Tools would've scared the crap out've me when I was 11 years old trying to figure out how web pages worked.
The classic view source showing just text is a very powerful message: websites are just text[1]. As a young wannabe, it was very empowering for me to realize that all I had to do to accomplish my dreams was to open up Notepad and type some special text.
[1]: And images and videos and so on. That's not the point.
Maybe, but there's still a lot of value in being able to see pre-rendered code so I wouldn't go as far as a redirect. Somehow combining the two could be a good option.
I like having them both personally. I'll normally use the page inspector for most things, but I like to see the raw HTML I'm producing from a web app too, along with the CSS and JS tags, etc.
They do very different things. View source will show the document as delivered to the browser; developer tools show the page as rendered. You really need both.
Bonus points for not just creating an image, but hiding the code steganographically in an existing image (ie only using the LSB of each pixel to hide code)!
This might be quite effective in preventing people trying to reveal your code as part of their job. You could use some sort of obscene image to hide your code in.
But at some point you need to have the code on client side to get the code in string format, doesn't that give away how you've stored the code in the image?
If you are willing to use HTML5 'magic', could you not stream the JS down via a web socket and then execute it? That would prevent most of the conventional HTTP intercepts from having access to the code.
If someone is clever enough to hide their JavaScript like this, then they hopefully know that it isn't foolproof. In other words, don't rely on obfuscating your code for anything related to security (as an example).
Actually, this slows down all levels of code stealers. No longer can we simply copy and paste (or download if it is its of *.js file) into our editor of choice. Now, we have to open the dev console, call getCode(), and deal with any formatting issues that might arise (such as \\n -> \n).
Modern servers and browsers support the DEFLATE algorithm for compressing over HTTP, which is the same algorithm as PNG. The only difference is that PNG preprocesses with a predictor to exploit row-to-row correlations in an image. Since the assumptions of that predictor are less likely to be sound with JavaScript code than with practical image data, and since lossless compression is a zero-sum game, PNG will perform worse than plain old DEFLATE on average for JS code.
Maybe, but obviously we would need loss-less compression. And the current web standards like gzip are optimized and perfectly suited for "text-like" loss-less compression, so it seems a little pointless to apply any image-optimized loss-less compression.
Also, this seems like a surprisingly naive generalisation to me: "... a first measurement for preventing evil business guys from stealing your code – developers who can figure the code out are (mostly) kind enough not to steal it."