Archive for May 10, 2023

Wednesday, May 10, 2023

Deleting Inactive Twitter Accounts

Elon Musk (via John Scott-Railton):

We’re purging accounts that have had no activity at all for several years, so you will probably see follower count drop.

John Carmack:

I may be reading this incorrectly, but if you are actually deleting inactive accounts and all their historic tweets, I would STRONGLY urge you to reconsider.

Letting people know how many “active” followers they have is good information, but deleting the output of inactive accounts would be terrible. I still see people liking ten year old tweets I made, but the threads are already often fragmented with deleted or unavailable tweets. Don’t make it worse!

Some may scoff at any allusion between Twitter and ancient libraries, but while the burning of the library of Alexandria was a tragedy, scrolls and books that were tossed in the trash just because nobody wanted to keep them are kind of worse.

Save it all!

I did not appreciate how excited many people are about freeing up old usernames. That doesn’t change the point about preserving the old tweets — maybe rename the old account to include the year of creation.

However, tossing old names back into the free pool just starts another land grab. People camping on hundreds of freely claimed usernames has always been one of the scummier aspects of the internet.


There’s also the issue of people who have died and their accounts have been turned into a kind of memorial, not only would deleting them be devastating to their loved ones it would also allow people to impersonate the dead person…

There was also a story about this in 2019, the Internet Archive offered to step in, and then Twitter backtracked.


Update (2023-05-24): James Vincent (via John Gruber):

Earlier this year on the 8th of May I deleted all my tweets, just under 5,000 of them. I know the exact day because I tweeted about it.

This morning, though, I discovered that Twitter has restored a handful of my old re-tweets; interactions I know I scrubbed from my profile. Those re-tweets were gone. I remember surveying my bare timeline with satisfaction before thinking, “great, time to draw attention to myself.” But now they’re back.

App Translocation in Ventura

Howard Oakley:

Most recently, Quinn “The Eskimo!” of Apple’s Developer Technical Support has explained: “The exact circumstances where the system translocates an app is not documented and has changed over time.”


Surprisingly, the third condition, of not moving the app or the folder it’s enclosed in, is no longer required for App Translocation to occur. In testing both within a VM and a regular Ventura system, translocation frequently occurs on quarantined apps even after they have been moved to the main Applications folder. It’s not entirely consistent, though: one app downloaded from the internet didn’t undergo translocation, while two others did, so there appears to be a random element involved.

The first condition also failed: apps that had successfully cleared quarantine underwent translocation repeatedly, even though they were being run from the Applications folder and the quarantine flag had been cleared.

You want to avoid translocation because, even if all your app’s resources are within its bundle, it will interfere with automatic updates. The app is mounted on a read-only volume, and “there is no supported way to determine the original (untranslocated) path.” You can avoid these problems by distributing your app in a disk image instead of in a ZIP archive. Apple says:

To provide secure execution, code sign your disk image itself using the codesign tool, or distribute your app through the Mac App Store.

DropDMG can also help with this.


Update (2024-05-16): Howard Oakley:

One shortcoming is that Apple’s user documentation doesn’t seem to mention this anywhere, such as in its latest account of Gatekeeper. Even its Platform Security Guide only mentions it in passing: “When necessary, Gatekeeper opens apps from randomized, read-only locations. This is designed to prevent the automatic loading of plug-ins distributed alongside the app.” The only explanation provided for developers is in these notes in Apple’s Developer Forums, where we’re told that “the exact circumstances where the system translocates an app is not documented and has changed over time.”

This article attempts to explain how App Translocation or GRP work as of macOS 14.4.1 Sonoma.

Update (2024-05-17): Howard Oakley:

Although macOS has been happily translocating apps since Sierra, nearly eight years ago, the process can still bring problems, particularly when an app appears to have cleared quarantine, and is run not infrequently. Any problems that can cause might appear odd: it may be slow to launch, never update, not work properly with software firewalls, and can even be unstable and crash. So how can you tell whether an app is running in translocation?

Code Signing Translocation Vulnerability

OccamSec (in 2021):

It is far easier, however, to break the codesigning system and sign your binary as an Apple binary. But let’s get this straight: even though the machine will be aware that the LC_CODE_SIGNATURE LoadCommand is tainted, it will still execute.


The result is that we can perform arbitrary memory read and write using the Mach virtual memory APIs and inject code into system processes.


As of Friday, July 16th (perhaps earlier, with the release of Big Sur 11.4), it seems Apple issued a stealth patch against this exploit, without notifying us. Code signatures no longer show up via codesign or other tools, though the kernel is still able to recognize the “detached code signature”, as seen above. It seems that the code signature format may have changed; given tools such as “Apparency” say the code signature is in an invalid format; alongside my script + classic dd + otool -l refuse to spit out a valid code signature. As for why Apple has been so silent on the communications side of things, we don’t know.


This band-aid patch essentially makes it possible for malware to hide a phony code signature, and does nothing on the kernel side to mitigate the vulnerability.

Note that the post refers to this as “codesigning translocation,” but this is completely separate from App Translocation, though that is also related to code signing.


Dolby v. Adobe

Karl Bode (in 2019, via Daniel J. Wilson, Hacker News):

Adobe this week began sending some users of its Lightroom Classic, Photoshop, Premiere, Animate, and Media Director programs a letter warning them that they were no longer legally authorized to use the software they may have thought they owned.


“We have recently discontinued certain older versions of Creative Cloud applications and and a result, under the terms of our agreement, you are no longer licensed to use them,” Adobe said in the email. “Please be aware that should you continue to use the discontinued version(s), you may be at risk of potential claims of infringement by third parties.”

William Gallagher:

While Adobe has not said who the dispute is with, the company is presently being sued by Dolby. Through a legal complaint filed in March 2019 with the US District Court and the Northern District of California, Dolby is seeking a jury trial over issues of “copyright infringement and breach of contract” against Adobe.

Prior to the creation of the Creative Cloud subscription service, Adobe licensed certain technologies from Dolby with an agreement based on how many discs of certain apps were sold. Now that the software is distributed online, the companies reportedly renegotiated their agreement to be based on how many users are actually running the software.

Jonathan Bailey:

In 2012 Adobe decided to largely ditch the model of selling units of software for a subscription model it dubbed the Creative Cloud.


However, it also produced a problem for one of Adobe’s partners, Dolby. Starting in 2002, Dolby provided audio technology to Adobe to be used in its software for both encoding and decoding audio. However, the licensing fee was based on sales figures, something that became much more difficult to calculate with the move to a subscription model.


According to Dolby’s lawsuit, in September 2017, the company announced it was exercising its audit rights for the 2015-2017 period. However, they claim that Adobe failed to provide the needed information, just as they had done for the 2012-2014 period.

Dolby also claims that Adobe improperly consolidated multiple software products when paying royalties. For example, offering a bundle that had four apps with Dolby software, but only paying for one use. Other issues included problems with site licenses, multiple sales to a single customer and so forth.

Karl Bode:

Gilbert noted that consumers now live in a world in which consumers almost never actually own anything that contains software. In this new reality, end users are forced to agree to “take it or leave it” end user license agreements (EULAs), in which the licensor can change its terms of service without notice. “Even if Adobe is fully in the right here with regard to the Dolby dispute, it has the power to force its customers to upgrade to newer more expensive versions at its whim, which illustrates the undue power and influence of EULAs over the lives of consumers,” Gilbert said.

Here’s some more information about the lawsuit, which I guess is still ongoing.


Update (2023-05-11): The case was dismissed in 2020 (via Nick Heer).

Update (2023-05-19): See also: Hacker News.