Crashing a web page is actually really easy.
You create a bit of code that says "go into an infinite loop",
and the page goes into an infinite loop.
The only reason people don't do it more often is there's not much point to it.
There have been pages that'll crash your browser --
deliberately or accidentally --
for years and years and years,
but the web these days is all about sharable, viral content,
and if you can't see it, if it crashes your browser,
you can't share it.
As well as that, browsers have been getting smarter lately.
If you run Chrome, each browser tab is a separate process on your machine,
so if someone puts an infinite loop in one page,
all it's going to do is grind that tab to a halt
while everything else continues. Firefox doesn't have that,
but it will detect when something's wrong, and after a few seconds
it'll ask if you want to stop the script that's causing the problem.
Now, it is possible to get around these and crash things
if you really want to be malicious, sure,
but all you're going to do is annoy a few people before your site fades into obscurity.
So well done to Mandatory, who came up with crashsafari.com in April 2015.
And after months of not much traffic,
someone posted it to a site called Hacker News a week ago,
and as I record this, a few days later,
it had percolated around the internet enough to finally go viral
and be picked up by click-hungry tech news reporters --
because as soon as one of them posted an article about it,
the rest realised they might get some clicks from a story like that too
and hurriedly bashed out a headline and a few hundred words.
None of them actually tracked it back to the source,
and one even called the page "new".
Journalism!
So why did this particular site become successful?
'Cos you don't need to click on it to know what it does. That's why.
Crash Safari, dot com.
I mean, they also have Crash Chrome dot com, and Crash Firefox dot com,
which do exactly the same thing.
That's a really tempting link, isn't it?
You can type it easily into a tweet,
you can send it on to other people.
But there's another reason as well: on an iPhone,
it doesn't just crash your browser:
it actually restarts your phone.
Now that shouldn't happen. Safari, the browser on iPhone,
has a few defenses against web pages who do that,
it'll notice if memory usage gets too high or it's in an infinite loop,
and it'll just reload or close the tab.
So you can't just create a web page that loops forever and hope it's going to crash phones:
you've got to actually break out of that little sandbox that it puts you in
and cause a problem in the browser itself,
somewhere where the engineers didn't see the problem coming.
Which is why Crash Safari dot com isn't quite your standard infinite loop.
Let's have a look at the code:
The first line just creates a string called "total". Just somewhere to store text.
Then it starts a loop: this line here, this means,
do everything between these brackets 100,000 times,
and store whichever count you're on in this variable: i.
Then we go into the loop.
Add the current number of the loop -- so, we start with 0, then 1,
all the way up to 100,000 -- as text,
to the end of that string called "total".
So that string just gets bigger and bigger and bigger on each loop.
And then, each time we go round,
push that string into the browser's history.
And that push is where the problem is.
'Cos manipulating the browser's history is a fairly new addition to what web pages can
do,
and like a lot of those recent additions,
the security aspects haven't really been thought through properly.
In the old days, if you had a single page web app, something like Gmail,
then the back button would break it.
The user would click an email,
their email would pop up on the same web page, just get loaded in,
and then the user would, logically,
click the back button to go back.
Except the web page address hadn't changed: it was still the same page.
So Gmail would promptly unload,
and you'd go back to whichever web site you were browsing earlier.
That "pushState" command -- that gets around that.
It's the web page saying, "hey,
"my user's just switched to something else within me.
"When they click 'back',
"don't actually go back to the page just before,
"just tell me about it, I'll deal with it. It's fine."
But unlike regular web addresses,
those push-states can be as long as you want.
And you can add as many as you want as quickly as you can.
The browser keeps track of it all.
It keeps track of every time the web page sends one of those commands,
to add it to the back button history. And remember that loop?
This page is going to send 100,000 entries to the browser's history,
and each one is going to be longer and longer and longer: by the end,
each individual entry will be about half a megabyte long.
Now I haven't done the exact maths, but at a rough guess,
that is somewhere around 25GB of history data.
And the iPhone only has 1GB of RAM to store that data in.
It gives up almost instantly,
realises that something is desperately wrong,
and just reboots to sort it out.
So should there be a check for this? Of course there should.
Will there be in the next version of iOS? Maybe.
And in the worst case, if conditions are perfect,
an exploit like this can convince a computer, or a phone,
to run any code and do anything.
But that is unlikely. And ultimately crashing someone's phone, while it's annoying,
isn't usually the sort of prank that gets traffic to your site --
but it might get you some clicks on your news article.
Or your YouTube video about it. Sorry.
[Translating these subtitles? Add your name here!]