Web SQL Database: In Memoriam (2014) | Hacker News Reader

Web SQL Database: In Memoriam (2014)

nolanlawson.com

37 pointsmucholove20 comments

I really don't get why Mozilla argued that they would have to re-implement SQLite for WebSQL, but then used SQLite for IndexedDB. Why were they so opposed to using SQLite for WebSQL?

They were opposed to having a web standard, which should be a generic standard, be implementation defined. Mozilla would have had to re-implement SQLite for WebSQL based on the principle that there should not be a standard with only a single implementation.

There's nothing wrong with implementing the actual standard IndexedDB on top of SQLite, since it's entirely possible to reimplement IndexedDB on top of a different underlying database.

WebSQL would have been awesome right up until the moment that some new platform takes off where SQLite won't meet the requirements for but we want to reach with the web platform, at which point we'd be screwed. Or even worse, WebSQL would guarentee that the reach of the web platform has been fundamentally limited by what a single codebase can reach.

Wouldn't it have been simple/easy to define a facade in front of sqlite as the standard?

Like some basic SQL select/insert/update/create table/drop table syntax and semantics? In a way such that advanced/specific features are not available in order to not be relied on and then let all browsers just use sqlite as implementation detail?

How much of a facade would you have had to build to be useful to the point where you run into the same problem? It seems like it would be very very easy for implementation specific behavior to leak this way.

At least with IndexedDB there's a large enough impedence between SQLite and IndexedDB that there's far less chance of details getting through.

> where SQLite won't meet the requirements

What does SQLite not run on in 2021?

https://www.sqlite.org/mostdeployed.html

Standards don't ask where it doesn't run in 2021, standard ask where it doesn't run in 2030.

SQLite does not appear to prioritize malicious SQL CVEs. They surmise that an adversary that has already compromised an application to the extent of issuing arbitrary SQL must have many other avenues of control.

https://www.sqlite.org/cves.html

While SQLite earned DO-178B compliance status through a difficult test suite that appears to verify every branch instruction at the assembler/machine level, focus on hostile SQL is demonstrably not a priority.

https://sqlite.org/th3.html#history

Web applications are going to see hostile SQL, so this is a problem. I know that additional sandboxing was implemented in Chrome, but exploits always seem to find ways around.

A new implementation of SQLite, in Rust or Ada, that could spend more time on the safety of the parser because the various C foot-guns are removed, might have brought WebSQL to be, but that was a bridge too far.

When I hear of multiple CVEs described without details (or categorization), the phrase "Security Theatre" comes to mind.

Apparently, there is no formal oversight over how CVEs are reported or assigned severity. But because the label sounds official & authoritative & scary, people who spam CVEs are rewarded with clout.

Some have speculated that CVE inflation will lead to the death of the term altogether:

https://news.ycombinator.com/item?id=25612429

The CVEs are detailed, broadly in the parents comment (malicious / injected SQL) and more specifically in the links provided.

There is specific commentary on the SQLite CVE page that addresses WebSQL, which you might find enlightening:

"A few applications do allow untrusted SQL scripts received from potentially hostile agents to be run direct in SQLite. The main example of this is the Chrome and Safari web browsers, which allow an anonymous web page to run SQL using the WebSQL feature of Javascript. This is done inside a sandbox with tightly controlled constraints on resources, lest the SQL script try to soak up all available memory or CPU cycles in a denial-of-service attack. Chrome and Safari have the infrastructure in place to allow a hostile agent to run code which does not harm or compromise the rest of the machine. They have to, as they also run Javascript which could, if not tightly controlled, do even more damage than unrestrained SQL. Apart from Chrome and Safari, no applications known to the SQLite developers deliberately allows an anonymous remote agent to run arbitrary SQL text.

"However, most CVEs written against SQLite flippantly assume that an attacker is free to run any arbitrary SQL in the database engine. So to a good approximation, this means most CVEs written against SQLite really only apply to SQLite as it is used in Chrome and Safari. Or, in other words, most CVEs for SQLite do not apply to you unless you are one of the developers of Chrome or Safari."

Seeing as $1.5mil investment from Nvidia is all it took for Mozilla to kill its DeepSpeech program

https://venturebeat.com/2021/04/12/mozilla-winds-down-deepsp...

https://blog.mozilla.org/en/mozilla/mozilla-partners-with-nv...

someone should really look into any grants/investments/deals Mozilla did with Oracle at the time of WebSQL decision.

Once we have storage foundation[0] we can install "any" db in the browser. Of course the communication protocol would have to be tweaked a bit. Until then see absurd sql[1]

[0] https://web.dev/storage-foundation/

[1] https://hackaday.com/2021/08/24/sqlite-on-the-web-absurd-sql...

Thank you! This is exactly why I did this post—someone would illuminate me :) What are the chances `storage foundation` gets adopted by all the other browsers? Not sure how the origin trial ends up as a standard.

I would say the chances are high to be adopted as a standard by all the other browsers...unless you consider Safari(aka IE6) part of the other browsers.

It would be the biggest irony ever if the web settles on sql.js [1] plus persistance based on IndexedDB.

Then to comfortably store data, we would have SQLite running in WebAssembly persisting the data via the awkward IndexedDB API which uses the comfortable SQLite API to store the data in native SQLite.

[1] https://sql.js.org

Not ironic at all. One of the arguments against WebSQL and for IndexedDB was that the web platform should incorporate a lower level API and that the library ecosystem could then experiement with how to interact with that API at a higher level.

At the time (2010?), WebSQL was the only way to store more than 5MB of data on both android chrome and ios safari. (Used it slightly ridiculously for storing base64 photos when there was no data connection.) It was quite frustrating when it got deprecated, it felt like they were killing the only way to get close to parity with native apps. I refused to use firefox for about 5 years.

What is the developer experience these days with IndexedDB. I stopped working web development shortly after IndexedDB started getting implemented, and I know the early implementations had some rough edges, my understanding is that there was some effort to improve apis over the last 5 or 6 years. So I would be interested if someone with some experience could speak to it

Getting acquainted with Javascript and the web today. Really wish I had this. Would make life very, very, very easy. :)

Today you get ABSURD: https://news.ycombinator.com/item?id=28156831

https://github.com/WICG/indexed-db-observers/blob/gh-pages/E...

Give me that and we can forget about web sql.

Reply on news.ycombinator.com