Atrise HTML Lock, a bad joke on Interval

It looked for a moment as though the days of poor client-side scripting articles on Interval
were over. Then along came an article with the misleading title
Secure HTML Pages, dredging up the proverbial skeleton in the closet.
Someone unfamiliar with the subject could read all sorts of things into that headline. A more experienced web designer or coder would shudder. I shook my head.

What Atrise HTML Lock does is flawed in principle. It tries to solve an unsolvable problem
and makes pages unusable in the process. Start by remembering that HTML
is inherently descriptive. It structures information so
it can be interpreted in a clear, readable form. It follows
that the source always reaches the browser in all its naked glory. The methods
the article describes and the program implements are mere crutches. The same key is used
to encode and decode the source. The article should have explained the pros and cons of the approach in place of finding roundabout ways to justify just one point of view.

So I downloaded the program and started testing it. I made a simple test page
and ran it through the program.

Pokusná stranka

Ahoj světe, jsem první zašifrovaná stránka

Analyzing the generated code

I was looking forward to seeing the resulting page the program would spit out. I was especially interested
 in how the decoder worked and what the source code would look like. The program didn't disappoint,
 in the worst sense.

An arbitrary change of encoding

The first thing that caught my eye in the generated page was the change
 of encoding. The program took the original windows-1250 and made it iso-8859-1. The page would therefore
 be completely unreadable unless we fiddled manually with the encoding settings
 in the browser.

Wiping out the DOCTYPE and producing invalid code

I set about deciphering the generated source code. The program apparently didn't like the original DOCTYPE,
 so to be safe it left it out entirely, perhaps to avoid confusing some browsers.
 The script tag has a related problem. In the output it contains the deprecated language attribute. If
 the original page were XHTML, this would make the code invalid, although a solution is available
 in the type attribute. In other words, the program completely ignores the document's chosen DTD
 and always substitutes a hard-coded definition. To be sure, I used the Dagblog home page, which uses
 the XHTML 1.0 Strict DTD. The result was exactly the same.

While debugging the decoder I found that it outputs the original page in its entirety.
 The authors didn't even bother to leave the original meta tags in place and insert their code into the body. Instead, the body
 of the page, the body tag, gets another copy of the doctype and every tag from the root html tag onward.

How the encryption works

The program warns that this kind of protection is easy to break, but I wanted to see the guts
 of the script. It is immediately clear that everything revolves around two arrays, t and h. The encoded page is stored
 in h, and t contains every character in the iso-8859-1 set. Part of the chosen password, the constant 44
 and part of the encrypted code are combined with the logical XOR operator to calculate the character's position in t.
 This continues until the whole line has been put together.

With the poor man's debugger, a phrase I really like, otherwise known as alert, it's easy to see the resulting source code. Put alert in the condition checking
 whether c equals 13 and use it to print the contents of s. That gives us the output printed by
 document.write into the resulting page.

Final assessment

Advantages

• It will put off a few would-be beginners looking around.

Disadvantages

• It works only when client-side scripting is enabled.
• The change of encoding makes it unusable for pages with Czech characters.
• It removes the DOCTYPE and uses its own very poor template.
• The generated code is invalid.
• The resulting document lacks any logical structure.
• It offers no protection at all against a somewhat experienced user.
• Indexing this kind of document, searching it and so on are problematic.
• Larger documents take significantly longer to display.

The output might put plenty of people off, but a slightly more
 experienced coder would have no trouble uncovering the source. From the points above,
 the program really is unusable and isn't worth the time. The whole thing
 strikes me as careless work, both Atrise HTML Lock itself
 and the article. If the author of the article had done a little more work, he would probably have reached the same
 conclusion. Trying to conceal source code is futile, unnecessary and runs against most
 basic principles of usability and accessibility.