No, NoScript acts more like a whitelist of executables permitted to run, with all others banned. Browser sandboxes themselves are the new antivirus.
Or alternatively, NoScript is the new lynx.
The problem shown in this example needs fixing in the browser, not by gutting the browser. This example just shows that "view source" should probably make it easier to get at the DOM-generated source. ("View Selection Source" or anything that shows the current DOM will work.)
A clever use of history.replaceState and some special characters (to make it less obvious that the state's been altered) - "view source" in Chrome operates on the currently active URL, which after the replaceState has executed is the "not that easily" page.
You can also reproduce the behavior by navigating back, then forwards again - you'll see the "not that easily" page that way, as well (as the "try and view the source" page has been replaced in your history list).
Just to add to this, the "special characters" are "%E2%80%AE" which is the escaped form of the UTF-8 "Right-To-Left Override" control character (which effectively reverses the display of text).
Even without the RTL directive, they might have used something like sourcе.html — which contains a non-ASCII glyph. So while RTL is problematic, I'm not prepared to call it a failure in that generally problematic space of unifying human communication.
That shows the current DOM state, not the source that created it. There's a distinction, especially if you use a lot of JavaScript to fiddle with the DOM.
Because coffeescript runs in any browser and is easier to install under more platforms and security configurations than curl? The browser is the VM of the Internet. It is more standard that POSIX now, for non-system level user space functions, at least.
That's actually not viewing the page source though. That's viewing the current DOM state. If the author was more clever he could have left you a little note to that effect.
I used to use this simple trick to hide my source where I would tell Apache to treat JavaScript files as PHP applications and then I'd use sessions to show the file. If the session was missing I would display bogus text.
$ curl http://www.kurlak.com/john/%E2%80%AElmth.ecruos
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>406 Not Acceptable</title>
</head><body>
<h1>Not Acceptable</h1>
An appropriate representation of the requested resource /john/lmth.ecruos could not be found on this server.</p>
Additionally, a 404 Not Found
error was encountered while trying to use an ErrorDocument to handle the request.</p>
</body></html>
That's not view source. You are looking at the current state of the DOM. Usually, it will be similar, but what you're looking for is the source that your browser received from the server. Inspect element won't give you that.
85 comments
[ 3.2 ms ] story [ 121 ms ] threadOr alternatively, NoScript is the new lynx.
The problem shown in this example needs fixing in the browser, not by gutting the browser. This example just shows that "view source" should probably make it easier to get at the DOM-generated source. ("View Selection Source" or anything that shows the current DOM will work.)
http://citeomatic.com/_asdf.html
(This one only works in Firefox and Opera, not Chrome, sadly)
With httpfox I got
html:after { padding-left: 5px; content: 'Can you view my source from Firefox or Opera?'; }
Edit: It's also possible to view the source with Firefox JSview, Web Developer addons and curl.
You can also reproduce the behavior by navigating back, then forwards again - you'll see the "not that easily" page that way, as well (as the "try and view the source" page has been replaced in your history list).
If you try copying the URL to plain-text, you'll see: http://www.kurlak.com/john/%E2%80%AElmth.ecruos
most people i know view source this way
<html> <head> <title>Source</title> </head> <body> Can you view my source from Chrome or Firefox? </body> </html>
An appropriate representation of the requested resource /john/lmth.ecruos could not be found on this server.</p>
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.</p> </body></html>
That said, pretty neat trick.