Hacker News Reader

Comment by tylerkahn | Hacker News Reader

https://developers.google.com/cast/release-notes

> Warning: The current Google Cast SDK is a preview SDK intended for development and testing purposes only, not for production apps. Google may change this SDK significantly prior to the official release of the Google Cast SDK. We strongly recommend that you do not publicly distribute any application using this preview SDK, as this preview SDK will no longer be supported after the official SDK is released (which will cause applications based only on the preview SDK to break).

View on HN

Exactly. I think we're a long way from malice here, or even incompetence. That the ChromeCast has an SDK at all at this stage seems like a pleasant surprise; I feel certain the API will become more stable over time. If this were truly intended to be a closed device, unavailable for use except by specific media partners, why would there be a public SDK at all?

In the absence of a statement from Google that the ChromeCast by design doesn't support the functionality used by this or other video streaming apps, I'd consider it premature to assume intentional breakage.

>> I think we're a long way from malice here

If you think about why did google enable local content streaming(but with bad/no sound - how hard is for google to get the bloody sound working before an important launch?) and whitelisting and used hdcp(secure content) on this device , google's strategy becomes clear:

They want to frighten content owners into submission. Let the content owners know that if they won't support chromecast , google will open it, and content companies will suffer.

On the other hand ,if content owners play ball, google will provide highly secure platform(and i wouldn't be surprised if tab casting will turned off - it's currently labeled experimental). This is the preferred road for Google, since there's more money that way.

In light of this potential strategy , there's probably malice in the last changes.

In the future, when video playback isn't restored and Google makes a public admission that they don't intend on restoring it, would you mind if I remind you of how you were naive and foolish?

When Google's next hardware product comes out, can we stop thanking them and instead point out how they have a history of releasing products that give users no control over what runs on them?

Google has far more technical expertise than any ISP, so it stands to reason that they'll be using that to push down on users more than any other ISP has in the past. We may yet regret clamoring for Google Fiber to be everywhere.

Entitled much? What obligations does Google have here, exactly?

Huh? The GP comment never mentioned or implied the word "obligation".

The ultimatum is for Google to restore undocumented functionality or publicly state they don't support openness. And we're all fools to think Google will go to the ends of the earth to support everything imaginable! Replace Google with Apple in the GP to understand the entitlement and just how foolish we aren't.

Sorry, but I just don't see it. All I see is a complaint and a demand for a feature. IMO, that's not entitlement. Entitlement would use words like "owe" and "responsibility".

I don't feel entitled to anything, I just take a perverse amount of pleasure in pointing out how much shit people are full of.

I'm just trying to encourage some honesty from an intellectual perspective -- why confuse ourselves when the outcome will be no different than the last? Why do we willfully continue to lock ourselves into an ecosystem, be it Google, Facebook, or Apple?

Only if you don't mind to be reminded of your own foolishness when similar functionality is enabled through SDK.

I don't understand this animosity towards Google, it's like every little change to the status quo triggers a hate-fest here on HN accompanied with wild accusations (only to be debunked soon after). They pushed a system update that broke undocumented APIs, they could be patching a security vulnerability for all you know, there is no need to commence spreading FUD about some other unrelated initiative.

If Google were to correct me then I would gladly eat my hat.

Personally I feel no such animosity towards Google, however any perceived hostility towards Google is purely coincidental -- my hatred is towards bait&switch and other parasitic corporate practices.

> I don't understand this animosity towards Google, it's like every little change to the status quo triggers a hate-fest here on HN accompanied with wild accusations

It’s not just Google, we like drama around here.

  > When Google's next hardware product comes out, can we
  > stop thanking them and instead point out how they have a
  > history of releasing products that give users no control
  > over what runs on them?

Consumer hardware devices that Google has released so far are: Nexus {One,S,Galaxy,4,7,10,Q}, Glass, Chromebook Pixel, Chromecast.

All of the Nexus devices (except for the abandoned-before-launch Q) have official support for flashing custom firmware. The Chromebook Pixel comes with "developer mode", which turns it into a standard unverified laptop. Glass can be unlocked, and Google employees demonstrated how to install Ubuntu on it at Google IO.

Other than the Chromecast, which devices do you feel restrict the user from controlling which code they run?

Past performance isn't the only indicator of future performance. What will you say when it's revealed that the Chromcast is Google's first foray into locked hardware, and that they liked how it was well-received by consumers?

and what will you say when you're wrong? either scenario is just as likely from the information available

I can't think of any tech company in Google's league that matches them in terms of device openness.

The Nexus phones and tablets officially support flashing of custom ROMs.[1,2]

The Moto X will have an unlockable bootloader on carriers that allow it.[3]

Google gave a tutorial on how to root Glass (see the I/O talk "Voiding Your Warranty: Hacking Glass" [4]).

All Chromebooks have a developer mode that can be accessed using a hardware switch or key combination. See e.g. [5,6] for the Samsung ARM and Pixel Chromebooks.

Google even provides instructions for disassembling the Chromebooks ([5,6], at the bottom).

I don't think it's wise to ignore Google's history and extrapolate the future based exclusively on an SDK preview.

[EDIT: Downvoters, I would be curious to know your motivations.]

[1] http://en.wikipedia.org/wiki/Android_rooting

[2] http://android-developers.blogspot.ch/2010/12/its-not-rootin...

[3] https://plus.google.com/+PunitSoni/posts/e6oQdFnLGiv

[4] https://developers.google.com/events/io/sessions/332704837

[5] http://www.chromium.org/chromium-os/developer-information-fo...

[6] http://www.chromium.org/chromium-os/developer-information-fo...

What is there to restore if Google never enabled it through the SDK in the first place?

He was not using the SDK. Google went back into their code and changed it just to break an app built by a developer. And, to be fair, Koushik, just alerted people who were planning on buying chromecast because of his app to hold on as his app may never be white listed.

It's a little presumptuous to say why they changed a private (emphasis on PRIVATE) api...

This. The API and its feature set is liable to change. This isn't a broken promise because no promises were made.

Do you think the intent of the post is to complain about SDK compatibility ? :)

I think he was saying that this is a case of Hanlon's razor[1]. i.e. this situation could be easily explained by simple api churn (and the fact that the OP was using an undocumented api), so it may not be appropriate to ascribe malice without evidence.

  [1]http://en.wikipedia.org/wiki/Hanlon's_razor

I agree with your point.

The larger implication (not withstanding using documented or undocumented API) is violation of general assumption that Chromecast will be open and idie friendly than the Apple TV.

Even if the OP had used a documented API, the developer warning is clear that any and all API can be changed.

You should have seen the reaction to this on Reddit/r/Android.

I thought Google made it clear from the beginning that this was intended to be a beta release until testing was done. Looking at Reddit I was shocked to see the number of people who think Google is trying to force them into buying from the Play Store.

The point isn't about functionality changing as much as how "open" the functionality is going to be.

The author posted code that suggests that the ability to stream arbitrary content has been intentionally disabled.

https://plus.google.com/110558071969009568835/posts/HbrpBbVG...

Looking at the actual code, it looks a lot like a random hack thrown into beta code to disable a feature that isn't ready for use yet. It doesn't look like those 3 lines of code are a long term solution to anything. It is hard to attribute a motive to code, but I don't think the motive of that snippet is less openness.

Reply on news.ycombinator.com