Wanted to Spy on My Dog, Ended Up Spying on Tp-Link

Even if your hardware doesn't support local APIs, there's a good chance someone has made an HA integration to talk to their cloud API.

My #1 wish would be for someone to build a HA-native voice assistant speaker. I'd pay $100 each for a smart speaker of the physical quality of the $30 Google Home Mini but which integrated directly with HA and used a modern LLM to decide what the user's intent was, instead of the Google Assistant or Siri nonsense which is like playing a text adventure whose preferred syntax changes hourly. I'd pay that plus a monthly fee to have that exist and just work.

But that also means then that often anyone with physical access can easily get into the device. The complicated password provides an additional layer of illusion of security, because people then figure "it's not a default admin password, it should be good". The fundamental problem seems to be "many people are bad at passwords and onboarding flows", and so trying variations on shipping passwords seem to result in mostly the same problems.

I used to sell a home networking device,[0] and I wouldn't do what you're describing. If there were an issue where the labels calculate the wrong password or the manufacturer screws up which device gets which label, you don't find out until months later when they're in customer hands and they start complaining, and now you have to unwind your manufacturing and fulfillment pipeline to get back all the devices you've shipped.

All that to protect against what attack? One where there's malicious software on the user's network that changes the device password before the user can? In that case, the user would just not use the camera because they can't access the feed.

[0] https://mtlynch.io/i-sold-tinypilot/

Thats the wrong way to do it, just require the user create a secret on first boot, and have factory reset functionality for when you forget it.

It is better than simple secret like 12345678 but it can go wrong too, like in the case of UPC UBEE routers where the list of potential passwords can be narrowed down to like ~60 possibilities using a googled generator [1] whilst knowing only the SSID.

It did require firmware reverse engineering to figure out [2][3] but applies to most devices I've encountered. User should ideally always change the default password regardless.

[1] https://upcwifikeys.com/UPC1236567

[2] https://deadcode.me/blog/2016/07/01/UPC-UBEE-EVW3226-WPA2-Re...

[3] https://web.archive.org/web/20161127232750/http://haxx.in/up...

These are sort of orthogonal rants. People view this as some kind of corporate power struggle but in this context, GrapheneOS, for example also doesn't let you do this kind of thing, because it focuses on preserving user security and privacy rather than using your device as a reverse-engineering tool.

There is certainly a strong argument that limiting third-party app store access and user installation of low-privilege applications is an anticompetitive move, but by and large, that's a different argument from "I want to install Frida on the phone I do banking on," which just isn't a good idea.

The existence of device attestation is certainly hostile to reverse engineering, and that's by design. But from an "I own my hardware and should use it" perspective, Google continue to allow OEM unlock on Play Store purchased Pixel phones, and the developer console will allow self-signing arbitrary APKs for development on an enrolled device, so not so much has changed with next year's Android changes.

Firmware which requires updates to be signed with a manufacturer key can still be open source. As long as its code is available publicly, under a license which lets the user create derivative works, it meets the definition. You can still make a version of it that doesn't contain that check, you just can't install that version on the device you bought from the original firmware developer. Some FIDO keys (and I think Bitcoin wallets) do this.

If e.g. Slack required attestation that would be a different story. I need that for work.

Google Android as installed on 99% of stock android phones never was open source. AOSP continues to be open source and is not effected by any changes made in the proprietary google android and google play services eco system.

People would do good by stop conflating the two.

This is the key thing, and the part that will change next year: previously, you could unpack, patch, and repack an APK with the Frida gadget and install it onto an Android device in Developer mode, while the device remained in a "Production" state (with only Developer mode enabled, and no root). Now, the device would either need to be removed from the Android Certified state (unlocked/rooted) or you would need to sign the application with your own Developer Console account and install it on your own device, like the way iOS has worked for years.

Yup, but say Samsung, kiss KNOX goodbye. Fused off once you flash a non-Samsung image.

> and Google publish official emulator images with root access for every Android version released to date. This part is still OK.

Many apps will straight refuse to run in emulators unless you're lucky to snag a debug build that accidentally got pushed to production.

> Most of the root detection is beatable with Frida etc, mostly.

It's a cat and mouse game and frankly, I'm sick of it - and especially about the fact that it's either "accept that you'll need to wait X weeks until <Magisk plugin> gets an update" or "install some unofficial closed source fork that may or may not be laced with malware".

> Best hope here is that a) it creates much work for most apps to bother and b) it eventually gets restricted as anti-competitive.

Rooting detection used to be too much work, then SDKs cropped up that made it very easy, and that will be the case for remote-verifiable hardware attestation.

And restrictions from anti-trust? No way that will happen in the next three years in the US, and here in the EU it takes about 5-10 years until our parliament finally gets to work after a problem gets too much attention for their lazy asses to ignore. And even then, the lobby from banks, game studios ("them cheaters!!!" in f2p scam games) and other influential lobbyists will likely prevent any serious action.

The further we can go, the further we will go.

The more CPU power we get, the more JS heavy websites get.

The more images we can generate, the more we will generate.

The more we can do, the more we do, whether we should or not.

You are not accounting for the model training (which can't be ignored, first because you can't ignore fixed costs, and second, because we keep training newer models, so amortizing doesn't quite work), rebound effect, the subsidized bot crawling, etc.

I won't comment further on this, this discussion has been rehashed to death anyway and in better ways that I can.

IMHO the better way is to not do meaningless cover images, and this is also true of stock, non-AI generated images (I'm not against art, so if it's your strength, by all means, please do meaningful or nice cover images).

It's worth noting that Ubiquiti provides local admin support, and that the Ubiquiti Cloud data breach was actually a false story spread by a disgruntled internal engineer in an attempt to extort his employer.

What use is reducing the attack surface of a device which only ever initiates connections?

Edit: also there are network operators that block customer traffic on certain ports liike NetBIOS, SMB or SMTP to name a few.

Thanks for your comments.