On 11/27/20 8:00 PM, Theodore Y. Ts'o wrote:
One important thing to remember is that IETF is a volunteer
organization. So the companies involved would need to be willing to
send engineers to work on the standardization process --- for years
and years and years.
And for what benefit? As far as Apple and Amazon is concerned,
customer lock-in to their ecosystem is a *good* thing. Heck, for a
while, Amazon refused to sell any of Google's chromecast product on
their website. So from a business perspective, if you can't convince
Amazon or Apple or Google why they should spend person-years if not
person-decades standardizing something, which might delay rollout of
the product, and perhaps make it easier for the competition to get
customers to transfer their ecosystem allegiance from (say) Apple to
Amazon --- why should they do it?
So there are certainly some people who prefer open, standards driven
protocols. But if they are not a sufficient large part of the
customer base, such that there is a business advantage, and the
standards route has velocity disadvantages and other downsides such as
making life easier for spammers, it is really quite unreasonable to
expect companies to do something just because you want something based
on interoperable standards.
Sure I understand that they all want walled gardens but from a consumer
standpoint it is completely impractical. Some people will use Apple,
some people will use Google, some people will use Amazon and two or more
of them exist in a huge swath of the households. This leads to a
complete mess of incompatibilities, missing features, and other bizarre
things like "can i shut my laptop while this thing is playing?" All of
this is bewildering to people who aren't tech savvy and ain't much
better for those of us who are.
And yes, it takes time and money to standardize things, but it takes
time and money to roll your own, maintain, and keep up with Joneses.
TANSTAAFL.
And then there is security. I had better Google Fu this time around and
found some developer documentation for chromecast the protocol. After
some hunting, I found that the sending app (ie, phone) delivers a URL to
the media to be played, and the users credentials apparently in plain
text to the chromecast. Is that OK? It sounds a lot like it has the
problem that OAUTH tries to avoid which is doglegging credentials
through something else, perhaps hostile. Apparently their API now allows
for apps to be written both on the sender side, and on the chromecast
side so it sounds like it's no longer the case "oh, i can trust google
not steal my credentials". what is the threat model here? I could even
be wrong about half of this and still illustrates my point that closed
box protocol designs like this in IoT land are scary.
All of the above in your message could be said of Apple and Microsoft
years ago when a lot of the media stuff was getting hashed out, for
example. Both would have been delighted to have a walled garden if they
could get away with it. But somehow they managed to bite the bullet and
cooperate in many important cases. Think about the combinatorics of
misery had they not and then grafting on all of new stuff. Yuck.
Mike, yes i know i'm pushing on string, but maybe it's a string worth
pushing for a bit
