Latest / Chief in Tech Deep Dive Shortcast / Chief in Tech S1E62 - Nicole de Klein : Co-Navigating the Changes in Healthcare

Transcript

Chief in Tech S1E62 - Nicole de Klein : Co-Navigating the Changes in Healthcare · Chief in Tech Deep Dive Shortcast

0:00
So the next time you text a funny video to a
0:02
friend, you might want to look really closely
0:06
at the actual link you're sending. Oh, definitely.
0:08
People just copy and paste without a second thought.
0:10
Right, because tucked inside that completely
0:13
harmless -looking string of text is a tiny, invisible
0:17
digital die pack. A die pack that goes off the
0:20
second it's clicked. Exactly. The moment your
0:22
friend taps that link, that die pack just explodes
0:25
on the server and it quietly reports the exact
0:29
pathways of your friendships back to a centralized...
0:33
database. Yeah, I mean, it is a truly remarkable
0:36
piece of passive surveillance. And it functions
0:39
entirely in the background of our daily communications.
0:42
It's totally invisible. Completely hidden in
0:44
plain sight. Which is exactly why we're doing
0:46
this today. So welcome to the deep dive. I am
0:49
looking right at you, the listener. The learner.
0:51
The one who loves to pull on those loose threads.
0:54
Yeah, the one who loves to pull on the loose
0:55
threads of everyday life, just to see how the
0:57
whole sweater is knit together. Because usually
1:00
you send us this massive stack of source material,
1:02
right? Like research papers, dense articles,
1:05
hours of reading. A lot of heavy lifting. So
1:07
much heavy lifting. But today, today you provided
1:10
a single line of text, 43 characters. It's so
1:13
brilliantly minimal. I love it. But. When you
1:16
actually look at the mechanics behind it, it
1:19
is staggeringly dense. It's a raw URL, specifically
1:22
this one. Question mark SI equals MFP capital
1:37
Q capital Y lowercase T capital Q lowercase X
1:40
UN Q Capital H five capital E capital D that
1:44
is quite the mouthful it is and that is our entire
1:47
universe for this deep dive Okay, let's unpack
1:49
this because to actually understand this we can't
1:51
just you know read it left to write like a sentence
1:53
in a book No, not at all. We need to look at
1:56
it as a timeline We're going to follow the exact
1:58
journey of a data packet from the millisecond
2:01
your thumb taps this link on your screen. Which
2:03
is really the perfect framework for this. We
2:05
are essentially slowing time down to a crawl.
2:08
Right. Matrix style. Yeah, exactly. Because in
2:11
the half second it takes for that video to load
2:14
on your screen, this massive global infrastructure
2:17
is executing a highly choreographed sequence
2:21
of events. And it's all based strictly on the
2:24
syntax of those 43 characters. 100%. OK, so millisecond
2:27
zero. You click the link. The very first thing
2:30
your browser does is look at the protocol, the
2:33
HTTPS part. Right, the transport layer. And I
2:36
know a lot of people just think of this as the
2:38
little padlock icon in the browser bar. But what
2:41
is physically happening the moment that command
2:43
is executed? So the browser is initiating a cryptographic
2:47
handshake before it even asks for the video.
2:49
It reaches out to the destination server. And
2:52
they essentially exchange secret decoder rings.
2:54
Decoder rings, OK. This is the TLS, the Transport
2:58
Layer Security Handshake. The server presents
3:00
a digital certificate proving its identity, and
3:03
then your device and the server agree on a unique
3:06
temporary encryption key. Wait, I want to push
3:09
back on that for a second. Sure. If every single
3:12
time anyone in the world clicks a link, their
3:14
phone has to negotiate a unique encryption key,
3:17
wouldn't that massively slow down the internet?
3:20
You would think so, yeah. Because generating
3:22
complex cryptographic math takes processing power,
3:26
right? Why do it for a public video of a cat
3:28
falling off a couch? Well, if we connect this
3:30
to the bigger picture, you have to realize that
3:33
network architecture prefers uniformity over
3:35
selective security. OK, meaning what, exactly?
3:38
Meaning, yes, it takes a few extra milliseconds
3:40
of computational power to establish that TLS
3:43
handshake. But if the platform only encrypted
3:46
private messages and, say, left public videos
3:49
unencrypted, network providers or bad actors
3:52
could easily intercept the traffic. Oh, I see.
3:54
They could inject malicious code or insert their
3:57
own advertisements into the video stream before
3:59
it even reaches your phone. Ah, OK. So it's not
4:02
just about keeping the data secret. It's about
4:05
proving the data hasn't been tampered with in
4:08
transit, it's sealing the package like an armored
4:11
truck. Precisely. It's an armored truck. Once
4:14
that split second handshake is complete, every
4:16
single piece of data traveling between your phone
4:19
and the server is scrambled. Wow. If anyone intercepts
4:22
it, All they see is random noise. The secure
4:25
tunnel is officially established. Okay, so the
4:27
tunnel is open, but where exactly does the tunnel
4:29
lead? Because right after the slashes, we hit
4:32
the domain address. And this is where our artifact
4:34
gets very weird. It does get fun here. Yeah,
4:37
because the link doesn't say youtube .com, it
4:39
says youtube .be. Ah, yes. The domain hack. It
4:43
is a phenomenal piece of engineering efficiency.
4:46
It's a linguistic shortcut. They are taking the
4:49
country code top level domain for the nation
4:51
of Belgium Which is dot BEE and hijacking it
4:54
to spell out their brand name. It's very clever
4:56
But here is what I don't understand about the
4:59
physical journey of our data packet here The
5:01
domain name system the DNS is essentially the
5:04
phone book of the Internet, right? Exactly. So
5:06
when my browser reads dot BEE Does my encrypted
5:10
tunnel have to route all the way across the Atlantic
5:12
Ocean to a server in Brussels just to ask where
5:15
the video is? That is a very logical assumption,
5:17
actually. And honestly, it is how the internet
5:20
used to work in its infancy, but no. Oh, really?
5:23
Yeah, doing that today would induce terrible
5:25
latency, like unwatchable buffering. Instead,
5:28
we rely on something called Anycast routing and
5:31
local DNS caching. Walk me through that. How
5:34
does that avoid the trip to Belgium? So when
5:37
you tap the link, your phone asks your local
5:40
internet service provider to resolve U2 .b. Your
5:44
ISP doesn't fly to Belgium. It already has the
5:47
Belgian registry or as master list cached locally.
5:50
Just saved on their own servers. Exactly. Because
5:52
millions of people ask for it every minute. Oh,
5:54
right. Because everyone is clicking these compressed
5:56
links on social media all day long. Right. So
5:58
your local ISP says, uh, I know who owes that.
6:02
It's the big tech company. But instead of giving
6:04
you the IP address for a central server in California,
6:08
the Anycast network finds the physical server
6:11
closest to your geographic location. Oh, that
6:13
makes sense. Yeah. So if you are sitting in Chicago,
6:16
your request is routed to a data center in Illinois.
6:19
If you are in Tokyo, it goes to a server in Japan.
6:23
So the .be is completely decoupled from physical
6:26
geography. It's literally just a character -saving
6:29
device for platforms like Twitter that used to
6:32
have, you know, strict character limits. Yes.
6:35
They basically paid the Belgian registry for
6:38
the rights to use that specific domain name,
6:40
and then they pointed it at their global distributed
6:43
network. It saves three letters of text, which
6:46
really matters when you are trying to squeeze
6:48
a thought into a tiny social media post, and
6:51
it sacrifices absolutely zero speed. It's incredibly
6:54
resourceful. Yeah. OK, so our request has securely
6:57
crossed the internet via the closest local node,
7:00
and it has knocked on the front door of the company's
7:02
data center. Server answers the door. Right.
7:05
The server answers. Now the server needs to know
7:07
what we want, which brings us to the next part
7:09
of the URL, the core identifier. The specific
7:12
file request. Right. And here's where it gets
7:15
really interesting. Because the string pointing
7:18
to the actual video file in our source text is
7:20
eight. capital D lowercase Q lowercase G capital
7:24
B lowercase D capital J lowercase Z lowercase
7:29
E capital L 8 a very specific 11 characters yeah
7:33
11 characters a mix of uppercase letters lowercase
7:35
letters and numbers and my first thought when
7:38
looking at this was why why make it so complicated
7:41
exactly storage space on modern servers is dirt
7:43
cheap right why go through the computational
7:46
trouble of generating random upper and lowercase
7:48
gibberish when they could just use sequential
7:50
numbers in a massive database, like video one,
7:52
video two, video three? Well, because a sequential
7:54
database is a highly vulnerable database. Vulnerable
7:57
how? What you are looking at with that string
7:59
is not just an identifier. It is a 64 -dial combination
8:02
lock. This 11 -character string utilizes a base
8:06
-64 encoding system. Okay, break down the mechanics
8:09
of that for us. What does base -64 actually mean
8:12
here? So, in a standard counting system, base
8:15
-10, you only have digits 0 through 9, right?
8:17
Right. Normal numbers? If a padlock has dials
8:20
with only 10 numbers, it is relatively easy to
8:23
crack. But in base 64, every single slot in that
8:27
11 -character string has 64 possible variations.
8:31
Because it's using letters, too. Exactly. You
8:33
have 26 lowercase letters, 26 uppercase letters,
8:37
10 digits, and usually two symbols, like a dash
8:40
or an underscore. Oh, wow. So it's 64 times 64
8:43
times 64 11 times. Yes. 64 to the 11th power.
8:47
That sounds like a big number. It is a massive
8:49
number. That creates an address space of over
8:52
73 quintillion unique combinations. Wait, quintillion?
8:56
Quintillion. Put that in perspective. If every
8:58
human being on Earth uploaded 1 million videos
9:00
every single day, it would still take thousands
9:03
of years to run out of IDs. That scale is just
9:06
mind -bending. But you mentioned vulnerability
9:08
earlier. How does making the address space that
9:11
massive protect the company? It acts as corporate
9:14
army against scraping. OK. Let's say you launch
9:16
a rival video platform. If your competitor uses
9:19
sequential ID, say, their newest video is ID
9:23
number 10 ,500 ,000, you instantly know exactly
9:27
how many videos are on their platform. Oh, I
9:29
see. You know their exact growth rate. Right.
9:32
And even worse, you could write a simple bot
9:34
to request video 1, then video 2, then video
9:37
3, and systematically download their entire multi
9:40
-billion dollar inventory. Oh, wow. Because the
9:43
addresses are entirely predictable. Exactly.
9:46
But with Base64, the IDs are randomly generated
9:49
and assigned. The gap between one valid ID and
9:51
the next valid ID is a vast, mathematically empty
9:54
desert. So a bot would just get lost. Completely.
9:56
If your scraping bot tries to guess the next
9:59
URL, it will hit millions and millions of 404
10:02
error pages before it accidentally stumbles onto
10:04
a real video file. It adds security through obscurity,
10:07
kind of. The randomized base 64 makes the internal
10:10
architecture of the database completely opaque
10:12
to the outside world. Precisely. And it also
10:15
drastically speeds up the database indexing.
10:18
Really? When your request for that specific 11
10:21
-character C string hits the server, The database
10:23
doesn't have to scan the actual titles of billions
10:26
of videos. It just hashes that string and instantly
10:30
pulls the exact storage location on the hard
10:32
drive. Okay, so let us check in on our timeline
10:35
here. We clicked the link. Yep. The TLS handshake
10:39
secured our tunnel. The armored truck. Right.
10:42
The DNS domain hack found the closest physical
10:44
server. The Base64 combination lock queered the
10:48
database, and the server has located our specific
10:50
video file. We are only milliseconds into the
10:53
process. Yeah. And the core job is basically
10:55
done. The server is ready to send the video back
10:58
to our phone. But the 43 character string isn't
11:00
finished yet. No, it is not. We're only at character
11:02
31. The video has been found. But right after
11:05
that identifier, the syntax of the URL changes
11:08
fundamentally. We hit a single punctuation mark.
11:11
The question mark. And this completely pivots
11:13
the relationship between your phone and the server.
11:15
Yeah, this is the query boundary. In the architecture
11:18
of a URL, the question mark is the ultimate demarcation
11:22
line. Everything before it is an instruction
11:24
to the network on how to find a file. But everything
11:27
after the question mark is a payload. This raises
11:30
an important question, though, about the phrasing
11:32
of that. Because when we see a question mark,
11:35
our brains naturally assume an interrogation.
11:38
We assume the browser is saying to the server,
11:40
hey, do you have this extra stuff? Right. It's
11:43
a very common misconception. But it is the exact
11:46
opposite. Your browser is not asking a question.
11:49
It is making a statement. It's handing over baggage.
11:53
It is handing over baggage. Right. It's saying,
11:55
I found the building, I found the file, and oh,
11:57
by the way, here is an invisible note containing
11:59
extra context about who I am and how I got here.
12:02
Yes. That's the query string. And the server
12:05
is programmed to receive that note, parse the
12:07
variables, and adjust its behavior. Like what
12:10
kind of behavior? Well, sometimes these variables
12:12
are functional. For example, if you see t equals
12:15
60s after the question mark. your browser is
12:18
telling the server, skip the first minute and
12:20
start playing at the 60 second mark. I've seen
12:23
that when people link to a specific part of a
12:25
long podcast or something. Exactly. But the parameter
12:28
in our source text. is not about a timestamp.
12:31
No, it is not functional for the video playback
12:33
at all. The note our browser is handing over
12:36
says, SI equals MFP, capital Q, capital Y, lowercase
12:41
T, capital G, capital Q, lowercase X, UNQ, capital
12:45
H5, capital E, capital D. And what's fascinating
12:48
here is how this specific parameter represents
12:52
the invisible economy of the modern internet.
12:55
The SI. Yeah, the SI stands for source identifier.
12:57
The digital die pack we talked about at the beginning.
13:00
Exactly. Let's look at the mechanics of how that
13:02
die pack is actually manufactured. OK, lay it
13:05
on me. So when a user is sitting on their couch
13:07
watching a video on their app and they click
13:10
the share button to copy the link. Right, to
13:12
text it to a friend. Yeah, the application doesn't
13:15
just copy the base URL. Yeah. In that fraction
13:18
of a second, the app generates this unique 16
13:20
-character string and appends it to the end.
13:22
And what exactly is encoded in that string? What
13:25
is it tracking? It is a cryptographic hash that
13:28
contains the origin details of the share. It
13:31
notes the specific account that generated the
13:33
link, the device they were using, the time of
13:35
day, and the exact interface button they pressed.
13:38
Wait, really? The specific button? Oh yeah. It
13:41
knows if you use the copy link button or the
13:43
share to watch that button or share to messages.
13:45
So when they text that link to me and I click
13:47
it, my phone goes through the whole secure tunnel,
13:50
finds the video and then dutifully hands that
13:53
S I note back to the server. Yes. Your phone
13:57
willingly volunteers the die pack. Wow. The server
14:00
receives the note, decrypts that 16 character
14:03
hash and logs a highly specific event. What does
14:06
the log say? It basically says, user B has just
14:09
arrived at this video. But they didn't search
14:11
for it. They arrived here specifically because
14:13
user A generated a link from their iPhone at
14:16
8 0 0 p .m. So what does this all mean, though?
14:19
For you, the listener who provided this exact
14:21
source, why does a massive tech company care
14:24
that my buddy texted me a video of a cat? Because
14:27
the Internet is no longer just about delivering
14:29
content. It is about understanding how humans
14:33
are connected. By quietly logging these source
14:36
identifiers billions of times a day, the platform
14:39
builds an unfathomably complex social graph.
14:43
A map of relationships, nodes and edges, basically.
14:46
Exactly. You might have strict privacy settings.
14:48
You might not list your friends publicly on your
14:50
profile. But if you consistently click links
14:53
that contain a source identifier generated by
14:55
your friend, the algorithm mathematically maps
14:58
the connection between you two. It knows we are
15:01
connected offline, just based on the links we
15:03
send each other. Yes. And it uses that map to
15:06
optimize its predictive models. How so? Well,
15:09
if the server knows that user A and user B share
15:12
a strong vector of viral transmission, the next
15:14
time user A watches a video for more than 10
15:17
minutes, the algorithm might automatically recommend
15:20
that same video to user B's home page. Even if
15:23
a direct link was never sent. Even if it was
15:25
never sent. Because it knows our tastes influence
15:27
each other. That is wild. It is using our organic,
15:32
private friendships to map the nervous system
15:34
of the internet. And it is doing it entirely
15:37
passively. Right. We think we're just sending
15:39
a funny video. We don't realize the URL itself
15:42
has been weaponized and, you know, I mean that
15:45
in a data collection sense, not a malicious one
15:47
to report back to the mothership. It is a highly
15:49
efficient, entirely silent data harvest. I mean,
15:53
the user experience is completely unaffected.
15:55
The video still plays instantly. Plays instantly
15:57
in high definition. The secure TLS handshake
16:00
ensures no one else intercepts the data. But
16:03
the die pack still explodes on the company's
16:05
server. Yep. Logging your relationship into the
16:08
social graph. Okay. This has been an absolute
16:10
journey. Let us recap the timeline we just walked
16:13
through, all within the span of a single tap
16:15
on a screen. Sounds good. We took 43 characters.
16:37
The HTTPS initiates a cryptographic TLS handshake,
16:41
creating an encrypted tunnel. Millisecond 10.
16:44
The Belgian domain hack, U2 .b, queries local
16:48
DNS cache and routes a request via any cache
16:50
to the closest physical data center, skipping
16:52
the Atlantic Ocean entirely. Millisecond 20.
16:55
The server receives the 11 -character Base64
16:57
identifier, navigating a mathematically vast
16:59
defense grid to instantly index the exact video
17:02
out of billions. And finally, millisecond 30.
17:05
We cross the query boundary of the question mark
17:07
and our browser hands over the SI payload, the
17:09
digital die pack that allows the platform to
17:11
map our human relationship. The entire architecture
17:13
of the modern web executed flawlessly in the
17:15
blink of an eye. Which brings me back to you,
17:18
the learner. The reason we take a microscope
17:20
to something so incredibly mundane is to remind
17:23
ourselves of the depth hidden in plain sight.
17:26
It's everywhere. It really is. We are swimming
17:29
in an ocean of data every single day. True understanding
17:33
isn't just about reading the big headlines. It's
17:36
about recognizing the invisible mechanics running
17:39
quietly in your browser bar. I can honestly say
17:42
you will never look at a shared link the exact
17:45
same way again. Nor should you. The infrastructure
17:48
of our digital lives demands our awareness. And
17:51
to that end, I would actually leave you with
17:53
a final thought to test this out on your own.
17:55
Oh, I love homework. Let's hear it. The next
17:57
time you copy and paste a link to send to a friend,
18:00
before you hit send, move your cursor to the
18:02
question mark. Delete the question mark and delete
18:04
every single character that comes after it. Just
18:06
backspace the payload away. Then send the link.
18:09
Cut the die pack off before you hand over the
18:11
bag. Exactly. Ask yourself, will the video still
18:14
load perfectly for your friend? And when it does,
18:17
who is suddenly blind to the digital footprint
18:19
of your friendship? I love that. A little manual
18:21
override of the social graph. Brilliant. Well,
18:24
that is all the time we have for today's deep
18:26
dive. Stay curious, keep pulling on those loose
18:29
threads, and we will see you next time.