WEBVTT
Kind: captions
Language: en

1
00:00:00.089 --> 00:00:01.410
September 2018.

2
00:00:01.410 --> 00:00:02.639
I was tired, I was exhausted,

3
00:00:02.639 --> 00:00:04.570
I’d just got back home from something,

4
00:00:04.570 --> 00:00:06.120
and I didn't have the energy to cook.

5
00:00:06.120 --> 00:00:07.440
So I went to my phone,

6
00:00:07.440 --> 00:00:11.410
opened up a certain food-delivery app that’s
popular in the UK, and I ordered pizza.

7
00:00:11.410 --> 00:00:15.160
Now, I know: that food-delivery company’s
employment practices are questionable,

8
00:00:15.160 --> 00:00:17.810
there are more ethical ways to get dinner
delivered.

9
00:00:17.810 --> 00:00:19.280
But I was tired, and I was hungry.

10
00:00:20.040 --> 00:00:22.160
As are a lot of their drivers.

11
00:00:22.170 --> 00:00:24.410
But that was the Night of the Multiple Orders,

12
00:00:24.410 --> 00:00:28.140
when a bug in that app meant that some people
around Britain ended up with

13
00:00:28.140 --> 00:00:30.720
identical food orders
being delivered two or three times,

14
00:00:30.730 --> 00:00:32.489
and others got nothing at all.

15
00:00:32.489 --> 00:00:34.440
And I nearly got caught up in the chaos.

16
00:00:34.440 --> 00:00:35.440
To explain what happened,

17
00:00:35.440 --> 00:00:38.880
I need to tell you a story about two generals.

18
00:00:40.989 --> 00:00:43.540
The Two Generals' Problem is a
classic of computer science,

19
00:00:43.550 --> 00:00:45.739
and it goes like this: picture a valley.

20
00:00:45.739 --> 00:00:48.239
In the middle of the valley is a
heavily fortified castle.

21
00:00:48.239 --> 00:00:51.180
On the edges of the valley are two armies.

22
00:00:51.180 --> 00:00:55.200
The generals of these armies know that the
only way they can win a battle and overwhelm

23
00:00:55.200 --> 00:00:58.700
the castle is if they both attack
at the same time.

24
00:00:58.700 --> 00:01:00.780
A single army isn't going to make it.

25
00:01:00.780 --> 00:01:04.290
They need the combined strength from
both sides of the valley to win.

26
00:01:04.290 --> 00:01:06.480
And the only way they can communicate

27
00:01:06.480 --> 00:01:09.979
is by sending messengers on a
risky path through the valley.

28
00:01:09.979 --> 00:01:16.119
And General A won’t know what the right
time is until everyone’s already in position.

29
00:01:16.119 --> 00:01:18.440
How can those two generals coordinate

30
00:01:18.440 --> 00:01:20.100
to make sure they
attack at the same time?

31
00:01:20.100 --> 00:01:22.819
This is a magical computer-science-land problem,
by the way,

32
00:01:22.819 --> 00:01:27.329
so reasonable suggestions like “semaphore”
or “telescopes” don’t apply.

33
00:01:27.329 --> 00:01:29.390
On the surface the problem seems trivial.

34
00:01:29.390 --> 00:01:33.299
General A could just send a message to
General B with a proposed time.

35
00:01:33.299 --> 00:01:34.299
Say, 8 o'clock.

36
00:01:34.299 --> 00:01:36.539
But the messenger has to pass
through the valley,

37
00:01:36.539 --> 00:01:38.739
and if they’re spotted, they’re, um,

38
00:01:38.739 --> 00:01:41.689
not going to make it to the other side to
deliver the message.

39
00:01:41.689 --> 00:01:46.029
So how does General A know that General B
received the message?

40
00:01:46.029 --> 00:01:47.799
The messenger might not have made it.

41
00:01:47.799 --> 00:01:48.799
And if that happens,

42
00:01:48.799 --> 00:01:52.520
A will attack, B won’t, and they’ll lose.

43
00:01:52.520 --> 00:01:56.469
So maybe they arrange it so General B has
to send an acknowledgment back,

44
00:01:56.469 --> 00:01:59.320
and General A will only attack
if that acknowledgement arrives.

45
00:01:59.320 --> 00:02:01.259
But that now runs into the same problem:

46
00:02:01.259 --> 00:02:03.999
how does B know that A has received
the acknowledgement?

47
00:02:03.999 --> 00:02:05.559
If it doesn’t get through,

48
00:02:05.559 --> 00:02:08.899
A won’t attack, B will, and they’ll lose.

49
00:02:08.899 --> 00:02:12.000
So, General A could send another acknowledgement
for the acknowledgement.

50
00:02:12.000 --> 00:02:14.680
But how do they know that message
has gotten through? Well,

51
00:02:14.680 --> 00:02:18.159
General B could send an acknowledgment for
the acknowledgement for the acknowledgement

52
00:02:18.159 --> 00:02:20.560
and so on, and so on, and so on.

53
00:02:20.560 --> 00:02:24.140
This problem is unsolvable.

54
00:02:24.140 --> 00:02:26.640
I know, it feels like there should be some
hacky workaround

55
00:02:26.640 --> 00:02:29.180
like sending 200 messengers,
and sure,

56
00:02:29.180 --> 00:02:31.580
that would probably work
in the real world.

57
00:02:31.580 --> 00:02:34.470
But this is magical information-theory
computer-science land.

58
00:02:34.470 --> 00:02:36.470
Under these strict rules,

59
00:02:36.470 --> 00:02:39.300
there is never a guarantee,
there is no certainty,

60
00:02:39.300 --> 00:02:41.860
there is no arrangement that can be made,
there is no way,

61
00:02:41.860 --> 00:02:44.780
that the two generals,
the two computers sending data,

62
00:02:44.780 --> 00:02:49.120
can agree that the message has definitely
been received and acknowledged.

63
00:02:49.940 --> 00:02:52.460
Now, with computers you’re not usually dealing
with such high stakes.

64
00:02:52.470 --> 00:02:56.519
If you are in computer science and working
on a problem that involves potential loss of life,

65
00:02:56.520 --> 00:02:59.900
I really hope you aren't watching a series
called "The Basics".

66
00:02:59.900 --> 00:03:01.980
Anyway. I was ordering food.

67
00:03:01.980 --> 00:03:03.819
And I put my order together, I tapped ‘pay’,

68
00:03:03.819 --> 00:03:05.359
I put my fingerprint on my phone’s reader.

69
00:03:05.360 --> 00:03:08.140
I got the little Apple Pay progress bar,
and the little tick.

70
00:03:08.140 --> 00:03:12.019
And then I got a message from the app
saying that there had been a problem,

71
00:03:12.020 --> 00:03:15.300
and my order had failed to go through.
Would I like to try again?

72
00:03:15.300 --> 00:03:16.680
And I was about to.

73
00:03:16.689 --> 00:03:18.209
I was about to hit ‘pay’ again.

74
00:03:18.209 --> 00:03:21.700
And then something, just in the back
of my head, said: hang on.

75
00:03:21.700 --> 00:03:24.109
There was that little tick saying
payment had worked.

76
00:03:24.109 --> 00:03:29.400
And I’m enough of a computer nerd to go
"I’m not sure I believe that failed".

77
00:03:29.400 --> 00:03:31.200
So I checked the ‘order history’ page.

78
00:03:31.200 --> 00:03:34.329
It took a few tries to load,
but when it finally did, there was my order.

79
00:03:34.329 --> 00:03:37.849
Processing. It had gone through, but
the acknowledgement hadn’t come back.

80
00:03:37.849 --> 00:03:39.989
Or, rather, something had gone wrong
on the app’s servers,

81
00:03:39.989 --> 00:03:43.379
and the logic they’d written
thought it had failed when it hadn’t.

82
00:03:43.379 --> 00:03:46.290
So I sat tight,
I hoped that my food would arrive,

83
00:03:46.290 --> 00:03:50.000
and I figured that the engineers were probably
having a very bad day.

84
00:03:50.000 --> 00:03:51.720
They really were.

85
00:03:51.720 --> 00:03:53.330
Because I wasn't the only one.

86
00:03:53.330 --> 00:03:56.644
People all over the UK ordering via the app
were going to the payment screen,

87
00:03:56.644 --> 00:03:59.279
hitting the button and getting
"try again".

88
00:03:59.279 --> 00:04:02.379
And a lot of them did.
Again, and again, and again.

89
00:04:02.379 --> 00:04:04.969
They were General A,
and the app’s server was General B,

90
00:04:04.969 --> 00:04:08.719
and they were part of a real-life,
complicated version of the Two Generals' problem.

91
00:04:08.719 --> 00:04:10.840
Imagine all the customers as General A,

92
00:04:10.840 --> 00:04:14.249
sending message after message to General B.
B received the messages,

93
00:04:14.249 --> 00:04:16.579
dutifully took the money from the credit card
every time --

94
00:04:16.579 --> 00:04:18.090
they attacked --

95
00:04:18.090 --> 00:04:23.020
but something had happened that stopped
the confirmation message getting through.

96
00:04:23.020 --> 00:04:25.560
According to the flood of angry reports on
Twitter,

97
00:04:25.560 --> 00:04:29.680
sometimes the restaurant would realise the
problem and just send one order.

98
00:04:29.680 --> 00:04:31.340
Sometimes the restaurant wouldn’t realise,

99
00:04:31.340 --> 00:04:34.960
and three different drivers would arrive
with three identical orders.

100
00:04:34.960 --> 00:04:36.699
Sometimes no food would arrive at all.

101
00:04:36.699 --> 00:04:38.960
The app’s customer service line was swamped.

102
00:04:38.960 --> 00:04:42.580
To be clear: this was not the sort of thing
that is one engineer’s fault.

103
00:04:42.580 --> 00:04:44.780
When something goes this drastically wrong,

104
00:04:44.780 --> 00:04:48.509
there have been many poor decisions made over
a long period of time.

105
00:04:48.509 --> 00:04:52.620
A single human error is never a root cause.

106
00:04:52.620 --> 00:04:54.199
So what else could the app team have done?

107
00:04:54.200 --> 00:04:57.660
How can you solve the Two Generals' problem
in the real world?

108
00:04:57.660 --> 00:05:01.740
Well, first, maybe no-one should have
been able to place two identical orders

109
00:05:01.740 --> 00:05:03.920
on the same credit card,
for the same restaurant,

110
00:05:03.920 --> 00:05:05.500
within a few minutes of each other.

111
00:05:05.500 --> 00:05:08.540
That seems like the sort of thing there should
have been a check for?

112
00:05:08.540 --> 00:05:12.910
But the real solution is an
“idempotency token”, or an “idempotency key”.

113
00:05:12.910 --> 00:05:16.710
This is a unique value generated on
the app, or on the web site:

114
00:05:16.710 --> 00:05:18.569
and it’s a shopping cart ID, basically,

115
00:05:18.569 --> 00:05:20.340
and it’s sent along with the order.

116
00:05:20.340 --> 00:05:22.349
it's not just for shopping carts, though:

117
00:05:22.349 --> 00:05:26.710
the idempotency token could be attached to
instructions to delete the oldest log file,

118
00:05:26.710 --> 00:05:27.800
or send a text message,

119
00:05:27.800 --> 00:05:31.039
or anything that you only want to happen once.

120
00:05:31.039 --> 00:05:34.030
The server stores the idempotency key to keep
track of the request.

121
00:05:34.030 --> 00:05:37.180
And if another request arrives with the same
key attached,

122
00:05:37.180 --> 00:05:40.389
then the server knows it’s already
dealt with that request.

123
00:05:40.389 --> 00:05:44.660
So it doesn’t fulfill it again; instead it
knows that the reply didn’t get through,

124
00:05:44.660 --> 00:05:47.800
so it just sends back a copy of that first
acknowledgement again.

125
00:05:47.800 --> 00:05:50.930
Now, that still won’t help if none
of the messengers get through,

126
00:05:50.930 --> 00:05:52.610
if the connection completely fails,

127
00:05:52.610 --> 00:05:56.620
but for real-world problems,
humans will notice that.

128
00:05:56.620 --> 00:06:00.380
Idempotence means that you can request the
same thing multiple times

129
00:06:00.380 --> 00:06:02.810
and it’ll only ever happen once.

130
00:06:02.810 --> 00:06:06.229
That’s the way to fix the
Two Generals' Problem.

131
00:06:06.229 --> 00:06:07.229
I was lucky.

132
00:06:07.229 --> 00:06:08.720
I placed one order,
I was charged for one order,

133
00:06:08.720 --> 00:06:12.050
and one order of food arrived
half an hour later.

134
00:06:12.050 --> 00:06:15.100
Next time, I’ll just cook for myself.

135
00:06:15.100 --> 00:06:18.480
This series of The Basics is sponsored by
Dashlane, the password manager.

136
00:06:18.480 --> 00:06:21.980
I mentioned in the previous sponsored section
that they sync all your passwords

137
00:06:21.980 --> 00:06:24.180
and payment details between
all your devices

138
00:06:24.180 --> 00:06:27.060
without ever
knowing those passwords.

139
00:06:27.060 --> 00:06:30.170
Which sounds a bit like magic.

140
00:06:30.170 --> 00:06:33.789
When you sign up to Dashlane, you choose a
Master Password.

141
00:06:33.789 --> 00:06:35.050
And incidentally,

142
00:06:35.050 --> 00:06:39.419
you can do that by going to
dashlane.com/tomscott for a free 30-day trial.

143
00:06:39.419 --> 00:06:40.800
Anyway, when you sign up,

144
00:06:40.800 --> 00:06:42.680
you pick a single Master Password,

145
00:06:42.680 --> 00:06:45.069
and that is never transmitted over the internet.

146
00:06:45.069 --> 00:06:47.560
Not even to Dashlane,
not to their servers, nowhere.

147
00:06:47.560 --> 00:06:49.699
If you don’t know that password,

148
00:06:49.699 --> 00:06:52.800
all that private data just looks
like random noise.

149
00:06:52.800 --> 00:06:55.895
So: when you sign up to a new website and
Dashlane generates

150
00:06:55.895 --> 00:06:58.340
a long, complicated password
for you,

151
00:06:58.340 --> 00:07:02.370
it is bundled up and encrypted using your
master password, that only you know.

152
00:07:02.370 --> 00:07:05.680
That encryption takes just long enough,
a few fractions of a second,

153
00:07:05.680 --> 00:07:08.800
that there’s no way to
brute-force it back open.

154
00:07:08.800 --> 00:07:10.960
That encrypted bundle gets sent to Dashlane:

155
00:07:10.960 --> 00:07:15.180
they just see random noise with a label saying
‘please synchronise this’.

156
00:07:15.180 --> 00:07:17.669
So they pass the bundle on to your other devices,

157
00:07:17.669 --> 00:07:21.860
and those devices, and only those devices,
can decrypt it because, at some point,

158
00:07:21.860 --> 00:07:24.760
you’re going to open up the app and type
in your Master Password.

159
00:07:24.760 --> 00:07:27.710
In truth, it’s actually a little
more secure than that,

160
00:07:27.710 --> 00:07:32.020
because behind-the-scenes they also generate
a different key for each device you log in to,

161
00:07:32.020 --> 00:07:34.040
but that is a whole other level of security

162
00:07:34.040 --> 00:07:36.930
that I have actually found it impossible to
explain in a script.

163
00:07:36.930 --> 00:07:41.030
But, in the massively unlikely event that someone
did compromise Dashlane’s servers,

164
00:07:41.030 --> 00:07:44.080
or bribe some employee, it wouldn’t work.

165
00:07:44.080 --> 00:07:47.909
All they could do is watch those packets of
random noise get shuffled around.

166
00:07:47.909 --> 00:07:50.449
All your data stays on your own devices.

167
00:07:50.449 --> 00:07:52.880
Which means,
if you lose your Master Password,

168
00:07:52.880 --> 00:07:54.340
Dashlane can’t help you.

169
00:07:54.340 --> 00:07:55.340
But that’s fine,

170
00:07:55.340 --> 00:07:58.530
because now you’ve just got a single password
to remember.

171
00:07:58.530 --> 00:08:02.220
That is massively more secure than reusing
the same password

172
00:08:02.220 --> 00:08:05.169
or variations on a password
everywhere online.

173
00:08:05.169 --> 00:08:08.350
Like I said last time:
you should use a password manager.

174
00:08:08.350 --> 00:08:11.660
So: dashlane.com/tomscott for a
free 30-day trial of Dashlane Premium,

175
00:08:11.660 --> 00:08:15.449
and if you like it you can use the code “tomscott”
for 10% off at purchase.