Disable View source

Roman

Hello to everybody,
I have some question concerning blocking view source from main menu of
IE or MF. I am able to block right click with <body
oncontextmenu="return false"> but still missing from main View->Source
Code.
Any hints ?
Regards,
Roman

Jan 12 '06 #1

Subscribe Reply

16056

RobG

Roman wrote:

Hello to everybody,
I have some question concerning blocking view source from main menu of
IE or MF. I am able to block right click with <body
oncontextmenu="return false"> but still missing from main View->Source
Code.
You only think you can, you can't prevent that reliably at all. There
are many ways of viewing the source other than via right-click or
browser menus.

Any hints ?

Yes, don't even try. Anything you publish on a web server can be viewed
and saved by someone visiting the site. If you don't want that, don't
publish it.
--
Rob

Jan 13 '06 #2

John Bokma

"Roman" <ro*************@gmail.com> wrote:

Hello to everybody,
I have some question concerning blocking view source from main menu of
IE or MF. I am able to block right click with <body
oncontextmenu="return false"> but still missing from main View->Source
Code.
Any hints ?

Don't waste your time and don't annoy your visitors. Your source is
probably not worth to be stolen in the first place.

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html

Jan 13 '06 #3

Ivo

"Roman" <ro*************@gmail.com> asks

I have some question concerning blocking view source from main menu of
IE or MF. I am able to block right click
Sorry, but no, you are not.
with <body oncontextmenu="return false"> but still missing from main
View->Source Code.
Any hints ?

There is no way you can hide your source from us or anybody. All you can do
is discourage people. If the browser is to display a page, the raw code must
be present on the user's hard disk, if directly not accessible from the main
menu due to scripts, frames and whathaveyou, then certainly from the
Temporary Internet Files folder, or by whatever name the cache may be known
locally.

And this little beauty of a bookmarklet restores all kinds of menus:

javascript:(function(w){for(var%20i=0;i<w.length;i ++){arguments.callee(w.fra
mes[i]);}try{function%20n(r){r.onclick=r.oncontextmenu=r .onmousedown=r.onmou
seup=null;}n(w.document);n(w.document.body);}catch (e){alert('Bookmarklet%20f
ailed:\n\n'+e.message);}})(top);

Really, it is more productive to put your energy into more fruitful
endeviours such as authoring innovative pages that people will want to come
and see, than hiding source code. If it is confidential, it doesn't belong
on the web.
--
hth
ivo
http://4umi.com/web/javascript/

Jan 13 '06 #4

Ed Jay

RobG <rg***@iinet.net.au> wrote:

Roman wrote:
Hello to everybody,
I have some question concerning blocking view source from main menu of
IE or MF. I am able to block right click with <body
oncontextmenu="return false"> but still missing from main View->Source
Code.
You only think you can, you can't prevent that reliably at all. There
are many ways of viewing the source other than via right-click or
browser menus.
Any hints?

While anyone with a will can see everything you've published and there's
nothing you can do stop that, there are several things you can do to
dissuade the casual looky-Lou from peaking at your code.
Yes, don't even try. Anything you publish on a web server can be viewed
and saved by someone visiting the site. If you don't want that, don't
publish it.

I think there should be a way to hide proprietary code. The need exists
and it's going to get bigger as hosted software becomes more commonly
used.

I'm about to market web-hosted medical diagnostic software that employs a
few proprietary algorithms. I've taken great measures to assure the app
isn't stolen, but I know that somewhere out there is a 13-year old,
pimply-faced kid wearing big glasses and a big grin who could get the code
if the mood struck him.

I wonder how owners of web-hosted applications are going to secure the
integrity of their ownership...

--
Ed Jay (remove M to respond by email)

Jan 13 '06 #5

John Bokma

Ed Jay <ed***@aes-intl.com> wrote:

I wonder how owners of web-hosted applications are going to secure the
integrity of their ownership...

They host the data as well.

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html

Jan 13 '06 #6

RobG

Ed Jay wrote:

RobG <rg***@iinet.net.au> wrote:

Roman wrote:
Hello to everybody,
I have some question concerning blocking view source from main menu of
IE or MF. I am able to block right click with <body
oncontextmenu="return false"> but still missing from main View->Source
Code.
You only think you can, you can't prevent that reliably at all. There
are many ways of viewing the source other than via right-click or
browser menus.

Any hints?

While anyone with a will can see everything you've published and there's
nothing you can do stop that, there are several things you can do to
dissuade the casual looky-Lou from peaking at your code.

What sort of threat - security or competitive - do such persons present?
How does preventing access to source code prevent anyone from
implementing a copy of your site? Getting the source code has never
been a requirement for knocking-off your competition.

Yes, don't even try. Anything you publish on a web server can be viewed
and saved by someone visiting the site. If you don't want that, don't
publish it.

I think there should be a way to hide proprietary code. The need exists
and it's going to get bigger as hosted software becomes more commonly
used.

A couple of methods spring to mind - there are others:

1. Provide downloadable binary executables - failed
2. Applets (Java, ActiveX) - rare, mistrusted
3. Xwindows and suitable X-client - never got off the ground
4. CORBA/IIOP barely drew breath - total failure

I'm about to market web-hosted medical diagnostic software that employs a
few proprietary algorithms. I've taken great measures to assure the app
isn't stolen, but I know that somewhere out there is a 13-year old,
pimply-faced kid wearing big glasses and a big grin who could get the code
if the mood struck him.
What will he/she do with it? How come eBay takes no precautions what so
ever? Or Google? Or even MSN? Because the value is in the service,
not the code.

You may as well complain that your competitors copied your idea of
putting in a front door to let the customers in. :-)

I wonder how owners of web-hosted applications are going to secure the
integrity of their ownership...

Those that try fail. Winners base their business on providing the best
service - their sites are kept up-to-date, they run efficiently in
(nearly) any browser, they offer useful content, they are open and
welcoming.

--
Rob

Jan 13 '06 #7

Ivo wrote:

There is no way you can hide your source from us or anybody. All you can do
is discourage people. If the browser is to display a page, the raw code must
be present on the user's hard disk, if directly not accessible from the main
menu due to scripts, frames and whathaveyou, then certainly from the
Temporary Internet Files folder, or by whatever name the cache may be known
locally.

To be fair there is a way to have View > Page Source grayed out (not
available). But it is not achievable by client-side scripting. One need
to send a right sequence of response headers from the server. It is
also not supported by all browsers, and where supported it smashes down
the browser caching mechanics.

But it is an absolute true: service is the key to success, not a copy
protection. One should go by the presumption of innocence and do not
look at *your* future visitors as a bunch of thiefs. (But still think
of them as of a bunch of experienced server hackers - it is paranoidal
and it is *not* true, but it's the way to build a secure server
solution).

It is very difficult to believe when reading Internet news :-), but in
the most part these are the same people used to work for money and
respect someone else's property. The rest sign off for "shrink" (as
it's called in grocery stores).

Jan 13 '06 #8

Evertjan.

VK wrote on 13 jan 2006 in comp.lang.javascript:

To be fair there is a way to have View > Page Source grayed out (not
available). But it is not achievable by client-side scripting.

Try this to gray it out:

<http://devrijehuisarts.org/test/noViewSource.asp>

[sorry, no clientside script]

;-)

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

Jan 13 '06 #9

Evertjan. wrote:

Try this to gray it out:

<http://devrijehuisarts.org/test/noViewSource.asp>

Right, I meant similar trick, and (besides other drawbacks) IE is the
only one (at least on Windows) who buys it.

Jan 13 '06 #10

Randy Webb

Evertjan. said the following on 1/13/2006 4:37 AM:

VK wrote on 13 jan 2006 in comp.lang.javascript:

To be fair there is a way to have View > Page Source grayed out (not
available). But it is not achievable by client-side scripting.

Try this to gray it out:

<http://devrijehuisarts.org/test/noViewSource.asp>

[sorry, no clientside script]

;-)

You need to update that image to say "This page has no view-source in
Internet Explorer but it does in Firefox".

Right click>View Page Source

Not of much use to you but it will give you some source code :)

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Jan 13 '06 #11

Evertjan.

VK wrote on 13 jan 2006 in comp.lang.javascript:

Evertjan. wrote:
Try this to gray it out:

<http://devrijehuisarts.org/test/noViewSource.asp>

Right, I meant similar trick, and (besides other drawbacks) IE is the
only one (at least on Windows) who buys it.

I doubt FF can be fooled.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

Jan 13 '06 #12

Paul Cooper

On Fri, 13 Jan 2006 03:25:30 GMT, RobG <rg***@iinet.net.au> wrote:

Ed Jay wrote:
RobG <rg***@iinet.net.au> wrote:

A couple of methods spring to mind - there are others:

1. Provide downloadable binary executables - failed
2. Applets (Java, ActiveX) - rare, mistrusted
3. Xwindows and suitable X-client - never got off the ground
4. CORBA/IIOP barely drew breath - total failure

Takes deep breath in anticipation of flames:

Use JSP or PHP or ASP to keep the processing server side?

If the data are client side, then you're sunk - you either have to
download an application (applet, OCX or plugin), or trust your users.

There simply isn't a Javascript answer, which puts it out of scope for
this newsgroup.

Paul

Jan 13 '06 #13

Patient Guy

Ed Jay <ed***@aes-intl.com> wrote in
news:bq********************************@4ax.com:

RobG <rg***@iinet.net.au> wrote:
Roman wrote:
Hello to everybody,
I have some question concerning blocking view source from main menu
of IE or MF. I am able to block right click with <body
oncontextmenu="return false"> but still missing from main
View->Source Code.

You only think you can, you can't prevent that reliably at all. There
are many ways of viewing the source other than via right-click or
browser menus.
Any hints?

While anyone with a will can see everything you've published and
there's nothing you can do stop that, there are several things you can
do to dissuade the casual looky-Lou from peaking at your code.

The "casual looky-Lou" most likely has no interest in your code, which
might actually be very badly written and poorly instructive.

Those determined to see your code who have even a modicum of talent will
get past your vain attempts to frustrate them.

In getting to the script, some people would answer to those asking the
question of how one sees the Javascript in the delivered document: "if
you have to ask, you probably don't need to know the answer."

Jan 13 '06 #14

Jasen Betts

On 2006-01-13, Ed Jay <ed***@aes-intl.com> wrote:

RobG <rg***@iinet.net.au> wrote:
Roman wrote:
Hello to everybody,
I have some question concerning blocking view source from main menu of
IE or MF. I am able to block right click with <body
oncontextmenu="return false"> but still missing from main View->Source
Code.
You only think you can, you can't prevent that reliably at all. There
are many ways of viewing the source other than via right-click or
browser menus.
Any hints?

While anyone with a will can see everything you've published and there's
nothing you can do stop that, there are several things you can do to
dissuade the casual looky-Lou from peaking at your code.

Yes, don't even try. Anything you publish on a web server can be viewed
and saved by someone visiting the site. If you don't want that, don't
publish it.

I think there should be a way to hide proprietary code. The need exists
and it's going to get bigger as hosted software becomes more commonly
used.

activex ?
I'm about to market web-hosted medical diagnostic software that employs a
few proprietary algorithms. I've taken great measures to assure the app
isn't stolen, but I know that somewhere out there is a 13-year old,
pimply-faced kid wearing big glasses and a big grin who could get the code
if the mood struck him.

I wonder how owners of web-hosted applications are going to secure the
integrity of their ownership...

--

Bye.
Jasen

Jan 14 '06 #15

Jasen Betts

On 2006-01-12, Roman <ro*************@gmail.com> wrote:

Hello to everybody,
I have some question concerning blocking view source from main menu of
IE or MF. I am able to block right click with <body
oncontextmenu="return false"> but still missing from main View->Source
Code.
do you think it might be harmful to IE users in some way?
are you embarrassed by your source?

seriously there's no way to put something on the web in a publically
accessible way and then stop people from

dowloading it
or reading its contents
or loading it into an editor etc...
Any hints ?

serve all the content by the IE version of XMLHttpRequest
and use innerHtml to insert it into the document.

then if they do click view source all they'll see is the fetcher.
--

Bye.
Jasen

Jan 14 '06 #16

phfeenikz

> serve all the content by the IE version of XMLHttpRequest

and use innerHtml to insert it into the document.

then if they do click view source all they'll see is the fetcher.

Better yet use the IE, AND FF version of XMLHttpRequest.

Remember that since the source can be viewed by anyone, they can also
see the URL that XMLHttpRequest is requesting. This means anyone can
visit that URL by typing it into their address bar, and then view the
source from there. Futhermore, XMLHttpRequest will not serve up
javascript; that can only be done on the client side. The only way to
hide code on the internet is to put it in a server-side script i.e.
PHP, ASP, PERL, etc., and serve the resulting content to the user's
browser (be it via a URL, or XMLHttpRequest). XMLHttpRequest itself
won't hide the code.

Jan 14 '06 #17

Dr John Stockton

JRS: In article <Xn*****************@207.115.17.102>, dated Fri, 13 Jan
2006 13:12:05 local, seen in news:comp.lang.javascript, Patient Guy
<sevisen.adam@gmailDOTHEREcom.?> posted :

Roman wrote:
Hello to everybody,
I have some question concerning blocking view source from main menu
of IE or MF.

But not from other browsers?
The "casual looky-Lou" most likely has no interest in your code, which
might actually be very badly written and poorly instructive.

Not necessarily so.

For example, a potential employer may wish to look at the Web site of a
potential employee, to see whether the employee appears competent,
follows accepted standards, etc. I've read that TL's site is
interesting in this respect. Likewise, a potential client might wish to
assess a possible provider of services.

My copy of W3's TIDY finds no problems with my copy of the newsgroup
FAQ; but the validator in my copy of CSELITE20 (Copyright © 1997-2000 AI
Internet Solutions. Wed, May 03 2000) finds two errors on line 715 !!
They are, however, errors I've frequently found harmless myself.

--
© John Stockton, Surrey, UK. ??*@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Check boilerplate spelling -- error is a public sign of incompetence.
Never fully trust an article from a poster who gives no full real name.

Jan 14 '06 #18

askMe

Ed Jay wrote:

RobG <rg***@iinet.net.au> wrote:
Roman wrote:
Hello to everybody,
I have some question concerning blocking view source from main menu of
IE or MF. I am able to block right click with <body
oncontextmenu="return false"> but still missing from main View->Source
Code.
You only think you can, you can't prevent that reliably at all. There
are many ways of viewing the source other than via right-click or
browser menus.
Any hints?

While anyone with a will can see everything you've published and there's
nothing you can do stop that, there are several things you can do to
dissuade the casual looky-Lou from peaking at your code.

Yes, don't even try. Anything you publish on a web server can be viewed
and saved by someone visiting the site. If you don't want that, don't
publish it.

I think there should be a way to hide proprietary code. The need exists
and it's going to get bigger as hosted software becomes more commonly
used.

I agree that the need exists. On the other hand, source code viewing
often helps the user. For example, I hate going to a site, filling out
some long form, posting it, then receiving a javascript error
preventing the form's submission. Viewing the source may provide
details about what went wrong (usually a missing/renamed form element
referred to by the javascript's onsubmit).
I'm about to market web-hosted medical diagnostic software that employs a
few proprietary algorithms. I've taken great measures to assure the app
isn't stolen, but I know that somewhere out there is a 13-year old,
pimply-faced kid wearing big glasses and a big grin who could get the code
if the mood struck him.

Shouldn't anything that processes/transmits medical information use
https?

http://www.askblax.com
I wonder how owners of web-hosted applications are going to secure the
integrity of their ownership...

--
Ed Jay (remove M to respond by email)

Jan 15 '06 #19

Randy Webb

askMe said the following on 1/15/2006 7:26 AM:

Ed Jay wrote:
RobG <rg***@iinet.net.au> wrote:

Roman wrote:

<snip>
Yes, don't even try. Anything you publish on a web server can be viewed
and saved by someone visiting the site. If you don't want that, don't
publish it.
I think there should be a way to hide proprietary code. The need exists
and it's going to get bigger as hosted software becomes more commonly
used.

I agree that the need exists.

And a means to protect "source code" exists. Just not for the web. And
there is no "need" for it.
On the other hand, source code viewing often helps the user.
Only if the user is trying to learn how (or how not to) write code.
Other than that, viewing the source doesn't "help the user" anymore than
anything else does.
For example, I hate going to a site, filling out some long form,
posting it, then receiving a javascript error preventing the form's
submission.
As well as I do. But viewing the source won't fix the error. It can only
tell me how to circumvent the js. But that still doesn't help the
*average* user.

javascript:document.forms[formName].submit();

I need the source to know the formname or the forms number in the page.
That is the only reason I need to view the source of a crappy page with
JS errors.
Viewing the source may provide details about what went wrong (usually a
missing/renamed form element referred to by the javascript's onsubmit).

Unless you are emailing the webmaster to inform them how to duplicate it
and fix it, then finding the source of the error is of no use.

I'm about to market web-hosted medical diagnostic software that employs a
few proprietary algorithms. I've taken great measures to assure the app
isn't stolen, but I know that somewhere out there is a 13-year old,
pimply-faced kid wearing big glasses and a big grin who could get the code
if the mood struck him.

Shouldn't anything that processes/transmits medical information use
https?

http://www.askblax.com

A better solution would be a stand-alone application that used an
internet connection to transmit data via https or some other secure
protocol would be a browser based application any day.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Jan 15 '06 #20

Thomas 'PointedEars' Lahn

RobG wrote:

Ed Jay wrote:
I think there should be a way to hide proprietary code. The need exists
and it's going to get bigger as hosted software becomes more commonly
used.
A couple of methods spring to mind - there are others:

1. Provide downloadable binary executables - failed

^^^^^^
I beg your pardon?
2. Applets (Java, ActiveX) - rare, mistrusted
True, however Java applets do not require ActiveX/COM per se.
3. Xwindows and suitable X-client - never got off the ground

Could you please elaborate on what you mean by "Xwindows"?
PointedEars

Feb 15 '06 #21

RobG

Thomas 'PointedEars' Lahn wrote:

RobG wrote:

Ed Jay wrote:
I think there should be a way to hide proprietary code. The need exists
and it's going to get bigger as hosted software becomes more commonly
used.

A couple of methods spring to mind - there are others:

1. Provide downloadable binary executables - failed

^^^^^^
I beg your pardon?

Gosh Thomas, did you decide to mark my stuff for homework? I'll reply
to just this one.

I was commenting on Ed's request to hide source code and suggesting that
supplying binary executables was one way of 'hiding' the source.

I consider it has failed because getting users to download binary files
for use over the web as a general method of providing functionality on
web sites has been tried but is extremely rare.

Most surfers won't even download plugins, they just use whatever came
with their PC and if that doesn't work, they'll go elsewhere. Some
banks used to require users to download programs to run for internet
banking which were generally only for Windows - all the ones I know of
have now switched to using open standards that work in any (modern)
browser on any platform (hurrah for that).

2. Applets (Java, ActiveX) - rare, mistrusted

True, however Java applets do not require ActiveX/COM per se.

I'm not suggesting that they do, I'm suggesting that ActiveX and Java
are technologies that can be used for applets. They aren't necessarily
mutually exclusive, or dependent, or the only technologies available but
they are probably the most common and best known.

3. Xwindows and suitable X-client - never got off the ground

Could you please elaborate on what you mean by "Xwindows"?

As in "X Window System", e.g. X11. I think you knew that.
--
Rob

Feb 16 '06 #22

Thomas 'PointedEars' Lahn

RobG wrote:

Thomas 'PointedEars' Lahn wrote:
RobG wrote:
Ed Jay wrote:
I think there should be a way to hide proprietary code. The need exists
and it's going to get bigger as hosted software becomes more commonly
used.
A couple of methods spring to mind - there are others:

1. Provide downloadable binary executables - failed ^^^^^^
I beg your pardon?

Gosh Thomas, did you decide to mark my stuff for homework?

In a sense. If you would like to remember, I discovered that you posted
with a nonexistent e-mail address that only looked OK in January, and
therefore I had to decrease your score. Since I happen to have observed
recently that your From header, albeit unchanged, conforms to Internet
Standards now, I found it appropriate to adjust my scorefile again (maybe
I should write a regularly called script to automate this). The articles
you posted since then were still marked as unread of course and I wanted
to catch up on those. I thought you of all people would appreciate that.
I'll reply to just this one.
That would be a pity.
I was commenting on Ed's request to hide source code and suggesting that
supplying binary executables was one way of 'hiding' the source.

I consider it has failed because getting users to download binary files
for use over the web as a general method of providing functionality on
web sites has been tried but is extremely rare.
They *are* rare. But has the distribution method *failed*? No.
Take Google Earth for example.
[...]
2. Applets (Java, ActiveX) - rare, mistrusted

True, however Java applets do not require ActiveX/COM per se.

I'm not suggesting that they do, I'm suggesting that ActiveX and Java
are technologies that can be used for applets. They aren't necessarily
mutually exclusive, or dependent, or the only technologies available but
they are probably the most common and best known.

As you already know that, why do you say that Java applets are rare or even
mistrusted per se? For they are not. Take the numerous Java-based Web
chats for example.

3. Xwindows and suitable X-client - never got off the ground

Could you please elaborate on what you mean by "Xwindows"?

As in "X Window System", e.g. X11. I think you knew that.

I see. Since I am using a recent newsreader application on top of the
"X Window System Version 6.8.2 (Debian 6.8.2.dfsg.1-11 20051129054125
David Nusinow <dn******@debian.org>)" now, and X-Forwarding is very
much alive even for Windows systems, that statement is not true either.
Regards,
PointedEars

Feb 16 '06 #23

RobG

Thomas 'PointedEars' Lahn wrote:

RobG wrote: [...]
Gosh Thomas, did you decide to mark my stuff for homework?

In a sense. If you would like to remember, I discovered that you posted
with a nonexistent e-mail address that only looked OK in January, and
therefore I had to decrease your score. Since I happen to have observed
recently that your From header, albeit unchanged, conforms to Internet
Standards now, I found it appropriate to adjust my scorefile again (maybe
I should write a regularly called script to automate this). The articles
you posted since then were still marked as unread of course and I wanted
to catch up on those. I thought you of all people would appreciate that.

Of course! :-)

I'll reply to just this one.

That would be a pity.

I was commenting on Ed's request to hide source code and suggesting that
supplying binary executables was one way of 'hiding' the source.

I consider it has failed because getting users to download binary files
for use over the web as a general method of providing functionality on
web sites has been tried but is extremely rare.

They *are* rare. But has the distribution method *failed*? No.
Take Google Earth for example.

It has failed in the sense that it is rarely used in comparison to
scripting or even the standard set of plugins (flash, shockwave, media
players).

Google Earth is interesting, but will it change the paradigm? We'll
have to wait and see on that I think, the 'wow factor' is wearing off
rapidly.

[...]
2. Applets (Java, ActiveX) - rare, mistrusted [...] As you already know that, why do you say that Java applets are rare or even
mistrusted per se? For they are not. Take the numerous Java-based Web
chats for example.

Fine, but as a general mechanism for adding functionality to web pages
they aren't much used. Java tends to be mistrusted because many users
do not differentiate between it and ActiveX.

3. Xwindows and suitable X-client - never got off the ground

Could you please elaborate on what you mean by "Xwindows"?

As in "X Window System", e.g. X11. I think you knew that.

I see. Since I am using a recent newsreader application on top of the
"X Window System Version 6.8.2 (Debian 6.8.2.dfsg.1-11 20051129054125
David Nusinow <dn******@debian.org>)" now, and X-Forwarding is very
much alive even for Windows systems, that statement is not true either.

Good for you, but if you wish to deliver some functionality over the web
to a general audience, would you choose to use X simply to stop others
looking at your source code?
--
Rob

Feb 16 '06 #24

Thomas 'PointedEars' Lahn

RobG wrote:

Thomas 'PointedEars' Lahn wrote:
RobG wrote:
[...]
> 2. Applets (Java, ActiveX) - rare, mistrusted [...]
As you already know that, why do you say that Java applets are rare or
even mistrusted per se? For they are not. Take the numerous Java-based ^^^^^^^^^^^^^^^^^^^ Web chats for example.
^^^^^^^^^^^^^^^^^^^^^^ Fine, but as a general mechanism for adding functionality to web pages
they aren't much used.
But they are.
Java tends to be mistrusted because many users do not differentiate
between it and ActiveX.

That is *their* problem, not something that is a valid argument against
using the technique. A valid argument would be runtime efficiency, for
example.

> 3. Xwindows and suitable X-client - never got off the ground
Could you please elaborate on what you mean by "Xwindows"?
As in "X Window System", e.g. X11. I think you knew that.

I see. Since I am using a recent newsreader application on top of the
"X Window System Version 6.8.2 (Debian 6.8.2.dfsg.1-11 20051129054125
David Nusinow <dn******@debian.org>)" now, and X-Forwarding is very
much alive even for Windows systems, that statement is not true either.

Good for you, but if you wish to deliver some functionality over the web
to a general audience, would you choose to use X simply to stop others
looking at your source code?

While I am against Closed Source in general, whether I would use X here
to accomplish Closed Source anyway would depend strongly on the field of
application. It is probably unwise to allow visitors of a fair to read
the source code of a Web-based invention presented there, for example.
Regards,
PointedEars

Feb 17 '06 #25

Similar topics