I hit F12 in Chromium, dev tools open with the tree, knowing that I'm viewing the DOM and not the source I hit the Resources tab, and there is the source.
Not a problem at all.
In fact, I had to remember to go back to right clicking and View Source to try and figure out why this was so highly ranked and lots of the comments confused me.
Now I see why... but just like using JavaScript to try and detect right click, using replace state to try and obscure the source isn't likely to be effective in any reasonable way. I guess that's not the point, that this is more fun than anything someone will do, except... I bet someone does it on their live site.
I doubt it, as this method breaks forward/back functionality, thus probably breaking most sites.
Having said that, for all links, you could do a further re-write using the history API, before allowing the redirect to take place. I guess that would actually make it usable even if, as you say, it's futile in the end.
Many sites (hi, Twitter; #! you, too!) happily break the back button. It is a standard technique to "boost" engagement and "reduce" bounce rate. Seems spiritually inline line with this view-source gimmick.
There is a problem, of course. Going to the new url fails to render the site, so view source won't work but neither will bookmarks. And you DON'T want to prevent bookmarking. But good to know this works.
On Twitter if I'm viewing an individual tweet page, and then click onto the authors profile page, and then click "back" in my browser, I will not be redirected to a different page altogether like in the OP's demo.
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.
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.)
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.
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.
In Chrome at least, it also breaks going back to the cached page after first view using back/forward navigation. (Try clicking the link from HN, go "back", then go "forward" again.) This might be obvious to people who know anything about browser caching, but I thought it was kinda interesting.
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.
I loaded the page, went to Firebug script panel, set a breakpoint on the line of javascript, hit F5, when the breakpoint got hit, I just hit escape to prevent it from running. Then, Ctrl-U as usual.
Chrome is broken on my machine (proxy issues) so I didn't test there, but I assume the same technique would work.
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.
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.
Please post the URL of your site, so we can all enjoy the functionality and not see any leaked IDs. And some AWS functionality would be great, I would love to use EC2 cluster computes on the "free" teir...
$ 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>
Not a problem at all.
In fact, I had to remember to go back to right clicking and View Source to try and figure out why this was so highly ranked and lots of the comments confused me.
Now I see why... but just like using JavaScript to try and detect right click, using replace state to try and obscure the source isn't likely to be effective in any reasonable way. I guess that's not the point, that this is more fun than anything someone will do, except... I bet someone does it on their live site.