Register for the iXsystems Community to get an ad-free experience and exclusive discounts in our eBay Store.

The case for disconnecting "Smart" stuff from the internet

Constantin

Vampire Pig
Joined
May 19, 2017
Messages
654
...A different paradigm is really needed for ongoing support and bugfixes of IoT devices. Paying up front doesn't seem to work too well...The reason Syno and QNAP can afford to keep coming out with updates for their devices appears to be primarily because they continue to crank out new hardware on what is effectively the same software platform...
Bingo. Smart companies come up with a platform that allows them to re-use code and leverage new work with minimal issue. To me, it was hilarious how Apple switched from one hardware platform to the next throughout it's Airport base station development cycle (486x, RISC, etc.) while Ubiquiti single-mindedly brought out a whole family of gateways, bridges, etc. that all seem to leverage the same processors / hardware architectures, allowing UBNT to support past product on the basis of current sales.

But vendors seem to be trying to monetize the information that they can gather. I wonder at what point someone is going to CFAA them. I mean, it's nice that they try to cloak themselves in EULA's, but if I give you my old already-activated TV, you aren't a party to that agreement, and there is effectively a malicious actor doing unauthorized things on your device.
That likely is a regulatory issue more than anything. Vizio only saw the light because the Obama administration sued them successfully. CA may become a model for the rest of the country re: implementing privacy protections, but I am not holding my breath.

Just as DOE explicitly has zero funding to enforce energy efficiency mandates for light bulbs (so lovers of high-wattage filament bulbs can still buy them) there are many ways for industry to subvert the writing, application, and enforcement of laws.
 

jgreco

Resident Grinch
Moderator
Joined
May 29, 2011
Messages
12,226
Bingo. Smart companies come up with a platform that allows them to re-use code and leverage new work with minimal issue. To me, it was hilarious how Apple switched from one hardware platform to the next throughout it's Airport base station development cycle (486x, RISC, etc.) while Ubiquiti single-mindedly brought out a whole family of gateways, bridges, etc. that all seem to leverage the same processors / hardware architectures, allowing UBNT to support past product on the basis of current sales.
This only gets you so far, though. We need a better mechanism than what is effectively lucking out.

I suppose most people will not recall the heady days of the early public Internet too well, but there was this thing called WebTV where you had a set-top box with a dial-up modem. One of my clients contracted with an Asian OEM to make their own version of this, "Voyager.net TV", which was an amazing IoT-astrophe because no one had considered that the web was evolving quickly. This thing had no real gameplan for firmware updates and no onboard resources to allow for the possibility anyways.

So this has been annoying me quite a bit in recent days. Back in the late 2000's I was buying Linksys WRT54GS and crossflashing them to OpenWRT or DD-WRT, and I handed out a bunch of these back in the day. I am literally sitting next to one right now, because I recently had a need to set up a new SSID for a low bandwidth IoT purpose. Turns out that these really dead-ended back in 2011-2012 due to some Linux 2.6 driver issues, and firmware bloat, which was just really annoying to discover. So really, they only have a 3 or 4 year lifespan? JFC.

By way of comparison, I recently upgraded the UBNT controller here and it scared the s*** outta me because I didn't really bother to read any release notes. Several old UAP-LR's suddenly went all scary-malfunction-warning when the controller came up ("holy crap do I revert to the snapshot?!") and then eventually settled down into a merely harsh "This needs to be upgraded" yellow status. Now I'm pretty sure some of those date from 2012-2013 era. But the controller just quietly went out and updated them when prompted. I'm guessing it'll be awhile longer before they go unsupported. Part of it's probably just that they provisioned these pretty well - I think they have 64MB of *RAM* in them!

Despite some gripings from the GPL community about UBNT's noncompliance with the terms of the GPL, it's easy to see why these are a better choice than the Cisco/Linksys product...

That likely is a regulatory issue more than anything. Vizio only saw the light because the Obama administration sued them successfully. CA may become a model for the rest of the country re: implementing privacy protections, but I am not holding my breath.

Just as DOE explicitly has zero funding to enforce energy efficiency mandates for light bulbs (so lovers of high-wattage filament bulbs can still buy them) there are many ways for industry to subvert the writing, application, and enforcement of laws.
Well, as a pragmatic libertarian, I'm not super-fond of being told what to do, but there are times when society needs to incentivize better behaviour where it affects us all. Light bulb technology is a perfect example of perverse incentives. Conventional filament bulbs are so damn cheap to acquire, when a person of limited financial means goes to the store and sees 2/$1 filament bulbs or $10 LED bulbs, there is little thought given to the less-obvious variables -- a filament bulb is usually rated for 1000-1500 hours whereas an LED is typically at least 25000. So that "50c" lightbulb needs to be replaced 16x more often and you need to spend $8 in filament bulbs to get 25000 hours. Not to mention the power savings! And the power savings goes directly to pollution reduction as most US power is still generated from coal/natgas/etc.
 

Constantin

Vampire Pig
Joined
May 19, 2017
Messages
654
The beauty of the DOE efficiency program is that there has to be a projected positive payback to the consumer, usually less than 5 years. It's a field of study that has fascinated me for the better part of 20 years. The program was brought into being over 40 years ago to address market failures, such as incomplete information (i.e. fee customers running a cost-benefit analysis), split-incentives (i.e. owner vs. tenant), and like issues.

Thanks to incentives and regulations, dimmable 100W LED light bulb prices have dropped down to less than a pop delivered and an equivalent-wattage filament light bulb may in fact cost you more than the LED version. But I also respect that there are folk out there who really prefer the look, warmth, and/or spectrum put out by a 100W light bulb... and on occasion I have a bit of evil fun replacing said filament bulbs with quality LED or CFL versions to see if these zealots can tell the difference (so far, never, even for exposed bulbs). :)

I don't happen to like swapping light bulbs much so I've been using filament alternatives for 2 decades now.

As an aside, had my first DNS failure today as both DNS servers were taken down by a common power supply failure. Ordered two replacements from Anker, to power each individually from now on. The original USB PS was from Amazon basics, likely a case of "you get what you paid for". At least Amazon is taking it back, no further questions asked.
 
Last edited:

NASbox

FreeNAS Experienced
Joined
May 8, 2012
Messages
480
But vendors seem to be trying to monetize the information that they can gather. I wonder at what point someone is going to CFAA them. I mean, it's nice that they try to cloak themselves in EULA's, but if I give you my old already-activated TV, you aren't a party to that agreement, and there is effectively a malicious actor doing unauthorized things on your device.
I think their needs to be legislation that provides for a reasonable level of functionality without privacy invasion. We have a smart TV which is just a glorified monitor. There is no availability to turn WiFi on/off except not to activate it, so I didn't. I use an external media player which is firewalled and can't call home. I think that consumers need to have a statutory right to a large minimum monitary amount for privacy invasion with no necessity of proof. Any company caught selling data is liable for a minimum of say $100,000/Consumer/Act and criminal damages to excutives in some cases.

There are reasons to put MCUs into fridges. For example, one of the most effective active ways to improve fridge efficiency is to fit a variable-speed compressor. If you want, I can go into the details, but there are instances in many appliance types where MCUs make a difference re: efficiency. Note however, that a MCU driving a IGBT system to modulate refrigerant flow to optimize cooling efficiency is not a full-fledged computer. It's an MCU that uses a few thermal inputs to optimize system efficiency.

MCU's can also be used to detect and react to test conditions (brilliant VW trick to detect test stands: no steering wheel input) That said, MCUs can have a very positive impact in dishwashers, clothes washers, HVAC, many white goods, etc. The case for 'connected' appliances is a narrower one. Consider the added electrical load re: always being connected vs. the marginal benefit of always being connected. Does my microwave really need Alexa integration?

To me, the fundamental issue re: connected smart appliances still revolves around consumer benefit. Few US residential customers have variable electrical rates, peak demand charges, etc. the way that commercial / industrial ones typically do. Until there is a $$$ reason, I don't see a tangible reason for consumers to jump wholesale into DR and like programs that would benefit from connected appliances (esp. HVAC, electric water heaters, and to a lesser extent, electric clothes dryers and dishwashers).

That 2009 ARRA funding rolling out hundreds of millions of smart meters is transforming utilities - they have far more data today than they used to and it likely is forcing a massive rethink re: what a utility is (electric or gas). I hope they're taking good care of that data since it's pretty revealing...
Nothing wrong with an MCU for efficiency, but no need to connect it to anything.... The "Smart Fridges" I'm talking about are consumer toys that have android tablets built into the door... likely for inventory management (and advertising/spying)... no thanks.

Does my microwave really need Alexa integration?
IMHO a stupid consumer toy.

Since the vast majority of the population are non-digirati, they can't do "smart homes" in a privacy enhancing/secure way. If your controller is in the home and access is either local or through a strong VPN then the security risks are greatly maimiized. If it works, it works and should continue to work util you have a component (hardware) failure.

I have a 10 year old medial player which is a security nightmare, but it's in a nice tight cage that doesn't see the light of day. Just my NAS and that's it! I'll use it until I find something that makes it worth upgrading, or it dies--whichever comes first.

I would likely take the same approach to smart home stufff as well. The only vulnerability is someone sitting outside your house (or remotely with a raspberry pi / wifi pinapple etc) and hacking in. Not likely unless you are a high value target, and likely minimal impact if the network is properly segmented.
 

NASbox

FreeNAS Experienced
Joined
May 8, 2012
Messages
480
As someone who tries to keep inventory of his food, I'd welcome this but only if I could control exactly where the data went; eg: "it doesn't leave my house."
In the lifespan of the fridge you will likely need 4-5 tablets. Why pay a lot extra for a fridge with a an overpriced tablet built in?

Buy a cheap table with some appropriate open source software that doesn't spy and put it next to the fride and done! When the tablet breaks or if it becomes too out of date, get another one.


The cheap tablet/open source software can also be controlled so it doesn't share your data... the fridge.... not so sure.

Just my $0.02.
 

Tigersharke

BOfH in User's clothing
Administrator
Moderator
Joined
May 18, 2016
Messages
215
As someone who tries to keep inventory of his food, I'd welcome this but only if I could control exactly where the data went; eg: "it doesn't leave my house."
I agree, but I suspect that such an expectation is unlikely to ever be an option, nor would attempting to isolate the fridge be an entirely simple task. The idea of the convenience of many/most smart devices is cool but all the other hidden nefarious and sneaky things that ride along with those time savers is not (for the savvy/techie or security-minded) worth it. It is such a shame that reality must be this way, that we couldn't just live in the futuristic sci fi portrayed by old time movies or tv.
 

HolyK

Ninja Turtle
Moderator
Joined
May 26, 2011
Messages
454
Hah, these posts remembers me the story about "Why my brand new washing machine needs Wifi connection - maybe for "monitoring"?" followed by "Honey did you ordered washing gel from Amazon?" ... so soon we will see a 0day explots like "miele.laundry.fuxker.0day" or "deep.freeze.your.neighborhoods.food.0day".

In the lifespan of the fridge you will likely need 4-5 tablets. Why pay a lot extra for a fridge with a an overpriced tablet built in?
Buy a cheap table with some appropriate open source software that doesn't spy and put it next to the fride and done! When the tablet breaks or if it becomes too out of date, get another one.
This is exactly what i am thinking about for last 6 months. Usually my wife sends me grocery list few times in a week and i do shopping on my way back from work. The idea is just to glue/fix some cheap tablet on the fridge doors (perma-hooked on power source) and ideally have it as "always on" with clock/weather by default. When tapping there should be some easy app with list of most-common items just with + and - signs to quickly add/remove these to/from list and ofc a "add new" for custom item. So she can easily "update" the list anytime something is running out and i can just check the list from my cell while shopping (and remove the items from list once i buy them).
If it breaks i would just replace the tablet, not the whole fridge!
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
6,078
Hey there, yeah the use of pfSense has crossed my mind but I’m pretty happy with my current setup. We likely subscribe to the same lists, my pi holes have a 1.6mm site ban list. Par for the course.

As for Sonos, at least they were open about the bricking issue for those of us who read the tech news. Sonos claims that it contacted every CR100 owner before the 8.4+ firmware update to tell them how dangerous the battery in the CR100 is and that therefore it would be a really good idea to get rid of it. Some users then asked the company in the forums to clarify, i.e. is this a potential product recall issue, which Sonos denied. Sonos then trotted out the excuse that the older zone players couldn't handle the awesome new features that Sonos would bring to market if they still supported the CR100.

But mostly, the elimination of support for the CR100 seemed to be aimed at clearing the decks re: older hardware that had been developed by the first generation of engineering teams. That product was NAS-based and the market has been fully tapped out for a while streaming is still growing. So, those teams allegedly got let go and the CR100 sported a 2014 copyright notice even in its 2018 boot screen.

Similarly, Sonos never upgraded the SMB stack beyond SMB1 NTLM v1 (even though the SMB team at MS offered to help them!) and asked users who didn't want crummy network security to use other workarounds. As of firmware 8.6 they pull the data via HTTP, I guess.

However, many folk like the CR100 (and to a lesser extent the CR200) controllers because they are simple to use, waterproof, rugged, and offer excellent battery life. At $350 a pop they were not cheap and you can imagine how happy people were being told that their functional hardware was going to be bricked by a coming software update. Here is how Sonos' firmware works:
  • If a new firmware is available, the controllers, apps, etc. will nag you to update.
  • The iOS and like Apps are continually updated and zone players with older firmwares are blocked from being used. The $3 SonoPhone is the best alternative to the Sonos App because it supports older and newer hardware.
  • Anyone with access to your sonos' can trigger the update. But, the the controller screen offers no warning that said warning will brick the controller permanently.
  • You can only update to the latest firmware - no other firmware choices are allowed.
  • When you set up a Sonos for the first time, add components, recover it from a deep reset, etc. a connection to the mothership is required, followed by updating to the latest firmware.
In other words, you may physically own a Sonos device but you never control it, as the company has illustrated so nicely. To deal with Sonos, I first built DNS blackholes into my router for update.sonos.com and like domains. Then I added blocks to prevent outside connections to my Sonos equipment. Finally I added the pi hole blacklists. Sooner or later, my Sonos' will die but then I'll switch to Bluesound. At least they allow me to download, backup, and install firmwares of my choice.
SMB2.1 has been available in linux kernel CIFS client since 3.7. NTLMv2 has been default since 3.8. If they're concerned about increasing size of resulting binaries, they can also use the minimal SMB2/3 client https://github.com/sahlberg/libsmb2

Ronnie Sahlberg managed to create a userspace client that does SMB2/3, encryption, and NTLM2 (and kerberos!) auth, AND trim it down to something like 128KB.
 

jgreco

Resident Grinch
Moderator
Joined
May 29, 2011
Messages
12,226
As someone who tries to keep inventory of his food, I'd welcome this but only if I could control exactly where the data went; eg: "it doesn't leave my house."
Well, this gets back to a point I think I made earlier in this thread. In the rush to bring the Internet to the masses, those of us who create and implement the technology failed to make a lot of it simple to deploy. I came to this realization many years ago when looking at the evolution of the e-mail ecosystem. Originally your ISP handled your e-mail because dial-up Internet meant that there wasn't a way to reach the end-user directly 24/7 (no static IP, not always-on). This created a bit of a monster because ISP's then started acting as mail service providers, and many of them were terrible at it, which in turn created strong demand for Hotmail and other "free" mail service providers. Ditto web servers and other similar server-y stuff.

The Internet might have evolved somewhat differently, and possibly somewhat better, if software developers had been encouraged to enable end users to host their own services. Up until maybe four or five years ago, I was actually pretty impressed with what Apple had done with OSX Server, as it came somewhat close to what I felt should be possible for a home user to do -- if it had been done 20 years earlier. Not that I'm faulting Apple here.

Making it worse is IPv4, where NAT has made it relatively difficult for end users to set up services on their local network. That issue is no stranger to many of the users here.

How many things that are hosted in the "cloud" (specifically meaning some big company's cloud) could just as well be hosted locally if only the code (and maybe an appliance) were made available? For purposes of this, "local" really means any system under your control, even if that happens to be an AWS cloud instance you run.

Ubiquiti has arguably done a good job with its Unifi management software, which you can run locally on your computer, locally on their appliance, or in the cloud on their service.

OwnCloud/NextCloud have done an okay job at creating a Dropbox replacement.

If I had a refrigerator with some sensors in it, I dunno, RFID and camera maybe, whatever, to help identify what's in there, that could be useful. I don't care if the manufacturer provides a cloud service for the average user, but the part we're missing now is that there's usually no option to self-host. This is a disservice to the end user. What happens to your Nest thermostat when Google decides to EOL the server side? A thermostat should be a several decade investment. And firmware updates for the devices? This is still a problem.

We need better support for home automation that doesn't rely on external connectivity.
 

jgreco

Resident Grinch
Moderator
Joined
May 29, 2011
Messages
12,226
Ronnie Sahlberg managed to create a userspace client that does SMB2/3, encryption, and NTLM2 (and kerberos!) auth, AND trim it down to something like 128KB.
Without shared libraries? That'd be impressive.
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
6,078
Without shared libraries? That'd be impressive.
What I thought was impressive was when he put it on an ESP32 microcontroller and used it to have a TRS-80 connect to an SMB share over SMB2 (to download games). Or another way to think about it is that there is a TRS-80 out there with a more capable SMB client than what Sonos managed to put in their speakers. :D https://github.com/apuder/TRS-IO
 

jgreco

Resident Grinch
Moderator
Joined
May 29, 2011
Messages
12,226
What I thought was impressive was when he put it on an ESP32 microcontroller and used it to have a TRS-80 connect to an SMB share over SMB2 (to download games). Or another way to think about it is that there is a TRS-80 out there with a more capable SMB client than what Sonos managed to put in their speakers. :D https://github.com/apuder/TRS-IO
Nicely done. Unfortunately the flip side of the coin is NOT impressive. The sad fact is that companies like Sonos are busy stitching together whatever bits of arseware they can find that already exists to make their products. Not unique to companies, either. One of my gripes with FreeBSD especially in recent years is that a lot of the ports tree is a bit trash. Try building Free Range Routing (frr7 as an example) on a fresh 12.1R box and look at all the garbage that gets pulled in and built. Not that Linux is any better.

You may or may not be aware that over here we run FreeBSD servers built on a customized FreeBSD build system that builds a consistent set of ports into the base and then does full provisioning. The end result is a platform which is designed to run "apps" which are basically just jails or chroot environments that run on top of the base. This used to be done on physical hardware but these days is mostly VM's. The ports added include various sysadmin tools and stuff for maintenance and problem resolution (iozone, iperf, bonnie, kermit, tcpblast, dmidecode, etc), code tools (git, subversion, gm4, bison, autotools, etc), general tools (curl, rsync, less, bash, etc) and networking (quagga/frr, nss-pam-ldap, etc). The goal is to build a general purpose system that doesn't require lots of extra effort to customize and set up on a per-application basis -- and the base OS image that is generated is reproducible. And to move forward from 9.3R to 10.3R to 11.3R to 12.1R is just a matter of sending the OS disk back to the build system. I don't have the engineering resources here to create a fully custom fork of FreeBSD like TrueOS.

Now for various reasons the system builds on a bunch of versions of FreeBSD. The specific interesting point is that the list of desired ports doesn't change, but the size of the ports indirectly included has exploded. For FreeBSD 9.3R, the system builds 80 ports. For FreeBSD 12.1R, it builds 174 ports. Same functionality. At the same time, the size of the OS disk for 9.3R is 18GB while for 12.1R it's exploded to 30GB. Again, same functionality.

I have to wonder if there will be a point at which software development will cease this expansive integration of every possible bell and whistle, and instead focus on providing solid, secure functionality... bet we'll get smaller code as a side effect.
 

Tigersharke

BOfH in User's clothing
Administrator
Moderator
Joined
May 18, 2016
Messages
215
I cannot fault the ports maintainers too much, it is still largely volunteer and may always be. I believe some of the differences between versions of FreeBSD and their sync'd ports, is where the code originates which is primarily the Linux community. Due to multiple collections of software, each distro wishing to focus on any of various things and not always compatible with some other distro, you have a whole lot of configurable options. It is nice to have these options and many/most of them are exposed to the ncurses port configurator. Unfortunately, in order to permit the maximum amount of compatibility and offer the most used capabilities, often many more of the available options are set to default (enabled) than you might in every case need.

Look at ffmpeg for example, I have not conclusively determined whether or how many of those options actually directly affect the result or if they simply tick a dependency which causes another thing to be built that is used alongside of it. My ffmpeg config has very few (compared to the number presented) options ticked, as far as I am aware, my functionality does not suffer. So, take a volunteer service and more software or options than any one person can handle, and the whole thing is likely to change over time-- more new software gets designed outside of our purview in successive years, those ports get added to the tree, older ones slowly deprecated and removed. The trend is always to convenience in all things, security is number two if we're very lucky, and if a bell or whistle of piece of tinsel can be attached or hung onto any mass of code, it will. We may never return to the old UNIX method of each small tool does one thing well (with the ability to combine them for more complex tasks). Back to ffmpeg, if it were the one thing you set options and install, the overview of options you tick would be the end of that step, everything you need would be built/installed and you're done. This would be grand, easy, nice, but this is not how things are, any other substantial bit of software has a similar large set of options which may overlap and may even duplicate dependencies. It would even be nice if there were one master configurator, but if you must pick each option over the hundreds of ports and options that you'd need to tick (try config-recursive on an expansive port) it will take a long time and many of the options are not explained or identified as well as they could be. A master configurator which asks more general questions like what you wish to accomplish, the end functionality you need, and then it chooses the best options of those hundreds, THAT would be awesome and amazing, that may be the cure.

I have tried, to control the options for ports I build, to keep things consistent and avoid things that I do not need, but it is a LOT of work and effort. There is simply too much code, too many ports, too many options. Maybe if I were to somehow get it all into a database or spreadsheet or something, I could have a better chance to fight through it all. Mostly, I just want things to work and not have to work to get them all to function, that without too much testing. I have enought trouble when my Xwindows or FVWM fail to startup because some random dependency didn't get installed when something was rebuilt. I dream of the master configurator described previously, which works on functional result choices instead of port names and vague option descriptions. That was what I was working toward but have shelved, it is too much work :/
 

HoneyBadger

Mushroom! Mushroom!
Joined
Feb 6, 2014
Messages
2,226
In the lifespan of the fridge you will likely need 4-5 tablets. Why pay a lot extra for a fridge with a an overpriced tablet built in?

Buy a cheap table with some appropriate open source software that doesn't spy and put it next to the fride and done! When the tablet breaks or if it becomes too out of date, get another one.


The cheap tablet/open source software can also be controlled so it doesn't share your data... the fridge.... not so sure.

Just my $0.02.
I'm actually trying to get some surplus handheld barcode scanners, and leveraging an open-source restaurant POS/inventory system. For now it's still pen-and-paper, because the WAF is pretty low on having to "go through the checkout again when I get home" :p
 

NASbox

FreeNAS Experienced
Joined
May 8, 2012
Messages
480
If I had a refrigerator with some sensors in it, I dunno, RFID and camera maybe, whatever, to help identify what's in there, that could be useful. I don't care if the manufacturer provides a cloud service for the average user, but the part we're missing now is that there's usually no option to self-host. This is a disservice to the end user. What happens to your Nest thermostat when Google decides to EOL the server side? A thermostat should be a several decade investment. And firmware updates for the devices? This is still a problem.

We need better support for home automation that doesn't rely on external connectivity.
That is my main complaint--an option is just fine, manditory is no go. I think it is time to start lobbying for consumer protection laws....
 

Constantin

Vampire Pig
Joined
May 19, 2017
Messages
654
...there is a TRS-80 out there with a more capable SMB client than what Sonos managed to put in their speakers. :D
That’s the least of all worries. In October, Sonos started a voluntary “recycling” program where they give you a discount for new hardware in return for permanently bricking your current hardware. See this Verge article for a summary. Unlike the CR100 debacle, the app walks the user through multiple screens to confirm they really want to brick their device in return for a discount on newer zone players or speakers. Allegedly, tech support even allows stuff to get unbricked if it happens accidentally.

I’d wager that the affected platforms are reaching their physical limits re code bloat and cannot offer Alexa, Siri, Echo, Airplay 2, or whatever integration. My interpretation is the company trying to make its established customer base more attractive to rent or buy. When one of the big three (Apple, Amazon, Google) needs more market share, Sonos will be there with a large base of voice-capable hardware, ready to offer an exclusive (either on a rent basis or by selling the company altogether).

However, this approach doesn’t change the fact that there are lots of Sonos customers out there that have no need for “upgrading”. They just want to enjoy their infrastructure as is. But how do you accommodate the "one firmware to rule them all business model" with an aging hardware fleet? Based on past experience, I predict more unwanted bricking in the future. This high-stakes gamble may result in a few at Sonos cashing out handsomely but it may signal the end of the company.

So, if you like your Sonos as-is, I suggest sandboxing it.
 
Last edited:

seb101

Newbie
Joined
Jun 29, 2019
Messages
70
Just thoughts I'd add my 2 cents here. I know a developer working for a major (i.e. the biggest) global cable TV provider. His job was to integrate bluetooth snooping into the cable boxes (essentially a passive BT transceiver set to log the device ID of any Bluetooth devices in the vacinity). There is no need for the device to authorise or pair to do this.

They merge this with data from other sources (like when you install their 'app' on your phone, and I'm sure much more clandestine ways) to identify the Bluetooth hardware address of each person in the household's mobile phone. Then, based on the signal strength of each device, they use this information to work out, with a pretty high degree of accuracy, who exactly in the household is watching the TV at any point in time. Relying on the fact most people keep their phone on them at all times, essentially acting like a personal locator beacon.

Currently they just use this data for audience/viewing statistics, but they actively plan to (maybe already do for all I know) use this to do targeted TV commericals based on the exact audience in the room. The advertisers dream.

Of course, everyone permitted and allowed this when they accepted the Ts&Cs of their cable subscription.

It would not surprise me at all, if 'Smart Home' devices were also secretly cataloging all the devices on your LAN. You can work out a fair deal of information from a MAC address (i.e. manufacturer, even product line) so you could get a fairly good profile of a home's 'tech inventory' just by being on their WiFi and snooping ARP. It is then very easy to do targeted advertising from this - i.e. if household X already has Alexa, target them with Alexa accessory adverts etc.

However, it's probably deeper than this, with a complete tech inventory of a household, it's possible to do consumer profiling. It is no stretch of the imagination that someone somewhere has written such a ham-fisted 'algorithm' along the lines of: if number of apple devices is greater than 5, mark the household as affluent.
 
Last edited:

NASbox

FreeNAS Experienced
Joined
May 8, 2012
Messages
480
So is it practical to build a simple "bluetooth sniffer" that can detect this type of BS.
 

Constantin

Vampire Pig
Joined
May 19, 2017
Messages
654
Just thoughts I'd add my 2 cents here. I know a developer working for a major (i.e. the biggest) global cable TV provider. His job was to integrate bluetooth snooping into the cable boxes (essentially a passive BT transceiver set to log the device ID of any Bluetooth devices in the vicinity). There is no need for the device to authorise or pair to do this.
Something similar was also reported on Slashdot as part of the Smart TV reporting.

The cable company has your address, viewing habits, etc. so it's pretty easy to use a local zillow / assessor index to figure out who is likely how rich. Then marry the bluetooth data with said info and sell it to third parties that bundle it for use by physical stores to more easily identify potentially profitable customers as they walk in or as sales targets later on (i.e. targeted ads by Comcast on your TV, email, or physical).

Even if people don't send each other emails, log onto various web sites, etc., set Top owners will know who spends how much time with whom to an even greater extent than is currently possible via the cell phone system. This is a location and association data stream that ISPs can then sell the same way that the cell phone companies have.

So is it practical to build a simple "bluetooth sniffer" that can detect this type of BS.
Unlikely, if the thing is designed to be a passive sniffer. You won't know its there and there is no way to prevent exfiltration via the set-top box. Short of opening the box and looking for the relevant hardware (difficult!) there will be no way to know other than by industry leaks. The only effective countermeasure I can think of is wrapping the set-top box in wire-cloth featuring a mesh size similar to that of a door to a microwave oven. Then GND the wire to the outer coax terminal and the box will be in a faraday cage. The cage shouldn't inhibit the IR remote much but it might raise a few eyebrows from visiting friends! :)

Unfortunately, I doubt that even if this were to get wider coverage that enough US customers would care to overturn the entrenched interests in DC.

Also, some hardware suppliers like Apple allegedly randomize BT and WIFI MACs until the device is paired to prevent this sort of snooping. Hence the rise of in-store WiFi networks.
 
Last edited:
Top