The 2024 UK general election, the first since Brexit officially began (January 31, 2020) and after 14 years of Conservative leadership, saw the Labour Party secure a majority. This blog post examines Internet traffic trends and cyberattack activity on election day, highlighting notable declines in traffic during the afternoon and evening as well as a DDoS attack on a political party shortly after polls closed.

For context, 2024 is considered “the year of elections,” with elections taking place in over 60 countries. We’ve covered elections in South Africa, India, Iceland, Mexico, the European Union, France, and also the 2024 US presidential debate. We also continuously update our election report on Cloudflare Radar.

The UK’s snap election on Thursday, July 4, 2024, typical of British Thursday weekday elections, contrasts with weekend elections in other countries. Polling stations were open from 07:00 to 22:00.

Generally, election days do not result in drastic changes to Internet traffic. Traffic typically dips during voting hours but not as sharply as during major events like national holidays, and rises in the evening as results are announced.

On July 4, 2024, traffic initially rose slightly from the previous week, then fell around noon (-2%). Significant declines began only after 16:00, with noticeable drops at 16:45 and again at 22:00 as polls closed.

Traffic shifts during voting day, compared to the previous week, are more revealing when viewed in detail. The map and table below summarize the traffic changes observed at the country level within the UK, where the greatest impact was observed in Northern Ireland (-10%), followed by Scotland (-6%), Wales (-5%), and England (-3%), all after 16:00.

Next, examining the day’s traffic changes, we observed a clear drop in Northern Ireland around 13:00 local time and during off-work hours between 16:00 and 20:00, before it began to increase again.

In Scotland, traffic fell by about 5% from 16:00 to 21:00 local time compared to the previous week.

In Wales, decreases occurred at 07:00 (4% drop), between 16:00 and 18:00 (around 5% drop), and at 21:00.

And in England, traffic decreased by approximately 3% between 16:00 and 18:00 and about 2% between 20:00 and 22:00.

In all the countries within the UK, traffic clearly increased after 23:00 local time when the voting polls had already closed and the first results started to arrive. Peak increases were reached at different times: Wales saw a 3% increase at 01:00; Northern Ireland and England experienced their highest increases of 12% and 11% respectively at 02:00; and Scotland had a 9% increase at 02:00 followed by a 12% spike at 04:00.

Switching focus to domain trends, our 1.1.1.1 resolver DNS data reveals a more targeted impact from the UK elections. Analyzing the participating parties, DNS traffic significantly increased on election day, peaking at 22:00 and midnight local time (up to 600% growth), and then again at 04:00 (671%).

Among the main parties, Labour, led by Keir Starmer, outperformed the Conservative Party on election day. Labour’s DNS traffic spiked at 22:00 local time, with an 866% increase from the previous week.

Analyzing official government and election-related websites, the UK differs from other countries in how results are shared. Official results weren’t continuously updated as they came in. The largest spike in DNS traffic, a 172% increase from the previous week, occurred on election morning around 07:00 local time. This increase likely happened because UK citizens were searching for the correct polling stations and other voting resources.

News sites and microblogging social media platforms in the UK experienced significant increases in usage after the polling stations closed at 22:00 local time. In the UK, news sites not only provide initial projections but also final results. DNS traffic for UK news media outlets surged 74% compared to the previous week, peaking at 104% at midnight and 04:00.

For microblogging social media in Great Britain, traffic was already 25% higher than the previous week when the polls closed (22:00), peaking at 27% at midnight and remaining elevated through the night.

We saw last week in the US, during the Biden vs Trump debate, that video streaming social platforms such as YouTube or TikTok, were used to watch through news outlets channels the debate live, with DNS traffic surging. How about the UK? DNS traffic was 10% higher than in the previous week starting at midnight, and at 01:00 local time was 15% higher.

Focusing on attacks, those are usually constant, and aren’t necessarily driven always by elections. But, as we’ve seen at the start of the war in Ukraine or more recently in the Netherlands or in France, specific events do trigger attacks. DDoS (Distributed Denial of Service) attacks remain a common method employed by attackers.

In recent days, there has been DDoS activity targeting political parties in the UK that participated in these elections. Our data shows that two parties experienced attacks that were blocked by Cloudflare. One party, represented in blue, suffered an attack on June 16, which lasted over four hours and peaked at 60,000 requests per second (rps).

The party shown in yellow was hit by four DDoS attacks on different days: June 13, 19, 26, and in the early hours of July 5 (UTC), just after the election’s first predictions were broadcast, giving a majority to the Labour Party. This was the most significant attack in recent days, peaking at 156,000 rps. It began at 01:47 local time (00:47 UTC) and ended four minutes later. Here’s a closer look at that July 5, 2024, attack:

Although these rates are small on Cloudflare’s scale, they can be devastating for unprotected websites unaccustomed to such levels of traffic.

Even if major political events don’t always bring notable changes to Internet traffic, our data shows that in the UK, traffic decreased more significantly in the afternoon and evening, especially as voting stations remained open until 22:00.

After voting ended, news sites became the go-to resource for UK residents seeking initial predictions and results.

We also observed attacks targeting political parties in the UK, further highlighting that this election year is marked by cyberattacks aimed at influencing politically related websites.

If you want to follow more trends and insights about the Internet and elections in particular, you can check Cloudflare Radar, and more specifically our new 2024 Elections Insights report, which will be updated as elections take place throughout the year.

When major events in a country happen Internet traffic patterns are often impacted, depending on the type of event. But what about the coronation of a king or queen? There’s no similar precedent, with a worldwide impact, in the Internet age, except maybe the coronation of the king of Thailand, in 2019. The last time it happened in the United Kingdom was 70 years ago (June 2, 1953), with Queen Elizabeth II; it was the first British coronation to be fully televised. Neither the Internet nor ARPANET were around at the time.

Imagine a grand royal event (if you saw the broadcast or the news, there’s no need), filled with pomp and pageantry, that's so captivating it impacts Internet traffic. That's what happened during the coronation of Charles III and Camilla, the newly crowned king and queen of the United Kingdom and other Commonwealth realms. As the coronation ceremony unfolded, on Saturday morning, May 6, 2023, there were clear spikes and dips in traffic, each coinciding with key moments of the ceremony.

Then came Sunday, and with it, the Coronation Big Lunch event. As the nation sat down to enjoy a communal meal throughout the country, Internet traffic took a significant nosedive, dropping by as much as 18%. The Sunday trends didn't stop there. As night fell and Prince William took to the stage to deliver a speech during the Coronation Concert, there was a clear drop in Internet traffic. Monday, May 8, was a bank holiday in the UK in honor of the coronation, and after a weekend of outdoor coronation events, Internet traffic was buzzing, noticeably higher than usual.

In the past, we’ve seen Internet traffic drop when a national televised event is happening — last year, we saw it, including in the UK, during the Eurovision, although traffic does increase when results are in. Different types of events and broadcasts yield different Internet patterns.

Let's take a closer look at coronation day, May 6, 2023, when Internet traffic in the UK had its own peaks and valleys. There were moments when the digital realm seemed to hold its breath, with traffic dipping to its lowest points. The arrival of the royals and their guests marked one such moment. As the anticipation built and all eyes turned to the grand entrances, Internet traffic dipped to a notable 7% lower than the previous week.

Here's a play-by-play of the day's traffic trends, compared to the previous week. We’re using a 15-minute granularity, and aligning with key events as reported live by the BBC:

On Saturday, May 6, 2023, a downward trend in traffic began after 06:15, with traffic 5% lower than the previous week. This trend shifted to a traffic increase after 11:15 (+6%), coinciding with the ongoing ceremony. The exceptions were the previously mentioned traffic dips. The following table illustrates clear traffic spikes after significant moments, some of which are represented in the previous table. Here's a list of periods with higher growth:

As guests and royals arrived and during moments like the king's crowning, Internet traffic noticeably dropped. However, during parts of the ceremony such as the choir singing, Internet traffic seemed to increase. That was also clear after the military flypast, over the Buckingham Palace balcony.

The following chart illustrates UK Internet traffic during the weekend, with the purple dotted line representing the previous weekend.

On a daily basis, daily traffic was 4% higher on Saturday, May 6, compared to the previous Saturday.

Another trend from the coronation weekend relates to the events that took place on Sunday, May 7. Internet trends here align with what we observed almost a year ago during Queen Elizabeth II's Platinum Jubilee. Sunday was a day of celebration with both the Coronation Big Lunch (where neighbors and communities were invited to share food and fun together across the country) and the Coronation Concert taking place.

Next, we present the percentages of increase/decrease in requests during this past weekend, compared with the previous week (a slightly different perspective from the previous chart):

On Sunday, May 7, it's clear that UK traffic was lower than usual right after 07:00 local time (-2% in traffic), but it dropped the most after 12:00 (-5%), compared to the previous week. The moment with the biggest drop in traffic, compared to the previous week, was between 14:15 and 15:30, when traffic was around 18% lower. That was still Big Lunch time, given that it’s a multiple hour event full of “food and fun” — there were more than 65,000 Coronation Big Lunch events around the UK. During last year's Queen Elizabeth II's Platinum Jubilee, traffic dropped as much as 25% on Sunday, June 5, 2022, at 15:00.

At night, the Coronation Concert took center stage, broadcast live from Windsor Castle on the BBC after 20:00. The lineup included musical guests such as Take That, Lionel Richie, Katy Perry, and Andrea Bocelli. However, the star of the event, at least in terms of when Internet traffic was at its lowest that evening, was William, Prince of Wales. Cloudflare observed another significant drop in traffic, compared to the previous week, around 21:15-21:30, when traffic was 7% lower than the previous week. At that time, Lionel Richie had just performed, and Prince William was on stage for a special address to the king.

In terms of daily traffic, if on Coronation Saturday we saw an increase (4%), on Coronation Sunday there was a 6% drop compared to the previous week. On Monday, the coronation bank holiday, there weren't any major coronation events, and traffic was 4% higher than the previous week (May 1, also a bank holiday in the UK).

Zooming in on the distribution of traffic from mobile devices, we find that Saturday, May 6, stands out in 2023. On this day, mobile traffic accounted for 61% of total traffic, a figure only matched by April 15 and January 1, 2023. Similarly, Sunday, May 7, was one of the Sundays with the highest percentage of mobile traffic, at 60%. This percentage was only surpassed by Easter Sunday, April 9 (60.4%), and, unsurprisingly, January 1, 2023 (61%).

Which UK countries were more impacted? Looking at both coronation weekend days, we saw a similar pattern (growth in traffic at around the time of the coronation ceremony on Saturday, and decrease on Sunday) in all of them. Looking at the Sunday drop, England had as much as 16% in traffic at 15:30; Scotland had as much as a 17% drop at around 13:30; Wales had as much as a 19% drop at around 15:00; and Northern Ireland had as much as an 18% drop in traffic, compared to the previous week, at the same time. Wales had the biggest drop.

Last year, in early June, we observed the impact of Queen Elizabeth II’s Platinum Jubilee on the Internet in the UK. This event, which celebrated the first British monarch to reach a 70th anniversary on the throne, caused a significant drop in traffic, as much as 25% (on Sunday, June 5, 2022). This trend was also noticeable in other Commonwealth countries.

Several Commonwealth countries also held notable events to celebrate both the Queen’s Platinum Jubilee and the recent coronation. In Canada, events and activities related to the coronation mirrored those for the Queen’s Platinum Jubilee. Whether related or not, we observed on Saturday, May 6, as much as an ~8% drop in Internet traffic compared to the previous week, between 09:30 and 16:30 Toronto time. On Sunday, the drop was even larger, with about 10% less traffic between 10:30 and 12:00.

In Australia, the difference in traffic wasn't as pronounced as in Canada. However, traffic was 7% lower than the previous week at 20:00 Sydney time (10:00 UTC), when the coronation ceremony began on May 6. This was the only period over the past weekend when traffic was lower than the previous one.

And what about the impact on DNS traffic to our 1.1.1.1 resolver from UK users? Social media apps certainly felt the ripple. Domains linked to social media platforms, which typically surge in popularity during major events, such as Twitter, experienced a notable uptick. We saw a 33% increase in DNS traffic in those around 14:00 local time on Saturday, May 6, compared to the previous week. By 18:00 on May 7, traffic had soared to 64% higher, and it remained elevated during the Coronation Concert: at 22:00, it was 36% higher.

Meanwhile, video-centric social media platforms, like TikTok, hit their peak at around 20:00 on May 7, when the Coronation Concert was starting, with a whopping 57% surge in DNS traffic.

During the coronation weekend, the peak period for DNS traffic to domains related to the royal family fell between 11:00 and 12:00 local time. In this hour, traffic was an impressive forty times higher than the same time the previous weekend (that growth is higher, more than 40x, when using a May 2022 baseline, as is seen in the next chart).

If we broaden our view to the past 12 months, we see that the domains associated with the royal family hit their highest point on the day Queen Elizabeth II passed away, September 8. Around 18:00 local time, DNS traffic was 12x higher than the previous week. This was followed by the day of Her Majesty's funeral, September 19, when around 11:00, DNS traffic was 6x higher than usual.

A similar impact was seen, related to the Queen's death, on British news organizations, in the past 12 months. September 8, around 18:00, was the peak of the whole year in terms of DNS traffic to news organizations, according to our data. At that time, DNS traffic was 263% higher than at the same time in the previous week. During the September 19 funeral, at 11:00, DNS traffic was 24% higher than before.

During the recent coronation weekend, DNS traffic to UK news organizations on Saturday, May 6, was higher than usual during the morning by as much as 47%, at 11:00, and continued higher than before mostly during that day.

We already mentioned domain trends related to when Queen Elizabeth II passed away on September 8, 2022. But what about the impact on Internet traffic? We saw a 7% decrease in Internet traffic in the UK on that day at around 18:30 local time compared to the previous week, coinciding with the announcement of her death.

The following weekend, on Saturday, September 10, 2022, traffic was as much as 17% lower at 15:00. This was the day Charles was proclaimed the new king and people flocked to the royal palaces to pay their respects — Prince William and Kate, and Prince Harry and Meghan, paused outside Windsor Castle to read messages left by mourners.

Internet traffic dropped even further compared to the previous week during Queen Elizabeth II’s funeral: on September 19, 2022, traffic was 27% lower at 10:45. According to Wikipedia, this was when the Queen's coffin was transported from Westminster Hall to Westminster Abbey on the State Gun Carriage of the Royal Navy.

In this blog post, we've seen how a very old tradition, like the British coronation, can impact a very recent innovation, the Internet. Almost 70 years ago, Queen Elizabeth II's coronation was the first ever to be televised, at a time when television in the UK was less than 20 years old. The event, which took place at Westminster Abbey in London (the site of coronations since 1066), was watched by 27 million people in the UK alone and millions more around the world.

This time around, King Charles III's coronation could be viewed through that now old medium called television, or online, via streaming services. The Internet is much younger than Britain’s former monarch's reign or even Sir Tim Berners-Lee (born in 1955), and it was only 30 years ago that the World Wide Web protocol and code were made available royalty-free, enabling the web's widespread use.

Streaming media events online, on the other hand, at least on a large scale, are a more recent development — YouTube was launched in 2005. Looking at video platforms trends in the UK, we could see how DNS traffic was 13% higher at around 12:00, during the coronation ceremony, on May 6 — it was broadcast on YouTube.

British broadcasters, such as the BBC, also included a streaming version of the event. There, the increase in DNS traffic was even higher. Between 11:00 and 12:00, on May 6, DNS traffic was 197% higher than in the previous week.

The difference in DNS traffic to UK's streaming services was even more pronounced when Queen Elizabeth II passed away on September 8, with a 470% increase in DNS traffic around 18:00 compared to the previous week. During the Queen's funeral on September 19, DNS traffic was 150% higher around 11:00 compared to the previous week.

You can check Internet trends related to events such as Easter, Ramadan, an ongoing civil war or a relevant UK outage here in our blog. You can also monitor changes in Internet patterns as they occur on Cloudflare Radar or using the Radar API. On social media, we’re at @CloudflareRadar on Twitter or https://noc.social/@cloudflareradar.

Cloudflare Radar data shows Virgin Media traffic dropping to near-zero around 00:30 UTC, as seen in the figure below. Connectivity showed some signs of recovery around 02:30 UTC, but fell again an hour later. Further nominal recovery was seen around 04:45 UTC, before again experiencing another complete outage between around 05:45-06:45 UTC, after which traffic began to recover, reaching expected levels around 07:30 UTC.

After the initial set of early-morning disruptions, Virgin Media experienced another round of issues in the afternoon. Cloudflare observed instability in traffic from Virgin Media’s network (called an autonomous system in Internet jargon) AS5089 starting around 15:00 UTC, with a significant drop just before 16:00 UTC. However in this case, it did not appear to be a complete outage, with traffic recovering approximately a half hour later.

Virgin Media’s Twitter account acknowledged the early morning disruption several hours after it began, posting responses stating “We’re aware of an issue that is affecting broadband services for Virgin Media customers as well as our contact centres. Our teams are currently working to identify and fix the problem as quickly as possible and we apologise to those customers affected.” Further responses after service restoration noted “We’ve restored broadband services for customers but are closely monitoring the situation as our engineers continue to investigate. We apologise for any inconvenience caused.”

However, the second disruption was acknowledged on Virgin Media’s Twitter account much more rapidly, with a post at 16:25 UTC stating “Unfortunately we have seen a repeat of an earlier issue which is causing intermittent broadband connectivity problems for some Virgin Media customers. We apologise again to those impacted, our teams are continuing to work flat out to find the root cause of the problem and fix it.”

At the time of the outages, www.virginmedia.com, which includes the provider’s status page, was unavailable. As seen in the figure below, a DNS lookup for the hostname resulted in a SERVFAIL error, indicating that the lookup failed to return a response. This is because the authoritative nameservers for virginmedia.com are listed as ns{1-4}.virginmedia.net, and these nameservers are all hosted within Virgin Media’s network (AS5089) and thus are not accessible during the outage.

Although Virgin Media has not publicly released a root cause for the series of disruptions that its network has experienced, looking at BGP activity can be instructive.

BGP is a mechanism to exchange routing information between networks on the Internet. The big routers that make the Internet work have huge, constantly updated lists of the possible routes that can be used to deliver each network packet to its final destination. Without BGP, the Internet routers wouldn't know what to do, and the Internet wouldn't exist.

The Internet is literally a network of networks, or for math fans, a graph, with each individual network a node in it, and the edges representing the interconnections. All of this is bound together by BGP, which allows one network (Virgin Media, for instance) to advertise its presence to other networks that form the Internet. When Virgin Media is not advertising its presence, other networks can’t find its network and it becomes effectively unavailable.

BGP announcements inform a router of changes made to the routing of a prefix (a group of IP addresses) or entirely withdraws the prefix, removing it from the routing table. The figure below shows aggregate BGP announcement activity from AS5089 with spikes that align with the decreases and increases seen in the traffic graph above, suggesting that the underlying cause may in fact be BGP-related, or related to problems with core network infrastructure.

We can drill down further to break out the observed activity between BGP announcements (dark blue) and withdrawals (light blue) seen in the figure below, with key activity coincident with the loss and return of traffic. An initial set of withdrawals are seen just after midnight, effectively removing Virgin Media from the Internet resulting in the initial outage.

A set of announcements occurred just before 03:00 UTC, aligning with the nominal increase in traffic noted above, but those were followed quickly by another set of withdrawals. A similar announcement/withdrawal exchange was observed at 05:00 and 05:30 UTC respectively, before a final set of announcements restored connectivity at 07:00 UTC.

Things remained relatively stable through the morning into the afternoon, before another set of withdrawals presaged the afternoon’s connectivity problems, with a spike of withdrawals at 15:00 UTC, followed by additional withdrawal/announcement exchanges over the next several hours.

Track ongoing traffic trends for Virgin Media on Cloudflare Radar, and follow us on Twitter and Mastodon for regular updates.

Black Friday by Per-Olof Forsberg, license: CC BY 2.0

To try and answer this question, we took a look at anonymised samples of HTTP requests crossing our network. First of all, let’s look at total page views from across our global network from the last few weeks and see if we can spot Black Friday and Cyber Monday:

All page views

So this is total page views by day (UTC) from November 19 (a week before Cyber Monday) until Monday December 3. Other than follow-the-sun fluctuations in a repeating daily pattern, each whole day is pretty similar in shape and size compared to the last. Black Friday and Cyber Monday aren’t visible in overall traffic patterns.

We have a very diverse set of customers across 12 million domain names and not all of them are selling products or doing so directly online. To identify those websites that are, I used metadata from the wonderful HTTP Archive project to export a list of domains using Cloudflare that were also running ecommerce software.

Here are the page views for these ecommerce sites over the same time period:

Ecommerce page views

So we can see clearly that our ecommerce customers are seeing a big increase in page views on November 23 and 26. Black Friday and Cyber Monday are most certainly a thing. This year Black Friday was quite a bit busier than Cyber Monday - around 22% busier in terms of page views. If we compare the page views of each day to the week prior, we can see the changes clearly:

% page view change vs previous week

The uplift starts on Wednesday but really kicks in during Thanksgiving with an increase of more than 100% on Black Friday.

So we’ve established that these shopping days are important in terms of visitor activity. More pages are being viewed on these days - but is anyone buying anything?

We’re dealing with trillions of requests across a really large data set of different websites without any specific knowledge of what a purchase transaction would look like for each - so to approximate this I took a crude approach, which is to look for successful checkout interactions in the data. If you imagine a typical ecommerce application makes a purchase with a HTTP request like “POST /store/checkout HTTP/1.1” we can look for requests similar to this to understand the activity.

% of checkout interactions vs prior week

We can see here that Black Friday has an almost 200% increase in checkout interactions compared to the previous Friday.

Using this raw number of checkout interactions to compare with the page views we have something approximating a conversion %. This is not a true conversion figure - calculating a true conversion figure would require data that identifies individuals and detailed action tracking for each website. What we have is the total number of page views (HTTP requests that return HTML successfully) compared to the total number of POST requests to a checkout. This gives us a baseline to compare changes in “conversion” over these big November shopping days:

% of checkout interactions / page views vs prior week

Each bar on this chart represents the % change in checkout interactions as a proportion of page views compared to the same day the previous week. We can see this increased by 45% on Black Friday compared to the Friday before (boring old beige Friday November 16). The following Saturday was booming at 60% - because we’re dealing with time in UTC, a UTC Saturday actually includes Black Friday traffic for some parts of the world, the same can be said of Tuesday which contains overlap from Cyber Monday - we’ll break this down a bit later.

On Cyber Monday, the increase actually beats Black Friday, meaning page views lead to cart interactions 57% more often than the prior Monday (boring old vanilla Monday November 19), albeit from a lower number of transactions.

What we see here is just how much more browsing people do on mobiles today vs desktop, with mobile winning most days:

Page Views by Device Type

When it comes to checkout interactions though, we can see the situation is switched with visitors more likely to interact with the checkout on a desktop overall, but even more so on Black Friday (14% more likely) and Cyber Monday (20% more likely).

Checkout Interaction as % of Page Views

Let’s look at a specific region to understand more, starting with the US:

USA Page Views (PST)

We can see a more normal weekday pattern on the prior Thursday & Friday (15 & 16 Nov) whereby desktop page views eclipse mobile during the daytime while people are at their desks. In the evenings and weekends, mobile takes over. What we see from the 21st onward is evidence of people taking time off work and doing more with their mobile devices. Even on Thanksgiving, there is still a big rise in activity as people start gearing up for Friday’s deals or finding ways to avoid political discussion with relatives at home!

On Cyber Monday, traffic earlier in the day is lower as people return to work, however we are seeing heavy use of desktop devices. As the working day ends, mobile once again dominates. Things begin to settle back into a more regular pattern from Tuesday November 27 onwards.

Let's take a look at checkout interaction over the Black Friday to Cyber Monday weekend by device type.

USA Checkout Interaction % (PST)

Despite all of that mobile browsing activity, desktop devices are more commonly used for checkout actions. People seem to browse more on mobile, committing to buy more often with desktop, it may also just be that mobile users have more distractions both on the device and in the real world and are therefore less likely to complete a purchase. From personal experience, I also think the poor mobile optimisation of some sites’ checkout flows make desktop preferrable - and when customers are incentivised with discounts & deals, they are more likely to switch devices to complete a transaction if they hit an issue.

It might be obvious if you’re reading this from the UK, but despite the fact that Thanksgiving is not a holiday here, retailers have very much picked up the mantle from US retailers and seized the opportunity to drive sales over this weekend.

UK Page Views (UTC)

Page views to ecommerce websites on Cloudflare look very similar in shape to the US on Black Friday. However, mobile is more dominant in the UK, even during working hours. It’s worth noting one big difference here - Cyber Monday in the UK was only 22% up in terms of page views compared to the prior Monday - in the US the increase was more than 4x that.

UK Checkout Interaction as % of Page Views

When it comes to checkout, it also looks like UK visitors to ecommerce sites commit more with their mobile, but desktop is still more likely to lead to more conversion.

Taking Germany as another example, here’s how page views look:

Germany Page Views (CET)

Desktop use during typical working hours is much more pronounced in Germany. Black Friday and Cyber Monday show higher page views than a normal Friday / Monday but the difference is much smaller than regions such as the US & UK.

Black Friday is spreading internationally despite these still being normal working days for the rest of the world. Cyber Monday is also increasing ecommerce activity internationally but tends to be quieter than Black Friday. Overall, mobile browsing eclipses desktop, but those desktop page views tend to lead to checkout more often.

Retailers should continue to invest in making their mobile & desktop ecommerce experiences fast & resilient to seize on these key days.

Photo by Nick Karvounis / Unsplash

Are you based in Copenhagen or London? Drop by one or all of these five events.

Ross Guarino and Terin Stock, both Systems Engineers at Cloudflare are traveling to Europe to lead Go and Kubernetes talks in Copenhagen. They'll then join Junade Ali and lead talks on their use of Go, Kubernetes, and Cloudflare’s Mobile SDK at Cloudflare's London office.

My Developer Relations teammates and I are visiting these cities over the next two weeks to produce these events with Ross, Terin, and Junade. We’d love to meet you and invite you along.

Our trip will begin with two meetups and a conference talk in Copenhagen.

Tuesday, 1 May: 17:00-21:00

Location: Trifork Copenhagen - Borgergade 24B, 1300 København K

How to extend your Kubernetes cluster

A brief introduction to controllers, webhooks and CRDs. Ross and Terin will talk about how Cloudflare’s internal platform builds on Kubernetes.

Speakers: Ross Guarino and Terin Stock

View Event Details & Register Here »

Wednesday, 2 May: 18:00-21:00

Location: Falcon.io - H.C. Andersen Blvd. 27, København

Talk 1: Building Go with Bazel

Fast and Reproducible go builds with Bazel. Learn how to remove Makefiles from your repositories.

Speaker: Ross Guarino

Talk 2: Internationalization in Go

Explore making effective use of Go’s internationalization and localization packages and easily making your applications world-friendly.

Speaker: Terin Stock

View Event Details & Register Here »

Friday, 4 May: 14:45-15:20

Location: KubeCon + CloudNativeCon 2018 - Bella Center, Center Blvd. 5, 2300 København

If you happen to be attending KubeCon + CloudNativeCon 2018, check out Terin and Ross’s conference talk as well.

This session demonstrates how to leverage Kubernetes Controllers and Initializers as a framework for building transparent extensions of your Kubernetes cluster. Using a live coding exercise and demo, this presentation will showcase the possibilities of the basic programming paradigms the Kubernetes API server makes easy.

Speakers: Ross Guarino and Terin Stock

View Event Details & Register Here »

Photo by Paul Buffington / Unsplash

When KubeCon + CloudNativeCon 2018 concludes, we're all heading to the Cloudflare London office where we are hosting two more meetups.

Wednesday, 9 May: 18:00-20:00

Location: Cloudflare London - 25 Lavington St, Second floor | SE1 0NZ London

This session demonstrates how to leverage Kubernetes Controllers and Initializers as a framework for building transparent extensions of your Kubernetes cluster. Using a live coding exercise and demo, this presentation will showcase the possibilities of the basic programming paradigms the Kubernetes API server makes easy. As an SRE, learn to build custom integrations directly into the Kubernetes API that transparently enhance the developer experience.

Speakers: Ross Guarino and Terin Stock

View Event Details & Register Here »

Thursday, 10 May: 18:00-20:00

Location: Cloudflare London - 25 Lavington St, Second floor | SE1 0NZ London

Whether you're building an e-commerce app or a new mobile game, chances are you'll be needing some network functionality at some point when building a mobile app. Network performance can vary dramatically between carriers, networks, and APIs, but far too often mobile apps are tested inconsistent conditions with the same decent network performance. Fortunately we can iterate on our apps by collecting real-life performance measurements from your users; however, unfortunately existing mobile app analytics platforms only provide visibility into in-app performance but have no knowledge about outgoing network call.

This talk will cover how you can easily collect vital performance data from your users at no cost and then use this data to improve your apps' reliability and experience, discussing the tips and tricks needed to boost app performance.

Speaker: Junade Ali

View Event Details & Register Here »

Ross Guarino is a Systems Engineer at Cloudflare in charge of the technical direction of the internal platform. He’s determined to improve the lives of developers building and maintaining everything from a simple function to complex globally distributed systems.

Terin Stock is a long-time engineer at Cloudflare, currently working on building an internal Kubernetes cluster. By night, he hacks on building new hardware projects. Terin is also a member of gulp.js core team and the author of the Sticker Standard.

Junade Ali is a software engineer who is specialised in computer security and software architecture. Currently, Junade works at Cloudflare as a polymath, and helps make the Internet more secure and faster; prior to this, he was a technical lead at some of the UK's leading digital agencies before moving into architecting software for mission-critical road-safety systems.

We'll hope to meet you soon!

You can watch the complete talk below or just read my summarized transcript.

Update: you might want to watch my more recent and extended 33c3 talk instead.

The Q&A session is open! Send us your questions about TLS 1.3 at tls13@cloudflare.com or leave them in the Disqus comments below and I'll answer them in an upcoming blog post.

.post-content iframe { margin: 0; }

To understand why TLS 1.3 is awesome, we need to take a step back and look at how TLS 1.2 works. In particular we will look at modern TLS 1.2, the kind that a recent browser would use when connecting to the CloudFlare edge.

The client starts by sending a message called the ClientHello that essentially says "hey, I want to speak TLS 1.2, with one of these cipher suites".

The server receives that and answers with a ServerHello that says "sure, let's speak TLS 1.2, and I pick this cipher suite".

Along with that the server sends its key share. The specifics of this key share change based on what cipher suite was selected. When using ECDHE, key shares are mixed with the Elliptic Curve Diffie Hellman algorithm.

The important part to understand is that for the client and server to agree on a cryptographic key, they need to receive each other's portion, or share.

Finally, the server sends the website certificate (signed by the CA) and a signature on portions of ClientHello and ServerHello, including the key share, so that the client knows that those are authentic.

The client receives all that, and then generates its own key share, mixes it with the server key share, and thus generates the encryption keys for the session.

Finally, the client sends the server its key share, enables encryption and sends a Finished message (which is a hash of a transcript of what happened so far). The server does the same: it mixes the key shares to get the key and sends its own Finished message.

At that point we are done, and we can finally send useful data encrypted on the connection.

Notice that this takes two round-trips between the client and the server before the HTTP request can be transferred. And round-trips on the Internet can be slow.

Enter TLS 1.3. While TLS 1.0, 1.1 and 1.2 are not that different, 1.3 is a big jump.

Most importantly, establishing a TLS 1.3 connection takes one less round-trip.

In TLS 1.3 a client starts by sending not only the ClientHello and the list of supported ciphers, but it also makes a guess as to which key agreement algorithm the server will choose, and sends a key share for that.

(Note: the video calls the key agreement algorithm "cipher suite". In the meantime the specification has been changed to disjoin supported cipher suites like AES-GCM-SHA256 and supported key agreements like ECDHE P-256.)

And that saves us a round trip, because as soon as the server selects the cipher suite and key agreement algorithm, it's ready to generate the key, as it already has the client key share. So it can switch to encrypted packets one whole round-trip in advance.

So the server sends the ServerHello, its key share, the certificate (now encrypted, since it has a key!), and already the Finished message.

The client receives all that, generates the keys using the key share, checks the certificate and Finished, and it's immediately ready to send the HTTP request, after only one round-trip. Which can be hundreds of milliseconds.

One existing way to speed up TLS connections is called resumption. It's what happens when the client has connected to that server before, and uses what they remember from the last time to cut short the handshake.

How this worked in TLS 1.2 is that servers would send the client either a Session ID or a Session Ticket. The former is just a reference number that the server can trace back to a session, while the latter is an encrypted serialized session which allows the server not to keep state.

The next time the client would connect, it would send the Session ID or Ticket in the ClientHello, and the server would go like "hey, I know you, we have agreed on a key already", skip the whole key shares dance, and jump straight to Finished, saving a round-trip.

So, we have a way to do 1-RTT connections in 1.2 if the client has connected before, which is very common. Then what does 1.3 gain us? When resumption is available, 1.3 allows us to do 0-RTT connections, again saving one round trip and ending up with no round trip at all.

If you have connected to a 1.3 server before you can immediately start sending encrypted data, like an HTTP request, without any round-trip at all, making TLS essentially zero overhead.

When a 1.3 client connects to a 1.3 server they agree on a resumption key (or PSK, pre-shared key), and the server gives the client a Session Ticket that will help it remember it. The Ticket can be an encrypted copy of the PSK—to avoid state—or a reference number.

The next time the client connects, it sends the Session Ticket in the ClientHello and then immediately, without waiting for any round trip, sends the HTTP request encrypted with the PSK. The server figures out the PSK from the Session Ticket and uses that to decrypt the 0-RTT data.

The client also sends a key share, so that client and server can switch to a new fresh key for the actual HTTP response and the rest of the connection.

0-RTT comes with a couple of caveats.

Since the PSK is not agreed upon with a fresh round of Diffie Hellman, it does not provide Forward Secrecy against a compromise of the Session Ticket key. That is, if in a year an attacker somehow obtains the Session Ticket key, it can decrypt the Session Ticket, obtain the PSK and decrypt the 0-RTT data the client sent (but not the rest of the connection).

This is why it's important to rotate often and not persist Session Ticket keys (CloudFlare rotates these keys hourly).

TLS 1.2 has never provided any Forward Secrecy against a compromise of the Session Ticket key at all, so even with 0-RTT 1.3 is an improvement upon 1.2.

More problematic are replay attacks.

Since with Session Tickets servers are stateless, they have no way to know if a packet of 0-RTT data was already sent before.

Imagine that the 0-RTT data a client sent is not an HTTP GET ("hey, send me this page") but instead an HTTP POST executing a transaction like "hey, send Filippo 50$". If I'm in the middle I can intercept that ClientHello+0-RTT packet, and then re-send it to the server 100 times. No need to know any key. I now have 5000$.

Every time the server will see a Session Ticket, unwrap it to find the PSK, use the PSK to decrypt the 0-RTT data and find the HTTP POST inside, with no way to know something is fishy.

The solution is that servers must not execute operations that are not idempotent received in 0-RTT data. Instead in those cases they should force the client to perform a full 1-RTT handshake. That protects from replay since each ClientHello and ServerHello come with a Random value and connections have sequence numbers, so there's no way to replay recorded traffic verbatim.

Thankfully, most times the first request a client sends is not a state-changing transaction, but something idempotent like a GET.

TLS 1.3 is not only good for cutting a round-trip. It's also better, more robust crypto all around.

Most importantly, many things were removed. 1.3 marked a shift in the design approach: it used to be the case that the TLS committee would accept any proposal that made sense, and implementations like OpenSSL would add support for it. Think for example Heartbeats, the rarely used feature that cause Heartbleed.

In 1.3, everything was scrutinized for being really necessary and secure, and scrapped otherwise. A lot of things are gone:

• the old static RSA handshake without Diffie Hellman, which doesn't offer Forward Secrecy

• the CBC MAC-then-Encrypt modes, which were responsible for Vaudenay, Lucky13, POODLE, LuckyMinus20... replaced by AEADs

• weak primitives like RC4, SHA1, MD5

• compression

• renegotiation

• custom FFDHE groups

• RSA PKCS#1v1.5

• explicit nonces

We'll go over these in more detail in future blog posts.

Some of these were not necessarily broken by design, but they were dangerous, hard to implement correctly and easy to get wrong. The new excellent trend of TLS 1.3 and cryptography in general is to make mistakes less likely at the design stage, since humans are not perfect.

A new version of a protocol obviously can't dictate how older implementations behave and 1.3 can't improve the security of 1.2 systems. So how do you make sure that if tomorrow TLS 1.2 is completely broken, a client and server that both support 1.2 and 1.3 can't be tricked into using 1.2 by a proxy?

A MitM could change the ClientHello to say "I want to talk at most TLS 1.2", and then use whichever attack it discovered to make the 1.2 connection succeed even if it tampered with a piece of the handshake.

1.3 has a clever solution to this: if a 1.3 server has to use 1.2 because it looks like the client doesn't support 1.3, it will "hide a message" in the Server Random value. A real 1.2 will completely ignore it, but a client that supports 1.3 would know to look for it, and would discover that it's being tricked into downgrading to 1.2.

The Server Random is signed with the certificate in 1.2, so it's impossible to fake even if pieces of 1.2 are broken. This is very important because it will allow us to keep supporting 1.2 in the future even if it's found to be weaker, unlike we had to do with SSLv3 and POODLE. With 1.3 we will know for sure that clients that can do any better are not being put at risk, allowing us to make sure the Internet is for Everyone.

So this is TLS 1.3. Meant to be a solid, safe, robust, simple, essential foundation for Internet encryption for the years to come. And it's faster, so that no one will have performance reasons not to implement it.

TLS 1.3 is still a draft and it might change before being finalized, but at CloudFlare we are actively developing a 1.3 stack compatible with current experimental browsers, so everyone can get it today.

The TLS 1.3 spec is on GitHub, so anyone can contribute. Just while making the slides for this presentation I noticed I was having a hard time understanding a system because a diagram was missing some details, so I submitted a PR to fix it. How easy is that!?

Like any talk, at the end there's the Q&A. Send your questions to tls13@cloudflare.com or leave them in the Disqus comments below and I'll answer them in an upcoming blog post!

Photo source: Andy B; images used under creative commons license.

Our new point of presence in Manchester, UK brings the CloudFlare network to 63 points of presence across 33 countries. In other words, the sun never sets across the CloudFlare network. Our data center in Manchester also admits the United Kingdom into a small club of countries with more than one CloudFlare data center, including the US, China, Japan, Australia, Germany, and France.

As of yesterday, traffic from the majority of Internet users in Northern England is now mere milliseconds away. More importantly, our Manchester and London data centers allow for redundancy and content localization within the UK for all of our customers.

The city of Manchester has made more than its fair share of technical contributions over the years. It is the city where Rolls met Royce (their first car drove off the line of their Manchester factory in 1904), and is also home to the first modern computer. The computer, nicknamed "Baby", was built at The University of Manchester using technology developed for WWII communications equipment, and ran the world's first stored program at 11am on Monday 21st June, 1948.

It is fitting, then, that in the last three years there has been a concerted effort to turn Manchester into a second hub for Internet traffic outside of London. We are proud to join this effort, and announce that we are the latest members of IX Manchester, a rapidly growing peering exchange serving the North of England. IX Manchester marks the 11th peering exchange we've turned up in just the past 3 months (to learn more about peering read our post here).

What does this mean for you? If you are a CloudFlare customer, it means that your web site is faster (your content is served closer to your visitors), safer (another facility to mitigate attacks), and always online (yet another redundant data center to serve your traffic). Best of all, you don't have to do anything! The benefits are free, automatic, and constantly growing. If you'd like to help us build a better web for everyone, consider signing up here.

— The CloudFlare team

CC BY-SA 2.0 by Yuko Honda (cropped, resized)

CloudFlare uses Go extensively to build our service and we need to people to build and maintain those systems. We've written a complete DNS server in Go, our Railgun service is all Go and we're moving more and more systems to Go programs.

We've recently written about our open source Red October Go project for securing secrets, and open-sourced our CFSSL Go-based PKI package. Go is now making its way into our data pipeline and be used for processing huge amounts of data.

We even have a Go-specific section on our GitHub.

If you're interested in working in Go on a high-performance global network like CloudFlare, send us an email.

Not into Go? We're hiring for all sorts of other positions and technologies.

Previously, only third-level domains have been available to the public, in the form .co.uk and .org.uk This is in contrast to other countries such as France and Germany who have always been able to register second-level .fr and .de domains.

According to Nominet, within the first 24 hours of .uk domains becoming available, 50,000 have been registered. Owners of a .co.uk address are given the option to also register the shorter .uk version of their domain for the next 5 years, allowing businesses and personal users to register the shorter version without fear that the domain would be taken by someone else. The third-level UK domains can be used alongside .uk, and will continue to work as before.

As of now, CloudFlare users can set up .uk domain names with CloudFlare in the usual way through their accounts, from within the My websites section.

As a Technical Support Engineer I get to work with many different members of the CloudFlare family and with customers from all around the world. Each day is very different to the next, and of course, some days stand out more than others.

Recently, I spent a bit of time working with a customer on an issue that was causing severe performance degradation on their website. The initial inquiry described a website that was yet to be publicised so it wasn’t seeing very much traffic. However, pages on the site were taking almost a minute to load. Throughout the day I worked with both the customer and other members of the support team to eliminate all the possible causes of the performance degradation. The main areas we looked at were:

• Did the customer’s server run out of resources?

• Was there anything preventing assets from being cached?

• Had the ISP of the customer caused traffic to be routed strangely?

• Were there any parts of the site that were noticeably slower than others?

• Did performance change when browsing the customer’s server directly?

After eliminating each of those points, it was unclear to us what was causing the issue. At this point we decided to make some configuration changes within the customer’s CloudFlare account. The main thing we did was to set up a few Page Rules to force everything under a certain URL pattern to be cached. The motivation for doing this was to ensure the site was fast for visitors while we continued to work on the performance issue behind the scenes. Another feature enabled for this CloudFlare Business customer was Railgun, to improve performance on any pages that we couldn’t set a Cache Everything page rule on.

After a careful examination of exactly what was running on the customer’s server we managed to find what was causing the issues — it was an installation of a caching programme on the origin that was taking up too much CPU, causing the web server to have to wait a long time before it could respond to any incoming requests. Upon disabling the programme the CPU load on the server dropped dramatically, this hugely improved performance.

By the end of the day the issue was solved and the customer had some extra CloudFlare features enabled to fully optimise the performance of their website — a great day working with a customer.

About Marty

Though he’d love to be at a Formula 1 race track any day of the week, we have convinced Marty to hang out in our UK office and help our customers. Previously a developer, Marty came to CloudFlare in the most awesome of ways: he was a customer. He’s now excited to be behind the scenes making the CloudFlare experience better for everyone. On his off days, he’ll be traveling between Formula 1 race tracks throughout the world.

The London Support Team (Marty is on the far left)

Do you have the enthusiasm to work with a technically motivated team? Do you enjoy working with a diverse global customer base? Are you somebody who uses their intuition to solve problems? CloudFlare is hiring Technical Support Engineers in London and San Francisco.

Photo by Viktor Forgacs / Unsplash

We've mentioned before that we're using Go internally for projects such as Railgun (and a new DNS server and SSL infrastructure amongst other things). And we've mentioned that we are opening an office in London.

Now we're putting those two things together by sponsoring and helping to organize a new Go London User Group. The first meeting is on March 27 at Makers Academy. CloudFlare will be providing food and drink. Speakers will be announced closer to the date. Be sure to sign up as we have limited space (and if it's full please put yourself on the waiting list so we can gauge how large the interest is).

Feel free to suggest speakers and talks of interest in the comments.

We're also actively hiring Go (and other) programmers in London and San Francisco.

As CloudFlare's customer base and network have grown our need for 24 hour operations and technical support has grown. At the moment keeping things running means keeping people awake in California. With data centers in 23 locations around the world and customers in every country CloudFlare staff have to keep things humming day and night.

And so CloudFlare will expand in the next couple of months with an office in London.

We believe that London will make an ideal base for operations and technical support to complement our San Francisco office, and we can dip into the rich London talent pool to find people.

We keep our Join Our Team page updated with positions on in London. These include Technical Customer Support andTechnical Operations Engineer.

Keep an eye out for new openings as we expand into London.

There were two talks: I was preceded by designer Laura Kalbag who talked about designing icons for WordPress sites. This is something that she made look incredibly easy using a tool called Sketch. I suspect that however good Sketch is, I'd end up drawing icons that looked awful!

My talk was about using WordPress and CloudFlare together. CloudFlare has a ton of features and I highlighted some that are of great interest to WordPress users including the CloudFlare WordPress Plugin and our integration with W3TC.

The other features that people found most interesting were:

1. Always Online: CloudFlare crawls the WordPress site and keeps a copy in a special cache. If the original site goes down CloudFlare serves up the most recent version from the crawler cache with a banner indicating that it is old content. This helps keep sites online when things go badly wrong.

2. Auto-minify: many WordPress sites have large amount of HTML, CSS, and JavaScript (especially if they use lots of plugins). Auto-minify helps shrink those resources so that sites are delivered faster to web browsers.

3. Rocket Loader: a tool that reorganizes the loading of resources such as CSS and JavaScript to that they are downloaded to web browsers quickly by bundling them.

4. A new, unannounced feature that I'm calling "Help, I've gone viral!" which allows any web site owner to instantly tell CloudFlare to start completely caching a URL (overriding any caching headers set by the site) to cope with load. With this if a URL goes viral and is overloading a WordPress site it's possible to just paste in its URL and ask CloudFlare to take the load of that page. We'll be writing more about that feature when it's released.

And, of course, other CloudFlare features like Easy SSL, SPDY, and IPv6 help everyone get the latest technology onto their site quickly.

You don't need to be a CloudFlare customer to take part, but sign up here.

As our network map will soon indicate, CloudFlare's London (LHR) data center is now online. The team started routing traffic through it this beginning at 12:13 GMT. We're already doing more than 1Gbps of traffic through LHR, most of which would previously have been routed to Amsterdam.

London was one of the most requested regions for us to support from users and hosting partners alike. We're up to 13 data centers worldwide, and London is our fourth European data center — joining Amsterdam (AMS), Paris (CDG), and Frankfurt (FRA) — continuing to expand CloudFlare's global reach. One of our core benefits is that CloudFlare allows a business to host anywhere and ensure their site is fast for all their customers worldwide. In an increasingly global world, that's important for companies large and small.

Our goal is to make the Internet fast and safe for everyone, regardless of where they're located. We will continue to expand our network and plan on rolling out another new data center in about three weeks to help service one of our fastest growing regions. Let the speculation begin!