Slashdot Mirror

Tiger4 writes "A group of black Philadelphia police officers have filed a lawsuit against the police department and the city, alleging a hostile work environment due to a private website popular with police. Their story has received wide coverage. From CNN: 'The suit alleges white officers post on and moderate the privately operated site, Domelights.com, both on and off the job. Domelights' users "often joke about the racially offensive commentary on the site ... or will mention them in front of black police officers," thus creating "a racially hostile work environment," according to lawyers for the all-black Guardian Civic League, the lead plaintiff in the suit.' The site appears to be owned and operated by a member of the police force, but it is not funded or operated by the city. Management clearly knows it exists; it is possible police force members access it on the job, and the suit says some of them reference it on the job. Individual police force members have a right to their own opinions, but management has a responsibility to enforce the law fairly and equitably across the city and among their own workforce. What is the solution here?"

bfwebster writes "Over the last forty years, a small set of classic works on risks and pitfalls in software engineering and IT project management have been published and remained in print. The authors are well known, or should be: Gerry Weinberg, Fred Brooks, Ed Yourdon, Capers Jones, Stephen Flowers, Robert Glass, Tom DeMarco, Tim Lister, Steve McConnell, Steve Maguire, and so on. These books all focus largely on projects where actual software development is going on. A new book by Phil Simon, Why New Systems Fail, is likewise a risks-and-pitfalls book, but Simon covers largely uncharted territory for the genre: selection and implementation of enterprise-level, customizable, off-the-shelf (COTS) software packages, such as accounting systems, human resource systems, and enterprise resource planning (ERP) software. As such, Simon's book is not only useful, it is important." Read on for the rest of Bruce's thoughts on this book. Why New Systems Fail: Theory and Practice Collide author Phil Simon pages 251 publisher AuthorHouse, 2009 rating 8/10 reviewer Bruce F. Webster ISBN 9781-4389-4424-1 summary Risks and pitfalls of enterprise COTS projects Phil Simon has written a long-needed and long-overdue book. Most risks-and-pitfalls book in the IT category focus primarily on projects where actual software engineering is the principal activity. However, many of the large, expensive and often spectacular IT project failures over the past 20 years have little to do with software design and development. Instead, they involve a given organization selecting and implementing — or trying to implement — a commercial off-the-shelf (COTS) software package to replace existing legacy systems, either homegrown or also commercial. The reasons for such a move can be many: standardizing IT and data management across the enterprise, seeking new functionality, retiring systems that are no longer supported or supportable, and so on. By so doing, the firm (usually rightly) thinks to avoid the risks and expense of from-scratch custom software development. However, the firm (usually wrongly) thinks that such a project comprises nothing more than installing the software, training some users, converting some data, and turning a switch. A quick search on the terms "ERP" and "lawsuit" shows just how mistaken that idea can be.

Simon's book is far more informative and instructive than a Google search and should be required reading for all CIOs, IT project managers, and involved business managers prior to starting any such enterprise COTS project. He covers the complete lifecycle of such projects, starting with the typical expectations by upper management ("Fantasy World") and following it through system selection, implementation, and production, along with a final section on how to maximize the chances of success. Along the way, he uses several real-word case studies (with names changed), as well as a few hypothetical ones, to demonstrate just how such efforts go wrong.

What Simon writes is spot on. For roughly 15 years now, my primary professional focus has been on why IT projects fail. I do that both as a consultant (brought in to review troubled projects to get them back on track) and as a consulting or testifying expert (brought in to review troubled or failed projects now in litigation). I have reviewed hundreds of thousands of pages of project documentation and communication; I have likewise traced or reconstructed project histories for many major IT projects, including enterprise COTS projects. It's clear that Simon knows exactly what he's talking about and knows where all the bodies are buried.

The book itself is very readable. Simon's tone is conversational and a bit humorous; he occasionally dives into technicalities that would be lost on upper management, but always comes back to basic principles. The real-world and hypothetical case studies will have those of us who have been on such projects nodding our heads even as we occasionally wince or shudder. His coverage is exhaustive (and at times a bit exhausting), but his goal appears to be to give those managing and overseeing such projects the information they need to navigate the shoals. He goes into detail about COTS pitfalls such as project estimation, vendor selection, use of consultants, group responsibility, integration with legacy systems, data conversion, and report generation.

The first section of the book covers how and why firms decide to initiate a major COTS project. Besides the "Fantasy World" section that compares management expectations to what really happens, the book also covers why firms hold onto legacy systems, why they buy new (replacement) systems, and how they can (or should) make the decision among building a custom system, buying a COTS system, and "renting" enterprise software via a web-based software-as-a-service (SaaS) vendors such as Workday and Salesforce.

The second section covers COTS system selection. The book divides current ERP and COTS vendors into four different tiers based on company size and use (e.g., SAP, Oracle and BaaN are all Tier 1) and warns of the, ah, enthusiasm of vendor salespersons. (Old-but-still-timely joke: What's the difference between a used car salesman and a software salesman? The used car salesman knows how to use his own product and knows when he's lying.) The book then raises up front an issue often left (by customers) until much later: how will business processes change as a result of the COTS system we're acquiring? It then talks about selecting, if necessary, a consulting firm to help with the installation and project management.

The third section covers the actual COTS implementation process, including the overall strategy, roles and responsibilities, providing the necessary environments, data migration, testing, reports, and documentation. This section is a bit exhausting at times, but it is critical for exactly that reason: far too many firms launch into a major COTS acquisition without fully realizing just what it will take to get the system into production.

The fourth section briefly deals with life after implementation. In theory, one of the reasons a firm buys a COTS system is to avoid doing its own maintenance and support; the reality is that the firm often doesn't like paying those large annual maintenance fees and instead goes off on its own path, which is seldom a good idea.

The fifth and final section talks about how to maximize the chance of success in a large COTS implementation. This section builds upon the rest of the book, which has provided suggestions along the way. In particularly, it talks about how to deal with a troubled project mid-course in order to get it back on track.

Throughout the book, Simon puts a significant focus on human factors in project success and failure. He identifies issues such as internal politics, kingdom-building, reluctance to learn new systems, internal project sabotage, end-user resistance, and staff allocation. Simon divides firm personnel assigned to work on the COTS project into four groups — willing and able (WAA); willing but not able (WBNA); not willing but able (NWBA); and neither willing nor able (NWNA) — and talks about how each groups helps or hurts. Similarly, he identified four dangerous type of project managers: the Yes Man, the Micromanager, the Procrastinator, and the Know-It-All. Again, those of us who have been on major IT projects, particularly those involving COTS implementations, will recognize both sets of categorization and the risks they entail.

While Simon is himself a consultant, he is also quite frank about the role consultancies can play in COTS project failures. In particularly, he notes the tendency of consulting firms to underestimate project duration and cost in order to win business, as well as the frequent unwillingness to point out risks and pitfalls to the client, particularly if they represent something the client wants to do.

My few complaints with Why New Systems Fail are mostly production-related. Simon self-published the book; as such, the book's internal layout and graphic design leaves something to be desired. Likewise, his organization and prose could use a bit of editing in spots; he has a propensity for throwing in terms and abbreviations without clarification, and the technical level can vary within a given chapter. Almost all of his footnote references come from Wikipedia; his bibliography is small (just four books) and cites only Brooks from the cadre of authors listed above. None of this makes the book's content any less important or useful, but some of the very people who should be reading this book might well skip or skim it for those reasons. My understanding is that Simon is working on finding a publisher for the book, which will likely solve all those problems.

In the meantime, if you or someone you love is about to embark on an enterprise-level COTS project, get this book; I've added it to my own short-list of recommended readings in software engineering.

You can purchase Why New Systems Fail: Theory and Practice Collide from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

gehrehmee writes "A recent Canadian Press Harris-Decima poll on ISPs' use of traffic shaping suggests that 60% of survey respondents find the practice reasonable as long as customers are treated fairly, while 22% believe Internet management is unreasonable regardless. The major Canadian Internet and phone service provider Rogers, meanwhile, compared 'person-to-person file-sharing to a car that parks in one lane of a busy highway at all times of the day or night, clogging the roadways for everyone unless someone takes action.' Is there a lack of education about the long-term effects of traffic shaping on free communication? Or are net neutrality advocates just out of touch?" The poll found that only 20% of respondents had ever heard of traffic shaping. The article is unclear on whether the "60%" who found the practice "reasonable" are 60% of all respondents — most of whom don't know what they are talking about — or 60% of the minority who know. If the former, then the exact phrasing of the question is the overwhelming determinant of the response. At the CTRC hearings, which wrapped up today, Bell Canada executives revealed that the company "slows certain types of downloads [P2P] to as little as 1.5 to 3 per cent of their advertised speed during 9-1/2 hours of the day."

Slashdot contributor Bennett Haselton says "Using FTP to administer a website is insecure -- but not for the reasons that you probably think. You yourself can stop using FTP any time you want, but how do we change the landscape Net-wide, to reduce the number of breakins using stolen FTP credentials?" You know what to click on if you want to read the rest.

On July 1st I found that one of my less important websites, hosted on a low-cost shared Web hosting service, had been broken into. A friend emailed me to say that the site was showing up in Google's search results with the Google "This site may harm your computer" warning listed next to it. I found that on one of the pages, about 1,500 HTML script tags had been inserted, loading JavaScript files from pseudo-random Russian hostnames like "www.chk06.ru" and "www.errghr.ru", none of which are currently resolving. Usually, when such script tags are maliciously inserted into a page on a website, the script tags attempt to install spyware on the machines of people who visit the site.

I immediately replaced the infected file on the website with the backed-up clean copy from my machine, and changed the password on the website in case the attacker had gotten in by using the old one. (The original file with the script tags inserted is here if you want to examine it, but use with caution -- if the .ru hostnames in the script tags start resolving again, then opening the file could cause the JavaScript on the pages to be loaded, which might infect your machine.) Then I started investigating (a) how this probably happened; (b) whether future similar attacks could be prevented, by changing some defaults in the way that hosting accounts are set up; and (c) whether the incentives for hosting providers are such that these changes are likely to happen by themselves, or whether it will require some third-party advocacy to change what we think of as "best practices".

Denis Sinegubko, the webmaster of Unmask Parasites, a free service that scans websites on demand for signs of break-ins, says:

The majority of web site compromises happen because of:

1. Stolen FTP credentials. Spyware on webmasters' computers: key-loggers, traffic sniffers (FTP protocol sends username/password as plain text), trojans that steal credentials from various programs' configuration files (FTP clients, DreamWeaver, etc).
2. Security holes in popular web software: CMS (Joomla, Drupal, etc), Forums (phpBB, vBulletin, Simple Machines, etc), Blogs (WordPress). Once a vulnerability discovered, hackers configure their automated tools to search the web for websites running vulnerable versions of the software and exploit them. This can be done easily and at almost no cost when they have an army of zombie computers.
3. Security hole in "in-house" web software. Many novice (and even many experienced) web developers don't properly sanitize user input making various attacks possible (SQL injections, XSS, etc)
4. Poor security practices (Something that should be manually configured by site/server admins and cannot be fixed with automated security updates): Weak passwords, open ports, insufficiently strict permissions for limited accounts, files and directories with world write permissions, etc.

I didn't have any third-party web software or custom-made software installed on the PublicEditorMyAss.com site, the password was a seven-letter meaningless mix of letters and numbers, and I didn't have permission to change most of the things like open ports and file permissions. That left the possibility of stolen FTP credentials. This is in fact what Sinegubko says is the most common cause of such break-ins:

I guess 90% of attacks use stolen FTP credentials this year. Check this Google's graph that shows the top 10 malware sites as counted by the number of compromised web sites that referenced it:
http://googleonlinesecurity.blogspot.com/2009/06/top-10-malware-sites.html

I reviewed 4 most widespread of them (Gumblar, Martuz, Goooogleadsense, Googleanalytlcs). All four used stolen FTP credential to penetrate web sites and upload malicious content. The chances are the rest used this vector too.

When the PublicEditorMyAss.com site was set up, the default setting was for pages to be edited over FTP. Even though FTP sends and receives passwords without encrypting them (in contrast with alternatives like SFTP or "secure FTP", which encrypts passwords), for a long time I had assumed that this was not a major security problem, because in order for an attacker to intercept the passwords in transit, they would have to control a machine somewhere on the path between my home computer and the PublicEditorMyAss.com server. I figured this wasn't worth worrying about, because it was much more likely that an attacker would attempt to steal the password by installing spyware on my home computer. And if an attacker managed to do that, then I assumed that the risk of passwords being stolen by spyware was about the same whether I used FTP or SFTP -- because either way, the spyware could just steal my password by reading it out of a configuration file where the password was stored. (Even though FTP and SFTP programs both store passwords in an encrypted format, the programs have to be able to decrypt the passwords in order to use them whenever the user wants to open a connection. So the spyware could just mimic whatever steps the client programs use to decrypt the stored passwords, in order to steal one of my passwords stored in a file.) So, I assumed it made no difference whether I used FTP or SFTP.

But according to what Sinegubko told me, this reasoning was probably wrong. The problem is that even though spyware installed on your machine could read passwords that are stored in configuration files, it would be a lot of work to write a spyware program that could do this, because every FTP program and SFTP program stores passwords according to a different algorithm. It's much simpler for spyware to simply watch the traffic sent and received from your machine, so that any unencrypted passwords will be spotted:

[Passwords can be stolen by] sniffers that read all TCP traffic on local computers. Like personal firewalls but malicious. They can easily intercept FTP credentials since they are sent as a plain text.

Sinegubko describes how one of his contacts obtained evidence that a common spyware program was doing exactly this:

One of them even infected a spare WinXP computer (with Gumblar) to test the consequences. On the infected computer he created a new account in a popular FTP client and saved it. The server address was correct (his server) and the username/password pair was not valid. A few hours later in FTP logs, he discovered login attempts that used that invalid username/password pair from a Singapore IP, then from a Florida IP, the some other country's IP. Apparently the FTP credentials were somehow stolen from that infected computer.

I know of only two instances where I've ever definitely been infected with spyware. I don't do stupid things like downloading and running strange programs from third-party sites, so I think both infections were probably caused by a site exploiting a security hole in Internet Explorer, or in a plug-in like Adobe Acrobat or the Flash player. Both times, once I noticed I was infected, I got rid of the infection with Malwarebytes, but I don't know how much damage the spyware did in the meantime.

So this was a case where a little knowledge can be a dangerous thing. If I had known nothing about Internet architecture, and someone told me "FTP is less secure than SFTP," I would have found a way to switch to administering the site via SFTP. But because I knew that the main reason FTP was considered "insecure" was because it transmitted passwords unencrypted, but I also knew that most of of the machines relaying those passwords in transit were secure and trustworthy, I thought it didn't matter. Now it seems that is probably how my password got compromised after all.

In that case, why don't more people switch to administering their sites via SFTP instead of FTP? Here are the steps it took me to enable SFTP on my GoDaddy hosting account. Feel free to use this as a reference, but the obvious point is that as long as this many steps are required, it's safe to say that most users won't be switching:

1. Go to the "Hosting" menu and pick "My Hosting Account."
2. Next to the name of your website, pick "Manage Account." This will open the Hosting Control Center.
3. In Hosting Control Center, click to expand the "Settings" options.
4. In the "Settings" control panel, click the "SSH" icon.
5. You will see a page saying "SSH is not set up", and prompting you to enter a phone number so that their automated service can call you with a PIN number. After you enter your phone number, the phone rings a second later, and you enter the PIN in a form on the GoDaddy website.
6. You will then see a page which says:

   Current Hosting Account Status: Pending Account Change
   Your request to enable SSH is being processed. This upgrade may take up to 24 hours.

In fact, even if only one step were required to switch, most users probably wouldn't change from the default setting to use FTP, due to the eternal, unchangeable fact that most people do not change their default settings, ever. (What percent of users ever change the default set of toolbars that are displayed at the top of their Web browser window?)

If more Web hosting companies made SFTP the default, then the number of websites that were compromised by stolen login credentials, would probably go down. Spyware authors might start to make their programs smarter at that point, enabling them to read the passwords stored by popular FTP and SFTP programs, so that it would make no difference whether the passwords were transmitted in the clear or not. However, this would be harder for spyware authors to do correctly, so it would at least raise the bar for a successful malware attack, and the number of compromised websites would be reduced.

Unfortunately, Web hosting companies don't have much incentive to make users switch to the more secure SFTP protocol. This isn't necessarily true of all security risks; sometimes the hosting company has a strong incentive to pass on the right wisdom (and select the right default settings) for their customers. From the hosting company's point of view, you could divide risks into three categories:

• Risks where the hosting company pays a large part of the price for a customer's machine being compromised. For example, if a cyber-criminal takes over a customer's machine and uses it to launch a denial-of-service attack by sending it a flood of traffic, the hosting company will see that traffic spike on their network. The hosting company has the most incentive to help prevent these types of attacks.

• Risks where the hosting company doesn't directly pay a price for the customer's machine being compromised, but they may have to deal with complaints sent in by third parties. For example, a customer's website could get broken into, and script tags could be inserted into the pages that cause visitors' machines to be infected with spyware. Those visitors might complain to the webmaster of the infected site, or they might complain to the hosting company, which then forwards the complaint to the webmaster. The hosting company may have to provide a few minutes of tech support to the customer, advising them to change their password and scan their own machine for spyware, but they probably won't incur any other material costs.

• Risks where neither the hosting company nor the customer pays a price for the machine being infected, but the price is paid by "Internet users as a whole." The only attack that I can think of in this category, is an attack where a cyber-criminal inserts key words into your web page and links them to his site, in order to increase his Google ranking for searches for those key words. Neither the website owner, nor any visitors to the website, are victimized directly; the harm being done is that the quality of Google search results is reduced for everybody. The only reports of the attack would probably come from "good Samaritan" Web surfers, who tell the hosting company or the webmaster that one of their pages has been vandalized.

When a customer's FTP credentials are stolen, the price paid by the hosting company lies somewhere in the middle. An attacker who stole my current PublicEditorMyAss.com credentials would only be able to deface the content on the site, but they wouldn't be able to launch an attack against a third-party network (my PublicEditorMyAss.com hosting account doesn't have the ability to initiate an outgoing connection to a third-party site).

Weighing in the other direction are the costs of switching to SFTP. If existing customers are forcibly switched over, phone lines will be clogged by customers wanting to know why their old method of logging in to their site has suddenly stopped working. A better choice would be to allow existing customers to stay with FTP while making SFTP the default for new customers. But there is a time and money cost of changing anything, even a default setting.

So GoDaddy doesn't have much incentive to make SFTP their new default. Indeed, I've used many different shared hosting companies before I started running proxies exclusively on dedicated servers, and none of the shared hosting companies ever used anything but FTP as the default method for customers to administer their websites. So who can blame them? They're not making the choice that makes the most sense for their customers or for Internet security as a whole, they're making the choice that makes the most sense in terms of costs and benefits for themselves, and I'm not being judgmental about that. We shouldn't expect most companies to ever behave in any other way.

That's why I think that glib "solutions" to security problems, like "Everybody install anti-virus software", or "Everybody stop using Windows", aren't helpful, because regardless of whether these ideas would work if everybody actually followed them, the fact is that most people won't. The problems have to be addressed in terms of changing incentives for the choices people make.

What's an idea for reducing the risks of FTP credentials stolen by malware, that addresses the incentives problem? Maybe give tax breaks to Web hosting companies that set up customer accounts to use SFTP instead of FTP by default? Or ask more computer vendors to include a desktop link to pre-installed SFTP software, so that when Web hosting companies present options to their customers, it's easier for users to choose the SFTP option since they have a client already installed? (I was tempted to recommend that Microsoft include a universal SFTP client pre-installed in Windows with a prominent desktop link, but the problem with that is that if almost everybody used the same SFTP client, malware authors would have greater incentive to reverse-engineer the algorithm that the client used to store saved passwords -- and then passwords would be just as easily accessible to spyware, as if the user were using FTP all along. So a good mix of SFTP clients is safer for this purpose.)

Since the difference between SFTP and FTP usually only matters in cases where a customer's machine has been infected with malware, obviously the best solution is to avoid malware altogether, but that's much harder problem to solve, as long as malware authors can keep finding security holes in Internet Explorer and other popular programs. Making SFTP the new standard for Web hosting accounts is something that we know how to do, right now. The incentives aren't currently right for Web hosting companies to make it happen. But there may be ways to change that, and I'll bet some people can think of better ideas than the ones I've suggested. I'm just saying that the incentives problem is where attention should be focused.

theodp writes "The Federal CIO got a standing ovation for the new Federal IT Dashboard. Federal contractors got the cash. But sneak a peek at the 'customcode' directory behind the Dashboard, and you'll see that some individuals also helped bring it to life with their free software. For starters, there's Timothy Groves' Auto Suggest (Creative Commons License), Alf Magne Kalleland's Ajax Tooltip and Dynamic List (GNU Lesser General Public License), and Gregory Wild-Smith's Simple AJAX Code-Kit (SACK) (modified X11 License)."

Tisha_AH writes "The Space Shuttle has had its launch delayed for inspection after several lightning strikes to the launch tower and/or shuttle. Several different technologies have been applied by NASA to divert the strike energy to ground potentials with Air Terminals (lightning rods), surge protectors or the often-disputed use of static dissipator brushes. One technology that appears promising is to cause a lightning strike (to a safe location) through the use of short pulsed ultraviolet lasers. Maybe in the future, once the technology matures, we may find widespread use of UV lasers to protect space launch vehicles, antenna towers or buildings."

bfwebster writes "US District Court Judge Andrew Gilford (Central District of California) granted a summary judgment motion in DealerTrack v. Huber et al., finding DealerTrack's patent (US 7,181,427) — for an automated credit application processing system — invalid due to the recent In re Bilski court decision that requires a patent to either involve 'transformation' or 'a specific machine.' According to Judge Gilford's ruling, DealerTrack 'appears to concede that the claims of the '427 Patent do not meet the "transformation" prong of the Bilski test.' He then applied the 'specific machine' test and noted that, post-Bilski the Board of Patent Appeals and Interferences has ruled several times that 'claims reciting the use of general purpose processors or computers do not satisfy the [Bilski] test.' Judge Gilford analyzes the claims of the '427 patent, notes that they state that the 'machine' involved could be a 'dumb terminal' and a 'personal computer,' and then concludes: 'None of the claims of the '427 Patent require the use of a "particular machine," and the patent is thus invalid under Bilski.' DealerTrack apparently plans to appeal the ruling. Interesting times ahead."

angry tapir writes "A botnet composed of about 50,000 infected computers has been waging a war against US government Web sites and causing headaches for businesses in the US and South Korea. The attack started Saturday, and security experts have credited it with knocking the Federal Trade Commission's (FTC's) web site offline for parts of Monday and Tuesday. Several other government Web sites have also been targeted, including the Department of Transportation."

ucanlookitup writes "Microsoft has warned of a 'privately reported' vulnerability affecting IE users on XP or Windows Server 2003. The vulnerability allows remote users to execute arbitrary code with the same privileges as the users. The vulnerability is triggered when users visit a web site with malicious code. 'Security experts say criminals have been attacking the vulnerability for nearly a week. Thousands of sites have been hacked to serve up malicious software that exploits the vulnerability.' The advisory can be found at TechNet. Until Microsoft develops a patch, a workaround is available."

An anonymous reader writes "After scoring a surprise electoral win in Sweden and getting high-profile support in Germany, The Pirate Party is coming to Canada. The party's goals are fairly simple. People should have the right to share and copy music, movies and virtually any material, as long as it is for personal use, not for profit. It opposes government and corporate monitoring of Internet activities, unless as part of a criminal investigation. It also wants to phase out patents."

pmontra writes "The City of Venice, Italy, started to offer free Wi-Fi to residents (Google translation from the Italian source) on July 3 2009. Tourists and other visitors will pay 5 Euros a day for the service starting from September. The hot spots are connected to a ten thousand kilometer (6,250 mile) fiber optic LAN the City started deploying in the '90s. The first day of free Internet access has been celebrated with a digital treasure hunt in the channels of the lagoon city."

Immutate and several other readers noted that Cablevision will be allowed to go ahead with deploying a remote-storage DVR system, when the US Supreme Court declined (without comment) to hear an appeal of a lower court ruling that went against movie studios and TV networks. (We discussed this case a few months back.) "Cable TV operators won a key legal battle against Hollywood studios and television networks on Monday as the Supreme Court declined to block a new digital video recording system that could make it even easier for viewers to bypass commercials. The justices declined to hear arguments on whether Cablevision Systems Corp.'s remote-storage DVR system would violate copyright laws. That allows the... company to proceed with plans to start deploying the technology this summer."

Michael J. Ross writes "Of all the potential challengers to Apple's phenomenally popular iPhone, perhaps the one with the best prospects is Google's Android, which is not a mobile phone per se, but rather an open-source platform that the company encourages phone manufacturers to deploy in their own products. Similarly, Google encourages computer programmers to develop applications for the Android environment. But learning how to create such applications is daunting to the uninitiated, particularly for developers who have never before worked with the user interface controls, Web services, and other resources involved. A recently published book, Unlocking Android, is designed to help such developers." Read below for the rest of Michael's review. Unlocking Android author W. Frank Ableson, Charlie Collins, Robi Sen pages 416 pages publisher Manning Publications rating 8/10 reviewer Michael J. Ross ISBN 978-1933988672 summary A guide to developing applications for Google's Android. Unlocking Android was put out by Manning Publications on 28 May 2009, under the ISBN 978-1933988672. It was authored by W. Frank Ableson, Charlie Collins, and Robi Sen — all of whom have extensive experience in developing mobile software applications. The publisher's Web page makes available author biographies, descriptions of the book, all its ancillary parts (the foreword, preface, acknowledgments, table of contents, and index), a white paper on Android (oddly termed a "green paper"), and two sample chapters ("Targeting Android" and "Intents and services"). There is a link to download the source code from the Google Code site, organized by chapter. The Manning site also hosts a forum, where readers and the authors can discuss the book. As of this writing, there are 42 threads, comprising 120 messages. Lastly, the site has links to order both the print and electronic versions of the book. Note that purchasing the former automatically entitles one to a copy of the latter. Manning appears to be pioneering this approach to making e-books more readily available to customers, since every print copy now contains an insert with a list of codes that can be used to download a PDF copy of the book.

The book is ostensibly intended for Android beginners, even though it does contain enough detailed information to serve as a partial reference for more experienced developers. It is organized in a logical fashion, in three parts, starting with an overview of Android itself, both the technology and the organization behind it. Then the reader is introduced to the Android programming environment, along with its many components and capabilities. The book concludes with tutorial chapters that step the reader through creating a sample Android application and more. The material covers Android SDK 1.x. Since Android programs are written in Java, any reader fluent in that language will have a much easier time absorbing the ideas. However, the authors state that even non-Java programmers should be able to follow the examples, as long as they have knowledge of similar languages, such as C, C++, or C#. However, even a cursory glance at the code, by such a reader, would prove that Java knowledge is essential.

The first chapter — oddly named "Targeting Android" — introduces the platform, the organizations behind it, the mobile market as a whole, Android's features, how it differs from featured phones and smartphones, its open-source licenses, platform components, libraries, service managers, programming environment, and virtual terminal. Be warned that Figure 1.1 could be confusing to some readers, because it shows the layers of technology that compose the Android platform, but pictures them on the front of a mobile phone, showing a keypad, which makes the layers appear to be part of the actual user interface; the phone should be removed from the illustration, in a future edition. The chapter goes on to discuss booting and activating Android, as well as how to map applications to processes. Some readers anxious to get to the technical nitty-gritty, may become impatient when reading the first portion of this chapter, because it largely consists of introductory material. Yet this context can be helpful and interesting to people unfamiliar with the mobile phone market. (Articles and tutorials aimed at new mobile application developers, oftentimes assume that said developers are already extremely familiar with the rapidly changing mobile market.) In the later portion of the chapter, readers are shown a handful of code snippets, with some explanation as to what they are doing and how. In reading this material, the reader could be easily overwhelmed with all of the new terminology. One can only hope that the authors were not thinking that the typical reader would understand all of what is discussed, or be able to do anything with it. A canonical "Hello, world" program or something similar — with an explanation as to how to execute it — would have been a far more gentle introduction. By the way, the first few code snippets are poorly indented, and some of the method names are italicized, while others are not — with no mention as to what this might signify, either in the chapter or in the earlier "Code Conventions" section.

In Chapter 2, the reader is introduced to the key tools for basic Android development, including the SDK, Eclipse, and the Android Emulator. An example application — a tip calculator — is developed, step by step, to illustrate those tools. Clearly, this tutorial information should have been presented before the second section of the previous chapter. It nonetheless serves as a valuable introduction to programming Android. Incidentally, Figure 2.1 labels the development environment as being located on a laptop, incorrectly suggesting that desktop computers are not equally usable platforms. Later, when the authors suggest that readers add the Android SDK tools directory to their system search path, they specify only the release-independent directory (containing adb, for instance), and not the release-specific paths (containing aapt, which is the first tool discussed); readers presumably should add both. Also, the authors should specify which release to use, 1.1 or 1.5. The reader eventually is told how to run a sample application — and not a moment too soon, because at that point the reader is already 15 percent of the way into the book. To reach that point, she must wade through more introductory material than was needed, in addition to discussions of network speed and latency, command line tools, DDMS, Java packages, and other information. All of this could and should be covered later, when it would be much more meaningful, and the reader would have greater motivation to learn it, having seen an Android application running (if only in the emulator).

Part 2 forms the bulk of the book, consisting of nine chapters devoted to the essential aspects of Android application development: user interfaces, including the Activity class, views, resource types, and manifest files; Intent classes, broadcast receivers, task services, and inter-process communications; data storage and retrieval, including user preferences, files stored on the local system and on SD cards, databases, and the ContentProvider class; networking, including client/server interaction, HTTP, and Web services such as SOAP; telephony, including how to receive and initiate calls and SMS messages; notifications and alarms; generating graphics and animation; multimedia, including audio and video, utilizing the OpenCORE technology; location-based applications, using a variety of tools, including Google Earth's KML. All of these chapters make use of example applications, with annotated source code and screenshots of the applications running in the Android emulator.

The third and final part of the book comprises two chapters, each of which extends the core concepts of Android development. Chapter 12 steps the reader through the creation of a substantial application, named "Field Service Application," designed for mobile technicians who provide support services for customers of contracted clients. The application is designed to be used by both the technician and his home office to assign and manage job orders, capture customer signatures of completed jobs, order replacement parts, and receive navigation assistance. The final chapter, "Hacking Android," explores Android's utilization of Linux, the C programming language, and the SQLite database — as well as how the Android developer can access these capabilities under the hood.

Appendix A explains how to install the Eclipse integrated development environment (IDE), the Android software development kit (SDK), and the ADT plug-in for Eclipse. Readers who do not already have those components installed on their computers, may want to first read the appendix and follow the procedures. Note, however, that the procedures given in section A.4, for installing the ADT plug-in, are already out of date — namely, for Eclipse version 3.3. In addition, the URL given by the authors ("https://dl-sll.google.com/android/eclipse") is invalid, because it is missing the trailing directory slash, which is necessary for it to work within Eclipse. (This points up the importance of including root directories in URLs, despite their common absence, because even though Web browsers will automatically correct this upon receiving an error message from the server, Eclipse evidently does not.) The online Android installation instructions are much more useful, because they also include the latest version of Eclipse, 3.4.

As is to be expected with the first edition of any detailed computer programming book, this one contains some errata — for instance, in the first portion of the book alone: "Android[']s" (page xxii, twice), "Webkit" (page 7, in the caption), "SQLite[,] an" (page 11), and "byte code[s]" (page 13). Also, terms such as "Internet" and "Web" are in all-lowercase, throughout the book, even though they are proper names. (In our world of instant messaging and Twitter, grammatical degeneration continues apace.) For any reader who wishes to follow along and implement the sample projects, possibly the most disappointing decision by the authors was that of offering the sample code not as a single archive file, or even individual archive files for each of the 13 chapters. Instead, the reader must tediously click through multiple layers of directories, just to get the code displayed in a browser, one file at a time. Readers are advised to employee a Web copying utility, which, given a starting URL, will try to download all of the linked pages, recursively, and store those Web pages and other Web elements on their own computer (even localizing links, to retain working navigation in the saved pages).

Yet by far the biggest problem with this book, is that while it claims to be an introductory text, suitable for someone completely unfamiliar with Android, it does not bring the newcomer up to speed at a reasonable pace for learning. Instead, it presents a large number of code snippets and tools to the reader, without adequate explanation for the beginner to truly understand what is happening. This pattern begins even in the first chapter, which is sorely lacking a tutorial on how to execute the sample code — to better understand it and perhaps modify it (a practice that most programmers find quite valuable for assimilating a new technology). On page 23 is a frustratingly brief sidebar on testing the receipt of an SMS message, that is far from adequate for the reader anxious to begin testing out this new material. The second chapter continues this unfortunate tendency of describing tools prior to giving the reader enough information to run those tools themselves in the same manner, and see the same results. For instance, on page 41, the authors show how to use the adb tool to connect to a running emulator session, but at that point the reader has no such sessions running. (Sometimes the authors of programming books understand the material quite well, but neglect to view it from the perspective of someone who does not yet have that understanding.)

While more appropriate for intermediate Android developers than claimed, Unlocking Android contains a wealth of information to help Java programmers begin developing mobile applications for Google's new platform, with numerous code snippets and screenshots.

Michael J. Ross is a freelance Web developer and writer.

You can purchase Unlocking Android from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

A Cow writes "TorrentFreak reports that the Regional Court in Hamburg, Germany, has ruled that file-hosting service Rapidshare must proactively filter certain content. Music industry outfit GEMA asked the court to ban Rapidshare from making 5,000 tracks from its catalogue available on the Internet." Reader biabia brings an update to a related case in Italy involving four Google executives. The issue in that situation revolves around Google's response time in taking down a video that was deemed to be a privacy violation. Google is worried that a verdict against them could lead to mandatory pre-screening of all public videos that are uploaded onto their websites. Those proceedings have now been postponed until late September.
Update: 6/24 at 17:45 GMT by SS: The article originally reported that Rapidshare was fined $34 million. No such fine has been imposed — $34 million was the estimated value of the tracks hosted on Rapidshare.

CWmike writes "Google has created a Web site for developers that is focused exclusively on making Web applications, sites and browsers faster. The site will allow developers to submit ideas, suggestions and questions via a discussion forum and by using Google's Moderator tool. Google hopes developers will join it in improving core online technologies such as HTML and TCP/IP. For Google, a prime example of how Web performance can be enhanced is the development of HTML 5, which provides a major improvement in how Web applications process Javascript, Google believes. 'We're hoping the community will spend some time on the basic protocols of the Internet,' Google product manager Richard Rabbat said. 'There's quite a bit of optimization that can be done [in that area].'"

eldavojohn writes "SCO lost last year and began the bankruptcy filings a long time ago but PJ has some speculative bad news on what they retain through the bankruptcy proceedings. SCO proposes to sell a number of assets to an outfit called UnXis, which PJ characterizes this way: 'It starts to hint that this is more a renaming, taking in some new management who seem to have financial expertise, and SCO keeps skipping along as unXis, with the dangerous litigation spun off safely into a litigation troll.' In their filings SCO says they retain 'their litigation and related claims against International Business Machines Corporation, Novell, Inc., AutoZone Corporation, Red Hat and certain Linux users which are not material customers of UnXis (excluding certain large-scale users of Linux servers) that are claimed to have infringed against UNIX copyrights.' So that's still a possibility they could go after anyone who is a 'certain Linux user.' And what's even worse is that they'll retain a patent for running multiple Java applications on a single Java virtual machine. We may not be out of the SCO litigation woods yet."

Godefricus writes "Outrage ensued among Dutch techie and media websites, after a government report advised that the dwindling print media industry should be financially supported by the online industry (Google translation; Dutch original here). The idea is to help the old media fund 'innovative initiatives.' The suggested implementation of the plan is by taxing a percentage of each ISP subscription, and give the money to the papers. The report, which was solicited by the Dutch parliament and written by a committee of its members, specifically states that 'news and the gathering of news stories is not free, and the public must be made aware of that.' The report is not conclusive, but from here it's just one step toward a legislative proposal. Both industries are largely privately owned in The Netherlands, and the current government is center-left wing. Who needs an RIAA if you can build one into your government? And hey, why invest in the future if you can invest in the past?"

Skapare sends word from TorrentFreak that Norway's Simonsen law firm has lost their license to pursue file sharers. "Just days after Norway's data protection department told ISPs they must delete all personal IP address-related data three weeks after collection, it's now become safer than ever to be a file-sharer in Norway. The only law firm with a license to track pirates has just seen it expire and it won't be renewed." Skapare adds, "Sounds like Norway's government treats privacy seriously. Maybe they've been watching the abuses in the USA. More info on the Norwegian perspective in this Google translation from Dagbladet.no."

Hugh Pickens writes "Nature reports that the US military has abruptly ended an informal arrangement that allowed scientists access to data on incoming meteors from classified surveillance satellites, dealing a blow to the astronomers and planetary scientists who used the information to track space rocks. 'These systems are extremely useful,' says astronomer Peter Brown, at the University of Western Ontario. 'I think the scientific community benefited enormously.' Meteor data came from the Defense Support Program (DSP) satellite network consisting of infrared satellites in geosynchronous orbit to monitor the globe for missile launches or atmospheric nuclear blasts, forming the principal component of the United States' ballistic missile early-warning system. The satellites' effectiveness was demonstrated during Desert Storm, when DSP detected the launch of Iraqi Scud missiles and provided warning to civilian populations and coalition forces in Israel and Saudi Arabia. As a side benefit, the satellites could also precisely detect the time, position, altitude and brightness of meteors as they entered Earth's atmosphere, information the military didn't consider particularly useful, or classified. 'It was being dropped on the floor,' says former Air Force captain Brian Weeden. Although the reason for ending the arrangement remains unclear, Weeden notes that it coincides with the launch of a new generation of surveillance satellites and speculates that the Pentagon may not want details of the new satellites' capabilities to be made public, or it may simply lack the expensive software needed to handle classified and declassified data simultaneously. 'The decision may have been made that it was perhaps too difficult to disclose just these data.'"

I Don't Believe in Imaginary Property writes "With all the turmoil and internet censorship in Iran making it difficult to get an accurate picture of what's going, security researchers have found a way to locate gaps in Iran's filtering by analyzing traffic exiting Iran. The short version is that SSH, torrents and Flash are high priorities for blocking, while game protocols like WoW and Xbox traffic are being ignored, even though they also allow communication. Hopefully, this data will help people think of new ways to bypass filtering and speak freely, even though average Iranians have worse things to worry about than internet censorship, now that the reformists have been declared anti-Islamic by the Supreme Leader. Given the circumstances, that declaration has been called 'basically a death sentence' for those who continue protesting." Reader CaroKann sends in a related story at the Washington Post about an analysis of the vote totals in the Iranian election (similar to, but different from the one we discussed earlier) in which the authors say the election results have a one in two-hundred chance of being legitimate.

Political Observer writes "Jörg Tauss, a member of the German Parliament (Bundestag), left the Social Democratic Party (SPD), which is part of the coalition government, and announced that he is joining the German Pirate Party (Google translation; original German article). Tauss resigned from the SPD after all but four of the party's members voted for a new censorship law, which passed the parliament on Thursday. The law, which aims at reducing child pornography, introduces an infrastructure for DNS-based content blocking and is the subject of major criticism from Internet users. In March 2009 Tauss became the subject of investigations by the German police for possession of child pornographic material. He said he had this material only for research as part of his role as a member of parliament. Investigations are still continuing."

eldavojohn writes "Unlike a lot of community support protection programs, the EFF's Patent Busting Project is starting to bear real fruit instead of just leveling the finger at offenders. The USPTO is revoking an illegitimate patent granted in 2004 that sounds like automatically assigning subdomains. Sites like Wordpress, LiveJournal, or basically anyone with generated subdomains have been doing this for quite some time. If you have some extra cash, now's the time to pony up a few bucks so the EFF can carry on as one of the few organizations genuinely protecting your interests."

oh2 writes "The highest applicable Swedish court, Regeringsrätten, has ruled that IP numbers are protected (in Swedish) since they can be traced to individuals. This means that only government agencies are allowed to track and store IP addresses, leaving 'anti-piracy' advocates with no legal way to find possible copyright infringers." Update: 06/18 14:42 GMT by KD : The original linked article had been pulled due to factual errors and a new article has been posted (link replaced above). Here is a Google translation. The new article makes clear that the ruling does not affect the anti-piracy efforts of rights-holders.
Update: 06/18 15:08 GMT by KD : Behind the link below is a summary in English of the article sent in by the submitter, oh2.
This autumn Datainspektionen will start monitoring how the IPRED law is applied when it comes to disclosure of personal information. A recent verdict in the Regeringsrätten, Sweden's highest applicable court, has upheld Datainspektionens decision that IP addresses are to be considered personal information and therefore protected under law.

In 2005 Datainspektionen ruled that collecting and storing personal information online like copyright advocates were doing was a breach of the Swedish PUL, Personal information act, that regulates how and what kind of information that can be traced to a single individual that can be stored. The anti-piracy organizations were quickly granted an exemption though, that expired March 31st. Starting April 1st this year IPRED allows holders of copyright to apply to the courts for this information.

Datainspektionen will now monitor closely how any personal information acquired from the courts in this manner is used by copyright holders.

Butte Montana's National Folk Festival, will hold a lying contest next month. Each contestant will get a fixed amount of time to tell judges about what happened at the poker game last night, the awesome things they did in college, and how small their butts look in those pants. The winner gets a trophy, and the competition is only open to amateur liars: No lawyers, politicians, patent medicine salesmen, or motivational speakers.

hoytak writes "An expert in electoral fraud, professor Walter Melbane, has released a detailed analysis (PDF) of available data in Iran's controversial election (summary here). While he did not find significant indications of fraud, he does note that all the deviations from the predicted model are in Ahmadinejad's favor: 'In general, combining the 2005 and 2009 data conveys the impression that a substantial core of the 2009 results reflected natural political process... [These] stand in contrast to the unusual pattern in which all of the notable discrepancies between the support Ahmadinejad actually received and the support the model predicts are always negative. This pattern needs to be explained before one can have confidence that natural election processes were not supplemented with artificial manipulations.'" In related news, EsonLinji notes reports in the Seattle PI and other sources that the US State Department has asked Twitter to delay system maintenance to prevent cutting off Iranians who have been relying on the service during the post-election crisis. And if you would like to help ease the communication crunch, reader RCulpepper tips a blog post detailing how to set up a proxy server for users with Iranian IP addresses.

Michael J. Ross writes "Among the more popular and better-regarded content management systems (CMSs), Drupal is distinguished partly by its building-block approach, in which a website's functionality is built up in pieces, each of which is a module (either core or contributed). The opposite approach — using far fewer but more encompassing modules — is generally preferred by non-developers who do not relish integrating a sizable collection of modules or trying to modify the underlying code. Nonetheless, anyone who wishes to build a Drupal-based social website, can learn how to do so in a new e-book titled Drupal 6: Ultimate Community Site Guide." Read below for the rest of Michael's review. Drupal 6: Ultimate Community Site Guide author Dorien Herremans pages 140 publisher Holistic Vibes rating 7/10 reviewer Michael J. Ross ISBN 978-2839904902 summary How to create a Drupal community site using contrib modules. Published by Holistic Vibes Sàrl in 2009, the book was written by Dorien Herremans, an independent Web developer in Belgium who holds an MSc degree in MIS from the University of Antwerp, and has lectured in IT and 3D computer animation at Les Roches University of Applied Sciences, in Bluche, Switzerland. Her Drupal story is no doubt similar to that of many other Web developers: After building numerous sites in Drupal, she decided to create a new community site — in this case, Raw Vegan Dating. She was well aware that other CMSs offered fairly sophisticated modules that could be dropped into a fresh CMS installation, thereby creating a new community site instantly. But that approach generally requires one to accept the functional limitations of the chosen module, or start hacking the module's code (which for most modules is poorly written and equally poorly documented), with no guarantee that one's modifications will even work. Dorien instead opted for Drupal's flexibility, but found the development process rather difficult and time-consuming, partly because of some technical issues that arose: How can one easily create advanced profiles in Drupal? Can one add a photo gallery to each profile? Ultimately, these lead to a much broader question: Is it possible to build a feature-rich community/dating site using only core and contributed modules, without having to make any modifications to them?

Dorien set out to answer that question, in developing a new site, Drupal Fun, which is a community primarily for Drupal users who have read the book and wish to help each other. The site also offers a few tutorials on how to convert to the latest versions of modules. In making that site, Dorien utilized only available modules, with no changes, and documented each step in the process. The lessons learned from that effort form the foundation of Drupal 6: Ultimate Community Site Guide. The first three chapters constitute an introductory foundation; the next two cover user profiles; and the remaining four major chapters explain content, monetization, etc. For all topics, the Drupal Fun site is used as a case study. Even though the book focuses on Drupal version 6, and the example site is created using that version, the book does have notes on how to implement everything in version 5 as well.

In the book's introduction, the author provides a brief overview of Drupal, virtual communities, and her perspective on how to build one of the latter using the former. She states that it is easy to resort to custom modules — i.e., modules created or modified by oneself — but this contradicts one of the central tenets of the book, that a non-programmer would find it difficult if not impossible to go beyond already-available modules in building a community site (unless of course he were to outsource the development of the custom modules). In a footnote, it is incorrectly stated that "You can use the Drupal interface to write a module yourself" (page 4).

The second chapter, titled "Setting up the site," explains the desired functionality of the example site to be created (including the site's main goal, which redundantly was also presented at the end of the previous chapter). The author explains how to install Drupal on one's local Web server. A Windows-only developer may be confused by steps 2, 3, and 8, which are specific to Linux/Unix, but not labeled as such. The expression "hidden files" (page 10) would mean in Windows any files with their "hidden" attributes enabled. But in this case the author is probably referring to a single file, ".htaccess," in the Drupal root directory, because in *nix parlance a file is considered hidden if its name consists only of an extension (such a file is not shown in directory listings by default). The chapter concludes with several figures, which should have been interspersed throughout the earlier narrative.

Any reader following the book should at that point have a working copy of Drupal in his development environment. Chapter 3 explains some basic configuration settings for the newly-installed Drupal instance, as well as how to install modules and themes. However, some of the information is presented in a potentially confusing manner, such as on page 16 when an absolute directory path in one step, is immediately followed by what appears to be another absolute directory path in the next step ("/admin/build/modules"), but is actually meant to convey a navigation path within the Drupal user interface. For a book intended for Drupal newbies, it is essential to clarify technical issues such as this one, because otherwise readers can quickly become frustrated, wondering what the author is discussing and how to follow along in their own Drupal instances. Later, a favicon is described as residing "on the top of your browser window," but that would be the browser icon; rather, favicons are next to the browser's location field and in any relevant tabs. The author briefly describes more than half a dozen modules that arguably should be included in any Drupal site, including ones for dynamic menus, spam control, and task scheduling. Links to the modules' pages — in the text and/or as links in the PDF e-book — would have been quite helpful. The Tagadelic module is recommended for generating tag clouds, including a friendlier 404 error page, using the directory path "/tagadelic"; but Figure 3.5 shows the setting without that leading slash, and a quick test suggests that it does not work. More importantly for the newbie reader, there is no explanation as to how to start using tags. This chapter — like all that follow, except for the last — concludes with a list of contributed modules discussed in the respective chapter. Given that the chapters are short, and the modules' names easily stand out, these module lists add no value and could be removed in a future edition.

In Chapter 4, the reader learns how to use the Content Profile module for making highly functional and versatile user profiles that include photo and video galleries, avatars, contact forms, social networking, map locations, personal Web pages, AdSense revenue streams, and more. Most of the instructions are straightforward, but the discussion on how to implement avatars, on page 30, should have been fleshed out (no pun intended) — with more details as to exactly what settings to make, and where. Chapter 5 extends the previous topic, by demonstrating how to enhance the new user profile content type by implementing additional functionality: image and video galleries, a site member's location on a world map, member search, and featured members. In the next chapter, the author shows how to add more text-oriented content types, using the Views, Panels, and Fivestar modules.

While the first six chapters of the book focus on how to create functionality for users, the three chapters that follow examine how to create functionality for the online community itself. Chapter 7 discusses the details of adding forums, shout boxes, buddy lists, messages, subscriptions, a newsletter, user points, user status, user activity (think Twitter), and user groups. Chapter 8 explains how to utilize Google AdSense, affiliate programs, and donations — so that site owners and members can receive some sort of financial reward for their community-building efforts. Chapter 9 covers subjects that a site builder will encounter near the final stages of site development, such as finalizing the navigation menus, providing a post-registration page, supporting internationalization and localization, customizing system e-mail messages, tuning site performance, promoting a new site, tracking a site's popularity with analytics, performing module updates safely, backing up Drupal files and database, and duplicating a site.

Drupal 6: Ultimate Community Site Guide is wrapped up with a brief chapter, an author bio, and an unnecessary marketing description of the book. Unlike most programming books, this one is missing an index — although, as an e-book, it can be searched far easier than a print book.

The list price of the book is a very reasonable €7.70, and it is currently available for €5.50. Even though it is registered under the ISBN 978-2839904902, it is currently not available from Amazon.com, because it is an e-book, and the Amazon.com Kindle is not yet available in Europe; this apparently prohibits European publishers from using it. However, the book's website makes it possible to purchase it online. That site also has more details on the book's contents and the author. In addition to the book site, the first three chapters can be previewed online, via its Google Books listing.

Like any technical work, this one has its strengths and weaknesses. Sadly, the book is marred by generally sloppy writing, with a high ratio of errors to pages. There are several errata: "to[o] much" (pages 4 and 79), "others[']" (page 5), "look[s]" (page 16), "fig 3.3" (page 17; should read "Figure 3.1"), "Imagecache_actions Module" (page 52), "eld avatar" (page 66), "other then" (page 69), "others['] contact link" (page 94), "less then" (page 117), "Clustermaps" (page 124), and ."[my]sql file" (page 128). Also, there are many instances of awkward or incorrect phrasing, such as "harmonic" (page 2; should read "in harmony"), "Skippy balls" (page 3; hint: they have nothing to do with peanut butter), "expansive" (page 4; should read "extensible"), "6-versions" (page 9), "and a while" (page 20; should read "in awhile"), "brackets" (page 26; should read "parentheses"), "200% satisfied" (page 34), "Fixfertig" (page 76), "a grip out" (page 83), and "yourbranch" (page 112). Some of these may be European expressions, though Google suggests otherwise. There are missing commas and hyphens, some punctuation marks used incorrectly, and numerous sentences split at the coordinating conjunction into separate (incomplete) sentences. The use of case and spaces in proper names throughout the book are oftentimes incorrect, e.g., "MySql" (page 10 and others), "ftp" (page 10), "cleanURLs" (page 15), "phptemplate" (page 16), "Dhtml" (page 23), "tagadelic" (page 31), "html" (page 98), and "Paypal" (page 113, etc.). Most of the PHP snippets do not have any proper code indentation. Web accessibility proponents will cringe at the table-based positioning. The book's first "chapter" is really an introduction, and should be relabeled as such. The "Acknowledgments" and "Overview" pages have the same page number. Chapter titles are not in title case, but in sentence case. The side notes, used to indicate unstable releases, are rather annoying, because each one of them is positioned so that it looks like a continuation of the narrative line to the left of it. All of these side notes — and perhaps the information in the footnotes as well — should be merged into the narrative. As of this writing, the book's site claims that the book has more than 100 screenshots, but by my count there are 87 of the them. All of these blemishes — none serious — suggest that no technical editing was done prior to publication.

However, the main problem with the book is how, at several points in the narrative, the author assumes too much understanding on the part of the reader, and does not provide enough details for the reader who is trying to implement each suggestion on his own computer and yet has never before worked with the modules in question, or even the key concepts. This problem is seen in entire sections (such as the tagging section mentioned above) and lone sentences (such as the baffling "If you want to change a preset later on, just flush the preset after making the changes..." on page 46).

But none of these weaknesses diminish the overall value of this contribution to the Drupal literature. The book largely achieves its goal of teaching the reader how to create his own Drupal-based community site, using core and contributed modules only, with no custom programming (with the exception of some code snippets stored in the Drupal database). The explanations are, for the most part, clear enough for the reader to step through the process within his own Drupal installation. Some people may fault the book as being too lightweight and lacking the in-depth discussions typical of most Drupal books. But those detractors would be missing the point: This particular title is written for a different target audience, namely, people who wish to build a new website as quickly and easily as possible, and who may not have the knowledge or time to write custom code.

With plenty of detailed instructions, and an upbeat tone throughout the presentation, Drupal 6: Ultimate Community Site Guide can serve as a useful and fast-paced beginning resource for any Drupal developer who wants to create a social media website, requiring minimal time and custom PHP code.

Michael J. Ross is a freelance Web developer and writer.

Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Hugh Pickens writes "The CIA is adopting Web 2.0 tools like collaborative wikis but not without a struggle in an agency with an ingrained culture of secrecy. 'We're still kind of in this early adoptive stage,' says Sean Dennehy, a CIA analyst and self-described 'evangelist' for Intellipedia, the US intelligence community's version of the popular user-curated online encyclopedia Wikipedia adding that 'trying to implement these tools in the intelligence community is basically like telling people that their parents raised them wrong. It is a huge cultural change.' Dennehy says Intellipedia, which runs on secure government intranets and is used by 16 US intelligence agencies, was started as a pilot project in 2005 and now has approximately 100,000 user accounts and gets about 4,000 edits a day. 'Some people have (supported it) but there's still a lot of other folks kind of sitting on the fence.' Dennehy says wikis are 'a challenge to our culture because we grew up in this kind of "need to know" culture and now we need a balance between "need to know" and "need to share."' A desire to compartamentalize information is another problem. 'Inevitably, every person, the first question we were asked is "How do I lock down a page?" or "How do I lock down a page so that just my five colleagues can access that?"' The growth of Intellipedia has so far largely been fueled by early adopters and enthusiasts says Chris Rasmussen, a social-software knowledge manager and trainer at the National Geospatial Intelligence Agency. 'We are struggling to take it to the next level.'"

Bibek Paudel writes "Nepal's Constituent Assembly is drafting a new constitution for the country. We (FOSS Nepal) are interacting with various committees of the Assembly regarding the issues to be included in the new constitution. In particular, the 'Fundamental Rights Determination Committee' is seeking our suggestions in the form of a written document so that they can discuss it in their meeting next week. We have informed them, informally, of our concerns for addressing digital liberties and ensuring them as fundamental rights in the constitution. We'd also like to see the rights to privacy, anonymity, and access to public information regardless of the technology (platforms/software). Whether or not our suggestions will be incorporated depends on public hearings and voting in the assembly later, but the document we submit will be archived for use as reference material in the future when amendments in the constitution will be discussed or new laws will be prepared. How are online rights handled in your country? How would you want to change it?" Read on for more about Bibek's situation. He continues,
Here is an email I wrote to FOSS Nepal mailing list. I wanted to post a similar message to some international mailing lists (like the FSF, EFF) but I know only of announcement mailing lists of that kind. If you have something to suggest, please do. We're committed to doing everything we can to make sure that in the future Nepal becomes a country where digital liberties are fully respected. It's my personal dream to make our constitution a model for all other developing (or otherwise) countries as far as digital liberties are concerned.

There are many issues on which your suggestions would be valuable. If you've interesting examples from history, they'd help too. If you're a legal expert, please mention the legal hassles our issues could generate. If you're from the FSF, the EFF etc, please provide your insights. If you're just another citizen like me, how would you like your government to address file sharing, privacy, anonymity, platform neutrality, open standards, etc? This Slashdot discussion itself would serve as a reference to our document.

GamePolitics reports that "Germany's 16 Interior Ministers have banded together to ask the Bundestag (Germany's equivalent of Parliament) to ban the production and distribution of violent video games. Moreover, the ministers hope to see this accomplished before Germany's new elections take place on September 27th." Violent games became a national issue in Germany earlier this year after Far Cry 2 was scapegoated for a shooting. Germany-based game developer Crytek could be forced to move or outsource if the ban goes through. Spiegel Online has the original story (Google translation).

blackbearnh writes "Google just released Google Squared into the Google Labs playground. Google Squared lets you get results back in row and column format, and then add more columns to the result set. There's a brief tour of the features over on O'Reilly Radar, where the judgement is that there's lots of rough edges, but a huge amount of potential, especially for quick and dirty table generation for reports."

Shastri writes "After blocking several prominent social websites like Twitter, Youtube ahead of Tiananmen anniversary, by the great firewall of China, some popular social sites in China have also gone under 'maintenance'. While it is anybody's guess as to whether these events are related or purely coincidental, the announced maintenance come mostly unscheduled and last for several days might give a hint. A spreadsheet (in Chinese) is being maintained enumerating the sites that have gone down for a maintenance."

theodp writes "Speaking at the Google I/O Developer Conference, Sergey Brin described Google's efforts to defeat "Page's Law," the tendency of software to get twice as slow every 18 months. 'Fortunately, the hardware folks offset that,' Brin joked. 'We would like to break Page's Law and have our software become increasingly fast on the same hardware.' Page, of course, refers to Google co-founder Larry Page, last seen delivering a nice from-the-heart commencement address at Michigan that's worth a watch (or read)."

theodp writes "Speaking at the Google I/O Developer Conference, Sergey Brin described Google's efforts to defeat "Page's Law," the tendency of software to get twice as slow every 18 months. 'Fortunately, the hardware folks offset that,' Brin joked. 'We would like to break Page's Law and have our software become increasingly fast on the same hardware.' Page, of course, refers to Google co-founder Larry Page, last seen delivering a nice from-the-heart commencement address at Michigan that's worth a watch (or read)."

Busshy writes "Linux has arrived on the Dingoo A320, a portable console that was recently released in Asia (bundled with emulators for 16-bit consoles) which looks like the bottom half of a DS Lite. It also has an XMB that closely resembles those that PSP and PS3 owners are used to. Homebrew Coders have already ported ScummVM and PRBoom (Doom Engine) to Dingoo Linux."

ArfBrookwood writes "Every year, I write a Christmas Letter and send it to about 50 people, and every year, it's different. One year it was just the word blah blah blah over and over with keywords, one year I made papercraft wallets with full color cards and money in them, another year I created a Christmas Letter writing contest that instructed the recipients to create our Christmas Letter for us and we awarded prizes to winners, last year, I took a fake retro photo of my family, Inkscaped/GIMPed in a chemistry set and some wall art, printed it onto CD covers, and burned retro Christmas songs onto digital vinyl and sent everyone in the family what looked like a miniature Christmas album. Last week, I came into the possession of 78 2GB USB drives. I have already taken the time to wipe them clean and reflash the memory so they are blank slates." Now, Arf's looking for suggestions for how to best use all these drives; read on for more.
"My first inclination was to remove the USB drives from their careful packaging and plastic enclosures, dump them into a slurry of glue and rock dust, sandpaper the USB port to make it look ancient, and then make some videos or include some oddly formatted numbered/whatever text files to make them look like they cam from some dystopian wasteland fallout-3 type future and then package them in envelopes that looked like they were from some central futuristic government post office. The idea would be that in the future, incidents that happened this year would have had a profound affect on the future. I never tell anyone what the Christmas Letter will look like, and I have only one rule — I have to outdo whatever I did the last year."

snydeq writes "Google will add scripting capabilities to Google Docs, allowing organizations to customize their online applications and automate tasks. Google plans to sign up about 1,000 customers over the next few weeks to test the feature, called Google Apps Script. It will be tested initially in Google Spreadsheets and extended to other Google Docs applications over time. The company isn't saying yet when Apps Script — which is based on JavaScript with object-based extensions added by Google — will be widely available. Google Docs users can already apply to try it out."

Hugh Pickens writes "Thomas O'Toole writes that President Obama's choice for Associate Supreme Court Justice, Sonia Sotomayor, authored several cyberlaw opinions regarding online contracting law, domain names, and computer privacy while on the Second Circuit. Judge Sotomayor wrote the court's 2002 opinion in Specht v. Netscape Communications Corp., an important online contracting case. In Specht, the Second Circuit declined to enforce contract terms (PDF) that were available behind a hyperlink that could only be seen by scrolling down on a Web page. 'We are not persuaded that a reasonably prudent offeree in these circumstances would have known of the existence of license terms,' wrote Sotomayor. Judge Sotomayor wrote an opinion in a domain name case, Storey v. Cello Holdings LLC in 2003 that held that an adverse outcome in an administrative proceeding under the Uniform Domain Name Dispute Resolution Policy did not preclude a later-initiated federal suit (PDF) brought under the Anticybersquatting Consumer Protection Act (ACPA). In Leventhal v. Knapek, a privacy case, Judge Sotomayor wrote for the Second Circuit that New York state agency officials and investigators did not violate a state employee's Fourth Amendment rights when they searched the contents of his office computer (PDF) for evidence of unauthorized use of state equipment. While none of these cases may mean much as far as what Judge Sotomayor will do as an Associate Supreme Court Justice 'if confirmed, she will be the first justice who has written cyberlaw-related opinions before joining the court,' writes O'Toole."

courteaudotbiz writes "French ISP Orange has been fined 13000 Euros after being sued by a man named Mohamed Zaidi, who has been assigned the temporary password 'salearabe' (dirtyarab) by e-mail after he placed a support call. At the hearing, the prosecutor called the password 'offensive, insulting and even defamatory.'"

Gerv writes "When Google launched their Map Maker community mapping tool last year, they included loads of Caribbean islands. This led Ed Parsons (chief Google Maps guy) to say that he was sad there wasn't any fieldwork involved. Well, now OpenStreetMap have gone one better — following a successful Pledgebank pledge, they have got together the money to send one randomly-chosen guy to Antigua for a week to work on the OpenStreetMap map!"

viyh writes to mention that six German states have mandated pulling Red Bull Cola energy drinks off the shelves after testing found trace amounts of cocaine in the drink. "Germany's Federal Institute for Risk Assessment said Monday that the cocaine level was too low to pose a health risk. It planned to produce a more detailed report Wednesday. Red Bull said its cola is 'harmless and marketable in both the US and Europe.' It said similar coca leaf extracts are used worldwide as flavoring, and a test it commissioned itself found no cocaine traces."

gbickford writes "Adeona, the first open source system for tracking the location of your lost or stolen laptop, was featured on Slashdot last year. I was stoked when I read about how it worked and I installed it immediately. I just went to look for updates on the site and was greeted with a giant warning message stating, 'Adeona is currently not working.' It seems that OpenDHT, the distributed hash table that stores the location information and photos, has been fairly unstable lately. The developers claim that this is "largely because the back-end OpenDHT system is not able to tolerate the load imposed by Adeona. OpenDHT removed the need for a centralized database with tracking information, which in effect prevents a 3rd party from tracking a user's whereabouts. OpenDHT was Sean Rhea's Ph.D. project back in 2005 and he has decided to officially bow out of maintaining it as of July 1st, which has left the developers of Adeona looking for another back end to store location information and photos. The source code for Adeona is available and they are actively seeking developer contributions on the developer's list. Do any developers have ideas on where to put scads of information in a free, reliable, anonymous, and secure manner?"

An anonymous reader writes "Istanbul's popular (and crowded) Istiklal shopping, cafe, and restaurant street is being outfitted with 64 wirelessly controlled, tamper-proof face-recognition cameras attached to a computer system capable of scanning 15,000 faces per second in a moving crowd for a positive match. The link from Samanyolu, badly translated by Google, states that 3 cameras are in place so far and that if trials are successful, this will mark the first time such a system, previously used by Scotland Yard and normally reserved for indoor security use, will be put to use in a public outdoor setting. It also notes that each camera controlled by the system is capable of 'locking onto' the faces of known criminals and pickpockets detected in the crowd and 'tracking' their movements for up to 300 meters before the next, closer placed camera takes over." Hit the link for more of this reader's background on the growing electronic encroachment on privacy in this city, which will be the European Capital of Culture in 2010, causing him to ask, "Is the historic city of Istanbul turning into the new London?"
While the article doesn't state it outright, it would appear likely that the outdoor face recognition system, if "successful," will be expanded to other crowded areas of Istanbul as well, which has already seen a dazzling increase in the number of installed plain-vanilla (non face-recognizing) CCTV cameras in recent years. This comes after Istanbul's two signature Bosphorus bridges have become passable only by vehicles with a mandatory vehicle windscreen-mounted electronic pass, subway and bus tickets in the city have gone electronic, vote tallying in municipal and national elections has become fully computerized, and future plans for mandatory biometric ID cards for all Turkish citizens have been announced by the government.

The ruling "moderate Islamist" AKP party appears to frame these and other e-government initiatives as "keeping step with the times," "keeping step with other major world cities," and "making living safer, easier and more efficient through the targeted use of electronic technology." Its secular critics, on the other hand, argue that everything and everyone under the sun is rapidly becoming electronically trackable thanks to the omnipresence of mobile phones and gratuitous overuse of these installed electronic systems, and that these systems will, eventually, form a dense surveillance grid that could turn daily life for Turks (and secular Turks critical of the current government in particular) into living in a veritable Big Brother House.

viyh notes that President Obama has named former astronaut Charles F. Bolden Jr. as NASA administrator. Obama's campaign space adviser, Lori Garver, will be Bolden's deputy. Bolden flew four shuttle missions, two as commander, as well as 100 combat missions over Viet Nam. If confirmed, Bolden will take over an agency uncertain of its direction. The shuttle Atlantis's landing will mark the end of the servicing era — it was the last planned mission to repair any satellite. Some inside the agency are less than happy about how NASA's future looks from here.

An anonymous reader writes "Despite promising in January to open RTMP, Adobe has issued a DMCA take down request for an open source implementation of the protocol. The former SourceForge project page for rtmpdump now reports 'Invalid Project.' rtmpdump has been used in tools such as get_iplayer and get-flash-videos. Adobe is no stranger to the DMCA, having previously used it against Dmitry Sklyarov."

RadiusK writes "Google has released the second major version of the Chrome browser. This version features more speed improvements thanks to a newer version of V8 JavaScript engine and WebKit. JavaScript-heavy web pages will now run about 30% faster. Other new features include form autofill, fullscreen mode, and improved New Tab page. If you're already using Google Chrome, you'll be automatically updated with these new features soon. If you haven't downloaded Google Chrome, you can get the latest version at google.com/chrome." A version for Linux or OS X would be nice.

langelgjm sends in an update to a story we discussed over the weekend about an extremely well-preserved fossil of an ancient primate, Darwinius masillae, that sheds light on an important area of evolution. The 47 million-year-old specimen has now been officially unveiled, and while many media outlets are stumbling over themselves with phrases like "missing link" and "holy grail," it's clearly a very impressive find. "Discovered two years ago, the exquisitely preserved specimen is not a direct ancestor of monkeys and humans, but hints at what such an ancestor might have looked like. According to researchers, 'The specimen has an unusual history: it was privately collected and sold in two parts, with only the lesser part previously known. The second part, which has just come to light, shows the skeleton to be the most complete primate known in the fossil record.' The scientific article describing the find was published yesterday in the peer-reviewed, open-access journal PLoS ONE. Google's home page is also celebrating the find with a unique image." Science blogger Brian Switek offers some criticism of the academic paper and the media swarm, saying, "I would have hoped that this fossil would receive the care and attention it deserves, but for now it looks like a cash cow for the History Channel. Indeed, this association may not have only presented overblown claims to the public, but hindered good science, as well."

Frequent Slashdot contributor Bennett Haselton writes "A woman sued Yahoo because they wouldn't remove a page created by her ex-boyfriend pretending to be her and soliciting strangers for sex. What would be an effective system for large companies like Yahoo to handle 'impostor' complaints, without getting bogged down by phony complaints and unrelated disputes? This is a harder problem than it seems because of the several possible cases that have to be considered. One possible solution is given here." Read on for Bennett's analysis.

When I first heard that Yahoo had been sued because they refused to remove a page created by the ex-boyfriend of a woman named Cecilia Barnes to impersonate her -- portraying her as a slut looking for sex with strangers (who obliged by hounding her office with phone calls and e-mails) -- I thought Yahoo's conduct was indefensible. Even though, as the court ruled, they may have been exempt from liability under the Communication Decency Act of 1996, what possible excuse could Yahoo have had for the way they handled the situation, exposing Barnes to months of harassment, when it would have taken them only seconds to review the page, see that it was obviously causing harm, and remove it?

Then I thought more about the consequences of the rule that I was implicitly advocating by making that argument. Obviously, if an ISP has a policy of removing a user's page if some third party merely complains that the page is impersonating them, then one of your enemies could get your page removed by filing a complaint saying that they were really "you", and that your page was impersonating them. But if the ISP has a policy of not acting on such complaints, then someone could create a user account pretending to be you, and you wouldn't be able to get it removed.

In both cases, there are two problems. One is the fact that the ISP has to have a way to figure out who is telling the truth. The second is that the solution has to scale well, even for a company like Yahoo that probably gets so many complaints about user conduct every day that it would be impossible to read them all. It should be possible for genuine complaints about impostors, to reach the attention of the right people and get an account closed, without accounts being shut down because of (a) people who file complaints about 'rude behavior' that get unintentionally mixed in with 'impostor' complaints by someone who is too overworked to read them all very carefully; or (b) people who file outright false complaints that a given account is an 'impostor', just to get it shut down; or (c) people who are really sneaky, and file complaints about things like rude behavior, but who craft the complaints in a way that is deliberately designed to get them mixed in with the 'impostor' reports, in order to get the account shut down (this way, if the complainer ever sued or otherwise confronted about the complaint that they filed, they can say that they "didn't lie"!).

It's hard to think of a solution that covers all of these bases. For example, John Morris of the Center for Democracy and Technology explained how many ISPs use faxed driver's licenses to decide impersonation complaints:

In many cases involving real people, the challenged site (whether it is a legit site or a bogus site) contains one or more photographs of the person involved. What service providers do in this case is to get the person to submit a copy of their driver's license, and the provider decides whether the person submitting the license is the same person depicted in the photos. And if so, that person is the one who can control whether the site stays up or not. This works in lots of cases (because pictures are often, but certainly not always, involved).

The problem is that even this could be abused when used against a company like Yahoo that handles an extremely high volume of complaints. Suppose that Yahoo publishes a standard procedure for submitting complaints about impersonation, that includes the requirement of a faxed driver's license. Abusers of the system would figure this out, and they could start filing "complaints" against users and websites by faxing in complaint letters along with a copy of their driver's license, where the letters were not complaints about impersonation at all, but just bogus complaints about other things like "This guy was mean to me". Because the driver's license accompanying the letter is real and the statements in the letter are true (or at least a matter of opinion), the complainer can't be accused of lying or forging government documents. And if anyone ever challenged them and asked, "Why did you send your driver's license with the complaint letter? Weren't you trying to trick the ISP into thinking that this was an impersonation complaint so they would take it seriously?", the complainer could play dumb and say, "Well, I heard that if you file a complaint against someone, you're supposed to fax your driver's license with it." But if Yahoo is still getting too many messages to sort through them carefully, some of these crank complaints could still get users' accounts shut down.

So now you have an interesting, non-trivial problem. Before reading further, it's worth thinking about how you would solve this. What's a good policy that would honor legitimate complaints, without giving cranks a way to get their enemies' pages shut down for no reason, and that would scale well for large companies like Yahoo? There are really two questions here: (1) What would you do if you were drafting an ISP policy and trying to balance the interests of all parties? and (2) What would you do if you were drafting a law requiring ISPs to implement certain policies, also while balancing the interests of all parties? (The best solution may be no law at all, but I think you would have to argue that position, rather than taking the default libertarian stance and simply assuming that. After all, the "no law" status quo didn't do much good for people like Cecilia Barnes who had a legitimate grievance and couldn't get anybody to listen.)

The non-verifiability of complaints is the same problem that I've posed to hard-core anti-spam advocates who have said that ISPs should have a zero-tolerance policy towards spam and cancel any account that is generating spam complaints. The problem with that is that unless the ISP has logs of all mail sent out by a customer (and if the customer is leasing a dedicated server, this would usually not be the case), the ISP can't tell for sure if a spam complaint is real or not. If they adopt a policy of removing a site in response to a complaint (or three or ten complaints), then someone could easily get one of their enemies' sites shut down by filing phony spam complaints sent from multiple Hotmail or Gmail accounts. (You would have to forge some e-mail headers to make it look convincingly like the spam came from the site in question, but this is not very difficult.) If the hosting company has a policy of kicking customers off in response to some threshold number of spam complaints, then a dedicated adversary could just file that many complaints until the customer was terminated. On the other hand, if the hosting company won't kick off customers for any number of spam complaints, then they have no deterrent against their customers spamming. (This is mostly an academic question, because I tried filing complaints against all the dozens of spammers who spammed me in a given one-day period a few years ago, and none of the hosting companies terminated any of the sites I complained about. I wouldn't have expected any of them to terminate a customer based on one complaint, but I assume that some of the hosting companies were getting spam complaints about those customers from other people as well.)

The big difference between spam incidents and impersonation incidents, is that while there may be no reliable record of whether a piece of mail was sent in the past or not, the fact of whether the Yahoo user "bennetthaselton" really is Bennett Haselton is something that can be determined with evidence that still exists in the present day. Some kinds of evidence are more readily available than others. If I were drafting an internal policy for an ISP on when to remove pages in response to an impersonation complaint, I would take care of the low-hanging-fruit cases first:

• If the page directs people to contact the page owner at an e-mail address or phone number (as the page created by Barnes' ex-boyfriend did), and you e-mail the address or call the number and someone answers by saying, "No, I didn't create that page, it's a fake", then you don't need to do any checking of the real-world identities of the parties involved -- all you need to know is that the page purports to be created by the owner of that phone number, but it isn't, so it's a fake and should be removed. This would take care of the most vicious cases of goading visitors into harassing someone directly.

  (Although I'd make clear in the policy that this wouldn't apply to consumer pages about companies, telling visitors to call such-and-such a company to complain about their conduct. Encouraging people to air their grievances is legitimate as long as the page owner isn't claiming to actually represent the company. I'm ducking the question of whether this should apply to pages about individuals -- if I make a page saying, "My ex is a skank, call her at this number for a 'good time'," am I infringing on her rights? But since I'm not claiming to be her, the situation wouldn't be covered by a policy about impersonation pages.)

• If the page is created by a paid user, then you can check if the real name on file with their credit card information, matches the name on the site. If it doesn't, that doesn't necessarily mean the page is a fake (possibly one person paid for the account while another one created the content), but if it does match, the page owner is probably not guilty of impersonating anyone. (Here I'm ducking the question of what to do if someone shares their name with a celebrity -- for example, if your name really is Julia Roberts and you create a page saying "Hi, I'm Julia Roberts", that's probably not enough to count as impersonation. But what if you talk about your interest in film and your exploits as an actress in local community theater, how much are you allowed to let people think that you might be "the Julia Roberts?)

• If the page violates the hosting company's Terms of Service in other ways, then it can be removed without determining whether the page owner is guilty of impersonation or not. The Yahoo Terms of Service doesn't actually mention sexual content (they used to allow users to post "adult profiles" in their Yahoo Profiles accounts as long as the profile owner flagged them as such), but the document prohibits content that is "vulgar" or "...otherwise objectionable". I haven't seen the page created by Barnes's ex-boyfriend soliciting strangers for sex, but it probably violated the Terms of Service in itself.

And there may be other low-hanging-fruit options that I'm not thinking of. But what if there is no easy call, because none of these simplifying factors apply? A user creates a profile on a free site claiming to be Mr. X. A third party complains that they are the real Mr. X and that the profile is fake. What should the ISP do, if they don't want to spend money verifying the real-world identities of the parties involved, every time they get a crank complaint about any users on their system?

This is essentially an economics problem. Cecilia Barnes wasn't asking Yahoo to do anything that would have been too burdensome for them -- the "labor" required to look at a faxed copy of her driver's license probably wouldn't have cost more than $5, at which point Yahoo could have initiated the process of shutting the page down, which they already have built-in procedures for. The benefit to her of getting the page shut down could have been valued in the hundreds or thousands of dollars. Normally, when you need someone else to do something that costs them $5 worth of effort and brings you $1,000 worth of benefit, the natural arrangement is to pay them, but Yahoo doesn't offer this as an option.

In fact, I assume the real cost to Yahoo here would not have been actually reviewing Barnes's complaint, but actually finding it buried among all the bogus complaints that they receive, and noticing that it had real merit. Again, including a $5 payment would be one way to ensure that your complaint gets taken more seriously than all the others. But while the $5 fee might have helped in this specific situation, it's easy to imagine how that could set a bad precedent -- ISPs charging exhorbitant fees for users to submit abuse complaints to them, or users not filing complaints because they didn't want to share their payment information or pay money at all.

So, rather than paying a small fee directly, a better approach might be to require complainants to post some sort of "bond" -- which may not be something financial, as some examples will show -- in order to get their complaint to the front of the queue. Recall the example of submitting your driver's license along with an impersonation complaint. It's important to understand the subtle reason why this procedure actually works. It's not because someone couldn't still file a bogus complaint with a phony ID. (While it's somewhat hard to create a fake driver's license that you can hold in your hand, creating a fake faxed driver's license would be easy.) It's because if the complainant is lying, now they can be prosecuting for forging government documents. Essentially the complainant is posting their freedom as a "bond", going out on a limb and saying: "I can't prove to you that I'm telling the truth. But now you know that if I'm lying, I'll go to jail. Bet you the other guy won't be willing to make a binding promise like that."

So naturally I'd put that in the ISP's policy as well: If someone sends in a complaint about our user impersonating them, and they're willing to fax in a copy of their government ID proving that they are who they say they are, and we can verify that the page owner is claiming to actually be that person (and not merely complaining about that person or their business), then we would remove the page unless the account owner can submit even more compelling evidence that they are who they say they are.

This addresses the problem of the impersonation complaints that are completely fake. However, you still have the problem of what to do about people who fax in their driver's license along with letters saying "This guy is a jerk", hoping to get someone's account closed down. If a company like Yahoo is too big to read through all the complaints carefully, then it becomes hard to sort through the complaints to see which ones are really about impersonation and which ones are about other behavior that doesn't violate their TOS.

What might be a solution would be to borrow some of the non-terrible aspects of the Digital Millenium Copyright Act. The two most controversial provision of the DMCA are (1) a ban on software that enables the user to circumvent copyright restrictions, and (2) a requirement that ISPs have to respond to copyright-violation "takedown" notices in a certain manner. As I've said before about the DMCA, I'm opposed to #1 in principle because I think software should be protected by the First Amendment; I'm not against #2 in principle, but just concerned about how it could be abused in practice.

But one thing the DMCA does is solve the "sorting problem" -- how to get complaints about copyright violations to the top of the pile. Service provides often have a procedure for handling DMCA complaints that is separate from the regular complaint channels. The DMCA also provides protection for users against phony complaints, by stipulating that anyone who files a false complaint can be sued for statutory damages and attorney's fees, as in a case where Diebold, Inc. agreed to pay $125,000 as a penalty for sending false "takedown" notices. In other words, the DMCA solves the "bonding" problem too -- by sending a DMCA complaint, a user is effectively saying, "I agree to pay big money if I'm lying. So, I'm probably telling the truth."

So, a law addressing how ISPs should handle "impersonation" pages, modeled after the DMCA to solve the "top of the pile" problem and the "binding promise" problem, might go something like this:

• For a user to file a complaint, the complaint should cite the name of the anti-impersonation law, as in, "This complaint is being filed under the Anti-Impersonation Act of 2009". This gives ISPs an easy way to sort these complaints to the top of the pile, the same way that they have specialized channels for handling DMCA complaints.
• In the complaint, the user has to assert unambiguously that the page they are complaining about is impersonating them, and is not merely posting gripes about them or their business.
• The complaint should include a copy of a government-issued ID. (Again, this is not because this is hard to forge, but because now the complainant is promising, "If this is fake, I'll go to jail.")
• If the impersonation page is directing visitors to call a phone number or e-mail an e-mail address, and the takedown notification to the ISP includes a request to call that number or e-mail that address to verify that it doesn't actually belong to the page owner, then the ISP should follow up on that within a given time period of receiving the complaint. (And once they call that number or e-mail that address and get a response saying, "No, that page is definitely not mine", then the ISP should shut the page down.)
• Anyone who files a phony complaint citing that statute, can be held liable for statutory damages and attorney's fees, and if they faxed a phony government ID, then they can be prosecuted for that as well.

The problem-solver in me says that this is one way to ensure that legitimate complaints will be acted on, while making phony complaints much harder and riskier. It also seems to me that this is a minimal solution, in the sense that if you remove any part of it, it no longer solves the problem. For example, if you remove the part about complaints having to cite the anti-impersonation law, then you no longer have an effective means for these complaints to get to the top of the pile. And if you remove the part about civil penalties for filing phony complaints, then you no longer have any disincentive for people to tie up the system with crank complaints trying to get their enemies' accounts cancelled. Perhaps others can come up with an alternative solution that meets the logical requirements of enabling real complaints while discouraging fake ones. Meanwhile, the civil libertarian in me doesn't get a queasy feeling from it right away. It seems that it could only be used to stop cases of actual impersonation, and even as a free speech advocate I don't think that you have the moral right to impersonate someone else in a non-satirical manner for the purpose of actually deceiving or harassing people.

But even the absence of such a law is hardly an excuse for what Yahoo did. All they had to do is go to the page, look at the phone number, call the number and hear her say, "Yes, this is me and no that's not my page", and shut it down. The fact that they couldn't do this, shows a contempt for the process of handling legitimate complaints. Apart from the harm caused to Cecilia Barnes directly, incidents such as these might lead to Congress narrowing the scope of the immunity given to providers for hosting content posted by their users. Of course I'm technically suggesting a law that would narrow the scope of that immunity too, but only in a very narrowly prescribed way. If, on the other hand, Congress or the courts ever adopt the vague principle that providers can be held "jointly responsible" for whatever their users say once they've been "made aware" of it, it's going to get a lot harder for people to find Web hosting who have anything controversial to say.

macson_g writes "Students from Wroclaw University of Technology (Poland) once again turned one of their dormitories into huge display. The project is called P.I.W.O. (B.E.E.R.). This time they converted a 10-story building into 4-color, 12x10 display. The business was used to display animations, and to play interactive games as well. On the project page (in Polish, Google translation here) you can watch an almost hour-long video, featuring music videos, a Tetris session, a dancing Michael Jackson, Duke Nukem and Mario."

mjasay writes "Mozilla's Asa Dotzler points to some interesting long-term trends in browser market share, noting that 'browser releases aren't having any major impact on the macro trends,' which suggests that a better IE will likely have little impact on its sliding market share. The most intriguing conclusion from the data, however, is that Firefox could surpass IE market share as early as January 2013 if Firefox continues to gain 5 percent every year, even as IE drops 5 percent each year. In the past, Microsoft might have fought back by tying IE to other products to block competition, but with the EU keeping a close antitrust eye on Microsoft and the US Obama administration keen to make an example of an antitrust bully, Microsoft may have few good options beyond good old fashioned competition, which doesn't seem to be working very well for the Redmond giant, as the market share data suggests. Microsoft's loss of IE market power, in turn, could have serious consequences for the company's efforts to compete with Google on the Web."

theodp writes "Slate's Farhad Manjoo feels the end of voice-mail is nigh, and it won't be missed. Since March, he's been using Google Voice to transcribe his voice-mail messages into text that he gets as skimmable e-mail. No more listening to at least a bit of each voice-mail message, hearing the same instructional prompts between each, and worrying about whether it's 9-to-archive and 7-to-skip (or vice versa). Goodbye and good riddance, says Manjoo, to an 'absurdly backward mode of human-computer interaction' that he half-jokes must violate the Geneva Conventions."