Here is a better review of the same event ...

http://www.notebookreview.com/default.asp?newsID=2939

It is obvious from the pictures that the DVD+R media is in the left laptop that it is showing the "standard definition" version of the movie.

It would have been better on Sony's part to use the commercial release of the DVD instead of a custom burned version so they coul dbe no debate about any transcoding / conversion issues.

Anyway - this entire thread of discussions undermines the credibility of the Engadget site as well as the original idiot reporter who was so eager to post his so called "scoop".

Engadget should post a retraction or correction on this as these facts now no longer support the original contention of the article.

ok - i just pulled the update from the Palm site and applied it to my Treo 700W ... it seems to have worked without any glitches. It is slow though - and cleaning up all the temp files has been the slowest part.

I was expecting my phone to go through a hard reset, but that does not appear to have happened. Rather my installed applications are still there and appear to work after install.

I will need to play with it a bit more to what's new, what's fixed, and what's broken.

I think #10 hit the nail on the head ... SecureBlue will probably be embedded in their PowerPC based processors such as the PS3 Cell and Microsoft XBox360.

Game console companies lose money on the consoles and make it up on games. They typically try to incorporate hack prevention technologies to prevent "abuse" of the game consoles (think the original XBox that now boots Linux). Most of these earlier attempts have been more based on obsfucation methods rather than strong crypto principles.

IBM knows and understands modern crypto technologies - and would certainly be capable of producing hardened systems that would be difficult for the hacking community to compromise. Hypothetically, it could require cracking 128 bit AES or 512 bit RSA encryption - or whatever equivalent they chose to use.

By allowing the processor to only boot and execute binaries that have been digitally signed by "approved" vendors using their private keys and associated trust hierarchies, it may prove very difficult to subvert and repurpose these modern game consoles.

So we'll have to see how progress goes on the XBox 360 hacking community. They may have their work cut out for them.

ok - I am curious. The information from Cable Labs that was cited in the article just says it is "certified".

Does anyone know if this is for cablecard 1.0 compliance (no iTV functionality or program guide resources)? Or is this TiVo Series 3 thing actually cablecard 2.0 compliant (which - through OCAP - supports iTV, electronic program guide (EPG) from cable company, etc.)?

Looking through the TiVo community site, this link discusses some of the key issues wihtout saying how TiVo is addressing them:

http://www.tivocommunity.com/tivo-vb/showthread.php?t=281722&highlight=cablecard

Generally - the EPG and scheduling tools offered by TiVo have been one of TiVo's strong points, while the EPG from cable provider has been pathetic in comparison.

But other iTV functionality is coming (supposedly) and it would be nice to know how far TiVo is really taking it.

Anyone out there have clue on this?

Also - I thought that cablecard itself was going to be obsolete soon with DCAS (or "downloadable crypto") ...see this link:

http://arstechnica.com/guides/other/cablecard.ars/3

It would be nice if the TiVo series 3 could be upgraded to support this new spec so we don't have to actually rent the cablecard from our cable company.

I think it would probably be worth waiting for the HD TiVo Series 4 with DCAS support - if the series 3 does not support it.

Anyway - real information is so hard to come buy ...

There has been a lot of speculation about what AACS is or is not. Also there is so much bluster about how "DVD John" or some other hacker is going to crack it.

Unlike DVD's CSS specifications - which were so flimsy they were supposed to keep it secret, the companies behind AACS are confident enough in AACS's robustness to actually publish the implementation specifications.

See here: http://www.aacsla.com/specifications/

Those of you who think this will be easy to crack should think again ... 128 bit AES, eliptic curve digital signatures, revocation, renewability, etc.

Chapter 4 of the Introduction and Common Cryptographic Elements spec spells out the various authentication, key exchange, revocation list update mechanisms, etc. in great detail.

As to Internet capabilities and requirements, see Chapter 5 of the Introduction and Common Cryptographic Elements spec. It is clearly stated that on-line connectivity is not required of devices.

Furthermore, AACS defines four "enhanced modes" associated with using AACS content with online connections. From the specs:

� AACS Network Download Content. This on-line content is intended to be recorded on AACS-protected media. An on-line transaction serves to bind the content to a particular piece of media.

� AACS On-line Enabled Content. This content is pre-recorded on pre-recorded media, or part of the initial download in AACS Network Download content, but only made playable by an on-line transaction.

� AACS Streamed Content. This is stream content logically associated with pre-recorded or AACS Network Download Content, but delivered on demand across the Internet.

� AACS Managed Copy. Content protected by AACS and contained on Pre-recorded Media includes an offer to allow at least one copy of that title onto alternative media such as a Home Media Server. The device performing the Managed Copy will need to obtain authorization from a Remote Server as a part of making this copy. The requirements to support AACS Managed Copy are defined in the Prerecorded Video book.


Perhaps more interesting to look at is the various ways that AACS can "bind content" (see section 5.5). From that section, content can be:

� Media Binding - content is bound to the specific recordable media

� Content Binding - downloaded content can be bound to any copy of a specific AACS content item

� Device/Content Binding - downloaded content is bound to a specific device and any copy of the specific AACS content item

+ Device/Media Binding - downloaded content is bound to a specific device on specific recordable media


So ... there is a lot to AACS - and hacking it will not be easy. There may be momentary security breaches - but these will be difficult to exploit in the long run because compromised devices can be revoked and security holes can be fixed through renewability (e.g., required firmware updates).

Some of the online options kind of suck ... if I buy a movie online and burn it to AACS media, I might not be able to watch it on anything but the device that burned the AACS media.

And such decisions are up to the content publishers who will probably all adopt different policies here. Which means confusion - this is a film from studio X, which I can only play on my PC, but studio Y's movies can be played on my equipment as well as my friends and family's AACS compliant equipment.

Confusion could reign supreme ==> consumer frustration.

#17 - "EVO" ... I think you make some excellent observations about privacy issues.

I would like to point out that many of the issues you raise already exist for the emerging interactive TV specifications - which are all based on the same Java foundations (much more so than you might realize).

It is pretty confusing - but hang in there ...

First there was DVB-MHP (see my links above). This is supposedly already widely used in Europe - although living in the US - I have not seen this first hand. The http://www.mhp.org site lists which countries have already adopted it and rolled it out.

CableLabs liked the iTV ideas developed by DVB-MHP - but it dod not work for the US cable market the way that the cable companies wanted it too.

So OCAP was developed - which is based on DVB's MHP spec (see link above). OCAP is at the heart of the Digital Cable Ready initiative by Cable Labs in the US - and is part of the CableCARD 2.0 compliance specifications for two-way cable (which MS won't support - probably for the same patent licensing and royalty issues).

To help keep these related standards from diverging too much - the "Globally Executable MHP" (or GEM) spec was developed and (1) BD-J (used in Blue-Ray), (2) OCAP (US cable TV standards for iTV), and ACAP (US terrestrial broadcast standards for iTV) are all based on this GEM spec. Furthermore, the existing MHP specs have been updated to conform to the GEM specs as well.

Actually reading these specs (GEM, MHP, OCAP, ACAP, etc.) is a bit of a nightmare as they are written in terms of each other, which make them very confusing to read. I would imagine that - given BD-J's basis on the GEM spec as well, much of this stuff is also really defined in the other specification documents. These documents are all available on line (see www.cablelabs.com for OCAP docs, for example).

The use of Java/J2ME is somewhat loose here - standard packages were dropped, modified in behavior, etc. and things might not work as you would expect a pure Java environment to work. For example, the notion of a "file system" in a digital broadcast is rather bizarre ... but it exists in some form.

So - while BD-J will present privacy issues - we are or soon will be facing similar issues with the iTV specs for cable, etc.

I suppose we should be able to watch our Blu-Ray and HD-DVD movies without actually connecting the players up to an Internet connection if we are concerned about privacy (and who isn't?).

There is really a lot going on here - and the situation is very confusing to the casual observer.

From what I have been able to figure out, Microsoft has licensed CableCARD 1.0 from CableLabs (old news) which offers the ability to descramble digital cable content - but not two way interactive TV. Microsoft was even showing off Vista using a digitable cable TV tuner at CES 2006 in Las Vegas. They were using a prototype CableCARD 1.0 digital TV tuner card - but I did not get information on the company that made it.

Microsoft has not licensed CableCARD 2.0 - which is required for interactive TV support (including channel guide, movies on demand, etc.). Furthermore Microsoft folks at CES 2006 that appeared to know anything about the HDTV and digital cable standards would not say when - or even if - they would ever license the CableCARD 2.0 standards from CableLabs.

We will soon be seeing a CableCARD 2.0 compliant CE devices (e.g., STBs, TVs, etc.) which will be labelled "Digital Cable Ready". The idea here is that consumers will be able to buy their own cable ready equipment and use them on any digital cable system in the US.

A bit more background .... these CableCARD 2.0 complaint devices require a full implementation of a Java based TV specification called OCAP 1.0 (from CableLabs). The OCAP 1.0 is based on GEM (short for Gloablly Executable MHP), which is in turn based on DVB-MHP. And DVB-MHP is the interactive TV standards for the pretty much the rest of the world outside of the US.

Furthermore, Blue-Ray uses BD-J for its interactive TV specification - which is also based on the GEM standards.

In contrast, Microsoft is pushing its own standard for interactive TV content - which is part of the HD-DVD specifications (fact) - and is probably going to part of their IPTV offerings (speculation).

Given Microsoft's love of anything Java (or lack of) - coupled with their support for competing technologies (HD-DVD, IPTV) - we may never see Microsoft support a full CableCARD 2.0 specification. Third party providers will have to do that - presumably bundled with their digitle cable ready tuner cards.

To make it all more confusing - there is even talk of obviating the CableCARD standard altogether and replacing it with a "downloadable crypto" capabilities instead. I suppose the advantage here is that we would not need to rent the CableCARD from the cable company in order to use our own digital cable ready equipment - but the lifespan of systems that actually use the physical CableCARD slot may be rather short.

The details on all this are pretty easy to find if you bother looking for it with Google.

But the madness here runs deep.