For the context, the vast majority of carriers do RCS with Google's RCS servers (https://github.com/phhusson/rcs-scanner). I'm a bit rusty, but to my knowledge the only exceptions are Jio in India, all Chinese telcos, and some Japenese telcos.
Of course it is relevant privacy-wise (Google still gather a lot of metadata about who speaks to who and when), but that's not even the reason I'm mentioning it.
In the RCS specification, there are three lines on a killer-feature: device attestation. A server can whitelist which devices are allowed to connect to it. And of course Google uses this, allowing only Google-certified devices and Apple devices.
And then, there is actually one RCS client for Google's RCS servers. Because Google Messages doesn't use RCS, it uses a custom protocol based on protobuf. My personal guess is that this protobuf is a 1-to-1 matching with actual RCS, and it's both-way compatible. But still, that means that potentially the Google device-attestation won't work with an RCS client.
Sibling comments say that GrapheneOS plan on implementing it. I think it can reasonably work. TBH I'm expecting that giving a LLM the publicly available information about RCS on microG should give a working "send message" within a day (even when using Google apps rather than microG, it's just that the microG work explains the API). And once RCS work in GrapheneOS' message app, it should be pretty straightforward to port to microG, so yay. However I have to admit I'm not optimist about how long it will keep working. I'd say we are two years away from Google enforcing RKP device integrity for RCS, and uh, good luck passing that.
Of course, I'm hoping that, in the EU, the DMA will break this Google/Apple-only device-attestation, but I'm not aware of anyone pushing that ATM.
Considering child comment, I agree it's not great. That being said, would a bit-hash have worked? How many users are capable of sending bit-perfect images to someone else? I don't expect more than 5% of people to know...
Relatedly, someone found that on a Qwen MoE, increasing the number of experts at the deep layers reduces the number of thinking tokens. So while you mention that the LLM is capable of thinking more if it's thinking less clearly, it looks like it's also capable of thinking less if it's thinking more clearly?
This has been validated on Qwen3.6-35B-A3B and Qwen3.8-Flash-Next, but with the caveat that it was always on quants.
I definitely love this article and this spirit. I've accumulated a lot of crap/cheap IoT, I'll probably owning them!
Two things:
- to rain on the parade, the European RED directive makes secure upgrades mandatory for anything connected to the internet (I suspect that's why Elgato Key Light Mini has signed firmwares). So OEMs are now required to prevent you from doing that. (EN18031-1). It even requires that network credentials (WiFi SSID/PSK) to be stored on secure storage (idk if you can pass that requirement without secure boot. I would guess Elgato does?). "secure upgrade" is loosely defined as "integrity and authenticity are valid at the time of installation" so this requirement doesn't forbid us from upgrading our hardware, but the most likely implementation of OEMs does.
- When you want to do that on Android smartphones (please do!): I recommend to go through GSI/Treble route: This way you quickly have an OS that boots. There are a lot of things to fix, but it will be mostly userspace stuff, which will be easier for the agent to work with. Agent will be able to decompile OEM's userspace and compare with AOSP's userspace, and implement the differences. (That's compared to the ""legacy"" or LineageOS official method which are more convoluted, including kernel stuff, and getting just to "it boots" can be complicated).
The CRA that will be active starting december 2027 will also do similar things like RED. Cant ship with fixed static credentials anymore or manufacturer backdoors (unless the user activates them)
Hum, I don't really know. I was pretty sure it applies to anything connected to the internet even if it's Ethernet-only, but double checked. And reading the EU directive, it looks pretty obvious to me that you're right, it's only for devices with wireless connectivity... (the wireless connectivity doesn't need to be wifi/internet though. like if you have a 433mhz-to-ethernet gateway it still fits).
(Technically it says "which intentionally emits and/or receives radio waves for the purpose of radio communication", I'll let HN crowd determine if Ethernet emits/receive radio waves in an enclosed channel called Ethernet cable)
The cool thing about cryptographic security is that it's an asymmetric amount of cost for both parties - to encode is cheap, to break is many orders of magnitude harder, unlike obfuscation where the difficulty is approximately symmetrical.
All security is always a matter of cost. Clown theater starts once you lose track of it, and start doing security for security's sake.
RE obfuscation and nation states - nation states have finite budgets too, both in terms of resources and attention. They can crack any system at any time, but they can't afford to crack all of the systems all of the time.
> "You can just make it type words, what's the risk in that?"
I don't know if it's a useful answer to people saying this kind of stuff, but here are some examples of other attacks arbitrary USB pwn allows.
A USB device can appear as a network adapter and most OS will happily route all your traffic there, so your speaker can know which porn you're looking at!
It can also appear as a DisplayLink dongle, so it can see what's on the screen (it does require those specific drivers installed, and uh yeah, no way in hell it's technically possible on that MCU).
It can also turn it into a mouse jiggler to prevent lock screen (yes it's technically the same thing as your first point, just HID, but different angle).
It can also appear as a USB-storage: You don't trust the cloud, so you're writing those super secret documents to give to your boss on the USB drive you just plugged in? Surprise, you actually sent it to the attacker.
The ability to "type words" is worse than all of that. Just type Win+R, "cmd", Enter and you've got arbitrary code execution on the connected PC. I think that was GP's point. Any competent security team would be aware of such risks.
Couple decades ago a product team of our product, the team consisting of PMs, senior engineers, etc., dismissed a security issue as a not serious because notepad.exe - which the PoC used to show arbitrary command execution - supposedly can't do much damage.
See also the debacle with Razer gaming mice giving you root access just by plugging in, which I think takes the cake for clownshoe software practices almost rivalling Riot Games (though not with the latter's degree of self-congratulatory Dunning-Kruger gusto.)
You can do an IR remote without a RTOS, but as soon as you do BLE you realistically need a RTOS. You have timers for keep-alives, connection states, competing interrupts, CPU-"intensive" tasks that can be preempted (for crypto)
I agree with you that it is the very obvious conclusion, but it isn't obvious to everyone. But it could still be relevant to you if you find yourself discussing with someone saying "why do we even spend money making an API, the AI can just control my computer?"
I'm on the side of "clever, fun, but feels useless". But to defend the project, all sensors require a powered central system. It's pretty common for Zigbee to have one repeater per room [1], which is just what is needed for this system.
[1] Because any AC-powered Zigbee device is a repeater, so just a bulb or a plug is enough
Of course it is relevant privacy-wise (Google still gather a lot of metadata about who speaks to who and when), but that's not even the reason I'm mentioning it.
In the RCS specification, there are three lines on a killer-feature: device attestation. A server can whitelist which devices are allowed to connect to it. And of course Google uses this, allowing only Google-certified devices and Apple devices.
And then, there is actually one RCS client for Google's RCS servers. Because Google Messages doesn't use RCS, it uses a custom protocol based on protobuf. My personal guess is that this protobuf is a 1-to-1 matching with actual RCS, and it's both-way compatible. But still, that means that potentially the Google device-attestation won't work with an RCS client.
Sibling comments say that GrapheneOS plan on implementing it. I think it can reasonably work. TBH I'm expecting that giving a LLM the publicly available information about RCS on microG should give a working "send message" within a day (even when using Google apps rather than microG, it's just that the microG work explains the API). And once RCS work in GrapheneOS' message app, it should be pretty straightforward to port to microG, so yay. However I have to admit I'm not optimist about how long it will keep working. I'd say we are two years away from Google enforcing RKP device integrity for RCS, and uh, good luck passing that.
Of course, I'm hoping that, in the EU, the DMA will break this Google/Apple-only device-attestation, but I'm not aware of anyone pushing that ATM.
reply