This really should be escalated to the point where Apple engineers build a one-off / custom iOS so that this person can unlock their phone and change their passcode. I'm sure this is in the realm of possibilities. It is such a bad look.
That seems very unlikely if only because Apple probably has the equivalent of big flashing nuclear stockpile grade warning signs internally around anything that involves the phrase "one off firmware release", since they have every interest in convincing any nation-state or anyone else that it would be quite difficult and something they have no interest in to do if they ever try to compel them to make one.
The VM limitation is only for macOS guests, otherwise I can spin up as many VMs as I like, which is no different to doing so in Linux (since it cannot run macOS VMs).
We send the messages in notifications. So the OS can keep them. Turns out Apple was doing that. There is an option you can turn on to prevent that. It is off by default.
At least on my iPhone the default is to preview messages only when unlocked [0]. This user went out of their way to show previews in a locked state which meant it was vulnerable by digital acquisition without unlock code.
“We learned that specifically on iPhones, if one’s settings in the Signal app allow for message notifications and previews to show up on the lock screen, [then] the iPhone will internally store those notifications/message previews in the internal memory of the device,” a supporter of the defendants who was taking notes during the trial told 404 Media
Doesn't indicate this is an issue when you have it set to preview when unlocked.
So I wonder about this. The quote from the 404 media article [0] is:
“We learned that specifically on iPhones, if one’s settings in the Signal app allow for message notifications and previews to show up on the lock screen, [then] the iPhone will internally store those notifications/message previews in the internal memory of the device,” a supporter of the defendants who was taking notes during the trial told 404 Media
The default setting appears to be to only show notification preview when unlocked. Will that notification still be stored unencrypted in notification storage or is it in an encrypted store because it will preview after unlock?
It makes sense that any notification that previews on the lock screen would be unencrypted (including the case where it is encrypted but the encryption key is adjacently stored).
This all reads to me that this was a user induced OPSEC issue and Signal had the right defaults.
I think that’s a little nutty. People go to signal for secure messaging. That’s their entire brand. An insecure by default setting is the wrong setting, even if it nets them a lot of tech illiterate users. Compromising the security of the system defeats the entire point of using Signal instead of some other messenger.
By this logic, you, me, and everyone else using the defaults are using bad opsec. Doesn’t that strike you as problematic?
I posted this elsewhere and I said this in my post, but the default setting is actually not the insecure one: https://files.catbox.moe/3gwjoy.png (supposing that previews are stored encrypted when locked which is what the 404media passage implies and nothing to say to the contrary).
This user went out of their way to show previews on the lock screen, that is an OPSEC failure, even if you do not consider the acquisition of the messages digitally.
"Security" is not a binary, but a spectrum along which there are various tradeoffs. The vendor attempts to select the best configuration for its average/median user, and that's almost by definition not going to be the most secure configuration (see: tradeoffs).
I do think there should be some UI somewhere that allows for locking all things down to the most secure configuration possible.
This article that "begs to differ" is inventing IPv6 all over again. It just refuses to call itself so.
I quote from the top comment:
>So you have to ship new code to every 'network element' to support IPv4x. Just like with IPv6.
and
>So you have to update DNS to create new resource record types [...] Just like with IPv6.
and
>You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6.
The key difference, you don't do dual stack, you can incrementally roll it out and get tangible relief, unlike IPv6.
The point is less about the technology proposed, but the point that there could be an interoperable version of a next generation IP and IPv4.
IPv6 did the braindead thing and completely threw out the idea of transition and interoperability for a clean slate. We're paying for it many decades later.
Also, rather than regurgitate a comment, perhaps you should read the article, because that comment misunderstands what is being proposed and thus completely missing the point.
Why are you still trying to claim this? v6 has transition methods and ways to interoperate coming out of its wazoo. It does pretty much everything you can do to work with v4. Nobody threw out the idea of transitioning.
> but the point that there could be an interoperable version of a next generation IP and IPv4
Yes, it's IPv6. The thing you linked basically took one of the interoperability methods of v6 and described it in weird terms.
You don't do dual stack with v6 either, unless you want to -- you can do the incremental rollout and tangible relief thing with v6 just fine. (But it turns out most people do want to do dual stack.)
Is this some kind of attempt at gaslighting? If IPv6 gave tangible relief, then IPv4 today would not be an important mainstay of the Internet. I recommend you read the article I posted, and see how different things could have been, and how completely botched IPv6 rollout has become, that it is just not taken seriously except by some die hard cultists and mobile/telco (which can be done because they pretty much get full configuration of your networking stack).
I guarantee, we will be having this same exact discussion 10 years from now. And then so on, and so on.
Nope, not at all. Everything I said is true. v6 supports deploying in the way described in that article, and you can do it today if you want.
If you don't want to deploy v6 like that, consider why -- because the people who live in the world described by that article will also have the same reasons as you to not deploy it that way.
> If IPv6 gave tangible relief, then IPv4 today would not be an important mainstay of the Internet
No, that argument doesn't hold. v6 can give tangible relief even while v4 is an important mainstay of the Internet. You only have to listen to the people doing CGNAT, or the people turning on v6-mostly and seeing their v4 address use drop by 75% to hear examples of that.
Deployments of v6 reduce the pressure on v4, because they allow us to deploy new networks without needing v4 and because migrating existing networks frees up v4 that can be repurposed. This is also a benefit that's making v4 more viable that it would be without v6.
Plus you're making assumptions about the time needed to replace the Internet's L3 protocol. It's nice to fantasize about finishing it in 10 years, but that doesn't mean that finishing it in 10 years is realistically possible. Deployment of v6 is ongoing and v4's importance is dropping over time; you can't know what the ultimate impact of v6 will be until we're finished deploying it.
There was always going to be a long tail of v4-only hosts, no matter what we did. That's why v6 has a large number of compatibility methods for dealing with them (yes, including the method described in the linked article). It wouldn't be possible to deploy it at all if it didn't.
Is that even a rebuttal? Seems like just a dismissal without any substance. I expect in 10 years the predictions will be wrong, kind of like Y2K all over again.
I think that /dev/u?random being implemented by Fortuna is actually incorrect, and the macOS manpages are wrong. My understanding is that it is using a NIST DRBG, there's a Craig Federighi tweet somewhere confirming this.
reply