{"version":"https://jsonfeed.org/version/1.1","title":"Ethan Hawksley's Blog","description":"A blog by Ethan Hawksley, a Computer Science student in the UK. Articles on systems programming, cybersecurity, and whatever else grabs my attention.","home_page_url":"https://hawksley.dev/","feed_url":"https://hawksley.dev/feed.json","authors":[{"name":"Ethan Hawksley","url":"https://hawksley.dev/"}],"language":"en","favicon":"https://hawksley.dev/icon-48x48.png","icon":"https://hawksley.dev/icon-512x512.png","items":[{"id":"https://hawksley.dev/blog/hack-club-horizons","url":"https://hawksley.dev/blog/hack-club-horizons","title":"My Experience with Hack Club Horizons Europa","summary":"I had a great time at a 3-day hackathon","content_text":"I had a great time at a 3-day hackathon","content_html":"

I've been participating in Hack Club for about two years so far. I've written posts about when I went to Shipwrecked and when I won Campfire.

\n

It started in late February. Whilst I was working on building this website, I checked the Hack Club Slack and discovered a new announcement.

\n
\n

You notice something big coming from the horizon... a new series of hackathons coming to a region near you!!

\n
\n

This was the announcement for Hack Club Horizons, a series of hackathons taking place around the world. I checked the region list and found that one such hackathon was called Horizons Europa. It was happening in Berlin, which the UK has reasonably priced flights to. Since it took place 24th-26th July, I had plenty of time to prepare.

\n

I signed up to the official Horizons dashboard and checked what I needed to do to qualify. It was simple - all I had to do was spend 35 hours programming on projects of my choice. Hack Club used a platform called Hackatime to track time coding. My prior experience with Hack Club meant it was already set up.

\n

Despite also preparing for exams, there was enough free time where I could polish this site. It didn't take long for me to complete the 35 hours required. I acquired a ticket from the official dashboard and, soon enough, the event arrived.

\n

24th July - Day One

\n

On the first day of the event, I woke up early at 4:15 and travelled from home to Heathrow Airport. My flight was at 8:50, but it didn't hurt to be cautious. Security was a breeze to get through. I arrived at the duty-free shops with two hours to kill.

\n

\"Seating

\n

In the run-up to the event, I had also been planning a free book about the XZ Utils backdoor called The Second Maintainer. As of the time of writing, it's in the proofreading stage. When I was at the airport, I found a table and continued working on it.

\n

After about 45 minutes, a message on Slack caught my attention. It turned out two other Horizons Europa attendees were taking the same flight as me (I won't be naming any attendees out of respect to their privacy). I saved my work and set off to find them.

\n

When we met up with each other, we got along immediately. With all the stuff we had in common, there was no shortage of things to talk about. Sadly, none of us had seats next to each other on the plane. When it came time to board, we drew the conversation to a close. The flight only took 90 minutes and went very peacefully.

\n

The plane landed, and we all made our way through security - the queues were long but not unbearably so. We met up with another attendee from the UK who had caught another flight. As it turned out, she went to the same school I completed my GCSE's at! Whilst travelling via German public transport to the event accommodation, we caught up on how everything had been going. I also chatted with the organisers of the event, who were surprisingly sociable.

\n

After disembarking and going on a brief walk, we arrived at the Wyndham Garden Berlin Mitte hotel. Originally built in the 1920s, it was starting to show its age. Nonetheless, it was a comfortable place. We waited in the lobby as the other attendees arrived in droves. Half an hour passed, and enough people had finally arrived.

\n

\"Interior

\n

With enough people, we set off to the nearby makerspace called MotionLab.Berlin. It was nearby and had plenty of space for us all. The standout feature was the double-decker bus, converted into a meeting room and office space. We all split into teams, and I formed a team of four.

\n

The premise of this hackathon revolved around household objects: each team is given a random item and has to build a project out of it. Our item was a plastic piece of broccoli. At first, we brainstormed potential ideas on a whiteboard. One of our team members brought some hardware, and the NFC tag reader caught our eye. With that, we formed a plan.

\n

The game focused on growing your broccoli faster than your opponent could. Every couple of seconds, either a raincloud or the sun would appear at the top of the screen. Both players had a corresponding NFC tag for each event, and the first to scan their tag boosted their broccoli's growth. The game ended once all 12 ingame-months had passed, and each player's score was saved to their mobile app. We started the implementation on the first day, finished it on the second, and polished it on the third.

\n

It quickly turned dark outside, so everybody headed back to the hotel. The spreadsheet used for room allocation had broken and took the organisers until midnight to sort out everyone's room numbers. On the flip side, I enjoyed the free ice cream they handed out. After a small room mix-up, my room was finally arranged and I got some much-needed rest.

\n

25th July - Day Two

\n

\"Group

\n

Day 2 opened with us exploring the city of Berlin. Several people split off from the main group, but I decided to stay with the majority. We visited the East Side Mall, where we bought snacks from Aldi. My personal favourites were vanilla waffles. A single pack contained over 40 waffles, and they each tasted amazing. I also found a nearby bookstore and got myself a nice fridge magnet of a penguin with balloons. Next, we walked alongside the East Side Gallery - the longest stretch of the Berlin Wall still standing. It had plenty of beautiful art made after the Berlin Wall fell.

\n

Having finished sightseeing for the day, we headed back to the venue to continue work on our projects. I completed a backend for the game using Python and Flask, whereas other members built the MicroPython NFC reader code, the React website, and the Flutter app. We had a functional, albeit clunky, game.

\n

During the afternoon, the organisers announced there would be lightning talks running. What separates a lightning talk from an ordinary talk is you only have two minutes to explain your topic. Some organisers had talks, but they opened it up to the attendees to join in too. I thought I might as well do one all about Search Engine Optimisation for personal websites. It is an area I have plenty of knowledge on, given the research I've completed whilst making this site. Over the course of an hour, I created a slideshow and then presented it to the 80 people there. It was received well, and I was approached for some feedback on someone's personal website afterwards.

\n

Each attendee was given some very nice Korean takeaway for dinner, which went down a treat. We then headed back to the hotel for the night. My team stayed up late as we polished the game. I tried to complete an online check-in for my flight back home, but the system gave an error. After an hour with customer support, the conclusion was to just check-in at the airport kiosk. I called it for the night and went to get some rest.

\n

26th July - Day Three

\n

\"An

\n

On the final day, I ensured to pack my bags early. We all travelled from the hotel to the venue, although on an empty stomach. When we arrived, we were soon met with an assortment of cakes from a local bakery for breakfast. Although unconventional, they were high-quality and tasted divine.

\n

We didn't have long until our projects needed presentation, so my team scrambled to apply the finishing touches. Our game was finally ready just in time!

\n

\"A

\n

All teams had their projects running on their laptops during the presentation, and you walked around to see them all. Since our project involved hardware, of course we encountered a couple of technical difficulties. They were relatively minor and easy to fix. Most importantly, the other attendees all seemed to really enjoy the game.

\n

Everyone else's projects were great too. Some key highlights were: a camera that used motion tracking so you could play Doom using a paper keyboard, a talking hamster therapist you could call on your phone, and a cooperative puzzle game where all players are computer mice. Everybody managed to create really unique projects out of their random items.

\n

Once everyone finished voting for their favourites, the scores were tallied. Although our team didn't win, I still greatly enjoyed the process of making the project. The organisers presented the closing ceremony and marked the end of Horizons Europa.

\n

I still had a couple of hours until my flight was due to set off. Me and two others asked a German attendee what their favourite restaurant was in all of Berlin. They gave us the address of a sushi place roughly 40 minutes away from the venue, and we set off to go find it. We accidentally held up a full bus whilst figuring out how to buy a ticket, but aside from that it was smooth sailing.

\n

\"Sushi

\n

We arrived at the location - Jasmin, a Vietnamese restaurant. The Celebration sushi mix caught our eyes, so we ordered it and a handful of starters. When they came, we easily saw why the German guy recommended it so highly. It's hard to put into words how nice it was. If you're ever in Berlin, you need to try it. Out of curiosity, I checked the kid's menu too and found dishes such as the I'm not hungry and the I want to go to Mc Donald's. The place has a great sense of humour.

\n

The journey back to the airport was slow but easy. We meandered through various train networks and even boarded a double-decker train! I chatted with the help desk at the airport, and it turned out they just wanted to stow my suitcase. The overhead lockers were overbooked and they needed some extra space. When passing through security, a guard asked about the talking hamster plush we were carrying. We turned it on, and its chattering attracted attention from plenty of passers-by. The guard found it very funny and let us continue.

\n

In the duty-free shops, I bought a fridge magnet of "Ampelmann" - the little pedestrians on German traffic lights. The queue for leaving the EU was far longer than expected, and I almost missed the plane! Thankfully, I made it with a few minutes to spare. There was some nice conversation with the passenger next to me during the flight, but I was relieved to make it back home to my own bed.

\n

Overall

\n

Horizons Europa was really fun! I'm endeavouring to stay in touch with the people I met there. I also enjoyed learning more about Flask, and I feel like a much more confident speaker after the lightning talk. It took a few days to wear off the sleep defecit, but it was all worth it.

\n

You can certainly count on me doing more hackathons in the future.

\n","date_published":"2026-07-30T00:00:00.000Z","tags":["hack-club","hackathon"]},{"id":"https://hawksley.dev/blog/json-ld-explained-for-personal-websites","url":"https://hawksley.dev/blog/json-ld-explained-for-personal-websites","title":"JSON-LD Explained for Personal Websites","summary":"Everything you need to know about JSON-LD and how to implement it.","content_text":"Everything you need to know about JSON-LD and how to implement it.","content_html":"

JSON-LD, also known as JSON Linked Data, is a format for adding structured data to webpages. It can aid web crawlers in understanding the semantic structure of your site, qualifying you for richer link previews, and even potentially improving your search ranking.

\n

It's been 4 months since my first post where I described building this site, and Wakatime estimates I've spent ~100 hours coding now, not including time spent researching and testing. Since then, this site has been receiving plenty of polish, including the addition of JSON-LD on each page.

\n

JSON-LD Fundamentals

\n

To add JSON-LD to a page, add the following somewhere in your <head> section:

\n
<script type="application/ld+json">\n  {\n    "@context": "https://schema.org",\n    "@graph": [\n      {\n        "@type": "WebSite",\n        "@id": "https://hawksley.dev#website",\n        "url": "https://hawksley.dev",\n        "name": "Ethan Hawksley"\n      },\n      // Insert more nodes here.\n    ]\n  }\n</script>\n
\n

Let’s break down what each part does.

\n
<script type="application/ld+json">\n
\n

This declares a new script with MIME type application/ld+json. Since it has this type specified, the browser's JS engine won't run it. Specialised crawlers like Googlebot look out for these elements and parse the contents.

\n
{\n  "@context": "https://schema.org"\n}\n
\n

Here, a JSON object is initialised and the property @context is set to https://schema.org. In JSON-LD, the structure of data is determined by assigning the appropriate context. Web crawlers are standardised on Schema.org, which defines all the valid key-value pairs for the JSON.

\n

Now that we've defined the schema our JSON-LD is following, we can describe our webpage!

\n
{\n  "@graph": [\n    {\n      "@type": "WebSite",\n      "@id": "https://hawksley.dev#website",\n      "url": "https://hawksley.dev",\n      "name": "Ethan Hawksley"\n    }\n    // Insert more nodes here.\n  ]\n}\n
\n

A JSON-LD document can be thought of as a labelled, directed graph, stored under @graph. The graph contains multiple nodes, connected to each other with directed arcs.

\n

Nodes have:

\n\n

In the example above, the type is WebSite, the ID is https://hawksley.dev#website, and it has two properties, url and name.

\n

Web crawlers can merge the properties of a node across multiple pages, as long as they share an ID. However, scrapers that only read one page - such as LLMs - will not merge the properties. When JSON-LD is reused across pages, striking this balance is important to keep in mind. It is best practice for the ID to be a URL followed by a hash, such as #website, that uniquely identifies the node.

\n

Although the Schema.org context defines many types of nodes, this guide will only be covering nodes that have noticeable SEO impact. If you're interested in more, look up the semantic web - it's a fun rabbit hole.

\n

Let's move on to which nodes each page on our site should include. For each type, I've included the JSON-LD from this site, so you can copy-paste and edit it to fit your own.

\n

WebSite

\n

You've seen an extract of WebSite earlier! Now here's the full version:

\n
{\n  "@type": "WebSite",\n  "@id": "https://hawksley.dev#website",\n  "url": "https://hawksley.dev",\n  "name": "Ethan Hawksley",\n  "alternateName": ["hawksley.dev", "Hawksley"],\n  "description": "The personal site and blog of Ethan Hawksley, a Computer Science student in the UK with a focus on systems programming and cybersecurity.",\n  "inLanguage": "en",\n  "publisher": {\n    "@id": "https://hawksley.dev#person"\n  },\n  "image": {\n    "@type": "ImageObject",\n    "url": "https://hawksley.dev/hawksley-dev-logo.png",\n    "name": "Logo of hawksley.dev",\n    "caption": "The official EH monogram logo for hawksley.dev",\n    "width": 1024,\n    "height": 1024\n  }\n}\n
\n

WebSite explains the metadata about the site. It gives crawlers hints on how to display your site.

\n

\"Google

\n

Here, you can see that Google has interpreted the name field as representative of the domain and is labelling the result appropriately.

\n

Although WebSite applies to every page, you don't need to include the full version of it on every page. The root page of the domain should be fully detailed, but it is perfectly acceptable for other pages to have a slimmed-down version:

\n
{\n  "@type": "WebSite",\n  "@id": "https://hawksley.dev#website",\n  "url": "https://hawksley.dev",\n  "name": "Ethan Hawksley"\n}\n
\n

This gives sufficient context to single-page crawlers so they correctly name the site, but they don't need the full details.

\n

WebPage

\n

WebPage describes the current page, but it's important to distinguish it from other types like BlogPosting (covered later). WebPage represents the physical page itself, the HTML. It contains the content of the page.

\n
{\n  "@type": "WebPage",\n  "@id": "https://hawksley.dev/blog/hack-club-campfire#webpage",\n  "url": "https://hawksley.dev/blog/hack-club-campfire",\n  "isPartOf": {\n    "@id": "https://hawksley.dev#website"\n  },\n  "name": "Winning the Hack Club Campfire Hackathon",\n  "inLanguage": "en",\n  "mainEntity": {\n    "@id": "https://hawksley.dev/blog/hack-club-campfire#blogposting"\n  },\n  "breadcrumb": {\n    "@id": "https://hawksley.dev/blog/hack-club-campfire#breadcrumb"\n  }\n}\n
\n

There are more specific subtypes of WebPage. In this post, I'll cover ProfilePage and CollectionPage. You can find less common ones at the bottom of Schema.org's definition for WebPage.

\n

Person

\n

Another node that every page on a personal website should have is Person. It describes who you are, which Google uses as part of their content quality metric. Increasingly, LLM crawlers are also using it to decide who to cite in their answers.

\n

Unlike WebSite, it is important enough context that you should include it on all of your site's pages.

\n
\n Warning - Quite Long!
{\n  "@type": "Person",\n  "@id": "https://hawksley.dev#person",\n  "url": "https://hawksley.dev",\n  "name": "Ethan Hawksley",\n  "givenName": "Ethan",\n  "familyName": "Hawksley",\n  "description": "Long Description",\n  "disambiguatingDescription": "Shorter Description",\n  "jobTitle": "Computer Science Student",\n  "knowsLanguage": "en",\n  "knowsAbout": [\n    // Keywords\n  ],\n  "nationality": {\n    "@type": "Country",\n    "name": "United Kingdom"\n  },\n  "homeLocation": {\n    "@type": "Place",\n    "address": {\n      "@type": "PostalAddress",\n      "addressLocality": "Warwick",\n      "addressRegion": "Warwickshire",\n      "addressCountry": "GB"\n    }\n  },\n  "affiliation": {\n    "@type": "CollegeOrUniversity",\n    "url": "https://warwick.ac.uk",\n    "name": "University of Warwick",\n    "sameAs": [\n      "https://www.wikidata.org/wiki/Q865528",\n      "https://en.wikipedia.org/wiki/University_of_Warwick"\n    ]\n  },\n  "alumniOf": [\n    {\n      "@type": "HighSchool",\n      "url": "https://www.alcestergs.co.uk",\n      "name": "Alcester Grammar School",\n      "sameAs": [\n        "https://www.wikidata.org/wiki/Q4713005",\n        "https://en.wikipedia.org/wiki/Alcester_Grammar_School"\n      ]\n    },\n    {\n      "@type": "HighSchool",\n      "url": "https://www.brookeweston.org",\n      "name": "Brooke Weston Academy",\n      "sameAs": [\n        "https://www.wikidata.org/wiki/Q4974495",\n        "https://en.wikipedia.org/wiki/Brooke_Weston_Academy"\n      ]\n    }\n  ],\n  "image": {\n    "@type": "ImageObject",\n    "url": "https://hawksley.dev/ethan-hawksley.jpg",\n    "name": "Ethan Hawksley",\n    "caption": "Headshot of Ethan Hawksley, Computer Science student",\n    "width": 1536,\n    "height": 1536\n  },\n  "sameAs": [\n    "https://github.com/ethanhawksley",\n    "https://www.linkedin.com/in/ethanhawksley",\n    "https://lobste.rs/~ethanhawksley",\n    "https://news.ycombinator.com/user?id=ethanhawksley"\n    // etc. etc.\n  ]\n}\n
\n

Phew! There's plenty of properties for Person. I find that it helps to be more descriptive, rather than less, when it comes to filling it out. Let’s look at the most important properties:

\n\n

The other properties of Person are useful for adding more detail, but aren't strictly necessary. You can trim them if you wish with only minor impact.

\n

ProfilePage

\n

A ProfilePage, as you may expect, describes a page on the site about a person. For instance, I use this node on my home page, as that's where I talk about myself. On your site, putting it on an about page could be more appropriate.

\n
{\n  "@type": "ProfilePage",\n  "@id": "https://hawksley.dev#webpage",\n  "url": "https://hawksley.dev",\n  "isPartOf": {\n    "@id": "https://hawksley.dev#website"\n  },\n  "name": "About Ethan Hawksley",\n  "inLanguage": "en",\n  "dateCreated": "2024-09-10T00:00:00.000Z",\n  "dateModified": "2026-05-17T00:00:00.000Z",\n  "mainEntity": {\n    "@id": "https://hawksley.dev#person"\n  }\n}\n
\n

It's important to use isPartOf to link it to your broader WebSite node, to create a relationship between the two nodes. The same applies for mainEntity, it lets crawlers know who the page is about. Including dateCreated and dateModified is a good freshness signal for crawlers, but if your site doesn't have them readily available, don't worry too much about it.

\n

SoftwareApplication

\n

If you are showcasing any software on your page, it's a good idea to include a SoftwareApplication node to describe the metadata about it.

\n
{\n  "@type": "SoftwareApplication",\n  "@id": "https://hawksley.dev#app-yt-play",\n  "url": "https://crates.io/crates/yt-play",\n  "name": "yt-play",\n  "description": "A CLI utility written in Rust that synchronises YouTube playlists to local directories.",\n  "applicationCategory": "MultimediaApplication",\n  "creator": {\n    "@id": "https://hawksley.dev#person"\n  },\n  "sameAs": ["https://github.com/ethanhawksley/yt-play"]\n}\n
\n

If you want to be more specific than SoftwareApplication, other valid types for this node are MobileApplication, WebApplication, and VideoGame.

\n

The url property should be a link to where the project is deployed, e.g. crates.io. sameAs is for any other pages associated with the project, like its source code repository.

\n

There are lots of valid values for applicationCategory, you can find a list on Google's definition for SoftwareApplication.

\n

BreadcrumbList

\n

BreadcrumbList is widely useful and should be included on all pages aside from the root page. It is used to describe the categorisation of a page, which isn't necessarily the actual path to the page.

\n
{\n  "@type": "BreadcrumbList",\n  "@id": "https://hawksley.dev/blog/hack-club-shipwrecked#breadcrumb",\n  "itemListElement": [\n    {\n      "@type": "ListItem",\n      "item": "https://hawksley.dev",\n      "position": 1,\n      "name": "Home"\n    },\n    {\n      "@type": "ListItem",\n      "item": "https://hawksley.dev/blog",\n      "position": 2,\n      "name": "Blog"\n    },\n    {\n      "@type": "ListItem",\n      "item": "https://hawksley.dev/blog/hack-club-shipwrecked",\n      "position": 3,\n      "name": "The Shipwrecked Hackathon by Hack Club"\n    }\n  ]\n}\n
\n

BreadcrumbList describes the path of a page. By including one, you can control how search engines represent the path of a specific page.

\n

\"Google

\n

Here, the search result for my blog post contains the path https://hawksley.dev › Blog. If your site already uses short paths, this node is a minor gain and can be omitted. However, if your paths are longer, BreadcrumbList is useful for shortening them.

\n

CollectionPage

\n

The CollectionPage node is a subtype of WebPage, usable for pages that primarily contain lists. For example, my /elsewhere/ page lists all my other profiles, and /blog/ lists all my blog posts.

\n
{\n  "@type": "CollectionPage",\n  "@id": "https://hawksley.dev/elsewhere#webpage",\n  "url": "https://hawksley.dev/elsewhere",\n  "isPartOf": {\n    "@id": "https://hawksley.dev#website"\n  },\n  "name": "Elsewhere",\n  "description": "Online profiles of Ethan Hawksley, a Computer Science student in the UK. Links to his development, social media, blogging, and security accounts.",\n  "inLanguage": "en",\n  "about": {\n    "@id": "https://hawksley.dev#person"\n  },\n  "breadcrumb": {\n    "@id": "https://hawksley.dev/elsewhere#breadcrumb"\n  }\n}\n
\n

You've met most of these properties already, so they are largely self-explanatory. Make sure you link breadcrumb to the correct BreadcrumbList! It needs to be the one on the current page for it to make any sense.

\n

Blog

\n

You should add the Blog node to your blog's index or home page. It acts as a stepping stone between your WebSite and the individual blog posts you publish.

\n
{\n  "@type": "Blog",\n  "@id": "https://hawksley.dev/blog#blog",\n  "isPartOf": {\n    "@id": "https://hawksley.dev#website"\n  },\n  "mainEntityOfPage": {\n    "@id": "https://hawksley.dev/blog#webpage"\n  },\n  "name": "Ethan Hawksley's Blog",\n  "description": "A blog by Ethan Hawksley, a Computer Science student in the UK. Articles on systems programming, cybersecurity, and whatever else grabs my attention.",\n  "inLanguage": "en",\n  "dateModified": "2026-05-17T00:00:00.000Z",\n  "publisher": {\n    "@id": "https://hawksley.dev#person"\n  },\n  "license": "https://creativecommons.org/licenses/by/4.0/"\n}\n
\n

dateModified is a good freshness signal, but if you don't have it handy, don't worry. Including license lets crawlers know under what circumstances they can use your prose.

\n

\"Definition

\n

If you've done prior research into JSON-LD, you may be surprised that the publisher property is set to be a Person, not an Organization. Although it used to require one, Google's documentation has since been relaxed and Person is entirely valid too, and arguably more accurate for a personal website.

\n

BlogPosting

\n

The last node we'll be covering is BlogPosting. It should be included on all published blog posts, providing added information to crawlers so they can more accurately represent them, including both more accurate placement and richer details in search results.

\n
{\n  "@type": "BlogPosting",\n  "@id": "https://hawksley.dev/blog/need-for-post-quantum-cryptography#blogposting",\n  "url": "https://hawksley.dev/blog/need-for-post-quantum-cryptography",\n  "mainEntityOfPage": {\n    "@id": "https://hawksley.dev/blog/need-for-post-quantum-cryptography#webpage"\n  },\n  "isPartOf": {\n    "@id": "https://hawksley.dev/blog#blog"\n  },\n  "headline": "The Need for Post-Quantum Cryptography",\n  "description": "Quantum computers are closer to breaking RSA and ECC than we thought. Learn what post-quantum cryptography is and how to start migrating.",\n  "articleSection": "cybersecurity",\n  "keywords": "cybersecurity, quantum",\n  "inLanguage": "en",\n  "datePublished": "2026-04-13T00:00:00.000Z",\n  "dateModified": "2026-04-17T00:00:00.000Z",\n  "author": {\n    "@id": "https://hawksley.dev#person"\n  },\n  "publisher": {\n    "@id": "https://hawksley.dev#person"\n  },\n  "image": {\n    "@type": "ImageObject",\n    "url": "https://hawksley.dev/og/blog/need-for-post-quantum-cryptography.jpg",\n    "width": 1200,\n    "height": 630\n  },\n  "license": "https://creativecommons.org/licenses/by/4.0/"\n}\n
\n

Since this is a personal site, it is alright for author and publisher to both point towards the same Person node. The image property should mirror the OG image that the post already uses for link previews.

\n

Conclusion

\n

Congrats, that's all the JSON-LD a personal site needs! I've structured this post to make it as easy as possible for you to copy-paste and implement into your own personal site. Even if you run a static site without a build step, you can still benefit from adding at a minimum WebSite, ProfilePage, and Person to the root page of your site.

\n

If you have any questions, you can get in touch via email, and I'll do my best to help.

\n","date_published":"2026-06-21T00:00:00.000Z","tags":["seo","web"]},{"id":"https://hawksley.dev/blog/supply-chain-attacks","url":"https://hawksley.dev/blog/supply-chain-attacks","title":"Mitigating Ongoing Registry Supply Chain Attacks","summary":"They are only becoming more frequent and more damaging.","content_text":"They are only becoming more frequent and more damaging.","content_html":"

Supply chain attacks are a growing threat to software registries.

\n

One of the first major typosquatting attacks on npm took place in 2017 when the user "hacktask" published a series of packages with similar names to popular libraries (e.g. crossenv vs cross-env), misleading people into installing them.

\n

Then the first time an official package was compromised was in 2018, when the account of an eslint-scope maintainer was hijacked and used to publish malicious packages. These packages would exfiltrate the contents of developers' .npmrc files, often including their keys used for publishing new npm packages. This marked a turning point when attackers began harvesting credentials at scale, to fuel further attacks.

\n

The recent attack - named Mini Shai-Hulud as a homage to the Dune sandworms - is a symptom of how broken the security of these registries is. It scans your system for API keys, creates public GitHub repositories containing said API keys, and abuses credentials to upload itself to other libraries, spreading its influence.

\n

Software developers are large targets for malicious actors due to their unique position as both users and distributors. They can easily be compromised by a single library and spread the infection rapidly to all downstream users. Paired with keys to expensive cloud billing accounts and browser token-stealers, it's no wonder developers face these attacks so often.

\n

Not all registries are at equal risk, npm is the worst offender by far. A recent report shows it contained 90% of all detected malware across a collection of registries. PyPI and crates.io both contain some malware, but their scale is dwarfed.

\n

Mitigations

\n

Despite the dangers associated with supply chain attacks, they can be mitigated. The easiest method is by setting a minimum-age on new packages. Most malicious packages from hijacked libraries last no longer than a few hours, so by setting an age-requirement of a week, the vast majority of threats can be foiled.

\n

For npm, set the contents of ~/.npmrc to:

\n
min-release-age=7\n
\n

For pnpm, run the command:

\n
pnpm config set minimumReleaseAge 10080 --global\n
\n

For Bun, set the contents of ~/.bunfig.toml to:

\n
[install]\nminimumReleaseAge = 604800\n
\n

For Yarn, run the command:

\n
yarn config set --home npmMinimalAgeGate 10080\n
\n

For uv, set the contents of ~/.config/uv/uv.toml to:

\n
exclude-newer = "7 days"\n
\n

For pip, set the contents of ~/.config/pip/pip.conf to:

\n
[install]\nuploaded-prior-to = P7D\n
\n

Cargo has a minimum age feature as an RFC, but as of the time of writing, it is not implemented in the client yet. Go has no such plans, nor do Maven or Gradle.

\n

This mitigation is not without drawbacks. It's worth considering that delaying such installations by a week also delays any critical security patches, unless otherwise overridden. It's worth weighing up whether it is worth the trade-off.

\n

Other Considerations

\n

Aside from a minimum-age, there are a few other key changes worth implementing.

\n

Firstly, ensure you have 2FA set up for all accounts that support it. It greatly limits the potential blast radius if you become compromised. I personally recommend Ente Auth - it's free, cross-platform, and supports optional E2EE cloud backups.

\n

Secondly, if you are not using pinned versions or lock-files, you should be. They ensure that installed software versions will only change when explicitly updated. This gives you greater control over how and when you want to update, limiting your exposure to supply chain attacks.

\n

Lastly, if your language supports post-install scripts, it's worth disabling them unless necessary. Especially in the JS ecosystem, post-install scripts are often abused to execute payloads immediately before you have time to react. In most circumstances, the feature is just an unnecessary attack surface.

\n

Even with these mitigations, no project is immune. However, with enough common sense and precautions, you should be able to keep reasonably safe.

\n","date_published":"2026-05-17T00:00:00.000Z","tags":["cybersecurity","packages"]},{"id":"https://hawksley.dev/blog/need-for-post-quantum-cryptography","url":"https://hawksley.dev/blog/need-for-post-quantum-cryptography","title":"The Need for Post-Quantum Cryptography","summary":"Quantum computers are becoming increasingly realistic. We need to be ready.","content_text":"Quantum computers are becoming increasingly realistic. We need to be ready.","content_html":"

The threat quantum computers pose to encryption is growing faster than many expected. Historically, the internet has relied on algorithms like RSA encryption and Elliptic Curve Cryptography (ECC) to exchange encryption keys and verify identities across the web. These algorithms are in danger of being entirely broken by the new capabilities of quantum computers, leaving our communications insecure. Modern breakthroughs in research are bringing us closer to this becoming a reality than we expected.

\n

Quantum computers can be thought of as computers with fundamentally unique capabilities. Instead of using bits as memory, they use qubits. Quantum computers can run specialised "quantum algorithms", which under certain circumstances can be much faster than conventional algorithms[^1]. RSA and ECC seemed secure when we designed them, but as we research more about quantum computers, we realise that they are not secure at all. To resolve this, we have now designed post-quantum algorithms capable of securing data even after quantum computers are accessible. NIST finalised its post-quantum standards in 2024, introducing new post-quantum algorithms such as ML-KEM to replace the old vulnerable ones.

\n

Shor's algorithm - the algorithm responsible for factorising the integers used in RSA encryption - has been improved and requires far fewer qubits than before. Google has also made quantum algorithms used for breaking ECC significantly more efficient. Major tech companies like Google, Microsoft, and IBM are competing to build bigger and faster quantum computers, bringing us closer to these quantum algorithms becoming possible. With these developments, the advent of quantum computing is closer than we had once expected. In response, Google has announced a 2029 timeline for using post-quantum cryptography, and Cloudflare has followed suit with their global network. It won't be long until other major providers follow.

\n

\"Cloudflare

\n

In the course of researching this, I discovered that America's Cybersecurity and Infrastructure Security Agency surprisingly still doesn't support post-quantum cryptography. If you want to check some websites yourself, Cloudflare offers a free tool where you can enter any URL and check.

\n

The Risks

\n

Adversaries aren't waiting, even though experts in the field predict that quantum computers capable of breaking RSA are likely to be built in 10-15 years. They are already harvesting huge quantities of our encrypted communications - known as Harvest Now, Decrypt Later (HNDL) attacks - knowing they will be able to decrypt them later.

\n

Adversaries aren't selective, they are collecting all the data they can get their hands on. Once quantum computers arrive, they'll decide what's worth decrypting. The question is simply whether your data will still matter in ten years.

\n

On a personal level, private messages, account records, medical records, and biometrics are in danger of being exposed. Some sensitive data, like passport pages and credit card details, will likely have expired by then, so there isn't much risk for those.

\n

For companies, trade secrets, source code, internal logs, and customer data pose great risk. Exposure of client information could lead to legal fines, and trade secrets risk losing your competitive advantage.

\n

With governments, however, the stakes are highest. Foreign intelligence, real identities of agents in the field, military plans, and diplomatic communications are severe threats to national security.

\n

No matter the scale you operate at, the transition needs to happen before quantum hardware catches up. That window is narrowing.

\n

[^1]: If you're interested in more details about how quantum computing works on a fundamental level, I highly recommend the quantum.country essay, which goes into far greater depth.

\n","date_published":"2026-04-13T00:00:00.000Z","tags":["cybersecurity","quantum"]},{"id":"https://hawksley.dev/blog/hack-club-campfire","url":"https://hawksley.dev/blog/hack-club-campfire","title":"Winning the Hack Club Campfire Hackathon","summary":"A high-intensity 12-hour collaborative sprint.","content_text":"A high-intensity 12-hour collaborative sprint.","content_html":"

As leader of ComSoc at my school, I guide the Year 12 and 13 students and keep on the lookout for any new opportunities we can take part in.

\n

A few months ago, we practised for the British Informatics Olympiad, a challenging set of three questions that required us to design accurate algorithms to solve. Over a short period, I had helped transform a group of enthusiastic Year 12 students into confident programmers capable of breaking down and solving complex problems.

\n

Whilst looking for new events, I found Campfire, a team-based hackathon by Hack Club, where over the span of 12 hours, you design, create, and present a game, and the best teams receive prizes! Having previously competed in Daydream - a very similar game jam - I knew that this would be a lot of fun. After getting the members of ComSoc to split into teams and sign up, we were off to the races.

\n

Preparing for Campfire

\n

Nowadays, there's plenty of choice for how to produce and release a game. The event was restricted to only game engines that could be exported to run on the web. After some thought, I chose to use Godot as its beginner-friendly nature makes it the perfect candidate for teaching.

\n

The members of my society needed some teaching, so after struggling through the pain that is Git credentials on Windows, I had them all set up and installed with the necessary software. After I ran a session on creating a simple platformer to bring them up to speed, I knew they were ready.

\n

The Big Day

\n

On the car journey over, I learned that the surprise theme was "Beneath the Surface", which started to give me plenty of ideas.

\n

Once we all arrived at the location, I met up with my teammates. It took a little brainstorming, but we came up with the idea for our game. Inspired by the incremental games you often see in ads or see others playing, our game was to be based around a cat that goes fishing deeper and deeper into the ocean. Any caught fish could be sold to buy upgrades, allowing for even deeper levels to be reached. We named it "Cat-Fishing Frenzy".

\n

Developing the Game

\n

\"Cat-Fishing

\n

We began the event by first creating the assets we would need. I used Aseprite to design the pixel art for many of the fish that would swim in the sea.

\n

Next, we laid the foundations. The main scene was created and populated with the cat, rod, and boat. After adding the fishhook, Ryley discovered a neat way to create the fishing line by just moving a point on a Godot Line2D.

\n
func _process(_delta: float) -> void:\n\tset_point_position(1, to_local(node.global_position))\n
\n

Ryley and I worked on fish spawning, whilst Sam implemented a currency and shop system. With each of us working on largely different areas of the codebase, Git merge conflicts were easy to solve and very infrequent.

\n

After not too long, we had created the skeleton of a fully functional game! With plenty of time to spare, we introduced a couple of smaller mechanics, and the game received many balancing tweaks. After some polishing, the time was up, just in time for the pizza that the organisers ordered.

\n

We presented the game to the other competitors, and then came a voting round. After a suspenseful wait, the results were in, with our game taking first place!

\n

Retrospective

\n

\"Hack

\n

This hackathon was plenty of fun to attend, and winning it was the icing on top. Lots of nice prizes were dished out, but I really enjoyed getting to know the people I was working with better. Programming under strict time constraints was excellent practice for my efficiency and teamwork skills, and I look forward to further opportunities in the future.

\n

If you're curious, you can play Cat-Fishing Frenzy here on itch.io. You'll need the arrow keys to move the hook, so no mobile compatibility at the time of writing.

\n","date_published":"2026-03-03T00:00:00.000Z","tags":["hack-club","hackathon"]},{"id":"https://hawksley.dev/blog/hack-club-shipwrecked","url":"https://hawksley.dev/blog/hack-club-shipwrecked","title":"The Shipwrecked Hackathon by Hack Club","summary":"Shipwrecked was really fun, actually.","content_text":"Shipwrecked was really fun, actually.","content_html":"

Last April, I was minding my own business when I received a curious email in my inbox.

\n
\n
    \n
  1. Hack Club is renting an island.
    2. \n
  2. We are hosting a hackathon.
    3. \n
  3. Anyone who ships 4 projects gets to come. Flight stipends available!
    4. \n
  4. Dates are August 8th - 11th. Boston, USA.
    5. \n
\n
\n

I'd signed up for Hack Club mailing lists in the past since they run a variety of coding activities. However, this email particularly stood out to me. I've always wanted to visit America, and it seemed like they would be offering me a free flight!

\n

Following the link led me to a sign-up page where I entered my details to register my interest. I spread the word about this event to the other coders I knew, and soon it reached the 5,000-signup threshold to be given the green light.

\n

Hack Club is a non-profit organisation that has received some generous donations in the past, but they still can't afford to give away such a great trip for free. To earn my place at the event, I needed to pass The Bay.

\n

The Bay

\n

The Bay was an online platform designed by Hack Club specifically for this event. You tracked your time spent coding projects with their WakaTime server Hackatime and submitted any completed projects for review by the Shipwrecked moderators.

\n

Approved projects granted you a number of "shells" relative to how many hours were spent creating the project. These shells could be spent on many different items from their shop, from Flipper Zeros to 3D printers. However, the grand prize was a ticket for the Shipwrecked hackathon in Boston. This cost the small sum of 60 hours total. Travel stipends were also available, at a conversion rate of 1 hour coding → $10 grant towards a flight.

\n

After checking Skyscanner to see return flights would charge an entire £400 (~$550), I checked the clauses for Shipwrecked and saw that if I programmed for 100 hours total, they would fully cover my flight regardless of how expensive.

\n

Now I had the 100-hour goal in mind, it was time to start programming.

\n

Some Notable Projects

\n

Gravify

\n

\"Gravify

\n

I had found an interesting library called html-to-image that could convert DOM elements into images I could manipulate with JavaScript. While that library was sitting in the back of my mind, I stumbled across the Matter.js physics simulation library. The library supported custom PNGs as input to the physics simulation, so I decided to combine these two libraries and recreate something very similar to Google Gravity.

\n

Going through the MDN Web Docs to learn how to build a browser extension was far smoother than I had expected. I was comfortable writing JavaScript, and not much boilerplate was required to hook into the Browser APIs. After not too long, Gravify was created.

\n

Turing Machine Simulator

\n

\"Turing

\n

After visits to Bletchley Park and diving into more theoretical computer science, I knew I wanted to build a Turing machine.

\n

Turing machines are a model for computing first devised by Alan Turing in 1936. They consist of an infinite roll of tape marked out into squares, a "head" that points to a single square at a time, and a set of states and instructions. Each cycle, the Turing machine reads the value of the tape underneath itself, compares it to the corresponding instruction, writes a new symbol onto the tape, and finally either moves left or right along the tape.

\n

Despite their limited nature, they can provably carry out any calculation and are often used for proving new theorems in computer science. I did some research and couldn't find a simulator online that I was content with using, so I built my own.

\n

I was still studying a React course at the time, so I wasn't fully confident building UI with JSX components. This led to a lot of repetitive code.

\n
const rightOption = document.createElement('option');\nrightOption.value = 'Right';\nrightOption.textContent = 'Right';\n// ...\n
\n

Looking back at it, it is quite brittle and challenging to debug, but I can thank my understanding of JavaScript fundamentals for framework-less code like this.

\n

Reaching America

\n

As soon as I got the official go-ahead from the organisers, I booked a flight ready to set off for Boston.

\n

Coming alongside me were two friends who also qualified for the event. They had put in the hours to earn tickets, and we all came over together.

\n

The flight took a long eight hours, but after not too long we finally reached America.

\n

\"EDIC

\n

Once we arrived at the airport, we set off to EDIC Pier where we laid our picnic blankets and bought some local food. I got to know the other contestants who were there. Many were American, but surprising numbers were from all across the globe, with one even as far as Vietnam!

\n

\"Boston

\n

It didn't take long until we began to set off towards Cathleen Stone Island. The ride was short but a great opportunity to chat with the other people there and take some photos. By the time we finally reached the island, we had already decided on the structure of our teams.

\n

Everyone scrambled to claim their beds, but as one of my projects had gone viral, I was given first pick and stayed in the executive suite with the other viral programmers. It was here that I met Daniel, another participant who managed to go viral, and formed a team with him and Oliver.

\n

By the end of the day, we were all invited down to the pavilion to learn about the first project we would be assigned. This hackathon had three projects that we would make in total, each themed around a certain idea. The first project was to design a method of communication that wouldn't involve letters or numbers.

\n

SymbolNotes

\n

\"SymbolNotes

\n

In my team, we decided to create an online peer-to-peer messaging app. Since I had prior experience with the PeerJS library, I suggested that we use that.

\n

As per hackathon tradition, the code we made was hacky, and the graphics were rough, but we managed to create a working solution. We released the source code for SymbolNotes onto GitHub so others could examine and learn from it. We made it together over the course of a morning and submitted it onto The Bay.

\n

Exploring The Island

\n

\"Map

\n

With our project complete, we spent the rest of the day exploring the island as a team. The executive suite and pavilion were both very close to the docks, but there was the entire rest of the island still to investigate.

\n

Alongside us were some Americans who knew the area much better than we did and told plenty of stories about what it was like living in America. As somebody who'd only set foot outside Europe once before, it was very refreshing to hear such different perspectives.

\n

Before long, however, it was back to the next challenge.

\n

Connect Infinity

\n

\"Connect

\n

Our next challenge was to design a creative game that could be played online. We decided to put a spin on the classic game Connect 4 and make it real-time. To prevent it from ending extremely quickly, the game only ends once the entire board is full. Every 4-in-a-row gives a point, most points win.

\n

Now the team had got used to PeerJS, we decided to use it once again here as it seemed perfectly suited for the task. As a challenge, we designed the code so that lobbies of unlimited size were supported, instead of just groups of two.

\n

This took more time than the previous project due to its larger scope, but we worked as a team much more efficiently. After a few tireless hours, Connect Infinity was created just in time to present.

\n

We took laptops down to the pavilion and set them up running the game by the shore. The other participants all tried out the game, and it was surprisingly well received! We managed to win a limited-edition Shipwrecked shirt, which I still have and wear to this day.

\n

Perlin Colours

\n

\"Perlin

\n

Our final task was to create a project that heavily featured a variety of colours. One of our team had the idea to create a Perlin noise generator that could create plenty of colourful gradients. We decided to name it Perlin Colours.

\n

After some research on the formulas involved and a fair bit of trial and error, we ended up with a functioning noise generator implemented with HTML Canvas. I had dabbled with Canvas before, but this was the first time I had implemented a proper renderer using it.

\n

We ended up sleeping on the problem, but once we woke up, we were fully refreshed and fixed the final bugs with the implementation. It was very satisfying to have a proper end product.

\n

The project was presented, and it went down a treat! The prizes were limited-edition laptop stickers that I have proudly stuck onto my laptop ever since.

\n

Returning Home

\n

\"Boston

\n

Alas, all good things must come to an end. It was the final day, so I gathered all my belongings and packed them away into a suitcase. My team attended the closing ceremony and said our goodbyes to the people there. There were so many nice people I met, and I'll cherish the memories made forever.

\n

I caught an Uber alongside some others also needing a flight back and returned to the airport. It was there our team finally disbanded. One amusing thing at the airport was the Hack Club official plushies were just over the weight limit and were tripping all the security alarms. I got through just fine, but it caused a right mess!

\n

It was then I also got to see my very first American passport. Having only seen European ones, it was a right culture shock with pages full of landmarks and a giant eagle on the photo page.

\n

The actual flight was thankfully uneventful. I watched the in-flight entertainment and ate the food, but slowly drifted off to sleep until we landed.

\n

Reflections

\n

Participating in Shipwrecked is an experience I'll remember forever, and I thank Hack Club and the organisers for helping set up such a wonderful event. I have still maintained contact with several of the other people there and arrange to meet up with them at future hackathons.

\n

It was also very enjoyable working in teams. Having spent so much of my time programming solo, it was nice bouncing ideas back and forth to come to informed conclusions.

\n

I've done many other things with Hack Club since, but they are perhaps a story for another blog post...

\n

One thing you can take for granted is that I'll absolutely be doing more hackathons in the future!

\n","date_published":"2026-02-11T00:00:00.000Z","tags":["hack-club","hackathon"]},{"id":"https://hawksley.dev/blog/building-astro-blog","url":"https://hawksley.dev/blog/building-astro-blog","title":"Building an Astro Blog","summary":"My developer experience trying out the Astro framework and ditching my old site.","content_text":"My developer experience trying out the Astro framework and ditching my old site.","content_html":"

I've owned the domain name hawksley.dev for a while now, but I've never done much with it aside from sending email. Over the weekend, I thought I might as well make good use of it and decided to create a blog.

\n

In the beginning, this site had a humble home page with some links to GitHub projects. A blog requires much more infrastructure for me to use it effectively. For one, it'd be great if I could just write my posts in Markdown and have them formatted by my project automatically. Having a look at the options available, the first that stood out was GitHub's Jekyll. It looked nice and had great integration with GitHub Pages, which I'm hosting with at the time of writing. However, it just felt too rigid. I needed something modern that I felt I could get my hands dirty with.

\n

Enter Astro.

\n

Why Astro

\n

In the grand scheme of things, the Astro framework is pretty new at just 5 years old. That hasn't prevented it from gaining popularity rapidly. It holds performance as a key design principle, anything that can be static will render statically. By default, it ships absolutely no JS to the browser, which felt perfect for my use case. I have no need for advertising or heavy tracking scripts weighing down my site. All I need is a place to write.

\n

Learning how to work with Astro was completely painless. I created a new GitHub repository and followed along with their very high-quality documentation to create a blog of my own. At the very end of it, I’d created a nice neat blog that loaded instantly and was easy to write for.

\n

I wasn't satisfied by using the tutorial's blog for my site, though, as it felt too cookie-cutter, and so I started again, now with confidence in the framework.

\n

The Design Decisions

\n

There were some definite design decisions I knew I wanted from the get-go. First-class light mode and dark mode support were a must. Plenty of blogs offered just one or the other, and after a bit of digging, it didn't seem technically hard to implement at all.

\n

Another key principle was mobile-first design. Many of my previous projects started with the key assumption that the reader will be on a laptop or desktop, but that often isn't the case. Mobile devices account for approximately two-thirds of global internet traffic, with the remaining third coming from desktops. I wanted this site to stand the test of time until I inevitably rebuild it again, so it's only natural I designed it with mobile devices in mind.

\n

My final decision I knew I wanted was to have excellent performance scores, one of the very reasons that I chose Astro for the job. Components are almost a certainty in modern web design to ensure consistency across pages, but I needed to write components used at compile time, rather than at run time.

\n

Actually Programming the Site

\n

After creating an experimental fork of my main repository and wiping the directory, I initialised a new blank Astro project with pnpm create astro@latest and scaffolded the directory structure I'd need.

\n
public // Assets such as robots.txt and favicons.\nsrc\n  assets // Any assets displayed in the actual site.\n  components // Reusable components representing sections of UI.\n  content // Markdown files representing the blog.\n  layouts // The base layout each page uses.\n  pages // The actual pages rendered, combining all parts together.\n
\n

Development went very smoothly over two days and 15 full hours, with only some minor hiccups along the way.

\n

Google's PageSpeed Insights flagged my planned accent colour International Orange #FF4F00 as having insufficient contrast in light mode, so I had to split into separate accents for light and dark mode. By using global CSS variables that change depending on the theme, I implemented this change painlessly.

\n

I also encountered some CLS issues surrounding my choice of font. I personally love the look of the Inter font and included it in my project[^1]. However, although 300 KiB may not sound like a lot, on a slow connection it’s a noticeable delay. After some research I discovered the fontTools library and managed to shrink the Inter font to 70 KiB by subsetting the font to only the character sets I need.

\n

The Conclusion

\n

Astro has been a pleasure to work with, and I can easily see myself using it in future projects now I've adjusted to it.

\n

\"Perfect

\n

A perfect score has got to be one of the most satisfying feelings after doing a site redesign.

\n

[^1]: I'm now using IBM Plex Sans and IBM Plex Mono, but they are subsetted to 62KiB and 9KiB respectively, so the advice still holds.

\n","date_published":"2026-02-04T00:00:00.000Z","tags":["astro","web"]}]}