As a chronic loser of keys and wallets, I recognize the user need here. However, this is a prime example of a piece of software that can only be trusted when an open-source implementation is provided.
Google and their customers don't have much to gain through a proprietary implementation. If anything, open-sourcing Find My Device Network would allow third party devices to join the network, enhancing its value to Google's customers. Google emphasizes ad nauseum that this system is extremely private and secure, so third party implementations shouldn't be cause for worry.
Governments and various potentially dangerous organizations stand to benefit greatly from a closed implementation for reasons that hardly need explaining.
Google makes a lot of lofty claims about E2EE and privacy considerations in that blog post, I'd just like to see them prove it.
Beside of open-source, this whole use-case should be built as an industry standard, not as a ammunition for an adjacent platform war.
With these few huge tech-companies, the industry has lost its natural "feature" that required competing players to work together and form an Alliance/SIG to make really big things happen.
Instead, the really big companies are happy to take the fruits from that time (Wi-Fi, Bluetooth, NFC,...) and build something proprietary on top instead of contributing back to it...
Open standards are still a very common thing. Google and Apple themselves cooperated in development of Matter... then failed to address the key-sharing issue that facilitates vendor lock-in on Matter... so yeah, uhh... never mind.
But that doesn't use the "find my device" netowrk. I think the parent wasn't saying, "I want an app that continually reports its location to my server so I can monitor my phone's location." Indeed, that's fairly trivial to build, but is useless if, say, your phone doesn't have internet access (like, someone turns it off or it runs out of battery).
The thing Google is announcing here is like the Apple "find my" network--it seems to allow you to use other people's devices to find your lost device simply based on a BLE ping.
That is something that is hard to build by yourself, and would benefit greatly from an industry-wide standard (more peer devices reporting locations!).
On Apple's devices, you cannot disable that BLE broadcast. The same is true on the Pixel 8: https://www.theverge.com/2024/4/8/24123909/google-pixel-8-pr.... That's the whole point of this design, and fundamentally different than just having some app ping a server once in a while so long as it has network access.
Beats me. I can't find anything definitive on this. Since Apple devices continue to broadcast Find My signals even when powered off (as long as they have a little bit of battery left), I assume they continue to do so in airplane mode.
It wouldn't do a lot of good if thieves could just turn off Bluetooth, right?
It turns off celular which is the main problem
(Wifi is common enough in modern airplanes so I have to assume the interference risk is low, same for Bluetooth)
This only works on the device itself, and while it can contact the internet or SMS. It's more akin to a self-hosted version of device locating features pre-airtag.
I think the real utility of tile/airtag/google-find-my-device is the network of other colluding devices listening for bluetooth pings and reporting on the location. Not least because apple (maybe google, don't know) forces your device to send reports if you want to use the feature. Heck, on modern phone OSs, you can't use BLE in apps without turning on the location service.
Open-source software would allow us to see how that published software handles our data, but it would not allow us to see how the cumulative sum of that data is handled after it is passed over to a central body.
Unless, of course: That centralized data store were also open -- perhaps even by using something like DNS -- but then, anyone of sufficient skill would be able to craft an application to see where others' things are.
(Unless... E2E encryption for location data, so it can only be understood by those who generate it? Hmm.)
An open source backend that requires end to end encryption on a per-user-storage basis, while not sharing those keys in the open source client (reference implementation) could effectively prevent third parties from seeing the data.
Something like shamir's secret sharing with split up keys effectively making the encrypted data useless, or based on time frames so you can only track the last "epoche" (like the last 24 hours, maybe?) similar to how HOTP/TOTP works could work nicely I'd imagine.
At Tholian (my company) we're using team based keys where at least 2 of x keys (the elected lead and co lead) in the team must co-sign a data changing action. It's peer to peer, meaning those peers can find each other and co-sign this without our servers having to store any transaction queue that could be compromised.
This way we prevent abuse, and if the feds come knocking on our doors, our users stay protected because without those keys we cannot see what's going on in any of the registered teams.
That's how I think it should be like, for any web service that supposedly keeps their privacy promises. If they don't do this, their promises were likely lies and once the root keys or the databases are compromised there's no turning back.
Looking at you, cross-tenant keys at Azure. Everyone knows you were and are still lying about the security aspects.
