(This post emphatically not endorsed by my employer.)
There are a bunch of projects on github, but I used:
https://github.com/newAM/idasen
You can install it with just "pip install idasen"
(Also fwiw if you email ‘dang sometimes he will change your username)
https://twitter.com/rombulow/status/990684453734203392
Maybe consider changing setting the height to a POST request
* I just didn't want to mess about with postman or curl or whatever in order to test, much easier to just issue a get request by visiting a url in the browser
* I'm going to be ripping the HTTP support out shortly and replacing it with MQTT support so it can more cleanly integrate with my HomeAssistant setup. The HTTP stuff was mostly just the fastest way I could get something approximating what I was looking for.
I definitely agree though, this being a `GET` request is offensive :P
To be clear I'm just talking about the web interface, not implying the whole project is throwaway - on the contrary it looks like a lot of work (and a lot of fun :) ) kudos!
Thanks for the post though, a fun read!
I'm not sure I understand. What is this referring to?
Had a GET request that would open or close the garage door.
Safari learned he liked that page, and would hit it every time he opened a new tab on any device.
Edit: Fixed the link now.
https://kn100.me/posts/desksniffer/pbfront.webp
It looks like it could come in handy for many esp32 projects.
p.s. In case the author comes across this comment - Absolutely superb write-up, your writing style reveals your curious and positive attitude, it's totally inspiring! I wish I could easily subscribe to future publications, like the emails I get from Ken Shirriff of https://righto.com. Also, your C++ is clear and easy to read, good job. Cheers.
Edit: @Klathmon, thanks for the info, that was very fast :)
I2C supports multi-master designs.
In practice, it is similar to how a firearm allows one to shoot at themselves in the foot.
Electrically it seems like a low speed bus should be the ultimate in reliability. Sadly, I2C peripherals are implemented with high speed digital logic and sometimes no filtering (or present but not enabled)! They might react on nanosecond glitches of the I2C clock line or very high frequency noise that is hard to see.
It boggles my mind that I2C is implemented so horribly but continues to be used… for decades.
And don’t get me started on the hung bus problem…
But it’s a hallmark of the times that I was immediately like, I bet someone is looking at how hard it would be to break into this.
All the great old-school IoT stuff (webcams of the coffee pot, all that stuff) was such a more fun time. We could have nice things back then.
The nice thing about a hack like this is you, the creator, have full control over exactly what is exposed or how. There's no cloud, no external control, no unwanted firmware updates, nothing. If everybody was willing and capable to engage with their hardware at this sort of a level, there wouldn't be this crisis of insanely insecure hardware being sold to uncaring consumers, imo!
I'd love to see that more standardized and things like OpenWRT for all sorts of IoT junk, giving back control. Opinionated things like Valetudo https://valetudo.cloud
It's why I also have trouble seeing the link you seem to find obvious, the global dystopian surveillance and data-brokering aspect. Specifically in relation to personal hobby projects like this, as the author is doing nothing new and there is absolutely no link to data-brokering...
While iot is blurry a personal electronics project is not.
Unfortunately, the root of the issue is that the line is very thin and hard to see. Which is why it gets crossed so often and only realized post hoc.
I apologize for the lengthiness that is to follow.
For a desk, it's something that seems nowhere near nefarious, even if it leaks to the internet, right? Well we could imagine a world where your boss can see this data because they set up such a system inside the office. Probably with some good intent too like raising all the desks at night to help janitors clean under them or something like that. But a new manager comes in and uses that data as a means of determining how much you are working. Might even implement policies like having to stand up and sit down every so often because they are reading blog posts on worker productivity and sitting too long. It can be "in the best interest" but can quickly become abusive. The concept of "turnkey tyranny" isn't limited to governments and it's important to remember tyrants don't view themselves as evil. More often they just view themselves as "better", "know what's best", or "ends justify the means." Generally it is an extreme version of Main Character Syndrome (which MCS is not too uncommon in our communities...)
As a clearer example, where we have the advantage of hindsight, I think social media can fit in here. I very much don't think social media started with bad intentions and honestly, I don't think people today working on it have bad intentions. It's more the problem with "the road to Hell is paved with good intentions." Social media does good, it brings people together across the world, and allows us to have competing (in a healthy way or unhealthy) views. We're doing it this very instant! But one issue at the core of the problem is "engagement." We know these algorithms optimize for is, but what's it mean? We can see how it is based on activity. Things like post interactions, shares, commenting, likes, and so on. But think about this problem hard. How do you __actually__ measure engagement? How do you __actually__ differentiate "good" engagement from "bad" engagement? Can you find natural language words for this? I bet you're going to have a really hard time. And then an even harder time expressing this in code. So what happened? Well we got an overly simplified version (obviously, given that this concept is essentially intractable and highly dynamic), and got metric hacked.
These people are trying to do the right things, but just have a limited scope. It's worse if they don't realize their scope is limited (see MCS). People who don't understand the metrics just understand that they are metrics and so optimize for them. Managers can dismiss engineer complaints because these people can't speak the same language and are working at different levels of abstractions. It's a whole complicated mess where the main issues come down to the chaotic interaction. It is almost never someone seeking out to perform evil, but people who can't see beyond themselves (which is hard!). And even when we can see beyond ourselves it is hard to see very far. Be that into the future, into other "tribes", or whatever. The best defense we have against these things is to stay defensive, communicate, acknowledge concerns (even if moving forward. Just means tread carefully), and to balance short term rewards and long term (short term is easy to measure, but can easily lead you away from huge future payouts). We live in such a complex world that to maximize your objectives you often need to maximize other peoples objectives in certain situations[0], because if we treat everything as "zero-sum", "single round", or similar naive approximations, we will push ourselves away from our goals. This is the tyranny of complexity, how trying to do what's best is always far harder than it seems. And worst of all, it's incredibly hard to measure the impact of your decisions through these chains of interaction.
So if all this was hard to understand, I get it, because that's also the problem. It's the little things adding up, not any one or even a few big thing/s.
if your standing desk has that ethernet like connection scheme, something like this might just work out of the box!
POST requests should be idempotent, ideally. PUT requests certainly must be; it's their defining characteristic. GET requests, though, just shouldn't have side-effects at all.
(A /toggle URL isn't idempotent. If it were /open and /close it would be, but still shouldn't be GET.)
Don't be dismissive. Just because others can't see it, doesn't mean we should be dismissive of __them__. I know it is subtle, but I think this is important, especially if we want to be taken seriously. The whole problem is about how small things add up, and often how we can't even see the issues with the small things themselves. People's views are going to be skewed by their experiences and often, with regards to this topic, how effective (or seemingly effective) their governments are. The line is thin and hard to see. That's the whole problem in the first place. So don't chastise people who can't see the spiderweb just because you were at the right angle to see it glistening in the sun.
In the end, building a product that could properly facilitate this would just wind up costing more than viewing them as disposable units that you toss out when a newer version of something is available. This is optimal from a capitalism standpoint, but suboptimal from a sustainability standpoint.
Yep, that's probably true.
> 2) This would likely violate most FCC/CE/C-tick/etc. certifications.
IANAL but that doesn't seem like it can possibly be necessarily true, since most computers let you replace the motherboard and wifi card.
> 3) The whole assembly would need to be designed to be field servicable so you could access the circuit boards, which would also add cost (and possible warranty issues).
Not all, but most IoT boxes I've seen already are easy enough to take apart, it's just that there's not much to do with it once it is apart. So I don't think this would be a change.
This would be okay for iot bricks but more useful for laptops. Company gets X years of secrecy and when they abandon support, they open up the secure enclave and let FOSS devs go to town.
I've tried a handful of used hikvision / dahua in the ~100usd range but they don't play nice with anything other than the vendor's software. Like VLC / open source VMSs can't play the RTSP stream. And even then, its a crapshoot whether features like stream configuartion or PTZ work.
I know the ONVIF group publishes a list of verified-compliant models but it's been a pain trying to find one that's affordable and in stock.
I've heard from devs that work on this stuff that most of this pain stems from how loose the ONVIF spec is. Too many optional features (even per "profile"), too vague on requirements, leading to lots of vendor-specific metadata / camera quirks.
What I did was go to them via the https://forums.zoneminder.com and looked for recent posts.
It's even more of a crapshoot because some of the cameras were absolute shite until I found some sketchy Chinese firmware of a particular version, which made them suddenly beautiful.
All of these are very securely cordoned off and unable to contact the Internet at large, of course.
I am now experimenting with the RLN36 NVR instead, and thinking about having enough disks to record continuously instead of events only.
Ideally I want continuous recording, and I want a timeline of events that aren't separate files, but are just shortcuts to alarm times within the continuous recording, with minimal seek delay. Interface must be friendly to small screens (phone size) which the RLN36 web UI isn't particularly. Maybe the zmNinja app.
If I were to set it up again, I'd go further down the home assistant path (one camera I got setup so it appears in HomeKit, but I never bothered getting the rest).
For an "IoT box" type of product there would likely be fewer issues with the certifications and swapability.
For IoT devices like light switches, bulbs, smart outlets, or anything else where the 120V/240V power is exposed vs. isolated by a power supply (as in the case of a PC or "IoT box") it would likely be too costly to do in a conformant way. Particularly when the tinkerer consumer base that would actually value this is maybe 5% of the total market.
