At first I thought you meant.js libraries that the user couldn't see by telling the browser to view the source.
I see your point, thanks for the education. My main point is that Javascript is primarily a browser (e.g., client-side) extension. Server-side JS was not part of the original JS technology.
Any serious web applications are probably not going to be written in server-side JS. I doubt that any web servers other than Netscape's Enterprise Server actually supports interpreting JS on the server side.
Re:This is one of the features of Java
on
Decompiling Java
·
· Score: 2, Insightful
As systems get more open/advanced, the sources are more difficult to hide. In case of web apps, there is no need to decompile anything, the javascripts are available for all to see in plain text. Even more advanced applications that use ASP pages...
Web applications are typically implemented server-side. Javascript is client-side code.
Javascript != web applications
Perhaps what you are referring to is the source for ASP and JSP/servlets. There have been bugs in servlet containers (specifically, I believe the issue was that the web server in front of a servlet container wasn't configured correctly, and thus instead of passing the request to the SC for handling, just retrieved the file and returned the content to the user's browser), but the code in a JSP or ASP is executed on the server before it ever reaches the client -- this means that it is not possible in the normal course of events for a client to see the "source" contents of such a server-side object.
This constraint can of course break down when web application servers are not built and/or configured correctly.
Here's an off-the-cuff guess as to the parts cost for one board (I'm sure I have most of the prices wrong):
FPGA $30
PCB $5
DAC $10
DVI transmitter $10
RAM $20
Assembly $??
Development cost $??
Profit $??
That should actually read:
Propose open-source friendly video card
Participate in discussion
??
Profit
Like one of the posters on the list said, if you can come out with an open and really good 3D implementation and platform, then people would probably flock to you. Sure, dirty dealing is part of business, but the momentum of a good product is hard to kill.
My computer isn't my hobby, it's my entertainment, and seriously, I've had zero to no problems with Windows XP.
Really? Hmmm. I've got a JPEG you'd probably like to see.
On the serious side, if it works for you, that's cool. There is a bit of a curve to switching, but it is no greater than the curve that someone has to climb when encountering a Windows-based OS for the first time.
FOSS is all about choice. If you choose to use what many in this crowd (including me) believe to be an inferior operating system, then you should be free to do so. But time will tell which is more "polished."
No time penalty is incurred during AES encryption or decryption.
That's pretty interesting. Perhaps they meant to say that there is no additional processing overhead beyond that which is introduced by performing the full number of rounds for a 256 bit key in hardware.
It seems you still need a shared secret. I assume it isn't doing any authenticated Diffie-Hellman to establish a session key.
Sorry, it's just kind of irritating when you hear things like "security through encryption." Great. You get integrity protection and data confidentialy while the data is in trasit. There are many other opportunities for an attacker to get your data besides when it's flying around in mid-air.
Our van was stolen once (we lived on Long Island) and in response, my Dad enclosed the perimeter of our property in a crotch-high wire tripalarm. He also mounted several motion-detectors that triggered lights on the outside and alarms in my parent's bedroom.
He bought the Club and installed a gas cutoff switch in the new van.
Finally, he drilled holes in the foundation of our garage (the van and its successor were too large to fit in the garage) and every night he wrapped a chain around the rear axle of the van and locked the loose ends together in the garage.
Which these sorts of tools, you need a signature to match against. Doesn't really do any good to catch Code Red sigs after patches have been applied, and only slows down traffic processing. The firewall has to stop and reassemble the packets, and then make a decision based on a-priori knowledge of that particular application-level protocol.
Sure, firewalls can catch this sort of low-hanging fruit, but how can a firewall make a useful decision about an otherwise syntactically legal piece of data that goes past it? All sorts of stuff gets tunneled over HTTP. If the firewall knows about authorization decisions and correct behavior of all the applications behind it, that's a pretty meaty firewall, and probably very prone to subversion itself.
Probably easier to create better software than to have cars that drive themselves. Your body already heals itself. If you want limb replacement, talk to genetic engineerings that want to insert whatever the heck crawfish have into us to regrow limbs.
"..these days, with the kind of plug-ins that come in your typical browser, combined with all the bizarre undocumented protocols used by new Internet applications, make it highly unlikely that a firewall is doing anything more complex than a thin layer of policy atop routing.
This pronoucement is right on the money. Firewalls are but one tool in our arsenal. <Insert relevant prose about defense in depth, yadda yadda.>
As such, the applications behind the firewall are now more critical to security than the firewall itself. Which should scare the holey moley out of you."
Firewalls were invented to essentially protect us from bad software engineering. Bad software engineering remains a problem. A good question is whether or not firewalls should be made more complex, or left as simple packet filters... there is simply no way for a firewall at the edge of a network to make intelligent decisions about application data flying past it.
We need fundamental advances in creating robust, secure, and self-recovering software.
Re:yet another worthless article about IPv6
on
An Introduction to IPv6
·
· Score: 3, Insightful
I would wager that the vast majority of people who tend to get 0wned have only 1 computer. Any house with 2, 3, or more probably has at least one person in it who knows about security.
I'll take that wager. It would be interesting to see the distribution of security experts to households with computers. Sure, some households may have folks that know enough to go to windowsupdate every couple of weeks, but I'll bet you that qualified security professionals are quite scarce, and there certainly isn't any proof that a household with 3 or 4 computers is different than a household with 1 computer in terms of the number of persons familiar with security.
I agree with you. For simple stuff, I think the 'prior art' qualification takes care of it.
As with the pharma case, it is sometimes a little ridiculous. I mean, should those compounds that have existed in nature or are 'obvious' be patentable? What about compounds that need to be synthesized by some non-obvious means, including finding ways to join the molecules that produce something that won't irritate the digestive system?
The hope is that a more capable patent evaluation system would weed out those sorts of "silly" algorithms. Adding two numbers doesn't deserve a patent. Does/did something like RSA deserve a patent? Does a particular sorting algorithm (nevermind that we have a whole host of good ones that are effectively in the public domain) deserve patent protection?
In any event, a good patent office would equate
public Date diffDate(Date x, Date y);
with "I hereby patent the ability to flip a piece of paper containing a table of days back and forth." From my (admittedly limited) experience of being involved in a patent filing, it seems that a good patent lawyer will make sure that the patent is non-trivial. The problem is all those folks (and $BIG_COMPANIES) that have enough money to spend that they can patent every brain-fart that comes along.
As far as paying money to $BIG_COMPANY, in the worst case we'll just have to wait for 20 years (conceivably much less the way the wait time is at the patent office) in order to program again.
A software implementation is a "physical" realization of an abstraction: an algorithm or collection of algorithms. To extend the previous metaphor to pharma's: the algorithm is like the formula for a particular compound, and the software implementation (of which yours is just a particular version) is like a tablet/pill that just rolls off the assembly line.
The bigger question is: should algorithms be patentable. There is probably a stronger case for patenting algorithms than there is for patenting chemical compounds...
From my perspective, Windows is meant to be dealt with via the GUI. *nix users are brought in assuming that cmd line is par for the course. Windows cmd line support is (as you point out) useful for knowledgeable admins. As a regular Windows user, I say Shell? Huh? Where do I click?. Oh, here. Ok. Great, a little black box. You mean I have to type something?
The problem is that many Windows users do not have that understanding.
Exactly. As I said, it's primarily a matter of user education: if they are initially conditioned to expect to interact with a GUI, they lose access to a rich legacy of cmd line apps (and yes, MS DOS has managed to include a good amount of equiv Unix functionality).
There is an application called fport by Foundstone that adds this capability.
And I think XP and W2k3 has the -O option (or -o, i can't remember) that allows a PID to be reported also.
Despite the existence of this utility, it is the fact that it is 'hidden'... the typical user has no way of knowing what their box is doing with reference to the net (and the new networking tab in the task manager is a start, but people have no frame of reference for what is normal).
It's really a user education problem, not a technology problem. The capabilities are (now, at least) there.
The highlight reel is nice when you have no time and want "just the facts, ma'am", but at what point do you cross over into Fahrenheit 451 and 1984 territory?
As a society, are we sure we want just soundbytes, especially when those soundbytes can be presented out of context.
No, i didn't RTFA, just speculating here. On saturday night, no less.
Better yet, just sign up for 100 accounts at gmail and do rotating automated backup to those accounts. Of course, you should also encrypt the data after compression.
Short term benefit that I can see: an up to date, complete implementation of the Java libraries. Long term, maybe RMS can tell you something about liberty.
One long term benefit that I can see would be freeing Java from Sun's eventual demise.
Let the Apache Software Foundation take it over -- they have maintained a pretty tight relationship with Sun and are a credible bunch.
Slashdot Mirror
I see your point, thanks for the education. My main point is that Javascript is primarily a browser (e.g., client-side) extension. Server-side JS was not part of the original JS technology.
Any serious web applications are probably not going to be written in server-side JS. I doubt that any web servers other than Netscape's Enterprise Server actually supports interpreting JS on the server side.
Web applications are typically implemented server-side. Javascript is client-side code.
Javascript != web applications
Perhaps what you are referring to is the source for ASP and JSP/servlets. There have been bugs in servlet containers (specifically, I believe the issue was that the web server in front of a servlet container wasn't configured correctly, and thus instead of passing the request to the SC for handling, just retrieved the file and returned the content to the user's browser), but the code in a JSP or ASP is executed on the server before it ever reaches the client -- this means that it is not possible in the normal course of events for a client to see the "source" contents of such a server-side object.
This constraint can of course break down when web application servers are not built and/or configured correctly.
Here's an off-the-cuff guess as to the parts cost for one board (I'm sure I have most of the prices wrong):
- FPGA $30
- PCB $5
- DAC $10
- DVI transmitter $10
- RAM $20
- Assembly $??
- Development cost $??
- Profit $??
That should actually read:Like one of the posters on the list said, if you can come out with an open and really good 3D implementation and platform, then people would probably flock to you. Sure, dirty dealing is part of business, but the momentum of a good product is hard to kill.
Really? Hmmm. I've got a JPEG you'd probably like to see.
On the serious side, if it works for you, that's cool. There is a bit of a curve to switching, but it is no greater than the curve that someone has to climb when encountering a Windows-based OS for the first time.
FOSS is all about choice. If you choose to use what many in this crowd (including me) believe to be an inferior operating system, then you should be free to do so. But time will tell which is more "polished."
No time penalty is incurred during AES encryption or decryption.
That's pretty interesting. Perhaps they meant to say that there is no additional processing overhead beyond that which is introduced by performing the full number of rounds for a 256 bit key in hardware.
It seems you still need a shared secret. I assume it isn't doing any authenticated Diffie-Hellman to establish a session key.
Sorry, it's just kind of irritating when you hear things like "security through encryption." Great. You get integrity protection and data confidentialy while the data is in trasit. There are many other opportunities for an attacker to get your data besides when it's flying around in mid-air.
Our van was stolen once (we lived on Long Island) and in response, my Dad enclosed the perimeter of our property in a crotch-high wire tripalarm. He also mounted several motion-detectors that triggered lights on the outside and alarms in my parent's bedroom.
He bought the Club and installed a gas cutoff switch in the new van.
Finally, he drilled holes in the foundation of our garage (the van and its successor were too large to fit in the garage) and every night he wrapped a chain around the rear axle of the van and locked the loose ends together in the garage.
Sure, firewalls can catch this sort of low-hanging fruit, but how can a firewall make a useful decision about an otherwise syntactically legal piece of data that goes past it? All sorts of stuff gets tunneled over HTTP. If the firewall knows about authorization decisions and correct behavior of all the applications behind it, that's a pretty meaty firewall, and probably very prone to subversion itself.
As such, the applications behind the firewall are now more critical to security than the firewall itself. Which should scare the holey moley out of you."
Firewalls were invented to essentially protect us from bad software engineering. Bad software engineering remains a problem. A good question is whether or not firewalls should be made more complex, or left as simple packet filters... there is simply no way for a firewall at the edge of a network to make intelligent decisions about application data flying past it.
We need fundamental advances in creating robust, secure, and self-recovering software.
I'll take that wager. It would be interesting to see the distribution of security experts to households with computers. Sure, some households may have folks that know enough to go to windowsupdate every couple of weeks, but I'll bet you that qualified security professionals are quite scarce, and there certainly isn't any proof that a household with 3 or 4 computers is different than a household with 1 computer in terms of the number of persons familiar with security.
Mom's machine, Dad's workstation, Billy's gaming machine, Suzie's laptop ...
that's what the echo command and the redirection operator are for.
But it seems to me that encoding policy in email addresses like this provides a rudimentary sort of "NAT" for emails.
http://www.tla.org/papers/spa-ndss03.pdf
As with the pharma case, it is sometimes a little ridiculous. I mean, should those compounds that have existed in nature or are 'obvious' be patentable? What about compounds that need to be synthesized by some non-obvious means, including finding ways to join the molecules that produce something that won't irritate the digestive system?
The hope is that a more capable patent evaluation system would weed out those sorts of "silly" algorithms. Adding two numbers doesn't deserve a patent. Does/did something like RSA deserve a patent? Does a particular sorting algorithm (nevermind that we have a whole host of good ones that are effectively in the public domain) deserve patent protection?
In any event, a good patent office would equate public Date diffDate(Date x, Date y); with "I hereby patent the ability to flip a piece of paper containing a table of days back and forth." From my (admittedly limited) experience of being involved in a patent filing, it seems that a good patent lawyer will make sure that the patent is non-trivial. The problem is all those folks (and $BIG_COMPANIES) that have enough money to spend that they can patent every brain-fart that comes along.
As far as paying money to $BIG_COMPANY, in the worst case we'll just have to wait for 20 years (conceivably much less the way the wait time is at the patent office) in order to program again.
A software implementation is a "physical" realization of an abstraction: an algorithm or collection of algorithms. To extend the previous metaphor to pharma's: the algorithm is like the formula for a particular compound, and the software implementation (of which yours is just a particular version) is like a tablet/pill that just rolls off the assembly line.
The bigger question is: should algorithms be patentable. There is probably a stronger case for patenting algorithms than there is for patenting chemical compounds...
From my perspective, Windows is meant to be dealt with via the GUI. *nix users are brought in assuming that cmd line is par for the course. Windows cmd line support is (as you point out) useful for knowledgeable admins. As a regular Windows user, I say Shell? Huh? Where do I click?. Oh, here. Ok. Great, a little black box. You mean I have to type something?
The problem is that many Windows users do not have that understanding.
Exactly. As I said, it's primarily a matter of user education: if they are initially conditioned to expect to interact with a GUI, they lose access to a rich legacy of cmd line apps (and yes, MS DOS has managed to include a good amount of equiv Unix functionality).
> never decides to attach itself to "System" or
> "svchost.exe", huh?
Amen. wait .. doh.
And don't ever try killing all svchost instances or your clipboard may go missing...
And I think XP and W2k3 has the -O option (or -o, i can't remember) that allows a PID to be reported also.
Despite the existence of this utility, it is the fact that it is 'hidden'
It's really a user education problem, not a technology problem. The capabilities are (now, at least) there.
The highlight reel is nice when you have no time and want "just the facts, ma'am", but at what point do you cross over into Fahrenheit 451 and 1984 territory? As a society, are we sure we want just soundbytes, especially when those soundbytes can be presented out of context. No, i didn't RTFA, just speculating here. On saturday night, no less.
ok, i'll stop.
One long term benefit that I can see would be freeing Java from Sun's eventual demise.
Let the Apache Software Foundation take it over -- they have maintained a pretty tight relationship with Sun and are a credible bunch.
http://gcn.com/vol1_no1/daily-updates/25400-1.html
"Go open source with DB2 and then you can tell me what to do with my assets," was McNealy's response to IBM
Did John Glenn go to the moon? I don't think so...
He was the first American to orbit the Earth.
But then again, I wasn't alive then, so what do I know?