Unexpected privacy issue or..? My cable company's tuner box flashes every time I use the TiVo remote

Discussion in 'TiVo Bolt DVR/Streamer' started by jmccorm, Jun 22, 2019.

  1. jmccorm

    jmccorm Special Forum Guest

    Oct 8, 2000
    Tulsa, OK
    I've noticed something odd with my TiVo, my cable box, and my TiVo remote.

    Any time I press a button on the TiVo remote control, the "messages" light on my cable company's tuner box starts flashing. I see this happening with both the newer VOX remote and with the original TiVo Bolt remote control. Both of the remotes are set up to communicate with the TiVo via RF and with the TV via IR.

    What happened was that as I was using the TiVo menus, every time I navigated through the options or made a selection, the cable company's tuner box would flash its MESSAGES light, which is normally off. (The cable company's tuner box is connected to the TiVo via USB and via coax, as it should be.) It seemed really odd that something as simple as choosing between some of my recordings would activate my cable company's tuner box, so I tried to get a better idea of what was going on.

    If I used the TiVo remote to power my television off or on, or to turn the volume up and down (all of which is controlled via infrared), it also causes the cable company's tuner box to flash its MESSAGES light. If I blocked the IR output of my TiVo remote and I pressed the volume up/down buttons, the TV wouldn't see the command, but the cable company's tuner box would still flash its MESSAGES light. If I used the infrared remote when came with my TV to do those same things, my cable company's tuner box didn't react at all.

    It seems like just about any time I use the TiVo remote, my cable company's tuner box is seeing activity. So I'm kind of wondering what's going on here? Is TiVo forwarding my keypress to the cable company? Is the cable company intercepting the RF from my TiVo remote? And do my keypresses stay within the tuner box, or is this captured and sent upstream?

    I didn't read anything about this in my TiVo privacy policy (or my cable company's privacy policy), so I'm wondering what might be going on here? Or might there be some other reason why my TiVo remote is activating my cable company's tuner box when I'm navigating through recordings or changing the volume on my TV? I just don't expect for my cable company to know all the details of what I do with my television when I'm not even watching cable.

    Known issue? What's going on here?

    UCLABB Well-Known Member

    May 29, 2012
    Riverside, CA
    Queue the Twilight Zone theme.

    I assume you are referring to the tuning adapter. My TA, a Cisco, does not have a "message light". I'm not familiar with the Motorola TAs, maybe they have a light that indicates it has received signal. Note the TiVo itself has such a light that blinks indicating a signal was sent, even it was simply sent to the TV to turn it on or off. I suspect this is what you are seeing on the TA.
  3. ManeJon

    ManeJon Active Member

    Apr 14, 2018
    Anyone who thinks that, at the moment, cable companies aren't collecting data about your watching habits - I have a bridge to sell you.
    Spectrum advertises on TV that they can provide great data on customers viewing and other habits. As long as companies can "legally" pay legislatures (campaign contributions, etc.) you won't see any privacy.
  4. jmccorm

    jmccorm Special Forum Guest

    Oct 8, 2000
    Tulsa, OK
    I think you've certainly captured the essence of what the puzzle is, but the explanation still seems to be in question here, right? The TiVo manual says the the Amber/Yellow "Light flashes when a signal is received from [the TiVo] remote". So why does my cable company's tuning adapter also flash its MESSAGES light when I'm using the TiVo remote?

    Is the cable company's tuning adapter intercepting the TiVo remote's RF signal? Is my TiVo communicating something (unnecessary for its operation) to the cable company's tuning adapter? Or is there something entirely different going on here?

    It seems a worthy question to ask, and if there turns out to be an absence of answers, this might make a good topic for me to turn into a research project.
  5. tatergator1

    tatergator1 Well-Known Member

    Mar 27, 2008
    Columbus, Ohio
    *Putting my tin foil hat on*

    You tested the remote IR blocked, and the light still flashed, correct? The only conceivable way that light is flashing with IR blocked would be that it's getting info via the USB cable from the Tivo during all key presses. Or perhaps it can sense RF signals, but I wouldn't expect the remote to broadcast RF for TV functions that are solely IR, or that a 10+ year old box was made to detect RF.

    Remove the USB cable from the MTR and do a testing cycle again. If the light still flashes, either the IR wasn't as blocked as you assumed it was, or it can, in fact, sense RF and RF is broadcast for TV functions.
  6. moyekj

    moyekj Well-Known Member

    Jan 23, 2006
    There's no mystery here. The TiVo passes along all button presses to the Motorola TA via USB connection. This is used among other things to track "idle time" to determine if switched digital channel possibly currently being tuned is no longer needed and can be timed out.
  7. jmccorm

    jmccorm Special Forum Guest

    Oct 8, 2000
    Tulsa, OK
    As suggested by tatergator1, I pulled the USB cable between the Cable Tuner and the TiVo... and the MESSAGES light on the Cable Company's tuner box stops flashing with each keypress. So it seems reasonable that the TiVo is sending information along with every keypress to my cable company's box. My question to you specifically would be how/where did you get that information?

    What I'm interested in is:

    1. Is there anything published reference (or examples of intercepted traffic) that says what specifically is being communicated? Example: "A key has been pressed" vs "User has pressed the select button" versus "The user has pressed the select button and entered the playlist menu entry for The CBS Evening News".

    2. You mentioned that it used used, among other things, to track idle time. Are any of those other uses documented in the public space?

    Thank you all for the great replies,
  8. dlfl

    dlfl Cranky old novice

    Jul 6, 2006
    Dayton OH
    If you pursue this topic further please refer to it as a Tuning Adapter to avoid confusion with other cable-supplied boxes.

    Note that whatever information can be obtained via that USB cable can also be obtained via a set top box or DVR furnished by the cable co. The tuning adapter just duplicates some functions that are already integral to those boxes.
  9. moyekj

    moyekj Well-Known Member

    Jan 23, 2006
    Here's a link to some documentation on the subject:
    ClearToLand and kpeters59 like this.
  10. jmccorm

    jmccorm Special Forum Guest

    Oct 8, 2000
    Tulsa, OK
    Thank you so much, moyekj! This is far more delicious than I first suspected!

    PDF page 16 onwards speaks directly to the communication between the TiVo (as a USB 2.0 host it is referred to as a "UDCP" or a Unidirection Digital Cable Product) and the Tuning Adapter (as a USB 2.0 client it is referred to as the "TR" or a Tuning Resolver). Of course, I must acknowledge that this document is not TiVo specific, it could be any set-top box (STB).

    As I start to read this, I see that as the STB changes channels, it reports the status of all of TiVo's tuners (what channel they are tuned to and what they are busing used for, such as: live full-screen and recorded, picture-in-picture, user-directed recording, and even speculative recording). But really, I think it is section 8.6.5 "udcp_status" which explains what is triggering this activity when using the TiVo remote.

    If the tuner_use_status is not 'inactive', the UDCP SHALL set user_activity_detected and transmit the
    udcp_status_update() APDU within one second of when human activity is detected. Note: Multiple detections of human activity within one second are expected to be contained within one udcp_status().

    When you press a button on your TiVo remote, and according to version 0x01 of the protocol, it reports that there has been human activity, and it also reports the status of all the tuners (similar to what was mentioned above when it changes channels).

    There is nothing published in this document which exposes (in very specific terms) what the human input was, although it seems convenient that human activity is encoded as a single bit, followed by a "reserved" field of 7 bits. The protocol leaves room for a vendor to re-purpose the reserved field to describe the human activity in more specific terms (while still retaining overall protocol compatibility).


    The UDCP SHALL define human activity as when either a remote control code is received OR a front panel key is pressed, AND cable content is being displayed, recorded, or sent to any digital or analog outputs.

    The word SHALL is defined as being a mandatory requirement. I guess there are three interesting parts here:

    1. If the set-top box receives a remote control code (even if it is actually intended for your television), that matches the definition of human activity, and it is required to report it to the tuning adapter.

    2. The intent seems to be that if the user is doing something on their set top box that is not related to cable (such as playing a game, watching Netflix, or watching YouTube), then it should not be reporting that human activity to the Tuning Adapter.

    3. The term "remote control code" is not defined in the specification. Would that include a desktop or tablet application? (Probably.) Would that include a voice command? (In the case of the TiVo, you need to press a button on your remote to active it, so yes, in part.)

    So if #2 is true (an apparent intent to report on cable TV activity), then why is it reporting every button press when I'm not watching or recording cable TV?

    I think the confounding factor is that unless you've got all of your tuners set to an invalid channel, your TiVo almost always is recording something from cable if only to put it into the live TV buffer. As a result, it is always in a state where the specification requires it to report your activity to the cable company. Even if you're spending all day binging on a series in Netflix, Hulu, or Amazon Prime Video. (I suppose, out of curiosity, it might be interesting to see if it still reports user interaction when all tuners set to an un-tuned state.)

    But I can't believe that the cable providers would have allowed such a glaring oversight to persist. Everything else seems to indicate that they want to know exactly what channels are being recorded (if human-directed or not) and are currently being watched. Those metrics are useless if they're updated by activities that are unrelated to watching cable television.

    [I've hit the forum limit for message length. Breaking this into two messages!]
  11. jmccorm

    jmccorm Special Forum Guest

    Oct 8, 2000
    Tulsa, OK
    [continued from the previous message]

    So, after reading the specification, what are my thoughts and observations? Quite a number of things!

    0. I also can't believe that the specification has gone six years without an update, extension, or unique vendor implementations. I also want to believe that some cable providers could have used their weight to request or require the use of certain extensions to the TR Message Protocol. Proof? No. Right now, I only have a suspicion.

    1. It looks like the messages on the USB bus are left unprotected, however the video keys are well-encrypted and are encrypted with public and private keys. I think the casual experimenter isn't very interested in the video stream itself; they're focused on reading thee TR protocol messages in both directions. Actually, back to item #0, I think that there could be some value in verifying that the protocol is operating in the real-world just as the document specifies, or if there are any interesting deviations happening behind the scenes. Has anyone else done this?

    Unlesss I've missed something, it is unfortunate that there aren't any low-cost or open-source USB 2.0 protocol analyzers. I pulled my Bus Pirate out of the closet and updated it to the latest firmware, but it looks like it an inexpensive tool like this isn't sophisticated enough to pull data directly from a USB 2.0 bus.

    I've seem that some older devices that don't have USB functionality integrated into their system chipset will have an additional chip which is dedicated to handling USB functionality. If the connection between the USB controller and the system chipset is done via a PCI bus, it isn't so easy to intercept. But if a system chipset connects to its USB adapter via a serial UART, something like the Bus Pirate could pull messages in both directions quite easily. It could allow for real-time interpretation and more. Otherwise, real commercial USB protocol analyzers start around $400 and go up from there.

    On the cheap side, it might be possible to connect a tuning adapter and set-top box through a USB hub. A Raspberry Pi could be connected to the hub as a USB host but that would restrict it to seeing tuning adapter only. With an on-the-go adapter (or using a Raspberry Pi Zero), it might be possible to read messages from the set-top box. A Raspberry Pi with both types of USB ports could potentially replace the hub and act as a man-in-the-middle device, intercepting all USB traffic in both directions using a project such as dominicgs/USBProxy. So that's interesting, right?

    2. The TR Message Protocol creates a lot of opportunities on both the tuning adapter and the set-top box to send them unexpected packets which could result in undetermined behavior (or crashes). Forget doing anything with the video stream, everything else actually seems much more interesting to explore.

    3. The protocol specification makes some indirect references to emergency (EAS) messages. It doesn't document the EAS protocol itself, but instead refers to SCTE 18, which I've found and linked to. Assuming it isn't illegal to do so, someone might strongly desire an arrangement where a Raspberry Pi (configured as pass-through device between the set-top box and the Tuning Adapter) is used to to filter out certain EAS messages, but otherwise allow traffic to flow through normally.

    At least in my area, some people are running into excessive EAS weekly and monthly tests in additional to regional weather alerts far outside their area. Not everyone wants to receive EAS type messages on all their devices. Some might want it only on their phone. Some might just want to rely on the civil defense siren that is just down the road. Controlling what EAS messages can generate alerts (just like higher-end cell-phones offer to their users) is a nice function for some people to explore.

    4. There is a very interesting use case of sending your own custom on-screen messages to the Set Top Box using the tr_message() protocol specification. One example (perhaps dated) would be an on-screen caller-id message. A more modern example would be the trigger from a security camera. (I won't dive into the protocol specification which forces the set-top box to change channels, but that might be a related use, too.)

    There might be any number of reasons why someone would want to put a message across their set-top box. The only issue that seems like it might be a problem is that set top box messages have a message ID attached to them. Also, within five seconds of processing an on-screen message from the Tuning Adapter, the set-top box must respond back with the ID of the request and if it was able to display it.

    How might the Tuning Adapter respond to an unsolicited reply? Unknown. I'd assume it would report it upstream to the cable company, but little more. The Set Top Box might make sure that it wasn't a duplicate message ID that it has processed before, but it is possible that it enforces a sequential ID policy. The good news is that there is nothing in the protocol which allows for message confirmation.


    That's what I see in the document. Again, thank you so much for your reply, moyekj. I think you've given me some really good projects to consider!
  12. UCLABB

    UCLABB Well-Known Member

    May 29, 2012
    Riverside, CA
    kpeters59 likes this.
  13. mdavej

    mdavej Well-Known Member

    Aug 13, 2015
    Of all the things in life to obsess about, the light on my TA is at the very bottom of my list.
    kpeters59, dianebrat and jrtroo like this.
  14. jrtroo

    jrtroo Chill- its just TV

    Feb 4, 2008

    I'm not seeing any projects from this, but have at it!
  15. BobCamp1

    BobCamp1 Well-Known Member

    May 15, 2002
    This reminds me of when people hate Windows 10 for gathering information on them. They complain by posting on online message boards using Chrome...because Google doesn't collect any information on you at all.

    It sounds like the system is working exactly as it's supposed to.

Share This Page