Those don't sound like security professionals... I've run into people like that, they're the ones who applaud "security theatre" solutions like Vista's UAC, but I wouldn't call them "IT Security Professionals". They sound more like the mob over in QA pushing ISO9000.
If they're not willing to make Bluetooth keyboards, why would they make Wireless USB keyboards? And if they do, that will just mean you'll have Bluetooth keyboards, Wireless USB keyboards, and shitty dongles.
I wouldn't mind seeing a real console PC out there, one with hardware DRM and hardware tilt sensors and all that, so long as I don't have to buy one and pay for all that extra hardware to make my computer less reliable and more likely to break if I install the wrong RAM or what have you. I'm concerned that they'll do that, and then make it so every PC has that stuff in it.
Compared to the appalling design decisions in Perl, things like using "+" for string concatenation are trivia. But it sounds like you're pretty sold on Perl and I suspect we'd be here a week if I started to bring those up. But let's at least get the dates right.
Again, not accurate. Perl 5 predates javascript by a number of years, 5+ in fact.
Perl5 was released late in 1994. Javascript first showed up in 1995.
I don't think that starting with a newbie Perl5, which was basically a completely new language, end embedding it in a browser using an extension module that was still in beta when Netscape released Javascript, would have been a really safe move. And that's assuming that Javascript development started after October 1994... which is a pretty short lead time.
Perl is right out. Other than the fact that it's a horrid language, It's not designed for embedding, so you'd have to rip a lot of code out of it and redesign the core for security, and you wouldn't have been looking at Perl5, you'd have been looking at Perl4... you remember Perl4? And you wouldn't get any benefit from CPAN... you'd need to build a new library from scratch, one designed for the limited environment of a sandbox, and that's nothing you couldn't do with Javascript.
Languages for this purpose need to be designed with embedding and security in mind, which rules out a lot of options. Forth is highly embeddable, but you'd need a high level derivitive of it (like, say, Postscript) to satisfy the security requirements. I love Forth, and Postscript was a much-requested extension back then, but I suspect that it would have ended up with more complaints by now.
I used REXX, as AREXX on the Amiga, and it's barely better than Basic, and it's got some really amazing design flaws... such as uninitialised variables defaulting to their name as their value which was probably OK on OS/360... but sheesh.
The only existing languages that I'm familiar with that they could have realistically used were Lisp derivatives. And of those Tcl or a similarly licensed Scheme would have been the best choices.
Javascript is actually quite a nice language. The object model is an excellent one for a scripting environment, much better than a formal class based structure. The syntax is straightforward. I would love a command line Javascript with a good built-in string library for the things I use awk/sh/perl/tclsh for now.
It's really going to depend on what the company's doing.
When I was the system/network admin at my last-but-one job, we had at various times between 150 and 400 developers, but they weren't expected to do IT work, they were expected to write code for production and shipping products. Most of the time I was the only "IT" person on the development network. All in all over teh 20 years I was there we never had more than a dozen full time "IT" people, 2-3 handling the administration network, 1-2 on the development network, and the rest on the test floor handling setup and shipping of production systems.
On the other hand, at some companies (such as wall-street trading and video production companies) you may have a 1:1 IT/non-IT ratio, with each trader or artist having a full time dedicated support guy.
Without knowing more about what the company in question does, I can't say whether 1:7 is high or low.
It's block rather than record oriented, but this seems similar to how classic Palm OS worked. In the Handspring Visor, which had directly addressable flash memory, this was used to execute code directly out of flash.
I had to force myself to finish the first volume. It read like a "swiss family robinson" renaissance-punk alternate history, with "Mary Sue" characters that would have seemed unlikely even in 1632 fanfic.
There are perfectly good scripting languages Netscape could have chosen to embedd which are both standard and considerably more suitable for non-trivial use.
I'm curious. What scripting languages are you thinking of. The open embeddable scripting languages that I can think of that were available then (the ones I was familiar with, back in the mid '90s) are things like REXX, Tcl, Forth, and *ostscript.
Given the speed of adoption of Wireless USB... if it takes another year for Bluetooth 3.0 (or whatever they call the higher speed post-2.1 version) you'd still be better off waiting than having to start shuffling two incompatible short-range wireless standards.
Who cares if allowing sites to sign their own certificates makes the whole SSL thing extremely pointless?
Except it doesn't, any more than the lack of a revenue structure for the likes of Verisign makes SSH pointless. If an unsigned certificate *changes*, then that should raise red flags, but just using an unsigned certificate? That shouldn't do more than warn you that you're visiting a site using an unsigned certificate and offer to add it to your keychain.
I haven't ever seen a "wireless USB" product in stores, so why should I care about "Wireless USB" when Bluetooth already provides a wireless equivalent of USB?
The only GUI library you have is AWT, which is best not described
In this situation, you wouldn't call any native Java GUI library. The "GUI" would be HTML, modified by modifying the page's DOM through Javascript hooks.
Personally, I prefer Javascript to Java for what Javascript was designed for.
The problem is not a shortcoming in Javascript, it's the use of Javascript in ways it was never intended.
It already exists in Firefox, with the use of XUL + XPCOM + XBL.
XUL's scripting language is ECMAscript, though, yesno?
The point of this is to have a plugin that implements a sandboxed programming language that is richer than ECMAscript and acts as the controller for the HTML+ECMAscript view in the browser.
You could of course implement such a thing in a library called from XUL, but then that library is the component addressed here, and XUL is merely an implementation mechanism. And a browser-dependent one.
Oh, and XUL is not really "what ActiveX was promised to be", because what ActiveX was promised to be can not be implemented. Even if you call it Silverlight and/or Moonlight. This is a good thing.
Instead of squid, use tinyproxy. You're not primarily interested in caching, you're interested in access control. Tinyproxy gives you much finer control of that, and it's also... well... tiny.
Just set up a "no proxy" rule for the sites you want them to get to, and redirect everything else to a 404 server.
I've never tried it, but there's "com.sun.java.browser.dom", which is supposed to let your applet access the browser's Document Object Model. In keeping with the applet security model, there are limits on what can be done to the DOM; I think access is read-only, although the documentation isn't clear.
Of course if it's readonly, there's no point to it.:(
Java itself would be a good alternative to JavaScript. At least it scales up better. But Sun insists on burying the language under a mountain of mediocre and ever-changing libraries.
Microsoft seems to be doing the same thing with.NET.
I think there's some intention that Android will address the problem of poor Java libraries, but unfortunately that will also be tied to a platform.
Slashdot Mirror
like being strip-searched by a clown.
I thought the TSA had a patent on that.
So what does "IA" stand for?
Those don't sound like security professionals... I've run into people like that, they're the ones who applaud "security theatre" solutions like Vista's UAC, but I wouldn't call them "IT Security Professionals". They sound more like the mob over in QA pushing ISO9000.
Well, hell, that's most of the market.
If they're not willing to make Bluetooth keyboards, why would they make Wireless USB keyboards? And if they do, that will just mean you'll have Bluetooth keyboards, Wireless USB keyboards, and shitty dongles.
I wouldn't mind seeing a real console PC out there, one with hardware DRM and hardware tilt sensors and all that, so long as I don't have to buy one and pay for all that extra hardware to make my computer less reliable and more likely to break if I install the wrong RAM or what have you. I'm concerned that they'll do that, and then make it so every PC has that stuff in it.
Compared to the appalling design decisions in Perl, things like using "+" for string concatenation are trivia. But it sounds like you're pretty sold on Perl and I suspect we'd be here a week if I started to bring those up. But let's at least get the dates right.
Again, not accurate. Perl 5 predates javascript by a number of years, 5+ in fact.
Perl5 was released late in 1994.
Javascript first showed up in 1995.
I don't think that starting with a newbie Perl5, which was basically a completely new language, end embedding it in a browser using an extension module that was still in beta when Netscape released Javascript, would have been a really safe move. And that's assuming that Javascript development started after October 1994... which is a pretty short lead time.
No.
No more than you'd be required to release the source code of a program you'd compiled with GCC.
Perl is right out. Other than the fact that it's a horrid language, It's not designed for embedding, so you'd have to rip a lot of code out of it and redesign the core for security, and you wouldn't have been looking at Perl5, you'd have been looking at Perl4... you remember Perl4? And you wouldn't get any benefit from CPAN... you'd need to build a new library from scratch, one designed for the limited environment of a sandbox, and that's nothing you couldn't do with Javascript.
Languages for this purpose need to be designed with embedding and security in mind, which rules out a lot of options. Forth is highly embeddable, but you'd need a high level derivitive of it (like, say, Postscript) to satisfy the security requirements. I love Forth, and Postscript was a much-requested extension back then, but I suspect that it would have ended up with more complaints by now.
I used REXX, as AREXX on the Amiga, and it's barely better than Basic, and it's got some really amazing design flaws... such as uninitialised variables defaulting to their name as their value which was probably OK on OS/360 ... but sheesh.
The only existing languages that I'm familiar with that they could have realistically used were Lisp derivatives. And of those Tcl or a similarly licensed Scheme would have been the best choices.
Javascript is actually quite a nice language. The object model is an excellent one for a scripting environment, much better than a formal class based structure. The syntax is straightforward. I would love a command line Javascript with a good built-in string library for the things I use awk/sh/perl/tclsh for now.
It's really going to depend on what the company's doing.
When I was the system/network admin at my last-but-one job, we had at various times between 150 and 400 developers, but they weren't expected to do IT work, they were expected to write code for production and shipping products. Most of the time I was the only "IT" person on the development network. All in all over teh 20 years I was there we never had more than a dozen full time "IT" people, 2-3 handling the administration network, 1-2 on the development network, and the rest on the test floor handling setup and shipping of production systems.
On the other hand, at some companies (such as wall-street trading and video production companies) you may have a 1:1 IT/non-IT ratio, with each trader or artist having a full time dedicated support guy.
Without knowing more about what the company in question does, I can't say whether 1:7 is high or low.
It's block rather than record oriented, but this seems similar to how classic Palm OS worked. In the Handspring Visor, which had directly addressable flash memory, this was used to execute code directly out of flash.
I had to force myself to finish the first volume. It read like a "swiss family robinson" renaissance-punk alternate history, with "Mary Sue" characters that would have seemed unlikely even in 1632 fanfic.
There are perfectly good scripting languages Netscape could have chosen to embedd which are both standard and considerably more suitable for non-trivial use.
I'm curious. What scripting languages are you thinking of. The open embeddable scripting languages that I can think of that were available then (the ones I was familiar with, back in the mid '90s) are things like REXX, Tcl, Forth, and *ostscript.
Redirecting to a host in the ".aspx" domain. :)
Given the speed of adoption of Wireless USB... if it takes another year for Bluetooth 3.0 (or whatever they call the higher speed post-2.1 version) you'd still be better off waiting than having to start shuffling two incompatible short-range wireless standards.
Who cares if allowing sites to sign their own certificates makes the whole SSL thing extremely pointless?
Except it doesn't, any more than the lack of a revenue structure for the likes of Verisign makes SSH pointless. If an unsigned certificate *changes*, then that should raise red flags, but just using an unsigned certificate? That shouldn't do more than warn you that you're visiting a site using an unsigned certificate and offer to add it to your keychain.
(yes, I know it's a different standard)
I haven't ever seen a "wireless USB" product in stores, so why should I care about "Wireless USB" when Bluetooth already provides a wireless equivalent of USB?
I gotta stop sniffin' glue first thing in the morning.
Yes, I mean without the quotes.
Running lots of Linux instances in VMs is pretty mainstream.
If these predictions are correct, there must be a lot of planetary heat being stored away somewhere
According to my A/C power bill, I've got more than my fair share this year. Cheers!
The only GUI library you have is AWT, which is best not described
In this situation, you wouldn't call any native Java GUI library. The "GUI" would be HTML, modified by modifying the page's DOM through Javascript hooks.
Personally, I prefer Javascript to Java for what Javascript was designed for.
The problem is not a shortcoming in Javascript, it's the use of Javascript in ways it was never intended.
It already exists in Firefox, with the use of XUL + XPCOM + XBL.
XUL's scripting language is ECMAscript, though, yesno?
The point of this is to have a plugin that implements a sandboxed programming language that is richer than ECMAscript and acts as the controller for the HTML+ECMAscript view in the browser.
You could of course implement such a thing in a library called from XUL, but then that library is the component addressed here, and XUL is merely an implementation mechanism. And a browser-dependent one.
Oh, and XUL is not really "what ActiveX was promised to be", because what ActiveX was promised to be can not be implemented. Even if you call it Silverlight and/or Moonlight. This is a good thing.
Man would I love to install Linux in a virtual machine. I'll bet it could fly.
Google for "penguin farm ibm".
Instead of squid, use tinyproxy. You're not primarily interested in caching, you're interested in access control. Tinyproxy gives you much finer control of that, and it's also ... well ... tiny.
Just set up a "no proxy" rule for the sites you want them to get to, and redirect everything else to a 404 server.
I've never tried it, but there's "com.sun.java.browser.dom", which is supposed to let your applet access the browser's Document Object Model. In keeping with the applet security model, there are limits on what can be done to the DOM; I think access is read-only, although the documentation isn't clear.
Of course if it's readonly, there's no point to it. :(
Java itself would be a good alternative to JavaScript. At least it scales up better. But Sun insists on burying the language under a mountain of mediocre and ever-changing libraries.
Microsoft seems to be doing the same thing with .NET.
I think there's some intention that Android will address the problem of poor Java libraries, but unfortunately that will also be tied to a platform.