Peakhour.IO - Interest

Cloudflare outage proves Plan B depends on controlling DNS

2025-11-18T21:00:00+11:00

On Tuesday, 18 November 2025, Cloudflare’s own status page marked every major service—CDN, Firewall, WARP, Workers, and the dashboard—as degraded for most of the day while engineers worked through an internal control-plane failure. The timeline moved from “Investigating” at 11:48 UTC to “Monitoring” after 14:42 UTC, and the incident wasn’t officially resolved until 19:28 UTC. During the worst of it, Cloudflare disabled WARP in London, bot scores seesawed, and customers were told to wait while remediation continued.

Waiting was the only option for many teams because their Plan B lived behind the same dashboard that was timing out. The top comment on the Hacker News thread was a set of curl commands for moving domains off Cloudflare’s proxy edge. Admins were stuck in 2FA flows trying to fetch an API token, or searching for Terraform credentials so they could toggle a proxied flag. That is not a resilience strategy.

We learned this lesson the hard way—and wrote about it after the 2021 Fastly outage in How to have a Plan B. The rule still stands: the platform you are trying to leave cannot be the only place that can change where your DNS points.

Detect: understand what’s actually broken

Incidents like Tuesday’s change shape quickly. Cloudflare’s own feed showed different failure domains every 30 minutes: bot management, dashboard auth, Access, WARP. The first mile is impartial telemetry that tells you what your users feel, not what the provider thinks. At Peakhour we stream real user monitoring, synthetic checks, and control-plane health from multiple CDNs and DNS partners. That lets us distinguish “cache errors in Hong Kong” from “global auth outage” and choose the right lever.

Decide: keep DNS authority in neutral territory

When your domain delegation lives with agnostic providers—Route 53, NS1, Azure DNS, or the enterprise registrar your legal team already approved—you can make failover decisions without pleading with a failing control plane. Peakhour doesn’t replace those vendors; we orchestrate them. We set short-but-safe TTLs, keep secondary answers staged, and continuously audit API access so we can flip traffic with one signed request. The minute you outsource DNS authority to a proxy CDN, you have given up the control that makes Plan B possible.

Divert: run the playbook in minutes, not hours

A workable Plan B has three moves:

Pre-stage alternate edges. Your secondary CDN, origin, or transit provider must be in sync with the active one—certificates, cache rules, WAF policies, everything. We keep them hot by replaying production configs across vendors.
Wire DNS automation. We integrate with multiple third-party DNS APIs at once so we can update apex A/AAAA, flattened CNAMEs, and geo/latency rules in a single workflow. Because the automation lives off the impacted platform, we can execute even while Cloudflare’s dashboard is returning 500s.
Drill humans on the handoff. Our SOC sits in Sydney and Melbourne, but we cover global hours. During an incident we line up Slack/Teams bridges with your SREs, confirm business impact, and keep execs in the loop while traffic drains to the healthy provider.

With that in place we routinely hit sub-five-minute diversion times, including DNS propagation, because the decision, the tooling, and the people are ready before the outage hits.

What Peakhour brings to your Plan B

Independent authority, familiar vendors. We leverage multiple established DNS providers instead of locking you into ours. You keep your contracts; we bring the automation and guardrails.
Unified multi-CDN config. Cache rules, image optimisation, WAF, and routing policies stay aligned across providers so you don’t lose capabilities when you switch.
Real drills, not just runbooks. Quarterly failover exercises prove that certificates, APIs, and humans are ready. We share the post-mortems so your execs see clear RTO/RPO numbers.
People you can phone. 24×7 Australian-based engineers who know your stack and can execute the play while your own team communicates with customers.

Book a resilience review

If Tuesday exposed that your failover path still depends on your primary provider’s dashboard, book a 30-minute Resilience Review with Peakhour and we’ll:

Map who really controls your DNS today.
Identify the gaps between your primary and standby CDNs.
Outline the automations we can layer on top of your existing DNS and hosting vendors.

The output is a concrete Plan B, a drill schedule, and a team that can execute it the next time a global provider blinks.

Why Don't We Have an AI UI Yet?

2025-07-20T00:00:00+10:00

In my last post, I made the case that Artificial Intelligence is the next great computer interface: a way to translate our intentions directly into actions. It is a powerful idea, but it immediately raises the practical question. If this is the future, where is it? Why am I still clicking icons and navigating menus on my computer instead of just talking to it?

The concept is much cleaner than the implementation. We are still a fair way from having a true AI-native interface, and there are some hard problems to solve before it becomes the main way we use a computer.

The Understanding Problem

The first challenge is that current AIs don't truly understand things in the way humans do. When you ask an AI to "write a summary of last quarter's sales," it doesn't know what a "sale" is or what a "quarter" means to the business. It is an extremely capable pattern-matching machine that knows which words and concepts are statistically likely to follow your request.

That is useful for generating text or code, but it can also lead to "hallucinations"—where the AI confidently makes things up. For a chatbot, that might be annoying. For a computer's operating system, it is a critical failure. You can't have an interface that might invent a file that doesn't exist or misinterpret a crucial command.

The Action and Safety Problem

An AI interface needs to do more than just talk; it needs to act. It must be able to open programs, manage files, change settings, and send emails. That requires giving the AI deep access to the core functions of the operating system, which is where the idea stops feeling neat and starts feeling risky.

How do you give an AI the power to delete files based on a verbal command without creating a massive security hole? How do you ensure it can't be tricked by a cleverly worded prompt (or an external attacker) into causing chaos on your system? Creating a safe and reliable bridge between the AI's language processing and the computer's functions is a hard engineering problem.

The Trust and Reliability Problem

For an AI interface to be useful, we have to trust it completely. If you tell it to "delete my old holiday photos from 2018," you need to be certain it won't misunderstand and delete your wedding photos or important work documents.

This need for absolute reliability runs counter to the probabilistic nature of today's AI models. We can't have an interface that is "mostly right." It needs to be right every single time. The hard part is adding the necessary safeguards and confirmation steps without turning the whole thing into a slower version of the menus we were trying to escape.

The Speed and Cost Problem

Finally, there is a practical issue. Running the massive language models that would power such an interface is slow and computationally expensive. A good user interface needs to feel instant and responsive. If it takes ten seconds for an AI to process your request to open a web browser, it is not a better experience than just clicking the icon yourself. The hardware and software infrastructure isn't quite ready to deliver the seamless, real-time experience we would expect from a primary computer interface.

These challenges aren't insurmountable, but they are significant. That is why I think AI will keep showing up first as powerful features within our existing apps and operating systems. Those narrower uses give it clearer jobs, tighter permissions, and more places for humans to confirm what is about to happen. The full AI interface may arrive eventually, but I don't think it appears all at once. It will earn trust in smaller pieces first.

AI as the Translator Between Human and Machine

2025-07-19T00:00:00+10:00

Think about how we've talked to computers over the years. At first, it was rigid and unforgiving. The command line expected the exact words, in the exact order. One typo, and you were met with an error. It was powerful, but only once you learned to speak the computer's language.

Then came the graphical user interface, or GUI—the familiar world of windows, icons, and mouse pointers. That changed the relationship. You no longer had to memorise commands before you could do something useful. You could see your options, click on them, and drag things around. It made computers accessible to hundreds of millions of people because it was more intuitive. It was a visual conversation.

But both of these interfaces, the command line and the GUI, share the same basic bargain: we adapt ourselves to the computer. We still have to navigate menus, find the right button, or remember a specific command. We take a goal in our head and break it into steps the computer understands.

What if that translation was no longer mainly our job? What if the computer could understand our goal well enough to work out the steps?

This is the next shift I find interesting, and it is powered by Artificial Intelligence. AI is starting to look less like another application and more like the next major interface. It's not a visual one with buttons and menus, but an intelligent one built on understanding.

The idea is simple, even if the implementation is not: we state our intent, and the AI figures out the steps. Instead of clicking through five different menus to create a sales report, you could just say, "Show me last quarter's sales figures for the eastern region, and visualise it as a bar chart." The AI's job is to understand that request and then do the work: query the database, aggregate the data, select the right chart type, and present it to you. It acts as a translator between human language and the computer's machine language.

We're already seeing the early stages of this. When you ask a smart assistant to play a song, or when an AI co-pilot writes code for you, you're using an intent-driven interface. You're not telling it how to do the task; you're just telling it what you want done.

That shift matters because it moves some of the cognitive load from us to the machine. We no longer need to be experts in using a particular piece of software; we just need to be clear about what we want to achieve. This has the potential to democratise technology on a scale we've never seen before, making complex digital tools feel closer to a conversation than a training course.

The future of computing isn't about learning more complex systems. It's about building systems that can learn from us. The interface of tomorrow won't be something we click on, but something we talk to, correct, and steer. That is the real change: technology that doesn't just follow instructions, but understands our goals.

From Research Paper to Running Code

2025-07-18T00:00:00+10:00

In my last post, I talked about my journey from typing format c: on an old DOS machine to collaborating with AI. The part I keep coming back to still feels slightly unreal: turning academic research papers directly into working code.

For years, the hard part was the distance between academia and industry. A good idea could be locked inside a dense, equation-heavy paper, and turning it into a practical tool could take a team of specialists weeks or months. You had to understand the mathematics, translate it into logic, write the code, and then debug all the places where the theory met the real world.

Now my process looks completely different. I'll find an interesting paper, give it to an AI like Gemini, and say, "code this for me". It is a conversation, not just a command. We go back and forth, clarifying ambiguities in the paper and refining the implementation. What used to take weeks of painstaking effort can now be prototyped in an afternoon.

Here are a few examples from my own experiments.

Anomaly Detection

I recently came across a paper detailing a new statistical method for detecting anomalies in time-series data. In the past, I would have spent days just trying to get comfortable with the mathematical models before writing a single line of code. This time, I fed the PDF to the AI. Within minutes, it had parsed the document and produced a Python implementation of the core algorithm. It was not perfect on the first go, but it was a solid, working foundation that we could test and refine together. The AI handled the heavy lifting of translation, leaving me to focus on validating and applying the model.

Customer Journey Mapping

Another area I have been looking at is using data to understand customer behaviour. There are academic papers that model how users interact with a website or product, mapping out their journey from discovery to purchase. Implementing these models used to be a serious undertaking. Now, I can give the AI a paper on a new journey mapping technique, and it can generate the code to analyse server logs or user event data and produce the kind of insights the paper describes. That makes it much easier to experiment with new ways of understanding our customers.

Building Small Language Models

This is where it gets really interesting. We can use large language models (LLMs) to help build smaller, more specialised ones. I've been experimenting with research papers that propose new, efficient LLM architectures. I can give one of these papers to a large AI and have it help me write the code for the smaller architecture. There is a beautiful irony in using a massive AI to help create its smaller, more nimble cousins. It speeds up the cycle of innovation inside the AI field itself.

For me, the important change is the shorter loop between reading an idea, testing it, and getting it into use. The friction between a theoretical concept and a working prototype has been reduced almost to zero. That means I can explore more ideas, take more risks, and bring those research ideas into real use much faster than before.

My Programming Journey

2025-07-17T00:00:00+10:00

My path into technology started with a beige box and no plan beyond seeing what it would do.

When I was a kid, I got an old 8086 computer. The only thing it came with was a thick manual for 'DOS', its operating system. For a child trying to make sense of it, the blinking C:\> prompt was not exactly welcoming. What was I meant to do with it?

I tried typing whatever came to mind, but most of it ended in errors. Then I stumbled on a command that actually did something interesting: format c:. After I typed 'Y' to confirm, the screen would fill with text, showing me its progress. I didn't realise I was wiping the computer's entire memory. I only knew the machine was finally responding.

Things properly opened up when I found a book filled with GW-BASIC programs. I wasn't just using a computer anymore; I was telling it what to do. I spent ages carefully typing out code, one line at a time. 10 PRINT "HELLO THERE", 20 GOTO 10. It was slow work, but there was something hard to beat about bringing a program to life with my own hands.

My skills moved along when QuickBasic started coming with MS-DOS. The tools were better, the language was more powerful, and I started building my own little games and applications, learning how to organise my ideas into code.

Every programmer eventually hits a wall. For me, it was a 64-kilobyte limit on a single variable. It sounds tiny now, but it blocked a project I cared about. The only way forward was to learn C, a much more complex language. It was a hard jump, but it was the way to build bigger and more powerful software.

That arc is why today's tools feel so strange to me.

For most of my career, my job was to translate human ideas into instructions a computer could follow. I had to think like a machine, breaking everything down into small, logical steps.

Now the process feels very different. I still solve problems, but I spend less time spelling out every instruction. I have a conversation with my computer. I can describe a goal, or show it a research paper, and an AI partner helps me write the code. My role has shifted from writing each line by hand to setting direction, checking the work, and deciding what is actually worth building.

Looking back, the path from blindly typing format c: to working alongside an AI still feels odd in the best way. We've moved from telling the machine exactly how to do something to describing what we want to achieve and then judging the result. That is a big change. I am still getting used to it.

RFC 9460

2023-11-16T00:00:00+11:00

RFC 9460 introduces two DNS record types: "SVCB" (Service Binding) and "HTTPS". They let browsers learn more connection details during DNS lookup, before redirects and TLS negotiation add extra steps. The result is cleaner connection setup, with practical improvements in speed, security, and efficiency.

Understanding the Current Process

Traditionally, when a browser connects to a website, it follows a sequence:

Browser requests site via HTTP.
Server redirects request to HTTPS.
Browser receives ALPN (Application-Layer Protocol Negotiation) during the HTTPS handshake.

The model is secure, but it is not optimal. It involves multiple round trips, which affects Time to First Byte (TTFB) and the overall user experience. Load balancing and failover are also less direct than they could be. RFC 9460 changes this by allowing DNS to provide the necessary connection details earlier. That reduces the steps involved in establishing a secure connection, lowering TTFB.

The Impact of SVCB and HTTPS Records

SVCB and HTTPS records move useful connection hints into DNS. They speed up the time-to-first-packet by incorporating the Alt-Svc HTTP header and ALPN TLS extension into DNS, which shortens connection setup. These records also enable redirection at the zone apex, a task not possible with CNAMEs. They simplify DNS load distribution and failover, making web services more resilient. They also remove the need for HSTS preloading and support Encrypted Client Hello (ECH), formerly ESNI, for better privacy.

Adoption and Industry Response

Adoption started before the RFC was finalised. Firefox has been conducting HTTPS lookups since May 2020, limited to DNS over HTTPS (DoH). Apple's iOS, Safari, and macOS have followed suit since September 2020. Chrome introduced partial support in December 2020 and has recently enabled ECH by default. Various DNS service providers have also started supporting HTTPS and SVCB records.

As reported on Netmeister, adoption is still early but not insignificant. As of October 2023, about 10 million domains have implemented an HTTPS record for their 'www' service names, roughly 4.4% of domains. Around 9.1 million domains, or about 4.0%, use the record on their bare second-level domain name. Among the top 1 million domains, approximately 22.5K (25.5%) use HTTPS records for 'www' service names, and nearly 24K (25.6%) use them on bare domains.

What the Records Look Like

A typical SVCB record might look like this:

_example.com. 7200 IN SVCB 1 svc4.example.net. (alpn="h2,h3" port="8004")

This record indicates that the service at _example.com can be accessed at svc4.example.net using either HTTP/2 or HTTP/3 on port 8004.

An HTTPS record could be:

example.com. 3600 IN HTTPS 0 svc.example.net.

This record suggests that example.com should be accessed securely through svc.example.net.

Apex Domains and the Importance of SVCB/HTTPS Records

One long-running DNS limitation is the inability to use CNAME records at the apex (root level) of a domain due to conflicts with other necessary records like NS and SOA. RFC 9460's SVCB/HTTPS records address this by enabling apex domain aliasing without those conflicts. This matters for efficient content delivery networks (CDNs) and load balancing strategies.

These records enhance capability

1. Load Balancing:

Consider a website that needs to distribute traffic across multiple servers. SVCB records can indicate different server endpoints with varying priorities.

example.com. IN SVCB 10 server1.example.com. (alpn="h2,h3")
example.com. IN SVCB 20 server2.example.com. (alpn="h2")

In this example, server1.example.com is the preferred endpoint (lower priority number), offering both HTTP/2 and HTTP/3 protocols. If it's unavailable, traffic automatically shifts to server2.example.com.

2. Failover Mechanism:

For a service that requires high availability, SVCB records can express failover directly:

critical-service.example.com. IN SVCB 1 primary-service.example.com. (alpn="h2,h3")
critical-service.example.com. IN SVCB 2 backup-service.example.com. (alpn="h2")

Here, primary-service.example.com is the primary endpoint. If it fails, the system automatically falls back to backup-service.example.com.

3. Apex Domain Usage:

A practical advantage of SVCB/HTTPS records is their ability to handle apex domains, where CNAME records are not feasible. This is important for root domain aliasing to different service providers.

example.com. IN HTTPS 0 cdn-provider.example.net.

This record indicates that the apex domain example.com is to be served through cdn-provider.example.net, overcoming traditional DNS limitations.

4. Encrypted ClientHello Support:

Future enhancements of SVCB could include keys for Encrypted ClientHello, which improves privacy and security during the initial TLS handshake.

secure.example.com. IN SVCB 1 tls-service.example.net. (ech="base64-encoded-key")

This record can be used to initiate a TLS connection with tls-service.example.net using the provided Encrypted ClientHello key.

5. Directing Traffic to Specific Protocols:

For services that need to direct clients to newer or more efficient protocols, SVCB records can specify the exact protocols to use.

api.example.com. IN SVCB 1 api-server.example.com. (alpn="h3")

Clients that understand HTTP/3 can connect directly using this protocol, bypassing the usual HTTP/1.1 or HTTP/2 protocols.

The Long Wait

HTTPS has been around for a while, so RFC 9460 raises an obvious question: why did this take so long? Apex records have had their share of problems, including not being able to use CNAMEs and having to resort to custom records like ALIAS or Cloudflare's 'cname flattening'.

It is a fair question. We've had some bizarre records hanging around for ages along with a wide range of solutions to the "CNAME at the zone apex" problem.

Credit to the creators of RFC 9460 for getting this through and obtaining browser support: - B. Schwartz from Meta Platforms, Inc. - M. Bishop from Akamai Technologies - E. Nygren from Akamai Technologies

Final Thoughts

RFC 9460 gives DNS a more useful role in HTTPS connection setup. SVCB and HTTPS records let operators publish endpoint, protocol, failover, and privacy information before the browser starts negotiating the connection. That gives service providers more precise control over how clients reach web services, with practical benefits for performance, reliability, and security.

Dive into CVSS Scores

2023-11-10T00:00:00+11:00

Understanding CVSS through Atlassian Confluence Vulnerabilities

The Common Vulnerability Scoring System (CVSS) gives security teams a shared way to rate the severity of software vulnerabilities. It does not predict risk on its own; it describes the characteristics of a specific security flaw. CVSS uses three metric groups: Base, Temporal, and Environmental. The result is a score from 0 to 10, represented by a vector string that records the details behind the score.

Base Metrics describe the inherent aspects of a vulnerability, including how it can be exploited and its potential system impact.
Temporal Metrics change over time, reflecting current exploitability and available mitigations.
Environmental Metrics account for the specific environment where the vulnerability exists, tailoring the score to the affected organisation.

The National Vulnerability Database (NVD) utilises CVSS to assign base scores and provides tools for calculating Temporal and Environmental scores.

Atlassian Confluence Vulnerability Analysis

Two Atlassian Confluence vulnerabilities show why the vector matters as much as the headline score:

CVE-2023-22515 is a critical flaw with a base score of 10.0. It is exploitable remotely, with low complexity, no privilege requirements, and no need for user interaction. The attack vector is network-based, so exposure is not limited to local access. Its broad scope and impact across confidentiality, integrity, and availability make it a vulnerability that needs immediate attention.

CVE-2023-22518 shares many similarities with CVE-2023-22515, including a critical base score of 10.0. It can also be exploited remotely without privileges or user interaction, and with low complexity. Its impact on the system's confidentiality, integrity, and availability is high, allowing attackers to gain complete control and shut down the affected resources.

Both CVE-2023-22515 and CVE-2023-22518 are critical vulnerabilities that demand urgent remediation. Understanding their CVSS vectors helps prioritise the security response and the mitigations needed.

CVE-2023-22515 carries a CVSS score of 10 because it is remotely exploitable, easy to execute, and does not require privileges or user interaction.

CVSS Vector for CVE-2023-22515

Base Score: 10.0 (Critical)
Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

This vector indicates:

Attack Vector (AV): Network (N) - The vulnerability is remotely exploitable.
Attack Complexity (AC): Low (L) - It is easy to exploit without major obstacles.
Privileges Required (PR): None (N) - No special access is needed.
User Interaction (UI): None (N) - It can be exploited without user involvement.
Scope (S): Changed (C) - The impact extends beyond the initial target.
Confidentiality, Integrity, Availability (C/I/A): High (H) - There is a complete loss of confidentiality, integrity, and availability.

Atlassian's high CVSS score for CVE-2023-22515 reflects its critical nature and the need for immediate action.

CVE-2023-22518 has the same CVSS score of 10, with similar impact across confidentiality, integrity, and availability.

CVSS Vector for CVE-2023-22518

Base Score: 10.0 (Critical)
Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

This vector means:

Attack Vector (AV): Network (N) - Exploitable remotely.
Attack Complexity (AC): Low (L) - Easy to exploit with minimal barriers.
Privileges Required (PR): None (N) - No user privileges required.
User Interaction (UI): None (N) - No need for user action.
Scope (S): Changed (C) - Broad impact beyond the initial system.
Confidentiality, Integrity, Availability (C/I/A): High (H) - Complete compromise of the system's security.

Understanding the CVSS scores for these vulnerabilities helps teams prioritise their security response. For a full breakdown and history of CVSS, see Wikipedia. More detailed information on CVSS can also be found in FIRST's official CVSS documentation.

A Risk Based Approach To Vulnerability Scoring

2023-11-10T00:00:00+11:00

The Exploit Prediction Scoring System (EPSS) estimates the likelihood that a published CVE will be exploited in the wild. Its value is that it brings several signals into one risk score, instead of treating every vulnerability with the same CVSS severity as equally urgent. The main inputs are:

Data Sources of EPSS

MITRE’s CVE List: EPSS scores only vulnerabilities that are "published" on this list.
Text-based “Tags”: Extracted from CVE descriptions and related discussions.
Publication Duration: The time period since the CVE was published.
Reference Count: The number of references in the CVE entry.
Published Exploit Code: Code from platforms such as Metasploit, ExploitDB, or GitHub.
Security Scanners: Data from security tools such as Jaeles and Nuclei.
CVSS v3 Vectors: Based on the base score in the National Vulnerability Database (NVD).
CPE (vendor) Information: Details about the vendors of the products involved, also from NVD.
Ground Truth Data: Real-world exploitation data from sources such as AlienVault.

EPSS Model and Tools

The current EPSS model, version 2022.01.01, uses 1,164 variables and is based on Gradient Boosting, a machine learning technique. For a visual and interactive view of EPSS scores, the EPSScall tool is useful. It provides historical data and graphs that make score movement easier to inspect.

The Drivers of EPSS Scores

To understand EPSS, it helps to look at which inputs carry the most weight. The variable importance graph shows the strongest contributors to the EPSS score.

Vendor data plays an outsized role in the scoring process. The graph shows how much weight each component has when estimating whether a vulnerability is likely to be exploited.

Why Does This Matter?

EPSS uses these data sources to predict exploit likelihood more directly than severity-only methods. By considering factors from the age of the CVE to real-world exploit instances, EPSS gives defenders a clearer view of which vulnerabilities are more likely to matter operationally. That makes patching and mitigation decisions easier to prioritise when resources are limited.

Understanding the components of EPSS also makes the score easier to interpret. It is not a single severity metric; it is a blend of several data points, each with different weight. Tools like EPSScall make those inputs easier to inspect when tuning a vulnerability management process.

Final Thoughts

EPSS is useful because it shifts vulnerability triage away from severity alone and towards exploit likelihood. Its use of multiple data sources and machine learning makes it a practical tool for defenders who need to decide what to fix first. Prioritising vulnerabilities this way does not replace judgement, but it gives teams a stronger starting point than CVSS alone.

Navigating CDN Consolidation

2023-11-01T00:00:00+11:00

The CDN industry is moving quickly, with major providers such as Akamai and Cloudflare consolidating their positions. For businesses caught in that movement, changing CDN providers is rarely a simple swap. Your CDN sits in front of your website or application, so migration decisions touch performance, security, routing, caching, and operational risk.

Market Shifts in the CDN Industry

The CDN market is being reshaped by large providers and newer entrants. Akamai's acquisition of Linode is one example, expanding its cloud services and strengthening its position beyond CDN. Cloudflare is moving in a similar direction, adding cloud-based services around its CDN platform.

Akamai's Strategic Moves

Akamai has recently bought customer contracts from both Lumen and StackPath. This is likely to lift its 2024 revenue by tens of millions of dollars. The transferred customers will also benefit from Akamai’s wider cloud and security services.

Azure CDN Standard from Akamai, StackPath CDN, and Lumen CDN are all going offline soon. Clients have received only 2-3 months' notice to migrate, which is a tight window for a service that usually has routing, security, caching, and origin dependencies. Vendors should avoid putting customers in this position. A multi-CDN strategy can reduce that exposure.

What Happened to Section.io?

Section.io, once a CDN, shifted to edge computing before being sold to Webscale. That leaves approximately 300 Australian websites looking for new service providers. If you are one of them, now is the time to act.

These moves make the decision to switch or stay with a CDN provider more complex, especially for smaller businesses that need flexible and reliable local alternatives such as Peakhour. Switching your CDN is not as straightforward as changing a DNS record. Your CDN acts as the gateway to your website or application, so a move can involve reconfiguring a large part of the delivery stack.

Why Peakhour Is the Right Choice

Peakhour is a local, reliable alternative in an industry changing quickly. We offer the flexibility needed for customisation and a full suite of services.

If you are considering a CDN switch, treat it as a technical migration rather than a procurement task. Peakhour can help make that transition smoother.

Peakhour's Top 10 Things to Consider When Changing Providers

Switching CDNs? Work through these ten factors before you move:

Caching Rules: Use the migration to review and optimise your caching settings.
POP Distribution: Understand how the new CDN's points of presence may affect your traffic.
Security Gaps: Evaluate how the new CDN's security measures compare to your current provider.
Access Lists: Make sure IP whitelists and blacklists are carried over cleanly.
Origin Security: Update IP addresses to ensure your origin server recognises the new CDN.
SSL/TLS Certificates: Confirm the new CDN supports your existing SSL/TLS settings and can carry over the certificates you need.
API Compatibility: Ensure the new CDN offers APIs that match or exceed your current usage.
Analytics and Monitoring: Assess if the new CDN's analytics tools meet your needs.
Rate Limiting: Review the new CDN's rate limiting options, especially if your site experiences traffic bursts.
Costs: Account for migration work, potential downtime, and any hidden fees.

Additional Considerations for a Seamless Transition

Beyond the top ten, also consider:

Bot Protection: Evaluate how the new CDN manages automated traffic.
User Agent Validation: Make sure the new CDN effectively screens search engine bots.
IP Reputation Lists: Know how your new CDN updates and uses IP reputation lists.
API Protection: Confirm that the new CDN provides strong API security controls.
Dynamic Page Caching: Check how the new CDN handles caching for dynamic content.
Query String Handling: Understand how your new CDN treats query strings, as this can affect cache performance after migration.

Special Concerns for E-commerce Sites

For e-commerce, also think about:

Site Integrations: Does the new CDN support plugins for your platform, such as Magento?
Custom WAF Rules and Exceptions: Ensure these can be moved to the new CDN.
Image Optimisation: Update Image APIs if your CDN handles image transformations.

Advanced Configurations

Advanced setups need closer review:

Origin Mounting: Confirm your multiple origins will work as needed with the new CDN.
Request Routing: Make sure you can replicate your existing routing configurations with the new provider.
Edge Redirects: Ensure the new CDN can handle any redirects you’ve configured at the edge.

Web scraping another Business' website

2023-10-11T13:00:00+11:00

As businesses continue to build their presence online, screen scraping is becoming more prevalent. Screen scraping is the use of software or code to take data from another website. For example, popular platforms like Skyscanner or booking.com usually take price data on flights and accommodation and display it on their websites. However, Australian copyright laws or the website owner’s terms and conditions may forbid you from screen scraping. This article explains the legal aspects of scraping data from another business’ website and the precautions you should take.

Am I Violating the Law by Screen Scraping?

Australian copyright law safeguards ‘original creative works’, including:

written works;
visual images;
music; and
moving images.

Copyright can also protect documents such as government reports and legal forms. When determining whether copyright protects a creative work, the work does not need to be intricate or of high quality. It only needs to demonstrate originality and not be copied from another source.

Is Data an ‘Original Work’?

Data is usually fact-based and primarily consists of statistics or numbers. As a result, copyright usually does not protect data.

Examples of such data include:

the consumer price index for a particular quarter;
monthly house price increases in a city;
the number of students in a class; or
the count of films released in a year.

Generally, the law does not consider this an original work because it merely represents real-world information.

What Data is an ‘Original Work’?

However, data can be an original work in some circumstances. For example, if you organise data in a unique manner that reflects someone's creativity, the law might consider that data an ‘original work’.

Examples of organised data that copyright protects include;

accounting forms;
sequences of numbers or letters for a bingo game; or
a car parts catalogue.

Consequently, screen scraping data from a website is unlikely to infringe copyright unless it involves protected, creatively organised data. Infringing someone’s copyright means using their copyright-protected material without their permission.

Are There Exceptions to Copyright Law?

In the rare event that your screen scraping infringes copyright, your use could fall under an exception to copyright infringement. Australian copyright law refers to these exceptions as 'fair dealing.'

The four ‘fair dealing’ exceptions include using copyright-protected materials for:

research or study;
review or critique;
parody or satire; and
reporting the news.

For instance, a journalist scraping original data sets to report potential price-gouging among airlines could potentially rely on the exception for reporting the news. However, if you are scraping data for business purposes, the fair dealing exceptions may not apply.

What if a Website Explicitly Bans Screen Scraping?

Even if screen scraping is not always illegal under Australian copyright law, website owners can use their terms of use to prohibit data scraping. These terms of use often appear as website pop-ups. The pop-ups typically state that by continuing to use the website, you accept the terms of use.

These terms can explicitly forbid:

data scraping;
copying;
hacking; or
any form of data extraction.

Violating these terms would result in you breaching the website’s terms of use. As a result, the website owner may take legal action against you. If the data on the website qualifies as original work, copyright infringement claims may also arise.

Therefore, it is advisable not to screen scrape from websites with explicit terms of use against that activity. If you do engage in screen scraping, ensure you only extract factual information.

Key Takeaways

Screen scraping is generally lawful if you extract strictly factual information from other websites. However, if a website's terms of use prohibit screen scraping, even for factual data, it is advisable to avoid data scraping. Otherwise, you could face potential breach of contract and copyright infringement claims.

For assistance with your legal obligations, LegalVision’s experienced IT lawyers can assist as part of their membership. For a low monthly fee, you will have unlimited access to lawyers who can answer your questions and draft and review your documents. Call LegalVision today on 1800 296 912 or visit their membership page.

A Secure Internet

2023-08-16T00:00:00+10:00

Here at Peakhour, we track browser security changes because they affect how sites are delivered and how users experience warnings. Google Chrome has made another move towards encrypted and authenticated traffic by expanding HTTPS-First Mode. Here is what Chrome unveiled on August 16, 2023, and what it means for HTTPS by default.

Automatic Upgrades to HTTPS

Chrome aims to make HTTPS the standard protocol by automatically upgrading all HTTP navigations to HTTPS. Even if you click a link explicitly declaring HTTP, Chrome will try HTTPS first. If the upgrade fails because of an invalid certificate or another issue, Chrome will fall back to HTTP.

The change is part of an experiment in Chrome version 115. It does not protect against active network attackers, but it does shift more everyday traffic away from passive eavesdropping and towards HTTPS as the default.

Warning on Insecurely Downloaded Files

Chrome is also adding warnings before users download high-risk files over insecure connections. Downloaded files can contain malicious code that compromises a computer. The warning gives users a clearer signal before they proceed, while still allowing the download if they accept the risk. The rollout of these warnings is expected to start in mid-September.

Expanding HTTPS-First Mode Protections

Chrome's longer-term goal is to enable HTTPS-First Mode for all users. It is expanding those protections in several areas:

Enabling HTTPS-First Mode for users in Google's Advanced Protection Program who are also signed into Chrome.
Planning to enable HTTPS-First Mode by default in Incognito Mode for a more secure browsing experience.
Experimenting with automatically enabling HTTPS-First Mode on sites frequently accessed over HTTPS.
Exploring automatically enabling HTTPS-First Mode for users who rarely use HTTP.

Try it Out

For users who want to try HTTPS upgrading or insecure download warnings before the full rollout, Chrome has provided options in the browser's settings to enable these features.

Peakhour's HTTPS Redirection Feature at the Edge

At Peakhour, HTTPS redirection is a practical edge control. It helps enforce encrypted and authenticated connections before a request reaches the origin.

When a user attempts to access a site over HTTP, our edge identifies the unsecured connection. Instead of allowing that connection through, we redirect the request to the HTTPS version of the site.

Enhanced Security: By enforcing HTTPS, data transmitted between your website and your users is encrypted and protected from potential attackers.
Compliance with Best Practices: This feature aligns with industry standards and recent browser policies, including Chrome's push towards HTTPS-first mode.
User Trust: A secure connection gives users a clearer reason to trust the site, improving the user experience and potentially supporting higher conversion rates.

We also offer options for customisation, allowing you to set specific rules and behaviours for how HTTP requests are handled and redirected to HTTPS. Peakhour's HTTPS redirection feature at the edge is a small control with a clear job: move HTTP traffic onto HTTPS automatically, protect users, and keep sites aligned with current browser expectations.

Final Thoughts

Chrome's push towards a secure-by-default web is another step towards a fully encrypted and authenticated internet. It also matches the way Peakhour thinks about everyday security controls: enforce the basics at the edge, and make the safe path the default.

Chrome's changes may require developers, enterprises, and users to adapt. The direction is still clear: less plain HTTP, more HTTPS by default, and fewer silent insecure paths. If your organisation is reviewing its HTTP handling, Peakhour can help you apply the right redirects and edge rules.

Down But Not Out - JXL Will Return on Safari

2023-06-04T00:00:00+10:00

Just as we were coming to terms with the controversial decision by Google to drop support for JPEG-XL (JXL) in Chrome, Apple announced support for JXL during the WWDC June 5th livestream. That is a meaningful shift. JXL was down, but not out.

Google's decision to stop JXL support in Chrome surprised us at Peakhour, along with plenty of others who care about web performance and image delivery. Google Chrome, as the most used browser globally, often sets the course for web standards. In deciding to drop JXL, Google appeared to be exercising its dominance over those standards, and the decision drew real debate in the web community.

Apple's announcement changes the picture. Apple has long pushed high dynamic colour and high-resolution features, and Safari support is a useful signal for image delivery. By bringing JXL support to Safari, Apple is giving this promising image format a fair go.

This move also hints at wider JXL support across the entire Apple ecosystem, which includes iPad, iPhone, Mac, and Apple TV. While there are still some limitations - embedded colour profiles and animations are not yet supported in the current MacOS Sonoma beta - we hope these gaps are fixed soon.

At Peakhour, this is good news. We look forward to welcoming Apple users to our websites, where they will be able to see the quality benefits of JXL images as soon as their operating systems support it.

This turn of events gives JXL a much-needed boost. It does not undo Google's Chrome decision, but it keeps the format in play and makes the future of web image formats less settled than it looked a short while ago.

Fastly Outage

2021-06-09T13:00:00+10:00

You may have heard that Fastly, one of the world’s largest providers of CDN services, had an outage of about 1 hour on the 8th July. Some of the world's largest websites and services were down, including reddit, CNN, The Guardian, Shopify Stores, Stripe and Spotify, to name a few.

According to Fastly themselves, the outage was caused by a 'service misconfiguration' (Update: Bug triggered by a client changing their configuration), which propagated globally and took websites offline. When users tried to access a website using the Fastly service, they were presented with a Varnish 503 Guru Meditation error (for those of us old enough to remember, Guru Meditation is a geek reference to the Commodore Amiga computer of the late 80s!). This generally occurs when there is an issue contacting the server that the website is actually hosted on. There were also some reports on twitter saying 'unknown domain'.

Essentially, Fastly took down its own network with a bad software update. Similar problems have affected other online platforms in the recent past, including Google, Amazon, and Cloudflare.

Why wasn’t there a Plan B?

Fastly is an excellent service, with an enviable reliability record. There is a reason why they're trusted by some of the world's largest websites to improve reliability and load times. However, the vast majority of Fastly clients still had to sit tight and wait for Fastly to fix the issue. Luckily this was only an hour. It could have been much longer.

Just like death and taxes, software outages are a certainty. The real story is not that Fastly had an outage. It is why didn't these large websites have a contingency plan for a single point of failure. For sites at that scale, this is a major oversight in infrastructure planning.

How to handle a CDN failure

The simple solution is to have a backup CDN provider already configured and tested, ready to switch over to if your primary provider fails. You can then utilise short expiry of DNS records to redirect users when the failure happens. This needn't be very expensive or complicated, although individual circumstances vary.

A Quick Introduction To DNS (Domain Name System)

Modern CDNs, like Fastly, Cloudflare, and Peakhour, operate as ‘reverse proxies’. This means they sit between a website's end users and the website server itself. They achieve this through DNS configuration.

When someone types a domain url into a browser, eg fastly.com, a request is sent to a DNS server with the host name (eg fastly.com) to find the IP address of the server to retrieve the content from. CDNs, like Fastly, get website admins to list the address of the CDN on the DNS server. That means requests for a website go through the CDN first. The process is analogous to listing someone else’s number in the phone book so they take calls for you.

The DNS server has a TTL (Time To Live) associated with its records. This TTL tells whoever asked for an IP address, for a given hostname, to remember the answer and not ask again until after the TTL has passed. Typically DNS record TTLs will be 1 hour, but they can be shorter, eg 1 minute.

Switching providers in case of an outage

By keeping a short TTL in DNS, webmasters can switch the answer for a DNS request to that of another provider, meaning users can quickly be directed to an alternative Cloud Provider. Once service has resumed on the primary provider, DNS can be switched again so normal traffic is resumed. The key is that the alternative provider is configured, tested, and ready to go.

This switch can even be automated to minimise outages. Premium DNS services, like Amazon’s Route 53, have optional health checking of DNS answers. This allows a switch to happen nearly instantly. The only downtime would be for people already on the site who have to wait for the TTL to expire before being directed to the backup Cloud Provider. In fact this is exactly what Peakhour.io does. In the event of a catastrophic outage we use DNS to switch to backup infrastructure so our clients are minimally affected.

Backup provider options

Now we've shown how switching CDN providers can be done, let's compare the major players and how they might serve as a backup CDN for Fastly. The three things we'll look at are Cost, Features, Integration.

Simply route traffic to the origin

This would be the simplest and most cost effective option, Assuming your origin server can handle the increased load that removing its CDN would entail. It also assumes that it's ok to lose any features that you may have been relying on, eg load balancing, WAF, edge scripting, image optimisation etc.

Cloudflare

Many people use Fastly because it uses Varnish, a richly featured, programmable cache with several advanced features. If you rely on those features, eg cache tags, cache on cookie value, custom cache tags, then you have to be on Cloudflare's top plan, which is not cheap.

The other major drawback of Cloudflare is that, unless you are on the most expensive plans, you have to cede control of DNS to them by delegating your domain. Cloudflare DNS is a great service, however it has the major drawback of caching negative DNS requests for an hour. If you were switching from an A record to a CNAME record or vice versa, you could be down for an hour regardless. Not ideal.

Akamai

Akamai has a highly respected, fully featured, and very expensive product. Maintaining a backup option with them will run into the $1000s a month. Only you can decide whether it’s worth it.

Cloudfront

Amazon's CDN offering is the third of the big three alternatives. Since it uses volume based billing, it could be an attractive CDN option as a standby, as long as you don't mind missing out on cache by tag (sorry Magento and Drupal). It is also complicated to configure for dynamic content and could miss features that you need. In fact most people use Cloudfront for static content, eg images, CSS, etc and run a Varnish instance within AWS to provide easier to configure full page caching.

This is what the BBC did with the Fastly outage. They had their backup infrastructure on Cloudfront and, as of time of writing, hadn't switched back to Fastly.

Peakhour.io

Peakhour is also volume based billing with a minimum monthly charge of $20. We provide all the advanced caching features that Fastly does, as well as WAF and image optimisation as standard, all in the one service fee. We don't require you to cede control of DNS to us and we're Australian owned and based.

Final Thoughts

CDNs, no matter how big, can fail. If your website is important then it needs a Plan B. This is how that Plan B works, and it doesn't have to be expensive when using a provider like Peakhour.io.

The important part is having it configured and tested before you need it.

Setting Up A Chia Hobby Farm

2021-04-30T13:00:00+10:00

Here at Peakhour, when we're not making websites faster and more secure, we like new tech and we like a good scheme. We ran Seti@home while at uni, and mined some bitcoin back in its early days (unfortunately we don’t have them anymore). Just recently we decided to set up a Chia farm, not the super-food Chia, but the new crypto coin Chia!

What is Chia?

Chia is not just a cryptocurrency; it is a brand new blockchain and smart transaction platform that implements the first new Nakamoto consensus algorithm since Bitcoin. It was invented by the engineer behind BitTorrent, Bram Cohen, who set out to address the shortcomings of Bitcoin.

The Chia network is set to officially launch on May 3rd, and the crypto world is going crazy getting ready.

I thought Bitcoin was great, what’s wrong with it?

The major flaws that Chia sets out to address are:

The environmental impact

Without getting too technical, Bitcoin relies on very intensive computations to verify transactions (Proof of work). These computations are carried out by 'miners' who are rewarded for their efforts from an ever decreasing pool of possible bitcoin. As the blockchain gets older, the verification gets harder, and as a result the Bitcoin network is now consuming as much electricity as a mid-sized country like Argentina. Huge mining operations have been set up in China, and some even have dedicated power plants. One poster child for the environmental impacts of bitcoin is an Australian startup looking to reopen a decommissioned coal power plant to power its mining operations.

Possibility of manipulation

The huge energy requirements have led to massive server farms in cool regions near cheap electricity, concentrating mining in the hands of a few large players. This centralisation opens up Bitcoin to the possibility of manipulation as anyone with 50% of the network can effectively change the blockchain.

How does Chia address these issues with Bitcoin?

Chia has implemented a new consensus algorithm called proof of space and time. It relies on unused hard disk space, which lots of people have and can use free of charge. Again, without getting too technical, 'Farmers' seed unused space on their hard drive/SSD with 'plots' of cryptographic numbers. When verifying transactions, the network issues a challenge to the farmers, who then scan their plots for the closest answer. The farmer passes this answer back to a server on the network known as a 'timelord'. The farmer with the closest answer is rewarded with a coin.

The more 'plots' a farmer has, the higher the chance of winning a coin.

Setting up the Farm

We got excited about the idea of Chia being the next big thing and decided to hitch a ride on the bandwagon. We had a spare old computer lying around, so we decided to fill it up with as much storage as we could find and farm some Chia!

To set up a farm you need as much space for plots as you can get your hands on. The speed of this space is not critical, so you can use spinning drives. We found 12-terabyte NAS drives to be the sweet spot for bang for buck, and opted for 4x Seagate Ironwolf NAS drives from Scorptec. (Note: they’ve gone up $40 since we bought them!)

Seeding the plots, however, is VERY disk intensive, so you need speedy and reliable SSDs. Since they don't have moving parts you'd think that SSDs would be very reliable, but just like spinning drives, they wear out and eventually die. SSDs come with a TBW (Terabytes Written) rating which estimates the amount of writes you can do before the drive will die. Popular consumer SSDs like a 500GB Samsung EVO 870 have a TBW rating of 300. Chia recommends getting server-grade SSDs that have ratings into the Petabytes, but of course they come with a price to match.

We were limited by the age of our available motherboard, so we could only choose from SATA3-compatible drives. Appropriate enterprise SSDs were also unavailable, so in the end we settled on 500GB Seagate Firecuda 120s that are rated at 700 TBW (also from Scorptec). We decided on two so we could double the plotting rate.

Now we had our hands on the drives, we just had to install everything. Within a few hours of transferring components and wiring it up we were good to go and started plotting.

Our Chia Farm!

Final Thoughts

Our old hardware limits the speed of the SSDs and therefore the number of plots we generate. We're managing around 10 plots a day and will need close to 500 before we’ve filled the available storage.

When we bought our equipment (28th April) the chia calculator showed that we’d be earning around a coin a day when fully plotted. However, with the official launch of Chia imminent, the network has exploded in growth, passing 1 Exabyte (1000 Terabytes) just one day ago. It's now up to 1.68 Exabytes! So unfortunately our estimated time to a coin is down to one every 7 days. That’s still pretty good though, and if Chia does end up supplanting Bitcoin we might just make back the setup costs. It has been a fun exercise, even if we did spend too long on it, and if it does end up being a flash in the pan we can always use the drives for something else….