X-Istence

Jasco/GE switches is what I used throughout my house... but the whole point to me was to have a smart home.

So when humidity goes up in the bathroom, the controller would kick on the exhaust fan.

When temperature drops in a room that is active below a set point, the fan is kicked on for the forced air to start circulating + heat would get kicked on if necessary.

The whole point of having a smart home is to have a smart home that does stuff for you. Walking into a room and having lights turn on is the best thing EVER. I don't want to touch a switch if I can avoid it.

If sensor traffic is not meant to go on a Z-Wave network then they shouldn't allow those device classes to exist on the Z-Wave network.

On the sensors I had I cranked up the change required before it would report, but it also did periodic reports. I had to also update those so that the network wouldn't get flooded.

Sleepy devices/battery powered devices on the Z-Wave network for things like window sensors/door sensors is kind of the norm. It's hard to run power for all those things, and those sorts of security sensors are handy for not just automation but also for peace of mind!

The thing is that I have a similar setup now with Zigbee/Thread devices... and everything just works. In fact due to not having motion sensors that also act as humidity/temperature/light sensors I end up having more sensors on the network, yet it is far more stable.

I see mDNS advertisements with my devices in them (such as Nanoleaf bulbs/Eve Thread devices), with a custom IPv6 prefix from the ULA, I assume assigned by my Thread border router.

The advertisements are captured by Avahi on my router... so they are on my existing IP home network.

It's not that the Z-Wave stick falls behind, when a Z-Wave device is broadcasting everything else has to go quiet (nature of RF), but the transmission speed is just very low, so when chatty devices (think sensors that report multiple bits of information such as humidity, temperature, light level, UV level, and more) are sending data you can't also turn on a light.

When you have a lot of those devices on the Z-Wave network (multiple motion sensors in a room to do more accurate presence detection and the like) those chatty devices slow down the network tremendously.

The single protocol throughout my house was my primary goal too, just to reduce complexity of having to deal with multiple hubs and integrations... but with my new house I did away with that.

Lutron Caseta for physical in-wall switches, IKEA Tradfri for cheap motion sensors/lighs, Philips Hue for more expensive motion sensors/lights, and a whole slew of Thread enabled devices, all controlled from HomeKit.

I don't really notice that its a bunch of different protocols/wireless standards underneath. I can control it from a single location which also makes it easier for guests/people visiting. Hand them an iPad with the Home app and they can control the house, or add them a Guest to my home on their own iOS devices.

I do miss some of the more advanced Home Assistant stuff I was doing, but overall the experience has been much cleaner, and with almost 0 lag.

That's less devices over a larger area than I had.

My house was 1200 sq ft, with a little over 200 devices.

All the devices were Z-Wave+, it was the one thing I was buying for. Not all of them supported the new encryption standard which started rolling out after I deployed most of my switches.

This was in a ~1400 sq ft house, with a little over 200 devices (motion sensors/lights/switches/smart plugs/humidity sensors/weather sensors). The network had a few repeaters the longest hop was 2 hops from the controller to the end device.

I was an early adopter for sure. This was back in 2016ish when I installed all of the devices. All of the devices were Z-Wave+ (specifically bought for that) but many of them did not support the newer encryption, and it ended up being a mixed network of devices for sure. Only the last few devices I bought supported the new encryption standard that was being rolled out at the time. I ended up getting a new Z-Wave hub that supported it to be able to securely enroll my new devices... but all it did was destabilize the network further.

It just left a horrible taste in my mouth, and once bitten, twice shy is definitely the case here.

The other thing that made things slow was sleepy devices that would wake up to report status. Things like motion sensors that also reported humidity, light levels, temperature and more (I do wish I could find a sensor like that for Zigbee/Thread... the multiple things in one was kinda nice). Every time they would wake up to report it would flood the network with traffic. And with each additional sensor I would have to tweak how often that would happen (and thus how accurate the data was over time) to reduce the amount of chatter on the network.

My Thread devices are all HomeKit devices, and they work incredibly well. Once they are joined to the Thread network they show up as IPv6 devices in mDNS and just work.

I have a ton of Thread enabled lightbulbs, smart outlets, and sensors on Thread, and I haven't had any issues.

They seem to mesh really well, store and forward for devices that are sleepy just works, but sleepy devices waking up and sending traffic is almost instant.

I do not own any devices that use WiFi, other than my Ecobee thermostat. So I can't compare against that. I would put the Thread devices up there alongside the Zigbee devices in terms of reliability, if not more resilient since I have multiple thread border router capable devices (multiple HomePod mini's and Apple TV's with Thread) so a device getting restarted (unlike a Zigbee hub like Hue/IKEA TRADFRI) won't affect the network/ability for the devices to trigger responses.

Z-Wave's mesh networking was a giant pain to get functioning correctly, and good luck if devices were multiple hops away... things would just randomly fall off the network.

With Zigbee (IKEA TRADFRI and Philips Hue) I haven' had any of those issues, nor with any of my Thread devices.

I installed Z-Wave all over my house. Replaced all the switches, got the sensors, light bulbs where necessary, everything was Z-Wave... and it was a nightmare.

I ended up selling the house with everything Z-Wave still in it, and the new owners were happy to have a "Smart Home" capable home, but I will never again touch Z-Wave.

Once your Z-Wave network grows past a certain number of devices it becomes too chatty and devices will be unable to communicate data. That led to motion sensors being incredibly slow and or not triggering when needed. Light bulbs wouldn't change colors until seconds or sometimes minutes later when the network was freed up enough to send the commands.

These days I have three systems: Zigbee (through Ikea TRADFRI and Philips Hue), Lutron (Caseta wireless), and Thread (through HomeKit).

I have a bunch of sensors on both Zigbee and Thread and they fire in HomeKit and HomeKit takes actions to turn on/off lights as necessary.

Lights turn on/off almost instantly, motion sensors just work (the Thread ones especially are incredibly fast), I've got temperature sensors/lightbulbs on Thread as well.

I am looking forward to seeing what Matter/Thread bring next as that is definitely where I will be concentrating my purchases. Z-Wave had a chance, and unfortunately it did not seem architected/high bandwidth enough for the amount of devices I ended up having on my Z-Wave network (~200 devices)...

Someone should tell the two recruiters in my inbox...

You are conflating keep alive with http pipelining, they are not one and the same. Keep alive may be supported and servers may claim to have fully parses request 1 correctly so they can be fairly confident request 2 can be parsed correctly, but reading the spec one way or another and that is no longer a guarantee that holds.

Keep alive and http pipelining are supported by major servers, some with bugs or issues, but no clients pipeline requests (at least not the major browsers, curl and other popular tooling).

It’s not FUD, pipelining and reuse of an existing connection is broken in the face of trying to parse text protocols that don’t have well defined semantics and where implementations reading the same documentation provide different results because it’s not black and white, it’s fuzzy around the edges.

There is not, which is what leads to vulnerabilities where two HTTP protocol parsers will parse the same request in two different ways (which led to the HTTP desync attacks).

https://portswigger.net/research/http-desync-attacks-request...

There's a reason why web servers will slam the door shut even when the client requests HTTP Keep Alive because they are unable to properly parse a request in a way that makes it safe to parse a follow-up request on the same TCP/IP connection.

HTTP pipelining is not normal usage of HTTP/1.1. And it means that if request number 1 fails, usually request number 2 and 3 are lost because servers will slam the door shut because of the lack of framing around HTTP it is too dangerous to try and continue parsing the HTTP requests that are incoming without potentially leading to a territory where they are parsing the incoming text stream wrong.

This is what led to the many request smuggling, its because the front-end proxy treats the request different from the backend proxy and parses the same HTTP text stream differently.

Since there is no framing there is no one valid way to say "this is where a request starts, and this is where a request ends and it is safe to continue parsing past the end of this request for the next request".

Servers are also allowed to close the connection at will. So let's say I pipeline Request 1, 2, and 3.

The server can respond to Request 1 with Connection: close, and now request 2 and 3 are lost.

That's the reason HTTP pipelining is not supported by browsers/most clients.

Curl removed it and there's a blog post about it: https://daniel.haxx.se/blog/2019/04/06/curl-says-bye-bye-to-...

HTTP Pipelining has the client sending multiple requests before receiving a response. It turns it into Request, Request, Request, Response, Response, Response.

The problem is that if Request number 1 leads to an error whereby the connection is closed, those latter two requests are discarded entirely. The client would have to retry request number two and three. If the server has already done work in parallel though, it can't send those last two responses because there is no way to specify that the response is for the second or third request.

The only way a server has to signal that it is in a bad state is to return 400 Bad Request and to close the connection because it can't keep parsing the original requests.

There is no support for HTTP pipelining in current browsers.

What you are thinking about is probably HTTP keep alive, where the same TCP/IP channel is used to send a follow-up request once a response to the original request has been received and processed. That is NOT HTTP pipelining.

> This is not the same as HTTP pipelining, which I will not discuss, out of spite.

That is cause HTTP pipelining was and is a mistake and is responsible for a ton of http request smuggling vulnerabilities because the http 1.1 protocol has no framing.

No browser supports it anymore, thankfully.

The key thing I am missing is how do I get my mail to flow from Postfix into this?

The docs are missing the most important part...

The Beats Flex uses the Apple W1 chip, just like the Beats X that came before them. They connect/pair to all of my iCloud enabled devices and switch easily between them as well.

I have mine mostly switching between my Apple Watch and my iPhone, but occasionally my MacBook Pro as well.

I won some Beats X from a contest at a conference in 2017, and used them on and off for the first two years. After that they were my daily drivers for any and all workouts.

They would get used at minimum 3 times a week for at least 2 hours, and then the last two years they would get used 7 times a week for at least 1.5 hours.

The last year or so I had to charge them every three workouts, so the battery was lasting 4.5 - 5 hours or so. They would still quick charge though, so 15 minutes of charging would be enough for a long workout.

About a month ago they stopped charging, no matter what I tried. I ended up buying the Beats Flex and the Powerbeats Pro. The Flex at $70 is a steal, and so far lasts about 12 hours before needing recharging. I've been using them almost daily around the house.

The Powerbeats Pro I've been using when heading to the gym when lifting, the lack of cord around the back makes them a better choice.

Anyway, the Beats Flex are holding up well over the last month or so... but the original Beats X definitely held their own too over many years of service!

I got this email too from Bank of America... but I already updated all my devices the day the new version came out.

Filtering by /64 is good enough. With a /56 you have 2^8 (256) prefixes, if you spam enough for a /64 to be blocked, you have 255 more tries before all of those are blocked too.

With some heuristics of "hey, we saw two /64's from the same /60" you can catch most ISP's that are offering prefix delegation to their customers, and that's only 16 /60's in that /56 before you are fully blocked...

It's not that much harder or difficult.

In Dell iDrac 7/8, NTP is a licensed feature.

See table here: https://www.dell.com/support/manuals/en-us/idrac8-lifecycle-...

I don't know how this is for others, but in the environments I am in we use a different KMS key for our backups so that if something were to happen, like a mis-click in a web interface or an accidental terraform destroy, we can recover the data.

It is also stored in a different location than the original (different AWS account).

You can have an instance of a VPC Endpoint per VPC. You can have multiple VPC's all with the same VPC Endpoints.

You just get billed for them ;-)

If you give me access to use your KMS key to encrypt/decrypt an EBS volume, and grant me access to that EBS volume/mount it to an AWS EC2 instance I manage, I can read/write data on that EBS volume all day long.

The fact that you own the KMS key doesn't stop me from reading/writing that EBS volume. It doesn't offer any additional security guarantees, especially if I was already encrypting the EBS volumes with a KMS key.

If I am a SaaS offering, whether I use a KMS key I own or one you own doesn't change the fact that I still have access to all of the unencrypted data that is silently being encrypted by those KMS keys, I've got access to the layer above it.

Sure, if the contract ended they could revoke the KMS key and now the data on the EBS volumes is no longer readable by me, but any backups I have of that data is still within my purview.

How old is your account?

I learned how to write code from books I purchased with cold hard currency. In the before times when dialup modems were the norm resources were scarce, and things like Github Copilot were just a pipe dream.

I have also taught classes and provided mentoring and support to new people up and coming in both programming and infosec. I would argue that as an open source maintainer I am actively contributing back and compensating those other developers. Unlike Github Copilot I am not selling the things I was taught, I am freely making it available to others.

It feels very icky that Github now gets to sell what it learned from my code base, when it has already been shown to replicate code with a 100% match, versus learning how to build on top of ideas or finding novel solutions to problems.

As the maintainer of some Python libraries, how do I get my part of that $10/month because Github Copilot was trained using my code...

There's communication between the device and the power brick. When the communication stops the power stops being delivered. Not sure how Apple is doing that these days with the MagSafe USB-C they have introduced on their laptops since you can plug the other end into any and all USB-C capable chargers.

The server would need to bind to that address, and then it should work fine as long as that address is assigned to a loopback interface.

That's the same as any system right now. If I bind to 127.0.0.1 I don't automatically get traffic for or listen on 127.0.0.2