whadya know?

[Jer]

Don't count out the idea of source barring quite yet.

I'm working on a project that when completed, would use HTML and image compression in conjunction with one another (server side) to prevent viewing of the source. The end product will be a fully functional html page, not able to be sourced, and still completely editable and manageable.

I'm making no promises or guarantees, but this theorem has been in development for about 10 months now, and is *almost* to the point where a test version can be compiled.

If anyone's interested, I can provide an update when progress merits it.

-J. Noonan

[partypageusa]

keep me updated

[BigTony]

Sounds pretty cool

Biggie-T

[partypageusa]

more information would be great

[Delicates]

Sounds pretty lame.

Lemme guess, taking a screenshot of your page and then using it as an image map?
:D

[Jer]

Although I am somewhat reluctant to release detailed specs of the project (for what can be viewed as obvious reasons), I can say this:

-This project was originally a conceptual theory, derived from an altercation stemming from an attempted commercialization of an idea originally copyrighted by myself and the two others involved in my work. The end result was positive (in my favor); winning the debacle and being allowed to claim the concept as my own. After this, I began thinking about what I could do to protect my designs (back then, mostly HTML, other simple scripting). However, back then, the thought of parenting a new scripting language was out of my ability, so I turned my attention to technology already implemented globally.

-The skeleton of our coding is based on simple HTML (,the protecting of), but integrated with the same properties that an image file (e.g. jpeg) possesses. Much in the way that you can't conventially edit the code that comprises an image file, our ultimate goal is to create HTML documents that can be exported to the same type of unalterable format.
While it is easy to say that you could technically open up an editing program and use the ol' eraser tool to change the name on the header of the page, this will be a futile process. As we have it now, the "image" of the page would be changed, but the source would not be compromised. Once saved in this format, the HTML document would be unalterable; hypertext and other active scripts would still function, however, the code of the document will be embedded into the image file that makes up the final product.
To edit such a document, one will have to obtain the original html document, unformatted. From there, you would make your edit to the original (make mods/updates, etc), save it (auto-encrypting, which by the way, we've deemed virtually impossible to decode/crack illictly), and then place both the original copy (mod'd), in sync with the target you want to update. Using an algorithm that we have created, the copy would have to match a digital stamp that both copies possess (embedded into source).
If the checksum proves true, the formatted copy can be modified.

**Note: This may sound confusing/inconcise, but this is only because I am having to describe the workings of the code without supplementing it directly. That, and my brain hurts.


We have been working to resolve a few key bugs; the primary of which is the end file size (a little too large - average html page is about 100-150k after formatting). Our goal is to compress this down to about 30-40k.
Additionally, I am looking for developers that have formidable experience with image design (namely jpeg, but bmp's and gif's are also of interest to us) to confer with.

All in all, the code uses pixel location to determine objects such as hypertext/links, which will have functionality even after the formatting of the original HTML.

Again, as time allows, a beta will be released, but I'm looking at another handful of months, at best (likely 6 months or so). Additionally, once we've managed to meet our own criteria (which we've *almost* done), we will be releasing a limited number of codec packages to people interested in checking the end result out. At that point, we will have compiled a small handful of pages online, all in the new format.

Again, if anyone can provide insight, it is more than welcome.
Ultimately, I'd like to commercialize this, but in a way that appeals to a middle-class income, not just the moneybags out there. Piracy will not be an issue at that point. To view someone's source code, you'd literally have to guess every character of code accurately to modify or even have the proper source code.
While this is not a permanent solution (there likely never will be), I am confident that this will provide a high level of content protection, when implemented.

And no, Delicates, this is much more than merely posting some horrendous screenshot of my page; however, you are correct in saying that that would be rather lame. I agree completely.

[Delicates]

If you're not making an image of the page, then you're making some kind of plugin that should be used to view pages. Which is even worse.

If you're doing that, you're basically trying to write a browser, that displays pages compiled in some format. And when reverse engineered, the resulting source code will probably be even better than original source could ever be.

You're sacrificing Dynamic HTML, you're sacrificing Forms, you are sacrificing accessibility. You're basically sacrificing everything that people have been striving to achieve in web standards, just for the purpose of stroking ego of someone who thinks the page they wrote is what every human desperately needs.

Bottom line is you're reinventing a wheel in an ugly and cumbersome way.

But then again, if you're not trying to encapsulate a browser into a plugin, then we get right back to displaying a lame image. And image with some scripting added to it is no less lamer. No accessibility, and no DHTML.

Step back and have a long look at Adobe Acrobat. And then look at what you're doing. And ask yourself why on earth are you doing it?

[Jer]

An interesting rebuttle; certainly worthy of credit.

However, despite the eloquence and interesting points you've presented, you're still quite incorrect as to the nature of this project.

As stated in my previous posts: I refuse to go into details as to th e inner workings of this software. And, you could also say that I'm not very good at verbally throwing a curveball, as to discuss the potential of this code without compromising mine and others' work.

Again: good things to bring up, but wrong nonetheless.

Regardless, you can make what assumptions you will; I will allow my program to speak for itself upon completion, and you will be impressed, at the very *least*.

Nobody has done this before; not to this degree, anyway.
And no, DHTML would not be sacrificed, nor would any other script lang.

-Jeremy Noonan

[HZR]

Can I ask why you're doing this project?

[Jer]

dbindel summarized it up fairly accurately.

I've always been tossed up between coding free software, rather than commercializing it for profit. However, as things have been uncertain in the aspect of stable Web business, I have felt a need to make an income off of a product I create, mainly because I have bills to pay, a family to support, and less and less time to spend *freely*.

I am doing this project in hopes that while information should be free, people can still protect what's their's. Not to mention that finding other professionals to work and develop with is hardly inexpensive - like myself, others in the industry need to earn a living.

This is a sound project, with results we've deemed as nothing short of amazing. While skeptics and pessimistic perspecties
are nothing that can be changed without a viable reason, we have been putting our 100 percent into this, in the hopes that we can annul such negativity. This is not something that can be compared to other software, such as Adobe Acrobat. This is an entirely different approach to a problem that has blemished people's work for many years. Much like any other script, codec, or any other new integration of the Internet, the benefits and capabilities of the code will become more present as the public adopts and reviews it for themselves.

All in all, everyone's got their own opinion; I'm no stranger to this.
My point is, that everything/one deserves a chance before negative assumptions are made.

I wouldn't have ever taken out a personal loan to cover the cost of employing others, as well as research and general work, if I didn't believe that we're on to something big.

[scotttyz]

How about the impact on the much loved Googlebot?

[Jer]

An interesting point.

Entities such as the "googlebot", amongst others, will have their functions differing in ways that aren't very easy to predict. I wouldn't go as far as to say that their "jobs" would be cut; let's face it: there's always going to be standard html out there to scour. On the same note, it's very unclear as to what's going to happen as a result of this project; it may fizzle into nothing (e.g. 3DML), or it may compel the designers of these bots to modify their product to include the new pages in their search.
In the end, everything rests on demand. I'm hoping that when our beta is released, larger enterprises who spend x amount of money annually on web design/maintenence will see our design to be of practical use; *especially* to corporations who take an imperialistic approach to those who duplicate their web designs for their own.
Most importantly, I hope to make a substantial amount of money so that my family and I can have financial security in our lives; who knows where consumerism will take us in 10 years? I don't want to be stuck in any rut all because of my career choices now.

I've recieved negative statements from those more in favor of the open source community, hearing everything from how this is technical nazism, to some rather crazy-sounding people quoting GPL beliefs that in my opinion, have little or no relevance to what I'm doing.
Either way, I'm doing this, and it's going to happen, whether people like it or hate it.
Although I must say, I still wouldn't mind talking to somebody who knows a little about pixel communication (hardware to soft).

Any additional questions/comments can be directed either here (provided it's topical), or to my mailbox at jpnoonan@shaw.ca

Thanks for your support; I've heard a few really positive things from those who are for this.

J. Noonan
ICQ: 15974218

[scotttyz]

I am not worried about the googlebot loosing it's job. The other end was where my interest was:

If the loved googlebot (mostly the standard in the SEW until Yahoo moves and then only half of it) does not like your encrypted pages than your market will be limited to people who don't care about search engine placement. That does not leave much, and with google openly against cloaking I do not think they will change to include the encrypted pages.

just 2 cents to think on

[Orange]

we've deemed virtually impossible to decode/crack illictly)

If you think you can write code or a program that won't be cracked your mistaken. My favorite example of this is 3d Studio Max.
When 3d Studio was released, it was suppose to have the most uncrackable protection ever created. It relied on using a Dongle(a hardware componet of your computer) in the protection.

Well 3 weeks later the uncrackable was cracked.

If you make it, They will crack it.

[Jer]

This was a statement that I would suppose, looking back, wasn't very well thought out.

What I mean is, you're not going to be able to just sit down and brute force this. It's not possible. Albeit there are other methods of decryption, and those may work. As I also stated in one of my posts, this will not be a long term or even permanent solution; there likely never will be such a thing. However, initially, I stand firm in my belief that it will suffice.

I certainly didn't mean to make such a bold remark, and I think I could have thought about what I posted; I apologize for any pretentiousness I may have portrayed.

** We are currently looking at a first-quarter 2003 release of our beta; this is not a solid date, but our estimated time of completion and as such, is subject (although unlikely) to change.

Jeremy Noonan
15974218

[Orange]

sepa ti my main daime

[Jer]

< My apologies, I didn't know where you were going in your original question.>


This project, in nature, is being geared to become a standardized format, and as such, will (hopefully) be taken in by engines.
Dont get me wrong: The process in entirety will be a slow, tedious one. But that's how things need to be to succeed.

Again, it will have to be adopted by consumers and proven to be popular; so much so that Google and all of the other players will see it as a notable item to be served.

It all comes down to a hybrid of trial and error/waiting game. Naturally, the developers/resources site that will be online prior and after the release will offer both the new format and HTML versions to peruse, as to avoid frustration and lack of option.

On another note; any ideas as to what the file extention should be? Suggestions are welcome.

Jeremy Noonan
15974218

[pezland]

While I don't believe there is or will ever be any definitive way to completely protect against the copying of websites, methods could be developed to make the process more cumbersome.

With graphics it could be as simple as taking a screenshot of the desired graphic, or even simply dragging the graphic onto one's desktop. Even with the design itself it is simple enough to just take the screenshot and divvy it up, easily transitioning into an HTML layout.

Yet while pirating of the page content itself is the issue, there many sites which display content dynamically through server-side scripting. I think the content pirates mete out their own punishment through the tedium of copying static code from dynamically generated pages. I've seen this in action from my own site, and while our content is continually updated, the copycats eventually lose interest anyway. As for copying a design or layout, imitation is the highest form of flattery, yet also unoriginality :)

[Jer]

Another interesting point.


The entire "tedium-of-process" aspect is an excellent one. Our design ties in a great deal with this. And as you said, most pirates would rather lose interest than have to snip at code and convert it all properly. Even so, the code would very likely make no sense to the pirate, so the process is lengthened even more by having to interpret the code in proper order before any pirating can occur.


If you or anyone else reading this has formidable experience in code encryption, we are looking for someone. Don't worry, the work can be done remotely.
Some form of contract would be negotiated. Contact jpnoonan@shaw.ca for more details.

Jeremy Noonan
15974218