Google Cast receiver JS - has unprotected calls to window.crypto

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a cast app
2. Write unit tests in jasmine or whatever
3. Try to run said tests in phantom and watch it fail when it tries to evaluate 
window.crypto.anything because this API is not yet supported in phantom.

What is the expected output? What do you see instead?
The expected output would be the cast app not crashing in phantom.

What version of the product are you using? On what operating system?
This is the receiver lib that was released last week. 

Please provide any additional information below.

Would be helpful if google-cast-team could protect calls to non-standard API's 
in all the google-cast JS files. I'm doing something like this. 

if (window.crypto && window.crypto.subtle &&  window.crypto.subtle.decrypt) {
 // do your thing with crypto
} else {
  do nothing and hope my unit tests pass
}

Thanks for the help,

Also - would be really really helpful if the version numbers on the receiver js 
file were revved along with the code inside. None of the sample apps seem to 
have been updated in a while and its pretty difficult to tell what code was 
supposed to work at what point in time and when changes were introduced.

Original issue reported on code.google.com by jose.her...@rd.io on 1 Jun 2015 at 11:35

[GoogleCodeExporter]

You can override this behavior by mocking the call, i.e. "mock 
window.crypto.subtle.decrypt". This should let you create mock crypto objects 
for testing.

Original comment by jonathan...@google.com on 2 Jun 2015 at 9:44

• Changed state: Invalid

[GoogleCodeExporter]

Right? That seems like the obvious approach but I already went down that path 
and the test environment I'm dealing with (phantom+jasmine) needs to bootstrap 
itself before I can mock or test anything - this file crashes phantom 
immediately because the un-protected calls are right up there in the init code 
for the receiver lib. This would also error out on quite a few other browsers 
such as IE10. Not that I would but it's possible.

My temporary solution was to remove this library entirely based on non `CrKey` 
user agents. Unfortunately this sidesteps our entire front-end dependency 
management / build system and as a side we can no longer test our receiver 
without remembering to spoof the user agent. The solution I'm testing now is 
basically what I asked for above - modify the lib to protect all the crypto 
calls. It even looks like someone at google actually started to do this with 
cryptoKeys but didn't finish the job so it only took a few minutes to propagate 
the pattern. Low and behold, it works, doesn't crash phantom and seems to still 
do its job - so its currently the best option we've got. Regardless of whether 
the problem is deemed valid or not, this seems to be a valid and pragmatic 
solution, so it is currently the most favorable.

I'm thinking it'll be a lot easier for google to simply protect the 
non-standard browser api calls in this one file than for partner developers to 
jump through all these real-world hoops. Previously we hosted a copy of the lib 
in order to prevent un-intended consequences due to un-announced updates. Now 
we have no choice but to host it in order to maintain the subtle variances. 
Eventually I imagine google is going to update the lib for various reasons and 
the integration is going to break because we'll be using an older version. This 
introduces more things to remember and creates more work.

I understand why the issue was marked as invalid but it is costing us time and 
effort, hurting the effectiveness of the integration and taking away from our 
ability to target and test various cast hardware devices - and therefore 
hurting the cast platform as a whole (google + hardware partners + software 
partners that are working toward a common goal). Please consider addressing 
this the easy way so we can get back to the master branch (so to speak) and 
avoid the incompatibility headaches that are guaranteed to arise with the next 
receiver lib revision. 

Thanks,
Jose M. Hernandez, Rdio

Original comment by jose.her...@rd.io on 2 Jun 2015 at 10:50

[GoogleCodeExporter]

Hi Jose, our TAM will contact you for further assistance regarding this issue.

Original comment by jonathan...@google.com on 2 Jun 2015 at 11:47

[GoogleCodeExporter]

Thank you for taking the time to look into this.

Original comment by jose.her...@rd.io on 3 Jun 2015 at 5:16