[ale] source code

[James Sumners]

The web browser cannot render a document it cannot parse. That is to
say, you _have_ to send the client the "source code."

There is nothing proprietary about HTML. It's an open document
specification. That's the whole point of it.

Even if you do the ridiculousness that others are suggesting, you have
to send the client the necessary code to decode your mangled HTML so
that the browser can parse and render it. Even if you obfuscate the
JavaScript, a dedicated person will be able to figure out what it is
doing with little effort. Plus, you can't count on the client to have
JavaScript enabled in the first place. In that case your obfuscated
HTML would never be loaded.

On Sunday, November 14, 2010, Terry Bailey <terry at bitlinx.com> wrote:
>
>
> I see that it was confusing as to what I meant by source code.  I
> meant the html code generated by the cgi Perl script that is sent to
> the client browser.
>
> Thank you for your thoughtful answer.
>
> At one time I was involved with complied Perl and wondered the other
> day if that was still being done.
>
>
>
>
>
> At 07:05 PM 11/14/2010, you wrote:
>>On Sun, 14 Nov 2010, Terry Bailey wrote:
>>
>> > If you are writing dynamic web pages using cgi and Perl, is there any
>> > way to set a flag so that the generated source code is not viewable?
>>
>>If you mean so the generated HTML is not easily readable,
>>there are all kinds of schemes where encoded junk is delivered to a
>>browser and then a piece of JavaScript decodes it in the browser..
>>and you can usually use a web developer tool to see the plain text
>>HTML afterwards if plain "view source" doesn't work.
>>
>>A lot of JavaScript is often "encoded" in one scheme or another,
>>and that is often a sign of hidden payloads or really bad things done in
>>code you don't want to see.
>>
>>As for code on the server: You used to be able to "compile" perl,
>>but last time I tried it (a couple of years ago) that has been
>>depreciated. Besides, it did not work well in some cases.
>>
>>I'm not sure what is currently available for Perl, but I am currently
>>using IonCube to encode/obfuscate some PHP. In my case it works better
>>than Zend's solution because it allows installing on a newer PHP version
>>then Zend's if you don't use the newer commands. It required a module
>>loaded on the server to decode it on the fly. Reportedly it's fairly
>>easy to "decode", but it allows me to deploy some code in a semi-hostile
>>environment where it keeps the young-turks from messing with it easily.
>>It's like keeping your door locked. Easy to bypass, but you can yell to
>>the authorities they broke in.
>>
>>there are also bad things like:
>>
>>http://liraz.org/obfus.html
>>
>>and discussions like:
>>
>>http://www.perlmonks.org/?node_id=832511
>>
>>
>>
>>
>>
>>_______________________________________________
>>Ale mailing list
>>Ale at ale.org
>>http://mail.ale.org/mailman/listinfo/ale
>>See JOBS, ANNOUNCE and SCHOOLS lists at
>>http://mail.ale.org/mailman/listinfo
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>

-- 
James Sumners
http://james.roomfullofmirrors.com/

"All governments suffer a recurring problem: Power attracts
pathological personalities. It is not that power corrupts but that it
is magnetic to the corruptible. Such people have a tendency to become
drunk on violence, a condition to which they are quickly addicted."

Missionaria Protectiva, Text QIV (decto)
CH:D 59