> The fact that they let law enforcement know when someone is stalking someone with an AirTag shows that the data is available to them.
Not technically correct. Apple devices (and Android phones with the appropriate app) detect if an unknown AirTag is moving with them and makes it home, possibly signalling a stalking attempt.
The heuristics for this happen locally; Apple isn't "aware" of this happening. That said, when you first set-up an AirTag, the serial is tied to your account. Therefore, when you physically find an unknown AirTag and report it to law enforcement, they can then subpoena (or get a warrant?) Apple for information on the AirTag owner's identity.
The serial itself, and any personal identifiers, are not used in the locating process, however.
This is well documented in the paper above, in articles, as well as in reverse engineering efforts.
That might be what's informally called a "respring", where the SpringBoard process is restarted.
SpringBoard is the process that shows the home screen, and does part of the lifecycle management for regular user apps. (i.e. if you tap an icon, it launches the app, if you swipe it away in the app switcher, it closes the app)
It is restarted to make certain changes take effect, like the system language. In the jailbreaking days, it was also restarted to make certain tweaks take effect. Of course, it can also just crash for some reason (which is likely what is happening to you)
Hi, is there some further info on iOS "internals" like this? I was always interested in how it works, but I found much less information compared to android (which obviously makes sense given one is more or less open-source), even though these probably don't fall in the secret category.
It doesn't do the same thing security-wise, though. It's more of a "performance manager" (i.e. the same reason you'd reboot an old Windows PC).
BFU (Before First Unlock, as described in the article) on an Android is pretty similar to an iPhone (data still locked down, notifs don't come in, apps not running). Only after you unlock the first time can apps start running and notifs come in. This is also the state where it's more vulnerable to attackers (cops or criminals).
I have both an iPhone and an Android (currently a Z Fold 5, so a recent model). My Fold 5 does this auto-reboot every week. When it does reboot, my usual background apps come up, and notifs work as usual.
This means that Android (or perhaps more accurately, OneUI — Samsung's custom stuff on top of Android) is not doing a "full" reboot, and thus isn't providing the same security benefits as Apple is by putting the phone in a "BFU" or "cold" state.
Are we talking about the same thing? If I reboot manually then I don't get notifications until I enter my pin. But if my phone does the auto-reboot I do get notifs as usual.
Thanks for this! Some feedback on the images: perhaps you can "bake-in" a white background. Your diagrams are transparent PNGs, which is fine when the webpage is white, but when in dark mode it makes the images hard to read (as now we have black text and drawings against a dark background).
Wish I could find something like these but open-source. Both of them parse your browser history, fetch the pages, and build their own index. Would be a "safer" and more space/cpu-efficient alternative to apps like Windows Recall and Rewind.ai.
There's https://github.com/go-shiori/shiori?tab=readme-ov-file . It works on bookmarks and uses SQLite to enable full text search. It's also a CLI so I thibk you can write a script that parses your history file and loads it into this
I have always felt uneasy about that too. I think it’s because the next (and final) panel looks exactly like the first. It’s the implication that you’ll have to do something so over the top as getting up, raising your arms, and shouting a brand name, then resuming what you were doing as it that were completely normal.
You have to show exuberance when demonstrating your brand loyalty, otherwise you’re not loyal enough to pass the ad. You’ll need to watch the entire reeducation, I mean ad, in that case.
Yes - name and shame. Slack is INFURIATING on intermittent connectivity. That is simply not good enough for a product who's primary value is communication.
Anyone who has tried to use Slack:
- in the countryside with patchy connection
- abroad
- in China
- on the London Underground
Can attest to how poor and buggy Slack is on bad internet.
These aren't weird edgecases - London is a major tech hub. Remote workers and open source communities rely on Slack around the world.
China is the second largest economy in the world with a population of 1.7B (incidentally it's blocked at least it was when I was last there but even on VPN it was weird and buggy).
How aren't these kinds of metrics tracked by their product teams. How isn't WhatsApp the gold standard now for message delivery, replicated everywhere.
Neither email nor WhatsApp have the weird consistency issues Slack has with simply sending a message with dodgy internet. Not to mention the unreliable and sometimes user-hostile client state management when Slack can't phone home which can sometimes lead to lost work or inability to see old messages you literally were able to see until you tried to interact with stuff.
Slack additionally decides to hard-reload itself, seemingly without reason.
I work on the road (from a train / parking lot / etc) for five or six hours per week. My T-Mobile plan is grandfathered in, so I can't "upgrade" to a plan that allows full-speed tethering without considerably impacting my monthly bill.
Realistically, I hit around 1.5Mbps down. When Slack reloads itself, I have to stop _everything else_ that I'm doing, immediately, and give Slack full usage of my available bandwidth. Often times, it means taking my phone out of my pocket, and holding it up near the ceiling of the train, which (I've confirmed in Wireshark) reduces my packet loss. Even then, it takes two or three tries just to get Slack to load.
I wonder if you could stick your own root CA into your OS'S certificate store and then MitM the connections slack makes, and then respond no don't update with burpsuite and cache with squid to alleviate the problem.
Slack web downloads 40MB of Javascript. The macOS Slack client, that I guess should have all that stuff already, downloads 10MB of stuff just by starting it (and going directly to a private text only chat).
I doubt I'll ever work with a place that uses Telegram but yes its clear that resilient message delivery is a solved problem nowadays but Slack is still hopeless at the one most important key feature of its product. Now that WhatsApp also has groups there's even less of an excuse for Slack to perform so badly
You got all the same answers I did, which helps me determine how good my sleuthing skills are. I used exclusively strings, either API routes, error codes, or version/build numbers.
I've also found that the AWS and Azure consoles behave this way. While not listed in the blog post, they load JavaScript bundles in the tens of megabytes, and must have a hard-coded timeout that fails the entire load if that JavaScript hasn't been downloaded inside of a few minutes.
To Amazon's credit, my ability to load the AWS console has improved considerably in recent months, but I can't say the same for Azure.
My experience is that Slack worked great last winter, when the broadband satellite was up. When it's down, folks use an IRC-style client to cope with the very limited & expensive bandwidth from Iridium.
Not technically correct. Apple devices (and Android phones with the appropriate app) detect if an unknown AirTag is moving with them and makes it home, possibly signalling a stalking attempt.
The heuristics for this happen locally; Apple isn't "aware" of this happening. That said, when you first set-up an AirTag, the serial is tied to your account. Therefore, when you physically find an unknown AirTag and report it to law enforcement, they can then subpoena (or get a warrant?) Apple for information on the AirTag owner's identity.
The serial itself, and any personal identifiers, are not used in the locating process, however.
This is well documented in the paper above, in articles, as well as in reverse engineering efforts.