Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

More awful IoT stuff

mjg59.dreamwidth.org

Post reply on HN
Print view View original

191–200 of 245 posts

Re: More awful IoT stuff

#191

Post by CaptSpify »

logicallee wrote: post #153
CaptSpify wrote: post #66

I just blogged about this yesterday. In short: > The line in the sand for me is: network vs cloud-based systems. I want things to be network connected, but I want it for my own network only. I want to be able to control my coffee pot, but only from home. If I choose to expose this over the internet, great! It's up to me to make sure it's secure. I don't want anyone making that decision for me. I also want it to be up…

This is a genuine question, and I think I've come to the opposite conclusion as you. You write: >I want things to be network connected, but I want it for my own network only. I want to be able to control my coffee pot, but only from home. and >I also want it to be upgradeable, So let's be super-super clear. You do want it to be upgradeable. That means you want it to be able to be better in the future than the day you…

I think your severely mis-interpreting what I'm saying.

> Meanwhile, are you sure that you 100% definitely want non-technical users who plug in the device and never want to take any further action, to ever enjoy the benefits of any automatic upgrade they don't need to know or touch or think about? You want to monopolize upgrades for hackers, and deny them to 99.999% of world's population, right?

I never said nobody else can upgrade, or that having cloud services (for things like upgrades) available are a bad thing. What I want is a device that doesn't assume it will be connected to the cloud, and doesn't lose any usability if it's not connected to the cloud. I think the best option would be a product that has both: Cloud services, and standalone services, and "home-cloud" services that I can install on my own home server.

> The default settings should have an option "Stay on latest version. Upgrades will be applied automatically." You as a hacker can turn it off to instead get the behavior you suggest.

I absolutely agree. By default I think auto-upgrades are a good thing. But I want to have the final control to turn those off if I want.

I actually really like your idea for how upgrades should be applied. I don't think it's the opposite of my desires though.

Re: More awful IoT stuff

#192

Post by saulr »

alexmingoia wrote: post #179

The principal reason devices need to be connected is so that business can hold your devices ransom and charge you money to use them. Turn on lights with a phone? No need for Internet. Open doors with a fingerprint? No need for Internet. An auto-adjusting energy-saving thermostat? No need for Internet. A fridge that knows the milk is low? No need for Internet. Charge people money to use their toaster? You need the Int…

Completely agree except the light argument -- having my lights cloud connected allows me to control them remotely. The main use for this is for time or sunrise/sunset scheduling. However you could quite easily architecture this without cloud connectivity, it seems easiest to keep the bulb dumb and keep the 'smarts' elsewhere (whether that's on a phone locally or a server in the cloud).

Re: More awful IoT stuff

#193

Post by DougN7 »

nbadg wrote: post #115
CaptSpify wrote: post #66

I just blogged about this yesterday. In short: > The line in the sand for me is: network vs cloud-based systems. I want things to be network connected, but I want it for my own network only. I want to be able to control my coffee pot, but only from home. If I choose to expose this over the internet, great! It's up to me to make sure it's secure. I don't want anyone making that decision for me. I also want it to be up…

Would you feel comfortable with end-to-end encryption via an open, documented, free protocol? This is literally my raison d'être as a company, so I'd be interested to hear your comfort level. What I've got is a platform that 1.) makes it substantially easier for IoT developers to get their devices to market and 2.} enforces end-to-end encryption and affirmative consensual sharing. It works by running as a background…

I've been debating about hooking my garage door opener up using a built-in feature so I could open the door from my iPhone. I don't trust that whatever central site I'll be connected to is safe. If I _knew_ the vendor had implemented your protocol/software well, and I _knew_ your software was safe, yeah, I'd use it. But I don't know those two things, so no way am I hooking my home's door up to the Internet...

Re: More awful IoT stuff

#194

Post by api »

CaptSpify wrote: post #184
api wrote: post #174

Earlier quoted context omitted.

We're working toward some IoT developer products designed to allow global p2p connectivity for IoT devices over networks the user can control: https://www.zerotier.com/ ZeroTier already runs fine on embedded Linux, which is a large subset of IoT, and we've researched a lightweight port to FreeRTOS.

Interesting. So this would be something you set up on an existing device?

You could install it on a device and then remotely access it. The software handles a lot of complexity for you. We're working with several vendors about incorporating it as a network layer and then using our (to be released soon) SDK to allow iOS/Android apps to directly access things.

Re: More awful IoT stuff

#195

Post by api »

ianlevesque wrote: post #188
api wrote: post #175

Earlier quoted context omitted.

We've been using the term "endpoint hostile" to describe how networks are typically deployed, especially with IPv4. "Endpoint hostile" networks are designed with a single use case in mind: accessing remote servers, usually via HTTP/HTTPS. Other use cases are prohibited or broken. Here are some of the characteristics that would label a network as endpoint hostile: - "Device isolation," which prohibits local LAN device…

This is exactly why the use of a remote server exists in so many IoT devices. Widely deployed home APs, even in USA, come with device isolation on by default or even not disableable.

Is there actually a good reason for this "feature" outside of airport and coffee shop WiFi?

Basically you have a 2000 mile data path to your light bulb because routers suck and networking engineers are cargo cult morons.

Re: More awful IoT stuff

#196

Post by CaptSpify »

api wrote: post #195
ianlevesque wrote: post #188

Earlier quoted context omitted.

This is exactly why the use of a remote server exists in so many IoT devices. Widely deployed home APs, even in USA, come with device isolation on by default or even not disableable.

Is there actually a good reason for this "feature" outside of airport and coffee shop WiFi? Basically you have a 2000 mile data path to your light bulb because routers suck and networking engineers are cargo cult morons.

IMO: this is actually a good default setting. Home-router designers should assume that things are hostile by default. Of course, it should be dead-simple to turn this off as well.

Re: More awful IoT stuff

#197

Post by wcummings »

DougN7 wrote: post #193
nbadg wrote: post #115

Earlier quoted context omitted.

Would you feel comfortable with end-to-end encryption via an open, documented, free protocol? This is literally my raison d'être as a company, so I'd be interested to hear your comfort level. What I've got is a platform that 1.) makes it substantially easier for IoT developers to get their devices to market and 2.} enforces end-to-end encryption and affirmative consensual sharing. It works by running as a background…

I've been debating about hooking my garage door opener up using a built-in feature so I could open the door from my iPhone. I don't trust that whatever central site I'll be connected to is safe. If I _knew_ the vendor had implemented your protocol/software well, and I _knew_ your software was safe, yeah, I'd use it. But I don't know those two things, so no way am I hooking my home's door up to the Internet...

Still probably more secure than most remote garage door openers tbh

Re: More awful IoT stuff

#198

Post by api »

CaptSpify wrote: post #196
api wrote: post #195

Earlier quoted context omitted.

Is there actually a good reason for this "feature" outside of airport and coffee shop WiFi? Basically you have a 2000 mile data path to your light bulb because routers suck and networking engineers are cargo cult morons.

IMO: this is actually a good default setting. Home-router designers should assume that things are hostile by default. Of course, it should be dead-simple to turn this off as well.

I pretty vehemently disagree. We should be very reluctant to systematically break good things to protect badly written junk.

Let badly written junk burn. Then people will learn it's junk and stop using it or the developers and vendors will be forced to fix it.

Re: More awful IoT stuff

#199

Post by logicallee »

CaptSpify wrote: post #191
logicallee wrote: post #153

Earlier quoted context omitted.

This is a genuine question, and I think I've come to the opposite conclusion as you. You write: >I want things to be network connected, but I want it for my own network only. I want to be able to control my coffee pot, but only from home. and >I also want it to be upgradeable, So let's be super-super clear. You do want it to be upgradeable. That means you want it to be able to be better in the future than the day you…

I think your severely mis-interpreting what I'm saying. > Meanwhile, are you sure that you 100% definitely want non-technical users who plug in the device and never want to take any further action, to ever enjoy the benefits of any automatic upgrade they don't need to know or touch or think about? You want to monopolize upgrades for hackers, and deny them to 99.999% of world's population, right? I never said nobody e…

Thanks for this feedback!! :)

Re: More awful IoT stuff

#200

Post by tzs »

pikewood wrote: post #183
tzs wrote: post #139

Earlier quoted context omitted.

If you are OK with building it yourself, you could do this with an ESP8266, a USB to serial cable, a solid state relay, a power brick, and some miscellaneous things like a power cord and a socket (and ideally some case to put all this in for safety). The ESP8266 is a micro controller with built in WiFi and network stack and a serial interface, and several digital I/O pins you can use to interface to other things. Var…

Anyone have recommendations for a relay that could handle 20A but would work with the ESP8266's 3.3V?

I've not used this, but it looks like it would fit the bill: https://www.sparkfun.com/products/13015

The datasheet says the control current is 7.5 mA at 12 V. It doesn't say what it would be at 3.3 V, so that would be the one thing I'd worry about. ESP8266 GPIO pins can source a maximum of 12 mA, so if you want to hook it up in a way that uses the GPIO pin as the current source there might be some issues.

I think to be safe, I'd just go ahead and add a transistor. That also can provide protection against a logical 1 being enough less than 3.3 V or a logical 0 being enough more than 0 V to cause problems.

You can find similar relays on Amazon for a bit less (search "solid state relay"), and even cheaper on AliExpress if you aren't in a hurry.

Post reply on HN