WEBVTT

00:00.000 --> 00:04.540
Apple was leaking DNS queries and doing some funky stuff that was found by

00:04.540 --> 00:08.300
people who run privacy projects, specifically the MISC developers who run the

00:08.300 --> 00:13.080
silo browser disclosed this issue in August of 2026 after they investigated

00:13.080 --> 00:15.720
some DNS leaks from a silo user.

00:15.880 --> 00:19.360
This pretty much made it possible in some situations for your IP address while

00:19.360 --> 00:21.300
being connected through private relay to be exposed.

00:21.720 --> 00:25.660
What MISC really wanted to highlight here was that Apple's just not very

00:25.660 --> 00:28.180
transparent. A lot of people have been complaining about the way they

00:28.180 --> 00:32.120
handle disclosure and MISC's point is that yeah, Apple fixed it,

00:32.120 --> 00:35.720
but it wasn't in the beta and Apple security release notes made no

00:35.720 --> 00:39.760
mention of this. So this was a quiet Apple fix with absolutely no

00:39.760 --> 00:43.660
acknowledgement of the feature, which I find a bit reckless given Apple,

00:43.840 --> 00:46.900
you know, when you have lockdown mode, when you sell yourself on privacy

00:46.900 --> 00:50.200
and security, which again, Apple does some things that I really do

00:50.200 --> 00:54.320
appreciate, but if you have people whose lives and their safety depend on

00:54.320 --> 00:58.540
these tools and they quietly fix it without communicating what they did

00:58.540 --> 01:01.640
and what went wrong, that's a huge knock on trust for Apple.

01:01.780 --> 01:04.960
And so I think it is a mistake long-term for Apple to not be a bit

01:04.960 --> 01:08.000
more transparent about why it went wrong and how that's not going to

01:08.000 --> 01:10.900
happen going forward. Cause how are they going to rebuild people's trust

01:10.900 --> 01:13.560
in this feature? They haven't really done that in my view.