Even more so considering the really complex situation Sonos is in – as an independent platform for streaming music from dozens of services, and in the future as a platform for digital assistants, they have a bundle of multilateral legal and contractual obligations that they need to handle on top of maintaining a technologically demanding product.
A case of really bad journalism can be found at Heise (Article in German): The article summarises some of the requirements from the actual privacy statement, but does not contextualise anything. It fuels outrage with the headline: »Sonos fordert mehr Daten, sonst droht Sendeschluss« (»Sonos demands more data, else the music stops«).
The title phrase hinges on the sentence »Der Kunde kann den neuen Vorgaben zustimmen, oder akzeptieren, dass sein Produkt vielleicht mit der Zeit aufhört, zu funktionieren.«, attributed to a Sonos spokesperson. (»The customer can accept the new conditions, or they can accept that their product over time may cease to function.«). That’s very bad wording on the side of the spokesperson, but it may well be that the context is lacking – it is pretty clear that if a streaming services API changes and you do not apply updates to your Sonos System in order to prevent acceptance of the new T&C it has no chance of working. Heise did nothing to clarify or contextualise this statement, though.
So what does Sonos do? The Sonos System in my part of the planet currently offers 45 primary online sound sources plus beta-level lab offers. A full list is supposed to be here.
For each of these, Sonos is a proxy providing identity and authentication – preferably in a way that does not entrust Sonos with your password and is nonetheless secure.
That means, you authenticate yourself to the streaming service (“It’s me, I am Kris and I am your customer”) and introduce the Sonos as a legal playback device to the service (“I am still Kris and this is my Sonos. Please send streams to this thing.”) . Ideally this is implemented without the Sonos System or the Sonos Online Services getting a chance to see for example your Google password which would be necessary to login to Google Play Music All Access (“GPMAA”), which is Google’s music streaming service.
Some streaming services grant Sonos special privileges – for example, GPMAA counts a Sonos household as a single device, even if it contains multiple Sonos Systems. You can consume more than one stream at a time – play back one thing on the Play:3 in the childrens room, and another thing on the Play:5 in the living room. That does not work with the same account using GPMAA and two cellphones. So Google needs a mechanism that allows a Sonos to identify and authenticate itself as a privileged device.
In any case, the streaming provider then trusts Sonos with the stream, which is intended for playback, and not for digital data capture or other forms of recording.
Also, there is a pretty beefy MIPS CPU, with a Linux kernel that is used as a wrapper around the device drivers for the playback hardware, and as a starter for a giant C++ blob which is then doing everything else. The whole thing is pretty overspec’ed, which allows them to provide software improvements through updates. Which they do – to my knowledge every piece of playback hardware they ever built is still supported within the limits of the hardware.
Sonos Systems differ from Bluetooth speakers. How?
With a Bluetooth speaker, your cellphone is downloading the MP3 stream from the streaming service, re-encodes it into whatever format the Bluetooth profile of your speaker requires (which may or may not require transcoding to a different format), and then send it out again, using Bluetooth.
That means: With a Bluetooth speaker
- Your cellphones processors, Wifi-circuits and Bluetooth circuits are powered up and active all of the time during playback
- You cannot remove the cellphone much from the speaker or you are running a risk of dropping the stream.
So you can’t run around with your phone, and it is eating quite a bit of battery, doubly so if transcoding is required.
With a Sonos, this is different: Here the device, which is plugged into a wall outlet, is requesting the playback and does all the processing. It is receiving the control commands to do that via Wifi, but that’s one command every half hour or so. The phone is not required for playback, and if you have a larger installation, you are free to move around inside it, or even leave the covered area. Other controllers – other cellphones or computers – can pick up where you left and work from there.
Also, multiple Bluetooth Speakers can’t sync.
That’s very different from a Sonos Systems, where all speakers in a system automatically get to know each other, elect a leader, find out a good way to talk to each other reliably, establish a common timebase, and then can sync up to play the same piece of music in a way that you can stand in the door between two rooms and not go insane from desync’ed playback.
You can in fact even link multiple speakers connected by Wifi into a single stereo pair and it works, no echo or distortion.
You can in fact, even calibrate the speaker and the room, using a well known microphone from a standardised piece of hardware, so that echoes, frequency distortions from furniture or people, and other circumstances that may affect the playback are taken into account. The effect is quite remarkable.
Of course that’s a relatively complicated piece of technology here, none of which is visible to the user: You plug it in, and it just works, and sounds quite good – awesome, actually, taking the size of the equipment into account.
Except when it doesn’t – and you call the support. I happen to know a few cases and circumstances where things didn’t work – Wifi did not mesh, rooms got dropped randomly, boxes jumped between two different APs, dropping frames, making playback stutter. Sonos actually has a support, they actually answer, and they actually know what they are doing, and they are equipped to grab relevant debug data from the systems.
All that of course needs a legal framework, which happens to be the privacy statement.
Now if you take the above into account and go through the text one more time, you can see how the various sections map to these things:
- “Erster Kontakt” is about the website,
- “Kauf” is about the purchase process,
- “Registrierung” about the data you need to enter into their website in order to be able to bundle multiple physical devices into a single system,
- “Verwendung” is then about the actual use you get out of the product,
- and “Support” is about the debugging explained above.
The entire thing goes at great length to explain which Funktionsdaten are necessary for the product to work, and which of these are collected when and for what.
Then there are Zusätzliche Nutzungsdaten, which is your consumption profile. These are needed for Marketing only, and are easy to control, in the app.
So all in all, nothing to see here really:
A company changing their privacy guidelines, actually making them really easy to understand, and providing a very clear and easy to understand distinction between data necessary for the delivery of the service and additional data they would like to have for product research and marketing.
And a newspaper that really could do a much better job at delivering context instead of making rage waves.