Not in the BitLocker configurations I've seen over the last few days. The file is deletable as a local administrator in safe mode without the BitLocker recovery key in at least some configurations.
It's not specific to iCloud Keychain--it applies to on-device Keychain on iOS devices, too, even if you don't use iCloud. Any developer can store data there with no way for the user to know or see what it's saving, and it's shared among all apps from the same developer. Keychain is quite a misnomer here--it's really "store any (short) data you want on a user's device without them ever being able to see or remove it". It transfers when you restore backups on new devices, too, even if you haven't had the developer's apps installed in the last decade.
This is an issue because if you ever use an app by a company, uninstall all their apps, and then install one of the developer's apps years later, they can tell it's the same iOS profile (even restored on a different device), profile what you do across those apps/installs/decades, and associate any accounts you log in with. Essentially they can put a permanent cookie that you can't even see on your iOS profile that's shared between their apps. If you use iCloud Keychain, they can probably profile you across all your devices regardless of whether you reset one.
Apple has said this isn't intended functionality and they were going to address the issue many years ago in iOS 10.3 by removing Keychain data when the last app from a developer was uninstalled [1], but they got cold feet. If I recall correctly, the reason was that some app developers were relying on this unintended functionality to ensure free trials couldn't be used more than once. Apple was going to introduce a service that could store only 2 bits of data to enable that use case and then revisit Keychain deletion when the last app from a developer is uninstalled, but it appears they haven't.
This is also used heavily for abuse / spam / fraud prevention.
If you detect that a user is abusing your service, the ability to put a permanent cookie on their device is very useful.
This isn't effective against organized crime groups (they can just get Macs / use the web / whatever), but works well against your average troll or internet racist.
Still tracking, but a very different kind of tracking.
The "store 2 bits of information" approach Apple was moving exploring would solve at least a lot of that case. You could effectively store 3 pieces of information: 00 = default state, 01 = used free trial, 10 = banned, 11 = something else the developer wants to store about the iOS profile. You don't need to be able to uniquely identify it to ban it.
So it's not the case that it'd be too much work or technically infeasible for such a permission to be available to us. It's just that Apple doesn't actually care about us or our privacy.
Phew! I'm not sure about Rogers and Bell, but Telus doesn't seem to grasp what the "e" stands for in eSIM. You have to go to a store and buy a physical card with the eSIM QR code printed on it. Instant online-delivery? Naw, that's too hard. (I opted for an eSIM with my iPad Pro.)
Can QR codes for eSIMs be sold like traditional SIMs? I haven't actually gone through the eSIM registration process, but I assumed this should be possible.
doubt they'd support that. it's surely technically possible, but apple & the carriers like to gatekeep the eSIM provisioning process to make you reveal your identity.
This prevents my day 1 purchase as well. My US carrier (Verizon Prepaid) doesn't support eSIM yet, and I don't want a postpaid plan. I see absolutely no reason removing the SIM slot at this time is in customers' interests.
Getting a model from Canada is an option, but those don't support mmWave 5G, and I'm often in areas where I'd actually use it.
Right before checking HN, I'd spent a few hours thinking about how to approach this very problem!
Where are you fetching or how are you determining the track IDs for each service? Is it a simple metadata search through each API, are you using some of the reference data from Musicbrainz, or is there another good source of these relationships available?
The Echo Nest used to have a great open-access API for cross-referencing track IDs called Rosetta Stone. Unfortunately, Spotify discontinued it a few years after acquiring The Echo Nest.
While I understand why the streaming platforms might think it's in their interests to make cross-service track relationships difficult to determine, I'm disappointed that Spotify shut down a useful service that really helped music lovers. From some brief searching earlier today, it looks like no one has taken up the mantle yet.
