Why Does My Remote Control Need to Know My Location?

Sounds like lawmakers need to enforce warnings labels on such products: „works only with sensitive data collection“ or similar.

My Sonos system is by far the biggest slice in the “Blocked” pie chart of my PiHole dashboard. I have no idea how much dat still ends up on their servers because I didn’t bother to dig too deeply yet.

Next step is different VLAN with no internet access.

If you're interested, I sell a dedicated Sonos music controller (built out of wood no less). It's available at https://turntouch.com and it's entirely open source so you don't have to worry about me taking your data and selling it. Earning money based on the initial sale is all that I want out of my users. That and props.

I can't see how situations like this aren't anything but a bait and switch. You buy something, it changes out from under you.

> They used to sell dedicated controllers/remotes years ago but these were also bricked as part of an upgrade about a year or two ago.

Would a class-action be successful in a situation like this?

Come to think of it, this is the real work rivaled of an API breaking change. It seems entirely reasonable to that we should have regulation that prohibits this kind of change after you've already purchased the product. But then again, in a sane system, you should either need to sign the user agreement for anything at purchase time or be allowed to return a device whenever you encounter a the (new) user agreement. Currently you might buy something that you cannot return and only then at the user agreement. The user aren't should be seen as pay of the purchase contract and the purchase shouldn't be valid without it being signed.

Does anyone know of a good (from a privacy and usability perspective) alternative to Sonos?

I plan to buy 5-6 of them sometime later this year, and for what that costs, they have no excuse to data-harvest me.

"... Unfortunately I have a Sonos system ..."

How very funny - as I read the OP and was clicking into the HN comments, all that I had on my mind was "Sonos".

I wish I had the time to clearly and succinctly elucidate the path of Sonos, corrupted by the mobile ecosystem and a reach for easy profits, from a darling hardware provider that users loved to a wannabe data broker that I hate-use.

I have been on the fence of buying a Sonos because I've always loved the sound quality but I could never bring myself to spend so much on them, your comment along with comments in this thread have made my decision easier. I'm going to stick with my dumb speakers and avoid all the hassle that comes with "smart" devices.

I know I'm in the extreme minority here but I also hate Netflix, Amazon Prime, Hulu, Spotify, Apple Music, and even Youtube tracking what I watch. For youtube I watch lots of things in incognito mode. I like the idea of getting recommendations. I hate the idea of a profile being built on me.

Yes I get this Sonos is arguably worse since they're spying on stuff not from a service. iTunes does this as well though you can opt out. Oculus does it too. No opt out there AFAIK. Steam as well. You can add in PS4/Switch/Xbox too.

Does the law preventing companies sharing your video rental history apply to internet companies and streaming music, videos, and games?

> by having it run on a disconnected network

This is only a temporary solution to the problem of devices phoning home against your wishes (or knowledge). The "system-on-a-chip" CPUs used in embedded ("smart") devices with an integrated cellular (LTE/etc) modem have existed for years[1]. The hardware that can simply bypass your local network and phone home over the cellular network already exists. The people that want to spy on everyone for profit will no longer ask for internet access through your LAN when someone finally negotiates with the carriers for some sort of low-priority/off-peak access they can use to batch-upload their eavesdropping ("analytics").

[1] random example from "Q4 3014" https://en.wikipedia.org/wiki/Exynos#List_of_ARMv8_Exynos_So...

I don't have any internal data, but I expect that the percentage of Sonos users that play music from a local source is in the single-digit percentage now. The product they sell is focused on supporting streaming audio and voice control, all of which involved 100% monitoring of what you play and ask for. You're just not their customer anymore.

You can find old used squeezeboxes on Ebay, and their server software is just a big perl script. That might meet your needs.

It is such an outrage that it is now just taken for granted that your hardware and software will be remotely attacked by the manufacturer. It doesn't even raise eyebrows anymore.

And looking at the Sonos debacle, I don't think they realize how damaging it is to their brand to just make their devices die every so often. Why not just save money and get something that is unreliable because it is cheap and poorly engineered?

It’s the reason I would never buy Sonos. I’d be interested in seeing an EU user give this the GDPR treatment

Hi!

You might be interested to know that the Turn Touch homepage starts playing audio as soon as it is opened. This was enough for me to close it and never come back, and I think this sentiment is reasonably widespread.

I'm genuinely curios about the reason some people decide to add audio (or video for that matter, but audio is way worse) on autoplay. Do you enjoy when web pages you visit do it? Did you see from some kind of metric that it increases your sales?

This is an awesome product.

Have you ever seen anyone with nightstand or coffee table where they hollowed out a section for the remote to go in.

I like the idea of being able to pop it out and take it withe me, but 99% of the time I would want it in the exact same place so I would love if it could lie flush and be a part of nightstand.

Any reason you don't support Android? This sounded like a perfect solution to have a physical button to control my smart lights, but then I realized I can't use it.

This is only true if they have access to a ssid database. This is very expensive to build, I guess Google has one, I think they don't give you directly access to it.

Um, no, that's not correct. SSIDs aren't tied to geographic location. The mothership might infer location by looking at the list of SSIDs and checking it against a geotagged list compiled by a mapper, but that's a completely different thing that saying if you let an app look for an SSID you are allowing to it to know your location. You might as well say that by giving a camera the ability to know the time, you are allowing it to know your location, as someone could look at the sun's shadows or weather and infer location.

> Google, in its wisdom, has tied "Location" into things like BLE Scanning and WiFi scanning

That line implies Google made a "stupid mistake" here, when to me it seems like it was very much a calculated/malicious move.

Perhaps I am being harsh on Big G here. But is there a better way to do this? Could an app request a list of all BT/WiFi devices starting with the first few digits of a MAC?

In this case, the remote wants to know if it is near the receiver. It doesn't want to search all devices - just to know if it is near a specific group.

But this is a failure on Googles part to not have a streamlined api for detecting external devices, a feature which is becoming more and more popular with smart devices. Apple has protocols like WAC that you can conform to and be visible to an iOS user without anything special. Inside your app you hand off control to the user to identify and pair that device so that you as a developer don't need special permissions and custom code to link things up.

Our iOS app is able to run without any special prompts for the user on first run, whereas our Android app has to ask for location services with lengthy explanations before they can get past the first screen.

There's a bit of history to this. Not going speculate too much on this, but I bet it has to do with some events in Germany a few years back.

I am probably missing something about the BLE scanning process, but why does one need the location permission after the first pairing?

Could one not just try to connect to the paired devices without scanning? There are presumably not that many paired devices.

How about a limited API that lets a program scan for a particular SSID - so it can look for a "PioneerSoundsystem" SSID, but it's much harder to scan for all SSID's.

Still not perfect, since it can search for well-known SSID's like "StarbucksWifi" or "Comcast", but it limits the exposure - the API could have a limit on how many SSID's can be searched for by the app before you need to re-authorize it, so it can only search for 6 SSID's instead of the top 10,000 SSID's.

Or the permission request can include the SSID "This app asking for permission to search for PioneerSoundsystem SSID" or maybe a prefix like "PioneerSoundsystem-*" so they can append unique ID's.

Though in reality it will never happen because few people care -- most people are happy granting the app whatever permission it requests.

Well I agree lots of times what the app wants is innocuous, I'd still rather have the message than not.

Maybe an option to open up a more detailed description of what the app wants the permissions for?

Totally agree. There should also be a log of what feature apps have actually accessed.

"Alarming text"? It should be alarming that to play my music with my sound system, I have to give away location data.

Frankly, this text isn't alarming enough.

Two problems with this assumption per the article: 1) the app previously worked fine without the location information 2) the app no longer works at all without location information.

The only legitimate use case for location I can think of would be to pull down cable/tv/radio channel/station listings. But this shouldn't be a requirement since the user could easily manually enter in the ones they want. My guess is that something like this might be used as the pretext for requiring location. However, if the app continues to require location to function longer term (i.e. that this wasn't just an oversight which gets corrected in a future update) then I would assume that the real use case is something that has nothing to do with helping the user.

This can easily be solved by app developers though. Add a screen before the permission explaining why you want that particular permission, and limit asking permissions to the point that you need to use them rather than the first time the app starts up.

Too many apps ask for permission immediately without any context as to why they're doing it.

This is a pet peeve of mine with Android (don't know about iOS). Another example:

Browser wants to download a file, so I have to give carte blanche permission to access all my files. Why can't I just give permission to place new files with app-supplied content, i.e. no reading of existing files, no overwriting / deleting of existing files, and OS-managed name collision resolution?

The same applies to the camera app. And no, the camera app does not need to read my files to display a gallery of photos taken. The gallery app already does that, and Android is perfectly capable to re-using an activity (via intent) of the gallery app as part of the camera app without the latter gaining any permissions.

Indeed. Our app once required location permissions because - get this - a webkit view used for settings used jQuery, which did some kind of screen orientation thing that somehow required location be turned on from the app.

I think a jQuery update fixed it, but don't recall. It wasn't simple to track down either.

Disclosure: I work on a Sonos competitor [1] that tracks customer data purely for product improvement and is fully opt-out-able.

[1] https://www.bluesound.com

For good reason! There's many online services where you can put in a wifi MAC and pretty much know within 100M where someone is.

Yeah, the message could be made clearer about what's actually being allowed, but in the end I'm glad it's there. Maybe a generic system for when you request a permission being able to provide an explanation string or something. I know some apps made a pop-up before the prompt but I found that rather verbose especially when it was incredibly obvious why they needed the permission.

My charge3 (basically, the same as a charge2 but truly waterproof) connects to my phone when I enter a "Walking" exercise and it uses the GPS data to plot my route AND to optimize my average step length distance. They do sell trackers with embedded GPS (that eat battery life, as you'd imagine)

I'm just saying fitness trackers have at least one legit reason. Unlike a remote control seemingly having no legit reason to scan local wifi.

Why does the app need Bluetooth or WiFi scanning permissions? Can't you handle the pairing in the OS and allow the app to use an already established connection?

If you only enabled that location tracking you wouldn't be in this problem.... :D

> I’m incredibly annoyed that phones don’t report themselves with randomized Mac addresses. WiFi tracking is pervasive.

You've got it backwards. The phone isn't being tracked, the phone is the one doing the tracking. The phone is looking at all the wifi APs it can see and then looking those up in a database.

Nobody sees the phone's MAC address. It isn't broadcasting anything at all.

four or five sig figs of internal pedometer step counts is rubbed up against four or so sig figs of phone-gathered GPS distance data after formal activities in the fitbit app to fine tune your stride length. In my case my stride length is about 75.821 cm per step. Then it can use that calculated stride length to estimate distances when not doing official activities. As if my hiking boots are identical to five sig figs to my urban walking shoes or my sandals, LOL. Well, in theory, at least, its a good idea.

Fitbit UI, weirdly, explains what its doing but refuses to provide the actual numeric result.

To some extent its overkill... from my experience orienteering as a civilian and in the military, your average stride length might vary up to 5% based on conditions. You can't use dead reckoning alone to do land nav on foot for long distances, you need a map (or GPS). Which I guess is kinda the point of the fitbit needing GPS access. Doing theoretical calculations to 4 sig figs means at least on average its not too far off, and frankly most athletes use the same boring path every day with the same shoes etc so averaged track data is going to be more accurate than a wilderness land nav course anyway.

I have not decompiled the fitbit code or done anything illegal but IF I were to implement this I'd include GPS/map based ground slope data as a correction factor because I know that has a major impact on stride length. I have no idea if fitbit does that, but they should.

You can get the answer to that question by reading the section of the article headed with "Cause #2", or from this page: https://help.fitbit.com/articles/en_US/Help_article/2134

Disclosure: #fitbitemployee but speaking only for myself.

Some google searches for old custom roms for Android would help. I recall stuff like this in non-commercial 2.0-series android custom roms.

For a very specific example of the genre, pdroid and its numerous clones (some of which were trojans as I recall) from around 2011 seems to almost perfectly match your request.

You know you're in deep when you have to root your phone, install a custom rom, then patch the custom rom, just to limit how much you're getting spied upon.

I'd guess it's easy and cheap.

You can make a purpose built remote with BLE and a nice screen, or buy a cheap Android phone for a fifth (guessing!) of the dev costs?

To clarify. The amp does have a physical infrared remote. It also has an Android app I can run on my phone.

I always know where my phone is, but the regular remote likes to hide in the sofa.