From 6d29322b240f043450a7cfbba5c0427515331756 Mon Sep 17 00:00:00 2001
From: Anton Livaja <anton@livaja.me>
Date: Mon, 29 Sep 2025 10:39:35 -0700
Subject: [PATCH] fix up site, add blog

---
 _config.yml                                |   2 -
 _includes/blog-about-distrust.html         |   9 +-
 _includes/{footer.html => footer.html.bkp} |   0
 _includes/header.html                      |  19 +--
 _layouts/landing.html                      |  10 +-
 _posts/2025-04-02-bybit-safe-report.md     | 164 ---------------------
 _posts/2025-09-29-verifiable-compute.md    |  75 ++++++++++
 _sass/base.scss                            | 126 +++++++++++++++-
 assets/js/main.js                          |   9 --
 9 files changed, 210 insertions(+), 204 deletions(-)
 rename _includes/{footer.html => footer.html.bkp} (100%)
 delete mode 100644 _posts/2025-04-02-bybit-safe-report.md
 create mode 100644 _posts/2025-09-29-verifiable-compute.md

diff --git a/_config.yml b/_config.yml
index 7c60ec7..c20163d 100644
--- a/_config.yml
+++ b/_config.yml
@@ -11,8 +11,6 @@ header_pages:
 style: dark
 listen_for_clients_preferred_style: false
 
-footer: '© 2025 Caution'
-
 theme: jekyll-theme-console
 
 permalink: blog/:title.html
diff --git a/_includes/blog-about-distrust.html b/_includes/blog-about-distrust.html
index 6fa4cdd..1716348 100644
--- a/_includes/blog-about-distrust.html
+++ b/_includes/blog-about-distrust.html
@@ -1,10 +1,5 @@
-<h2>About Distrust</h2>
+<h2>About Caution</h2>
 
-<p>The Distrust team has helped build and secure some of the highest-risk systems in the world. This includes vaulting infrastructure at BitGo, Unit410, and Turnkey, as well as security work with electrical grid operators, industrial control systems, and other mission-critical systems.</p>
+<p>The Caution team has helped build and secure some of the highest-risk systems in the world via their consulting company Distrust. This includes vaulting infrastructure at BitGo, Unit410, and Turnkey, as well as security work with electrical grid operators, industrial control systems, and other mission-critical systems.</p>
 
-<p>We've conducted deep security due diligence across most major custodians. Through our experience with organizations that operate under constant threat—where **every class of attack is viable**—we've developed a methodology and set of open source tools designed to defend against even the most sophisticated adversaries.</p>
-
-<p>Today, we're taking the hard-earned lessons from that work and sharing them with the broader community. Our goal is to help others strengthen their security posture by making what we've learned—and the open source tools we've built—available to everyone.</p>
-
-<p><b>Looking for help analyzing and mitigating security risks in your own organization? <a href="/contact.html">Talk to us.</a></b></p>
 
diff --git a/_includes/footer.html b/_includes/footer.html.bkp
similarity index 100%
rename from _includes/footer.html
rename to _includes/footer.html.bkp
diff --git a/_includes/header.html b/_includes/header.html
index 516eb24..39052b7 100644
--- a/_includes/header.html
+++ b/_includes/header.html
@@ -10,7 +10,7 @@
 		</a>
 
 		<nav class="nav-menu">
-			<div class="nav-dropdown">
+			<!--<div class="nav-dropdown">
 				<button class="nav-dropdown-toggle">
 					Caution
 					<img
@@ -30,20 +30,21 @@
 					</li>
 					<li><a href="#" rel="noopener noreferrer">Contact</a></li>
 				</ul>
-			</div>
+			</div>-->
 
+			<!--
 			<a class="nav-link" href="/dr.html" rel="noopener noreferrer"
 				>Disaster Recovery</a
 			>
 			<a class="nav-link" href="/pricing.html" rel="noopener noreferrer"
 				>Pricing</a
 			>
-			<a class="nav-link" href="#">Docs</a>
+			<a class="nav-link" href="#">Docs</a>-->
 		</nav>
 
 		<div class="nav-cta">
-			<a href="#" class="btn btn-primary" rel="noopener noreferrer"
-				>Get started →</a
+			<a href="/blog.html" class="btn btn-primary" rel="noopener noreferrer"
+				>Blog →</a
 			>
 		</div>
 	</div>
@@ -87,10 +88,10 @@
 			</div>
     </div>
   </div>
-	
-	
-	
-	<script> 
+
+
+
+	<script>
 		document.addEventListener('DOMContentLoaded', function () {
 			let pathSegment = window.location.pathname.split('/')[1];
 
diff --git a/_layouts/landing.html b/_layouts/landing.html
index 2062fed..78f26b4 100644
--- a/_layouts/landing.html
+++ b/_layouts/landing.html
@@ -7,16 +7,12 @@
 		<main>
 			<section class="hero landing">
 				<div class="hero-content landing container">
-					<h1 class="hero-title landing">Secure what matters most.</h1>
+					<h1 class="hero-title landing">Verifiable Compute</h1>
 					<p class="subtext">
-						Recover any encrypted data without relying on blind trust. Open
-						source, verifiable, and trustless by design.
+					Caution is the next-gen compute platform – verifiable, portable, and fast to deploy. Built by the security engineers behind <a href="https://distrust.co" target="_blank" rel="noopener noreferrer">Distrust</a>.
 					</p>
 					<div class="hero-cta">
-						<a href="#" class="btn">Get started →</a>
-						<a href="/contact.html" class="btn btn-secondary"
-							>Contact sales →</a
-						>
+						<a href="/blog.html" class="btn">Blog →</a>
 					</div>
 				</div>
 			</section>
diff --git a/_posts/2025-04-02-bybit-safe-report.md b/_posts/2025-04-02-bybit-safe-report.md
deleted file mode 100644
index 3eff44f..0000000
--- a/_posts/2025-04-02-bybit-safe-report.md
+++ /dev/null
@@ -1,164 +0,0 @@
----
-layout: post
-title: The Safe{Wallet}/Bybit incident report and mitigation strategies
-date: 2025-04-02
----
-
-The Safe{Wallet}/Bybit incident is an example of a nation-state actor executing a series of sophisticated, multi-layered attacks on high-value targets. In cases where the potential gain is significant, all attacks are on the table. It may be justified for attackers to invest in multiple 0-day vulnerabilities and chain them into elaborate exploit sequences. These campaigns often span multiple layers of tech stack, involve precision-targeted social engineering, insider compromise, or even physical infiltration.
-
-As such, defending against this level of adversary requires a threat model that accounts for their full range of capabilities—and guides the design of equally rigorous mitigations. It demands defenders adopt a much more rigorous set of assumptions about attacker's capabilities and invest time in implementing controls that typical organizations may not need. When protecting high value assets, the game changes.
-
-### Threat model assumptions
-
-At Distrust, we operate under the assumption that nation-state actors are persistent, highly resourced, and capable of compromising nearly any layer of the system. Accordingly, our threat model assumes:
-
-* All screens are visible to the adversary
-* All keyboard input is being logged by the adversary
-* Any firmware or bootloader not verified on every boot is considered compromised
-* Any host OS with network access is compromised
-* Any guest OS used for non-production purposes is compromised
-* At least one member of the Production Team is compromised
-* At least one maintainer of third party code used in the system is compromised
-* At least one member of third party system used in production is compromised
-* Physical attacks are viable and likely
-* Side-channel attacks are viable and likely
-
-These assumptions drive everything at Distrust, including the strategies and tooling outlined in this report. The strategies we've developed are built specifically to address this elevated threat model. Many of our open source tools are ready to use today, some are reference designs, while other tooling requires further development.
-
-### Summary
-
-This report identifies critical single points of failure—cases where trust is placed in a single individual or computer—creating opportunities for compromise. In contrast, blockchains offer stronger security properties through cryptography and decentralized trust models.
-
-Traditional infrastructure has historically lacked mechanisms to distribute trust, but this limitation can be addressed. By applying targeted design strategies, it's possible to distribute trust (**dis**trust, get it?) across systems and reduce the risk of a single compromised actor undermining the integrity of the entire system.
-
----
-
-## Root cause analysis and mitigation strategies
-
-In our opinion, the primary causes of this incident stem from two key issues identified in the <a href="http://web.archive.org/web/20250328121908/https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/" rel="noopener noreferrer" target="_blank">Sygnia report</a>.
-
-* > ... a developer’s Mac OS workstation was compromised, likely through social engineering.
-
-* > ... the modification of JavaScript resources directly on the S3 bucket serving the domain app.safe[.]global.
-
-These findings highlight both endpoint compromise and weak controls around cloud infrastructure. The following sections focus on how such risks could be mitigated through architectural decisions and more rigorous threat modeling.
-
-## Introduction
-
-The compromise occurred due to several key factors, already documented in other reports. This report focuses on how the incident **could have been prevented** through a stronger, first-principles approach to infrastructure design.
-
-While many security teams reach for quick wins—like access token rotation, stricter IAM policies, or improved monitoring—these are often reactive measures. They may help, but they're equivalent of "plugging holes on a sinking ship" rather than rebuilding the hull from stronger material.
-
-For example, improving access control to the S3 bucket used to serve JavaScript resources, or adding better monitoring, are good steps. However, they  don't address the root cause.
-
-> At the core of this breach lies a recurring theme: single points of failure.
-
-To explore this from first principles, consider the deployment pipeline. In most companies, one individual—an admin or developer—often has the ability to modify critical infrastructure or code. That person becomes a single point of failure.
-
-Even if the pipeline is hardened, the risk will shift, rather than disappear. There is almost always one super-admin who has the "keys to the kingdom". Most cloud platforms encourage this pattern, and the industry has come to accept it.
-
-But this isn't about doubting your team and their intentions—it's about designing systems where **trust is distributed**. In the blockchain space, this is already accepted practice. So the question becomes:
-
-> *Does it make sense for a single individual to hold the integrity of an entire system in their hands?*
-
-Those who've worked with decentralized systems would say: absolutely not.
-
-#### Mitigation principles
-
-To adequately defend against the risks outlined in the Distrust threat model, it is critical to distinguish between **cold** and **hot** wallets. The following principles are drawn from practical experience building secure systems at BitGo, Unit410, and Turnkey, as well as from diligence work conduced across leading custodial and vaulting solutions.
-
-* A **cold cryptographic key management system** is one where all components can be built, operated, and verified offline. If any part of the system requires trusting a networked component, it becomes a **hot** system by definition. For example, if a wallet relies on internet-connected components, it should be considered a hot wallet—regardless of how it's marketed. While some systems make trade-offs for user experience, these often come at the cost of security guarantees.
-
-* Cold cryptographic key management systems that leverage truly random entropy sources are **not susceptible to remote attacks**, and are only exposed to localized threats such as physical access or side-channel attacks.
-
-* A common misconception is that simply keeping a key offline makes a system cold and secure. But an attacker doesn't always need to steal the key—they just need to achieve the outcome where the key performs an operation on the desired data on their behalf.
-
-* **All software in the stack must be open source**, built deterministically (to support reproduction), and compiled using a fully bootstrapped toolchain. Otherwise, the system remains exposed to single points of failure, especially via supply chain compromise.
-
-#### Mitigations and reference designs
-
-We propose two high-level design strategies that can eliminate the types of vulnerabilities exploited in the Safe{Wallet}/Bybit attack. Both approaches offer similar levels of security assurance—but differ significantly in implementation complexity and effort.
-
-In our view, **when billions of dollars are at stake**, it is worth investing in proven low-level mitigations, even if they are operationally harder to deploy. The accounting is simple: **invest in securing your system up front**, rather than gambling on assumptions you won't be targeted.
-
-State funded actors are highly motivated—and when digital assets are involved, it's game theory at work. The cost of compromising a weak system is often far less than the potential gain.
-
-We've seen this playbook used in previous incidents, a major example being Axie Infinity, and we will see it again. Attackers are increasingly exploiting supply chains and single points of failure—while defenders often under-invest in securing this surface area.
-
-#### Strategy 1 - Run everything locally
-
-This strategy can be implemented without major adjustments to the existing system. The goal is to move the component currently introducing risk—effectively making the wallet "hot"—into an offline component, upgrading the system to a fully cold solution.
-
-The idea centers on extracting the **signing** component from the application (which currently operates in the UI) and converting it into an offline application.
-
-However, simply making a component offline does not eliminate all single points of failure. To close off supply chain threats stemming from compiler, dependency or environment compromise requires that the application is reproduced on multiple diverse systems (using different chipsets and operating systems), using a fully bootstrapped compiler—a fully hermetic, deterministic and reproducible process.
-
-We've developed open source tooling for this under <a href="https://codeberg.org/stagex/stagex" target="_blank" rel="noopener noreferrer">StageX</a>. To learn more about the importance of reproducible builds, check out <a href="https://antonlivaja.com/videos/2024-incyber-stagex-talk.mp4" target="_blank" rel="noopener noreferrer">this video</a>, where one of our co-founders explains how the SolarWinds incident unfolded—and how it could have been prevented.
-
-##### Reference design
-
-This reference design was developed for the Safe{Wallet} team, but it can be applied to any system seeking to distribute trust.
-
-1. **System administrators use dedicated offline laptops**
-
-	* All radio hardware (Bluetooth, Wi-Fi) is physically removed
-
-	* Machines are air-gapped and have never been connected to the internet
-
-2. **Engineers provision and manage their own personal signing keys (PGP)**
-
-	* Smart cards like NitroKey or YubiKey are used
-
-	* Signing operations are performed exclusively on the engineer's offline system
-
-	* Distrust has developed open source tooling to drastically simplify PGP key provisioning: <a href="https://trove.distrust.co/generated-documents/all-levels/pgp-key-provisioning.html" target="_blank" rel="noopener noreferrer">Trove</a>
-
-3. **Offline signing applications are deterministically compiled, verified, and signed by multiple engineers**
-
-	* Includes a full set of tools needed for secure offline key operations
-
-	* Distrust also created <a href="https://git.distrust.co/public/airgap" target="_blank" rel="noopener noreferrer">AirgapOS</a>, a custom Linux distribution designed specifically for offline secret management. It has been independently audited and is used in production by several major digitial asset organizations.
-
-4. **All sensitive operations are fully verified offline before any cryptographic action is taken**
-
-This design drastically reduces exposure to remote attacks and central points of trust, aligning closely with Distrust's first-principles security model.
-
-#### Strategy 2 - Use remotely verified service
-
-This strategy maintains a user experience nearly identical to the current system, while introducing verifiability at critical points in the architecture. It requires significantly more engineering effort and operational discipline, and the tooling needed to support this model is still under active development.
-
-##### Reference design
-
-This design relies on **secure enclaves** to host servers that are immutable, deterministic, and capable of cryptographically attesting to the software they are running. While this brings us closer to a cold setup, some residual attack surface—such as browser exploits, host OS compromise, or 0-day attacks—will always remain.
-
-The core implementation steps are:
-
-1. **Rewrite the application to run entirely within a secure enclave**
-
-	* TLS termination occurs **inside** the enclave
-
-	* The web interface is served **from within** the enclave
-
-	* Nothing outside the enclave is trusted
-
-2. **Create a deterministic OS image with remote attestation (e.g., TPM2, Nitro Enclave or similar)**
-
-	* The entire stack is built using full source bootstrapped compiler in a bit-for-bit reproducible manner
-
-3. **One engineer deploys a new enclave** with the updated application code
-
-4. **A second engineer independently verifies** that the deployed code matches the version in the source repository
-
-5. **Clients are issued a service worker** on first load that pins attestation keys for all future remote verification
-
-	* Users can optionally verify and download the application locally for offline operations
-
-	* Users are also encouraged to self-build and match the published signed hash
-
-
-## Implementation considerations
-
-Implementing these strategies can be technically demanding. They represent two ends of the trust minimization spectrum: one favoring offline, air-gapped assurance; the other introducing verifiability within connected systems. Both approaches significantly reduce risk but vary in complexity, tooling and requirements, and rollout timelines.
-
-This high-level overview is meant to illustrate the kinds of problems we focus on at Distrust. Depending on the chosen strategy and organizational context, implementation can take anywhere from a few weeks to several years, especially as tooling continues to mature.
-
diff --git a/_posts/2025-09-29-verifiable-compute.md b/_posts/2025-09-29-verifiable-compute.md
new file mode 100644
index 0000000..9506b77
--- /dev/null
+++ b/_posts/2025-09-29-verifiable-compute.md
@@ -0,0 +1,75 @@
+---
+layout: post
+title: Introducing Generalized Verifiable Compute
+date: 2025-09-29
+---
+
+What if the software running your systems isn't what you think? And if you had to prove what software is on a system, how would you do it?
+
+Most of today’s technologies are black boxes. From firmware and operating systems to compilers and cloud platforms, opacity is the default. Users can send requests to an API or server, but they cannot verify what software, or whose software, they are really interacting with. The issue impacts organizations internally as well, where system managers can't verify whether the code they think they deployed is actually what's running on the server. This is not just a usability issue it is a systemic design failure and the result is software stacks riddled with blind spots, where compromise can occur at any stage and remain invisible.
+
+After many years of working with high risk clients and analayzing different technologies, our team has concluded the pieces needed for verifiable systems already exist, but they are underutilized because they are misunderstood and difficult to use - a problem we needed to solve.
+
+Reproducible builds, secure enclaves, and cryptographic remote attestation each solve part of the problem. Taken together, they form the building blocks for **verifiable compute**, which allows software to be verified. Our work is focused on creating the next generation of cloud hosting platform centered around verifiability and elimination of single points of failure present in current market solutions.
+
+Like “zero trust” before it, the term verifiable compute is already being hijacked by marketing teams. Companies throw it around to describe partial solutions — usually just proving a binary hash hasn’t changed. We take a stricter view: verifiable compute means the entire supply chain can be checked. Anything less is **not** verifiable compute.
+
+## The Real-World Risk of Unverifiability
+
+The risks of unverifiable systems are not theoretical — they’ve already caused some of the most damaging security incidents of the past decade.
+
+SolarWinds (2020) showed how a compromised software supply chain can cascade globally. Attackers injected malicious code into SolarWinds’ Orion updates, which were then shipped to thousands of companies and U.S. government agencies. Because customers had no way to verify what software they were actually running, the backdoor spread silently through trusted update channels.
+
+This is one of the many breaches which demonstrate that without verifiability across the entire stack, organizations have no reliable way to prove the integrity of the systems they depend on.
+
+## What True Verifiability Requires: The Building Blocks
+
+Our team established that three key technologies are essential for making software verifiable end-to-end:
+
+- Reproducible builds
+
+Reproducible builds eliminate certain categories of supply chain attacks and would have prevented incidents like Solar Winds. It allows for integrity verification, without which software is opaque and difficult to verify.
+
+- Secure enclaves
+
+Hardware-isolated execution (e.g., IOMMU-backed enclaves) prevents external processes — even privileged ones — from tampering with sensitive workloads. Enclaves give us strong isolation, but isolation alone doesn’t prove what is running.
+
+- Remote attestation
+
+Remote hardware attestation (TPM2, Intel TDX, AMD SEV, AWS Nitro, and others) measure the state of a machine and provide cryptographic proof of what software is running. Attestation anchors trust at the hardware layer, but on its own it doesn’t guarantee the software’s provenance or build integrity.
+
+Taken together, these three technologies form the foundation of true verifiable compute: the ability to verify the integrity of software from the toolchain it’s built with to the hardware it runs on.
+
+## Why Existing Platforms Fall Short
+
+Current offerings from the major cloud providers — AWS, Azure, and GCP — are demanding in terms of both expertise and time to set up. They also lock users into a single vendor’s ecosystem and force reliance and trust in one type of hardware or firmware. For example, AWS requires implicit trust in its proprietary Nitro Card, a black-box technology that customers cannot independently verify.
+
+Other companies, such as Tinfoil, Turnkey, and Privy, offer wrappers around enclave and attestation technologies, but their solutions are limited to narrow use cases like digital asset wallets or running LLMs. Even then, what they provide is only surface verification: proving that a binary’s hash hasn’t changed. That does not give transparency into the entirety of what is running on the server.
+
+In short: these are “partially verifiable, but still mostly black-box” solutions. They fall far short of end-to-end verifiability, and risk diluting the very meaning of the term “verifiable compute.”
+
+## “Cautiously” Building the Next Generation of Verifiable Compute
+
+Our team has chosen a no-compromise approach to solving this problem:
+
+- Fully open source. Every component we build is transparent and verifiable.
+
+- Deterministic from the ground up. All software in our stack is full-source bootstrapped and reproducible.
+
+- Portable across environments. Deployable on any major cloud, bare metal, or self-hosted environment.
+
+- Resilient by design. We use multiple hardware attestations per server to distribute risk and eliminate reliance on a single vendor.
+
+This approach didn’t emerge overnight. We kept running into the same problems over and over again — whether working with high-risk clients or just pulling apart existing cloud platforms. Everything boiled down to the same pattern: black-box infrastructure, half-measures passed off as “verification,” and single points of failure you couldn’t design around.
+
+At some point it clicked. The primitives — reproducible builds, enclaves, attestation — already existed. What didn’t exist was a way to actually use them without an army of engineers and months of duct-taping. That’s when we decided to build it ourselves. That’s how Caution was born.
+
+We’ve already laid the foundation. StageX is the first LLVM-based, bootstrapped, and fully deterministic Linux distribution, and EnclaveOS is nearing completion as a portable OS for deploying verifiable compute across clouds and bare metal, levarging multi-hardware attestation. The next step is the hosting platform — designed to deliver unprecedented transparency and resilience. Unlike today’s hyperscalers, our architecture eliminates single points of failure, including the root-admin model that makes existing platforms inherently untrustworthy.
+
+We believe this marks the beginning of a new era of infrastructure: verifiable, open, and resilient by default.
+
+## Closing Thoughts
+
+Vitalik is right: verifiability is critical for the future. To get there, we must be precise about definitions, uncompromising in execution, and provide easy to use tooling to leverage concrete technical controls. Verifiable compute is the new foundation for infrastructure.
+
+At Caution, we’re building that foundation. If you’re interested in collaborating, contributing, or investing, we’d love to talk.
diff --git a/_sass/base.scss b/_sass/base.scss
index 558d3bd..86a1224 100644
--- a/_sass/base.scss
+++ b/_sass/base.scss
@@ -80,7 +80,7 @@ $container-max-width: 1440px !default;
 
 html,
 body {
-	min-height: 100%;
+	min-height: 100vh;
 	width: 100%;
 	margin: 0;
 	padding: 0;
@@ -343,11 +343,6 @@ img {
 
 .hero.landing {
 	min-height: 100svh;
-	background-image: linear-gradient(
-			rgba(255, 255, 255, 0.3),
-			rgba(255, 255, 255, 0.3)
-		),
-		url(/assets/imgs/hero-glass-flow.jpeg);
 	background-size: 125%;
 	background-position-y: 0vh;
 	background-repeat: no-repeat;
@@ -639,6 +634,125 @@ img {
 	font-size: clamp(1.1rem, 2.5vw, 1.25rem);
 }
 
+//* Blog */
+
+.blog-link:hover .arrow {
+	transform: translateX(5px);
+	background: none !important;
+	background-color: var(--base-color);
+	color: white !important;
+}
+
+.blog {
+	margin: auto;
+	max-width: 700px;
+	margin-top: 120px;
+}
+
+.post {
+	max-width: 700px;
+	margin: 100px 0px;
+}
+
+.post img {
+	max-width: 100%;
+}
+
+#lp-post-img {
+	max-width: 100%;
+}
+
+#lp-post-img {
+   max-width: 100%;
+}
+
+.entry {
+	font-size: 1.2rem;
+}
+
+.date h4 {
+	font-size: 1rem !important;
+}
+
+#blog-header {
+	margin: 80px 0px;
+}
+
+.blog-header-title {
+	display: inline-block;
+	font-size: 3.2rem;
+	text-align: center;
+	width: 100%;
+	margin-top: 80px;
+}
+
+.blog-header-subtitle {
+	text-align: center;
+	font-size: 1.5rem;
+	color: var(--light-grey);
+}
+
+.blog h1 {
+	font-size: 2rem !important;
+	line-height: 2rem !important;
+	font-weight: 600 !important;
+}
+
+.blog h2 {
+	font-size: 1.8rem !important;
+	font-weight: 600 !important;
+}
+
+.blog h3 {
+	font-size: 1.6rem !important;
+	font-weight: 600 !important;
+}
+
+.blog h4 {
+	font-size: 1.4rem !important;
+	font-weight: 600 !important;
+}
+
+.blog h5 {
+	font-size: 1.2rem !important;
+	font-weight: 600 !important;
+}
+
+.blog hr {
+	margin: 80px 0px;
+}
+
+.post a {
+	color: var(--pink);
+}
+
+.post a:hover {
+	text-decoration: underline;
+}
+
+.blog-details {
+	display: flex;
+	flex-direction: left;
+	font-size: 0.9rem;
+	margin-bottom: 10px;
+}
+
+.blog-details-date {
+	background: var(--light-grey);
+	color: var(--background-color);
+	border-radius: 5px;
+	padding: 2px 10px;
+}
+
+.blog-details-read-time {
+	padding: 2px 10px;
+	margin-left: 15px;
+	color: var(--pink);
+}
+
+/** end blog */
+
+
 // ====== PRICES ======= //
 
 .price {
diff --git a/assets/js/main.js b/assets/js/main.js
index 8649df7..c0ee793 100644
--- a/assets/js/main.js
+++ b/assets/js/main.js
@@ -129,15 +129,6 @@ document.addEventListener("DOMContentLoaded", function () {
 
 	if (!footer) return;
 
-	const borderStyles = {
-		"/software.html": "2px solid var(--light-teal)",
-		"/blog.html": "2px solid var(--pink)",
-	};
-
-	if (borderStyles[path]) {
-		footer.style.borderTop = borderStyles[path];
-	}
-
 	// Set hover color
 	const hoverColors = {
 		"/software.html": "var(--light-teal)",