Slashdot Mirror

JacobSteelsmith was one of many readers to note an ongoing problem with Gmail: "As I type this, GMail is experiencing a major outage. The application status page says there is a problem with GMail affecting a majority of its users. It states a resolution is expected within the next 1.2 hours (no, not a typo on my part). However, email can still be accessed via POP or IMAP, but not, it appears, through an Android device such as the G1." It's also affecting corporate users: Reader David Lechnyr writes "We run a hosted Google Apps system and have been receiving 502 Server Error responses for the past hour. The unusual thing about this is that our Google phone support rep (which paid accounts get) indicated that this outage is also affecting Google employees as well, making it difficult to coordinate."

JacobSteelsmith was one of many readers to note an ongoing problem with Gmail: "As I type this, GMail is experiencing a major outage. The application status page says there is a problem with GMail affecting a majority of its users. It states a resolution is expected within the next 1.2 hours (no, not a typo on my part). However, email can still be accessed via POP or IMAP, but not, it appears, through an Android device such as the G1." It's also affecting corporate users: Reader David Lechnyr writes "We run a hosted Google Apps system and have been receiving 502 Server Error responses for the past hour. The unusual thing about this is that our Google phone support rep (which paid accounts get) indicated that this outage is also affecting Google employees as well, making it difficult to coordinate."

Tiger4 writes "Cancer researchers in the UK have come up with a way to sniff for lung cancer on the breath. 'From the results, the researchers identified 42 "volatile organic compounds" (VOCs) present in the breath of 83% of cancer patients but fewer than 83% of healthy volunteers. Four of the most reliable were used to develop a nine-sensor array made from tiny gold particles coated with reactive chemicals sensitive to the compounds.' Other sources have picked up the story as well. Obviously, this would be a big breakthrough for rapid screening, and early detection significantly improves outcomes."

It seems that Swedish regulators have decided to extend the requirement of not calling yourself a bank to the registration of domain names. Now anyone that tries to register a .SE domain name with the word "bank" in it will need to prove they are a legitimate bank. Hopefully there are no blood banks or anyone with the last name of "Banks" that might want a .SE domain. Here is a Google translation of the demand issued by the authorities to the .SE registry.

Hugh Pickens writes "BBC reports that a treasured piece at the Dutch national museum — a supposed moon rock from the first manned lunar landing given to former Prime Minister Willem Drees during a goodwill tour by the three Apollo-11 astronauts shortly after their moon mission in 1969 — has been revealed as nothing more than petrified wood, curators say. A jagged fist-size stone with reddish tints, it was mounted and placed above a plaque that said, 'With the compliments of the Ambassador of the United States of America... to commemorate the visit to The Netherlands of the Apollo-11 astronauts.' The plaque does not specify that the rock came from the moon's surface. Researchers from Amsterdam's Free University said they could see at a glance the rock was probably not from the moon. They followed the initial appraisal up with extensive testing. 'It's a nondescript, pretty-much-worthless stone,' wrote Geologist Frank Beunk in an article published by the museum. Beunk says the rock, which the museum at one point insured for more than half a million dollars, was worth no more than $70. The 'rock' had originally been been vetted through a phone call to NASA. As the US Embassy in the Hague said it was investigating the matter, the Rijksmuseum says it will keep the piece as a curiosity."

An anonymous reader writes "The country that has bought Sukhois, tanks and 100,000 AK-103's, is planning to build a manufacturing plant of Russian rifles, and oppresses peaceful marches has decided to ban 'violent' video games because they 'promote violence and can alter the behavior of children.' The new legislation in Venezuela says, 'The violence found in video games is translated into the real world.' This new law affects people who sell, 'use,' produce, import and distribute these games. Video games as a whole have been labeled as 'a consequence of savage capitalism' by PSUV (United Socialist Party of Venezuela), which is the political party led by Hugo Chavez. Days before this law was approved by the National Assembly, Chavez promoted the use of traditional toys like the Yo-Yo and Trompo, and suggested that electronic toys like 'the Nintendo' be put aside because they promote 'egoism, individualism and violence.' Just today the AFP released a report showing Caracas as the second most violent city on the planet — even more violent than Baghdad. I guess all those violent gangs in Venezuela are addicted to video games."

Hugh Pickens writes "Heart attacks usually cause irreversible damage to heart muscle and, because cells lost from the heart do not grow back naturally, leave the organ in a weakened and vulnerable state that may cause another serious condition — called heart failure — if the victim survives. Now a team of scientists led by Tal Dvir from Ben-Gurion University of the Negev in Beer-Sheva has developed a tissue-engineering technique, using the body as a 'bioreactor,' to create a 'patch' made from heart muscle that can be used to fix scarring left over from a heart attack. First, a biodegradable 'scaffold' is seeded with immature cells taken from the hearts of newborn rats. For 48 hours, the scaffold is exposed to a cocktail of growth-promoting chemicals in the laboratory and is then transplanted into a rat's abdomen where it develops a network of blood vessels and muscle fibers. After seven days the patch is removed and grafted onto the animal's heart. A month later the patch has completely integrated itself into the heart, synchronizing its 'beat' with that of the surrounding tissue. 'Using the body as a bioreactor to engineer cardiac tissue with stable and functional blood vessel networks represents a significant improvement in cardiac patch performance over ex vivo (outside the body) methods currently used for patch production,' write the authors. The technique is also being developed for livers and bladders."

Hugh Pickens writes "Heart attacks usually cause irreversible damage to heart muscle and, because cells lost from the heart do not grow back naturally, leave the organ in a weakened and vulnerable state that may cause another serious condition — called heart failure — if the victim survives. Now a team of scientists led by Tal Dvir from Ben-Gurion University of the Negev in Beer-Sheva has developed a tissue-engineering technique, using the body as a 'bioreactor,' to create a 'patch' made from heart muscle that can be used to fix scarring left over from a heart attack. First, a biodegradable 'scaffold' is seeded with immature cells taken from the hearts of newborn rats. For 48 hours, the scaffold is exposed to a cocktail of growth-promoting chemicals in the laboratory and is then transplanted into a rat's abdomen where it develops a network of blood vessels and muscle fibers. After seven days the patch is removed and grafted onto the animal's heart. A month later the patch has completely integrated itself into the heart, synchronizing its 'beat' with that of the surrounding tissue. 'Using the body as a bioreactor to engineer cardiac tissue with stable and functional blood vessel networks represents a significant improvement in cardiac patch performance over ex vivo (outside the body) methods currently used for patch production,' write the authors. The technique is also being developed for livers and bladders."

Frequent contributor Bennett Haselton writes with an idea that he thinks could help keep browsing on Microsoft's browser more secure for users — and benefit Microsoft as a result. "Tests show that IE's malware filter performs well against other browsers that use the Safe Browsing blacklist from Google. But wouldn't IE's filter be even more effective if it used both filter lists at the same time? And are the political obstacles to that really so insurmountable?" Read on for the rest of a plan that seems a lot more than half-baked. Most major browsers now come with a built-in blacklist of malware-infected or phishing websites, that display a warning if the user tries to access them in the browser. Internet Explorer 8 uses Microsoft's SmartScreen filter, while Firefox, Safari and Chrome all use Google's Safe Browsing API. Recent tests from NSS Labs reported that IE's filter blocked 81% of "socially engineered malware sites" from the lab's sample, while Firefox, in second place, blocked only 27%, and other browsers trailed even further behind. When NSS Labs ran a test of the different browsers' efficiency at blocking phishing sites, IE and Firefox scored about the same, both blocking about 80% of the sites in the sample. These results left a lot of unanswered questions, such as: Why Firefox, Safari and Chrome got such different scores in both tests (since they supposedly all use the Safe Browsing blacklist), and why such a huge gap between IE's and Firefox's performance in the malware test, but such close scores for the two browsers in the phishing test (the Google Safe Browsing API page says that the database is an attempt to list both malware and phishing sites, after all).

But I had a different question: Since Google allows anybody to use the Safe Browsing API, why doesn't Internet Explorer use it as well, in conjunction with their own blacklist, so that a site will be blocked by IE if it's present on either list? This would almost certainly increase the block rate for IE (unless the set of sites blocked by Safe Browsing was entirely a subset of the sites blocked by SmartScreen, which is extremely unlikely). Google's Terms of Use for the Safe Browsing API do require parties to obtain written permission for any usage that will result in more than 10,000 users sending "regular requests" to the API, which would obviously include Internet Explorer. But Google already serves requests for all Firefox users who have the SafeBrowsing API turned on, so for them to process requests for all Internet Explorer users might require four or five times as much computing power, not orders of magnitude more. It's impossible to guess what kind of deal Microsoft and Google would make for the right to have IE do lookups on the Safe Browsing API, but if Microsoft placed a dollar value on increasing the protection for their users, and that dollar value exceeded the cost to Google of running the servers to process the additional queries, then in theory they should be able to agree on a price between those two amounts. Google might well offer to service the queries for free, just for the prestige of being able to say that the Safe Browsing database provided protection for almost all major browsers on the market.

(Microsoft's SmartScreen team declined to comment on the record about their reasons for not using the Safe Browsing list in addition to their own database. I couldn't get an official response from Google about what position they would have on Internet Explorer using the Safe Browsing list, although unofficially an employee said the team would probably be "delighted" if IE were to use it.)

It's worth underlining what a strong statement Microsoft is making by not using the Safe Browsing list. They're not just saying that their own list is better. They're saying that the Safe Browsing list is of such low quality that adding it to their own product would actually make the product worse.

This is different from, for example, what McAfee and Symantec might say about each other's anti-virus lists. Consider the set of all viruses that McAfee blocks and the set of all viruses that Symantec blocks. Let List X be the overlap — the huge swath of viruses that are blocked by both McAfee and Symantec. Then let List Y be the set of all viruses that are blocked by McAfee but not blocked by Symantec, and let list Z be the set of all viruses that are blocked by Symantec but not by McAfee. (So McAfee blocks viruses in the set X+Y, and Symantec blocks viruses in the set X+Z.) Now, representatives from McAfee and Symantec will each say that their list is the better one, which they may or may not believe. But even McAfee is not claiming that List Z — that portion of the list that is blocked by Symantec but not by McAfee — is so worthless that McAfee wouldn't incorporate it into their own product if they could get it for free. If Symantec allowed any anti-virus maker to download Symantec's anti-virus signature database, then presumably McAfee would scratch their heads a bit about why Symantec would do this, but if they cared about giving their users maximum protection, they would incorporate it into their product as well (so that McAfee would then be blocking all viruses in the set X+Y+Z, instead of just the set X+Y as they were before). But Symantec doesn't make it available for free, so McAfee doesn't have the option of using it and the issue doesn't come up. Other than each company claiming their product is the better one (which is par for the course for competitors), the two companies' positions are not contradicting each other.

But consider the analogous situation for anti-malware lists, where X is the set of all sites blocked by both IE's SmartScreen and by the Google Safe Browsing API, Y is the set of all sites blocked by SmartScreen but not by the Safe Browsing API, and Z is the set of all sites blocked by the Safe Browsing API but not by SmartScreen. When Microsoft says that they don't want to use the Safe Browsing list in addition to their own — that they would rather block just X+Y than block X+Y+Z — they're saying that they're estimating that the list Z is of such poor quality (too much risk of containing too many false positives) that it would be better not to block it at all.

In this case, Microsoft's position really is contradicting that of Google, Firefox, Safari, and others who use the Google Safe Browsing API. To achieve the best tradeoff between user safety and convenience, should the sites on List Z — the set of sites on the Safe Browsing API blacklist but not on the SmartScreen blacklist — be blocked, or not? If the answer is Yes, then IE should use the Safe Browsing API in addition to their own SmartScreen list. If the answer is No, then Google should take the URLs in the Safe Browsing API list, run them through IE using some automated script, and then remove all the URLs that weren't blocked by IE — in other words, remove all the URLs on List Z from the Safe Browsing blacklist. But I can think of no consistent set of assumptions that would lead one to recommend that both companies continue doing what they're doing now — that IE should continue not to use the Safe Browsing API, and that Google should continue publishing the Safe Browsing API without trimming URLs that aren't also blocked by IE. Microsoft is saying that the URLs on List Z should not be blocked; Google is saying that they should be.

(Note that this argument is independent of the relative weights that you assign to the benefit of blocking a genuinely malicious site, versus the cost of accidentally blocking a site which is not malicious. Different users might assign different values to these costs and benefits, and depending on what values they assign, those users would want different thresholds to be used in deciding whether to block a site or not. And Microsoft and Google have picked default thresholds that they estimate will meet the needs of the average user. But no matter what values you assign to the benefit of blocking a malicious site and the penalty for blocking a false positive, it's still the case that blocking the sites on List Z either does increases the total cost/benefit score — in which case IE should block sites on the Safe Browsing list in addition to its own — or it doesn't — in which case Google should remove sites from the Safe Browsing list that aren't blocked by SmartScreen.)

I suspect, of course, that the answer is the former — that the set of sites on List Z, those which are blocked by the Safe Browsing API but not blocked by SmartScreen, are probably approximately as likely to be malware as the rest of the sites on the list, and that it would make Internet Explorer safer if Microsoft augmented SmartScreen to use the Safe Browsing API as well. So why don't they?

The answer is probably what people have been shouting out from the back of the classroom since the first paragraph: That for political reasons, Microsoft doesn't want to be seen incorporating anything from Google into their own flagship application. It's not news that a company would prefer to promote its products over its rivals'. But this goes beyond, for example, Microsoft bundling Internet Explorer with Windows instead of Google's Chrome browser. Chrome and Internet Explorer do virtually the same thing, so it would look positively odd for Microsoft to promote IE over Chrome. But IE's SmartScreen list and Google's Safe Browsing list can be used simultaneously, providing more protection than either one by itself.

Still, Microsoft has already calculated that it would be an unwise move politically to use Google's Safe Browsing list. So I'm not trying to second-guess the calculation that they made, based on data that was available to them at the time. Rather, I think that if some publicity can increase the political benefit that they could get from using Google's Safe Browsing list in conjunction with SmartScreen (and increase the political cost of not using it), that might lead them to recalculate and make a different decision. To that end, let me raise up a banner that people can gather under if they want to:

Microsoft, we will not think any less of you if you use the Google Safe Browsing API in Internet Explorer in conjunction with the SmartScreen filter! We'll give you credit for setting aside petty rivalries and using the technology of a competitor in order to make users safer.

The IE team's blog post about the initial success of the SmartScreen filter, from March 2009, cited statistics showing 10 million malware blocks in the previous six months, and asked readers to think about those numbers in terms of their impact on real humans and the grief it saved them: "These are BIG numbers — each malicious download blocked helps prevent compromise of that user's computer." Since then, Microsoft has released new statistics showing that SmartScreen has delivered about 70 million blocks since IE8 was officially released. Of course, not every one of those blocks made the difference between infecting a machine with spyware and keeping it clean (many users wouldn't have downloaded or installed the software that the website was trying to send them), but the IE team is right to be proud anyway. However that also means that if adding Safe Browsing support to IE resulted in only a small percent increase in the filter's effectiveness, it would mean several million additional malware blocks over the same period, and cumulatively tens of millions of more in the years ahead. Isn't that worth Microsoft forming an alliance with Google, especially if doing that would make them look good?

Frequent contributor Bennett Haselton writes with an idea that he thinks could help keep browsing on Microsoft's browser more secure for users — and benefit Microsoft as a result. "Tests show that IE's malware filter performs well against other browsers that use the Safe Browsing blacklist from Google. But wouldn't IE's filter be even more effective if it used both filter lists at the same time? And are the political obstacles to that really so insurmountable?" Read on for the rest of a plan that seems a lot more than half-baked. Most major browsers now come with a built-in blacklist of malware-infected or phishing websites, that display a warning if the user tries to access them in the browser. Internet Explorer 8 uses Microsoft's SmartScreen filter, while Firefox, Safari and Chrome all use Google's Safe Browsing API. Recent tests from NSS Labs reported that IE's filter blocked 81% of "socially engineered malware sites" from the lab's sample, while Firefox, in second place, blocked only 27%, and other browsers trailed even further behind. When NSS Labs ran a test of the different browsers' efficiency at blocking phishing sites, IE and Firefox scored about the same, both blocking about 80% of the sites in the sample. These results left a lot of unanswered questions, such as: Why Firefox, Safari and Chrome got such different scores in both tests (since they supposedly all use the Safe Browsing blacklist), and why such a huge gap between IE's and Firefox's performance in the malware test, but such close scores for the two browsers in the phishing test (the Google Safe Browsing API page says that the database is an attempt to list both malware and phishing sites, after all).

But I had a different question: Since Google allows anybody to use the Safe Browsing API, why doesn't Internet Explorer use it as well, in conjunction with their own blacklist, so that a site will be blocked by IE if it's present on either list? This would almost certainly increase the block rate for IE (unless the set of sites blocked by Safe Browsing was entirely a subset of the sites blocked by SmartScreen, which is extremely unlikely). Google's Terms of Use for the Safe Browsing API do require parties to obtain written permission for any usage that will result in more than 10,000 users sending "regular requests" to the API, which would obviously include Internet Explorer. But Google already serves requests for all Firefox users who have the SafeBrowsing API turned on, so for them to process requests for all Internet Explorer users might require four or five times as much computing power, not orders of magnitude more. It's impossible to guess what kind of deal Microsoft and Google would make for the right to have IE do lookups on the Safe Browsing API, but if Microsoft placed a dollar value on increasing the protection for their users, and that dollar value exceeded the cost to Google of running the servers to process the additional queries, then in theory they should be able to agree on a price between those two amounts. Google might well offer to service the queries for free, just for the prestige of being able to say that the Safe Browsing database provided protection for almost all major browsers on the market.

(Microsoft's SmartScreen team declined to comment on the record about their reasons for not using the Safe Browsing list in addition to their own database. I couldn't get an official response from Google about what position they would have on Internet Explorer using the Safe Browsing list, although unofficially an employee said the team would probably be "delighted" if IE were to use it.)

It's worth underlining what a strong statement Microsoft is making by not using the Safe Browsing list. They're not just saying that their own list is better. They're saying that the Safe Browsing list is of such low quality that adding it to their own product would actually make the product worse.

This is different from, for example, what McAfee and Symantec might say about each other's anti-virus lists. Consider the set of all viruses that McAfee blocks and the set of all viruses that Symantec blocks. Let List X be the overlap — the huge swath of viruses that are blocked by both McAfee and Symantec. Then let List Y be the set of all viruses that are blocked by McAfee but not blocked by Symantec, and let list Z be the set of all viruses that are blocked by Symantec but not by McAfee. (So McAfee blocks viruses in the set X+Y, and Symantec blocks viruses in the set X+Z.) Now, representatives from McAfee and Symantec will each say that their list is the better one, which they may or may not believe. But even McAfee is not claiming that List Z — that portion of the list that is blocked by Symantec but not by McAfee — is so worthless that McAfee wouldn't incorporate it into their own product if they could get it for free. If Symantec allowed any anti-virus maker to download Symantec's anti-virus signature database, then presumably McAfee would scratch their heads a bit about why Symantec would do this, but if they cared about giving their users maximum protection, they would incorporate it into their product as well (so that McAfee would then be blocking all viruses in the set X+Y+Z, instead of just the set X+Y as they were before). But Symantec doesn't make it available for free, so McAfee doesn't have the option of using it and the issue doesn't come up. Other than each company claiming their product is the better one (which is par for the course for competitors), the two companies' positions are not contradicting each other.

But consider the analogous situation for anti-malware lists, where X is the set of all sites blocked by both IE's SmartScreen and by the Google Safe Browsing API, Y is the set of all sites blocked by SmartScreen but not by the Safe Browsing API, and Z is the set of all sites blocked by the Safe Browsing API but not by SmartScreen. When Microsoft says that they don't want to use the Safe Browsing list in addition to their own — that they would rather block just X+Y than block X+Y+Z — they're saying that they're estimating that the list Z is of such poor quality (too much risk of containing too many false positives) that it would be better not to block it at all.

In this case, Microsoft's position really is contradicting that of Google, Firefox, Safari, and others who use the Google Safe Browsing API. To achieve the best tradeoff between user safety and convenience, should the sites on List Z — the set of sites on the Safe Browsing API blacklist but not on the SmartScreen blacklist — be blocked, or not? If the answer is Yes, then IE should use the Safe Browsing API in addition to their own SmartScreen list. If the answer is No, then Google should take the URLs in the Safe Browsing API list, run them through IE using some automated script, and then remove all the URLs that weren't blocked by IE — in other words, remove all the URLs on List Z from the Safe Browsing blacklist. But I can think of no consistent set of assumptions that would lead one to recommend that both companies continue doing what they're doing now — that IE should continue not to use the Safe Browsing API, and that Google should continue publishing the Safe Browsing API without trimming URLs that aren't also blocked by IE. Microsoft is saying that the URLs on List Z should not be blocked; Google is saying that they should be.

(Note that this argument is independent of the relative weights that you assign to the benefit of blocking a genuinely malicious site, versus the cost of accidentally blocking a site which is not malicious. Different users might assign different values to these costs and benefits, and depending on what values they assign, those users would want different thresholds to be used in deciding whether to block a site or not. And Microsoft and Google have picked default thresholds that they estimate will meet the needs of the average user. But no matter what values you assign to the benefit of blocking a malicious site and the penalty for blocking a false positive, it's still the case that blocking the sites on List Z either does increases the total cost/benefit score — in which case IE should block sites on the Safe Browsing list in addition to its own — or it doesn't — in which case Google should remove sites from the Safe Browsing list that aren't blocked by SmartScreen.)

I suspect, of course, that the answer is the former — that the set of sites on List Z, those which are blocked by the Safe Browsing API but not blocked by SmartScreen, are probably approximately as likely to be malware as the rest of the sites on the list, and that it would make Internet Explorer safer if Microsoft augmented SmartScreen to use the Safe Browsing API as well. So why don't they?

The answer is probably what people have been shouting out from the back of the classroom since the first paragraph: That for political reasons, Microsoft doesn't want to be seen incorporating anything from Google into their own flagship application. It's not news that a company would prefer to promote its products over its rivals'. But this goes beyond, for example, Microsoft bundling Internet Explorer with Windows instead of Google's Chrome browser. Chrome and Internet Explorer do virtually the same thing, so it would look positively odd for Microsoft to promote IE over Chrome. But IE's SmartScreen list and Google's Safe Browsing list can be used simultaneously, providing more protection than either one by itself.

Still, Microsoft has already calculated that it would be an unwise move politically to use Google's Safe Browsing list. So I'm not trying to second-guess the calculation that they made, based on data that was available to them at the time. Rather, I think that if some publicity can increase the political benefit that they could get from using Google's Safe Browsing list in conjunction with SmartScreen (and increase the political cost of not using it), that might lead them to recalculate and make a different decision. To that end, let me raise up a banner that people can gather under if they want to:

Microsoft, we will not think any less of you if you use the Google Safe Browsing API in Internet Explorer in conjunction with the SmartScreen filter! We'll give you credit for setting aside petty rivalries and using the technology of a competitor in order to make users safer.

The IE team's blog post about the initial success of the SmartScreen filter, from March 2009, cited statistics showing 10 million malware blocks in the previous six months, and asked readers to think about those numbers in terms of their impact on real humans and the grief it saved them: "These are BIG numbers — each malicious download blocked helps prevent compromise of that user's computer." Since then, Microsoft has released new statistics showing that SmartScreen has delivered about 70 million blocks since IE8 was officially released. Of course, not every one of those blocks made the difference between infecting a machine with spyware and keeping it clean (many users wouldn't have downloaded or installed the software that the website was trying to send them), but the IE team is right to be proud anyway. However that also means that if adding Safe Browsing support to IE resulted in only a small percent increase in the filter's effectiveness, it would mean several million additional malware blocks over the same period, and cumulatively tens of millions of more in the years ahead. Isn't that worth Microsoft forming an alliance with Google, especially if doing that would make them look good?

Frequent contributor Bennett Haselton writes with an idea that he thinks could help keep browsing on Microsoft's browser more secure for users — and benefit Microsoft as a result. "Tests show that IE's malware filter performs well against other browsers that use the Safe Browsing blacklist from Google. But wouldn't IE's filter be even more effective if it used both filter lists at the same time? And are the political obstacles to that really so insurmountable?" Read on for the rest of a plan that seems a lot more than half-baked. Most major browsers now come with a built-in blacklist of malware-infected or phishing websites, that display a warning if the user tries to access them in the browser. Internet Explorer 8 uses Microsoft's SmartScreen filter, while Firefox, Safari and Chrome all use Google's Safe Browsing API. Recent tests from NSS Labs reported that IE's filter blocked 81% of "socially engineered malware sites" from the lab's sample, while Firefox, in second place, blocked only 27%, and other browsers trailed even further behind. When NSS Labs ran a test of the different browsers' efficiency at blocking phishing sites, IE and Firefox scored about the same, both blocking about 80% of the sites in the sample. These results left a lot of unanswered questions, such as: Why Firefox, Safari and Chrome got such different scores in both tests (since they supposedly all use the Safe Browsing blacklist), and why such a huge gap between IE's and Firefox's performance in the malware test, but such close scores for the two browsers in the phishing test (the Google Safe Browsing API page says that the database is an attempt to list both malware and phishing sites, after all).

But I had a different question: Since Google allows anybody to use the Safe Browsing API, why doesn't Internet Explorer use it as well, in conjunction with their own blacklist, so that a site will be blocked by IE if it's present on either list? This would almost certainly increase the block rate for IE (unless the set of sites blocked by Safe Browsing was entirely a subset of the sites blocked by SmartScreen, which is extremely unlikely). Google's Terms of Use for the Safe Browsing API do require parties to obtain written permission for any usage that will result in more than 10,000 users sending "regular requests" to the API, which would obviously include Internet Explorer. But Google already serves requests for all Firefox users who have the SafeBrowsing API turned on, so for them to process requests for all Internet Explorer users might require four or five times as much computing power, not orders of magnitude more. It's impossible to guess what kind of deal Microsoft and Google would make for the right to have IE do lookups on the Safe Browsing API, but if Microsoft placed a dollar value on increasing the protection for their users, and that dollar value exceeded the cost to Google of running the servers to process the additional queries, then in theory they should be able to agree on a price between those two amounts. Google might well offer to service the queries for free, just for the prestige of being able to say that the Safe Browsing database provided protection for almost all major browsers on the market.

(Microsoft's SmartScreen team declined to comment on the record about their reasons for not using the Safe Browsing list in addition to their own database. I couldn't get an official response from Google about what position they would have on Internet Explorer using the Safe Browsing list, although unofficially an employee said the team would probably be "delighted" if IE were to use it.)

It's worth underlining what a strong statement Microsoft is making by not using the Safe Browsing list. They're not just saying that their own list is better. They're saying that the Safe Browsing list is of such low quality that adding it to their own product would actually make the product worse.

This is different from, for example, what McAfee and Symantec might say about each other's anti-virus lists. Consider the set of all viruses that McAfee blocks and the set of all viruses that Symantec blocks. Let List X be the overlap — the huge swath of viruses that are blocked by both McAfee and Symantec. Then let List Y be the set of all viruses that are blocked by McAfee but not blocked by Symantec, and let list Z be the set of all viruses that are blocked by Symantec but not by McAfee. (So McAfee blocks viruses in the set X+Y, and Symantec blocks viruses in the set X+Z.) Now, representatives from McAfee and Symantec will each say that their list is the better one, which they may or may not believe. But even McAfee is not claiming that List Z — that portion of the list that is blocked by Symantec but not by McAfee — is so worthless that McAfee wouldn't incorporate it into their own product if they could get it for free. If Symantec allowed any anti-virus maker to download Symantec's anti-virus signature database, then presumably McAfee would scratch their heads a bit about why Symantec would do this, but if they cared about giving their users maximum protection, they would incorporate it into their product as well (so that McAfee would then be blocking all viruses in the set X+Y+Z, instead of just the set X+Y as they were before). But Symantec doesn't make it available for free, so McAfee doesn't have the option of using it and the issue doesn't come up. Other than each company claiming their product is the better one (which is par for the course for competitors), the two companies' positions are not contradicting each other.

But consider the analogous situation for anti-malware lists, where X is the set of all sites blocked by both IE's SmartScreen and by the Google Safe Browsing API, Y is the set of all sites blocked by SmartScreen but not by the Safe Browsing API, and Z is the set of all sites blocked by the Safe Browsing API but not by SmartScreen. When Microsoft says that they don't want to use the Safe Browsing list in addition to their own — that they would rather block just X+Y than block X+Y+Z — they're saying that they're estimating that the list Z is of such poor quality (too much risk of containing too many false positives) that it would be better not to block it at all.

In this case, Microsoft's position really is contradicting that of Google, Firefox, Safari, and others who use the Google Safe Browsing API. To achieve the best tradeoff between user safety and convenience, should the sites on List Z — the set of sites on the Safe Browsing API blacklist but not on the SmartScreen blacklist — be blocked, or not? If the answer is Yes, then IE should use the Safe Browsing API in addition to their own SmartScreen list. If the answer is No, then Google should take the URLs in the Safe Browsing API list, run them through IE using some automated script, and then remove all the URLs that weren't blocked by IE — in other words, remove all the URLs on List Z from the Safe Browsing blacklist. But I can think of no consistent set of assumptions that would lead one to recommend that both companies continue doing what they're doing now — that IE should continue not to use the Safe Browsing API, and that Google should continue publishing the Safe Browsing API without trimming URLs that aren't also blocked by IE. Microsoft is saying that the URLs on List Z should not be blocked; Google is saying that they should be.

(Note that this argument is independent of the relative weights that you assign to the benefit of blocking a genuinely malicious site, versus the cost of accidentally blocking a site which is not malicious. Different users might assign different values to these costs and benefits, and depending on what values they assign, those users would want different thresholds to be used in deciding whether to block a site or not. And Microsoft and Google have picked default thresholds that they estimate will meet the needs of the average user. But no matter what values you assign to the benefit of blocking a malicious site and the penalty for blocking a false positive, it's still the case that blocking the sites on List Z either does increases the total cost/benefit score — in which case IE should block sites on the Safe Browsing list in addition to its own — or it doesn't — in which case Google should remove sites from the Safe Browsing list that aren't blocked by SmartScreen.)

I suspect, of course, that the answer is the former — that the set of sites on List Z, those which are blocked by the Safe Browsing API but not blocked by SmartScreen, are probably approximately as likely to be malware as the rest of the sites on the list, and that it would make Internet Explorer safer if Microsoft augmented SmartScreen to use the Safe Browsing API as well. So why don't they?

The answer is probably what people have been shouting out from the back of the classroom since the first paragraph: That for political reasons, Microsoft doesn't want to be seen incorporating anything from Google into their own flagship application. It's not news that a company would prefer to promote its products over its rivals'. But this goes beyond, for example, Microsoft bundling Internet Explorer with Windows instead of Google's Chrome browser. Chrome and Internet Explorer do virtually the same thing, so it would look positively odd for Microsoft to promote IE over Chrome. But IE's SmartScreen list and Google's Safe Browsing list can be used simultaneously, providing more protection than either one by itself.

Still, Microsoft has already calculated that it would be an unwise move politically to use Google's Safe Browsing list. So I'm not trying to second-guess the calculation that they made, based on data that was available to them at the time. Rather, I think that if some publicity can increase the political benefit that they could get from using Google's Safe Browsing list in conjunction with SmartScreen (and increase the political cost of not using it), that might lead them to recalculate and make a different decision. To that end, let me raise up a banner that people can gather under if they want to:

Microsoft, we will not think any less of you if you use the Google Safe Browsing API in Internet Explorer in conjunction with the SmartScreen filter! We'll give you credit for setting aside petty rivalries and using the technology of a competitor in order to make users safer.

The IE team's blog post about the initial success of the SmartScreen filter, from March 2009, cited statistics showing 10 million malware blocks in the previous six months, and asked readers to think about those numbers in terms of their impact on real humans and the grief it saved them: "These are BIG numbers — each malicious download blocked helps prevent compromise of that user's computer." Since then, Microsoft has released new statistics showing that SmartScreen has delivered about 70 million blocks since IE8 was officially released. Of course, not every one of those blocks made the difference between infecting a machine with spyware and keeping it clean (many users wouldn't have downloaded or installed the software that the website was trying to send them), but the IE team is right to be proud anyway. However that also means that if adding Safe Browsing support to IE resulted in only a small percent increase in the filter's effectiveness, it would mean several million additional malware blocks over the same period, and cumulatively tens of millions of more in the years ahead. Isn't that worth Microsoft forming an alliance with Google, especially if doing that would make them look good?

Rik van der Kroon writes "Major Dutch cable provider UPC has introduced a new network management system which, from noon to midnight, for certain services and providers, caps users' bandwidth at 1/3rd of their nominal bandwidth (Google translation; Dutch original here). After the consumer front for cable providers in The Netherlands received many complaints about network problems and slow speeds, UPC decided to take this as an excuse to introduce their new 'network management' protocol which slows down a large amount of traffic. All protocols but HTTP are capped to 1/3 speed, and within the HTTP realm some Web sites and services that use lots of upstream bandwidth are capped as well. So far UPC is hiding behind the usual excuse: 'We are protecting all the users against the 1% of the user base who abuse our network.'"

Noam.of.Doom writes "The Google Chrome developers announced on August 19th the immediate availability of a new version of the Google Chrome web browser for Linux, Windows and Macintosh operating systems. Google Chrome 4.0.202.2 is here to fix a lot of annoying bugs (see below for details) and it also adds a couple of features only for the Mac platform. However, the good news is that Dean McNamee, one of the Google Chrome engineers, announced yesterday on their mailing list that a working port of the Chrome browser for 64-bit platforms is now available: 'The v8 team did some amazing work this quarter building a working 64-bit port. After a handful of changes on the Chromium side, I've had Chromium Linux building on 64-bit for the last few weeks. I believe mmoss or tony is going to get a buildbot running, and working on packaging.' Until today, Google Chrome was available on both 32- and 64-bit architectures, but it appears that the latter was running based on the 32-bit libraries. Therefore, starting with Google Chrome 4.0.202.2, 64-bit users can enjoy a true x64 version!"

Professor_Quail notes an AP story that begins, "Mexico enacted a controversial law Thursday decriminalizing possession of small amounts of marijuana, cocaine, heroin and other drugs while encouraging free government treatment for drug dependency. The law sets out maximum 'personal use' amounts for drugs, also including LSD and methamphetamine. People detained with those quantities will no longer face criminal prosecution when the law goes into effect Friday." An official in the attorney general's office said, "This is not legalization, this is regulating the issue and giving citizens greater legal certainty... for a practice that was already in place." In 2006, the US criticized a similar bill that had no provisions for mandatory treatment, and the then-president sent it back to Congress for reconsideration.

theodp writes "If you're brilliant, work really hard, and earn a world-class doctorate from a US university, IBM has a job for you at one of its US research sites — as a 'complementary worker' (as this 1996 piece defined the then-emerging term). But be prepared to ship out to India or China after you've soaked up knowledge for 13 months as a 'long-term supplemental worker.' Newsweek sketches some of the bigger picture, reporting that IBM, HP, Accenture, and others are finding it profitable to detach from the United States (even patenting the process). 'IBM is one of the multinationals that propelled America to the apex of its power, and it is now emblematic of the process of creative destruction pushing America to a new, less dominant, and less comfortable position.'"

glow-in-the-dark writes "The Swiss office for Data Protection has asked Google to turn off Street View within the country because it doesn't meet the conditions demanded when permission was given to go ahead with the photography. Google answered privacy concerns with the following points (I'm translating them from German; here's an automated translation): 'Google will publish in advance where it is going to record the images, so you can act accordingly.' Do they want you to hide? Where is the real obligation here? 'Google has made masking the images of people and car license plates obligatory.' I think this is where trouble starts, because their permission to go ahead appears to have been dependent on how well they did this. I have browsed one particular town as an experiment and was quite quickly able to find unmasked faces. This means that either the algorithm they use doesn't work, or that it is done manually and they've fallen behind (in which case they should not have put up the images). 'Although a picture of a home is generally not covered under Data Protection, Google has agreed to remove them if asked. Follow the same process as removing a person.' I think it wouldn't be half as bad if the pictures weren't taken with a high enough resolution to see inside a house. In short, Google has not been given the easy ride it had in other countries regarding Street View. I actually suspect there is more to come."

glow-in-the-dark writes "The Swiss office for Data Protection has asked Google to turn off Street View within the country because it doesn't meet the conditions demanded when permission was given to go ahead with the photography. Google answered privacy concerns with the following points (I'm translating them from German; here's an automated translation): 'Google will publish in advance where it is going to record the images, so you can act accordingly.' Do they want you to hide? Where is the real obligation here? 'Google has made masking the images of people and car license plates obligatory.' I think this is where trouble starts, because their permission to go ahead appears to have been dependent on how well they did this. I have browsed one particular town as an experiment and was quite quickly able to find unmasked faces. This means that either the algorithm they use doesn't work, or that it is done manually and they've fallen behind (in which case they should not have put up the images). 'Although a picture of a home is generally not covered under Data Protection, Google has agreed to remove them if asked. Follow the same process as removing a person.' I think it wouldn't be half as bad if the pictures weren't taken with a high enough resolution to see inside a house. In short, Google has not been given the easy ride it had in other countries regarding Street View. I actually suspect there is more to come."

stelt writes "Scalable Vector Graphics (SVG) is in most graphical tools. It is used heavily in many big projects, such as KDE and Wikipedia. But Internet Explorer's lack of built-in support for SVG was keeping it away from mainstream use on the web. Google is fixing that now with a JavaScript drop-in named SVGWeb. They've posted a quick, one-minute overview, a longer and more detailed presentation, and you can read about it on the project page."

An anonymous reader writes to tell us that while scientists may have learned how to forge DNA, it appears that a group of Israeli scientists has created a DNA authentication method that is able to distinguish between real and faked DNA samples. "The new process was tested on natural and artificial samples of blood, saliva and touched surfaces, with complete success, Nucleix said. It also identifies 'contaminated' DNA that has been mixed with two or more samples."

stevel writes "Holly Ramer, who lives in Concord, NH, has never been to the Federated States of Micronesia, but debt collectors dun her mercilessly for unpaid loans taken out by a small business owner in that Pacific island nation. Why? Micronesia and other countries in the region have their own Social Security Administrations which gave out numbers to residents applying for US disaster relief loans. The catch is that the Micronesian SSNs have fewer digits than the nine-digit US version, and when credit bureaus entered these into their database, they padded them out with zeros on the front. These numbers then matched innocent US citizens with SSNs beginning with zeroes, as many in northern New England do. The credit bureaus say to call the Social Security Administration, the SSA says call the credit bureaus, the FTC says they can't help, and nobody is taking responsibility for the confusion."

I Don't Believe in Imaginary Property writes "After the permanent injunction barring Microsoft from selling Microsoft Word, many armchair lawyers and pundits wondered how the ruling would affect OpenOffice. The company with the patent, i4i, believes that OpenOffice does not infringe upon it. But lest anyone think that therefore ODF will win out over OOXML, keep in mind that Microsoft has its own broad XML document patent, which issued just two weeks ago, having been filed in December 2004, and they're telling the Supreme Court to apply the Bilski ruling narrowly, so that it doesn't invalidate patents like theirs (and i4i's). After all, unlike most companies and individuals, Microsoft can afford $290 million infringement fines. Then again, given that Microsoft's new patent has only two independent claims (claim #1 and claim #12), and both of those claims 'comprise' something using an 'XML file format for documents associated with an application having a rich set of features,' maybe they wouldn't be that hard to work around if you just make sure any otherwise infringing format is only associated with an application lacking in the feature richness department."

An anonymous reader writes "COLLADA — the group creating open 3D data standards — announced their latest contest winners at Siggraph 2009. Ordinarily this wouldn't interest me, but the grand prize winner, NaviCAD, really did submit something rather interesting — an iPhone app that lets you explore Google 3D Warehouse models. Of course there's the pinching for zooming in/out, but it also uses the motion sensor to control the view. If you are walking around the inside or outside of a building, as you look around in the real world the view on the iPhone displays the corresponding view."

snitch writes with this snippet from InfoQ about the current state of Google Wave: "With the Google Wave Preview scheduled for public availability on September 30th, Wave API Tech Lead Douwe Osinga has posted on the Wave Google Group about what the team has been working on along with some future directions. Up until now, with the limited availability of testing accounts there have been complaints on the Google Group from users that wanted to get their hands on this new technology but didn't have access to the sandbox. As Douwe explains, the team has been busy all this time with stability issues and more."

snitch writes with this snippet from InfoQ about the current state of Google Wave: "With the Google Wave Preview scheduled for public availability on September 30th, Wave API Tech Lead Douwe Osinga has posted on the Wave Google Group about what the team has been working on along with some future directions. Up until now, with the limited availability of testing accounts there have been complaints on the Google Group from users that wanted to get their hands on this new technology but didn't have access to the sandbox. As Douwe explains, the team has been busy all this time with stability issues and more."

snitch writes with this snippet from InfoQ about the current state of Google Wave: "With the Google Wave Preview scheduled for public availability on September 30th, Wave API Tech Lead Douwe Osinga has posted on the Wave Google Group about what the team has been working on along with some future directions. Up until now, with the limited availability of testing accounts there have been complaints on the Google Group from users that wanted to get their hands on this new technology but didn't have access to the sandbox. As Douwe explains, the team has been busy all this time with stability issues and more."

snitch writes with this snippet from InfoQ about the current state of Google Wave: "With the Google Wave Preview scheduled for public availability on September 30th, Wave API Tech Lead Douwe Osinga has posted on the Wave Google Group about what the team has been working on along with some future directions. Up until now, with the limited availability of testing accounts there have been complaints on the Google Group from users that wanted to get their hands on this new technology but didn't have access to the sandbox. As Douwe explains, the team has been busy all this time with stability issues and more."

snitch writes with this snippet from InfoQ about the current state of Google Wave: "With the Google Wave Preview scheduled for public availability on September 30th, Wave API Tech Lead Douwe Osinga has posted on the Wave Google Group about what the team has been working on along with some future directions. Up until now, with the limited availability of testing accounts there have been complaints on the Google Group from users that wanted to get their hands on this new technology but didn't have access to the sandbox. As Douwe explains, the team has been busy all this time with stability issues and more."

Handbrewer writes "The FreeBSD developer Poul-Henning Kamp (phk) has sued Lenovo in Denmark (Google translation, original here) over their refusal to refund the Windows Vista Business license, even though he declined the EULA during installation. Lenovo argues that they sell the computer as a full product, and that they cannot refund it partially, such as the power supply or the OS even if people intend to use a different one. This seems to be contrary to previous rulings in the EU where Acer and HP has been forced to refund the 'Microsoft tax.'"

Slashdot regular Bennett Haselton writes with his take on the news we discussed early this morning about the UK government's prosecution of two people who refused to disclose their encryption keys: "Is it possible to write a program that enables you to encrypt files without drawing suspicion upon yourself if anyone ever seizes your computer? No; a program by itself, no matter how perfectly written, couldn't do this because you'd still attract suspicion just for possessing the software. You'd need a social element driving the program's popularity until it gets to the point where people no longer look suspicious just for having the program installed. Here are some theories on how that could happen — but it would be a high bar to clear." Hit the link below for the rest of Bennett's thoughts.

Police in Britain have announced that two people have successfully been prosecuted under a UK law that forces defendants to give up their encryption keys and penalizes those who don't comply. Another UK woman's case had attracted attention two years ago, when the government demanded she give up her encryption keys after the police found encryption software on her computer, but the police say she was not one of the two defendant's charged. Is there a software solution to this problem — a way that people can encrypt files on their computers, without arousing the suspicion of law enforcement if the computers are seized?

File encryption, if properly implemented, is generally considered mathematically unbreakable. But to prevent suspicion falling on people just for encrypting files in the first place, requires a human solution as well as an engineering one. One way or another, some file encryption software would have to be in widespread use that has these two properties: (1) it's deployed on a large number of people's machines — not just a large absolute number, but a significant proportion of the total population, so that suspicion does not fall on people just for possessing the software — and (2) it should not be possible to tell the difference between machines where the users use the software regularly, and machines where the software has never been run. Then, and only then, would it be possible to use the encryption software on your machine, without anyone who seizes the machine having reason to think that you had ever encrypted anything at all.

(Of course, in a relatively free society, if law enforcement has probable cause to seize your machine in the first place, then they would presumably already have some evidence against you. But this would at least prevent police officers and judges from becoming more suspicious as a result of encryption software being present on your machine.)

Note that this is similar to the kind of problem that is normally solved with steganography, but by my reasoning, I don't think that using stego would actually gain anything in this situation. Whether you're talking about encryption software or stego software, if it's a program that not a lot of people have installed, then just by virtue of having it on your machine, you'll attract suspicion if your machine is seized. On the other hand, suppose you've cleared that hurdle and the software is installed on a lot of people's computers, so that just having installed it is not by itself grounds for suspicion. If it's stego, then you can embed the hidden data inside other images or videos, so that an intruder can't tell whether you've been using the software to hide anything (assuming the stego software is good enough that the intruder can't tell the images have been tampered with). But you could achieve the same thing with straight encryption software: just have every installation of the program create a "storage volume" file, where encrypted files will be stored. As long as a storage volume file with files embedded in it, is indistinguishable from a storage volume file that has never been touched, the presence of the storage volume file won't give you away.

I'm not actually aware of any encryption program that has that property: that for a given machine with the software installed, it's impossible to tell whether the software has ever been used to encrypt data. This is probably because this would normally not be a useful feature of an encryption program. The whole point of making it impossible to tell whether someone has used the program or not, is that people who have used the program would not attract undue attention to themselves as a result. But if the encryption program is only used by one thousandth of one percent of total Internet users anyway, then just the fact that a user has the program installed, would be enough to draw suspicion to the user if their computer is seized, so there's no benefit to concealing the fact that the program has been used. On the other hand, if the encryption program is installed on a significant proportion of users' machines anyway, then simply having the program installed is no longer grounds for suspicion. And that's when it would become a valuable feature for it to be difficult to tell whether the owner of the machine actually uses the encryption program or not.

This may be hard to implement correctly, and there are some tradeoffs that will have to be decided. For example, if the program creates a default "storage volume" file when it's installed, how big should that initial volume be? The problem with creating a small storage file initially and then letting it grow as encrypted files are added, is that this now makes it easy to tell who is using the program and who isn't — anyone whose storage file has grown beyond the default size, is using it to encrypt files (and is therefore a terrorist movie-downloading child pornographer, etc.). In order to avoid suspicion falling on people who use the program, the storage file would have to be the same size on everyone's computer. If you make it 1 GB, that wastes a lot of space on people's machines who aren't using it. On the other hand, if it's only 1 GB, it also means that users will only be able to store up to 1 GB of encrypted data — any more than that, and they'll have to expand the size of the storage file, thus calling attention to themselves if the machine is ever seized. And then, what about the fact that a large file which is created all at once, is normally not fragmented very much, but if the storage file is frequently modified, it is likely to become more and more fragmented — thus giving people a way to tell if the encryption program is being used frequently. (So you'd either have to deliberately create a very fragmented storage file by default on the first install, or create an unfragmented file on first install but then make sure to read and write from the file in a way that doesn't fragment it further.) I don't want to get too bogged down in implementation details. The point is just that you'd have to block all the possible ways that an intruder would be able to tell whether the software is used frequently — forget one thing, and you've given an intruder a way to identify people who are actually using the software to encrypt files.

A program called TrueCrypt achieves something close to this — TrueCrypt allows you to encrypt a storage volume with two different passwords, so that one password provides access to "innocent-looking" data, while the other password provides access to the data that you really want to keep secure. If someone is compelled to give up their password, they could provide only the password that unlocks the "innocent-looking" data — and there's no way, from examining the encrypted file, to tell that there is a second password guarding even-more secret data. (Of course, the "innocent-looking" data can't be truly innocent-looking, because it has to look like the kind of thing that someone would believe you might want to encrypt — so it should look suspicious enough that you would genuinely want to hide it, but not bad enough to get you in real trouble if you're forced to reveal it!) The Achilles heel of this scheme is that just having TrueCrypt on your computer in the first place, would at least signal to an intruder that you're encrypting files. And even if they can't prove that you might have another "super-secret password" guarding more private data on your encrypted volume, they would certainly suspect it, if they already had grounds to be investigating you and if they knew anything about how TrueCrypt works. To provide true plausible deniability of any encryption at all, you need a program that already exists on lots of people's machines, so that an intruder doesn't suspect anything when they find it on your computer.

(The same objection also applies to many other non-solutions to the problem, like using a Linux distro that encrypts your entire file system. Even assuming this would be within the technical means of the average person who wanted to do encryption, it's still going to look suspicious as long as the vast majority of people are not doing it.)

Which leads to the other half of the problem, which is getting the software widely deployed enough that it would not look suspicious for someone to have the program installed in the first place. Best of all for the purpose of avoiding suspicion, of course, would be for the program to come installed by default with a popular operating system. Windows XP and Vista have the built-in ability to encrypt folders, but anyone who seizes the machine can still see that you encrypted a folder, so this don't have the undetectability factor. Built-in deniable encryption of the kind that I'm describing, doesn't instinctively feel like the sort of thing that Microsoft would start bundling with its operating system. (Among other things, they might say that while companies often have business reasons for encrypting files, it's harder to think of a business case where employees would need to encrypt files and hide the fact that they were encrypting anything.)

Perhaps instead it could be bundled with a popular free software program beholden to no for-profit corporate masters. (My first thought was Firefox, but I was quickly told that Firefox was created specifically to strip out many of the features that had caused bloat in the original Mozilla project, and that any bundling of unnecessary tools would go against the whole ethos of the project.) Maybe a good place to include something like this would be the Google Pack — it's installed by lots of people, and currently doesn't have a file-encryption tool in the bundle. Beholden to for-profit corporate masters, yes, but ones that frequently declare "Don't Be Evil" and often seem to do cool stuff just to see what would happen.

Another possibility would be for a next-generation P2P program to bundle this capability with their software. This provides a nice dovetailing of interests — P2P users might want a way to hide the files that they've downloaded, while at the same time, intruders who seize the computer and found the P2P application installed, wouldn't necessarily suspect the owner of anything more than a little copyrighted file trading. "Well, he's got this NiftyP2P program installed, which comes with 'plausibly deniable' encryption, but most people use just NiftyP2P to download mp3 files and movies anyway. And I can't tell if he was actually using the encrypted file storage volume, because that's how 'plausibly deniable' encryption works. Is this the same guy who uploaded those subversive anti-government documents? I dunno."

Anyway, if you actually want to give people a way to run encryption software on their PCs, while ensuring that anyone who seizes their machine cannot tell that any encryption has been going on, these are the hurdles that you'd have to clear. I'm not sure whether this is better viewed as a blueprint for how to achieve this goal, or an argument for why it will probably never happen. There are lots of almost-solutions, like TrueCrypt with its ability to encrypt different sets of data into the same storage volume. But you still can't actually hide the fact that you're doing encryption in the first place.

(If you're willing to store your encryption software away from your computer, you could keep a steganography program on a CD or USB drive hidden in your house, and then whenever you need access to the encrypted data, plug in the program and use it to extract data that has been hidden in a large number of image or video files. That would achieve the goals I've outlined in the article: the ability to encrypt files, while still ensuring that anyone who seizes your computer won't be able to tell that you've encrypted anything. The problem is that it would require enough self-discipline to always return the CD or USB stick to its hiding place when you were done with it — and still, you'd have to hope that whatever authorities seize your computer, don't also search your house and find the CD or USB stick where you keep your stego software.)

Finally, risking the wrath of my civil-libertarian allies, I'll admit it may not actually be a positive thing for every citizen to be able to hide the fact from their local law enforcement that they're encrypting files on their computer. Many times if the police in a mostly-free country like the US or the UK seize a person's computer, they're trying to prevent real harm, and not every person with an encrypted file volume is a good guy. For some of the people who have left enough of an evidence trail that their computers get seized, it would be perfectly rational to view them with suspicion because of an encrypted volume found on their computer. But if you assume it's a worthwhile goal for people to be able to encrypt files without attracting suspicion, my argument is that the prerequisites in this article are necessary for that to work. At the moment it seems a long way off. But if someone created an encryption program with "deniability" — so that it was impossible to tell whether the program had ever been used after it was installed — and someone at Google thought "Hey, that's cool" and added it to the Google Pack, everything would change very suddenly.

Slashdot regular Bennett Haselton writes with his take on the news we discussed early this morning about the UK government's prosecution of two people who refused to disclose their encryption keys: "Is it possible to write a program that enables you to encrypt files without drawing suspicion upon yourself if anyone ever seizes your computer? No; a program by itself, no matter how perfectly written, couldn't do this because you'd still attract suspicion just for possessing the software. You'd need a social element driving the program's popularity until it gets to the point where people no longer look suspicious just for having the program installed. Here are some theories on how that could happen — but it would be a high bar to clear." Hit the link below for the rest of Bennett's thoughts.

Police in Britain have announced that two people have successfully been prosecuted under a UK law that forces defendants to give up their encryption keys and penalizes those who don't comply. Another UK woman's case had attracted attention two years ago, when the government demanded she give up her encryption keys after the police found encryption software on her computer, but the police say she was not one of the two defendant's charged. Is there a software solution to this problem — a way that people can encrypt files on their computers, without arousing the suspicion of law enforcement if the computers are seized?

File encryption, if properly implemented, is generally considered mathematically unbreakable. But to prevent suspicion falling on people just for encrypting files in the first place, requires a human solution as well as an engineering one. One way or another, some file encryption software would have to be in widespread use that has these two properties: (1) it's deployed on a large number of people's machines — not just a large absolute number, but a significant proportion of the total population, so that suspicion does not fall on people just for possessing the software — and (2) it should not be possible to tell the difference between machines where the users use the software regularly, and machines where the software has never been run. Then, and only then, would it be possible to use the encryption software on your machine, without anyone who seizes the machine having reason to think that you had ever encrypted anything at all.

(Of course, in a relatively free society, if law enforcement has probable cause to seize your machine in the first place, then they would presumably already have some evidence against you. But this would at least prevent police officers and judges from becoming more suspicious as a result of encryption software being present on your machine.)

Note that this is similar to the kind of problem that is normally solved with steganography, but by my reasoning, I don't think that using stego would actually gain anything in this situation. Whether you're talking about encryption software or stego software, if it's a program that not a lot of people have installed, then just by virtue of having it on your machine, you'll attract suspicion if your machine is seized. On the other hand, suppose you've cleared that hurdle and the software is installed on a lot of people's computers, so that just having installed it is not by itself grounds for suspicion. If it's stego, then you can embed the hidden data inside other images or videos, so that an intruder can't tell whether you've been using the software to hide anything (assuming the stego software is good enough that the intruder can't tell the images have been tampered with). But you could achieve the same thing with straight encryption software: just have every installation of the program create a "storage volume" file, where encrypted files will be stored. As long as a storage volume file with files embedded in it, is indistinguishable from a storage volume file that has never been touched, the presence of the storage volume file won't give you away.

I'm not actually aware of any encryption program that has that property: that for a given machine with the software installed, it's impossible to tell whether the software has ever been used to encrypt data. This is probably because this would normally not be a useful feature of an encryption program. The whole point of making it impossible to tell whether someone has used the program or not, is that people who have used the program would not attract undue attention to themselves as a result. But if the encryption program is only used by one thousandth of one percent of total Internet users anyway, then just the fact that a user has the program installed, would be enough to draw suspicion to the user if their computer is seized, so there's no benefit to concealing the fact that the program has been used. On the other hand, if the encryption program is installed on a significant proportion of users' machines anyway, then simply having the program installed is no longer grounds for suspicion. And that's when it would become a valuable feature for it to be difficult to tell whether the owner of the machine actually uses the encryption program or not.

This may be hard to implement correctly, and there are some tradeoffs that will have to be decided. For example, if the program creates a default "storage volume" file when it's installed, how big should that initial volume be? The problem with creating a small storage file initially and then letting it grow as encrypted files are added, is that this now makes it easy to tell who is using the program and who isn't — anyone whose storage file has grown beyond the default size, is using it to encrypt files (and is therefore a terrorist movie-downloading child pornographer, etc.). In order to avoid suspicion falling on people who use the program, the storage file would have to be the same size on everyone's computer. If you make it 1 GB, that wastes a lot of space on people's machines who aren't using it. On the other hand, if it's only 1 GB, it also means that users will only be able to store up to 1 GB of encrypted data — any more than that, and they'll have to expand the size of the storage file, thus calling attention to themselves if the machine is ever seized. And then, what about the fact that a large file which is created all at once, is normally not fragmented very much, but if the storage file is frequently modified, it is likely to become more and more fragmented — thus giving people a way to tell if the encryption program is being used frequently. (So you'd either have to deliberately create a very fragmented storage file by default on the first install, or create an unfragmented file on first install but then make sure to read and write from the file in a way that doesn't fragment it further.) I don't want to get too bogged down in implementation details. The point is just that you'd have to block all the possible ways that an intruder would be able to tell whether the software is used frequently — forget one thing, and you've given an intruder a way to identify people who are actually using the software to encrypt files.

A program called TrueCrypt achieves something close to this — TrueCrypt allows you to encrypt a storage volume with two different passwords, so that one password provides access to "innocent-looking" data, while the other password provides access to the data that you really want to keep secure. If someone is compelled to give up their password, they could provide only the password that unlocks the "innocent-looking" data — and there's no way, from examining the encrypted file, to tell that there is a second password guarding even-more secret data. (Of course, the "innocent-looking" data can't be truly innocent-looking, because it has to look like the kind of thing that someone would believe you might want to encrypt — so it should look suspicious enough that you would genuinely want to hide it, but not bad enough to get you in real trouble if you're forced to reveal it!) The Achilles heel of this scheme is that just having TrueCrypt on your computer in the first place, would at least signal to an intruder that you're encrypting files. And even if they can't prove that you might have another "super-secret password" guarding more private data on your encrypted volume, they would certainly suspect it, if they already had grounds to be investigating you and if they knew anything about how TrueCrypt works. To provide true plausible deniability of any encryption at all, you need a program that already exists on lots of people's machines, so that an intruder doesn't suspect anything when they find it on your computer.

(The same objection also applies to many other non-solutions to the problem, like using a Linux distro that encrypts your entire file system. Even assuming this would be within the technical means of the average person who wanted to do encryption, it's still going to look suspicious as long as the vast majority of people are not doing it.)

Which leads to the other half of the problem, which is getting the software widely deployed enough that it would not look suspicious for someone to have the program installed in the first place. Best of all for the purpose of avoiding suspicion, of course, would be for the program to come installed by default with a popular operating system. Windows XP and Vista have the built-in ability to encrypt folders, but anyone who seizes the machine can still see that you encrypted a folder, so this don't have the undetectability factor. Built-in deniable encryption of the kind that I'm describing, doesn't instinctively feel like the sort of thing that Microsoft would start bundling with its operating system. (Among other things, they might say that while companies often have business reasons for encrypting files, it's harder to think of a business case where employees would need to encrypt files and hide the fact that they were encrypting anything.)

Perhaps instead it could be bundled with a popular free software program beholden to no for-profit corporate masters. (My first thought was Firefox, but I was quickly told that Firefox was created specifically to strip out many of the features that had caused bloat in the original Mozilla project, and that any bundling of unnecessary tools would go against the whole ethos of the project.) Maybe a good place to include something like this would be the Google Pack — it's installed by lots of people, and currently doesn't have a file-encryption tool in the bundle. Beholden to for-profit corporate masters, yes, but ones that frequently declare "Don't Be Evil" and often seem to do cool stuff just to see what would happen.

Another possibility would be for a next-generation P2P program to bundle this capability with their software. This provides a nice dovetailing of interests — P2P users might want a way to hide the files that they've downloaded, while at the same time, intruders who seize the computer and found the P2P application installed, wouldn't necessarily suspect the owner of anything more than a little copyrighted file trading. "Well, he's got this NiftyP2P program installed, which comes with 'plausibly deniable' encryption, but most people use just NiftyP2P to download mp3 files and movies anyway. And I can't tell if he was actually using the encrypted file storage volume, because that's how 'plausibly deniable' encryption works. Is this the same guy who uploaded those subversive anti-government documents? I dunno."

Anyway, if you actually want to give people a way to run encryption software on their PCs, while ensuring that anyone who seizes their machine cannot tell that any encryption has been going on, these are the hurdles that you'd have to clear. I'm not sure whether this is better viewed as a blueprint for how to achieve this goal, or an argument for why it will probably never happen. There are lots of almost-solutions, like TrueCrypt with its ability to encrypt different sets of data into the same storage volume. But you still can't actually hide the fact that you're doing encryption in the first place.

(If you're willing to store your encryption software away from your computer, you could keep a steganography program on a CD or USB drive hidden in your house, and then whenever you need access to the encrypted data, plug in the program and use it to extract data that has been hidden in a large number of image or video files. That would achieve the goals I've outlined in the article: the ability to encrypt files, while still ensuring that anyone who seizes your computer won't be able to tell that you've encrypted anything. The problem is that it would require enough self-discipline to always return the CD or USB stick to its hiding place when you were done with it — and still, you'd have to hope that whatever authorities seize your computer, don't also search your house and find the CD or USB stick where you keep your stego software.)

Finally, risking the wrath of my civil-libertarian allies, I'll admit it may not actually be a positive thing for every citizen to be able to hide the fact from their local law enforcement that they're encrypting files on their computer. Many times if the police in a mostly-free country like the US or the UK seize a person's computer, they're trying to prevent real harm, and not every person with an encrypted file volume is a good guy. For some of the people who have left enough of an evidence trail that their computers get seized, it would be perfectly rational to view them with suspicion because of an encrypted volume found on their computer. But if you assume it's a worthwhile goal for people to be able to encrypt files without attracting suspicion, my argument is that the prerequisites in this article are necessary for that to work. At the moment it seems a long way off. But if someone created an encryption program with "deniability" — so that it was impossible to tell whether the program had ever been used after it was installed — and someone at Google thought "Hey, that's cool" and added it to the Google Pack, everything would change very suddenly.

Google has announced a "developer preview" of a new search infrastructure, though one wouldn't have to be a developer to try it out. Google is asking for feedback on how the search results in the new regime stack up against the old. Matt Cutts has posted a mini FAQ. Some early testing indicates that the new search may be faster in some cases, and return more relevant results, than the old one. Those who attempt to game Google search for a living will be scrambling henceforth. Has anyone identified the new crawler bot in log files?

coffeeisclassy writes "Google's second Android Developer Contest (ADC2) has started, despite some confusion around how to submit applications. The prizes are different from the first ADC, with each category having prizes of 100k, 50k, and 25k and an overall best of 150k,50k and 25k, meaning the best Android application from ADC2 is eligible for ~250k. The rules seem to allow any application never published before August 1st to compete, and the contest is open through the end of August (so break out your keyboards!). The top prizes are certainly less than that of first ADC, but with the prizes broken down by category, Google may be hoping to inspire some love for less popular categories."

coffeeisclassy writes "Google's second Android Developer Contest (ADC2) has started, despite some confusion around how to submit applications. The prizes are different from the first ADC, with each category having prizes of 100k, 50k, and 25k and an overall best of 150k,50k and 25k, meaning the best Android application from ADC2 is eligible for ~250k. The rules seem to allow any application never published before August 1st to compete, and the contest is open through the end of August (so break out your keyboards!). The top prizes are certainly less than that of first ADC, but with the prizes broken down by category, Google may be hoping to inspire some love for less popular categories."

Digital Dan writes "Twitter is being sued for patent infringement. Surprised? OK, probably not, but you'd think the plaintiff would at least wait for Twitter to actually make money before striking. According to TechCrunch: 'Twitter is being sued ... by TechRadium, a Texas-based technology company which makes mass notification systems for public safety organizations, the military, and utilities.' The abstract to patent #7130389 describes it: 'A digital notification and response system utilizes an administrator interface to transmit a message from an administrator to a user contact device. The system comprises a dynamic information database that includes user contact data, priority information, and response data. The administrator initiates distribution of the message based upon grouping information, priority information, and the priority order.' Two other patents are involved as well."

reporter and barnyjr were among the readers alerting us to the discovery of a new strain of the HIV virus, found in a woman from the west central African nation of Cameroon. "It differs from the three known strains of human immunodeficiency virus and appears to be closely related to a form of simian virus recently discovered in wild gorillas, researchers report in Monday's edition of the journal Nature Medicine. ... The most likely explanation for the new find is gorilla-to-human transmission, Plantier's team said. But... they cannot rule out the possibility that the new strain started in chimpanzees and moved into gorillas and then humans, or moved directly from chimpanzees to both gorillas and humans. ... Researchers said it could be circulating unnoticed in Cameroon or elsewhere. The virus's rapid replication indicates that it is adapted to human cells, the researchers reported."

tikurion writes "It's only been a few weeks since the law dubbed Zugangserschwerungsgesetz (access impediment law) was passed in the German Parliament despite over 140,000 signatures of people opposed to it. The law will go into effect in mid-October 2009. Now Minister for Family Affairs Ursula von der Leyen implied in an interview that she is planning on extending the reach of the law, claiming '...or else the great Internet is in danger of turning into a lawless range of chaos, where you're allowed to bully, insult, and deceive limitlessly.' More on golem.de via Google translate (here is the German original)."

NeoBeans writes "According to this article in the New York Times about the recent 'improvements' in military strikes by the Pakistani military it is revealed that they have dropped Google Earth as part of their target planning for a more precise technology. From the article, '... the air force has shifted from using Google Earth to more sophisticated images from spy planes and other surveillance aircraft, and has increased its use of laser-guided bombs. And no, you can't really find Osama Bin Laden using Google Maps either."

Over the past few weeks, the cellphone industry has been criticized on a variety of subjects, from distracted driving to handset exclusivity deals to everything else that's shady within the industry. Verizon's CEO has now responded, addressing what he claims are "myths" about standard practices. Reader DJRumpy points out that the chairman of the Senate Subcommittee on Antitrust, Competition Policy and Consumer Rights has been calling for an investigation into whether competition is being stifled through many of these practices, "including possible text messaging price fixing and questionable roaming arrangements." Apparently the new antitrust chief is hitting resistance from within the government over the aggressive inquiries into this and other major industries. However, a small victory was achieved the other day when the National Telecommunications and Information Administration "told incumbent carriers that they'll have to prove their cases just like everyone else if they want to challenge broadband grant proposals from smaller players." There is also legislation in the works that would require states to impose a ban on text messaging while driving or lose a significant portion of their federal highway funding.

eldavojohn writes "Certainly one of the most important steps in adopting a protocol is a working open source example of it. Well, google has open sourced an implementation of the wave protocol for those of you curious about Google's new collaboration and conversation platform. It's been reviewed, skewered and called 'Anti-Web' but now's your chance to see a Java implementation of it. The article lists it as still rapidly evolving so it might not be prudent to buy into it yet. Any thumbs up or thumbs down from actual users of the new protocol?"

Arguendo writes "A federal appeals court ruled Monday that Blackboard Inc.'s patent on a learning management system is invalid in light of the inventors' own prior software product. We have previously discussed the patent and Blackboard's trial court victory against Desire2Learn. It's not completely over, but this is almost certainly the death knell for Blackboard's patent. If so inclined, you may read the appellate court's decision here (PDF) or on scribd."

Al writes "Microsoft researchers have come up with a novel way to fine-tune the algorithms behind the company's new search engine, Bing: a game that harnesses human computing power to improve the results. Called Page Hunt, the game (which of course requires Silverlight to run) shows users a web page and asks them to figure out a search query that should produce the page within the first five results. The idea is to better understand user behavior and expectations and ultimately improve its search algorithms. Other human-computing projects have sought to digitize out-of-print text (reCAPTCHA) and image labeling (Google Image Labeler). Can Microsoft use a similar approach to gain the edge over its rival? Or does Google already have the edge with SearchWiki, which lets searchers re-rank its results?"

An anonymous reader writes "After months of waiting, the Google Latitude social maps service finally arrived for the iPhone ... but thanks to an Apple rejection of the natively developed app, it's a web app. Says Google on their blog, 'We worked closely with Apple to bring Latitude to the iPhone in a way Apple thought would be best for iPhone users. After we developed a Latitude application for the iPhone, Apple requested we release Latitude as a web application in order to avoid confusion with Maps on the iPhone.' But it gets worse for iPhone users: 'Unfortunately, since there is no mechanism for applications to run in the background on iPhone (which applies to browser-based web apps as well), we're not able to provide continuous background location updates in the same way that we can for Latitude users on Android, BlackBerry, Symbian and Windows Mobile.' Latitude has been sprouting new features lately and is an interesting take on social networking, but it looks like Apple is determined to ensure its users only get a seriously crippled implementation compared to the Android and WinMo versions. PC World put it less politely than Google did, saying, 'Google's new Latitude Web app for iPhone is so hamstrung that Apple customers may be wishing they had a BlackBerry or Android handset instead.'"

An anonymous reader writes "After months of waiting, the Google Latitude social maps service finally arrived for the iPhone ... but thanks to an Apple rejection of the natively developed app, it's a web app. Says Google on their blog, 'We worked closely with Apple to bring Latitude to the iPhone in a way Apple thought would be best for iPhone users. After we developed a Latitude application for the iPhone, Apple requested we release Latitude as a web application in order to avoid confusion with Maps on the iPhone.' But it gets worse for iPhone users: 'Unfortunately, since there is no mechanism for applications to run in the background on iPhone (which applies to browser-based web apps as well), we're not able to provide continuous background location updates in the same way that we can for Latitude users on Android, BlackBerry, Symbian and Windows Mobile.' Latitude has been sprouting new features lately and is an interesting take on social networking, but it looks like Apple is determined to ensure its users only get a seriously crippled implementation compared to the Android and WinMo versions. PC World put it less politely than Google did, saying, 'Google's new Latitude Web app for iPhone is so hamstrung that Apple customers may be wishing they had a BlackBerry or Android handset instead.'"

AnonymousIslander writes "The Information and Privacy Commissioner for the Province of British Columbia has ruled that electronic scanning of driver's licenses (and similar forms of ID) as a condition of entering a bar or nightclub is a violation of BC's Personal Information Privacy Act. The decision (PDF), while dealing with one specific club, will still have ramifications across the entire province. It is not known if the nightclub in question will attempt to appeal the decision in court. A similar decision was reached last year in Alberta. The system in question is known as BarWatch, and has been the target of criticism by many for a number of years. Despite this, a number of bars/nightclubs and restaurants in communities across Canada have installed similar systems, and just days before this decision came down there were calls for the expansion of BarWatch in Victoria to cover restaurants and other establishments serving the post-bar crowds." Similar systems are in use across the US, as we have discussed.

theodp writes "On Tuesday, the USPTO granted Microsoft a patent for 'Email Emotiflags' despite ample evidence of a circa-1996 Lotus Notes precedent called Mood Stamps — sender-chosen emoticons that appear next to inbox messages. Among those seemingly aware of the existence of Mood Stamps is Microsoft Chief Software Architect Ray Ozzie, who appears to have fielded questions about the feature while at Lotus. While simply Googling for 'Email Emotiflags' would have turned up evidence of this prior art (including a Slashdot discussion), the USPTO came up empty after instead going with the more-upscale Google Scholar and patent databases for its search effort. Think we can count on Ozzie to do the right thing and give the USPTO a heads-up?"

I Don't Believe in Imaginary Property writes "Doctor's groups, including the AMA and too many others to list, are supporting the Mayo Clinic in the case Prometheus v. Mayo. The Mayo Clinic alleges that the patents in question merely recite a natural phenomenon: the simple fact that the level of metabolites of a drug in a person's body can tell you how a patient is responding to that drug. The particular metabolites in this case are those of thiopurine drugs and the tests are covered by Prometheus Lab's 6,355,623 and 6,680,302 patents. But these aren't the only 'observational' patents in medicine — they're part of a trend where patents are sought to cover any test using the fact that gene XYZ is an indicator for some disease, or that certain chemicals in a blood sample indicate something about a patient's condition. There are even allegations that certain labs have gone so far as to send blood samples to a university lab, order testing for patented indicators, then sue that university for infringement. Naturally, Prometheus Labs sees this whole story differently, arguing that the Mayo Clinic will profit from treating patients with knowledge patented by them. They have their own supporters, too, such as the American Intellectual Property Law Association." Prometheus doesn't seem to be a classic patent troll; they actually perform the tests for which they have obtained patents.

I Don't Believe in Imaginary Property writes "Doctor's groups, including the AMA and too many others to list, are supporting the Mayo Clinic in the case Prometheus v. Mayo. The Mayo Clinic alleges that the patents in question merely recite a natural phenomenon: the simple fact that the level of metabolites of a drug in a person's body can tell you how a patient is responding to that drug. The particular metabolites in this case are those of thiopurine drugs and the tests are covered by Prometheus Lab's 6,355,623 and 6,680,302 patents. But these aren't the only 'observational' patents in medicine — they're part of a trend where patents are sought to cover any test using the fact that gene XYZ is an indicator for some disease, or that certain chemicals in a blood sample indicate something about a patient's condition. There are even allegations that certain labs have gone so far as to send blood samples to a university lab, order testing for patented indicators, then sue that university for infringement. Naturally, Prometheus Labs sees this whole story differently, arguing that the Mayo Clinic will profit from treating patients with knowledge patented by them. They have their own supporters, too, such as the American Intellectual Property Law Association." Prometheus doesn't seem to be a classic patent troll; they actually perform the tests for which they have obtained patents.

CNETNate writes "Complete with Street View-like panoramas, 3D models of spacecraft now left abandoned on the moon's surface, and guided tours from the voices of Apollo astronauts, Google's recent update to Google Earth marks the 40th anniversary of the Apollo 11 moon landing with an enormous update. It's a collaboration with NASA and other agencies, and follows the launch of Google Earth 5.0 which, amongst other things, added the ability to explore our planet's oceans. There are a number of original creations — such as the 3D mock-up of the Apollo 11 spacecraft and its astronauts — and you can download the new version from Google now."

LinuxScribe tips a piece up at Linux.com with inside details on the design and construction of the Apollo 11 code. There are some analogies to open source development but they are slim. MIT drafted the code — to run on the Apollo Guidance Computer, a device with less grunt than an IBM XT — it had 2K of memory and a 1-MHz clock speed. It was an amazing machine for its time. NASA engineers tested, polished, simulated, and refined the code. "The software was programmed on IBM punch cards. They had 80-columns and were 'assembled' to instruction binary on mainframes... and it took hours. ... During the mission, most of the software code couldn't be changed because it was hard-coded into the hardware, like ROM today... But during pre-launch design simulations, problems that came up in the code could sometimes be finessed by... computer engineers using a small amount of erasable memory that was available for the programs. The software used a low-level assembly language and was controlled using pairs or segments of numbers entered into a square-shaped, numeric-only keyboard called a Display and Keyboard Unit... The two-digit codes stood for 'nouns' or 'verbs,' and were used to enter commands or data, such as spacecraft docking angles or time spans for operations." Reader Smark adds, "The Google Code Blog announced today that the Virtual AGC and AGS project has transcribed the Command Module and Lunar Excursion Module code used during the Apollo 11 moon landing. The code is viewable at the VirtualAGC Google Code Page."

Wired has a feature on noctilucent clouds, once seen only at high latitudes but increasingly visible now lower down the globe. The clouds result from ice crystals at altitudes of 50 miles, higher than five 9s of the atmosphere. What water ice is doing up there, in a region 100 million times drier than the Sahara desert, is only one of the mysteries associated with the clouds. They are a recent phenomenon: the first scientific description of noctilucent clouds was penned in 1885. For a time it was believed that the clouds were an effect resulting from the eruption of the Krakatoa volcano two years before. Since 2002, the clouds have been sighted — and photographed — as far south as Oregon, Colorado, and Utah. Some scientists believe that human-caused climate change is playing a role, but others doubt this. Two satellites are in orbit to study the clouds; NASA's AIM generated this day-by-day movie of clouds in the vicinity of the North Pole during 2008.