WEBVTT
Kind: captions
Language: en

1
00:00:00.070 --> 00:00:02.689
Crashing a web page is actually really easy.

2
00:00:02.689 --> 00:00:05.060
You create a bit of code that says "go into
an infinite loop",

3
00:00:05.060 --> 00:00:07.310
and the page goes into an infinite loop.

4
00:00:07.310 --> 00:00:11.280
The only reason people don't do it more often
is there's not much point to it.

5
00:00:11.280 --> 00:00:13.700
There have been pages that'll crash your browser
--

6
00:00:13.700 --> 00:00:15.789
deliberately or accidentally --

7
00:00:15.789 --> 00:00:17.960
for years and years and years,

8
00:00:17.960 --> 00:00:21.490
but the web these days is all about sharable,
viral content,

9
00:00:21.490 --> 00:00:24.800
and if you can't see it, if it crashes your
browser,

10
00:00:24.800 --> 00:00:26.429
you can't share it.

11
00:00:26.429 --> 00:00:29.269
As well as that, browsers have been getting
smarter lately.

12
00:00:29.269 --> 00:00:33.780
If you run Chrome, each browser tab is a separate
process on your machine,

13
00:00:33.780 --> 00:00:36.329
so if someone puts an infinite loop in one
page,

14
00:00:36.329 --> 00:00:38.449
all it's going to do is grind that tab to
a halt

15
00:00:38.449 --> 00:00:41.670
while everything else continues. Firefox doesn't
have that,

16
00:00:41.670 --> 00:00:44.989
but it will detect when something's wrong,
and after a few seconds

17
00:00:44.989 --> 00:00:47.750
it'll ask if you want to stop the script that's
causing the problem.

18
00:00:47.750 --> 00:00:51.480
Now, it is possible to get around these and
crash things

19
00:00:51.480 --> 00:00:54.510
if you really want to be malicious, sure,

20
00:00:54.510 --> 00:00:59.500
but all you're going to do is annoy a few
people before your site fades into obscurity.

21
00:00:59.500 --> 00:01:05.570
So well done to Mandatory, who came up with
crashsafari.com in April 2015.

22
00:01:05.570 --> 00:01:08.720
And after months of not much traffic,

23
00:01:08.720 --> 00:01:11.830
someone posted it to a site called Hacker
News a week ago,

24
00:01:11.830 --> 00:01:14.400
and as I record this, a few days later,

25
00:01:14.400 --> 00:01:17.369
it had percolated around the internet enough
to finally go viral

26
00:01:17.369 --> 00:01:20.439
and be picked up by click-hungry tech news
reporters --

27
00:01:20.439 --> 00:01:24.070
because as soon as one of them posted an article
about it,

28
00:01:24.070 --> 00:01:26.740
the rest realised they might get some clicks
from a story like that too

29
00:01:26.740 --> 00:01:30.920
and hurriedly bashed out a headline and a
few hundred words.

30
00:01:30.920 --> 00:01:33.590
None of them actually tracked it back to the
source,

31
00:01:33.590 --> 00:01:36.140
and one even called the page "new".

32
00:01:36.140 --> 00:01:37.500
Journalism!

33
00:01:37.500 --> 00:01:40.220
So why did this particular site become successful?

34
00:01:40.220 --> 00:01:44.020
'Cos you don't need to click on it to know
what it does. That's why.

35
00:01:44.020 --> 00:01:45.240
Crash Safari, dot com.

36
00:01:45.240 --> 00:01:48.409
I mean, they also have Crash Chrome dot com,
and Crash Firefox dot com,

37
00:01:48.409 --> 00:01:50.240
which do exactly the same thing.

38
00:01:50.240 --> 00:01:52.280
That's a really tempting link, isn't it?

39
00:01:52.280 --> 00:01:53.689
You can type it easily into a tweet,

40
00:01:53.689 --> 00:01:55.560
you can send it on to other people.

41
00:01:55.560 --> 00:01:58.000
But there's another reason as well: on an
iPhone,

42
00:01:58.000 --> 00:02:00.049
it doesn't just crash your browser:

43
00:02:00.049 --> 00:02:01.909
it actually restarts your phone.

44
00:02:01.909 --> 00:02:05.289
Now that shouldn't happen. Safari, the browser
on iPhone,

45
00:02:05.289 --> 00:02:07.610
has a few defenses against web pages who do
that,

46
00:02:07.610 --> 00:02:11.040
it'll notice if memory usage gets too high
or it's in an infinite loop,

47
00:02:11.040 --> 00:02:13.090
and it'll just reload or close the tab.

48
00:02:13.090 --> 00:02:17.640
So you can't just create a web page that loops
forever and hope it's going to crash phones:

49
00:02:17.640 --> 00:02:21.820
you've got to actually break out of that little
sandbox that it puts you in

50
00:02:21.820 --> 00:02:24.160
and cause a problem in the browser itself,

51
00:02:24.160 --> 00:02:27.540
somewhere where the engineers didn't see the
problem coming.

52
00:02:27.540 --> 00:02:30.960
Which is why Crash Safari dot com isn't quite
your standard infinite loop.

53
00:02:30.960 --> 00:02:33.580
Let's have a look at the code:

54
00:02:33.580 --> 00:02:39.540
The first line just creates a string called
"total". Just somewhere to store text.

55
00:02:39.540 --> 00:02:42.730
Then it starts a loop: this line here, this
means,

56
00:02:42.730 --> 00:02:46.670
do everything between these brackets 100,000
times,

57
00:02:46.670 --> 00:02:50.510
and store whichever count you're on in this
variable: i.

58
00:02:50.510 --> 00:02:51.730
Then we go into the loop.

59
00:02:51.730 --> 00:02:54.790
Add the current number of the loop -- so,
we start with 0, then 1,

60
00:02:54.790 --> 00:02:56.650
all the way up to 100,000 -- as text,

61
00:02:56.650 --> 00:02:58.090
to the end of that string called "total".

62
00:02:58.090 --> 00:03:00.690
So that string just gets bigger and bigger
and bigger on each loop.

63
00:03:00.690 --> 00:03:03.030
And then, each time we go round,

64
00:03:03.030 --> 00:03:05.510
push that string into the browser's history.

65
00:03:05.510 --> 00:03:08.270
And that push is where the problem is.

66
00:03:08.270 --> 00:03:12.610
'Cos manipulating the browser's history is
a fairly new addition to what web pages can

67
00:03:12.610 --> 00:03:12.810
do,

68
00:03:12.810 --> 00:03:15.570
and like a lot of those recent additions,

69
00:03:15.570 --> 00:03:19.280
the security aspects haven't really been thought
through properly.

70
00:03:19.280 --> 00:03:23.000
In the old days, if you had a single page
web app, something like Gmail,

71
00:03:23.000 --> 00:03:25.830
then the back button would break it.

72
00:03:25.830 --> 00:03:27.310
The user would click an email,

73
00:03:27.310 --> 00:03:30.370
their email would pop up on the same web page,
just get loaded in,

74
00:03:30.370 --> 00:03:32.060
and then the user would, logically,

75
00:03:32.060 --> 00:03:34.460
click the back button to go back.

76
00:03:34.460 --> 00:03:37.430
Except the web page address hadn't changed:
it was still the same page.

77
00:03:37.430 --> 00:03:39.020
So Gmail would promptly unload,

78
00:03:39.020 --> 00:03:42.230
and you'd go back to whichever web site you
were browsing earlier.

79
00:03:42.230 --> 00:03:45.610
That "pushState" command -- that gets around
that.

80
00:03:45.610 --> 00:03:47.070
It's the web page saying, "hey,

81
00:03:47.070 --> 00:03:49.880
"my user's just switched to something else
within me.

82
00:03:49.880 --> 00:03:51.320
"When they click 'back',

83
00:03:51.320 --> 00:03:54.040
"don't actually go back to the page just before,

84
00:03:54.040 --> 00:03:57.290
"just tell me about it, I'll deal with it.
It's fine."

85
00:03:57.290 --> 00:03:59.190
But unlike regular web addresses,

86
00:03:59.190 --> 00:04:01.390
those push-states can be as long as you want.

87
00:04:01.390 --> 00:04:05.120
And you can add as many as you want as quickly
as you can.

88
00:04:05.120 --> 00:04:06.530
The browser keeps track of it all.

89
00:04:06.530 --> 00:04:09.470
It keeps track of every time the web page
sends one of those commands,

90
00:04:09.470 --> 00:04:12.210
to add it to the back button history. And
remember that loop?

91
00:04:12.210 --> 00:04:16.670
This page is going to send 100,000 entries
to the browser's history,

92
00:04:16.670 --> 00:04:21.370
and each one is going to be longer and longer
and longer: by the end,

93
00:04:21.370 --> 00:04:25.410
each individual entry will be about half a
megabyte long.

94
00:04:25.410 --> 00:04:28.220
Now I haven't done the exact maths, but at
a rough guess,

95
00:04:28.220 --> 00:04:33.050
that is somewhere around 25GB of history data.

96
00:04:33.050 --> 00:04:36.550
And the iPhone only has 1GB of RAM to store
that data in.

97
00:04:36.550 --> 00:04:38.430
It gives up almost instantly,

98
00:04:38.430 --> 00:04:40.900
realises that something is desperately wrong,

99
00:04:40.900 --> 00:04:43.090
and just reboots to sort it out.

100
00:04:43.090 --> 00:04:45.570
So should there be a check for this? Of course
there should.

101
00:04:45.570 --> 00:04:48.180
Will there be in the next version of iOS?
Maybe.

102
00:04:48.180 --> 00:04:51.370
And in the worst case, if conditions are perfect,

103
00:04:51.370 --> 00:04:54.110
an exploit like this can convince a computer,
or a phone,

104
00:04:54.110 --> 00:04:56.050
to run any code and do anything.

105
00:04:56.050 --> 00:05:02.810
But that is unlikely. And ultimately crashing
someone's phone, while it's annoying,

106
00:05:02.810 --> 00:05:06.510
isn't usually the sort of prank that gets
traffic to your site --

107
00:05:06.510 --> 00:05:09.450
but it might get you some clicks on your news
article.

108
00:05:09.450 --> 00:05:13.850
Or your YouTube video about it. Sorry.

109
00:05:14.800 --> 00:05:16.800
[Translating these subtitles? Add your name here!]