I was wondering if something like could be done to upload sensor data without a data connection and it looks like that's exactly what the authors here had in mind!:
> Potential use cases
> While I was mostly just curious about whether it would be possible, I wouldimagine the most common use case to be uploading sensor readings or any data from IoT devices without a broadband modem, SIM card, data plan or Wifi connectivity.
The use case I had in mind is gathering sensor data from boat out in a harbor (away from wifi) that other boats with iPhone-bearing crew pass by frequently. This ESP32 AirTag emulator could send out battery level and bilge pump data any time someone sailed by, without the need for a dedicated modem. Might have to try this out!
I recall a mechanism like this used to deliver email in rural India. There were basically email “kiosks” which would let you receive and send mail for a fee and would store these messages locally until a truck with the company’s transponder stopped at the village, at which point it would send the data to the truck which would upload the data to the Internet when it reached the city. Obviously obviated by mobile data.
In 2006, I did a summer internship at NASA implementing the Bundle protocol [1]. It assumes intermittent connectivity and/or large delays between transfers. For example, you have intermittent line-of-sight between Mars and a tracking station on earth or line-of-sight between a rover and an orbiter on the far side of Mars that will at some point in the future relay the data onto Earth. I can't find it in the RFC, but using it to provide internet to rural villages was definitely discussed.
The process of delivering the internet by trucks is quite laughable, yet SMTP is the perfect protocol for that: Mail can hop from server to server until it finds the right one, as opposed to now where SMTP hosts like Gmail only accepts mail sent from or to a Gmail account.
I had a professor that made us answer questions about the bandwidth, latency, and reliability of a stationwagon loaded with hard drives. I never imagined I'd see a practical example of that principal at work.
Cloud providers like AWS will do data import/export via racks of drives in a shipping crate, if you have that much data. [1] (Or just a few drives in the mail if you're not moving petabytes.)
On the other end of the enterpriseyness scale, but still an actual real-world use, there's SD cards attached to homing pigeons [2], in addition to numerous stunts or pranks ala RFC1149.
Physical transportation of storage has always been a thing. Of course, over time, internet speeds increasing means it only makes since for larger amounts of storage. https://aws.amazon.com/snowmobile/
Classically SMTP let you "relay" mail that neither originated or is destined for the specific server. Gmail, and most modern SMTP servers, only permit mail from or to a Gmail address/their primary domain.
Edit: added clarification that all SMTP servers do not only permit Gmail addresses...
Is this sarcasm? As the gmail part is completely false.
Relaying used to be a thing, before spammers and unwillingness to deal with it at the source (boot infected devices, originating AS / IX, .. ) resulted in a choice between a game of whack-a-mole or only accepting gmail¹.
These days, relaying has to be setup on the specific relay server, the originating address needs to permit it (DNS SPF/DKIM/DMARC/whatever), and the relay server will still have a reputational problem with deliverability to unrelated servers, which is problematic even for direct mail, unless you are gmail¹.
Yeah another use case is broadcasting air quality metrics for consumption by the Health app, to start capturing exposure to various air environments you spend a lot of time in (office being primary example). I talk about this air quality broadcast a bit toward the end of my piece on repositioning HomePod around air quality - https://nickpunt.com/blog/apples-next-homepod-should-monitor...
Unfortunately Health doesn't yet store air quality, but I spelled out how air quality scores might be designed in the article. To the user it would be something akin to Fitness apps three rings but for different aspects of air quality: Safe, Fresh, and Comfortable. Within each would be specific air quality metrics (pm2.5, pm10, co, co2, vocs, temp/humidity, etc), which would sum up into three different scores for the three aspects. These would drive recommendations to the user.
I don't have an opinion on what protocol would work best, just that it needs to be localized pretty well to match up with the localization of air quality. My hunch is UWB is a better fit for that.
Could this be made into a cool emergency short messaging service during natural disasters or emergencies where connectivity may be unreliable or unavailable? Wonder how much “AirTags” payload one phone will proxy/buffer? And if/how well it works offline between phones?
As there's a limit of 16 AirTags per Apple ID, and each AirTag's keys rotate every 15 minutes, presumably Apple can detect if anyone is abusing the system by sending more than 16 different "messages" per 15 minutes. They can't detect this when the fake airtags are sending, but can detect it from stored message timestamps when you query. If they start to see this being abused a lot, they can then block Apple IDs. To avoid Apple being able to see this, you probably need to either use multiple Apple IDs, or send less than 16 bits per 15 minutes.
Suppose a real AirTag owner is wondering where their lost tag is. Although it would be ideal to learn where it is right now they'd be somewhat happy to know where an iPhone "saw" it two hours ago, or indeed a week ago... and Apple's system deliberately stores up to a week of data.
A week is about 700 keys to check. For one "lost" device, but as you note Apple are happy for you to buy more than a dozen, and of course you wouldn't be happy if Apple tells you that you must only track one of those.
Apple has no way to know if your check for 7000 keys is, in fact, ten devices for a week, or 7000 unrelated queries, it deliberately doesn't know how to relate the keys to one or more tags.
So while yes, that would mean if you have a long term sensor network Apple could block you using it to move more than a few bytes per hour per Apple ID (Apple IDs are free) if you have a more nefarious motive to move say a kilobyte in an hour or two, once every few weeks, that should work fine.
It's not the number of keys you check - that can indeed be large. It's the number of responses for different keys you receive with recorded receipt timestamps in the same 15 minute interval. If that is greater than 16 (or perhaps 32 given a normal tag can send two different keys in the same 15 min interval), Apple will know you're either querying more than 16 tags, or have tags using more than one key each.
The timestamps are useful to Apple only so that its storage needs don't grow continuously over time, it gets to throw away material it was told about seven days ago.
Because AirTag is designed not to chew battery lifetime on the various Apple devices which are effectively drafted to report they saw an AirTag those devices have no limit on how long they can take to get around to telling Apple what they saw. So Apple does have a "timestamp" but that doesn't tell them when the BLE happened, it just helps them purge their database tables.
Either the site linked or the paper (I can't remember which) has a chart showing that it can take at least hours for some iDevices to be comfortable that it's time to tell Apple. Maybe they're configured not to spend $$$ on mobile Internet and waited until they saw a friendly WiFi AP, maybe they got low on battery and went dormant until charged that evening.
Apple's main "defence" appears to be, as usual, that stuff is designed to be hard to use unless you've given Apple money, thus defending Apple's profitability but not really its customers of course. So a Mac can easily be tricked into doing this stuff (as was done for the article), but you'll need to do a bunch of custom reverse engineering to write a PC app and periodically Apple will casually break it, not because this helps their users but because it protects revenue. I predict some researchers will do that reverse engineering work, Bad Guys will just buy a MacBook.
This is covered in the blog post. There doesn't currently appear to be any rate limiting. And the rate limit would be tricky to implement because there are times when you need to catch up on the location of a device over a longer period of time. But yes Apple could limit to say 16 * 4 * 24 * 7 = 10752 requests per week.
No, the comment in the blog post is not what I'm suggesting. All Apple needs is to do is record the timestamps that iPhones received the AirTag beacon. When an Apple ID queries for keys, if Apple finds more matching key reports received in any 15 minute period than is plausible, then either the Apple ID is associated with more than the 16 permitted AirTags, or some of them are using more than one key per 15 minutes. So Apple can definitely detect this unless you either use multiple Apple IDs, or you limit to around 16 bits per 15 minutes.
for nation states and interested parties, these seem like trivial restrictions considering the value of now having a deployed mobile mesh network of 1 billion + devices available for free.
Any more info on "can be"? For existing AirTags, they would have to already have that functionality (polling for updates). I can't find anything that says they do.
Their firmware can probably be updated in the same mysterious way AirPods firmware is updated.
Roughly, be in the presence of an iDevice for a certain amount of time under unknown conditions. The advice on the internet is usually something like "leave your AirPods charging and have your phone connected to them when you go to sleep, and they'll probably be updated in the morning".
I’d be surprise if Apple fielded AirTags without any way to update their firmware. I doubt it would be automatic though, you’d have to push an update to them from an iDevice.
Then you'd have the problem of new air tags not working until they'd been updated. It's something of a minor problem, but unless people actually misuse this enough to be a worse problem, I don't see why Apple would update to disable this.
It's a much cheaper device than Airpods, harder to manage battery life, and there's not yet evidence that they can update them automatically. As far as I can tell, competitor products (Tile, for example) don't update firmware automatically...it's a user-initiated thing.
I can't find anything that shows OTA firmware updates of the tags themselves happening. Yes, you could tweak the iPhone, but if a "emulated tag" looks exactly like a "real tag that can't be updated", you're somewhat limited.
Rate limiting would help with the "hijacking the network to send your own data" piece in the original article.
It wouldn't do much for other uses, like tracking people without their knowledge. A "faked AirTag", could, for example, rotate it's serial number to avoid triggering Apple's "AirTag Found Moving With You" feature. Or the opposite of that. You could stick a fake device on someone's car and trigger the "AirTag Found Moving With You" warning over and over by periodically changing the serial number after the user suppressed the warning for a particular AirTag.
Presumably a valid serial number for each AirTag is something that can't be guessed? That's how it is with Apple's other products. Each serial number has some entropy in it and there's no way to generate a valid new one.
Does this fall within Apple's policy of fair use? Would be great if there were an officially supported (paid) API for this, the technology and potential use cases are great. I'm afraid hooking something like this up to my Apple ID will get me banned somehow.
You are using other users' (mobile) bandwidth to do the transmission, and apples server resources to brute force/ddos request the data on the other side. I can't see them condoning this at all and simple not responding negatively to it could encourage this misuse. I would expect that kind of response from Apple.
Would be cool if Apple released a iPod touch with pager functionality that works thru find my network. Where you can send / receive short messages (even with 15 min delays).
Every message uploaded to the "Find My" network very slightly degrades the user experience for all Apple users - since it is using up CPU cycles, battery and bandwidth of random strangers iPhones.
I wonder what the capacity of the network is before the impact on battery life becomes significant...
It uses BLE (I believe), and data upload can be combined with other requests on the iPhone's next cellular connection request. CPU use is going to be extremely minimal. BLE power usage for a low data rate transmission is very, very low.
I don't really see any realistic density of AirTags that would have any measurable impact on energy use of nearby iPhones.
I guess they can just rate-limit the program that runs in the iPhone, but that still (to me, very naively) would allow a DoS that prevented genuine tags from access.
As mentioned in the OP to know if the tag is genuine a device needs to go to the trouble of receiving the traffic in case it's real, then decrypting (search "ECIES encryption" in OP): so you'd be wasting quite a bit of processing before you reject a fake tag. If they rate limit the decryption - which you'd have to - then you can overwhelm a device on the network by sending out fake packets.
It strikes me you can generate random BLE data that looks like airtag data cheaper than you can verify packets and so in theory one iPhone could overwhelm a minimum of one other; and presumably could overwhelm all others in range (with lower or equal processing power).
They do mention their (the OP's) public keys being rejected.
So, if my analysis is right you can either use all processing on all devices in range, or overwhelm all devices in range of they're rate-limited. The second case is preferable.
I'm interested in why I'm wrong. Can the imaginary fake tags in my analysis be rejected using less power than it takes to make them?
Or, in summary: “Using radio frequencies to intentionally disrupt or damage the functioning of devices you do not own”. Make sure the FCC doesn’t catch you!
I'm not in USA, but I've always read FCC as an administrative arm of government, do they do active monitoring and enforcement? Like of you fire up a rogue transmitter the FCC send officers to apprehend you?
They have an enforcement division. I’ve always heard if you start a pirate radio station with a bit too much signal, it’s only a matter of time before two agents come tell you to knock it off.
The power hungry bit is probably powering in the GPS to attach a location.
On Android at least, getting a GPS fix takes many seconds, during which the CPU cannot sleep. For that reason, a default Android phone won't power up the GPS for hours on end sometimes. Yet this find-my feature might require a GPS position every few minutes whenever a new tag is seen. That's a lot of extra power.
If they were to officially support this use-case of arbitrary data transmission, you could also default to non-GPS-located transactions, which would save that power except in cases where the user has specified that they do need locations.
Also, coarse location (cellular and wifi) uses basically no power, and might be good enough for an awful lot of applications.
Cool, but I don’t see it being viable, commercially.
Suppose they make this, how many would they sell? How many of those customers would have bought an (more expensive, I presume) iPhone if they wouldn’t make it?
They stopped making iPod touch for similar reasons. I doubt adding this feature would attract enough extra buyers to change that.
That would be swimming upstream in terms of profit incentives, though. I hope it does happen but anyone who has the money and inclination to fund the development is also someone who has a vested interest in the client / server topology we have now. If there's no server to feed you wireless connectivity there's no way to make a profit from being that server.
The sending rate on the microcontroller is currently ~3 bytes/second.
The latency is usually between 1 and 60 minutes.
That's not much, but it has value for industrial machine-to-machine communications. (That's IoT without the hype.) Like commercial air conditioning units. They can send in minimal data ("compressor 1 running, compressor 2 stopped, system OK") to a maintenance service without needing a cellular account or connection to the Internet.
Minimum cellular cost for very low data volumes is about $1.75/month.
5G is only useful if you need bandwith in an area with very high contention, like a stadium, or you're in an area remote enough that the lower frequencies work but the higher ones don't.
Sounds like you could drive someone a bit crazy with Apple's "AirTag Found Moving With You" feature, since you could rotate serial numbers. Like gluing one of these to their car in someplace not obvious.
Wait, maybe I'm confused, but isn't the point behind rotating serial numbers that the person couldn't just click ignore? But how much sense does that make, if people are routinely ignoring tracking devices glued to their cars instead of finding and disabling them, that seems like... a problem. A tracking device that decides to re-alert you to its presence rather than remain hidden and silent seems like a less dangerous tracking device, rather than the other way around.
You can either rotate it after the time period where it alerts them, to be annoying (they have to keep dismissing it). Or, you rotate it before it alerts them, and stitch the tracking together. That's the more dangerous bit. Apple only alerts if a specific tag is following you for more than X whatever.
Would it be possible to relay communication between iPhone and the AirTag, making the iPhone think the tag is in a different location than it actually is?
The communication is one-way, and the only thing transmitted from the lost device is the bluetooth public key, so no. The device that detected the AirTag encrypts the location with the public key and transmits it to Apple, not the AirTag itself.
But what if there is a man in the middle, X: tag sends Bluetooth key to X, then X relays that (e.g. over the internet) to Y which sends it to an IPhone.
And since the communication is one way, there is no encryption (I suppose), so replay-attacks should be possible unless it uses a clock.
Someone could write an app which reads Bluetooth IDs and then transmits them at random times.
I think spoofing will be difficult unless you can dump the key from a specific AirTag (already done, but it's a manual process involving disassembly and advanced skills and equipment).
Replay attacks may be possible, but we will have to wait to see if the protocol is entirely passive. The iPhone could broadcast a challenge to the AirTag and transmit the signed response and response delay. The delay should be fairly tightly bounded.
The AirTags do have a clock as I understand it, but drift is inevitable, so it wouldn't be a tight bound.
You can opt your phone out of participating, but of course that won't stop other people's iPhones and iPads reporting the position of any AirTags they see near you.
It's unfortunate that, even though your phone can leave FindMy, it isn't as straightforward as going into Airplane Mode. You certainly can't choose to disable it at certain locations.
I think you'd still have issues mapping a mesh, especially with how often phones are moving. I remember looking at meshtastic for a mesh wireless network and they're still working on a solution for a large number of nodes covering a large area:
It is only decentralized if the entire world is covered in Apple devices every few meters. At the moment they are simply extensions to a nearby router or cell tower.
It’s interesting, that this use case is only possible because Apple tries to preserve privacy of the devices. Unlike Amazon Sidewalk, that requires to authentication of the IoT device, Apple does not, allowing unauthorized devices using the network.
Sidewalk is also connected to grid power, and the backbone consumer devices are in fixed locations. I don’t see grid vs battery or fixed/mobile device locations as necessary advantages or disadvantages though.
For example, the FindMy network would continue to work even in power outage scenarios like parts of the country experienced in Feb 2021.
Apple is creating a yawning double standard between its "privacy is a human right" [1] refrain and its own profit interests.
If you're skeptical, the pricing says it all. Apple could've sold AirTags for $99 each with a $1/mo service fee to use the Find My network. That would've boosted their profit margin on the initial sale and created recurring revenue, while restricting network load.
As it stands, AirTags are $25 each and free to operate, which means that Apple wants them to be ubiquitous — buy 10 or 20 and put them everywhere.
Apple has gotten a lot of mileage on their idea that "the customer is not the product" but this is a turn in the wrong direction. Despite months of claims that AirTags are impregnable, unhackable, etc. the news is just going to get worse.
I am fascinated by the amount of attention the AirTag has gotten from the HN community and elsewhere.
Of course Apple is a massive company, but there is something extremely compelling about precise location tracking. Even if this product isn't successful, I think Apple have propelled a new category of products to the forefront.
I'd be much more comfortable with Apple being Privacy, Inc. if they kept their commitment to it, too often it looks like engineers got overrode by marketing. It's v unlikely a privacy engineer signed off on something, with so many side channels, with real world consequences, compromising a billion + iOS devices
Um - I think you are totally missing the point - Apple is doing probably the only fully encrypted system - vs tile and friends where everything lives in a database. This is not compromising billions of iOS devices, which frankly remain FAR FAR more secure than 80% of the competitor handsets which in many cases seem to ship with backdoor built in by their mfgs.
I've gathered there's a beep if this is going on for 3 days, but...still not comfy with this. And this isn't a particularly fringe opinion, plenty of comments on the article wondering how to opt out:
"Beep as anti-stalking measure" is somewhere between marketing spin and gaslighting. A lost AirTag chirps to serve its primary function of being recovered.
The timer is 3 days[1], which observers (Forbes, WaPo) agree is surprisingly unreasonable for this use case. We can infer it was never a serious design consideration.
On Android, decent Bluetooth is a gamble, but scanning will theoretically find one[2].
Not constructive :( Getting downvoted through the floor on Apple comments for the first couple hours is a time-honored HN tradition at this point, but I'm hoping you can help us break that habit: a big contributor is aggressive comments like this that assume an agenda.
I know you can come up with something more substantive than guessing I didn't read the article. To wit, easy quote that backs what I read, and I assume I'm mistaken, given your feedback:
'The details should come as a surprise to everyone because it turns out that ITP could effectively be used for:
- information leaks
- tracking the user
- fingerprinting'
> Potential use cases
> While I was mostly just curious about whether it would be possible, I wouldimagine the most common use case to be uploading sensor readings or any data from IoT devices without a broadband modem, SIM card, data plan or Wifi connectivity.
The use case I had in mind is gathering sensor data from boat out in a harbor (away from wifi) that other boats with iPhone-bearing crew pass by frequently. This ESP32 AirTag emulator could send out battery level and bilge pump data any time someone sailed by, without the need for a dedicated modem. Might have to try this out!