Thomas Sileo

bigbrowser: build provenance for bigbrowser’s Firefox web extension

Thu, 22 Jan 2026 00:00:00 +0000

bigbrowser: build provenance for bigbrowser’s Firefox web extension

Installing a Firefox extension requires a signed build (the .xpi file), and the process to get it signed is a bit cumbersome:

It requires a Mozilla Addons account
Each built version needs to be uploaded/validated/signed

I’ve tried to come up with a process to build and sign the extension in a way that can be “trusted”.

What I mean by trusted is how can I make people trust that the extension I provide was built using the code publicly available in the repo.

A common concept to help with that is “build provenance”, which is basically providing trustable metadata about the process.

The SLSA (Supply-chain Levels for Software Artifacts) security framework is trying to come up with some standard about build provenance, but I looked at it mainly for inspiration.

I am using Sourcehut builds for CI, which is a joy to work with and made the process quite easy.

Here’s my version of a simplified build provenance for the web extension:

The whole build/signing/uploading happens in a public CI build run
- This helps prove that the extension is built with the public code for a given tag
  - Mozilla provides an API to sign extensions
- It prints the SHA-256 hash of the signed extension after signing/before uploading
  - Artifacts are stored in a Backblaze B2 bucket
- It uploads the metadata in a bucket along with the build artifact:
  - date
  - artifact hash
  - CI job ID
Anyone can look at the job run and confirm it generated/uploaded this specific build
- The bucket is public and the download page will display the metadata

This process is way better than “trust me you can download this extension that I built locally on my machine”.

I will see how I can improve it over time but I feel like this is a good start!

bigbrowser: improving navigation trails

Wed, 10 Dec 2025 00:00:00 +0000

bigbrowser: improving navigation trails

In bigbrowser, a navigation trail starts when a tab is opened, and ends whenever that tab is closed, tracking all transitions in between. This led to weird behavior where I would follow links within a website, and then go to a totally different website by typing it into the address bar, and it would continue the existing trail.

I am updating bigbrowser to automatically reset trails based on the transition type.

link: clicked on a link within a page
auto_bookmark: clicked on a bookmark
typed: typed url in the address bar
…

And in bigbrowser’s case, I want to try starting a new trail on typed and auto_bookmark.

This information is gathered in the extension using the webNavigation API.

Aas usual there’s browser compatibility issues:

Firefox doesn’t expose transitiontype in oncompleted events, only in oncommitted
Firefox doesn’t support the auto_bookmark transition at all

Excited to see how it improves the trails!

TIL about CSS scroll-margin

Thu, 27 Nov 2025 00:00:00 +0000

TIL about CSS scroll-margin

I am working on the bigbrowser documentation website, and the page has a sticky navigation bar at the top.

Everything was working well until I decided to add a basic table of content. Clicking on a section would scroll to the correct location, but the section title was hidden behind the sticky navbar.

It turns out there’s a CSS property designed to help with this use case: scroll-margin-top.

It’s mainly used for “scroll snapping” (which I’d never heard of before either). This helps implement carousel-style scrolling where content “snaps” into place (the MDN page shows an example). But since it also affects anchored links scroll positions, that’s exactly what I needed.

Here’s the fix, it can be applied to headings directly, and anchored links will magically have a 80px margin top:

#docs h2[id],
#docs h3[id] {
    scroll-margin-top: 80px;
}

I had no idea that “offsetting” the scroll was natively supported in CSS, it’s quite nice not having to resort to any hack!

The heading is now properly positioned below the sticky navbar

bigbrowser: content extraction weirdness

Mon, 17 Nov 2025 00:00:00 +0000

bigbrowser: content extraction weirdness

While reviewing the results of the content extractor (used to power the history search engine), I ended up with CSS rules as part of the extracted text.

.css-1x8m391 { fill: rgb(7, 79, 105); } extracted content

At first, I thought that the website somehow embedded CSS style outside of regular <style> tags.

It turns out that the indexed website is using XHTML (as in <html xmlns="http://www.w3.org/1999/xhtml" lang="en">) and uses some namespaced <style> tags: <a0:style>.

This is my first time stumbling upon namespaced tags while processing HTML documents.

bigbrowser uses html5ever for content extraction and the namespace is included as part of the tag local name.

This was kind of unexpected to me, but XHTML is XML and it makes sense for a “pure” HTML parser to parse the whole tag without parsing the namespace.

As a result, I ended up using tag_name_str.ends_with(":style") to detect style tags.