[leszek1]

I'm starting this thread to start a discussion on the possibility of encryption being enforced by firewire enabled future cable/satellite STBs.


Don,


To continue where we left off in the other thread. HBO started encrypting their signal in 1986 using VideoCipher II. When that was compromised, they switched to VideoCipher II Plus and that's what they still use to distribute their programming to dish/cable providers. (See the "Ups and downs section of the following Stereophile magazine article. ) Dish/cable providers decrypt that signal and re-encrypt it using their own schemes so that the signal arrives encrypted to the STB, where the combination of the STB and smart card (if applicable) keys are used to decrypt the signal. As I said in the other thread, since such a great care is taken to encrypt the signal at every single point, I see no reason for the encryption to stop at the STB. I would think that once STBs have 5c, it will be used to encrypt the programming past STB.

 

[Don Landis]

This is where I thought you were going with it. I don't disagree with anything you said as far as the general concept of encryption is concerned.

The difference is that I was stating that HBO and others have not set the 5C copy protection bit so that it will affect one way or another what we are doing with 1394 devices for making DVHS recordings. Will they do it in the future? While it is possible as we have seen in the Cablevision case, according to DR1394 and others this practice is not per present 5C license agreements and the copy protection bit of 5C is supposed to be set by the licensed copyright owner. Now if I were discussing this end of the subject, I would say that there may be some legal argument as to who is a copyright owner using the legal reference to copyright assignments law. BUT all this has to do with legal, not technical issues. Technically, it has been proven that the 5C may be set by anyone who is cabale of adjusting the data stream.


Your final statement in your paragraph has great merit in that you state your opinion that you feel these providers will set the 5C copy protection based on their propensity for using other forms of viewing encryption. (if I understood you correctly) While I say you could be right, as it stands right now they are not doing it and I believe that HBO and other movie channel networks would only do this if they feel that the cost of doing it is justified in the money made for preventing DVHS a la 1394 style program recordings. Real economics calculations of using 5C for the Movie channels are somewhat flawed because every model I have seen ASSUMES that those making copies of a program will not buy, or will result in a sale should they not be able to make a copy. In my opinion they won't do this. This is where we disagree.


We have a difference of opinion of what might happen in the future.

I cannot guarantee that I will be right forever( they will never use 5C) and neither can you predict when HBO and others would begin to control DVHS recording of their content specifically via 5C.


PS- Thanks for doing this outside the Poll thread.

 

[leszek1]

Don,


I hope that your predictions turn out to be the correct ones.


Leszek

 

[bb1987]

Quote:

Originally posted by leszek1 Don, I hope that your predictions turn out to be the correct ones. Leszek

I do too and speaking only for myself I can say with 100% accuracy that the moment HBO can no longer be recorded to D-VHS, is the moment that I CANCEL my subscription.


This means that should they implement 5C to encode the stream with record-never protection they lose me as a customer. By not doing this I will continue to pay them every month for the programming.


I hope that I'm not the only one with this attitude.


bb

 

[h2ofun]

Bernard, I second you pocket book.


Dave

 

[leszek1]

For me "copy once" is also a problem. I use my HTPC to remove 3-2 pulldown on 1080i movies and I watch them at 1080p. With 5c "copy once" I will loose that ability, since the deck will no longer send the data in the clear to my HTPC.


Leszek

 

[CKNA]

The article is a little inaccurate. First of all very few channels are left analog and most cable companies take digital versions. Most cable companies use Headend in the Sky which uses Digicipher 2. They just remodulate digital signal onto QAM. Also Primestar did not use Digicipher 2 but Digicipher 1. DC1 was quickly replaced by DC2 and by the time Primestar was shutdown they were the only using outdated DC1. I do not think there will be any encryption beyond STB but 5C flag might still control the ability to make copies.

 

[Shady Bimmer]

Quote:

Originally posted by Don Landis While it is possible as we have seen in the Cablevision case, according to DR1394 and others this practice is not per present 5C license agreements and the copy protection bit of 5C is supposed to be set by the licensed copyright owner. Now if I were discussing this end of the subject, I would say that there may be some legal argument as to who is a copyright owner using the legal reference to copyright assignments law. BUT all this has to do with legal, not technical issues. Technically, it has been proven that the 5C may be set by anyone who is cabale of adjusting the data stream.

Has anyone actually confirmed the issue with Cablevision? It seems that one person posted in multiple forums at multiple sites that CV was adding a 5C copy-never on all content over firewire. This despite the fact that:


1. CV has stated that it was NOT a 5C issue

2. CV has stated that in fact no content was actually being delivered.

3. Owners of TVs with firewire input have actually verified #2

4. CV has stated that they do not set/change 5C flags on their own - they follow what is determined by the content provider.


The problem as documented by CV is that the firewire port on the Sony STB was meant for HD content only. CV currently has no HD content (delivered via QAM) so there is nothing to send over this port. Apparently CV wanted to deliver SD content as well and this is where the issue came up: The box is apparently not sending SD content over the firewire since it isn't HD. Devices such as the JVC misinterpret (?) the lack of content as a copy-never (or incorrectly display this error)


Until someone steps up and says that they've put an analyzer on the bus and verified what is happening it doesn't do any good to jump to conclusions about what cable providers may or may not be doing. Unless there is another case we really do NOT know how violators of the 5C agreement will be dealt with.


As a CV iO customer with a JVC 30K I have experienced this problem and am dissapointed just as others are and until CV responded thought it was a 5C issue too. Now I do not know.


The only way firewire/5C can be a viable delivery for HD content is if agreements are honored and violators are dealt with appropriately.

 

[dr1394]

Quote:

Until someone steps up and says that they've put an analyzer on the bus and verified what is happening it doesn't do any good to jump to conclusions about what cable providers may or may not be doing.

You've hit the nail squarely on the head.


Ron

 

[Glimmie]

I thought under the 5C agreement only the content OWNER can set restrictions? In many cases HBO is just a distributor and would not have the right to set restrictions.


Now on HBO produced material they could set restrictions. D* and E* basically would have no right to implement restrictions on their own. Except for the demo channels and Charlie Chats! LOL

 

[vruiz]

Quote:

Originally posted by Shady Bimmer 1. CV has stated that it was NOT a 5C issue 2. CV has stated that in fact no content was actually being delivered. 3. Owners of TVs with firewire input have actually verified #2 4. CV has stated that they do not set/change 5C flags on their own - they follow what is determined by the content provider.

Where and to whom has CV stated these things? The statements given to Gary Merson by CV appear to contradict these points.

http://www.avsforum.com/avs-vb/showt...hreadid=180039

 

[dr1394]

Quote:

I thought under the 5C agreement only the content OWNER can set restrictions? In many cases HBO is just a distributor and would not have the right to set restrictions.

It's a bit of a problem. The DTCP_descriptor (copy flags)

is part of the Transport Stream. If the movie is

distributed on some other medium besides Transport Stream

(like D5 tape), then someone has to insert and correctly

set the DTCP_descriptor for that program in the uplink

Transport Stream muxer.


Ron

 

[Don Landis]

Just for clarification, my reference to Cablevision in NY was based on the claims of Gary Mercer on this forum and not personal experience. I agree that we really don't know the actual facts of the case until the actual data would be analized. with some new information in this thread, it seems to me that there may be a difference of opinion on what actually happened at Cablevision. Gary? you reading this? Could you jump in and clarify your earlier claims? Maybe Cablevision just uncovered a flaw in the compatibility of equipment. Hey, so what else is new?

 

[Glimmie]

Quote:

Originally posted by dr1394 It's a bit of a problem. The DTCP_descriptor (copy flags) is part of the Transport Stream. If the movie is distributed on some other medium besides Transport Stream (like D5 tape), then someone has to insert and correctly set the DTCP_descriptor for that program in the uplink Transport Stream muxer. Ron

Very true. I didn't think of that. There are several metadata proposals for ANC data within the SMPTE 292 package but I don't see this ever getting ironed out enough to include 5C data.

 

[Shady Bimmer]

Quote:

Originally posted by vruiz Where and to whom has CV stated these things? The statements given to Gary Merson by CV appear to contradict these points. http://www.avsforum.com/avs-vb/showt...hreadid=180039

CV has acknowledged a bug but in everything I've seen they'd always stated it was not a 5C copy protection issue.


Gary had also posted in the Yahoo! iO forum on this very subject and Wilt Hildebrand (Executive VP of Engineering and Technology) has posted several replies (to which Gary never replied):

Re: [cablevision_digital] No 1394 output on Sony boxes
Re: [cablevision_digital] Re: Firewire/iLink/IEEE1394 on Sony box


I also had a post concerning this, to which Gary never replied: RE: [cablevision_digital] Re: WE WANT HDTV NOW!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!...


My whole point is that there is a difference in opinion. CV has one statement and a customer has another statement. Why take anyone's word for it? The fact that displays are unable to use the firewire (displays should not be affected by 5C copy protection) makes me tend to lean towards believing CV but without any proof I'm remaining open-minded.

 

[Gary Merson]

I sent a reply yesterday just as my OOL service crashed.

I hope it works this time.)


First, let me say that I have never written that I have used the Sony Digital Cable Box (model DHG-M55CV) . I have stated, restated, and re-restated that I used a Mitsubishi integrated HDTV with its built-in QAM tuner to receive SD Cablevision (unencrypted) Digital channels. I have attempted to record, without success the signal via the Mits on both Mitsubishi and Pansasonic DVHS recorders.


To put it mildly the Sony STB has been bug infested with problems.

With that said, lets get down to the above posts.


SB wrote:


2. CV has stated that in fact no content was actually being delivered.

3. Owners of TVs with firewire input have actually verified #2


I do not understand what #2 means. If you are saying that no HDTV content was being delivered via QAM Let me state


I HAVE NEVER PUBLISHED ANY NEWSLETTER OR POSTING THAT STATES THAT CABLEVISION SENDS HDTV CONTENT VIA QAM.


That being the case, who are the "owners that verified #2. If that is not what you meant, you should state it more clearly.


Moving on


Obviously I do not have the ability to analyze Cablevision's data steam.


After I published my newsletter, describing the activation of 5C "no copy" circuits when attempting to record SD digital Cablevision channels via the Mits TV and DVHS VCR, Wilt Hildenbrand posted on the Yahoo iO user group

and wrote:


"The thing is there’s a bug that we’ve discovered, and are working to fix:

1. Since there currently is no HD QAM on the system the box can’t pass that, and,"


As I stated, I have never written that HD QAM was on the system or that this had anything to do with a "box"




"2. The 1394 port on the box is *only* responding to things marked as High Def on the system--â€copy†status notwithstanding,

3. If we tag things HD, then the SD digital stuff will come out 1394 and no other port right now—destructive compliance at it’s best—so we can’t do that,"


DITTO


"4. It has nothing to do with the 5C flag, that happens right now to be set to Copy Always, since as you know, that setting is the responsibility of the Content Provider, we merely supply the switch, they will supply the lever, as per the rules,

5. The “Copy Never†you’re seeing is a default report back from the recorder, not a result of any flag. We bought the very same recorder and tested it,

6. We are *not* and never have been doing any capricious or Machiavellian things to create any improper reliance on our products or boxes,

7. Once the software fix and upgrade is done, as I said, this whole issue will go away and be seen to be *exactly* what I said it was, a bug *not* a conspiracy."


What I interpret the above to mean is that Cablevision claims they are sending out a non-standard datastream which is causing the DVHS VCR to activate its "no copy" 5 C circuit.


Again, I have no way to confirm this. It does raise the question as to whether an MSO has to conform to industry standards to allow devices to perform as intended. Fact is it has been about three and a half months since CV was made aware of the 5C "no copy" activation and as of Thanksgiving (the last time checked) the condition remains the same, no digital recording of its SD digital content is possible.


Wilt has also stated on the iO group that its new SA 4200HD boxes can not currently be implemented due to a software bug. Whether one bug has anything to do with the other, I do not know.

 

[Don Landis]

Gary-


Since the MIts VCR will display a "CP" indicator anytime the VCR cannot interpret the stream for recording, it does not mean that the 5C flag was set to copy none. It just means the VCR cannot interpret the signal. I believe the statement in your post #5 to be accurate. I also believe from what you have stated on this issue that you and CV have done nothing more than found some sort of "bug" in the compatibility of what they are doing and the VCR. I also feel based on your explanation that you went over the top accusing them of tampering with the 5C flags. It appears that you had no proof of this and you also jumped to an incorrect conclusion based on an indicator on a VCR that you mis-interpreted.

You said-
"What I interpret the above to mean is that Cablevision claims they are sending out a non-standard datastream which is causing the DVHS VCR to activate its "no copy" 5 C circuit. "


They may be sending out a non-standard data stream but whether it is activating a 5C circuit or simply that the VCR cannot understand the stream is what remains in question. Based on the reports you have made, and how I know the VCR reacts to non-standard signals, I'd disagree with you that the 5C flags are being interpreted and the VCR shut down on a 5C falg. It, IMO, is just a signal incompatibility issue. Therefore accusing CV of mal-intent is beyond what you can prove.





Bottom line, however, is that recording is not yet possible and the goal should be to get the true issue analized and corrected. CV should be encouraged to resolve this expeditiously. That, seems, by the reports to not be happening.

 

[trbarry]

Quote:

What I interpret the above to mean is that Cablevision claims they are sending out a non- standard datastream which is causing the DVHS VCR to activate its "no copy" 5 C circuit.

Gary -


I'm as willing to be paranoid as the next guy and my hatred of copy protection is well known.


But I read through the posted threads above and came away with a different opinion. I think what Wilt was saying is that there is a bug such that CV will either send a HD signal through firewire or a SDTV signal through analog outputs, but not both.


So since there is nothing currently flagged as HD there is nothing at all on the firewire signal. Not just an erroneous signal. It is turned off. And they will try to fix it once they have HD material.


- Tom

 

[Gary Merson]

Tom,


Wilt's comments were about the Sony box, not my set-up (integrated set and DVHS), the title of his post was:


"No 1394 output on Sony boxes"


Gary


Don,


I do not feel that we are talking about malice, just benign neglect. CV is selling product(s)- digital cable via Cablevision; integrated HDTVs with QAM tuners and DVHS VCRs (via The Wiz), has known for months that products they are promoting and selling do not function as they should (digitally recording CV digital content) but to date, has neither specifically publicly identified the problem, source of the cause, found a solution and implementation.


What's its motivation to fix it?


While I would like to get accurate information from them, whatever the true cause, its still broke they have not fixed it and all they say its a bug, unintentional and it will be fixed soon.


If they really wanted to fix it, don't you think they could (and should) after 100 days?

 

[Shady Bimmer]

Quote:

Originally posted by Gary Merson First, let me say that I have never written that I have used the Sony Digital Cable Box (model DHG-M55CV) . I have stated, restated, and re-restated that I used a Mitsubishi integrated HDTV with its built-in QAM tuner to receive SD Cablevision (unencrypted) Digital channels. I have attempted to record, without success the signal via the Mits on both Mitsubishi and Pansasonic DVHS recorders.

I have been following the posts on the Yahoo forum closely for quite some time (since the very beginning in fact - Sept 01, which is also when I got my iO service) and I don't remember ever seeing you mention using your own QAM tuner. The only posts I saw on the forum indicated you could not copy via firewire due to a 5C problem. I apologize for making assumptions about that. I also was not trying to attack or provoke you but I felt it important that we be fair and all hear all sides of the story.


My understanding is that it is the 5C compliant device that sets the copy flags, and that the state of these flags is determined by information provided by the source of the stream. I assumed that since you were claiming CV was setting these flags that you were using CV equipment, and you never replied to Wilt in the forum to dispute that.

Quote:

2. CV has stated that in fact no content was actually being delivered. 3. Owners of TVs with firewire input have actually verified #2 I do not understand what #2 means. If you are saying that no HDTV content was being delivered via QAM Let me state

Please reread those lines. There is no HD content at all. The iO box will only pass HD via firewire. Hence, here is no content via firewire right now from the iO box. The bug is that SD content never makes it out via firewire even though CV apparently intented it to. On the Yahoo forum "ScottBusy" confirmed that his XBR2 had no display when trying to view any content via the firewire (CV said there is no content and Scott confirmed it)

Quote:

Obviously I do not have the ability to analyze Cablevision's data steam.

Then how do you know exactly what CV is doing with their stream? You only know the results, which I will agree with you sound entirely wrong and CV may have something to fix.

Quote:

What I interpret the above to mean is that Cablevision claims they are sending out a non-standard datastream which is causing the DVHS VCR to activate its "no copy" 5 C circuit.

In this case, do you know that the Mits is actually passing a stream out the firewire? Or is it behaving similar to the Sony iO box and not passing content because it is not HD. I'm not disputing what you are saying but I am wondering if you are seeing the same issue that we see with the Sony iO box. Whether or not the Mits is supposed to pass SD content, is it in fact doing so?


Do you know for a fact that the Mits is being compliant and is adhering to the 5C standards and that the Mits and Mits/Panny always play nice together(Sony, Mitsubishi, JVC, and Panasonic have all claimed to be compliant but there are reported cases where there are incompatibilities)? I know you'd expect a pair of Mitsubishi devices to work 100% together so it doesn't sound like it is likely compatibility between the DVHS and TV. On the other hand, do we know for a fact that the Mits TV will play nicely as a source to the DVHS as a sink (regardless of vendor?)


As several of us have found, DVHS recorders (incorrectly?) claim recording is prohibited when they don't know what to do with the stream (or lack thereof).


Given all this, without being able to analyze the QAM signal, do we even know that CV is in fact setting flags incorrectly (or otherwise rendering QAM devices half-brain-dead?)


Or, as has already been pointed out could it be simply an incompatibility between CV's encoder/modulater and your Mits' demodulator/decoder?


(If we only had a DVHS deck with a QAM tuner builtin!)

Quote:

It does raise the question as to whether an MSO has to conform to industry standards to allow devices to perform as intended.

This is a very valid point. I had posted a question to Rick Spanbauer (also of CV) asking if customers will be able to use their own QAM tuners to view unencrypted programming and I got a very saddening "We don't know" type of answer. You are currently able to view digital programming from CV using your TV's builtin QAM tuner. If you couldn't view even basic programming I'd think CV might be violating other regulations (such as must-carry) but I wouldn't have a clue as to whether CV needs to ensure you can record this same content directly.


Believe me, if CV is indeed doing anything malicious I'll stand behind you 100% but I have not seen any evidence that clearly indicates that.


I am just as frustrated as you that I can't record the digital signal directly, even for broadcast stations in SD.


As far as customers demodulating and decoding the QAM signal using their own equipment I don't even know what requirements CV needs to meet or regulations they need to comply with. How will "must-carry" legislation apply? Will there be/are there regulations controlling what customers can/can not do with QAM signals provided by MSOs? Are there regulations controlling what MSOs must allow us to do with their QAM signal?