Open Source IDE, Windowing System and Desktop Environment (31kb)*

[darwinist]

*With manual.

http://darwinist.googlepages.com/htmldesktop.html

Please criticise or contribute.

 

[Zepos]

http://darwinist.googlepages.com/htmldesktop.html

Please criticise or contribute.

Lovely lightblue screen, but what else am I suppose to see?

Zepos

 

[darwinist]

Lovely lightblue screen, but what else am I suppose to see?

Zepos

I should have said it requires firefox or ie and with javascript turned
on.

Feel free to browse the source there is nothing malicious and it's well
commented.

 

[meow2222]

*With manual.

http://darwinist.googlepages.com/htmldesktop.html

Please criticise or contribute.

criticism of an almost blank light blue page too obvious to need
stating.

NT

 

[Number 11950 - GPEMC! Replace number with 11950]

*With manual.

http://darwinist.googlepages.com/htmldesktop.html

Please criticise or contribute.

Ditch the client-side code. Most of your visitors don't even know you, and
have no reason to trust you to run unquarantined/unscanned code on their
computers. If you want to do something interesting, use SSI, CSS, HTML 4.01
Strict DTD, and if all else fails there are always server-side CGI scripts -
then it does not matter if your visitor puts you on the Restricted Sites
list, the page still displays as intended.
For example, take the web-menus and fixed branding at:
www.fieldcraft.biz

Never mind the atrocious green colour scheme. It works as intended in Gecko,
Opera, & IE - and runs no client side code as seen in other menu systems -
and because it all runs in the basis of overlapping formats, it loads and
functions faster than anything you could hack out with JavaScript or .NET -
All this and it validates as well, so one can reasonably hope (but not
reasonably assume) that future user agents won't deviate so far as to effect
the look and feel of the page display.

Are you selling something? Something the marketing meat-heads who think that
well-formed XHTML vs conformable HTML makes a scrap of difference to the
visitor don't understand; is that the people who spend money online are
those who know the security ropes - and who don't allow web-sites to run the
sort of code that could just as easily install spyware to go fishing for
bank account numbers and passwords. The luddites won't spend a dime because
they are too lazy to learn anything more than the high cost of foolishness.
If you want the online spenders to buy from you, let the established, known,
trusted third-party merchant provider run the client-side code and you
concentrate on making the website equally accessibly to those who do not
take unnecessary risks while browsing. Most importantly, forget impressing
the luddites who want to be dazzled by Hollywood because that ain't where
the money is, unless you are making movies instead of web pages!

Just my two cents. I hope you find it useful in some way...

 

[darwinist]

Ditch the client-side code. Most of your visitors don't even know you, and
have no reason to trust you to run unquarantined/unscanned code on their
computers.

If it is allowed to do anything malicious it is clearly a poor
javascript implementation, and therefore the browser's fault. Most
people surf the web with js turned on these days, as far as I can tell.

If you want to do something interesting, use SSI, CSS, HTML 4.01
Strict DTD, and if all else fails there are always server-side CGI scripts -
then it does not matter if your visitor puts you on the Restricted Sites
list, the page still displays as intended.
For example, take the web-menus and fixed branding at:
www.fieldcraft.biz

Wow that is fast.

Never mind the atrocious green colour scheme. It works as intended in Gecko,
Opera, & IE - and runs no client side code as seen in other menu systems -
and because it all runs in the basis of overlapping formats, it loads and
functions faster than anything you could hack out with JavaScript or .NET -
All this and it validates as well, so one can reasonably hope (but not
reasonably assume) that future user agents won't deviate so far as to effect
the look and feel of the page display.

Are you selling something?

Just the idea that a web-based desktop is easy to make, and its time
has come. It's a free idea.

Something the marketing meat-heads who think that
well-formed XHTML vs conformable HTML makes a scrap of difference to the
visitor don't understand; is that the people who spend money online are
those who know the security ropes - and who don't allow web-sites to run the
sort of code that could just as easily install spyware to go fishing for
bank account numbers and passwords. The luddites won't spend a dime because
they are too lazy to learn anything more than the high cost of foolishness.
If you want the online spenders to buy from you,

If I wanted online spenders to buy from me I would probably just use
paypal or something, and let them take care of the security.

let the established, known,
trusted third-party merchant provider run the client-side code and you
concentrate on making the website equally accessibly to those who do not
take unnecessary risks while browsing.

Merchants can use it however they want, it's less than 800 lines
including liberal comments.

I reject the idea that we should code under the assumption that
javascript is insecure. It's the browsers job to make it secure and
some of them do a damn fine job of it.

Most importantly, forget impressing
the luddites who want to be dazzled by Hollywood because that ain't where
the money is, unless you are making movies instead of web pages!

Just my two cents. I hope you find it useful in some way...

I don't know anyone who turns off javascript by default. I'll take your
word for it they exist.

I'm not sure if you could do a dynamic windowing system without
javascript. But I appreciate that some things are better done with css,
which I don't understand very well at the present. I may steal some
ideas from that website you referred me to. Thank you.

 

[darwinist]

criticism of an almost blank light blue page too obvious to need
stating.

Ha I suppose you would say the same thing of any command-shell. You are
funny.

It has a few core (and working) gui features and a command box with a
manual of the system's api.

Criticism of judging an ide based on its minimalism and colour is too
obvious to need stating (except perhaps in your case)

I'm sorry if you think my software is ugly, what do you suggest?

 

[Jack]

If it is allowed to do anything malicious it is clearly a poor
javascript implementation, and therefore the browser's fault. Most
people surf the web with js turned on these days, as far as I can
tell.

Any implementation that isn't provably correct is probably incorrect.
That includes essentially all implementations of Javascript.

Anyway, the problem with Javascript isn't that it's insecure - the
problem is that it's a general-purpose programming language.

A bug in a piece of general application software (such as a script-free
browser) is much less likely to expose an exploit than a bug in the
implementation of a GP programming language. And because Javascript
programs generally give no indication that they are about to launch, or
that they are still running, they pose an even more insidious threat
than a piece of warez or dodgy shareware that the user downloads and
runs deliberately.

Consequently malicious coders flock to Javascript exploits like flies to
shit.

 

[meow2222]

Ha I suppose you would say the same thing of any command-shell. You are
funny.

It has a few core (and working) gui features and a command box with a
manual of the system's api.

Criticism of judging an ide based on its minimalism and colour is too
obvious to need stating (except perhaps in your case)

I'm sorry if you think my software is ugly, what do you suggest?

Maybe you misunderstood. Your link simply leads to a practically blank
webpage, which for practicality scores 1/10


NT

 

[arachnid]

I don't know anyone who turns off javascript by default. I'll take your
word for it they exist.

They do. FireFox has a number of very popular extensions to disable javascript by
default and only enable it for selected sites (look up "NoScript"). Some
people disable javascript for security reasons, others because it cuts way
down on obnoxious advertising gimmicks, flashing banner ads, popups, etc.,
and speeds up page downloads.

 

[Number 11950 - GPEMC! Replace number with 11950]

They do. FireFox has a number of very popular extensions to disable javascript by
default and only enable it for selected sites (look up "NoScript"). Some
people disable javascript for security reasons, others because it cuts way
down on obnoxious advertising gimmicks, flashing banner ads, popups, etc.,
and speeds up page downloads.

At the risk of making everyone here barf in unison - I sell a product
specifically designed to make it easier for IE users to disable all
client-side code except for sites they first white-list.

www.fieldcraft.biz/software/browser-security

Rightly or wrongly, this has kept the script kiddies, and their "spyware"
and other worms out of my systems for years - and that is what counts.

To change the subject before I loose my lunch ;^) special effects are for
high-budget blockbuster movies - and not for public organisational
documentation. The key is NOT to impress the luddites who can't buy online
because their computers are crawling with bugs because they turn on
everything for the promise of yet another "amazing" special effect. No!
Instead, the aim is to reach the serious and cautious visitors who actually
do spend real hard currency online from time to time - thus justifying the
bandwidth consumed by visitors. If you are trying to change the world and
thus your goals are political rather than economic, then the last thing you
want is to make some of your mentally less stable visitors want to wrap
their heads in aluminium foil every time they wind up on your site, because
these are the ones that will put the most effort into counteracting your
message if you give them any reason to feel threatened by you... ...and
when client-side scripts such as Java are flagged, there is every reason to
feel suspicious, and suspicion translates to threat with just a few brief
little thoughts...

Any of you ever done a business plan? Me neither! (well not properly if my
consultant has anything to say about it!) However, if you can just hold on a
moment more without woofin' yer woofies: doing a business plan is all about
asking your idea to, "Show me the money!" A business plan is a good way to
find out if and how an idea will actually contribute where it counts or if
the idea will be yet another black hole for time and money...

OK, everyone. Breath deeply & drink lots of water...

 

[darwinist]

Maybe you misunderstood. Your link simply leads to a practically blank
webpage, which for practicality scores 1/10

Well if that's how you judge things. It demonstrates various javascript
funtionality, the source is well commented and free, and it has a brief
manual (the first link, titled "help"). I don't know what else you were
looking for, given the title of the OP.

 

[darwinist]

Any implementation that isn't provably correct is probably incorrect.
That includes essentially all implementations of Javascript.

Anyway, the problem with Javascript isn't that it's insecure - the
problem is that it's a general-purpose programming language.

A bug in a piece of general application software (such as a script-free
browser) is much less likely to expose an exploit than a bug in the
implementation of a GP programming language. And because Javascript
programs generally give no indication that they are about to launch, or
that they are still running, they pose an even more insidious threat
than a piece of warez or dodgy shareware that the user downloads and
runs deliberately.

Consequently malicious coders flock to Javascript exploits like flies to
shit.

Sandboxed code isn't a pipe-dream, it's just that microsoft get trigger
happy with features and ignore security. Use firefox, it's not perfect
but nothing is.

 

[darwinist]

At the risk of making everyone here barf in unison - I sell a product
specifically designed to make it easier for IE users to disable all
client-side code except for sites they first white-list.

www.fieldcraft.biz/software/browser-security

It's a pity that javascript has been implement so poorly and so people
have become afraid of it. There is nothing wrong with manipulating
client objects with script, and it can add a lot of convenience to a
web page, although I admit most people don't know how to use it and a
lot of people use it for ads.

 

[Number 11950 - GPEMC! Replace number with 11950]

It's a pity that javascript has been implement so poorly and so people
have become afraid of it. There is nothing wrong with manipulating
client objects with script, and it can add a lot of convenience to a
web page, although I admit most people don't know how to use it and a
lot of people use it for ads.

[SNIP]

I agree with you, it is a pity that a few mess it up for the rest of us -
although I think you are perhaps too kind in your description of the sort of
implementations that have scared people off.

I think that a possible solution to the client-side problem is to set a
security standard for remote code that dictates apps written in
security-compliant languages simply canNOT:

1. Trigger apps not written in an equally security-compliant language
2. Access or overwrite any files not actually created by the app itself
3. Run in the background without obvious visual display
4. Receive any input whatsoever while they do not have the focus
5. Open any forms that are not children of the app's main MDI form
6. Access any hardware other than through the OS's API
7. Operate from raw uncompiled source.

This would fix the client-side problem as far as malicious code goes.

In reality, the lack of security compliance as applied to scripting
languages brings us back to constraining the presentation of web content to
forms that can be trusted if only because they are simply not capable of
being used for mischief. And yes, this is a shame...

 

[darwinist]

It's a pity that javascript has been implement so poorly and so people
have become afraid of it. There is nothing wrong with manipulating
client objects with script, and it can add a lot of convenience to a
web page, although I admit most people don't know how to use it and a
lot of people use it for ads.

[SNIP]

I agree with you, it is a pity that a few mess it up for the rest of us -
although I think you are perhaps too kind in your description of the sort of
implementations that have scared people off.

I think that a possible solution to the client-side problem is to set a
security standard for remote code that dictates apps written in
security-compliant languages simply canNOT:

1. Trigger apps not written in an equally security-compliant language
2. Access or overwrite any files not actually created by the app itself
3. Run in the background without obvious visual display
4. Receive any input whatsoever while they do not have the focus
5. Open any forms that are not children of the app's main MDI form
6. Access any hardware other than through the OS's API
7. Operate from raw uncompiled source.

This would fix the client-side problem as far as malicious code goes.

I'm pretty sure that web-browser javascript shouldn't be allowed to do
any of these things with standard security settings (no special activex
controls, for example), with a couple of exceptions: 5 i agree with but
i don't think is actually defined and 7, what do you mean?

In reality, the lack of security compliance as applied to scripting
languages brings us back to constraining the presentation of web content to
forms that can be trusted if only because they are simply not capable of
being used for mischief. And yes, this is a shame...

Damn straight. The web browser has sneakily become the most installed
and installable application platform. All that's holding it back is

 

[Richard Cornford]

(e-mail address removed) wrote:

Anyway, the problem with Javascript isn't that it's insecure
- the problem is that it's a general-purpose programming
language.

Javascript is not a general-purpose programming language, as if evident
form its lake of IO (particularly for user interaction and files). It is
a general- purpose scripting language, for scripting object models
provided by a host. Every thing that has ever been done with javascript
that has been a security/privacy issue has been done through a facility
provided by the host's object model. With by far the worst offender
being the IE object model allowing scripts to instantiate and then
interact with ActiveX objects.

A bug in a piece of general application software (such as a
script-free browser) is much less likely to expose an exploit
than a bug in the implementation of a GP programming language.

Maybe, but a bug in a javascript implementation is unlikely to be a
genuine security issue, just because javascript as such cannot do much
that is harmful. While bugs (and design errors) in the object models
exposed for scripting by web browsers are inevitably problematic.

And because Javascript programs generally give no indication
that they are about to launch, or that they are still running,
they pose an even more insidious threat than a piece of warez
or dodgy shareware that the user downloads and runs deliberately.

I am not user that is reasonable. If someone is operating a browser with
javascript enabled and they load a web page they can expect any
javascript it contains to be executed.

Consequently malicious coders flock to Javascript exploits like
flies to shit.

Malicious coders certainly do use javascript do attempt what is
malicious, but they are not actually exploiting javascript when they do
that, they are exploiting the object model exposed by the browser. If a
browser exposed nothing but the W3C (HTML and Core) DOM(s) and common
pre-DOM features of the window object then there would be nothing
javascript could do that would harm the user's system (it could still
annoy them with flashing adverts and the like but that is about it).

While disabling javascript will prevent any exploitable aspects of a
browsers object model from being exploited by scripts on web pages, for
IE users disabling the scripting of ActiveX, including ActiveX 'marked
safe for scripting', in the Internet security zone is an action that
will seriously reduce the potential for external scripts to do harm.

Richard.

 

[Number 11950 - GPEMC! Replace number with 11950]

[SNIP]

Damn straight. The web browser has sneakily become the most installed
and installable application platform. All that's holding it back is
people trying to own it <cough>microsoft</cough>, but they will learn
eventually.

I've lots to say about UA developers who ignore international mark-up
standards and in some cases go out of their way to disrupt the standard by
depriving web developer of unified code, and the user of features that do
not depend on interoperability bloat. There are more than one and I am not
naming any names. They know who they are, and interestingly, so too does
everyone-else.

Suffice it to say that successfully coding around these morons is supremely
satisfying. While I am at it, I am yet to see a compliant UA. If I float a
div and set the height, the height is ignored in spite of the fact that the
CSS specification says nothing about this exception to the rule that a div
will be of the height set - unless I've misread the specs...? So failing
this simple compliance test, we see... ...everyone. Have I misread the
spec or is everyone just copying everyone-else???

 

[darwinist]

[SNIP]

Damn straight. The web browser has sneakily become the most installed
and installable application platform. All that's holding it back is
people trying to own it <cough>microsoft</cough>, but they will learn
eventually.

I've lots to say about UA developers who ignore international mark-up
standards and in some cases go out of their way to disrupt the standard by
depriving web developer of unified code, and the user of features that do
not depend on interoperability bloat. There are more than one and I am not
naming any names. They know who they are, and interestingly, so too does
everyone-else.

Suffice it to say that successfully coding around these morons is supremely
satisfying. While I am at it, I am yet to see a compliant UA. If I float a
div and set the height, the height is ignored in spite of the fact that the
CSS specification says nothing about this exception to the rule that a div
will be of the height set - unless I've misread the specs...? So failing
this simple compliance test, we see... ...everyone. Have I misread the
spec or is everyone just copying everyone-else???

The default overflow of a div is visible, so if you want its height to
be respected, set its overflow style property to something else.

 

[meow2222]

Well if that's how you judge things. It demonstrates various javascript
funtionality, the source is well commented and free, and it has a brief
manual (the first link, titled "help"). I don't know what else you were
looking for, given the title of the OP.

I cant make sense of your reply, a blank web page doesnt demonstrate
anything. It has no function at all.


NT