Maybe if half the sites on the web start using it, browsers can finally be convinced that it would be OK to add SQLite to the base platform.
WASM SQLite is the correct solution. It’s extendable by the developer using it, they can uses SQLite extension modules, and build their own.
But almost more so it proves the idea of a WASM db engine backed by a low level block FS api. We will see other db engines uses this architecture. DuckDB have already done it. I’m sure MongoDBs Realm and CouchBase Mobile will do the same soon too.
We are in for an exciting time in the next few years.
Why not? Web SQL would not be different from WebGL/GLSL or even JavaScript itself in that respect. Developers use feature detection and and work to the lowest supported version. APIs and languages can evolve, but in (mostly) backwards compatible ways. Extension and versioning mechanisms can be made. That's how the web works and Web SQL could have worked that way too.
More broadly, you could apply arguments like this against everything in the entire web platform. Maybe everything should be a WASM module that developers could choose themselves! Image loading, video decoding, font rendering, DOM, JS engine, why not? It's actually a beautiful vision and I'd be all for it if not for cache partitioning. Every site would have to re-download and re-JIT an entire browser engine before it could do anything.
The base platform needs to include a diverse set of commonly used features so that apps don't have to download the world, and on a list of ubiquitous libraries SQLite is right up there with other libraries backing the web platform, like zlib.
WebGL/GLSL give the developer a low level api to the graphics hardware.
Video decoding apis talk to the hardware video decoding hardware.
OPFS gives developers a low level API to the persistent file system / HDD / SSD.
To clarify, Apple made a proposal[0] which got no real traction. It has migrated[1] to a Javascript API[2]
[0] https://github.com/WebKit/explainers/tree/main/model
The enemy of progress is perfect.
> I’m supposing that the problem is that the web browser is the universal platform for all applications
This is a feature not a problem.
> There’s a benefit for information consumption (web pages) being separate from functionality rich and infinitely fingerprintable “native capabilities”
What exactly is that benefit supposed to be? If you want a read-only publishing platform, put PDFs on a FTP site.
Isn't this like a revival of the dreadful era of browser plug-ins from Adobe Flash Player to Java applets?
The issue with flash and applets was not that you had to download stuff.
It was that the security was non-existent (leading to the embedded runtime routinely crashing your browser), the interactivity was divergent from its surroundings, and the accessibility model was MIA.
Also downloading 500K over 56k and over fiber or 5G are rather different propositions.
If we had block API and SQL (it could be just a concrete version running from WASM itself, to not bloat browser itself) it could save a lot on app size. App then could look at browser version and decide to use that or to download newest one to run.
Not only that, but WebSQL disables a lot of mundane functionality, like the instr() SQL function and it's impossible to VACUUM because WebSQL requires explicit transactions and VACUUM cannot run in a transaction. i had the "pleasure" of having to work with WebSQL over the past couple of months for purposes of comparing its performance to the new sqlite features, and IMO, WebSQL is, as the kids say today, _weak sauce_. Its API is far too limited.
All of a sudden you have multiple slightly different instances running just because there isn't a standard.
I don't really see the problem with that. Looking at the sql.js demo[1] the WASM binary is 610K (305K compressed/transferred), and it seems to run pretty fast even on my slow laptop.
> Maybe if half the sites on the web start using it
Most websites have no reason to use it; simple key/value localStorage is enough for many sites or apps that need some sort of storage. It's kind of a niche thing. Many regular desktop applications have no need SQLite, either.
Please do not put words in quotes as if I said them when, in fact, I did not. Thank you.
...and that is small by your standards ?
In case you hadn't noticed it, the new sqlite features include using localStorage and sessionStorage as db backend storage :).
It can be done, and needs to be - and more securely than the half-assed efforts of the likes of NPM and Maven.
All dependencies signed - let's encrypt has made this a viable option.
I don't see how there's anything approximating an unresolvable privacy concern here.
Sharing a cache between websites has proven to be a privacy issue.
Read more here: https://developer.chrome.com/en/blog/http-cache-partitioning...
or here: https://www.peakhour.io/blog/cache-partitioning-firefox-chro...
> This means if you visited a website and it loaded the resource:
> https://www.somesite.com/foo.js
> and you then visited a second website, and it also included the same resource, then the resource would be loaded from the shared cache rather than being downloaded from the internet a second time. Cookies set by these resources would also be shared.
The privacy problem is not a result of the shared dependency, it's a result of the shared cookies.
Yes, if you share the execution space between multiple programs running the same lib, there's a privacy concern.
No shit - don't fucking do that.
No, it's not the result of the shared cookies. You just ignored all of the timing attacks and fingerprinting which a shared cache allows, as those articles discuss.
The cookie thing is honestly completely irrelevant to the topic of privacy, if you understand how the shared cache used to work. If you loaded the same library from separate CDNs on different websites, the shared cache didn't come into play at all. The library was loaded twice anyways. There was no chance for cookies from different CDNs to accidentally cross the streams. Browsers weren't attempting to heuristically determine if you were trying to load the same asset from different hosts.
The shared cache only came into play if you loaded the same asset from the same third-party CDN on multiple websites. The host serving an asset is the one responsible for setting the cookies, and sharing the cookies is helpful in that case, since the same CDN is the host serving the asset to the browser for both websites. These aren't cookies controlled by separate websites, they're cookies supplied by the CDN, and they should be the same for both requests anyways, outside of maybe some remote possibility of a theoretical attack involving a malicious CDN intentionally setting some weird request-dependent cookies, but I can't see how that would even do anything harmful anyways. So, the cookies get shared because the browser is serving a cached response for the same asset from the same host to both sites, which makes sense.
So, cookies aren't the problem here, and they're not the reason the shared cache was partitioned. If you want browsers to undo that in any form, you would have to solve the actual privacy problems here.
If I make a request for a given dependency, and am allowed to so much as time how long it takes to resolve, I can detect if it was already there and there's an information leak.
Sure. At some point though, a malicious site's gonna end up making some very weird requests - obviously polling the cache.
You could specify the dependency set in a static context and limit the ability of a site to measure how long dependency resolution takes.
Is there still an information leak? Yes.
Do I think it should stand in the way of a functional internet? Not really.
We have a functional internet. I'm using it to communicate right now.
I think it is completely fair to say that privacy-respecting shared caches are not simple.
Some solutions can be imagined, but they come with weird trade-offs or they do nothing for majority of the web. A new manifest format like you describe falls into the latter, since it would only apply to new websites using the new feature, and that’s without digging into the other problems it would pose.
In practice, people often visit the same websites repeatedly; they aren't constantly visiting new websites only once. A partitioned cache works just fine for the normal scenario. It's slightly less efficient for the first day someone uses their browser, but then things are honestly fine after that. It's unfortunate that we can't eek out the last tiny bit of performance for this, but I think the difference would be hard to measure in practice.
In my opinion, if websites would more commonly use brotli, that would make a far larger difference in efficiency than returning to a shared cache, and if browsers could have a standardized means of downloading only the bytes that changed in an asset like a javascript library instead of downloading the new version from scratch, that would make a much bigger difference too.
Couldn’t they make an exception for some domains and create a registry of really popular or fundamental links to packages like jquery et al? I have read on this topic before, but it sounded like all or nothing no shades of grey maximalism. Fine, partition those memes from imgur cdns, but let common libraries with known hashes to be shared at least. The potential attack is based on leaving a cdn-pixel and dl-time-testing it on other sites. But there is no big data in who has the 10 most popular releases of wasm-sqlite, dayjs or bootstap.min.css in their cache. These could be warmed up from literally anywhere, or even synced in background by an idle browser thread.