(1) You mention 'it will stay outside a Roku'. I'm assuming that means there is no direct access to network functions? Our binary has to run a few tests to our servers and would need to use some basic network tools like ping, a sort of traceroute and some udp ports. These are used to ensure that the service is not actually down but in some other temporary state to tell the client would know how to handle certain conditions. We would use http, https, udp and icmp.
You mention 'that's the app ("channel") that will run on Roku. This seems to imply that there is limited access to certain things but I'm not sure if that implies/includes networking functions such as above.
A small example of this would be windows. On a windows machine, you need admin level access to use network level tools. So I suppose I am saying that on the Roku, I would need that same kind of access.
(3) A registry ID might work, but so long as it can be based on some unique ID of the device. We don't need to keep track of the user, only the unique devices. Meaning, ownership doesn't matter, user doesn't matter, if it changes hands or how many players there are at the same location is not important for our application. We normally use the MAC address as a simple way to permanently identify a device so our server side app can know how to deal with it.
You also mention the 'app' ("channel") that will run on a Roku. The 'channel' part is how we would display the output but the 'app' part would be something that needs to run on the Roku, such as a binary which has access to networking. This is the 'client' part I was initially talking about. This is mainly the part I am missing in terms of information right now. At this point, I suspect that this is not possible and that only 'channels' are supported.