Since Firefox restarted the browser wars innovations have been pouring in, and it appears the next generation or browsers will be no exception. While most of the new features in Microsoft’s upcoming Internet Explorer 8 focus on usability and performance, a couple of security enhancements have leaked into the limelight.
The major announcement so far is IE8’s “Safety Filter” which builds upon the existing Phishing Filter. To recap the Phishing Filter uses a local white list and a server-side blacklist to check websites in real-time for the possibility that they’re trying to defraud the user. In IE8 this is being expanded to look for malicious code attempting to take control of the users’ computer.
Alright, let's think about filtering the Internet logically from AT&T’s perspective. It's easy to say the idea sucks, especially if one fears that he will be filtered or have his privacy invaded. The real question, though, is does this even make sense for AT&T?
First off, there is the real issue behind this debate: bandwidth. The current collection of American internet service providers simply does not have the bandwidth it promises to customers. This varies, but one major regional ISP gave the factor of 2MB of bandwidth per month per customer. Perhaps that was more true ten years ago, but the current generation of consumers use much more than that. For every few grandmothers who check their email once a weekend, there is someone else consuming GB's of data each month eschewing the graph. But the fact remains – the contract a consumer signs says (for example) 8Mb/s is the speed cap; nothing is stated about limiting how much one can download or how often he can utilize that cap. In theory one could use that all day, every day.
Having used Linux solely for nearly four years now, I've gained a respect for what Linux can and can't do. By no means is it the perfect solution for every problem, but there are some misconceptions heard again and again that I plan to set straight.
1. Linux is Behind the Times
One comment heard often is “Linux was five years behind XP, and it's 10 years behind Vista!” Well, here are some facts:
And Linux isn't slowing down. The Xen project has added an incredible level of virtualization to Linux, with more work going into the kernels development to add enterprise ready virtualization built-in [4]. Microsoft promised built-in Xen-like virtualization in Windows Server 2008 next year, but has announced that feature has been delayed and should be available sometime after launch [1], possibly in SP1, meaning Linux will lead with built-in virtualization by at least a couple of years before Windows catches up.
Unfortunately the web server died last weekend, and most this week was spent finalizing repairs and restoring things. This means it's been awhile since part two of this series, so some of the more minor details have been forgotten. Because of this I'll be making part three more about customization and debating the licensing for the site. But I will talk about some interesting issues new admins might want to know of in advance, such as issues with Apache, PHP, and Drupal's default .htaccess file.
So with the basic framework in place it was time to start getting core functionality returned, after all a site's worthless if you can't post content. Likewise I had to start making decisions regarding older data made before we got the new server as well as solve some interesting issues regarding Drupal's new flagship release.
To begin I must discuss my personal philosophy with third party modules. Due to the fluid nature of software, especially third party stuff, some projects will eventually be abandoned, that's just how it goes. I'm sure some of the modules that work for 4.6/4.7 will never be ported to work with Drupal 5. Because of this I'm very careful with what modules I use. With the major exception of the Image module, which gives me my galleries, I generally don't use modules that would break parts of the site if I had to abandon them. I normally go for ones which work behind the scenes, ones I could live without on a moments notice. Going along with this thinking, I also take into account that modules add code, which adds attack surface that isn't scanned by as many eyes as the core code or the main Drupal developers, and it's entirely possible the authors of these modules have never coded with security in mind a day in their lives. Because of this, again I aim for modules which normal users don't have direct interaction with. My goal is to make available awesome functionality, but functionality that's “just there”, stuff that people may not even realize they're using. That said my choice in modules can mainly be lumped into two groups, security and “back end magic”.