In other words, when some changes were published after the release, .get({ verifySignature: true }) will throw because it fetches a signature that does not match the packaged default data.

When calling .get({ verifySignature: true }) on a fresh profile, for a collection that packages initial data (aka. JSON dumps), only the metadata is pulled from the server after loading it.
The fact that we only fetch metadata is not documented.
Why we need to verify signature on dump data is not documented either. Is omni.jar safe?

That exact call is missing cache busting queryparams, so it just does a simple GET /v1/buckets/{this.bucketName}/collections/{this.collectionName}.

We could add the cache busting queryparams, using the ?_expected={dump-timestamp} and hope clients will fetch the right one. But it would imply that the CDN is able to retain cached data as long as ESR support.

Instead of just fetching metadata and failing we could:

a. Package collection metadata along data. AFAIU it does not expire (if x5u remains online during ESR).

b. Run a full sync to fetch both latest metadata and associated recent changes.
It would only make first startup slower on .get() if many changes were published since the packaged release.

c. Leave as is. Let caller handle invalid signature error in that context. Consumers can choose to sync manually or fallback to hard-coded values until background sync happens. Documentation improvement and cache busting wouldn't hurt.

Mark, what behavior would you expect for search config?
In your use-case, I'm pretty sure that fetching metadata is as slow as fetching metadata+recent changes. I'm tempted to go for solution b).

Sorry Rob, I NI'd you because I wanted to know about the work you mentioned once to have omni.jar signed, but actually I changed my mind because I don't think it matters too much here, we could verify the signature of packaged data anyway...

Ok, let me try to give the steps:

1. Release dump is packaged at version X
2. A week later, an update to the collection is published, records and metadata are at version X+1 on the server
3. Browser starts with a fresh profile. Records dump is loaded, signature verification is skipped for this time.
4. Another call to .get({verificySignature: true}) is made, local DB has records but metadata are still missing, we fetch them to verify the signature. 5. Pulled signature is at version X+1 and local DB is at version X (packaged records dump). Signature verification will fail.

My suggestion would be to go with b. at step 4. Synchronize the collection instead of just fetching the missing metadata, so that local DB (records + metadata) will both at version X+1

I would agree that b) is a reasonable step. The code for some of the search items already does c) though that loads the local dump again - so I think avoiding having to wipe the database and re-get everything would be better.

https://hg.mozilla.org/mozilla-central/rev/91b88781a337