Windows 10 telemetry and whatnot can all be turned off. It's still the desktop OS it always was, just with some extra crapola (Cortana) that iOS millennials expect. At least Windows isn't sending a hash of every file I open to their servers like Apple is...
I have a computer science degree, and have gone through periods where I've maintained custom Linux distros built from scratch for myself. I'm not able to keep up with all of the newly discovered (and subsequently disabled) methods for disabling all of the online services in windows 10.
I didn't mention OSX because I didn't want to be overly verbose but yeah any non-free OS at this point has pretty much no respect at all for privacy or user freedom.
I have a master degree in CS. There's really not much of a learning curve to disabling telemetry on Windows or OSX. It requires some labor, but so does any kind of technological upkeep.
It is a hash of executables, not files. It does include shell scripts.
The intent seems to be malware prevention, but yes, the implementation is terrible from a privacy perspective. Far better would be a local bloom filter or similar.
But the bit about Windows being more respectful of privacy is not correct, or at least substantially more complicated. For instance, if you run 'full' telemetry, Microsoft can, in fact, pull your documents from your machine and execute things on it remotely, something I've seen no indication Apple does.
It's more that a lot of people seem to have zero mental model about how the file system in their computer works (files, folders, paths, ...). Let alone their computer as a whole.
More accurately: do not store your data in a proprietary format. The issue isn't that the app stopped working, the issue is that the app changed from a single-purchase to a subscription model, and the last version of the single-purchase app is no longer supported.
If the data was freely accessible, you could at least pull it out and migrate to an app with a more user-friendly business model.
Based on the image at the end of the page, it looks like the app does allow you to export the data in a non-propriety format. The problem was that the app couldn't launch, so the author couldn't export the data.
There are reports that iOS 14.5 changed some sort of signature system, requiring people that first installed certain apps from long enough ago to redownload the app from the App Store. Chances are that if you delete and redownload Momento Classic from your current iPhone it’ll “just work.”
This is a nasty problem that has been around for decades: Data storage rot.
Here's a rather embarrasing example of data storage rot[0].
> Don't do that, that'll delete all the data as well.
Not necessarily, but it depends on the app.
I use the User Defaults dictionary all the time, for things like operational prefs. I even have an SPM module that I wrote for it[1]. User Defaults gets deleted with the app, unless you do some hacking to sync it somewhere else.
I think that storing as an app file may also get deleted when the app is deleted.
We're not supposed to use that for persistent data, though. Apple provides Core Data for that kind of thing (a mixed bag). Even that needs to be done correctly, like storing using iCloud (Disclaimer: I have not chosen to use Core Data for my apps, so I can't speak to it authoritatively).
keychain persists, user defaults won't, if you store files in the documents directory it will persist if offloading the application. CoreData will NOT afaik, unless you choose to define where it persists. I'd also say that CoreData isn't exactly only meant for persisting data either - it can do that, but first and foremost it is an object graph.
more fun facts: user defaults has a limit to how big it can be. And I also think that your library would benefit from using actual types instead of Any, you can actually define this so long as the value is Codable, generics would make the library nicer to work with instead of requiring the dev to cast the type themselves. You basically just switch out Any for a generic and have the Generic conform to Codable. If targeting an iOS version that is 14+ I would just recommend using the AppStorage or SceneStorage property wrappers.
Hey, thanks for that! I can probably require Codable (even though it has been around for a while, I've only been using Codable a few months).
I'll probably do that. I started it years ago, so it has a lot of legacy. I will probably do a refactor, when I come up for air. A couple of my libs could use a facelift.
Thank you, this saved my day!!! I had very similar problems with MiniHack app on my older iPhone, that it stopped working after iOS 14.5 upgrade, but which still worked on a newer iPhone.
Offloading and reinstalling the app fixed the problem!
Apple's been automatically updating apps with these new signatures by themselves. You'll see changelogs with the following "This app has been updated by Apple to use the latest signing certificate."
I believe this is the case of an app that has been removed from the App Store though, which will receive no such support.
Yep. I received that in an email from Apple couple months ago for an old app I have on the store and since it had been working just fine for 3 years, I hadn't updated it. I decided to update it just in case the new signature would break something.
Must have to do with Apple's change over time that you no longer submit the installable app to them for review, but an intermediate package with code and assets for multiple CPU architectures and screen resolutions; that means they can do the final packaging before installation. Smart.
I'm not a published app developer, but even if I don't trust Apple hundreds of millions of users do. If I wanted to market to those users, or if I worked for a company that wanted to, I would have to suck it up and deal with Apple and their platform in order to reach the users.
Also, trustworthy people do not ask you to trust them.
I am honest and trustworthy, and so if you gave me the pin to your debit card to go buy something for you, I would not mis-use that information.
But because I am honest, I would never ask you to trust me with your pin. If we were standing next to each other at a pos, I actively look away when you start to type so I don't even find it out by innocent accident.
Honest people take the trouble to figure out some way to get a job done without requiring you to trust them, even if you would have, even if it's less convenient for you both.
In fact, I think that one thing is probably the single biggest proof of trustworthiness.
A person or organization that I've never met before and and does not ask me to trust them, is more trustworthy than one that I've known for years and have a long history of good interactions with.
Apple could publish a builder binary with which you could verify that your submitted code gets compiled+linked+thinned into the same thing you get from the App Store (minus the signature.)
They haven't — which is bad — but they could, and that would be a guarantee. Same as you get with reproducible binary packages in Debian.
And I would agree it should be outrageous and intolerable.
I wonder if there might be some way for a developer to post their own hashes somewhere, but then there's no good way for an end user to use them to verify their phone.
You could post a web page that reports that Apple has not modified the contents of your app, or a site could do that for many apps, by downloading the Apple-repacked app and checking it, but you could only check the copy of the app that the site downloaded.
It would not prove that Apple didn't modify the individual copy of the app residing on anyones phone.
I don't know the details of ios userspace, but I extremely doubt it's possible for the browser or any other app to read some other apps files and uload them to a site to have them checked. So you couldn't make a 3rd party site that says "check my phone".
Maybe such a report could be made by reading the app out of an unencrypted backup?
I mean, since Apple controls the entire OS there is already no guarantee that the code that gets installed is the code that gets executed. In other words, you already had that problem. (Of having to trust Apple in the first place.)
How is this different than when Google wants to do this? Because as far as I remember the consensus when the topic was last posted on HN was pretty clear that this was Google doing Bad Evil Things (as you have no guarantee that the code you submit is the code published).
On iOS, the security model has always been Apple signs the code, and no cryptographic protection from Apple modifying it.
On Android, the original security model was that the developer signs the code, preventing a distributor from modifying it (as long as the signature checks are sound).
Apple's system is worthy of complaining about, but you can only bring it up so often. Google taking Android backwards in this regard is worth making a fuss over; but Google is likely to just steamroll through.
I just checked the App Store for the first time since that update. The version number and release date remain the same. The only visible change is the new release text prepended with:
> This app has been updated by Apple to use the latest Apple signing certificate.
Essentially, yes. I subscribed to Setapp as soon as I realized they have several apps I already had individual subscriptions for (like Ulysses), and Setapp is cheaper. I’m a happy customer.
Yes, and for the value of the software it is well worth it! I had paid for several apps standalone, and I now get them through Setapp (including updates) and pay far less!
To be honest, this is another reason I moved away from Apple back to a Google Pixel running CalyxOS. I'm choosing to only install banking apps from Aurora and everything else is coming straight from fdroid. A massive thank you to Calyx and also to all the fdroid developers for making my life more simple and privacy focused.
OTOH it is the reason I moved to iOS. Privacy is important, but so is having full access to your own data. You don’t get that on Android these days without rooting - adb backup barely works and more than half of apps opt out
This is exactly why I have become increasingly wary of any new app to store any kind of long-term data in. The fact that an OS update breaks an app and the developer is unwilling or unable to fix it is unacceptable in my book.
I had a very similar problems with MiniHack app on my older iPhone, that it stopped working after iOS 14.5 upgrade, but which still worked on a newer iPhone 11 that also runs 14.5.
Came to these comments specifically to find a reason for that (reinstalling an app was not an option because I think the app no longer is visible in the App Store).
Thanks to @xuki, I tried offloading and reinstalling the app, and it fixed the problem!
The developer had already released a new version of the app that is compatible with iOS 14.5, the problem was the user was using a very old version from 2014. Expecting a 7-year old build of an app to continue to work on a modern version of iOS isn't really realistic, especially considering how often iOS introduces breaking changes.
I use 30 and 40 year old software all the time, and more importantly, the data from 30 and 40 year old software all the time, with no problem at all.
There is no compatibility or obsolescence problem with ios, ios apps, or most importantly the data in ios apps, that is not artificially created by people who benefit from such problems.
Expecting a 7 year old build of anything to still work is entirely "realistic".
55 comments
[ 4.6 ms ] story [ 130 ms ] threadI didn't mention OSX because I didn't want to be overly verbose but yeah any non-free OS at this point has pretty much no respect at all for privacy or user freedom.
Wait, what is Apple doing? Which Apple OS is sending a hash of every file that is opened? And can this be disabled?
The intent seems to be malware prevention, but yes, the implementation is terrible from a privacy perspective. Far better would be a local bloom filter or similar.
But the bit about Windows being more respectful of privacy is not correct, or at least substantially more complicated. For instance, if you run 'full' telemetry, Microsoft can, in fact, pull your documents from your machine and execute things on it remotely, something I've seen no indication Apple does.
https://answers.microsoft.com/en-us/insider/forum/insider_wi...
If the data was freely accessible, you could at least pull it out and migrate to an app with a more user-friendly business model.
Here's a rather embarrasing example of data storage rot[0].
> Don't do that, that'll delete all the data as well.
Not necessarily, but it depends on the app.
I use the User Defaults dictionary all the time, for things like operational prefs. I even have an SPM module that I wrote for it[1]. User Defaults gets deleted with the app, unless you do some hacking to sync it somewhere else.
I think that storing as an app file may also get deleted when the app is deleted.
We're not supposed to use that for persistent data, though. Apple provides Core Data for that kind of thing (a mixed bag). Even that needs to be done correctly, like storing using iCloud (Disclaimer: I have not chosen to use Core Data for my apps, so I can't speak to it authoritatively).
Or you could do what I do: Use a server.
[0] https://www.theguardian.com/uk/2002/mar/03/research.elearnin...
[1] https://riftvalleysoftware.com/work/open-source-projects/#RV...
more fun facts: user defaults has a limit to how big it can be. And I also think that your library would benefit from using actual types instead of Any, you can actually define this so long as the value is Codable, generics would make the library nicer to work with instead of requiring the dev to cast the type themselves. You basically just switch out Any for a generic and have the Generic conform to Codable. If targeting an iOS version that is 14+ I would just recommend using the AppStorage or SceneStorage property wrappers.
I'll probably do that. I started it years ago, so it has a lot of legacy. I will probably do a refactor, when I come up for air. A couple of my libs could use a facelift.
Offloading and reinstalling the app fixed the problem!
I believe this is the case of an app that has been removed from the App Store though, which will receive no such support.
Link for those curious:
https://www.macrumors.com/2021/04/16/psa-apple-updating-old-...
Also, trustworthy people do not ask you to trust them.
I am honest and trustworthy, and so if you gave me the pin to your debit card to go buy something for you, I would not mis-use that information.
But because I am honest, I would never ask you to trust me with your pin. If we were standing next to each other at a pos, I actively look away when you start to type so I don't even find it out by innocent accident.
Honest people take the trouble to figure out some way to get a job done without requiring you to trust them, even if you would have, even if it's less convenient for you both.
In fact, I think that one thing is probably the single biggest proof of trustworthiness.
A person or organization that I've never met before and and does not ask me to trust them, is more trustworthy than one that I've known for years and have a long history of good interactions with.
They haven't — which is bad — but they could, and that would be a guarantee. Same as you get with reproducible binary packages in Debian.
And I would agree it should be outrageous and intolerable.
I wonder if there might be some way for a developer to post their own hashes somewhere, but then there's no good way for an end user to use them to verify their phone.
You could post a web page that reports that Apple has not modified the contents of your app, or a site could do that for many apps, by downloading the Apple-repacked app and checking it, but you could only check the copy of the app that the site downloaded.
It would not prove that Apple didn't modify the individual copy of the app residing on anyones phone.
I don't know the details of ios userspace, but I extremely doubt it's possible for the browser or any other app to read some other apps files and uload them to a site to have them checked. So you couldn't make a 3rd party site that says "check my phone".
Maybe such a report could be made by reading the app out of an unencrypted backup?
Twitter, JSON/ATOM/RSS feeds, apps in privately hosted F-Droid compatible repos...etc
On Android, the original security model was that the developer signs the code, preventing a distributor from modifying it (as long as the signature checks are sound).
Apple's system is worthy of complaining about, but you can only bring it up so often. Google taking Android backwards in this regard is worth making a fuss over; but Google is likely to just steamroll through.
https://stackoverflow.com/questions/67067587/app-store-app-n...
I just checked the App Store for the first time since that update. The version number and release date remain the same. The only visible change is the new release text prepended with:
> This app has been updated by Apple to use the latest Apple signing certificate.
https://tidbits.com/uploads/2021/05/Setapp-sqlite-640x469.jp...
It's great!
Interesting calyx recommendation, although I personally want my data harvested(to serve me). I suppose this is the Android benefit of Choice.
It's a video about the efforts to preserve an old iOS App that had been broken by new updates and removed from the app store
Came to these comments specifically to find a reason for that (reinstalling an app was not an option because I think the app no longer is visible in the App Store).
Thanks to @xuki, I tried offloading and reinstalling the app, and it fixed the problem!
There is no compatibility or obsolescence problem with ios, ios apps, or most importantly the data in ios apps, that is not artificially created by people who benefit from such problems.
Expecting a 7 year old build of anything to still work is entirely "realistic".
As an application user, I want to start a career as a software engineer, so that I may save my data from a deliberately crippled application.