Roku Developer Program

[TheEndless]

"lucasgonze" wrote:
I wonder if there's a way to have your Roku tell the extension what its IP is? Is there any Brightscript API for that?

The roDeviceInfo component has a GetIPAddrs() method that returns an associative array of IP addresses (wired and/or wireless), but I don't think that'll do what you're talking about. The only way I know of for an external application to get that information be via SSDP broadcast. After all, there's no way for the extension to talk to the Roku unless it already knows the IP address.

[gonzotek]

"TheEndless" wrote:

"lucasgonze" wrote:
I wonder if there's a way to have your Roku tell the extension what its IP is? Is there any Brightscript API for that?

The roDeviceInfo component has a GetIPAddrs() method that returns an associative array of IP addresses (wired and/or wireless), but I don't think that'll do what you're talking about. The only way I know of for an external application to get that information be via SSDP broadcast. After all, there's no way for the extension to talk to the Roku unless it already knows the IP address.

I've been spending some time thinking about this. SSDP discovery is great if your platform can take advantage of it. But apps like Remoku (and other 'web'-based services, and apps on platforms that ssdp isn't implementable in, like WebOS) need another way to determine the Roku addresses on the local network. Here's one possible way:

• The Roku device can obviously already determine its own IP, as explained above.


• The Roku website already provides owners with a list of units registered to their account, protected by a username/password login.


• What if:
  A)The Roku device periodically 'called home' its local IP to the the owner website.
  B)The website offered an api that would give that information back to a requesting app/service/device, secured using Oauth or another suitable authentication scheme?

Then remoku could poll the Roku web api to get a list of units and their local addresses. This wouldn't have to be limited specifically to remote apps, either. For instance, the MOG website could let users register their Roku accounts with MOG, then enable playback of the queue directly to the Roku. Obviously, this would require changes to the Roku firmware and web services, and ongoing support for any/all the traffic generated to owner.roku.com from the use of this feature, so I can understand why it might not be a path they'd want to pursue.

Another possibility would be to have a program run on a pc on the local network, that can use SSDP to do the discovery, then publish that info to a third-party website, like apps4tv. This wouldn't require any involvement from Roku, but would require the user to locally install software, and for the website to maintain a secure database of registered users, and associated units and IP addresses (along with secured communication channels in each direction). I'm not keen on making Remoku server-dependent like that, nor to require users to install software and set up yet more accounts, nor the security implications such a solution would present (not to mention having to implement that software on Windows, Mac and probably Linux too). I'd much prefer calling the roku mothership and (with authorization) being provided the info directly.

[EnTerr]

"gonzotek" wrote:
I've been spending some time thinking about this. SSDP discovery is great if your platform can take advantage of it. But apps like Remoku (and other 'web'-based services, and apps on platforms that ssdp isn't implementable in, like WebOS) need another way to determine the Roku addresses on the local network. {/quote}

Why do you say UDP multicast (which SSDP is) is not implementable on WebOS? I can't find read to that extent, except that you may need to call API to open firewall port.

"gonzotek" wrote:
I'd much prefer calling the roku mothership and (with authorization) being provided the info directly.

The approaches you describe are overcomplicated but more importantly are security and privacy concern. Roku provided my home IP address to third parties, say whaaat? 🙂 I don't think that will pass muster with a CPO (chief privacy officer). Third parties controlling from the cloud your Roku player in your room is also creepy.

Why is it hard for you to ask your user to go to Settings / Player Info and ask them to copy the IP from there? You can cache that value in a cookie and moreover you can probably get the first 3 numbers from the browser host IP anyway, so we are talking about asking the user to enter one number when first using your web app or after on load you find out there is no connection (so you show popup asking them to check).

Here is additional idea (hack, really) but i don't know what the browser abilities are to open multiple connections (js threads? async?): in overwhelming number of cases the Roku player will be in the same /24 network like the browser and the two IPs will be really close (routers tend to allocate dhcp in order, whether starting at .1 or .100). So if you could possibly start probing the network for Roku, chances are you will find it in 5-10 attempts (vs the worst case of 252).

In pytonish pseudo-code:

def checkForRoku(lastOctet):
  if 0 < lastOctet < 255:
    testIP = <construct IP w/network base and lastOctet>
    <if possible do host ping test first>
    # better if you can provide short connection timeout
    if <test over http for roku> : return testIP
  else: 
    return None

myIP = <last octet of my IP> # e.g. 9 for 192.168.1.9
for i in range(1,254):
  rokuIP = checkForRoku(myIP+i)
  if rokuIP: break
  rokuIP = checkForRoku(myIP-i): 
  if rokuIP: break

# and here rokuIP is either the correct IP or bupkis

[TheEndless]

"EnTerr" wrote:
Why is it hard for you to ask your user to go to Settings / Player Info and ask them to copy the IP from there? You can cache that value in a cookie and moreover you can probably get the first 3 numbers from the browser host IP anyway, so we are talking about asking the user to enter one number when first using your web app or after on load you find out there is no connection (so you show popup asking them to check).

That's how it already works. The remote is also entirely client-side javascript. There are no server-side components, so capturing the request headers isn't really an option.

As for Roku knowing your internal IP address, how is that a security concern? My Roku's IP address is 192.168.12.132, what can you do with that?

[brandon15811]

"TheEndless" wrote:

"EnTerr" wrote:
Why is it hard for you to ask your user to go to Settings / Player Info and ask them to copy the IP from there? You can cache that value in a cookie and moreover you can probably get the first 3 numbers from the browser host IP anyway, so we are talking about asking the user to enter one number when first using your web app or after on load you find out there is no connection (so you show popup asking them to check).

That's how it already works. The remote is also entirely client-side javascript. There are no server-side components, so capturing the request headers isn't really an option.

As for Roku knowing your internal IP address, how is that a security concern? My Roku's IP address is 192.168.12.132, what can you do with that?

You could request the netflix icon from a img tag, and check with javascript if the image loaded correctly

[TheEndless]

"brandon15811" wrote:

"TheEndless" wrote:

"EnTerr" wrote:
Why is it hard for you to ask your user to go to Settings / Player Info and ask them to copy the IP from there? You can cache that value in a cookie and moreover you can probably get the first 3 numbers from the browser host IP anyway, so we are talking about asking the user to enter one number when first using your web app or after on load you find out there is no connection (so you show popup asking them to check).

That's how it already works. The remote is also entirely client-side javascript. There are no server-side components, so capturing the request headers isn't really an option.

As for Roku knowing your internal IP address, how is that a security concern? My Roku's IP address is 192.168.12.132, what can you do with that?

You could request the netflix icon from a img tag, and check with javascript if the image loaded correctly

You'd still need to know the subnet, otherwise you're loading an awful lot of images.. 😛

[gonzotek]

"EnTerr" wrote:

"gonzotek" wrote:
I've been spending some time thinking about this. SSDP discovery is great if your platform can take advantage of it. But apps like Remoku (and other 'web'-based services, and apps on platforms that ssdp isn't implementable in, like WebOS) need another way to determine the Roku addresses on the local network.

Why do you say UDP multicast (which SSDP is) is not implementable on WebOS? I can't find read to that extent, except that you may need to call API to open firewall port.

My mistake, that does appear to be possible. Someone who develops with WebOS will have to confirm(and hopefully implement 🙂 ).

"EnTerr" wrote:

The approaches you describe are overcomplicated but more importantly are security and privacy concern. Roku provided my home IP address to third parties, say whaaat? 🙂 I don't think that will pass muster with a CPO (chief privacy officer). Third parties controlling your Roku player via Roku web service is also creepy.

Remoku (among other apps) can already control your Roku via web service, that's what ECP is designed for. Any website/service could implement it. At least Remoku is open, and anyone can see for themselves exactly what connections are being made, and can run the code from their own servers, so that they can be as secure as they choose to.

I don't think it's overly complicated (from a user perspective), nor is it insecure, to be presented with a one-time authorization page that asks permission to retrieve this info from a roku account. Facebook, Twitter, and Google all routinely support requests for, and transmission of, much more valuable personal data than a local IP.

Why is it hard for you to ask your user to go to Settings / Player Info and ask them to copy the IP from there? You can cache that value in a cookie and moreover you can probably get the first 3 numbers from the browser host IP anyway, so we are talking about asking the user to enter one number when first using your web app or after on load you find out there is no connection (so you show popup asking them to check).

That's what I'm doing now, and what all remotes had to do before they implemented SSDP(or the scan you suggested below..I think DVPRemote for iPhone did this pre-ssdp). You can't get any part of the ip address from pure javascript, which is by design. Javascript doesn't allow any detection of the local ip address, so the user has to enter more than just the final octet. We could use something other than pure js, like a java applet, but that limits us to platforms where java runs. In other words no iOS, and (without looking) probably not Kindle or Nintendo DSi, all devices that remoku currently works on.

Here is additional idea (hack, really) but i don't know what the browser abilities are to open multiple connections (js threads? async?): in overwhelming number of cases the Roku player will be in the same /24 network like the browser and the two IPs will be really close (routers tend to allocate dhcp in order, whether starting at .1 or .100). So if you could possibly start probing the network for Roku, chances are you will find it in 5-10 attempts (vs the worst case of 252).

I've done this in an unreleased copy of remoku. It works. It's still a hack compared with an authorized request for the info. It still requires re-scanning(for an indeterminable amount of time, even if short) any time an ip changes, versus a request to the web-service (In plain english: App:"Has there been any change to any roku registered to this account since the last time I asked?" Roku:"No." OR Roku:"Yes. ROKUSERIAL# is now 192.168.1.13").

Like I said already, the second proposal doesn't require anything further from Roku. If someone wanted to maliciously implement parts of it today, to collect the local addresses of Roku units would be trivial. Stick the code in any of the several Roku home media servers that are out today and let it report back to a public server somewhere. What I suggested in the first scenerio would give Roku and users control over who has requested access to the info, with the ability for either the user or Roku to revoke access at any given time. Like I already said, I can also see the objections Roku might have to implementing this on their end.

[EnTerr]

"TheEndless" wrote:
As for Roku knowing your internal IP address, how is that a security concern? My Roku's IP address is 192.168.12.132, what can you do with that?

Personally, I would like to know myself what the concern is, yes. But there are others that impress it is an issue, random URL here: http://www.auditmypc.com/internal-ip-address.asp

Why are we striving so much to implement ECP in Javascript, just to prove Atwood's Law (Any application that can be written in JavaScript, will eventually be written in JavaScript)? Here it seems to be the wrong tool for the purpose, after given reasonable amount of effort. Sometimes microscope can be used to hammer a nail - pity as it is - and sometimes pickax can't screw a Philips head, why ask the manufacturer make pickax-compatible screws?

ps. Is there a javascript to discover and control my iPod Touch?

[TheEndless]

"EnTerr" wrote:
Why are we striving so much to implement ECP in Javascript,

Portability. The beauty of Remoku is that I can save it to my desktop and launch it locally if I want, without the need for a web server.
The ECP requests are also made on the local network, which the web server wouldn't necessarily be able to see, so a client-side solution makes more sense.

[gonzotek]

"EnTerr" wrote:

"TheEndless" wrote:
As for Roku knowing your internal IP address, how is that a security concern? My Roku's IP address is 192.168.12.132, what can you do with that?

Personally, I would like to know myself what the concern is, yes. But there are others that impress it is an issue, random URL here: http://www.auditmypc.com/internal-ip-address.asp

I don't see much relevancy in that page, with regard to the issues present to Roku in the context of this discussion. Roku units on a local network broadcast their addesses. They respond to any command from any host, without regard to authentication, local or remote connection, or previous session activity. They're inherently insecure in this regard and my proposal that Roku provide a secured api for access to the local ips(versus catching the ssdp broadcast) does nothing to make that worse.

Why are we striving so much to implement ECP in Javascript, just to prove Atwood's Law (Any application that can be written in JavaScript, will eventually be written in JavaScript)? Here it seems to be the wrong tool for the purpose, after given reasonable amount of effort. Sometimes microscope can be used to hammer a nail - pity as it is - and sometimes pickax can't screw a Philips head, why ask the manufacturer make pickax-compatible screws?

Multi-platform support. If a device has a semi-modern browser, it can control the Roku. I didn't consider devices like the Kindle or Nintendo DSi when I started Remoku. I set out to learn some html5 techniques, and write a remote that I could use on my pc and iPhone. I hoped it would work on Android. It was the users who tried it on a bunch of different devices, and it turned out to be very compatible across many different phones, tablets and game systems. I wouldn't necessarily want to use a Kindle to control the Roku, but in a pinch, it'd get the job done.

ps. Is there a javascript to discover and control my iPod Touch?

Probably not, as Apple hasn't published a protocol for it. Being that Roku HAS published one, and has already made certain choices about security vs. usability, I don't see why we can't discuss further improvements to it.