Is this not a valid approach then? The issues of ossification and strict allowance for just known protocols appear to be big enough to cause things like SCTP to not have a viable, widespread use in their future.
I believe that we will see ossification of QUIC eventually too. TCP has been around for decades, anything around that long is going to have issues rolling out new changes in a backwards compatible way. TLS 1.3 and the lengths it had to go to with backwards compatibility with middleboxes is another good example.
I hope that QUIC has used these lessons from TCP and TLS to make changes in the future as easy and effective as possible, but I’m sure it’ll still have its limits.
The IETF QUIC working is well-aware of this, and is attempting to save design room for future QUIC versions as much as possible. The "QUIC invariants" spec documents everything that is guaranteed not to change, but other than than everything in a future QUICv2 could be updated (e.g. tls version, features, large parts of packet header layout).
I fear that unless they are already actively using different values for those updatable values that middleboxes will implement a de facto version of QUIC that “just works” with what is out now, but no regard to gracefully handling forwards-compatibility. Example is the SSL version field which has become static because many implementations didn’t handle an unknown value gracefully.
You misunderstood what's happening here. A rogue server can request the client to read any file on the client's file system, and the client will comply without validation that the client actually requested this.
Back in the early 90s, I learned the vi movement keys through hunt(6) from the BSD Games collection. Can't find a good link for the package, but here is the man page: https://www.unix.com/man-page/bsd/6/hunt/
RCS is a standard on which development started in 2008 and was built upon the core of another standard called IMS, which started development in 1999. The same year the jabber.org project was announced.
The battery argument is just misinformed. The real reason Google dropped XMPP was not a technical one. Yes, Google claimed it was not "cloud ready" at that GoogleIO. The same one where they announced Google Cloud Messaging, based on, wait for it, XMPP.
Let me first turn this around. I actually personally tried to interact with the Slack team on how they implemented their XMPP gateway, early on. I pointed out how a relatively small missing protocol feature (server-side group chat bookmarking) was severely impacting the usability of the gateway, as it caused caused you to have to explicitly join the group chat room representing a Slack channel on every client (re)connect. In fact they violated protocol in case a client requested the list of bookmarks, causing clients to hang while connecting. It took them a year to start responding, and the problem was not fixed.
Additionally I had pointed that their statements on XMPP security were factually wrong. No useful response or changes were made.
That all said, I really like a bunch of things about Slack and have repeatedly pointed out in discussions in the XMPP community that there is a lot to be learned from Slack in terms of features (and how they work technically), UI consistency, and usability. As JC points out, this is surprisingly hard to achieve in open source projects. Even harder to pull off for a very diverse community around a set of protocols, rather than a single software product.
There are also things in Slack that I think would be a lot better if they were modelled after recent protocol proposals in XMPP. For example we are working on something called MIX, an evolution on group chat, based on Publish-Subscribe. This allows for orthogonal streams of information bound to a channel, besides just chat and presence, like merge request notifications, Twitter mentions, etc. that could be displayed in a side-bar or ticker, instead of (annoyingly) interleaved with chat messages.
I would have welcomed Slack interacting with the community, but they didn't.
The part where playing audio, including that from 3rd party sources, doesn't need Sonos to get any device usage data. However they still want it 'to improve their service', and you can't turn that off. Not accepting terms means that you'll never get firmware updates.
Read the privacy policy, you can opt out of usage data. This article is clickbait crap and completely inaccurate. They clearly tell users how to opt out of usage data collection; I'm not seeing the problem here.
As for the data collection you can't opt out of, it's super basic data like your ip and account registration info. How do you expect to use a cloud service if it doesn't know your ip?
You can play stuff you physically own from a Roku too. Are you saying that Sonos could arbitrarily upload your media files to their servers? Doubtful. At worst, they could do a sound-print analysis locally on the device to identify it and send the metadata to Sonos.
I am trying to think of concrete examples of scenarios where actual harm would REALISTICALLY be done to individual consumers because of Sonos privacy policy.
If an out-of-control oppressive government is the real concern here, is a flimsy EULA _really_ going to provide any protection whatsoever? Can you really even have 100% trust that the EULA will be obeyed by the company if they can get away with violating it?
