This review is great, I'm glad we have a source like Ars Technica to provide counterbalance to all the vapid and superficial product reviews we usually find elsewhere; Siracusa goes in-depth on every topic from the UI to the filesystem to the new Core APIs and Objective-C 2.0. I agree on just about every point, particularly his comment about Apple's need to eventually supplement OS X with a first-class managed code language and runtime:
I'm sure there are Mac developers reading this that don't see any problem at all, in 2010 or otherwise. I could go off on another tangent about how programmers always seem to think the language they're currently using provides exactly the right amount of abstraction for the task at hand, with anything less dynamic being considered barbaric, and anything more dynamic seen as crazy and unsafe, but I'll spare you and save it for a blog post.
(As much as I love working and programming on the Mac, seeing how nice.NET is really gives me concern for the long-term future of Apple's platform.)
On the other hand, if you're not interested in all this technical mumbo-jumbo and only wanted to catch a glimpse of the new intro movie, here it is.
This isn't about snatching domain names from previous owners. It's about improper use of search records from the whois databases, using this information to automatically grab new, currently unregistered domains when other people check the domain names' registration status.
Yeah, Font Book on my OS X 10.4 machines didn't like it either. I assume mere Windows compatibility, rather than complete OpenType standards compliance, was the design goal for Microsoft here.
I guess I'm one of those folks who has sort of been living under a rock with respect to Vista: I actually thought these new fonts were only available through Office 2007. I guess it's cool that they're being included in Vista too, but whether or not it's appropriate to think of them as actual replacements for their Web Core versions depends entirely on their license. If the new fonts cannot be freely used in OS X, Linux, and BSD as the other fonts are, I think most clueful web developers (and even not-so-clueful ones like myself) would be hesitant to base their designs on an entirely new set of fonts which are only sure to be installed on one particular operating system, for a marginal improvement in font quality.
Yeah, Candara looks pretty nice, at least on an LCD where rendered with Microsoft's... peculiar anti-aliasing technique. It's still nowhere near as nice as Slimbach's Adobe Myriad, particularly when printed out on paper or displayed using an accurate, non-pixel aligned rendering engine like FreeType or OS X, on the other hand.
These new fonts will be pretty nice to have around, presuming the license is liberal enough to allow distribution with OS X and other Unix-like systems. Otherwise, they won't be much more than a subpixel-rendered footnote in web development.
For one thing, Apache's FastCGI module is notoriously flaky and poorly documented. In the past, Apache users typically employed mod_php, mod_python, etc., and as a result mod_fastcgi has historically received second-class treatment by developers. There's a reason so many people are turning to lighttpd for their FastCGI applications even though Apache 2 offers its own multithreaded MPM, and performance is only part of the equation...
How much our hypothetical audiophile has in his bank account doesn't change the fact that he just wasted $7,000 on something of which he could have obtained the functional equivalent for less than $5 a foot at the hardware store.
You're right of course, SELinux is a lot more complex to initially configure than a simple chroot. The "complexity" I was referring to was the additional administrative complexity of managing system changes and software updates down the road when you have multiple copies of your system libraries and executables living in various chroot jails, which is best done with specialized software like ezjail or something from your own personal script toolbox. On the other hand, you might wind up having to tweak a couple SELinux policies down the road as well...
It's not a matter of trusting or not trusting your server's software. It's a matter of saying, "OK, I realize that like all software, this program has the potential to be exploited someday. It would be best exercise foresight, configuring the system so that the damage will be minimized should an attacker take over this daemon."
One way to minimize the potential for such damage is to limit server processes' access to a minimal subset of the file system. This way if my OpenVPN server is exploited, for example, the attacker wouldn't be able to extract the list of valid usernames from/etc/passwd, because/etc/passwd isn't accessible from within the chroot jail. More importantly, the attacker also wouldn't have access to any number of setuid system software which, while not at all necessary in the normal chrooted operation of OpenVPN, might provide the grounds for privilege escalation, turning the attacker's possession of a single limited user account into ownership of the entire system. And vice versa, the attacker cannot escape the chroot jail without becoming root to begin with. The only "obscurity" about it is your apparent lack of understanding of what chroot() really does on modern BSD and Linux systems.
Of course by your reasoning, you wouldn't run server daemons under limited user accounts to begin with. After all, if you can't trust the software to run as root, then why the heck would you trust it to run on the system at all?
In my opinion, FreeBSD jails stand too far to the right of the line between the simple chroot and all-out virtualization to be terribly useful for things like protecting a system against exploits of your MTA or your basic web server. It's just so much overhead... unless the jail mechanism has changed since the last time I tried it, you even have to set up separate IP addresses for each jail. I think a more appropriate comparison would be between FreeBSD jails and Linux-Vserver.
OpenBSD's and Linux's chroot()s can be used to augment filesystem security, provided that you realize they're useless if the jailed process is running as root (or if it runs in fertile grounds for privilege escalation). I use OpenBSD's chroot in this capacity on my home router, for isolation of my OpenVPN and BIND server daemons. Just don't run as root and keep your chroot directories free of any setuid binaries with the potential for exploit, and you should be golden.
On the other hand, both FreeBSD jails and regular Unix chroots are inelegant and bear unnecessary complexity when contrasted with the mandatory access control approach of SELinux. It does take some effort to set up properly, but once you've fine-tuned your SELinux policy you can share the same root directory and all the same libraries and configuration files between your server's daemons, yet have the kernel restrict each daemon's behavior down to the granularity of individual files and network sockets, entirely independently of Linux's built-in discretionary access control mechanisms. Once the Distribution Gods figure out the art of simple MAC policy management (and it seems to me that Red Hat is getting close), I think we'll begin to look at *nix server security in a whole new light.
I think that this was once (or may currently be) the case with bind and various MTA's. Standard practice for many daemons now is to start as root and fork as another non-privileged user, but not every daemon has this option.
Any good sysadmin knows not to rely on a chroot jail to contain a process running as root. And if your MTA has to run as root, then it's a problem with the design of the MTA, not with the chroot mechanism. (If your MTA insists on running with root privileges, I highly recommend switching to Postfix if possible.)
Chroot is an excellent tool. But as with all security devices, it's up to the administrator to know precisely what it can and cannot do, rather than relying on it blindly. That's sort of what sysadmins are paid for.
From a technical perspective, cross-site scripting (XSS) vulnerabilities isn't exactly a new thing. Nor are they isolated to Gmail.
From what I gather about this exploit (and contrary to what the CNET article has to say about it) this is actually a cross-site reference forgery (CSRF) attack rather than XSS. The attack takes advantage of the fact that a malicious Web site's clients may have persistent GMail cookies in their web browsers: The attacking site directs the victim's web browser, (possibly, but not necessarily) using JavaScript, to make a POST request to GMail which creates a mail filter to copy all messages to an email address under the attacker's control. No JavaScript needs to be injected into GMail itself, so I don't really think it counts as XSS; in fact, the attacker never sees the actual session cookie or recovers the account password. Still, this is a huge threat, especially considering that so many people have their (Facebook|MySpace|AIM|whatever) accounts set up to send their password to their GMail accounts in case the password is "forgotten".
You're absolutely correct in stating that this isn't strictly a GMail problem, but rather a fundamental problem with using the Web as an application platform. In fact, I'd argue that CSRF attacks are an even more deeply rooted and difficult to deal with problem than any type of XSS. My friends might think I'm outdated, but this is why I still use fetchmail and mutt to grab my GMail messages by POP, staying logged out of the GMail web site as much as possible.
Real value is power--the ability to control other people (aka labor). Whether the medium is gold coins or paper money or tootsie pops, what you are trading when you exchange money is labor. No, you're not. What you're exchanging is an item of value. Labor is important in the initial creation of a product but it is not the only significant "cost" of a product. Rarity, longevity, storage requirements, transportation requirements and usefulness are all valuable towards the price of a product. Labor, while important, doesn't account for value alone.
Yes, you are. Storage and transportation requirements affect the cost of a product because they have an impact on the amount of labor required to produce it. The cost of the fuel and vehicles used in transportation, in turn, corresponds to the cost of the labor used to produce these utilities. Rarity, longevity, and usefulness affect the value of a product and, according to the rules of supply and demand, help set what a producer can reasonably charge for the product of his labor; however, it's important to understand that in the end it's still labor what is being paid for, whenever money is used to create something. These properties just affect the value of that labor. You don't pay a wage to raw materials.
Paper money can be printed at will, tootsie pops can be manufactured by the billions. Only gold has the rare aspects of its composition and rarity that make it valuable as a store of value.
And gold can be dug up from the earth, enriching people involved in an activity which does not directly benefit the rest of society. My contention is that the quality of a monetary system can be judged by its lack of incentives for economic "leaches". With the gold standard you have gold miners for leaches; with the current system you have the Federal Reserve. Neither is ideal.
Paper money is a scam.
Our current system is arguably a scam, but don't confuse paper money with the issue of the Federal Reserve. The problem is not with the idea of monetary policy, just with who controls it: hand control of the money supply over to the government and taxpayers no longer have to pay interest into the pockets of a third party. And (for the sake of argument) if economists suddenly turned their backs on so many years of thought and evidence and decided that a fixed money supply was a good thing, then we could have the government hold the supply of money constant for all the benefits of using a gold standard, without the wasted effort on gold mining.
Gold is an arbitrary choice for a monetary standard and, like any other natural resource, leads to the misdirection of labor to the detriment of the entire society. Conflating the ideas of using a fixed money supply and using gold as a monetary standard - not to mention desiring a return to a fixed money supply to begin with - betray a naive understanding of economic theory.
You misread my post. Point releases of Python are generally backwards compatible, aside from a few minor differences which aren't an issue for most programs. All I was saying is that, should you find yourself in one of those edge cases where it is necessary to run your program under a specific older version of Python, it's generally easy to do so.
Huh. One of the things that really attracted me to Python was the (perceived) quality of the Web documentation. The Python Tutorial and Python Reference Manual are very complete and provide an excellent high-level overview of the language, something which can be rather difficult to come across in, for example, the land of Perl. Granted, the Library Reference could be stronger, but I can still usually find what I need in there; and if not, it's easy enough to invoke dir() and view the __doc__ string on any objects of interest from Python's command line.
I guess it's just a matter of personal taste. But for what it's worth, I found it much easer to pick up Python without resorting to any third-party books or reference materials than to start fresh with either Ruby or Perl.
You'd typically install multiple versions of python on the same machine. On Unix-like systems each Python version's executable will be named in the manner of python2.4, python2.5, and so on, with a symbolic link from/path/python to (usually) the newest version. Scripts can call for a specific version of Python by starting with a hash-bang line like #!/usr/bin/env python2.5.
Many operating systems facilitate this scheme by offering independent packages for different versions of Python. In particular, on Debian Etch the user can choose to install any of the python2.3, python2.4, and python2.5 packages, then use update-alternatives(8) to switch the system default between the three.
This isn't directed entirely at you, but I do find these "I don't trust Windows Update" type comments quite ridiculous. So you trust Microsoft to write your computer's entire operating system, but you're afraid that a patch might contain something nefarious? Granted, software updates may accidentally break things from time to time (this is true on OS X and even Linux as well as on Windows), but if your concern is that Microsoft may try to install something "evil" on your computer - too late, you're already running their closed-source operating system; the damage, if any, is done.
If you're that concerned about it, install BSD or Linux instead. In any event, do everyone a favor and keep up with the latest security updates on whichever operating system you run.
I had a roommate once who refused to install Microsoft's Windows 2000 patches on his laptop, right up until my NIDS discovered his computer attempting to propagate the Zotob worm. Oops. He installs software updates now.
[vim is] lightweight, fast and userfriendly Absolutely. Especially with respect to vim and other vi descendants, people seem quick to confuse user-friendliness and newbie-friendliness. vim is not newbie-friendly, because learning it entails covering a lot of ground (in a sense, learning a new form of touch typing). But once you've taken the plunge and really learned how to use it, nothing else comes close to vim's efficiency and power.
Also, I don't believe that the promotion of binary blob kernel drivers is a worthwhile goal to begin with. According to certain interpretations of the GPL, Linux drivers are supposed to be GPL-licensed themselves. Not to mention that if something's going to be running on my computer at the kernel level, I damn well want to have its source code anyway...
Not having used Windows for a while, can someone clarify what the consequences of a WGA "invalidation" would be? Once invalidated, is there a straightforward way to revalidate a Windows installation?
Granted, if you have absolutely no idea what you're doing then it'll probably be easier to click away at a GUI until you come up with a working (albeit possibly not correct, or possibly insecure) configuration, than to hack one out of a text file. But if you have no idea what you're doing, you shouldn't be setting up a public-facing Web site to begin with.
Text files make configuration much easier for the skilled administrator. No hunting through obscure menus needed; if you want to find out how to implement a feature, you just search the man page. Copying or backing up your configuration is no more convoluted than copying a file. Real administrators tend to demand text based configuration, hence IIS 7.
Slashdot Mirror
This review is great, I'm glad we have a source like Ars Technica to provide counterbalance to all the vapid and superficial product reviews we usually find elsewhere; Siracusa goes in-depth on every topic from the UI to the filesystem to the new Core APIs and Objective-C 2.0. I agree on just about every point, particularly his comment about Apple's need to eventually supplement OS X with a first-class managed code language and runtime:
(As much as I love working and programming on the Mac, seeing how nice .NET is really gives me concern for the long-term future of Apple's platform.)
On the other hand, if you're not interested in all this technical mumbo-jumbo and only wanted to catch a glimpse of the new intro movie, here it is.
This isn't about snatching domain names from previous owners. It's about improper use of search records from the whois databases, using this information to automatically grab new, currently unregistered domains when other people check the domain names' registration status.
Yeah, Font Book on my OS X 10.4 machines didn't like it either. I assume mere Windows compatibility, rather than complete OpenType standards compliance, was the design goal for Microsoft here.
I guess I'm one of those folks who has sort of been living under a rock with respect to Vista: I actually thought these new fonts were only available through Office 2007. I guess it's cool that they're being included in Vista too, but whether or not it's appropriate to think of them as actual replacements for their Web Core versions depends entirely on their license. If the new fonts cannot be freely used in OS X, Linux, and BSD as the other fonts are, I think most clueful web developers (and even not-so-clueful ones like myself) would be hesitant to base their designs on an entirely new set of fonts which are only sure to be installed on one particular operating system, for a marginal improvement in font quality.
Yeah, Candara looks pretty nice, at least on an LCD where rendered with Microsoft's... peculiar anti-aliasing technique. It's still nowhere near as nice as Slimbach's Adobe Myriad, particularly when printed out on paper or displayed using an accurate, non-pixel aligned rendering engine like FreeType or OS X, on the other hand.
These new fonts will be pretty nice to have around, presuming the license is liberal enough to allow distribution with OS X and other Unix-like systems. Otherwise, they won't be much more than a subpixel-rendered footnote in web development.
For one thing, Apache's FastCGI module is notoriously flaky and poorly documented. In the past, Apache users typically employed mod_php, mod_python, etc., and as a result mod_fastcgi has historically received second-class treatment by developers. There's a reason so many people are turning to lighttpd for their FastCGI applications even though Apache 2 offers its own multithreaded MPM, and performance is only part of the equation...
Dangit, should have previewed... cross out that "per foot" part and you'll get my drift.
How much our hypothetical audiophile has in his bank account doesn't change the fact that he just wasted $7,000 on something of which he could have obtained the functional equivalent for less than $5 a foot at the hardware store.
Citation?
You're right of course, SELinux is a lot more complex to initially configure than a simple chroot. The "complexity" I was referring to was the additional administrative complexity of managing system changes and software updates down the road when you have multiple copies of your system libraries and executables living in various chroot jails, which is best done with specialized software like ezjail or something from your own personal script toolbox. On the other hand, you might wind up having to tweak a couple SELinux policies down the road as well...
What in the Hell are you talking about?
It's not a matter of trusting or not trusting your server's software. It's a matter of saying, "OK, I realize that like all software, this program has the potential to be exploited someday. It would be best exercise foresight, configuring the system so that the damage will be minimized should an attacker take over this daemon."
One way to minimize the potential for such damage is to limit server processes' access to a minimal subset of the file system. This way if my OpenVPN server is exploited, for example, the attacker wouldn't be able to extract the list of valid usernames from /etc/passwd, because /etc/passwd isn't accessible from within the chroot jail. More importantly, the attacker also wouldn't have access to any number of setuid system software which, while not at all necessary in the normal chrooted operation of OpenVPN, might provide the grounds for privilege escalation, turning the attacker's possession of a single limited user account into ownership of the entire system. And vice versa, the attacker cannot escape the chroot jail without becoming root to begin with. The only "obscurity" about it is your apparent lack of understanding of what chroot() really does on modern BSD and Linux systems.
Of course by your reasoning, you wouldn't run server daemons under limited user accounts to begin with. After all, if you can't trust the software to run as root, then why the heck would you trust it to run on the system at all?
In my opinion, FreeBSD jails stand too far to the right of the line between the simple chroot and all-out virtualization to be terribly useful for things like protecting a system against exploits of your MTA or your basic web server. It's just so much overhead... unless the jail mechanism has changed since the last time I tried it, you even have to set up separate IP addresses for each jail. I think a more appropriate comparison would be between FreeBSD jails and Linux-Vserver.
OpenBSD's and Linux's chroot()s can be used to augment filesystem security, provided that you realize they're useless if the jailed process is running as root (or if it runs in fertile grounds for privilege escalation). I use OpenBSD's chroot in this capacity on my home router, for isolation of my OpenVPN and BIND server daemons. Just don't run as root and keep your chroot directories free of any setuid binaries with the potential for exploit, and you should be golden.
On the other hand, both FreeBSD jails and regular Unix chroots are inelegant and bear unnecessary complexity when contrasted with the mandatory access control approach of SELinux. It does take some effort to set up properly, but once you've fine-tuned your SELinux policy you can share the same root directory and all the same libraries and configuration files between your server's daemons, yet have the kernel restrict each daemon's behavior down to the granularity of individual files and network sockets, entirely independently of Linux's built-in discretionary access control mechanisms. Once the Distribution Gods figure out the art of simple MAC policy management (and it seems to me that Red Hat is getting close), I think we'll begin to look at *nix server security in a whole new light.
Any good sysadmin knows not to rely on a chroot jail to contain a process running as root. And if your MTA has to run as root, then it's a problem with the design of the MTA, not with the chroot mechanism. (If your MTA insists on running with root privileges, I highly recommend switching to Postfix if possible.)
Chroot is an excellent tool. But as with all security devices, it's up to the administrator to know precisely what it can and cannot do, rather than relying on it blindly. That's sort of what sysadmins are paid for.
From what I gather about this exploit (and contrary to what the CNET article has to say about it) this is actually a cross-site reference forgery (CSRF) attack rather than XSS. The attack takes advantage of the fact that a malicious Web site's clients may have persistent GMail cookies in their web browsers: The attacking site directs the victim's web browser, (possibly, but not necessarily) using JavaScript, to make a POST request to GMail which creates a mail filter to copy all messages to an email address under the attacker's control. No JavaScript needs to be injected into GMail itself, so I don't really think it counts as XSS; in fact, the attacker never sees the actual session cookie or recovers the account password. Still, this is a huge threat, especially considering that so many people have their (Facebook|MySpace|AIM|whatever) accounts set up to send their password to their GMail accounts in case the password is "forgotten".
If this is how the attack works, then Firefox's NoScript extension should protect you as long as you don't have the attacking web site whitelisted, even if the CSRF POST vector isn't JavaScript based.
You're absolutely correct in stating that this isn't strictly a GMail problem, but rather a fundamental problem with using the Web as an application platform. In fact, I'd argue that CSRF attacks are an even more deeply rooted and difficult to deal with problem than any type of XSS. My friends might think I'm outdated, but this is why I still use fetchmail and mutt to grab my GMail messages by POP, staying logged out of the GMail web site as much as possible.
Yes, you are. Storage and transportation requirements affect the cost of a product because they have an impact on the amount of labor required to produce it. The cost of the fuel and vehicles used in transportation, in turn, corresponds to the cost of the labor used to produce these utilities. Rarity, longevity, and usefulness affect the value of a product and, according to the rules of supply and demand, help set what a producer can reasonably charge for the product of his labor; however, it's important to understand that in the end it's still labor what is being paid for, whenever money is used to create something. These properties just affect the value of that labor. You don't pay a wage to raw materials.
Paper money can be printed at will, tootsie pops can be manufactured by the billions. Only gold has the rare aspects of its composition and rarity that make it valuable as a store of value.And gold can be dug up from the earth, enriching people involved in an activity which does not directly benefit the rest of society. My contention is that the quality of a monetary system can be judged by its lack of incentives for economic "leaches". With the gold standard you have gold miners for leaches; with the current system you have the Federal Reserve. Neither is ideal.
Paper money is a scam.Our current system is arguably a scam, but don't confuse paper money with the issue of the Federal Reserve. The problem is not with the idea of monetary policy, just with who controls it: hand control of the money supply over to the government and taxpayers no longer have to pay interest into the pockets of a third party. And (for the sake of argument) if economists suddenly turned their backs on so many years of thought and evidence and decided that a fixed money supply was a good thing, then we could have the government hold the supply of money constant for all the benefits of using a gold standard, without the wasted effort on gold mining.
Gold is an arbitrary choice for a monetary standard and, like any other natural resource, leads to the misdirection of labor to the detriment of the entire society. Conflating the ideas of using a fixed money supply and using gold as a monetary standard - not to mention desiring a return to a fixed money supply to begin with - betray a naive understanding of economic theory.
You misread my post. Point releases of Python are generally backwards compatible, aside from a few minor differences which aren't an issue for most programs. All I was saying is that, should you find yourself in one of those edge cases where it is necessary to run your program under a specific older version of Python, it's generally easy to do so.
Huh. One of the things that really attracted me to Python was the (perceived) quality of the Web documentation. The Python Tutorial and Python Reference Manual are very complete and provide an excellent high-level overview of the language, something which can be rather difficult to come across in, for example, the land of Perl. Granted, the Library Reference could be stronger, but I can still usually find what I need in there; and if not, it's easy enough to invoke dir() and view the __doc__ string on any objects of interest from Python's command line.
I guess it's just a matter of personal taste. But for what it's worth, I found it much easer to pick up Python without resorting to any third-party books or reference materials than to start fresh with either Ruby or Perl.
You'd typically install multiple versions of python on the same machine. On Unix-like systems each Python version's executable will be named in the manner of python2.4, python2.5, and so on, with a symbolic link from /path/python to (usually) the newest version. Scripts can call for a specific version of Python by starting with a hash-bang line like #!/usr/bin/env python2.5.
Many operating systems facilitate this scheme by offering independent packages for different versions of Python. In particular, on Debian Etch the user can choose to install any of the python2.3, python2.4, and python2.5 packages, then use update-alternatives(8) to switch the system default between the three.
Then he simply needs to deselect all but the -security repositories for his version of Ubuntu. Works fine for me.
This isn't directed entirely at you, but I do find these "I don't trust Windows Update" type comments quite ridiculous. So you trust Microsoft to write your computer's entire operating system, but you're afraid that a patch might contain something nefarious? Granted, software updates may accidentally break things from time to time (this is true on OS X and even Linux as well as on Windows), but if your concern is that Microsoft may try to install something "evil" on your computer - too late, you're already running their closed-source operating system; the damage, if any, is done.
If you're that concerned about it, install BSD or Linux instead. In any event, do everyone a favor and keep up with the latest security updates on whichever operating system you run.
I had a roommate once who refused to install Microsoft's Windows 2000 patches on his laptop, right up until my NIDS discovered his computer attempting to propagate the Zotob worm. Oops. He installs software updates now.
Also, I don't believe that the promotion of binary blob kernel drivers is a worthwhile goal to begin with. According to certain interpretations of the GPL, Linux drivers are supposed to be GPL-licensed themselves. Not to mention that if something's going to be running on my computer at the kernel level, I damn well want to have its source code anyway...
In short: it's a feature, not a bug.
You're fooling yourself if you think that any version of Windows is more user-friendly than Ubuntu.
I just came in here to make sure someone had noticed this. Judging by the Ars forums, the present WGA problem is still very much in effect...
Not having used Windows for a while, can someone clarify what the consequences of a WGA "invalidation" would be? Once invalidated, is there a straightforward way to revalidate a Windows installation?
Granted, if you have absolutely no idea what you're doing then it'll probably be easier to click away at a GUI until you come up with a working (albeit possibly not correct, or possibly insecure) configuration, than to hack one out of a text file. But if you have no idea what you're doing, you shouldn't be setting up a public-facing Web site to begin with.
Text files make configuration much easier for the skilled administrator. No hunting through obscure menus needed; if you want to find out how to implement a feature, you just search the man page. Copying or backing up your configuration is no more convoluted than copying a file. Real administrators tend to demand text based configuration, hence IIS 7.