Saturday, March 16, 2013
Like a Thief in the Wire
Blog Entry #282
In today's post we will discuss the How do I block my document source? script (hereafter "block-source script") offered by Section 6 of the JavaScript subsector of Lissa Explains It All. Lissa credits the block-source script's authorship to Urs Dudli and Peter Gehrig; I suspect that Peter alone crafted the script given that
(a) Peter says
Urs Dudli is a great artist and I am a great writerat his "Kostenlose DHTML und JavaScript Text Animationen" page and
(b) the script doesn't make use of any images,
although Urs or Peter is welcome to contact me and correct me if I'm wrong about this.
Right-clicking on a Web page pops up a context menu that features a View Source (or equivalent) command
via which the user can access the page's source: the block-source script aims to thwart this process by canceling the right-click. The script also displays a tabular form that solicits the user's name, country, and email address
and pops up an alert( ) box bearing a "Please order my HTML-source by email!" message. As Urs, Peter, and Lissa envision it, the user fills in the requested form data and clicks the button, which submits the data to the page author's email address, and then the author replies with a selling price for the page source. (In the script's credits, Urs and Peter give the script a
Turn source-code-thieves into source-code-buyerstitle.) Quaint, huh? Good luck with that one, guys.
The How do I block my document source? subsection includes a demo link that when clicked is supposed to call a document1( ) function, which is nowhere to be found. An Internet Archive search for the Section 6 javascript6.shtml page returns:
Sorry. This URL has been excluded from the Wayback Machine.So we don't have a current demo to work with, and I can't tell you how well the original demo worked back in the day.
The JavaScript
The block-source script's 10 January 2000 release date indicates that it was written when IE 5.x and Netscape 4.x were the current versions of IE and Netscape, respectively. Accordingly the script's JavaScript (the script element in the subsection's first textarea field) comprises a meant-for-IE part and a meant-for-Netscape part; I will specify the former in the discussion below. I'd go through the Netscape part as well if there were any browser other than Netscape 4.x that supports the layer object, but there isn't.
At the end of the JavaScript, a buttoncheck( ) function that listens for mousedown events is registered on the document object.
document.onmousedown = buttoncheck;Here's the buttoncheck( ) function:
function buttoncheck(e) {
if (document.all && event.button == 2) {
document.all.orderwindow.style.visibility = "visible";
window.alert("Please order my HTML-source by email!");
return false; }
/* Netscape block */ }• The button property of the event object returns 2 for a right-button mouse event.
• The "Please mail me your source-code" form is wrapped in a div element (IE 5.x will position a form element but IE 4.x and Netscape 4.x won't) whose id is orderwindow. The buttoncheck( ) function visibilizes the orderwindow div by toggling its CSS visibility property from hidden to visible.
• With most browsers context menus are generated by mousedown events (vis-à-vis click events), which are canceled by the
return false; statement.Clicking the form's button calls a sendmail( ) function that rehides the orderwindow div and submits the user's form data.
function sendmail( ) {
if (document.all) {
document.all.orderwindow.style.visibility = "hidden";
document.forms[0].submit( ); }
/* Netscape block */ }Finally, clicking the form's button calls a closewindow( ) function that rehides the orderwindow div.
function closewindow( ) {
if (document.all) {
document.all.orderwindow.style.visibility = "hidden"; }
if (document.layers) document.orderwindow.visibility = "hidden"; }The HTML
The "Please mail me your source-code" form's action attribute is set to a mailto: URL specifying the page author's email address. As you might guess from the
document.forms[0] reference in the sendmail( ) function, the form doesn't have an identifier, although it would be a good idea to give it one: back then we would have used a name attribute and today we would use an id attribute for this purpose. As noted above, the form's orderwindow div container is initially hidden; it's also absolutely positioned, which makes sense as we don't want the div to disrupt the normal flow of the document when we display it.<div id="orderwindow" style="position:absolute;top:10px;left:220px;visibility:hidden;">
<form action="mailto:you@youraddress.com"> ... </form></div>The form's legend, controls, and text input labels are laid out via a table:
<table width="300" cellpadding="4" cellspacing="0" border="0"> ... </table>The table HTML is larded with deprecated code - specifically, the cell background colors are set with bgcolor attributes and the cell contents are marked up with font elements - and I'm not going to burden you with the whole thing; here's the "lastname" (second) row:
<tr>
<td align="right" bgcolor="blue"><font face="Verdana" size="1" color="white">lastname:</td>
<td align="left" bgcolor="blue"><font face="Verdana" size="1"><input type="text" name="lastname" size="20" maxlength="40"></font></td>
</tr>
<!-- You don't need to see any more of this, do you? Didn't think so. -->• The first cell's lastname: text can and probably should be marked up with a label element.
<label for="textinputID">lastname:</label>
<!-- Explicit labeling is necessary if the text field and its label are in separate cells. -->• On my computer, a
size="1" font element attribute is equivalent to a font-size:x-small; style declaration.• Although the font element has an (%inline;)* content model and can therefore legitimately have input element children, I find that font element attributes have absolutely no effect on a text input value; they similarly have no effect on the push button values in the table's last row.
• Even as we are looking to get rid of the font element markup, I should note as regards the first cell that the font element's end-tag is not optional.
In practice
We recently discussed two 'no right-click' scripts in Blog Entry #274; I reported then that, in general,
(1) right-button mouse events are not recognized by Classic Mac browsers and
(2) mousedown event cancelation does not suppress the generation of context menus with modern OS X browsers but
(3) contextmenu event cancelation does suppress the generation of context menus with modern OS X browsers (and some older browsers).
These considerations likewise apply to the block-source script and its buttoncheck( ) code, which can be upgraded to:
document.oncontextmenu = function ( ) {
document.getElementById("orderwindow").style.visibility = "visible";
window.alert("Please order my HTML source by email!");
return false; }We noted in The mailto: blues section of Blog Entry #172 that mailto: forms are no longer handled as they were way back when, specifically, mailto: form submission does not directly send the form data to the action URL but instead launches the user's default email program, opening a "New Message" window with the To: field set to the action URL. (This presupposes (a) that there's a default email program on the user's computer in the first place, (b) that the email program is configured correctly, and (c) that the user's browser can communicate with the email program, which may not necessarily be the case - see Wikipedia's "mailto" entry and webdesign.about.com's "When Mailto Forms Don't Work" tutorial.) Moreover, if the form's method attribute is set to post, then the form data set will appear as a 'query string'
Lastname=Blow&Firstname=Joe&Country=USA&Email=jblow%40gmail.com
at the beginning of the "New Message" window's message field with some but not all browsers. The net result is that the user is required to take a more active role in getting the form data to the form's author, but that's probably as it should be.
Demo
Right-click me, I dare you.
You can send me an email if you like; I promise I won't try to charge you for my demo code.
More cold water
I'm the first to tell you that the foregoing analysis is all rather academic. The source for any Web page is easily accessed via the View Source (or equivalent) command of the browser's View or Tools menu: no right-clicks required. The block-source script is not practical code but rather a 'museum piece'.
Let me wrap up this post with some relevant developer commentary.
(1) Matthias Gutfeldt subscribes to a philosophy of
steal the code, not the content. Sounds right to me, Matthias.
(2) In a "How Do I Force...?" article in the Web Tips sector of his Web site, Dan Tobias explains the futility of concealing a Web page's HTML:
People have an exaggerated impression of the value of their HTML code and want to protect it from being "stolen". But there's no way to hide HTML source code from the user. The user's browser needs to receive all the HTML source code in order to display the page, so no matter what devious techniques the author uses to obscure the code, it still has to be parseable by the browser, and is thus not too hard for any halfway-intelligent user to turn into something readable.In sum, the only way to prevent the user from grabbing your code is to not upload it to the Web in the first place.
We will conclude our Lissa Explains It All JavaScript odyssey with a look at Section 8's mouse fireworks script, which we'll take up in the following entry.
- posted by A. Peak @ 7:33 PM
Actually, reptile7's JavaScript blog is powered by Café La Llave. ;-)