At least they acknowledged it, responded to the feedback and fixed it.
Unfortunately I have a Sonos system which became effectively bricked unless I signed a new user agreement allowing the collection of data. There are no physical controls on Sonos so the system becomes useless without accepting.
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. Unhappy owners were offered a voucher (worth less than the value of a single controller - many users owned multiple in order to fully support multi-room - see https://en.community.sonos.com/controllers-software-228995/s...) for their next Sonos purchase rather than allow them to continue to use the hardware they had purchased and used happily for years.
All concerns, requests to be allowed to downgrade, etc. are met on the official forums with a passive-aggressive dismissal of users' concerns by staff backed up by a few cultist fanatics.
I've tried to avoid any further updates (and deny Sonos access to my listening habits) by having it run on a disconnected network but if anyone accidentally updates the app on the old ipad we use as a controller, your forced to update everything. I just wish I had the same system which I originally bought which I use exclusively to play my ripped CDs from a NAS.
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.
What you do with the remote is between you and what you control. I store anonymous metrics that I use to gauge usage levels but you can turn that off. Sonos undoubtedly takes your listening habits and profits off that data but Turn Touch does not, even though it has access to that data.
It tells me which features I should invest more time in getting right and handled edge cases and which features nobody but me uses and so it’s not worth the extra effort. I only have so much time!
OK, I was wondering if you were a complete middleman between me and Sonos. I don't own one, but I would consider it if there were a way to keep their paws off my data.
Btw, this is a tough crowd, getting downvoted for a simple question like this. Sheesh.
Seems cool, and perhaps I'm missing something, but it appears to require a closed-source app from a walled-garden app store to configure it, so it could easily be made useless if the app disappears?
Everything I build I want to last beyond myself. So beyond the source code I also write about the why for everything. That it improves sales is a nice bonus.
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").
> 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").
I can happily confirm that Canada’s telecom oligopoly will never allow such a thing to happen.
Discounts for off-peak cellular data? Bwahahahahahaha
> The hardware that can simply bypass your local network and phone home over the cellular network already exists.
Wouldn't such a thing require an antenna that you could remove or disable to function?
Speaking of... is there a more effective way to disable a cellular modem than removing its antenna? Like some kind of component that you could replace the antenna with that would mitigate any residual antenna-function of the remaining wiring? I want to do this to the modem on my car.
Basically, the problem is the car's electronics have a cellular modem component, but I want everything besides that to continue to function and receive other radio signals. I can disconnect the antenna plug, but my understanding is that will just make the reception worse but not eliminate it.
I'm wondering if there's something simple and safe that would basically act as an anti-antenna, and absorb or interfere with any signals the rest of the electronics manage to pick up or transmit. I don't know much about electronics, but I was thinking maybe some kind of passive component, like a capacitor or resistor, might be able to soak up any residual signal.
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?
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.
Just for conformity so I don't bash and run, it seems Philips (Hue) has taken the crown recently with ~30 times more attempts to call home then the next culprit, Microsoft. MS also snuck ahead of Sonos.
A lot of these attempts are probably due to the fact that they fail and keep retrying. Possibly allowing them all would lead to far fewer attempts.
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.
Quite a few people run systems with a Raspberry Pi, a high-quality I2S DAC+amp, and a set of (normal, non-internet-connected, firmware-free) speakers. There's a tiny industry of producing hardware and software for this situation.
What were you looking to get out of a Sonos? If you just want something that can play music wirelessly from various devices, I'd recommend getting a pair of bookshelf speakers and plugging them into one of (Airport Express, Chromecast Audio, Raspberry Pi[1]). You won't be locked into Sonos and generally bookshelf speakers sound better than all-in-one units. I'd love to recommend some speakers if you're interested (e.g. [2]).
I have run a few Airport Expresses for the past 10 years and love them. Older models are cheap (<$30) and still work great.
Low cost SBC (Raspberry Pi, etc) and whatever speakers you'd like. Airsonic or a basic UPnP server as your driver.
Take it a step further (if you prefer portability of sound quality) and get an SBC with a bluetooth adapter, and several bluetooth modules which you can rig up to each speaker.
Well, there's snapcast that allows you to relatively simply build an alternative, but I don't know if anyone builds and sells ready-made products.
You can probably go by using a couple raspberry pis (or any ARM board with a jack output), a preconfigured SD card image, and some external speakers. I don't know the price of Sonos speakers, but I don't think it would be much higher.
I guess someone could even create a business out of this, especially if tailoring the PCBs to the task.
You don’t mention which ecosystem you live in. I’m very happy with my Apple Homepods. The sound quality is great and I trust Apple with privacy. I don’t use Siri at all (I have disabled the microphone) and so for me they’re purely network speakers which are very easy to use and look after themselves with updates.
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?
I've found Dropbox to be notorious with this. Their business plan used to be only $150/yr (Fine Print: you pay minimum 3 seats.) That magically changed to five seats at some point and now the $150/yr suddenly shows up as $750/yr auto-renewed and almost impossible to cancel.
It was a manner of speech. There was no way to get out of the 2 extra magically added seats, even though you agreed to 3, you pay for 5 because they changed their minimum seat policy. I spoke to customer service over and over and they wouldn't even point me to the agreement I signed...just the agreement on their website (the new one.)
The Adobe Cloud suite certainly is. It took me nearly an hour and a half on customer support to cancel my subscription after it autorenewed without my consent. They tried to charge me a full year of service as an early termination fee, as though they were a 90s cellphone carrier.
Protip for anyone else in this situation: The only way to make the cancellation happen without the fee is to repeat "I need to talk to your supervisor" to the drone on customer support, no matter what they try to tell you about not being able to waive the fee. They will never, ever connect you to a supervisor, but they will eventually waive the fee before hanging up on you.
Is there not an alternative to Dropbox that offers better service for the same if not lower cost? I understand that they could pull the same bait and switch on you but maybe there are providers who wouldn't do that or grandfather you in.
I eventually completely terminated the account and moved to Google Drive. I got lured into DropBox because I was an editor to a book that required DropBox to access manuscripts.
The way they were set up, I ended up having to upgrade to a business user given the shared file sizes I was editing (had something to do with the book publisher being on a business account as well.) I ended up paying more for DropBox than I even made as an editor. Brutal.
It felt like a mobile phone contract: seemingly inexpensive, sneaky, convoluted, and before you know you have a gigantic bill committed to for the year.
That is why i cut the cord on my cable tv. I dont understand how companies can accept the ill-will of bait-and-switch tactics -- is it really more profitable than an upfront deal where each party feels it was an honest deal? I mean, I dont mind paying...but I want know know what i'll be paying and decide accordingly. Cable TV is a virtual monopoly, but DropBox is not and I dont know how they can deal with ill-will from former customers, once bit twice shy.
Host your own Nextcloud on a NAS, and have the most popular files synced? Be sure to make proper backups. On the short term, it will be expensive, but the investment will pay off.
I'm also using Stack by TransIP. 1000 GB for 0 EUR/month, with e.g. offers of 1250 GB for 2,50 EUR/month. TransIP is by made by the same people as bunq (its Ali Niknam's first successful company)
Intention was to set up next cloud on a rock64 talking to my nas as backing store - but it turned out more difficult than I originally intended, might do it all on AWS instead - still not sure and didn't have time to try again
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.
Building a dumb system will also provide a much better audio quality if you're willing to spend some time researching what to do. Plus it's of course more flexible as all parts are replaceable separately.
This is worse, in a way - from what I can tell at the point of purchase the system didn't have the problematic data collection - that was added later in an update. Even a savvy consumer who researched which product to buy would be screwed in this circumstance.
It does seem to me that once a product is purchased, it ought to remain usable and supported under the terms it was purchased under, but that seems a long way from the current laws around user agreements.
The law could include a ban on firmware updates that subsequently introduce and require sensitive data collection post-purchase.
That said, I'm not sure you can really pin this down. It's probably better to just assume that any device that requires a wi-fi connection to work is phoning home until proven otherwise.
And you have to assume that any device that phones home is collecting data. It's not even a secret that this is the case. Pretty much every time I go to a lunch-and-learn for a data product, the major premise of the obligatory client case study is, "We sell this consumer product that does X, but our most exciting product is actually all the data we can harvest from it and then resell."
> any device that requires a wi-fi connection to work is phoning home until proven otherwise.
It's really beyond me why people are buying these devices in case the wifi functionality is completely superfluous and has nothing to do with the main function of the device. It's like asking "hello strangers, tap me and track what I'm doing". This crap needs to stop.
> The law could include a ban on firmware updates that subsequently introduce and require sensitive data collection post-purchase.
This is IMHO a broader issue with products that receive firmware or OTA updates, it's probably legally a breach of contract already to modify products after sale and change functionality to the disadvantage of the consumer.
Example off the top of my head: you have devices in the field which have not received an update since they were purchased 10 years ago.
A common crypto algorithm gets broken to a degree where it is phased out of use industry-wide to prevent leaking user data, MitM attacks, etc.
But once you flip the switch on that old crypto algorithm, your old devices can no longer be updated without a complex manual process (good luck getting the group of users who have never updated to do that,) and the devices will stop working with any secure online connectivity the users have been used to having (purchasing, downloading, etc.)
You have been trying to let users choose how they use their devices, but now they are upset that you broke their product, which they purchased in a working state. What do you do? This is a very small number of people and the years of accommodating them is getting very expensive, but you want to do right by them.
Offer the old crypto algorithms as a configuration option, or offer 2 versions of the firmware (standard vs. compatibility). Can't be prohibitively expensive, but isn't necessary when it's in the clear interest of customers not to use these old algorithms.
The issue is that you cannot forcibly update devices; not all users accept them, often because of the concerns which were being discussed in this thread.
But if you continue to 'support' the legacy algorithm to keep things working for those users, you also open them up to attack and they will surely complain if someone steals their information from "your service".
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.
A sane system would consider the knowledge and power differences between the average individual and the corporate lawyers who wrote the agreement, along with the one sided nature of the agreement, and void any consent as not having been possible to give. Likely the agreement would be treated as one signed by a child, where the more powerful party is the only one bound by it.
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.
I designed and built a wooden remote control[1] so I know a bit about why this is.
My iOS app asks the user for location permissions because without it the remote control app won't know when to attempt to connect when you walk in the door with your iPhone but your remote is sitting at home, waiting for you to hit it to turn on your lights or play music on your Sonos. If you hit the button and nothing happens, that's a horrible user experience!
I used to have location set to Always even though I don't store the location (and I'm explicit about that, even going so far as to open source the entire app ecosystem[2]) but then Apple pushed back and said that always having a location was against their ToS for remotes. I then switched to a geofence, which is still a location based permission but takes less battery life.
For Apple the tradeoff was not privacy but battery life. If I were to store your geofence information on my servers (which, ick) that would be OK as long as it was in teeny tiny text in my privacy policy. So while other remote control products are happy to take that information and sell it I decided to not double dip since you already pay once for the product. This is similar to my news reader which also has competitors that sell users' data. The tradeoff for me is that I earn a lot less than I theoretically could, but again, I don't double dip. Benefits of indie technology vs. venture-backed technology.
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?
Yikes! It's part of a hidden video that shouldn't play until you explicitly open it. What's your browser/OS? I tested on Chrome, Safari, and FF on mac as well as iOS.
I also just added a muted attribute to the `video` tag so it should no longer do that even if I messed up the JS for some browser somewhere. I encourage you to try it once again to confirm.
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.
I built a complementary product called the pedestal which does exactly this. You can either mount it on the wall (it has magnets to hold it in place) or place it on a nightstand (as I do) where it lives in the same place every time when I reach for it.
Wow... your answer makes my question sound like it was sponsored.
But you are awesome. I will be making an order.
I've been looking for a way to turn all the lights off in the house and shut off my kids iPad. I can do these things by going into apps on my phone, but when I'm wanting to do it I'm often REALLY exhausted and would kill for a 1 button solution.
I don't quite see how I can use this to shut off the iPad easily. But it definitely helps with the lights. And I think if I hook the house Wifi up to a smart switch I can basically turn the iPad off.
You can use NFC tags in a way such that a script is run when the device comes close to the tag. I gather you can thus do things like send an API call to turn off all the lights when you put your phone on your bedside table.
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.
> Google, in its wisdom, has tied "Location" into things like BLE Scanning and WiFi scanning. The excuse is that you can use these things as a proxy for location. That is, if I know you are near access point X your location is probably near Y.
It’s not an “excuse”, it’s a fact. If you allow an app to scan SSIDs you are allowing it to know your location. No amount of sarcasm on the part of OP is going to change that.
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.
This seems the classic 'ease of use' vs privacy. Google has done the right thing for privacy, because an app that can scan for ssid can determine location and report it if it has any outside connection. Good for google to equate the two, this was always a well known hole.
One suggestion- please update your blog, if this thread convinces you that Google did the right thing. Those posts hang around and impact product engineering.
What kind of api would you propose? The only one i can think of is one that says 'connect to x' instead of 'list all ssid', which still tells you about location but not a lot.
I occasionally think about g+ shutdown, and how Google engineered quite a bit for privacy, and removed things like games that leak location and quizzes, and forced people to create groups, which is the right thing but people liked the rich experience of facebook. Now that many are fleeibg from fb, they can't go to g+.
Sorry to thread-jack. Clearly i have a blog post pent up.
Google desperately wants location services enabled and will use any wedge possible to force it on. They even disable the center on my location button in the maps app even though the app knows very well where your current location is.
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.
SSID's pretty much ARE tied to geo, and those that aren't tied are easy to identify. The basic tech is known to both major players [1,2]. First you crowdsource as much of the data collection as you can: various apps can collect both SSID, BT, etc. sightings and report them with GPS. So you have a giant DB of locations vs network IDs. Then you tag any network ID which appears at differing locations: it's somehow mobile for whatever reason. The untagged ones are not mobile and probably dependable indications of location to within a few dozen meters. If they do move, they get tagged at your next sweep.
SSID's pretty much ARE tied to geo, and those that aren't tied are easy to identify.
I bring an AirMac (Apple Airport Express) with me to hotels when I travel. I guess this is why my Android phone gets so confused about where I am if it's in airplane mode with wifi enabled.
If inferring location works well enough in enough cases (for the purposes of the inferrer), the fact that it is not completely accurate or reliable is moot.
It's not SSIDs that are used for location but the BSSID of access points around you. You need only 2 of them to get the location of a user with Mozilla Location Service and there is other providers.
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.
Why not just forward the SSID of any device matching that companies MAC, as a default, then allow customers to let an app access top-10, top-100, all, selected, etc., using normal permission requests.
manufacturer ID's in the MAC don't always match the branding on the hardware - some companies (especially smaller companies) use third-party hardware that has a MAC belonging to the component maker.
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.
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.
I'm failing to understand how it would be malicious - without this permission setting apps would absolutely be able to pinpoint a user's location. I can sort of agree that more fine-grained permissions could be helpful, but asking for something like "Allow this app to access Wifi signals" doesn't convey the privacy risk to the user, and so putting it under location makes sense to me.
The coarse permissions and alarming text from the OS is a problem with both Android and iOS. Often, an app wants something fairly innocous, but has to ask for more, because it's grouped with other things in the same permission ask. Then, the OS message shifts all the blame with scary messages about what the app wants to do.
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.
The problem here is that they don't really want location, they just want a list of the surrounding Wifi networks, it just happens that such information is easily converted into a location, so Android requests that permission.
Android doesn't request the permission, the app does (via the app manifest) While that is the stated reason, that really isn't a legitimate reason for a remote control app to require location as it might not even work in all network scenarios. (i.e. the device in question may not be using a wifi network the phone can see/use)
Keep in mind that many things including trivial flashlight apps have a history of wanting location access. There's usually a pretext in the form of some questionable/marginal feature that's used as a justification for the permission. Often after some digging the real reason becomes apparent in the form of data collection or an included ad serving library.
For example, I have a 'smart' thermostat which has an app that requests location access. I deny it and it still works. There's at least one feature they use to justify requesting it but I suspect that if there weren't other uses (having nothing to do with benefiting me) for location data that the feature requiring location data probably wouldn't even exist.
I don't think they even want a list. Sounds like they'd be happy with a single SSID. Perhaps passed to it the way a browser file dialog works, where the OS sees the list, the app only sees what was selected.
"the app previously worked fine without the location information"
Maybe. Perhaps they fielded a lot of support requests related to getting Bluetooth and/or WiFi connectivity established before using the remote for the first time.
So it worked fine for this user, but didn't work well for less technical customers.
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.
Technically, for example, an app may not even want to see all available SSIDs. Maybe an app just wants one passed to it. Sort of like a browser file dialog works.
The pop up text from the OS says it wants the user's location. That's not what it wants or needs.
My point is that we shouldn't base permissions dialogs on what the app intends to do with the data, but what potential risk is introduced with the app having that data.
I could make an app that logs every phone call I make along with it's duration so it can recommend friends for me. I wouldn't expect that app's permissions dialog to read "Allow app to recommend friends to you".
Getting into the technical details doesn't work for average users, especially for cases like this where the risk isn't obvious - non-technical people will almost certainly not know that revealing local SSIDs reveals your location.
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.
I'm not an Android developer, but I think they've introduced SAF (Storage Access Framework) in 4.4 just for those cases; the app just asks the user for a specific file or directory, which is selected using the system's UI.
On iOS, applications are required to submit a reason why they require the permissions which is then displayed to the user along with the permission request. I believe it's also looked at in app review if it's a valid reason.
Would it have helped in this case? Permissions should convey the privacy risk to the user, not just the technical details of what's happening.
To a non-technical user, "Access nearby Wifi signals" (or something similar) sounds totally innocuous. Most people would approve that assuming that the app just wants to connect to the internet.
You could get more detailed and say "Access nearby Wifi signals, which could reveal your location", which conveys the privacy risk. But to the average user, "access nearby wifi signals" isn't adding anything - the only real privacy risk is that location is revealed, so it just makes sense to convey it as your location.
There's other cases where I think there's a better case for finer-grained permissions - some apps ask for phone call permission just so they can know whether you're a call or not - arguably something that should hardly require permission at all, but it's lumped in with one of the more scary sounding ones.
I agree that the technical details may be difficult to understand but that shouldn’t be a reason to make permissions so broad. I bet if it served ad selling then the permissions would be narrower.
But we've done research on this. Fine grained permissions don't work, even for people who claim to be knowledgeable. It sounds like a good idea until you look at the papers.
Web browsers let me upload a file without giving me permission as the "app writer" to trawl the filesystem.
In this case, the phone OS could provide a similar interface for an app to pass off selection of an SSID or Bluetooth device to the OS, without giving away other permissions.
Maybe. At a minimum we should get a log about how apps are using their permissions. I think I am reasonably tech savvy but when I really want an app I pretty much have to agree to all permissions. I don't know how not agreeing will impact app performance.
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.
All these stories give me a though choice. Should I auto update apps on android?
Clearly the answer is Yes because of security updates and bug fixes, and maybe the occasional interesting feature. Besides, once in a while an android developing HN poster will complain about all those pesky users that just don't update, and I know their pain very well.
Clearly the answer is No because I have no idea if the app will continue to work tomorrow after the next update? Will it start doing something sleazy, causing a worse security problem than just being hacked? Will it break because I happen to use an edge case which will be buggy.
I could manually update after a few days have passed, so I can make an informed choice. But finding detailed info for 1 app is challenging, and there are 40 or so on my phone. That's about a full time job, and my parents and neighbors have smart phones too.
I mean, I love my radio. You push power, you get music. Easy. I' pretty sure this will happen tomorrow, just like it did the last 20 years. It's not going to decide one day to start walking around and sell a map of the house to ikea or whatever. Now why can't I ask from my phone, being a personal organiser and extension of my mind, to be as trustworthy as this?
For now, my personal compromise is to auto update firefox, manually update the OS, and firewall the others and never ever update them when they work well enough. I trust firefox and HME(OS, zombie Nokia) not to fuck up too bad and fix things reasonably fast. I wish i could trust the ecosystems more and just auto update everything, but today? Not gonna happen.
I think Google is the culprit here. Not just for wifi scanning, but also for Bluetooth, Google demands location permissions.
In last 5 years or so, I have had a Garmin, a Fitbit and now a Garmin watch. I never used to have to enable location with my first Garmin tracker untill I upgraded Android os. After that point onward all my fitness trackers now ask to enable location in order to connect to my phone.
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.
> There's many online services where you can put in a wifi MAC and pretty much know within 100M where someone is.
Minor nitpick, it’s the BSSID that’s used to lookup the location. In some cases the BSSID is the same as the MAC address (usually with cheaper consumer gear), but it’s not the case with APs that are broadcasting (or have capability to broadcast) more than one SSID. As one example, think of APs that have “Home” and “Guest” separate networks.
Google is far from the only one to have that dataset. Apple has one, too, for example, as does Skyhook. And Mozilla ( https://location.services.mozilla.com/ ).
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?
I think for Bluetooth it doesn't work that way (you can connect some standard devices Android can use itself, e.g. a headset on OS level, but not arbitrary devices). For WLAN it's probably an ease of use thing, automatically finding and setting up the device instead of telling the user "please connect to the WLAN created by your new device and then press this Button".
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.
I recall ditching a relatively high-end router a year or two ago after a firmware update required me to accept that in order to use most of the advanced features supported by the router, essentially all of my household's web activity would be sent to a 3rd party data collection service. Thanks but no thanks.
> Google, in its wisdom, has tied "Location" into things like BLE Scanning and WiFi scanning. The excuse is that you can use these things as a proxy for location. That is, if I know you are near access point X your location is probably near Y.
There’s a reason Apple Maps says “enable WiFi to improve location accuracy”.
I’m incredibly annoyed that phones don’t report themselves with randomized Mac addresses. WiFi tracking is pervasive.
> 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.
I don't have a Fitbit, but I do carry an iPhone which includes a pedometer in the "Health" app. It's notion of stride length is interesting. I exported my daily step count and distance walked, and divided that later by the former to get the stride length.
Note that it breaks down into 5 distinct regions, with very sharp boundaries between them. Within each region the stride length has a fairly level average but a lot of variation around that. When you cross a region boundary, same patter but the average shifts down (sometimes dramatically, such as the shift in early 2016).
I have no explanation for any of these shifts except that last one and maybe the small one around Oct 2016. The last one, in the middle of 2018, corresponds to my changing phones from in iPhone 6 plus to an iPhone x. That small one before that matches up with when we switched to full time work at home
The earlier shifts were all on the iPhone 6 plus, and as far as I can tell do not correlate with iOS updates, or with anything in my life that might change my stride size such as seasonal changes (I probably take smaller strides in winter) or getting new shoes.
I asked about this on apple.stackexchange.com, but it got no answers or comments, a down vote, and was automatically deleted as a dead question.
Is there a virtualization app/service that can sit between the OS and an app that allows me to see or restrict what an application actually sees? For example I may allow it to see my public contacts rather than all contacts. Or, I may provide it with a location once rather than whenever they request it.
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.
When Slacker Radio decided it wanted my contact list, out it went. Sorry, but that information is NOT YOURS.
These days, if any important-to-me app is slated to be updated, I first run a backup in case ridiculous permission demands, feature removal, or other such f*ckery comes with the update.
Once again, this stuff won't stop until it becomes impossible for apps to tell whether private data is enabled or not. And the way to do that is with a data-spoofing layer controlled by the user below the API.
I would blame lot of this sort of thing on various frameworks / sdks / libraries and whatnot. Many of them demand all sorts of permissions like this.
If you dont want to write everything from scratch then u are stuck with this sort of crap.
Unfortunately I have a Sonos system which became effectively bricked unless I signed a new user agreement allowing the collection of data. There are no physical controls on Sonos so the system becomes useless without accepting.
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. Unhappy owners were offered a voucher (worth less than the value of a single controller - many users owned multiple in order to fully support multi-room - see https://en.community.sonos.com/controllers-software-228995/s...) for their next Sonos purchase rather than allow them to continue to use the hardware they had purchased and used happily for years.
All concerns, requests to be allowed to downgrade, etc. are met on the official forums with a passive-aggressive dismissal of users' concerns by staff backed up by a few cultist fanatics.
I've tried to avoid any further updates (and deny Sonos access to my listening habits) by having it run on a disconnected network but if anyone accidentally updates the app on the old ipad we use as a controller, your forced to update everything. I just wish I had the same system which I originally bought which I use exclusively to play my ripped CDs from a NAS.