91–100 of 245 posts
Earlier quoted context omitted.
Is that compatible with non-apple devices? I generally dislike apple philosophically, so I avoid their products.
Yes, but Homekit enabled boxes need to be licensed and apparently need a custom chip. A look at the practicalities here: http://fortune.com/2015/06/09/ceo-apple-homekit-mess/
IoT is all about unsecured devices generally?
That's been my understanding as well. The cpu's used typically aren't powerful enough to do anything other than simple encryption in a reasonable amount of time. Ssl is generally out of the question. Someone please educate me if that's incorrect.
That's not to say that you can't do encryption though, just that you need to rethink how to do it, where the solution is not just unencrypted JSON APIs.
The stuff from wirelesstags.net are generally very good. I have a bunch of sensors and their Reed sensors for detecting opening and closing of doors are very good. I hook it up with ifttt and turn on my Hue lights when I open and close my doors. Clearly not ground breaking stuff but useful. The Hue lights are great but expensive. The Hue switch made things a lot more useful as well. I'm waiting for them to come out w…
The nice thing about Hue is that their bridge can run completely disconnected from the internet and still respond to RESTful API requests, which means that when Phillips end-of-lifes Hue my bridge will keep working with Home Assistant.
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…
> I'm willing to pay a lot of money for standalone quality devices, but nobody is supplying! You could pay an amateur electronics hacker to make you such devices.
Earlier quoted context omitted.
It doesn't bridge directly to real IP, there will be a 'hub' somewhere. You can't talk directly to the devices from any PC or mobile on the network, which is less convenient but reduces the attack surface to just the hub. (It's also much more power-efficient; you can't really use wifi on battery powered devices unless you charge them frequently)
I've gotten an ESP8266 device to last for about 3 days with (2) AAs when in using sleep mode aggressively for the wifi. Not to say that the Python stack is stable on it. It's not.
Earlier quoted context omitted.
If that's really how it works then does that mean that open source projects with no clear copyright owner can't enforce their license?
Well, if it's a project with lots of contributors, any one of them can sue¹. If no contributor can be identified, it's probably unenforceable, yes, though IANAL. ¹I believe there are some exceptions, like having contributed only an insignificant fraction of the whole work.
Let's say you contributed 500 lines of code to some project. You sue somebody for violating GPL and not publishing their changes. The judge has to give them the choice : either pay damages or actually comply (another western legal principle : money buys your way out of anything, as long as it isn't criminal).
What damages to assign ? Well, seems reasonable to say "how much for 500 lines of code ? A week's wages ? Okay, 2500 dollar damages awarded". The other party might become scared because other developers could conceivably sue, but ...
Earlier quoted context omitted.
That's been my understanding as well. The cpu's used typically aren't powerful enough to do anything other than simple encryption in a reasonable amount of time. Ssl is generally out of the question. Someone please educate me if that's incorrect.
Sounds more like the companies aren't bothered enough to pay for someone who knows what they're doing in a reasonable amount of time.
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…
I imagine something like the following would be good:
- Each component runs in it's own chroot/container/virt so the manufacturer can provide whatever they want, and the user can throttle it if it's poorly engineered.
- Discovery service that allows installed network server components to register with it for discovery. (Sun's RPC service, anyone?)
- Possibly also to proxy all traffic through discovery service, so network components have to specifically register for direct network access with very specific access limits if they want to use an internet service or talk to a company server.
- Separate file systems exposed for the application and stored data for each app, so a memory card card can be used for the data portion, and replacing hardware is fairly simple (after base software is installed, each application will discover it's configuration and stored data from the provided memory card). Possibly even a separation between data and config as well. IP cameras can spool all their recorded video to the data partition, which might be a large attached disk, but their config can be on a separate, easily swapped memory card, for maximum choice when upgrading.
- Let the manufacturers work out standardizing protocols for their industry, or not, and integrating with other apps, but let apps see the list of available apps, and request access to other ones, so devices from the same manufacturer or ones with a partnership can leverage each other.
- Lots of other stuff people will come up with along the way.
I imagine you could get any relatively cheap box, install the base software (linux distro of choice plus framework, or distro dedicated to this), and have it mostly work. Something like FreeNAS and similar projects.
Does anyone know of any groups out there working on something like this? Maybe some docker oriented distro that aims to be super simple comes closest?
Edit: Added another point or two.
> Eventually I plugged my phone into my laptop and ran adb logcat, and the Android debug logs told me that the app was trying to modify a network that it hadn't created. Apparently this isn't permitted as of Android 6, but the app was handling this denial by just trying again. I deleted the network from the system settings, restarted the app, and this time the app created the network record and could modify it. It st…
As a counter example, my brother who never uses a computer setup his chromecast in 5 minutes with zero help from me. I know b/c he called me and asked for help. I told him he wouldn't need it, but he didn't believe me. Things are getting better. There will always be more crap out there than good stuff. That's why walmart is so popular, but things will generally improve.
Earlier quoted context omitted.
Is that compatible with non-apple devices? I generally dislike apple philosophically, so I avoid their products.
Yes, but Homekit enabled boxes need to be licensed and apparently need a custom chip. A look at the practicalities here: http://fortune.com/2015/06/09/ceo-apple-homekit-mess/
Edit: Missed this line in the original article:
The issue, according to Lombard, is that Apple HomeKit certification requires a co-processor to handle device authentication. That co-processor is where the device’s encryption key is stored and handles the computing associated with encryption.
Looks like (for security purposes) Apple wants a dedicated crypto co-processor. Probably a tamper-proof chip that stores a private key, similar in concept to Apple's Secure Enclave.