Feeds

All you ever wanted to know about the DoJ's Windows cave in

Oh all right, you didn't want to know most of it. But for the record...

  • alert
  • submit to reddit

3 Big data security analytics techniques

The DoJ-Microsoft settlement deal doesn't get any better once you've actually had the opportunity to read the small (and often largely unintelligible) print. It won't stop the onward march of integration, it won't stop Microsoft inducing PC companies to take the easy way out, and it won't magically reinvent tough competitors to dispute the slightly levelled playing field with Redmond. But in addition to the sellouts and the numerous loopholes, there are a few good points. Unfortunately, they get less good the more you read. But here it is, warts and all, Everything you want to know about the Proposed Final Judgement."

At last, OEMs shipping Linux PCs?
Given the confused state of the rest of the document, it's a bit of a puzzle that this one got in at all. But there it is, in black and white: Microsoft shall not penalise an OEM "because it is known to Microsoft that the OEM is or is contemplating... shipping a Personal Computer that (a) includes both a Windows Operating System Product and a non-Microsoft Operating System, or (b) will boot with more than one Operating System."

Microsoft OEM licensing deals have historically meant that dual boot systems, or indeed any non-Microsoft software getting involved in the boot sequence, were streng verboten, so this looks like progress. One can of course see a possible loophole here, because if it's still forbidden in the licence they still can't do it, but no, on the very next page it says Microsoft shall not restrict by agreement any OEM licensee from "offering users the option of launching other Operating Systems from the Basic Input/Output System or a non-Microsoft boot loader or similar program that launches prior to the start of the Windows Operating System Product."

So there you go, free at last. It ought to be fairly cheap and simple for the big PC companies who allegedly support Linux to ship dual boot systems, and it wouldn't cost them any more if they made all of their machines, or at least all in particular lines, dual boot. The users would benefit from choice and the fact that the alternative OS would be pre-configured for the hardware they'd bought, and Linux would benefit from the PC companies really supporting the OS, as opposed to just mouthing off about supporting it.

Ah, but will they jump? Although Microsoft is forbidden to do anything about it if they do, Bill is sure to be very cross anyway. Do the OEMs seriously believe the DoJ deal will protect them? Do they have the guts to test it? Will the retention of bribes and incentives (see below) mean the big outfits remain loyal Ringwraiths? We'll see soon enough, but this has the potential to be a, possibly the, major benefit. For what it's worth Be founder Jean-Louis Gassée seems at least slightly hopeful on the subject.

Middleware swap-shop

The OEMs, bless 'em, are more likely to want to take advantage of the non-Microsoft middleware clauses, because there'll be money attached. This will not be an entirely unmitigated blessing for users, because they'll likely be getting in-your-face offers from all and sundry, rather than just The Beast itself. The definition of middleware here covers the usual suspects, IE, WMP, Outlook Express Messenger and the JVM, and Microsoft's licence agreements now won't be allowed to outlaw the substitution of rivals.

There are some unintelligible riders to this which may be cunning loopholes, or they may just really be unintelligible. For example, we have:

"Microsoft may restrict an OEM from displaying icons, shortcuts or menu entries specified in the Windows documentation as being limited to products that provide particular types of functionality, provided that the restrictions are non-discriminatory with respect to non-Microsoft and Microsoft products."

Sorry? It may, or may not mean something, but we're not entirely clear what. Or, in allowing the intrusion of non-Microsoft middleware we have this curious rider:

"... provided that any such non-Microsoft Middleware displays on the desktop no user interface or a user interface of similar size and shape to the user interface displayed by the corresponding Microsoft Middleware."

So if you replace Outlook Express you've still got to do so with something around the same shape and size? Can this be Microsoft's daft (and utterly rejected by the courts) desktop copyright argument sneaking back in, or something odder still?

But finally in this section, we have a genuine and intelligible loophole candidate. OEMs can insert their own Internet access offer "provided that the OEM complies with reasonable technical specifications established by Microsoft." Friends, do you seriously believe such things exist?

Show us the money

In the past Microsoft has been able to use differential pricing and marketing subsidies (Market Development Agreements, or MDAs) to reward or punish PC companies. IBM's experiences around the launch time of Windows 95, where it was effectively punished for selling a rival OS in the shape of OS/2, provide an example of how this process worked. Now, however, the deal proposes that "Covered OEMs" should have "uniform license agreements with uniform terms and conditions." The charges for Windows will be published - but not, er, public. They will be placed on a web site "accessible to the United States [we fear they mean the Government of the United States here, not the people] and all Covered OEMs."

Still, it's a level playing field, right? Not exactly. "Covered OEMs" are defined as the 20 PC companies worldwide with the highest Windows licensing volumes in the preceding Microsoft fiscal year. Anybody below this, all the little guys, gets nothing from this deal. And here come the riders. Microsoft can charge different royalties for different language versions, and can also "specify reasonable volume discounts." The schedule may also include MDAs, "programs and other discounts in connection with Windows Operating System Products."

Sounds a little bit like the status quo ante, doesn't it? Except that the discounts have to be uniformly available to Covered OEMs. Microsoft can however split these into the top ten and the next ten, which brings it more into line with the status quo ante. It can work closely with the big companies (really, we're only talking about five or so here), but it can't pick on one specific recalcitrant vendor as previously. Some change, but not much. and still plenty room for manoeuvre.

Disintegrating IE, etc

From the release of XP Service Pack 1, or 12 months from the submission of the Final Judgement to court (whichever is sooner), Microsoft will have to supply users and OEMs with mechanisms to remove access to Microsoft middleware and replace it with non-Microsoft middleware. To some extent this is good news for users, because it will likely become easier to dump Outlook, IE, WMP and Messenger and use alternatives, but it's obviously less than half a loaf, it's maybe a year down the line (the move itself will no doubt delay SP1), and... what about Passport? Passport seems not to have even made it into the document's list of definitions; we do not think this is accidental.

If - as seems likely - the partial unbundling is a year down the line, then the whole XP strategy is intact, and Microsoft will have been able to benefit hugely in the interim. Note also that as we're talking about removing access rather than the product itself here, the DoJ has conceded Microsoft's claims that the middleware products are integrated parts of the OS that can't be removed, despite having pretty much disproved this during the trial. When the add/remove functionality ships, there will also be some limitations:

"...except that Microsoft may restrict the display of icons, shortcuts, or menu entries specified in the Windows documentation as being limited to products that provide particular types of functionality, provided that the restrictions are non-discriminatory with respect to non-Microsoft and Microsoft products..."

Sorry? Microsoft clearly has some kind of authority as regards what can and can't be done, but there's precious little else about the sentence that's clear. There's a much clearer brace of escape clauses that guard .NET, and offer a fair bit of scope for Microsoft to nit-pick about the capabilities of alternative software:

"...the Windows Operating System Product may invoke a Microsoft Middleware Product [without your permission, even after you've hidden it, presumably] in any instance in which:

"1. that Microsoft Middleware Product would be invoked solely for use in interoperating with a server maintained by Microsoft (outside the context of general Web browsing), or
"2. that designated Non-Microsoft Middleware Product fails to implement a reasonable technical requirement (e.g. a requirement to be able to host a particular ActiveX control) that is necessary for valid technical reasons to supply the end user with functionality consistent with a Windows Operating System Product, provided that the technical reasons are described in a reasonably prompt manner to any ISV that requests them."

Point 1 gives pretty good cover for .NET services (which can easily be "outside the context of general Web browsing"), while 2 provides endless scope for Microsoft to tell its rivals how fundamentally broken their products are. It's also worth noting that the rotating middleware concessions could easily be interpreted as only applying if Microsoft had an equivalent of the relevant non-Microsoft product already in place. Which could actually work as a brake on innovation, and keep everybody in line behind Microsoft. In summary, it's perfectly possible that this little pile of "concessions" won't just be ineffectual - it could pave the way for .NET, part two.

Technical disclosure

This comes in two parts. The ludicrous procedure for source code revelation to appointed high priests in a secure facility has fallen on the cutting room floor, and instead we have API disclosure, and the licensing of communications protocols. "Starting at the earlier of the release of Service Pack 1 for Windows XP or 12 months after the submission of this Final Judgment to the Court, Microsoft shall disclose to ISVs, IHVs, IAPs, ICPs, and OEMs, for the sole purpose of interoperating with a Windows Operating System Product, via the Microsoft Developer Network ('MSDN')... the APIs and related Documentation that are used by Microsoft Middleware to interoperate with a Windows Operating System Product."

So if you want to produce software that interoperates with Windows software, Microsoft is going to tell you about the APIs via MSDN. Well well - how on earth have those MSDN subscribers been able to manage, all these years?

The Samba Team has already responded to the protocol licensing clause. Nine months after the judgment "Microsoft shall make available for use by third parties, for the sole purpose of interoperating with a Windows Operating System Product, on reasonable and non-discriminatory terms... any Communications Protocol that is... (i) implemented in a Windows Operating System Product installed on a client computer, and (ii) used to interoperate natively... with Windows 2000 Server or products marketed as its successors."

The Samba response points to the document's definition of Communications Protocol, and says: "If Microsoft is allowed to be the interpreter of this document, then it could be interpreted in a very broad sense to explicitly exclude the SMB/CIFS protocol and all of the Microsoft RPC calls needed by any SMB/CIFS server to adequately interoperate with Windows 2000. They would claim that these protocols are used by Windows 2000 server for remote administration and as such would not be required to be disclosed. In that case, this settlement would not help interoperability with Microsoft file serving one bit, as it would be explicitly excluded.
"We would hope that a more reasonable interpretation would allow Microsoft to ensure the security of its products, whilst still being forced to fully disclose the fundamental protocols that are needed to create interoperable products." And of course we've already highlighted the borad piracy-security get-outs here. Also on the definitions front it's worth noting that "major version" (which in many cases is the trigger for moves and disclosures to be made, "shall be identified by a whole number or by a number with just a single digit to the right of the decimal point." WinXP, the 'most important product' since Win95, is of course 5.1, so go figure.

The Three Kings

A three strong Technical Committee to "assist in enforcement... and compliance" will be installed in Mordor itself, although we believe it is not intended for them to be in thrall to Bill - immediately, anyway. There'll be one appointed by the Government, one by Microsoft, and the pair will then select a third. The members won't have been recently employed by Microsoft or a competitor, and won't have consulted or testified for them. Even without the two sides furiously vetoing each other's nominations, this will surely make it fiendishly difficult to assemble a TC that actually knows about what it's supposed to be supervising.

The TC will have access to source code, "subject to the terms of Microsoft's standard source code Confidentiality Agreement" and its members will also "sign a confidentiality agreement prohibiting disclosure of any information obtained in the course of performing his or her duties... All information gathered by the TC in connection with this Final Judgment and any report and recommendations prepared by the TC shall be treated as Highly Confidential under the Protective Order in this case, and shall not be disclosed to any person other than Microsoft and the United States execept as allowed by the Protective Order entered in the Action or by further order of this Court."

And just in case they don't get the message from that: "No member of the TC shall make any public statements relating to the TC's activities." So they're going in there, and we're quite possibly never going to hear from them again. If they do have a beef, and the DoJ doesn't agree it's a beef, then nobody need ever know. If they're hopeless, outnumbered and outflanked, we're never going to know about that either. ®

SANS - Survey on application security programs

More from The Register

next story
This time it's 'Personal': new Office 365 sub covers just two devices
Redmond also brings Office into Google's back yard
Batten down the hatches, Ubuntu 14.04 LTS due in TWO DAYS
Admins dab straining server brows in advance of Trusty Tahr's long-term support landing
Microsoft lobs pre-release Windows Phone 8.1 at devs who dare
App makers can load it before anyone else, but if they do they're stuck with it
Half of Twitter's 'active users' are SILENT STALKERS
Nearly 50% have NEVER tweeted a word
Internet-of-stuff startup dumps NoSQL for ... SQL?
NoSQL taste great at first but lacks proper nutrients, says startup cloud whiz
Windows 8.1, which you probably haven't upgraded to yet, ALREADY OBSOLETE
Pre-Update versions of new Windows version will no longer support patches
Microsoft TIER SMEAR changes app prices whether devs ask or not
Some go up, some go down, Redmond goes silent
Red Hat to ship RHEL 7 release candidate with a taste of container tech
Grab 'near-final' version of next Enterprise Linux next week
Ditch the sync, paddle in the Streem: Upstart offers syncless sharing
Upload, delete and carry on sharing afterwards?
prev story

Whitepapers

Designing a defence for mobile apps
In this whitepaper learn the various considerations for defending mobile applications; from the mobile application architecture itself to the myriad testing technologies needed to properly assess mobile applications risk.
3 Big data security analytics techniques
Applying these Big Data security analytics techniques can help you make your business safer by detecting attacks early, before significant damage is done.
Five 3D headsets to be won!
We were so impressed by the Durovis Dive headset we’ve asked the company to give some away to Reg readers.
The benefits of software based PBX
Why you should break free from your proprietary PBX and how to leverage your existing server hardware.
Securing web applications made simple and scalable
In this whitepaper learn how automated security testing can provide a simple and scalable way to protect your web applications.