Where I work, they handle like 300 million users [...]
Hmm, where have I heard that number before...? Oh, right, that's just about exactly the current population of the US!
So, you say these are your "users" ?
[...] and have data associated with each user.
Ok, well, I don't think I'm going to sue you, and I really don't care who you work for, but I do think I'm going to go find my tinfoil hat RIGHT NOW...!
They may be running on the same server but it is still middleware processing business logic.
Right...but that wasn't my point at all. I wasn't disputing that "middleware" is involved (although I must say I disagree with the broadness of the second definition of the term in Wikipedia). I was instead suggesting that it was misleading to imply that the example included Java middleware under a PHP presentation layer. They've got a Java presentation tier with a Java business tier and a database back end. They've also got a PHP presentation tier with a (trivial) PHP business tier and the same database back end.
So, the Java business tier (what you are calling middleware) is only bridging between the Java presentation tier and the database; it has nothing to do with the PHP components. The PHP business tier is interacting only with the PHP presentation tier and the database; it does not interact in any way with Java. If anything, it is the database itself (and--to a much lesser extent--the HTTP server) that bridges PHP and Java in this example.
If you RTFA it isn't talking about JSP. It is about using Java in the middleware (WebSphere) and PHP in the presentation layer (Apache).
With all due respect, this is quite incorrect. If you re-RTFA carefully, you'll see:
The example consists of a Struts application deployed on WebSphere Application Server V5.1, which serves as the private content management tool for entering information by the Catabase team. A PHP 5 public site will display the content and enable users to search for animals based on their attributes. The database shared by both components is DB2 UDB Enterprise Server Edition Version 8.2. The Web server instance for both portions is Apache 1.3.
So yes, basically they have a Struts part (hosted by WebSphere acting only as a J2EE Web Container) for the "internal" web site, and a PHP part for the "external" web site. The only things shared are the HTTP server (which invokes the PHP or Struts modules) and the database (which is read by PHP and read/written by Struts).
I don't understand. Viruses are simply programs that run in an O/S that we don't want running. How can an O/S know the difference between an application I just compiled and some virus?
Well, as a start, your app doesn't attempt to keep itself persistent and/or hidden, and it doesn't access resources (memory, files, etc.) for which it doesn't have privileges. These are all detectable and/or (ideally) preventable by the OS (and in fact only by the OS). Even the best virus scanner needs help from the OS to do its job. Is it easy for the OS to detect this? It depends on the overall security architecture of the OS; it could either be trivial or impossible.
Oh, and let's not forget that when a file named foo.zip is clicked, if anything other than [Pk|win|other]zip.exe gets launched, that's a virus. Again detectable and preventable by the OS. (By the way, I can't imagine a more hideous way to determine the type of a file than by its [hidden-by-default!] filename extension. If you wanted an example of a poor security design decision, there it sits.)
Don't get me wrong. I think the SPREADING of viruses should be stopped. But I think that falls into the internet connection. Adding a REAL firewall, and fixing IE. But I don't think it's the O/S's fault.
I don't think I "get you wrong" but I highly disagree with these points as well. If I, as a user click a ".zip" or ".doc" file and an email gets sent, that should have been stopped well before the firewall (unless I have explicitly allowed it and/or checked the ubiquitous "don't ask me about this again"). An OS could (and should, IMO) enforce that the network resources shouldn't be accessible due to clicking on either of those files. If a firewall is the last line of defense to prevent the outbound port TCP/25 connection in this case, the OS has failed.
It's all about deception. The bad app either needs help from the OS (e.g. to hide its true filename extension) or needs to exploit the OS (e.g. to hide itself or bypass privileges). Sure I expect any app to be potentially "harmful" to my machine. However I (should!) expect the OS not to be a co-conspirator.
An ill-behaved app might blow away my "My Documents" but I should at least have known that I was explicitly launching an app (not unzipping an archive or reading an email) and it shouldn't affect files of any other users, and certainly not affect the OS itself.
It is how the market works, when you are on top people focus on your vulnerabilities in order to bring you down.
This brings up a quote FTFA:
And "do you really want to have your security issues discussed by the Linux developer community on a public bulletin board," queries Alistair Baker of Microsoft UK.
Well, yes, that's exactly what I want. Private discussions are much more likely to degenerate for a number of reasons (Groupthink being a major contributor). In all likelihood, the people with the best solutions are not invited into the private discussions. There is also a certain degree of arrogance inherent to such discussions ("we are the only ones smart enough to have found this security hole").
Public discussion promotes a much wider sampling of views, opinions, and advice. Of course, some of these will be useless and/or counter-productive. That doesn't imply the process of public discussion itself is not superior; the positives generally far outweigh the negatives.
So I say again, YES, Mr. Microsoft Man, I would indeed prefer this approach.
Slashdot Mirror
Hmm, where have I heard that number before...? Oh, right, that's just about exactly the current population of the US!
So, you say these are your "users" ?
[...] and have data associated with each user.
Ok, well, I don't think I'm going to sue you, and I really don't care who you work for, but I do think I'm going to go find my tinfoil hat RIGHT NOW...!
Right...but that wasn't my point at all. I wasn't disputing that "middleware" is involved (although I must say I disagree with the broadness of the second definition of the term in Wikipedia). I was instead suggesting that it was misleading to imply that the example included Java middleware under a PHP presentation layer. They've got a Java presentation tier with a Java business tier and a database back end. They've also got a PHP presentation tier with a (trivial) PHP business tier and the same database back end.
So, the Java business tier (what you are calling middleware) is only bridging between the Java presentation tier and the database; it has nothing to do with the PHP components. The PHP business tier is interacting only with the PHP presentation tier and the database; it does not interact in any way with Java. If anything, it is the database itself (and--to a much lesser extent--the HTTP server) that bridges PHP and Java in this example.
With all due respect, this is quite incorrect. If you re-RTFA carefully, you'll see:
So yes, basically they have a Struts part (hosted by WebSphere acting only as a J2EE Web Container) for the "internal" web site, and a PHP part for the "external" web site. The only things shared are the HTTP server (which invokes the PHP or Struts modules) and the database (which is read by PHP and read/written by Struts).
There is no "middleware" to speak of here.
Well, as a start, your app doesn't attempt to keep itself persistent and/or hidden, and it doesn't access resources (memory, files, etc.) for which it doesn't have privileges. These are all detectable and/or (ideally) preventable by the OS (and in fact only by the OS). Even the best virus scanner needs help from the OS to do its job. Is it easy for the OS to detect this? It depends on the overall security architecture of the OS; it could either be trivial or impossible.
Oh, and let's not forget that when a file named foo.zip is clicked, if anything other than [Pk|win|other]zip.exe gets launched, that's a virus. Again detectable and preventable by the OS. (By the way, I can't imagine a more hideous way to determine the type of a file than by its [hidden-by-default!] filename extension. If you wanted an example of a poor security design decision, there it sits.)
Don't get me wrong. I think the SPREADING of viruses should be stopped. But I think that falls into the internet connection. Adding a REAL firewall, and fixing IE. But I don't think it's the O/S's fault.
I don't think I "get you wrong" but I highly disagree with these points as well. If I, as a user click a ".zip" or ".doc" file and an email gets sent, that should have been stopped well before the firewall (unless I have explicitly allowed it and/or checked the ubiquitous "don't ask me about this again"). An OS could (and should, IMO) enforce that the network resources shouldn't be accessible due to clicking on either of those files. If a firewall is the last line of defense to prevent the outbound port TCP/25 connection in this case, the OS has failed.
It's all about deception. The bad app either needs help from the OS (e.g. to hide its true filename extension) or needs to exploit the OS (e.g. to hide itself or bypass privileges). Sure I expect any app to be potentially "harmful" to my machine. However I (should!) expect the OS not to be a co-conspirator.
An ill-behaved app might blow away my "My Documents" but I should at least have known that I was explicitly launching an app (not unzipping an archive or reading an email) and it shouldn't affect files of any other users, and certainly not affect the OS itself.
Must that "office" dude in the first vid!
This brings up a quote FTFA:
Well, yes, that's exactly what I want. Private discussions are much more likely to degenerate for a number of reasons (Groupthink being a major contributor). In all likelihood, the people with the best solutions are not invited into the private discussions. There is also a certain degree of arrogance inherent to such discussions ("we are the only ones smart enough to have found this security hole").
Public discussion promotes a much wider sampling of views, opinions, and advice. Of course, some of these will be useless and/or counter-productive. That doesn't imply the process of public discussion itself is not superior; the positives generally far outweigh the negatives.
So I say again, YES, Mr. Microsoft Man, I would indeed prefer this approach.