I think specifically latest Pixels are often Google's beta testers. The enthusiasts owning them are happy to get features first and won't complain too much if it's rough around the edges. The phone is also not big enough revenue driver for them to be afraid that too many people would abandon it due to buggy new features
Also `we welcome the opportunity to work with Apple to enable “Contacts Only” mode in the future` doesn't make it sound like Apple actually helped implement this
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.
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.
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.
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.
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.
We get the early worm. At the same time, as a screenreader user, I wished that I didn't miss the responsiveness and ease of use of my old Samsung Galaxy S9+. I fail to comprehend how Google managed to make a phone which is harder to use than something produced 7 generations ago.
We've reached the point where a program that simply links file selection dialog APIs with network identity broadcast and file transfer APIs is so difficult to get working, that you can't expect it to be functional without the exact specified hardware and software version it was written for.
