Oliver Reichenstein (Mastodon, Hacker News):
A couple of months ago, Google changed its API policy and revoked iA Writer’s access to Google Drive on Android. By freezing up Android’s main storage option, our app was frozen in carbonite. It still lived but we couldn’t move forward before resolving it.
In order to allow our users to access their Google Drive on their phones we had to rewrite privacy statements, update documents, and pass a series of security checks, all while facing a barrage of new, ever-shifting requirements.
[…]
The cost, including all internal hours, amounts to about one to two months of revenue that we would have to pay to one of Google’s corporate amigos. An indie company handing over a month’s worth of revenue to a “Big Four” firm like KPMG for a pretty much meaningless scan. And, of course, this would be a recurring annual expense. More cash for Google’s partners, while small developers like us foot the bill for Android’s deeply ingrained security shortcomings.
[…]
So, as of today, we’re not just accepting our frozen-in-carbonite fate. We’re embracing it. We’re going to take the app offline. We know this decision will disappoint our loyal Android users, and we share your frustration. After seven years of continuous investment, this is way more painful for us than it is for any of you.
With ForkLift, this problem seemed to apply to all platforms, yet iA is framing it as an Android issue rather than a Google Drive issue. Is this because Google Drive is less prevalent on the other platforms, so that removing it isn’t fatal, or because they can get by indirectly accessing Google Drive via the a file provider or the file system directly?
mgraczyk:
I just finished the process to get drive.readonly for my app. It was a huge pain in the ass, and Google was not very helpful. Google recommends you pay $720 for a CASA lab assessment, which consists of some random dude in an apartment in SF running an open source script against a .zip of your codebase, then that guy emails Google saying you “passed”.
Oliver Reichenstein:
CASA isn’t real security. It’s a very badly played security theater. There are plenty of holes, MI CASA SU CASA, that real hackers can use to steal your selfies and credit card info. You still think we’re not informed enough? We never wanted access to Google Drive. We don’t care about your Google Drive or anyone’s Drive at all.
We don’t have, want, or ever asked for access to your files. And don’t start with, “But you could be hackers!” We’re not. Google has our entire history—7 years with them, 14 years building apps, and 20 years as a company. They have our code, user feedback, passports, phone numbers, bank info, and confidential documents. But they still pass the security theatre burden onto us, making us pay KPMG for audits. Not because it makes things safer. It's so they can lean back, do nothing, and then lift both hands and then point fingers in case things go wrong. That scales nicely.
Previously:
Android Android App Google Drive iA Writer iOS iOS 18 iOS App Sunset
Fatbobman:
However, in SwiftData, there is currently no similar property or method to directly determine the [temporary] state of a PersistentIdentifier. Since SwiftData’s mainContext defaults to the autoSave feature (developers do not need to explicitly save data), identifiers may temporarily be unusable in other contexts after creating data objects.
[…]
SwiftData’s default implementation is still based on Core Data, so the format of PersistentIdentifier is very similar to that of NSManagedObjectID[…]
You can see this when printing it, but crucially there is still no API to convert between the two types.
Starting with Xcode 16, the Core Data framework has officially annotated [NSManagedObjectID as Sendable], so developers no longer need to do it manually.
It’s interesting that it took so long since NSManagedObjectID has always been threadsafe outside of Swift Concurrency.
Although an NSManagedObjectID instance contains sufficient information to indicate the data post-persistence, it cannot retrieve the corresponding data when used with another NSPersistentStoreCoordinator instance, even if the same database file is used. In other words, an NSManagedObjectID instance cannot be used across coordinators.
This is because the NSManagedObjectID instance also includes private properties of the corresponding NSPersistentStore instance.
I kind of look at it backwards from this. The NSManagedObjectID doesn’t contain very much information—it’s often squeezed into a tagged pointer. How is this possible when it logically contains a reference to the entity description and the persistent store, in addition to the primary key? I assume that it’s storing abbreviations for these, which can only be interpreted with respect to a coordinator.
Previously:
Core Data iOS iOS 18 Mac macOS 15 Sequoia Programming Swift Concurrency SwiftData
Mike Masnick:
Among the key reasons Elon Musk insisted he had to buy Twitter were (1) that it was too political in how it was managed and how content moderation was done, (2) the company was not as transparent as it should be, and (3) it was too quick to censor.
[…]
We can only confirm how much more willing to censor he is because he finally released a transparency report. Twitter had been among the first internet companies to regularly release transparency reports, talking about content moderation, copyright takedown demands, and (of course) government demands for both information and content/account removals. Every six months, like clockwork, Twitter would publish detailed, thorough transparency reports.
[…]
As I’ve said, in both those cases, I think it was good that he was willing to stand up to over-aggressive government demands. But it’s hard to see it as any strong commitment to free speech when he’s so quick to comply elsewhere. Indeed, he’s already backed down in Brazil, to much less fanfare.
Separately and importantly, Elon has been way more willing to hand over user data to governments upon request. This was another thing that old Twitter was aggressive in fighting back against, but Elon seems quite willing to roll over on.
Twitter under Musk is certainly censoring differently. People who were banned have been unbanned and vice-versa. The misleading information policy has changed. Maybe there is more variety of content than before, but it does not really seem to be following the principles that Musk laid out at the acquisition.
Elizabeth Lopatto (Hacker News):
X is preventing users from posting links to a newsletter containing a hacked document that’s alleged to be the Trump campaign’s research into vice presidential candidate JD Vance. The journalist who wrote the newsletter, Ken Klippenstein, has been suspended from the platform. Searches for posts containing a link to the newsletter turn up nothing.
The document allegedly comes from an Iranian hack of the Trump campaign. Though other news outlets have received information from the hack, they declined to publish.
Ken Klippenstein (via Hacker News):
First, I never published any private information on X. I linked to an article I wrote here, linking to a document of controversial provenance, one that I didn’t want to alter for that very reason.
The dossier did violate Twitter’s policy because it contained unredacted personal information, but that does not explain why links to the article were blocked. Musk is on record that Old Twitter should not have blocked links to the leaked Hunter Biden information, which was more personal and damaging. From what I’ve seen, the Vance dossier itself is far less interesting. The most notable aspects are its source (Iran) and the fact that Twitter wants to suppress it.
And, as far as I know, Twitter is still messing with Substack links.
Mike Masnick:
Another user on Twitter notes that their own account was temporarily suspended not even for tweeting out a link to the Vance dossier story, but for tweeting a link to Ken’s post about getting suspended!
Previously:
Elon Musk Substack The Media Twitter URL Web
Gerald Lynch:
After more than 15 years covering everything Apple, it’s with a heavy heart I announce that we will no longer be publishing new content on iMore.
[…]
I would like to take this moment to thank everyone from the iMore community, past and present, for their support and passion for what we’ve created over the years. A massive thanks goes to iMore’s previous leaders, Lory Gil, Serenity Caldwell, and Joe Keller, and of course, the inimitable Rene Ritchie who kickstarted this wonder all those years back.
[…]
iMore will stay online so readers can continue to access articles from the archive, and the forum at https://forums.imore.com/ will remain active until November 1 to serve our community. Our sister sites TechRadar.com and TomsGuide.com will also continue to publish all the latest news, reviews, and more from the world of Apple-based computing, while our buddies at WindowsCentral.com and AndroidCentral.com have the privilege of continuing to serve you class-leading news, reviews and features from the other side of the tech fence, keeping you up to date with the latest from Microsoft and Google.
Joe Rossignol:
The website that eventually became iMore has operated under various names for over 17 years. The site originally launched as PhoneDifferent.com in 2007, merged with and took the name of TheiPhoneBlog.com in 2008, and abbreviated its domain name to TiPb.com in 2010. In 2012, the website rebranded as iMore.
iMore has been home to a number of well-known technology journalists over the years, including Dieter Bohn, Rene Ritchie, Serenity Caldwell, and many others. Bohn went on to become a founding member of The Verge in 2011, and he now works at Google. Ritchie left iMore in 2020 after 12 years at the website, and he now works for YouTube. Caldwell worked for iMore between 2014 and 2018, and she now works at Apple.
Previously:
Sunset The Media Web
