Christopher Dignam

Firebase Storage vs Cloud Storage Latency

2026-03-23T00:00:00+00:00

Firebase Storage provides an easy way to save and retrieve files in Google Cloud Storage, without needing a server.

The downside of Firebase Storage is the added 500ms of latency over using Google Cloud Storage directly.

Comparison

To compare the two services, I accessed the same file, multiple times via Firebase Storage and Cloud Storage.

The DNS, TCP, TLS, and download speeds are similar, but the Time to First Byte (TTFB) averages 549ms for Firebase Storage versus 41ms for Google Cloud Storage.

Name	DNS	TCP	TLS	TTFB	Download
Firebase Storage trial 1	0.041	0.017	0.036	0.477	0.285
Firebase Storage trial 2	0.003	0.097	0.034	0.499	0.170
Firebase Storage trial 3	0.003	0.027	0.042	0.672	0.185
Firebase Storage average	0.016	0.047	0.037	0.549	0.213
Cloud Storage trial 1	0.003	0.024	0.040	0.030	0.271
Cloud Storage trial 2	0.005	0.105	0.034	0.032	0.170
Cloud Storage trial 3	0.007	0.021	0.033	0.060	0.238
Cloud Storage average	0.005	0.050	0.036	0.041	0.226

Conclusion

To improve download performance, I enabled public read-only access to the bucket used by Firebase Storage.

Instead of downloading objects from https://firebasestorage.googleapis.com/v0/b/{bucket_name}/0, I download objects from https://storage.googleapis.com/{bucket_name}.

The objects are stored using random Firebase IDs, so it’s effectively impossible to guess the URLs, but once a user has the URL of a file, they’ll have access to that file forever.

Feedly API Tokens

2026-02-22T00:00:00+00:00

For a personal project, I need API access to my Feedly account.

Previously, with a paid Feedly account you could generate an API token for programmatic API access.

Now, Feedly locks this feature behind an Enterprise account ($2,400/month, billed annually).

So I needed to find another way to get API access.

Browser Dev Tools

My first idea was to copy the Feedly Authorization header from my browser’s network tools. But this token expires after a few days.

OAuth Applications

My second idea was to create a personal Feedly OAuth application, but this is locked behind approval from Feedly.

My workaround was to leverage an existing OAuth application and copy the OAuth refresh token used by the application.

NetNewsWire is an open source RSS Reader for macOS with Feedly support.

Since NetNewsWire uses OAuth to connect to the Feedly API, I can extract the OAuth credentials for my own use.

Apple Keychain

After logging into my Feedly account with NetNewsWire, I found two cloud.feedly.com “Internet Password” entries in “Keychain Access.app”.

One of these is the OAuth Access Token, and the second is the OAuth Refresh Token.

Sadly, these two credentials aren’t enough to generate a new access token.

We need the OAuth Client ID for the NetNewsWire Feedly OAuth application, and the OAuth Client Secret.

Charles Proxy

Using a man-in-the-middle proxy, Charles Proxy, I was able to intercept the web traffic between NetNewsWire and the Feedly OAuth API.

From this, I was able to extract all of the OAuth credentials necessary to generate a new OAuth Access Token.

I observed a request to the /v3/auth/token endpoint which contained the OAuth client_id and client_secret.

POST https://cloud.feedly.com/v3/auth/token
{
	"redirect_uri": "netnewswire:\/\/auth\/feedly",
	"client_id": "<NetNewsWire-client-id>",
	"code": "<fac_code>",
	"client_secret": "<NetNewsWire-client-secret>",
	"scope": "https:\/\/cloud.feedly.com\/subscriptions",
	"grant_type": "authorization_code"
}

The response contained an OAuth refresh_token and access_token.

{
  "id": "<my-feedly-user-id>",
  "provider": "Google",
  "is_new_account": false,
  "plan": "proPlus",
  "scope": "https://cloud.feedly.com/subscriptions",
  "refresh_token": "<refresh:token>",
  "access_token": "<JWE.token.here>",
  "token_type": "bearer",
  "expires_in": 604800
}

Now with all of the required information, I could call the Feedly API myself and generate a new OAuth access token.

curl -X POST https://cloud.feedly.com/v3/auth/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=refresh_token" \
  -d "refresh_token=<feedly-refresh-token>" \
  -d "client_id=<feedly-client-id>" \
  -d "client_secret=<feedly-client-secret>"

Improving Git Repository Performance

2026-01-25T00:00:00+00:00

For large repositories, the easiest way to improve performance is to enable feature.manyFiles:

git config --global feature.manyFiles true

Enabling this configuration will enable a newer index format and make git status faster.

With core.fsmonitor, Git will use FSEvents to monitor your repository for changes in a daemon.

git config --global core.fsmonitor true

This will improve git status performance too.

Some git log commands can be sped up with fetch.writeCommitGraph, but I didn’t notice a huge change with this.

git config --global fetch.writeCommitGraph true

I don’t notice git checkout being slow, but checkout.workers is supposed to help on SSDs:

git config --global checkout.workers 0

Conclusion

Enable these settings to improve repository performance.

git config --global feature.manyFiles true
git config --global core.fsmonitor true
git config --global fetch.writeCommitGraph true
git config --global checkout.workers 0

FNM (Fast Node Manager)

2026-01-23T00:00:00+00:00

FNM manages Node versions for your different projects.

FNM provides more features and is significantly faster than NVM, the de facto tool for managing Node versions.

Let’s compare the features and performance.

Shell Integration

When switching directories, FNM will automatically enable the required Node version based on the .nvmrc or .node-version files in the directory.

If the Node version is not installed already, FNM will prompt you to install it.

NVM doesn’t provide this functionality out-of-the-box and recommends using other tools.

Performance

FNM is fast.

Calling fnm use takes 4ms.

The equivalent nvm use takes 450ms.

FNM’s great performance means the shell integration won’t slow you down, unlike NVM.

Conclusion

FNM is better than NVM for managing Node versions.

How to generate a Firebase ID Token

2025-05-18T00:00:00+00:00

Firebase Functions has a https.onCall trigger that supports calling the Function from your Firebase client.

For the Mobile and Web Firebase SDKs, authentication is handled for you. But if you want to call these Cloud Functions manually, you need a Firebase ID Token.

Generating an ID Token

Creating an ID Token is a two step process. We first create a Custom Token for a user, and then exchange that token for an ID Token.

Create a Custom Token

Using the firebase_admin SDK, we can generate a Custom Token for a given Firebase Auth uid (User ID).

from firebase_admin import initialize_app, auth
initialize_app()
uid = "T29cMsbYVyNTNQhnkIApXIBDWB73"
custom_token = auth.create_custom_token(uid)

This custom_token doesn’t allow us to authenticate with Firestore. Instead, we must exchange this token for our ID Token using Google Cloud APIs.

Exchanging a Custom Token for ID Token

First, you’ll need a Google Cloud API Key which can be generated on the Google Cloud Console.

This API Key only needs Identity Toolkit access, so edit your key’s API restrictions to Identity Toolkit API.

Now we can use our custom_token from the previous step, along with our Google Cloud API key to call signInWithCustomToken and retrieve an ID Token:

CUSTOM_TOKEN="custom_token-from-previous-step"
API_KEY="your-google-cloud-api-token"
curl -X POST \
  "https://identitytoolkit.googleapis.com/v1/accounts:signInWithCustomToken?key=$API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    {"token": "$CUSTOM_TOKEN", "returnSecureToken": true}
  }'

{
  "kind": "identitytoolkit#VerifyCustomTokenResponse",
  "idToken": "<id.token.jwt>",
  "refreshToken": "<refresh-token>",
  "expiresIn": "3600",
  "isNewUser": false
}

The idToken in this response will allow us to authenticate with Firebase Functions.

Calling an Authenticated Firebase Function

With our idToken, we can call our Firebase Function, using the protocol specification for https.onCall as a reference.

ID_TOKEN="<id.token.jwt>"
curl -X POST \
  'https://us-central1-firebase-project-name.cloudfunctions.net/myFunctionName' \
  -H "Authentication: Bearer $ID_TOKEN" \
  -H 'Content-Type: application/json' \
  # firebase function arguments are passed in the `data` param:
  -d '{
    "data": {}
  }'

Prototype Pollution in Javascript

2024-05-24T00:00:00+00:00

At work a small percentage of requests were failing with bizzare error messages. A quick fix was to roll back our deployment, but it took a year and a half to find a solution to the underlying bug.

The root cause: prototype pollution

Prototype pollution

By setting a property on Object.prototype, we modify the prototype of all objects in Javascript. This is prototype pollution.

In this example, we set the hello property on our Object prototype. Now all objects in our Javascript process will have the hello property.

const foo = {}
console.log("hello" in foo) // false
Object.prototype.hello = "world"
console.log("hello" in foo) // true
console.log("hello" in {}) // true

You normally wouldn’t modify Object.prototype, but you can do so accidentally with the __proto__ property.

We can rewrite the previous example to use __proto__.

const foo = {}
console.log("hello" in foo) // false
foo["__proto__"].hello = "world"
console.log("hello" in foo) // true
console.log("hello" in {}) // true

Suspicious Code

This is a simplified recreation of the production code.

Because the bug is triggered by user-generated data, the bug was able to exist in the codebase for over a year and half before triggering an error.

This bug was only discovered after many of my previous attempts came up empty.

const events = [
  {
    name: "click",
    properties: [
      "user_id",
      "name",
      // the problematic user-provided attribute
      "__proto__",
    ],
  },
  {
    name: "navigate",
    properties: ["user_id", "url"],
  },
]
const countsByProperty = {}

events.forEach((event) => {
  for (const property of event.properties) {
    // when "property" is "__proto__", we retrieve the prototype of countsByProperty.
    let entry = countsByProperty[property]
    if (!entry) {
      entry = { count: 0 }
    }
    // "entry" is the Object prototype.
    entry.count += 1 // set the "count" property on "Object.prototype"
  }
})

// all objects will have an inherited property of "count".
console.log("count" in {}) // true

This on it’s own isn’t enough to cause damage. By setting count on the prototype, we set an “inherited property” for future objects. Iteration done correctly ignores them.

const a = {}
a.__proto__.count = 1

for (const key of a) {
  console.log(a)
}
// no output

In our case, we used lodash.omitBy to removed undefined properties from an object.

lodash.omitBy iterates over both “own properties” and “inherited properties”, returning a new object with all properties set as “own properties”.

The previously invisible count property, now became an iterable property in the new object created by Lodash. This new attribute triggered errors in our service, causing requests to fail.

const omitBy = require("lodash/omitBy")
const a = {}
a.__proto__.count = 1
console.log(a.count === 1) // true
console.log(Object.keys(a).length) // 0

const b = omitBy(a, (x) => x != null)
console.log(Object.keys(b).length) // 1

Once the object prototype was modified in our running service, the only fix was to restart.

It took three years from when the bug was introduced to when it was fixed in our system.

Concise Example

Here’s a minimal version of the prototype pollution code.

const countsByProperty = {}
const property = "__proto__"

const entry = countsByProperty[property] || { count: 0 }
// entry is equal to "Object.prototype".
entry.count += 1

// all future objects will have an inherited property of "count".
console.log("count" in {}) // true

Solutions

Removing the __proto__ attribute from objects in Javascript is the most robust solution.

Node

We can remove __proto__ via node --disable-proto=delete.

Deno

__proto__ is removed by default.

Browsers

There’s no solution to remove __proto__. Use Map instead of plain objects for hash maps.

Instead of an object:

const properties = ["__proto__", "name", "title"]
// plain object vulnerable to prototype pollution in browser.
const propertyCounts = {}
properties.forEach((property) => {
  if (!(property in propertyCounts)) {
    propertyCounts[property] = { count: 0 }
  }
  // vulnerable to prototype pollution.
  propertyCounts[property].count += 1
})

Use a Map:

const properties = ["__proto__", "name", "title"]
// Map() is safe to use with user-provided keys.
const propertyCounts = new Map()
properties.forEach((property) => {
  if (!propertyCounts.has(property)) {
    propertyCounts.set(property, { count: 0 })
  }
  propertyCounts.get(property).count += 1
})

Fast Image Resizing

2024-03-17T00:00:00+00:00

On Recipeyak, we resize user-uploaded images to improve page performance (see “Image Optimization”).

We use Twicpic because the free tier is large, but I was curious how fast Twicpic was compared to the gold standard, Imgix.

resizing HTTP APIs

Twicpic and Imgix provide image resizing HTTP APIs. The first request for an image will trigger the service to resize and cache the image. The following requests will pull from the CDN.

In this comparison, Imgix took 1.5 seconds to resize an image, while TwicPics took 2.1 seconds.

The follow up requests from the CDN are significantly faster.

Imgix

https://recipeyak.imgix.net/IMG_9631.HEIC?w=100&h=100

trial	duration (seconds)
1	1.47
2	0.14 (cached)
3	0.11 (cached)
4	0.10 (cached)
5	0.08 (cached)

Twicpic

https://recipeyak-images.twic.pics/IMG_9631.HEIC?twic=v1/contain=100x100

trial	duration (seconds)
1	2.09
2	0.14 (cached)
3	0.08 (cached)
4	0.09 (cached)
5	0.07 (cached)

resizing CLIs

We can resize images ourselves with libaries like ImageMagick, sips, and libvips.

ImageMagick

convert -define jpeg:size=100x100 IMG_9631.HEIC -auto-orient \
 -thumbnail 100x100 imagemagick.jpeg

trial	duration (seconds)
1	0.46
2	0.28
3	0.30
4	0.28
5	0.27

sips

sips --resampleWidth 100 IMG_9631.HEIC --out sip.heic

trial	duration (seconds)
1	0.38
2	0.35
3	0.36
4	0.34
5	0.36

libvips

vipsthumbnail IMG_9631.HEIC --size 100x100

trial	duration (seconds)
1	0.10
2	0.10
3	0.10
4	0.10
5	0.10

Conclusion

Twicpic is slow, but Imgix isn’t much better. I think generating thumbnails ahead of time would deliver the best user experience.

Image Optimization

2024-02-10T00:00:00+00:00

On Recipeyak, users upload images for recipes and we display them throughout the app.

For pages with many images, we don’t want to show full size images if they only display at 200 pixels wide. Browsers are slow to render many large images.

The solution is to use smaller images.

Generating smaller images

We could resize our images into a set of predefined sizes. But we’d need to figure out those sizes ahead of time. Also, if we need other sizes in the future, we’d need to backfill older uploads.

A simpler solution is to use an on demand image optimization service, like Imgix.

With Imgix, we can request any image size we want at request time via a query parameter. So if we wanted our image to be 100x100px, we can rewrite our URL with this query parameter:

https://example.com/image_4032.jpeg?h=100&w=100

This works great for all the various image sizes we display throughout the app.

size (px)	page
25x25	calendar
40x40	nav search
48x48	home (schedule, recently viewed, recently added)
60x60	schedule modal
100x100	comment image thumbnail
244x180	list recipes
620x413	recipe
~1200x900	gallery (full page image)
1200x910	Open Graph

In reality we only use a few image sizes in the app, but Imgix makes it easy to experiment and add new variants.

1200 pixels wide
200 pixels wide
1200x910 pixels

Improving caching

Imgix takes a noticeable amount of time to generate an image variant. With their caching this is less of an issue, but I’ve found the cache expires too quickly. So I placed Bunny.net in front and enabled PermaCache, to ensure that image variants are cached forever.

Finding a cheap solution

Imgix has excellent docs and works well, but the free tier has a relatively small limit of 1000 source images.

For Recipeyak we have over 1,200 images now and recently hit this free tier limit. With the basic plan of $75/month way outside our cheap budget for Recipeyak, we needed an alternative.

Imagekit.io was the first contender. With drop-in support for Imgix’s API and a generous free tier, it worked great. Until we uploaded a JPEG 2000 (.jp2) image, which Imagekit doesn’t support.

Now we’re using Twicpic, which doesn’t have as nice of an API as Imgix, but has a decent free tier and supports all of our image formats.

Image compression in messaging apps

2023-09-26T00:00:00+00:00

Images sent over messaging apps are compressed before being delivered. This makes messages faster to send, but comes at a cost of visual fidelity.

Images

iMessage has the highest image quality, with HEIF encoding at size similar to Discord’s JPEG encoding.

One caveat with iMessage is that if you share a 48MP RAW image, iMessage will downsize the image to 12MP before sharing.

	Original	iMessage	Discord	WhatsApp (HD)	WhatsApp	Signal	Instagram
Resolution (MP)	12	12	12	12	2	2	1
Encoding	HEIF	HEIF	JPEG	JPEG	JPEG	JPEG	JPEG
Size (MB)	2.4	2.4	6	1.9	0.4	0.7	0.5

Videos

iMessage has the highest video quality, using HEVC encoding at 720p video, but the framerate is dropped to 30fps. Any panning shot becomes noticeably choppy with the loss of framerate.

Videos shared via WhatsApp and Instagram are almost unusable because of the compression.

	Original	iMessage	Discord	WhatsApp (HD)	WhatsApp	Signal	Instagram
Resolution (height)	2160	720	360	720	480	360	360
Framerate (fps)	60	30	60	60	60	59.86	29.77
Encoding	HEVC	HEVC	H.264	H.264	H.264	H.264	H.264
Size (MB)	52.9	2.3	3.8	2.7	1.4	3.8	0.6

Conclusion

If you care about image or video quality, don’t use messaging apps for sharing. Use methods that preserve full quality, like AirDrop or an iCloud Link.

Disable commits to the main branch

2023-04-30T00:00:00+00:00

I unintentionally create commits on my main branch all the time. When this happens, I need to undo my changes, or delete my local main branch and checkout a fresh copy from origin.

With a Git hook, we can prevent commits being made to the main branch.

I found an example of this on Stack Overflow, which works, but I wanted a solution that I could configure with multiple branch names.

I wrote the pre-commit hook in Python, which I find easier to work with than Bash.

Use the following steps:

mkdir ~/.git-hooks
git config --global core.hooksPath ~/.git-hooks/
touch ~/.git-hooks/pre-commit
chmod +x ~/.git-hooks/pre-commit
# copy the following python code into ~/.git-hooks/pre-commit

#!/usr/bin/env python3

import subprocess
import sys
import os

PROTECTED_BRANCHES = ("master", "main")
DISABLE_KEY_PATH = "protected-main.disabled"

def main():
    disabled = bool(
        subprocess.run(
            ["git", "config", "--get", DISABLE_KEY_PATH],
            capture_output=True,
        )
        .stdout.decode()
        .strip()
    )
    if disabled:
        return
    branch = (
        subprocess.run(
            ["git", "rev-parse", "--abbrev-ref", "HEAD"],
            capture_output=True,
            check=True,
        )
        .stdout.decode()
        .strip()
    )
    if branch in PROTECTED_BRANCHES:
        print(f"You can't commit directly to the {branch!r} branch", file=sys.stderr)
        print(f"Disable with `git config --add {DISABLE_KEY_PATH} 1 ", file=sys.stderr)
        exit(1)


if __name__ == "__main__":
    main()

Christopher Dignam

Firebase Storage vs Cloud Storage Latency

Comparison

Conclusion

Feedly API Tokens

Browser Dev Tools

OAuth Applications

Apple Keychain

Charles Proxy

Improving Git Repository Performance

Conclusion

FNM (Fast Node Manager)

Shell Integration

Performance

Conclusion

How to generate a Firebase ID Token

Generating an ID Token

Create a Custom Token

Exchanging a Custom Token for ID Token

Calling an Authenticated Firebase Function

Prototype Pollution in Javascript

Prototype pollution

Suspicious Code

Concise Example

Solutions

Node

Deno

Browsers

Fast Image Resizing

resizing HTTP APIs

Imgix

Twicpic

resizing CLIs

ImageMagick

sips

libvips

Conclusion

Links

Image Optimization

Generating smaller images

Improving caching

Finding a cheap solution

Image compression in messaging apps

Images

Videos

Conclusion

Disable commits to the main branch