DEV Community: withuse

I shipped Chrome extensions with an empty permissions list. Here is what that costs you.

withuse — Sat, 10 Oct 2026 15:48:43 +0000

Every Chrome extension I install asks for something. Read and change all your data on all websites, usually. So when I built five small developer utilities as extensions, I wanted to know how far I could get with the permissions array empty.

All five shipped with this:

{
  "manifest_version": 3,
  "name": "Base64 Encoder & Decoder",
  "version": "1.0.0",
  "description": "...",
  "icons": { "16": "...", "48": "...", "128": "..." },
  "action": { "default_popup": "popup.html", "default_title": "..." },
  "homepage_url": "https://base64.withuse.io"
}

That is the whole manifest. No permissions. No host_permissions. No content_scripts. No background. Not an empty array — the keys are absent.

What you actually give up

Three things, and they are the three that most tutorials reach for reflexively.

No access to the current page. Without activeTab or a host permission you cannot read the selected text, the URL, or anything in the DOM. For a tool that encodes text the user types into your own popup, that turns out not to matter. For "encode whatever I highlighted", it does — that is a real feature you are declining.

No storage. No chrome.storage, so nothing survives closing the popup. No history, no remembered settings. I replaced the usual "last 10 results" list with nothing and have not missed it; the work in these tools is a single transformation, not a session. localStorage is still available inside the popup's own origin if you want per-install state without declaring the permission — worth knowing, though I did not use it.

No clipboard permission. You do not need one. navigator.clipboard.writeText() works from a user gesture inside the popup without clipboardWrite in MV3. This is the one that surprised me; a lot of extension code still declares it.

What you keep

More than I expected. The popup is a normal web page with a normal origin, so Web Crypto, TextEncoder, Intl, and the whole DOM API are there. Every one of these tools is a pure function over text:

UUID generation — crypto.getRandomValues, RFC 9562 layout, no network
Base64 — TextEncoder plus btoa, with the padding rules handled locally
JSON formatting and duplicate-key detection — a scan over the raw source text
JWT decoding — three base64url segments, split and decoded in place
cron parsing — field expansion and arithmetic

None of them has a reason to touch the page you are on, and none has a reason to make a request. I grepped the five source trees for fetch, XMLHttpRequest and any CDN-shaped import: zero hits. The token you paste into the JWT decoder cannot leave your machine, because there is no code in the bundle that could send it.

The dependency decision that follows from this

I did not bundle anything from npm. The UUID logic, the base64 helpers, the cron parser — all hand-written, totalling a few hundred lines across the five.

That is not about bundle size, though the zips do come out around 16 KB each. It is that the source a reviewer reads is the source that ships. A build step that pulls a transitive dependency tree breaks that property, and an extension is exactly the place where it matters: it runs with whatever permissions you declared, in the browser, forever, updated silently.

The cost is real. I reimplemented UUID v7 and got the same-millisecond ordering wrong on the first pass, which a mature library would have had right. I caught it with a test, but only because I went looking. A dependency would have saved me that bug and cost me the review property. For five files of pure logic I took that trade; for anything with a protocol or a parser of real complexity I would not.

What the store does with it

Two observations from actually submitting these.

The review was fast — both published within a day. I have no way to know whether the empty permissions list is why, and I would not claim it. But a reviewer's job is easier when there is nothing to assess.

The thing that actually blocked me was unrelated and badly documented: a new developer account can have only two extensions published at a time. Not two per day — two total, until you request an increase from the dashboard. I had five packaged and found this out by hitting it. The error that surfaced first was a generic file-upload failure whose only useful detail was a line about enabling 2-Step Verification, which is a separate prerequisite. Searching for the limit turned up very little, so: two, total, request an increase in the developer dashboard.

Worth trying before you declare anything

Write the manifest with no permissions first and add them one at a time as something actually breaks. I expected to need three and needed none.

The exercise is cheap and it tells you something about the tool. If nothing breaks, your extension never needed access to the user's pages — and the install prompt that says so is the most honest thing in the listing.

Two of the five are on the store so far; the two-at-a-time limit above is exactly why. The UUID one is here.

Correction, 12 Oct 2026: this sentence originally said all five were on the store. Two are. The limit described in the section above is the reason, and the original wording contradicted it.

I measured whether .NET Guid sorting is broken. It isn't.

withuse — Thu, 08 Oct 2026 02:12:52 +0000

"Guid sorting in .NET is weird" is a claim you run into often enough that I wanted a number for it. So I measured CompareTo directly.

It sorts in logical value order. The claim is wrong, and the thing people are actually hitting is something else.

You need a sample that can tell the two hypotheses apart

This is the part that took me two attempts. .NET stores the first three groups of a Guid in little-endian internally, so to distinguish "sorts by string order" from "sorts by raw byte order" you need values where those two orders disagree. Most hand-written samples do not.

value                                   ToByteArray() first 4 bytes
00000100-0000-0000-0000-000000000000    00-01-00-00
00000001-0000-0000-0000-000000000000    01-00-00-00
01000000-0000-0000-0000-000000000000    00-00-00-01
00010000-0000-0000-0000-000000000000    00-00-01-00

Sorted by string, those come out in one order. Sorted by raw bytes, exactly the reverse. Now the test means something.

Result

CompareTo order == string order       True
CompareTo order == raw byte order     False
sample distinguishes the hypotheses   True

That third line matters as much as the other two. Without it you cannot tell a passing test from a test that could not have failed.

So Guid.CompareTo is independent of the ToByteArray() layout. The folk claim conflates the comparer with the byte layout.

The real trap is the byte layout

ToByteArray() does not return RFC 9562 network byte order. The first three groups come back reversed:

Guid        00112233-4455-6677-8899-aabbccddeeff

default     33-22-11-00-55-44-77-66-88-99-AA-BB-CC-DD-EE-FF
bigEndian   00-11-22-33-44-55-66-77-88-99-AA-BB-CC-DD-EE-FF

Look at the first four bytes. 33-22-11-00 against 00-11-22-33. Groups one, two and three are byte-swapped; the last two groups are not.

Since .NET 8 you can ask for RFC order explicitly with ToByteArray(bigEndian: true).

Where it actually bites

Python gives you both and names them: .bytes is RFC order, .bytes_le is the .NET default layout
SQL Server's uniqueidentifier comparison uses yet another order, which is where most of the "sorting is weird" stories actually come from
Anywhere you write a Guid to bytes and read it back with a different library

So

Sorting is not broken. The layout differs when you serialise. It only matters when a value crosses a system boundary, and at that boundary you can just say which order you want.

Verified

.NET 10.0.400, run 2026-10-08. An earlier run on 2026-09-14 gave identical results on .NET 10.0.11.

Full write-up, including the Python and SQL Server side: https://uuid.withuse.io/uuid-vs-guid/

atob() does not require padding. It rejects half-padding.

withuse — Tue, 06 Oct 2026 05:09:28 +0000

A common claim about Base64 in the browser is that the input length must be a multiple of 4. It isn't. atob decodes unpadded input fine. What it rejects is something else.

Here are all five cases, run:

"YQ=="     len % 4 = 0   ->  "a"
"YQ"       len % 4 = 2   ->  "a"        <- no padding, still decodes
"YWJjZGU"  len % 4 = 3   ->  "abcde"    <- decodes
"YWJjZ"    len % 4 = 1   ->  throws
"YQ="      len % 4 = 3   ->  throws     <- half-padded

So the rule has nothing to do with multiples of 4.

Remainder 2 or 3 decodes without padding. The leftover bits are enough to reconstruct the bytes.
Remainder 1 always fails. Six bits cannot encode a byte, so an encoder can never produce that length in the first place.
If you pad, pad fully. "YQ=" is rejected even though its length mod 4 is 3 — the same remainder as "YWJjZGU", which passes.

The actual contract of atob is "pad correctly, or do not pad at all", not "length must be a multiple of 4".

Where this bites

The rule is not the same across languages. Same input, "YQ":

JavaScript   atob("YQ")                             ->  "a"
Python       base64.b64decode("YQ")                 ->  binascii.Error: Incorrect padding
Go           base64.StdEncoding.DecodeString("YQ")  ->  illegal base64 data at input byte 0

JavaScript is the lenient one and Go is the strictest. A value that round-trips fine in the browser and is then handed to a Python or Go service is a common way to get an error that looks like it came from nowhere — the data was never wrong, the two decoders just disagree about what counts as well-formed.

If you generate Base64 in the browser and consume it elsewhere, normalize the padding before it crosses the boundary, not after.

Verified

Node v23.7.0, Python 3, Go 1.22.0, run on 2026-09-14. The longer write-up — including Go's four encodings, and why picking the wrong one can pass every test and still break in production on one payload — is here: https://base64.withuse.io/base64-in-go/