Hacker News Reader

Comment by evanjrowley | Hacker News Reader

The answer to your 2nd question might be Google's custom silicon: https://blog.google/products/pixel/tensor-g5-pixel-10/

The answer to your first question may simply be they want to sell more Pixel 10 phones.

The investment into custom silicon is more likely to pay off when new and exiting features are exclusive to the newer platform.

View on HN

That hardware is completely unrelated to such a simple feature. Something like AirDrop will only use fairly trivial crypto, which most likely ciphers with full acceleration available but even without it would work fine with plenty of performance headroom.

Neither Apple nor Google is doing anything revolutionary with their silicon for such a standard compute task. It's really mostly minor tuning to get a more optimal part instead of an off-the-shelf chip catering to other uses too, with die area and power consumption "wasted" in your setup.

Could it be that this process needs to be running in a secure enclave

No, not at all. Someone even implemented AirDrop in Python before[1]. In fact, nothing ever needs such special hardware. It's a decision of the implementer if they'd like to get fancy and rely on such hardware in their implementation to change its security profile, but the iPhone at the other end or any Apple infrastructure would be none the wiser - they just see that they're getting appropriately signed or encrypted, and neither knows nor cares how that came to be. Use of a hardware security module would just make the process more tamper resistant but would not otherwise change the outcome.

1. https://github.com/seemoo-lab/opendrop

Relies on OWL which does have specific hardware requirements

No, OWL only appears to have specific driver requirements, namely that they expose to userspace functionality that any remotely modern WiFi chip should already have.

"you will need a Wi-Fi card supporting active monitor mode with frame injection" https://github.com/seemoo-lab/owl

Yeah, I saw that. I'm pretty sure that's a statement more about the drivers than the underlying hardware. Open-source drivers often have more limited feature support than the underlying hardware. I doubt anyone is producing WiFi chips that cannot transmit arbitrary software-constructed WiFi frames, or capture and relay to software all the frames they hear, and ACK frames as needed while doing so. But it's very easy to imagine that some of those capabilities would not be publicly documented, or not enabled with the default firmware provided to end users. Those limitations that hinder Linux end-users tinkering with their machines don't necessarily apply to an OS vendor with a deep partnership with the relevant hardware vendors.

Active monitor mode doesn't allow using AWDL while staying connected to a regular Wi-Fi network. That needs special firmware support.

It requires WiFi active monitor mode, which is a standard chipset feature. Nothing related to custom silicon, secure enclave, hardware acceleration or other such shenanigans being brought up in the current conversation, and nothing that most android phones wouldn't fully support.

Could be special needs for the radios

previous pixel phones also had custom Google silicon, just with some Samsung IP

Reply on news.ycombinator.com