On Monday, a US District Court in Seattle dismissed with prejudice a class action case originally brought by Los Angeles native Brian Johnson in the summer of 2006. Johnson's claim at the time was that, when Windows XP used Microsoft's Windows Genuine Advantage (WGA) feature to validate his rights to use a newly purchased XP, Microsoft not only employed software not covered by the end-user license agreement, but used it to transmit his personal information to Microsoft against his wishes.

His allegation was that XP violated California's and Washington state's statutes regarding spyware -- separate software that transmits personally identifiable data back to a source.

Although it took several months for the parties in the suit to simply give the judge permission to declare it over and done with, Johnson's case actually started falling apart in June 2009. At that time, Judge Richard A. Jones denied the plaintiffs' motion for summary judgment. In his denial, Judge Jones found that WGA was a part of Windows XP, not some separate software. If it had been separate, plaintiffs had argued, a strict interpretation of Microsoft's EULA should have prevented it from being downloaded. The typical definition of spyware (which may also be part of some states' legal definition) is that it keeps itself hidden from its user; and the judge maintained WGA not only announces its presence, but is part of Windows XP just like any other component.

But the clincher was the Judge's declaration that when WGA sends the computer's IP address to Microsoft's servers, that's not sending them personally identifiable information, as plaintiffs alleged. Plaintiffs relied upon a passage from Microsoft's online glossary at the time, which did count IP addresses as personally identifiable, as the company's official definition of the phrase. But the judge said that online glossary was not part of the software, citing the company's defense as trumping its Web site's glossary.

"Because the EULA does not incorporate the Web glossary by reference, and there is no evidence that any of the Plaintiffs even read the glossary, the court finds that the Web glossary is not helpful to construing the provision," Judge Jones wrote last June. "Furthermore, the court finds that Microsoft's interpretation of 'personally identifiable information,' in the absence of any definition, is the only reasonable interpretation. In order for 'personally identifiable information' to be personally identifiable, it must identify a person. But an IP address identifies a computer, and can do that only after matching the IP address to a list of a particular Internet service provider's subscribers. Thus, because an IP address is not personally identifiable, Microsoft did not breach the EULA when it collected IP addresses. Plaintiffs' contract claim on that ground must fail."

The last eight months were mostly spent haggling over legal affairs, which included the dropping out of some members of the class action, and the self-excusing of Johnson's attorney. In the end, Judge Jones' June opinion sufficed as the foundation for his dismissal with prejudice this week.

Making good on a promise delivered just about one year ago, Facebook announced today that its popular chat feature can now be accessed through any Jabber (XMPP)-compatible desktop instant messaging software, including AIM, iChat, Pidgin, Adium, and Miranda.

Users can simply connect their Facebook account with their instant messaging client of choice and they can then chat with Facebook friends without having to stay logged into the social networking site.

Further, Facebook Chat has been integrated into the Facebook Connect platform for developers so other services wishing to integrate instant messaging into their sites.

Last June, Facebook's chat service reached the milestone of 1 billion messages being exchanged in a single day, and its growth has continued.

Making good on a promise delivered just about one year ago, Facebook announced today that its popular chat feature can now be accessed through any Jabber (XMPP)-compatible desktop instant messaging software, including AIM, iChat, Pidgin, Adium, and Miranda.

Users can simply connect their Facebook account with their instant messaging client of choice and they can then chat with Facebook friends without having to stay logged into the social networking site.

Further, Facebook Chat has been integrated into the Facebook Connect platform for developers so other services wishing to integrate instant messaging into their sites.

Last June, Facebook's chat service reached the milestone of 1 billion messages being exchanged in a single day, and its growth has continued.

Can You Safely Buy a New iMac Yet?

Nope, but you might be able to next week.

Why?

There are two noted problems with iMacs—the 27-inch models in particular. First is an issue where their screens flicker. Apple released a firmware update for the problem, but it didn't seem to fix it. However, the second firmware update looks to have been more successful. How successful?

Combing through about 30 pages of this thread (thanks Kyle), dozens have found the second update successful—and similar threads have come to similar conclusions. A few outliers still exist, but the vast consensus seems to be that the issue is nullified when the update is properly installed.

So it looks like the flickering problem is fixed for most users. This is great news—a huge breakthrough in this whole saga. If your iMac is still flickering after the update, call up Apple and demand new hardware. It finally seems safe to say, you're probably in the minority.

But the existing, huge question mark is regarding the yellow screens. Are these fixed yet? Apple halted production lines in what we assumed as an attempt to solve the yellow screen problems (among other iMac quirks). Now they're shipping new 27-inch iMacs again.

Theoretically, the yellow screens could be behind us. But until customers actually receive and test these iMacs, we don't know if Apple was able to solve whatever problems are going on.

Apple most certainly hasn't made claims either way.

What Ever Happened With Those Apple Pay-outs

We received reports from the UK, and then the US, that Apple was essentially buying back faulty iMacs for 15% over the sticker price. It was until later, however, that we learned the catch. What once looked like a pretty great deal turned out, well, mediocre. The 15% was a flat payback rate that was meant to cover both tax and shipping. We assume it covered purchasing expenses, but a money hand-out it was not. It's also worth mentioning that this deal was handed out sporadically, and I'm not sure it's still being offered to customers at all.

Quote of the Week

"[Apple] said they can issue me a refund via check that'll come 4-6 weeks. That's nearly $2600 of my money they're going to hold for over 2 months since the day I paid for this messed up computer."

Apple Is All In

So this is it, the big moment of truth. Without official word, we are forced to interpret the delivery freezes as both a silent admission that there were problems with iMacs and an attempt to fix them. But who knows if Apple actually solved the yellow screens. Especially if the source of the issue is really in the LG panel itself—which some suspect given similar complaints with similar Dell monitors—it's possible that Apple can't cure the jaundice without raising hell down at the factory, or shopping for another supplier. (This problem shouldn't be the consumer's inconvenience, of course.) We won't know until we see the latest iMacs in the wild.

We've got a lot of sources—retail/repair spies, plenty of tipsters who are on their third or fourth faulty iMac and, of course, all of you—just waiting to share their replacement experiences. Tip us at submissions@gizmodo.com and join in.

Apple, I hope we can put these problems behind us because neither of us wants to see how bad that apple on the table can rot.

We've got tech that can put us in touch with so many people at once, but can keep us from real intimacy with our closest few: Facebook friends don't have to meet, tweets don't require thoughtfulness, movie dates don't require talking, and sexting obviates touching. But we still need to get down to brass tacks for love and fucking. Uh, so to speak.

The underlying game remains but it seems like we have a lot more interference to deal with.

Of course, it isn't that one-sided. We're meeting people we might have never met before, and we're engaging with them, even superficially, across barriers and distances and with immediacy impossible even a few decades ago.

But my guess is that when we spend all this time at arms length or farther, engaging in little meaningless conversations with the crowd, it's hard to imagine we're all as good at the one-on-one time than we might been sometime in the last century. I might even suggest from my pop psychobabble arm chair that gadget geeks who prefer to fiddle with apps at a party instead of conversing with other human beings are at least slightly damaged romantic goods. I'd be speaking about myself. And so would my girlfriend:

When Brian first brought his iPhone home, it was like he'd taken a mistress. All day, all night, he fondled its touchscreen and gawked at its shiny face. He couldn't keep his eyes off of it for more than five minutes at a time. Like a good Japanese girlfriend, I let him get the lust out of his system instead of trying to stop the inevitable. I pretended not to care while he lay in bed smoothing his finger across the unlock bar, and sat stoically at the other end of the dinner table as he and the iPhone whispered sweet nothings to each other.

Geek-on-geek love isn't all bad. Nerds use the same websites and gadgets and develop, together, the same affinities and rules of right and wrong. The challenge is, along the worldwide spectrum from geek to non-geek, everyone gets comfortable with these modern tools at different paces. What's left, and constant, then, is human nature.

For the next few days, counting down to Valentine's day, we're exploring love in modern times. Our resident love doctor, Dr. Debby Herbenick, will be sharing wisdom and data to help us understand the new challenges, and we'll all be publishing various takes on this complicated subject, as well as sharing your experiences as well.

It's not all bad, in fact, sometimes it's beautiful, but let's face it, love is messy enough and adding social networks and smartphones into the mix without any established rules for how or when to use them properly, things can only get messier.

This is where our theme—and our exploration of awkward geek love—begins.

You can read all our Bad Valentine stories here.

A defect in the protocol that secures monetary exchanges and other private transactions throughout the Web, discovered by wireless security engineers last August, continues to go unfixed as vendors work towards a solution. It can only be described as miraculous that a working exploit hasn't yet been detected for a security hole that hid in plain sight ever since Transport Layer Security was developed.

The problem was inadvertently made public last November. In short, it has to do with the transition Web sites make between the older Secure Sockets Layer protocol and the augmented TLS. During the transition process, the Web sites leave one protocol, but have to remind each other what they were transitioning from and to -- like asking one another, "What were we talking about again?" The question and answer get sent in the clear, making it easy for a man-in-the-middle to spoof the site with the answer.

Yesterday, Microsoft issued an advisory for server administrators, linked to a Knowledgebase article that provides an update package for Windows Server. But that package is not a fix; actually, it's just a System Registry patch that disables the entire renegotiation process. It makes your system safe from the exploit, but it may end up leaving transactions encrypted with SSL rather than TLS.

Microsoft warns that this could be an inconvenience for some customers whose applications require this kind of step-up renegotiation in order to make a connection. That could be a very serious inconvenience indeed if your name happens to be "US Dept. of Defense."

Back in April 2004, DoD directive 8100.2 (recently redubbed 8100.02) specified that data traffic over wireless devices was only permissible by layering an encryption system atop the existing wireless infrastructure. This was back before Wi-Fi was trusted. That changed with a supplement to that directive issued in June 2006 by the Assistant Secretary of Defense for Networks and Information Integration (known on record as "ASD(NII)/DoD CIO"). The supplement marked the Department's official embrace of 802.11i security standards for Wi-Fi, which the CIO deemed compliant with Security Level 2 out of 4, of the government's Security Requirements for Cryptographic Modules (PDF available here).

As the latest (2007) version of 8100.02 now reads (PDF available here), "Encryption of unclassified data for transmission to and from wireless devices is required. Exceptions may be granted on a case-by-case basis as determined by the Designated Approving Authority (DAA) for the wireless connections under their control. At a minimum, data encryption must be implemented end-to-end over an assured channel and shall be validated under the Cryptographic Module Validation Program as meeting requirements per Federal Information Processing Standards (FIPS) Publication (PUB) 140-2, Overall Level 1 or Level 2, as dictated by the sensitivity of the data."

And as the FIPS 140-2 document explains, "Security Level 2 allows the software and firmware components of a cryptographic module to be executed on a general purpose computing system using an operating system. An equivalent evaluated trusted operating system may be used. A trusted operating system provides a level of trust so that cryptographic modules executing on general purpose computing platforms are comparable to cryptographic modules implemented using dedicated hardware systems."

Standard 802.11i is published and maintained by the IEEE, and its encryption protocol of choice is maintained by the IETF: EAP-TLS, the most evolved form of the protocol that started out as SSL.

Now, it would appear the DoD may be on the threshold of wading into precisely the minefield they had hoped to avoid, prior to their embrace of 802.11i. The fix to the TLS security hole, when it comes, will have to be coordinated and simultaneous, involving the cooperation of not just Microsoft but hardware vendors that supply the government with systems, such as Cisco and Aruba Networks. Technically, operating systems that were considered "trusted" enough to substitute for firmware cryptographic modules, under FIPS 140-2 Security Level 2, may not qualify as "trusted" now, were someone to make that official evaluation. The more time vendors assume in coordinating their response, the more opportunity the Pentagon may have to reach that dreadful conclusion.

A defect in the protocol that secures monetary exchanges and other private transactions throughout the Web, discovered by wireless security engineers last August, continues to go unfixed as vendors work towards a solution. It can only be described as miraculous that a working exploit hasn't yet been detected for a security hole that hid in plain sight ever since Transport Layer Security was developed.

The problem was inadvertently made public last November. In short, it has to do with the transition Web sites make between the older Secure Sockets Layer protocol and the augmented TLS. During the transition process, the Web sites leave one protocol, but have to remind each other what they were transitioning from and to -- like asking one another, "What were we talking about again?" The question and answer get sent in the clear, making it easy for a man-in-the-middle to spoof the site with the answer.

Yesterday, Microsoft issued an advisory for server administrators, linked to a Knowledgebase article that provides an update package for Windows Server. But that package is not a fix; actually, it's just a System Registry patch that disables the entire renegotiation process. It makes your system safe from the exploit, but it may end up leaving transactions encrypted with SSL rather than TLS.

Microsoft warns that this could be an inconvenience for some customers whose applications require this kind of step-up renegotiation in order to make a connection. That could be a very serious inconvenience indeed if your name happens to be "US Dept. of Defense."

Back in April 2004, DoD directive 8100.2 (recently redubbed 8100.02) specified that data traffic over wireless devices was only permissible by layering an encryption system atop the existing wireless infrastructure. This was back before Wi-Fi was trusted. That changed with a supplement to that directive issued in June 2006 by the Assistant Secretary of Defense for Networks and Information Integration (known on record as "ASD(NII)/DoD CIO"). The supplement marked the Department's official embrace of 802.11i security standards for Wi-Fi, which the CIO deemed compliant with Security Level 2 out of 4, of the government's Security Requirements for Cryptographic Modules (PDF available here).

As the latest (2007) version of 8100.02 now reads (PDF available here), "Encryption of unclassified data for transmission to and from wireless devices is required. Exceptions may be granted on a case-by-case basis as determined by the Designated Approving Authority (DAA) for the wireless connections under their control. At a minimum, data encryption must be implemented end-to-end over an assured channel and shall be validated under the Cryptographic Module Validation Program as meeting requirements per Federal Information Processing Standards (FIPS) Publication (PUB) 140-2, Overall Level 1 or Level 2, as dictated by the sensitivity of the data."

And as the FIPS 140-2 document explains, "Security Level 2 allows the software and firmware components of a cryptographic module to be executed on a general purpose computing system using an operating system. An equivalent evaluated trusted operating system may be used. A trusted operating system provides a level of trust so that cryptographic modules executing on general purpose computing platforms are comparable to cryptographic modules implemented using dedicated hardware systems."

Standard 802.11i is published and maintained by the IEEE, and its encryption protocol of choice is maintained by the IETF: EAP-TLS, the most evolved form of the protocol that started out as SSL.

Now, it would appear the DoD may be on the threshold of wading into precisely the minefield they had hoped to avoid, prior to their embrace of 802.11i. The fix to the TLS security hole, when it comes, will have to be coordinated and simultaneous, involving the cooperation of not just Microsoft but hardware vendors that supply the government with systems, such as Cisco and Aruba Networks. Technically, operating systems that were considered "trusted" enough to substitute for firmware cryptographic modules, under FIPS 140-2 Security Level 2, may not qualify as "trusted" now, were someone to make that official evaluation. The more time vendors assume in coordinating their response, the more opportunity the Pentagon may have to reach that dreadful conclusion.

Google announced today that it is planning to build and test broadband networks in several trial deployments across the US which promise to be "100 times faster than what most Americans have access to today with 1 Gbps fiber-to-the-home connections."

A careful read of that line suggests that Google is promising 1 Gbps fiber, which is 100x faster than the average broadband user's transfer rate, as opposed to a 100 Gbps pipeline. The company says the service will reach 50,000 people initially, with a potential reach of up to 500,000, the company announced.

Right now, Google is putting out a request for information for communities looking to test Google's new fiber service. On March 26, the Mountain View search company will be announcing the markets where it will begin deployment.

The company is going to test this super high speed internet to "a small number of trial locations across the United States," and give somewhere between 50k to 500k people an amazingly fast pipe. What's the point of this?

* Next generation apps: We want to see what developers and users can do with ultra high-speeds, whether it's creating new bandwidth-intensive "killer apps" and services, or other uses we can't yet imagine.
* New deployment techniques: We'll test new ways to build fiber networks, and to help inform and support deployments elsewhere, we'll share key lessons learned with the world.
* Openness and choice: We'll operate an "open access" network, giving users the choice of multiple service providers. And consistent with our past advocacy, we'll manage our network in an open, non-discriminatory and transparent way.

We basically read that as bridging the gap between webapps and desktop apps by making the connection so fast that most people won't be able to tell the difference. And, forcing other ISPs to upgrade their pipes to compete with Google, since they say it's going to be released at "a competitive price". Think of it as the Nexus One of service providers. Google is going to make an offering that's better than other comparable devices/services in order to make everyone else play catch-up.

So, if you want my address, Google, to know where you need to deploy the test, you've probably got it already. Seriously man, I need this. [Google]

Almost exactly a year after Verizon Wireless named its LTE equipment partners, AT&T has done the same. And like Verizon, AT&T has chosen Swedish wireless technology provider Ericsson and French telecommunications company Alcatel-Lucent, to make the transition from 3G to LTE more streamlined.

Rather than start fresh and attempt to install all new hardware at its cell sites, AT&T is going for hardware that is easily upgradeable. All 3G equipment purchased from the Ericsson and Alcatel-Lucent this year will be easily convertible to LTE, AT&T said.

Ericsson and Alcatel-Lucent will be the suppliers for AT&T's Radio Access Network Domain, also known as the middle tier between the users and the central AT&T network. It's called a "domain" because it is part of AT&T's Domain Supplier program which launched last September. In this program, only two suppliers are selected to work on each part of AT&T's network, and they're given multi-year contracts which include not only immediate goals, but also goals for the future. That way, the contractors can develop systems that can evolve, and AT&T can worry less about legacy systems.

This year, AT&T says it will upgrade the fiber backhaul to its cell sites to boost 3G speeds and pave the way for its first LTE-compatible sites next year.

Prominent developers sometimes tease us with products made on the iPhone platform that have not yet been approved by Apple. Frequently it's because their applications face certain rejection; sometimes on the famous grounds of "duplicate functionality", sometimes for other reasons.

Mobile World Congress next week will be hosting the mother of all iPhone app teases: Opera Mini for iPhone.

Opera Mini is already on more than 40 million devices, and is easily the most prominent browser for resource-constrained mobile devices. The company announced today that it will be showing off a version of Opera Mini for the iPhone that is up to six times faster than the iPhone's native Safari browser and can cut bandwidth consumption by up to 90%, thanks to the server-side rendering techniques that Opera uses.

Naturally, the browser is not available to the public, nor is it likely to ever be. Opera has built the "duplicate functionality" argument into its very presentation...claiming it can improve upon a primary piece of the iPhone's software.

It actually looks more like Opera has gotten wise to Apple's PR magic; and hopes to stimulate some attention for itself in showing off a product certain to create friction with the strict Cupertino company.