On Friday, Whyte found that Rambus destroyed documents when it anticipated litigation. Specifically, Whyte said, Rambus employees were told to destroy documents at annual "shred days," from 1998 to 2000, prior to filing the patent suits.

Because litigation was "reasonably foreseeable," Whyte ruled, Rambus should had preserved the documents.

"Rambus engaged in spoliation of evidence when it engaged in the destruction of documents on all three shred days," the 66-page ruling states.

Rambus countered that its engineers tended to be "pack rats" and said that its policy was justified...

"The evidence does not show that Rambus knowingly destroyed damaging evidence," Whyte said.

"Although the evidence does not support a conclusion that Rambus deliberately shredded documents it knew to be damaging, the court concludes that Rambus nonetheless spoliated evidence in bad faith or at least willfully," he added.

Because litigation was "reasonably foreseeable," Whyte ruled, Rambus should had preserved the documents.

"Even if none of the destroyed documents would have shed new light on the disclosure obligation, there may have been internal Rambus documents containing information about Rambus' plans to gain market power by using information learned at [Joint Electron Device Engineering Council] JEDEC meetings. Such evidence could have been relevant and given support to Hynix's equitable claims and defenses," Whyte said.

"The court concludes that Hynix has made a plausible, concrete suggestion that it may have been prejudiced by destruction of JEDEC-related documents, and that Rambus has not overcome this suggestion of prejudice by clear and convincing evidence."

ETSI DTR 101 567, to give it the full title, was pointed out to us by Erich Moechel, who has written an excellent exploration of its elements (original in German). Here's the summary from the draft standard (Microsoft Word format):

The present document provides an overview on requests for handover and delivery of real-time information associated with cloud/virtual services. The report identifies Lawful Interception needs and requirements in the converged cloud/virtual service environment, the challenges and obstacles of complying with those requirements, what implementations can be achieved under existing ETSI LI [Lawful Interception] standards, and what new work may be required to achieve needed Lawful Interception capabilities. Cloud Services in whichever forms they take (Infrastructure, Software, Platform or combinations of these) are often trans border in nature and the information required to maintain Lawful Interception (LI) capability or sufficient coverage for LI support may vary in different countries, or within platforms of different security assurance levels. This work aims to ensure capabilities can be maintained while allowing business to utilise the advantages and innovations of Cloud Services and was undertaken cooperatively with relevant cloud security technical bodies.

One key section spells out how this is to be achieved:

If the traffic is encrypted, the entity responsible for key management must ensure it can be decrypted by the CSP [Communication Service Provider] or LEA [Law Enforcement Agency].

In order to maintain LI coverage the cloud service provider must implement a Cloud Lawful Interception Function (CLIF). This can be by way of Applications Programming Interface (API) or more likely ensuring presentation of information in a format recognisable to interception mechanisms. Deep packet inspection is likely to be a constituent part of this system.

Since this is currently a draft, the threat it represents might be seen as purely theoretical; but a recent article in the Guardian confirms that the UK government "quietly agreed to measures that could increase the ability of the security services to intercept online communication" -- a reference to the ETSI draft. The Guardian also provides us with some explanation of why this draft just happens to be available at precisely the moment when the UK government is announcing a plan that seems likely to use it:

Etsi has faced criticism in the past for the pre-emptive inclusion of wiretapping capabilities, a decision that critics say encouraged European governments to pass their wiretapping laws accordingly. According to Ross Anderson, professor in security engineering at the University of Cambridge Computer Laboratory, the institute has strong links with the intelligence agencies and has a significant British contingent, along with a number of US government advisers.

The British government insists now that it will "only" gather communications data, and not content. At the same time, it will require that ISPs adopt the new ETSI cloud interception standard (once it's been finalized) in the "black boxes" that they must install under the proposed snooping legislation. That will put in place all the capabilities needed for accessing encrypted streams -- since those providing cloud services will be required to hand over the encryption keys -- and hence the content. The UK government may not intend accessing content today, but thanks to the wonders of function creep, when it decides to do it tomorrow the facility will be there waiting for it.

Meanwhile, European governments will be able to point to the UK's adoption of the ETSI standard as just "good practice"; they will ask their own ISPs to implement it, while insisting that they too have no intention of accessing the contents of people's Internet streams either. Until, that is, the day comes -- probably in the wake of some terrorist attack or pedophile scandal -- when the governments will note that since the capability is available, it would be "irresponsible" not to use it to tackle these terrible crimes. The US government will then bemoan the fact that Europe is taking better care of its citizens than it can, and will therefore pass laws requiring US ISPs to install similar real-time access to their systems, and for cloud-based services to hand over the encryption keys. Luckily, there will be a well-tried European standard that can serve as a model....

Follow me @glynmoody on Twitter or identi.ca, and on Google+

The BSA argues that "[m]any of today's most widely-deployed open specifications incorporate patented innovations that were invented by commercial firms...including WiFi, GSM , and MPEG."

This is an attempt to create a false dichotomy between "commercial" companies inventing patented technology, in contrast to "non-commercial" inventions which are not patented. In reality a great wealth of unpatented modern technology originating in commercial companies constitute globally implemented standards (such as HTML5), whilst continuing to provide their creators with revenue. There is no such divide, either economical or ideological, between hardware and software technologies which are patented, and those which are not. Yet the BSA divisively implies there is a difference between conventional and accepted business methods, which they associate with patents, and un-businesslike non-commercial organisations, which they associate with patent-free technology. Given the increasing prevalence of Free Software in Europe's IT service market, such a claim is plainly false.

In court, parties have to prove their case by some "standard of proof." In almost all civil cases, the standard is "preponderance of the evidence" -- meaning it is more likely than not that the facts are true. When the question is invalidating a patent, however, the U.S. Court of Appeals for the Federal Circuit decided that a defendant trying to prove a patent invalid must do so by a higher standard than normal civil cases, that of "clear and convincing" evidence. "Clear and convincing" means that the facts are "highly probable," which is a much more difficult standard to meet when trying to invalidate a patent than just a preponderance.

You may have heard of the first one already: ScreamingMonkey has gotten some press. It aims to make the core of Firefox's next-generation Javascript engine (originally developed by Adobe) available in IE, providing advantages in speed and standards-compliance.

The other project is a bit more recent, and a bit more far-out: it's an IE plugin created by Mozilla developer Vladimir Vukićević that implements the HTML5 <canvas> element -- something that IE's never gotten around to supporting. Canvas allows Javascript to draw 2D graphics on the client-side. You may have stumbled across it in the form of one or another nifty in-browser FPS demo. It's a potentially powerful tool, but, as Ars notes, one that hasn't achieved widespread adoption by web developers due to IE's lack of support for it.

Both of these projects are impressive pieces of technology. But unfortunately both attempts to improve IE are unlikely to succeed in the ways that their authors would like -- and it's easy to see why. It's safe to say that IE users tend to be among the web's least technically sophisticated. These are exactly the people who can least reasonably be expected to install modular improvements to their browser's underlying technology. It's hard to imagine anyone finding it easier to do this than to simply download and begin using Firefox -- a task that's already clearly too complicated for many people. And that's to say nothing of the difficulty of getting the word out in the first place.

The right solution is the same as it's always been: for Microsoft to fix its abysmally noncompliant browser. They wouldn't even have to do it themselves! As Tom Raftery suggested some time ago, Microsoft could simply open-source IE. Superficially, this seems like a good fix: it's not as if IE is a profit center for Microsoft, and Apple has already shown the viability of the approach with its open source WebKit HTML rendering engine. A bold step like that could go a long way to bolstering what has thus far been a fairly anemic stab at open source on Redmond's part.

But of course it will never happen. As some of Raftery's commenters pointed out, IE probably couldn't be open sourced without revealing critical -- and valuable -- Windows code. More to the point, Microsoft wants a broken browser. Not supporting <canvas> means that no one will rely on it, which in turn means less competition for Microsoft's rich client library Silverlight -- created to solve the problem of missing <canvas>-like functionality (among other things). More broadly, a world of webapps that are perpetually forced to accommodate IE's underachieving status means less time spent by users in the cloud, and consequently a bit more relevance for MS. Put simply, IE's awfulness isn't a bug, it's a feature.

This is hardly an original observation, but that doesn't make it any less true. And that means that the answer to IE's persistence is the same as it's always been: for Safari, Opera, Firefox et al to consistently provide a better browsing experience and thereby compel Microsoft to fix its mistakes -- as it at least began to do with IE7. Unfortunately, that's something that they're going to have to do for themselves.