Intent to Deprecate and Remove: WebSQL in non-secure contexts

[Ayu Ishii]

Contact emails
ay...@chromium.org, jsb...@chromium.org, ajayra...@google.com  

Specification
https://www.w3.org/TR/webdatabase/

Summary
We intend to deprecate and remove usage of WebSQL in non-secure contexts. Deprecation is targeted for M105 and removal is targeted for M107.

Blink component
Blink>Storage>WebSQL

Motivation
The Web SQL Database standard was first proposed in April 2009 and abandoned in November 2010. Gecko never implemented this feature and WebKit deprecated this feature in 2019. The W3C encouraged those needing web databases to adopt Web Storage or Indexed Database.

WebSQL has been deprecated and removed for third-party contexts in M97.

We hope to entirely deprecate and remove WebSQL at some future point when usage is low enough.

TAG review
N/A

Risks
Based on usage measurements rolled out in M97, 0.005% of page loads use WebSQL in a non-secure context.  Less than 0.01% of top sites have adopted this feature.

Out of the 20 top sites listed for the month of April 2022, 11 of the sites use a feature detection library Modernizr 1.5, on a version released in 2010. This would create a test database to check feature availability. I was unable to reproduce the creation of other WebSQL databases outside of the one created by Modernizr on these sites. 4 sites that seem to use an outdated private mode detection script which was intended for older versions of iOS. All the scripts I have found checked if window.openDatabase existed before usage, likely due to the lack of support in Gecko and WebKit. 

Interoperability and Compatibility

Gecko: Never implemented

WebKit: Deprecation shipped in iOS 13 and Safari 13  

Web developers: No signals

Debuggability
N/A

Is this feature fully tested by web-platform-tests?
Not fully, one test checks the availability of the feature.

Tracking bug
https://crbug.com/1212492

Link to related intents
Intent to Deprecate and Remove: WebSQL in third-party contexts

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5175124599767040

[Mike West]

I'm happy to see this moving forward, thanks for pushing it ahead!

That said, this seems like the kind of thing that's likely-enough to impact enterprise that we should include a temporary opt-out to give ourselves some wiggle room if it turns out that we're undercounting usage. Have y'all already put something like that together?

-mike

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bc5f407d-e6fe-4743-ae46-84541d271a92n%40chromium.org.

[Ayu Ishii]

Hi Mike!

With the current usage measurements we see, we hadn't considered any enterprise policy for opt-out.
But certainly can follow the process to do so if you feel that there may be risk of undercounting.

Deprecation of WebSQL in third-party contexts added a policy that lasted 3 milestones after deprecation before full removal as an example.

Although the usages were quite different from that deprecation, we can follow the same process if this sounds reasonable.

- Ayu

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Chris Harrelson]

On Tue, May 31, 2022 at 8:26 PM Ayu Ishii <ay...@chromium.org> wrote:

Hi Mike!

With the current usage measurements we see, we hadn't considered any enterprise policy for opt-out.
But certainly can follow the process to do so if you feel that there may be risk of undercounting.

Deprecation of WebSQL in third-party contexts added a policy that lasted 3 milestones after deprecation before full removal as an example.

Although the usages were quite different from that deprecation, we can follow the same process if this sounds reasonable.

I think this plan sounds good. LGTM1 once you have an enterprise opt-out in place that will remain for 3 milestones. Also please make sure to communicate this change in the enterprise notes and other communication channels.

 

- Ayu

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bc5f407d-e6fe-4743-ae46-84541d271a92n%40chromium.org.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aa706101-184b-4a25-a446-6643a96e062fn%40chromium.org.

[Mike Taylor]

On 6/1/22 1:34 PM, Chris Harrelson wrote:

On Tue, May 31, 2022 at 8:26 PM Ayu Ishii <ay...@chromium.org> wrote:

Hi Mike!

With the current usage measurements we see, we hadn't considered any enterprise policy for opt-out.
But certainly can follow the process to do so if you feel that there may be risk of undercounting.

Deprecation of WebSQL in third-party contexts added a policy that lasted 3 milestones after deprecation before full removal as an example.

Although the usages were quite different from that deprecation, we can follow the same process if this sounds reasonable.

I think this plan sounds good. LGTM1 once you have an enterprise opt-out in place that will remain for 3 milestones. Also please make sure to communicate this change in the enterprise notes and other communication channels.

A couple of notes I took last Friday and forgot to post:

I dumped the list of sites from HTTPArchive (query below) and after de-duping them, ended up with 835 sites.

I then ran a script which naively looks at response codes, and got the following results:

2XX count: 685/835
3XX to HTTP endpoint count: 74/835
4XX count: 3/835
5XX count: 2/835

So, from this dataset, roughly 9% of those redirect to an HTTP endpoint.

That said, I think reducing risk of breakage for enterprise environments is a useful and friendly thing to do. LGTM2 w/ that done.

SELECT
  rank,
  url,
FROM
  `httparchive.blink_features.features`
WHERE feature = 'OpenWebDatabaseInsecureContext'
ORDER BY rank ASC

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9xqv76X-fAQjvb4iiT%2Bx-GxUffO0H16AYMWDk91ma-hw%40mail.gmail.com.

[Yoav Weiss]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5a30e8f7-49cf-ab6e-9e36-d63fb0f139fa%40chromium.org.

[Mike Taylor]

On 6/1/22 3:52 PM, Yoav Weiss wrote:

LGTM3

On Wed, Jun 1, 2022 at 8:58 PM Mike Taylor <mike...@chromium.org> wrote:

On 6/1/22 1:34 PM, Chris Harrelson wrote:

On Tue, May 31, 2022 at 8:26 PM Ayu Ishii <ay...@chromium.org> wrote:

Hi Mike!

With the current usage measurements we see, we hadn't considered any enterprise policy for opt-out.
But certainly can follow the process to do so if you feel that there may be risk of undercounting.

Deprecation of WebSQL in third-party contexts added a policy that lasted 3 milestones after deprecation before full removal as an example.

Although the usages were quite different from that deprecation, we can follow the same process if this sounds reasonable.

I think this plan sounds good. LGTM1 once you have an enterprise opt-out in place that will remain for 3 milestones. Also please make sure to communicate this change in the enterprise notes and other communication channels.

A couple of notes I took last Friday and forgot to post:

I dumped the list of sites from HTTPArchive (query below) and after de-duping them, ended up with 835 sites.

I then ran a script which naively looks at response codes, and got the following results:

2XX count: 685/835
3XX to HTTP endpoint count: 74/835
4XX count: 3/835
5XX count: 2/835

So, from this dataset, roughly 9% of those redirect to an HTTP endpoint.

This should say HTTPS, not HTTP. I am bad at typing.

[Ayu Ishii]

Thank you all for the approvals!
And thank you miketaylr@ for the HTTPArchive analysis!

 

- Ayu

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bc5f407d-e6fe-4743-ae46-84541d271a92n%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aa706101-184b-4a25-a446-6643a96e062fn%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9xqv76X-fAQjvb4iiT%2Bx-GxUffO0H16AYMWDk91ma-hw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Ayu Ishii]

We've done some extra communications with enterprise partners and have come up with a new target milestone.
The new target milestone for this removal is M110, with enterprise policy available for 2 milestones (M110-111).

Thanks!

Ayu

[Thomas Steiner]

The developer-facing documentation is being updated in https://github.com/GoogleChrome/developer.chrome.com/pull/4299.

 

- Ayu

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bc5f407d-e6fe-4743-ae46-84541d271a92n%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aa706101-184b-4a25-a446-6643a96e062fn%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9xqv76X-fAQjvb4iiT%2Bx-GxUffO0H16AYMWDk91ma-hw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5a30e8f7-49cf-ab6e-9e36-d63fb0f139fa%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/049f32e7-9d79-4cfc-8f91-5f7c9649bd3bn%40chromium.org.

--

Thomas Steiner, PhD—Developer Relations Engineer (https://blog.tomayac.com, https://twitter.com/tomayac)

Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
Geschäftsführer: Paul Manicle, Liana Sebastian
Registergericht und -nummer: Hamburg, HRB 86891

----- BEGIN PGP SIGNATURE -----

Version: GnuPG v2.3.4 (GNU/Linux)

iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.hTtPs://xKcd.cOm/1181/

----- END PGP SIGNATURE -----

[Ben Morss]

I've done a more thorough search for examples of webkitStorageInfo and of WebSQL in insecure contexts on the web. Among the top 10K sites, the only usage I found was from standard libraries - and, in these cases, removal wouldn't cause an error or affect any functionality.

No one in Enterprise at Google, Microsoft, or Salesforce has uncovered usage among their partners either.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALgRrLmvGVvzbS%3D0F9PYEBfGEvm1SX%3DfyugwxMrMWOb2MCLfaA%40mail.gmail.com.

[Ben Morss]

Yes. Carl, does your app depend on Web SQL, webkitStorageInfo, or something else?

On Thu, Dec 8, 2022 at 6:55 PM Carl Turechek <carltu...@gmail.com> wrote:

You'll break an app I developed to be passed around as a single html file. Hope you'll provide us plebs some guidance on finding a replacement solution.

[Chris Thompson]

I'll note that file:// URLs are considered secure contexts, which may be relevant for single-html-file apps -- see https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts#when_is_a_context_considered_secure

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA6%2Bj4tBDyfRwhwi%2Btp-pAk6Vr%2Bg9ivKCHnDCtJVk%3DQuiq%3DGtg%40mail.gmail.com.

[Carl Turechek]

Hi,

Thanks for taking it into account. In a nutshell, my app is a C.R.U.D. that exports all of the data as json into a new html file along with everything else required to search through the information. It is a catalogue resonee where it could be downloaded and searched by anyone using a chrome browser. So you could search for a timeframe or keyword... and see a list and view images etc.. Also, privacy is an aspect.

It sounds like web assembly would not make this possible without fetching stuff or including more files. Maybe websql could be optional or something.. Anyway, thanks for the question! Have a good one :)

[Carl Turechek]

I don't think that the increased security will have an effect on my app, but the removal all together is my concern. Sorry if I haven't been clear enough.

On Thursday, December 8, 2022 at 7:28:58 PM UTC-5 mo...@google.com wrote:

[Carl Turechek]

You'll break an app I developed to be passed around as a single html file. Hope you'll provide us plebs some guidance on finding a replacement solution.

On Wednesday, November 16, 2022 at 1:22:34 PM UTC-5 mo...@google.com wrote:

[Carl Turechek]

I'd rather websql wasn't removed. I use it for a few non-web applications making it possible to have a one click app with a database without too much hassle. Having to roll your own with web assembly sounds like it wouldn't be worth the trouble.

[PhistucK]

Note that file:// storage is quite fragile, I believe it is keyed by either the file path or the folder path, so moving the downloaded file will effectively replace/clear the storage...

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7f5ce439-914f-4aa0-8a2a-776a08addd1dn%40chromium.org.

[Ben Morss]

Hi Carl,

I'm sorry we can't keep Web SQL going any further in its present form. As you know, it's been deprecated for years and only Chromium still supports it. It sees little use; almost any site that wants sophisticated storage wants it to work on all browsers, and so people build things on top of indexedDB. Despite the relatively small usage, it takes us time to keep up with updates, and security problems demand our attention rather frequently. We don't have enough engineers to merit keeping it going.

On the other hand, we're quite excited about the new SQLite-over-Wasm, and some developers of other databases have told us they're interested in following this example. After years in which browser vendors tried to create sophisticated storage solutions, often without success, the possibility that databases that are available on other platforms might become available on the web, created and supported by the developer community, is quite exciting.

Sorry that doesn't help with your HTML-file application :-/ If you're curious, it is possible to embed Wasm in an HTML page:

• https://stackoverflow.com/questions/52582367/a-single-file-webassembly-html-demo
  
• https://gist.github.com/dio/ae79cf546e808a9bc46515bf9400ad5d
  

Of course, this isn't as simple or as small as simply using Web SQL, but it miiiiiight work?

All best,

Ben

[Michal Šimonfy]

Hello there! 

will WebSQL continue to be available in Chrome extensions (through the chrome-extension:// scheme)?

Thank you!

All the best, 

Michal

[Ben Morss]

Our plan is to remove support entirely.

It's good to hear from developers who have been using Web SQL - since the vast majority of uses we've found on the web emanate from standard libraries using it for browser sniffing or as a backup for basic key-value storage. If you're using it, and migration to SQLite-over-Wasm looks hard for you, I'd like to hear more about your use case. It's always difficult when a feature you rely on gets removed - but we want to make this as easy on everyone as possible.

[Michal Šimonfy]

Hi Ben, thank you for your answer!

I figured that the plan is to phase out support entirely, I was just wondering whether deprecating and removing WebSQL "in non-secure contexts" is going to affect chrome extensions (I assume it is not). Is there a specific timeline for removing WebSQL from the extensions and "secure contexts"?

I'm using WebSQL for a legacy reasons, I created my extension when WebSQL was a new thing in Chrome and I liked the fact that I was able to use a relational database. I was hesitant to stop using it because it was working well for my use case and seemed to be reliable for all these years. I'll have to explore all the available options and SQLite-over-Wasm looks great, although I might just try to migrate to chrome.storage or IndexedDB.

Best,

Michal

[Ben Morss]

HI Michal,

We don't yet have a date for removing WebSQL everywhere. We need to finish looking for more examples of current nontrivial usage. The best I can say is, in 2023, but not super early in 2023. You'll have plenty of notice!

Ben

[Thomas Steiner]

Hi all,

I realize we haven't announced the general availability of our Web SQL replacement on this list yet (apologies). It's an official port of SQLite to WebAssembly (Wasm) by the SQLite team, which is backed by the Origin Private File System (OPFS) for maximum performance. You can read all details, including a code sample and demo, in our blog post: https://developer.chrome.com/blog/sqlite-wasm-in-the-browser-backed-by-the-origin-private-file-system/.

Cheers,

Tom 

[Carl Turechek]

Referring to this example  https://developer.chrome.com/blog/deprecating-web-sql/   , promises might resolve the callback madness there. Do you really need actual transactions if it is in the browser though? Thanks again for the responses!  Peace

[Carl Turechek]

I'll probably just scrap it and ajax everything to that dusty old mysql thing. But I do appreciate the links! 

[Carl Turechek]

Are you sure that callback hell can't be avoided using js promises? If that is a major reason then hopefully you're right. I think it should remain in the desktop browsers at least, or as an option still. Thanks for the heads up on turning off updates lol

On Thursday, December 15, 2022 at 7:02:53 PM UTC-5 mo...@google.com wrote:

[Carl Turechek]

Going to all that trouble for a "replacement" that's not any better .. ok. Good luck finding anyone who'd actually use it.

[Randy Lauen]

Speaking of nontrivial examples, I have a Chrome extension that relies heavily on WebSQL. On my desktop, the WebSQL database for my extension is almost 400 MB. I know some users have a database over 1 GB. I'm very excited about using Wasm SQLite, since I can (hopefully) configure SQLite the way I want, instead of being stuck with the configuration used by Chrome.

What I'm not looking forward to, though, is the transition. Do you have any advice on migrating data from WebSQL to Wasm SQLite? My best guess so far is to have users use my extension's import/export mechanism to export all of their WebSQL data to a file and then import it back into Wasm SQLite.

Also, with WebSQL, I can locate the SQLite database on disk within Chrome's profile directory. Will that be possible with Wasm SQLite/OPFS?

Finally, between manifest v3 and WebSQL deprecation, my extension will need a lot of changes this year. If it's possible to stagger the deadlines for those, so I don't have to tackle both at the same time, then that gets my vote!

Thanks,

  Randy

[Thomas Steiner]

Hey Randy,

On Tue, Jan 31, 2023 at 10:51 PM Randy Lauen <randy...@gmail.com> wrote:

Speaking of nontrivial examples, I have a Chrome extension that relies heavily on WebSQL. On my desktop, the WebSQL database for my extension is almost 400 MB. I know some users have a database over 1 GB. I'm very excited about using Wasm SQLite, since I can (hopefully) configure SQLite the way I want, instead of being stuck with the configuration used by Chrome.

Very exciting. Do you mind sharing the name of the extension?

 

What I'm not looking forward to, though, is the transition. Do you have any advice on migrating data from WebSQL to Wasm SQLite? My best guess so far is to have users use my extension's import/export mechanism to export all of their WebSQL data to a file and then import it back into Wasm SQLite.

Asking users to manually export their database file from Web SQL via your extension's export feature and then importing to SQLite is probably the easiest way, yes.  

 

Also, with WebSQL, I can locate the SQLite database on disk within Chrome's profile directory. Will that be possible with Wasm SQLite/OPFS?

As a developer, you can use the OPFS Explorer extension (https://chrome.google.com/webstore/detail/opfs-explorer/acndjpgkpaclldomagafnognkcgjignd) to do so. 

 

Finally, between manifest v3 and WebSQL deprecation, my extension will need a lot of changes this year. If it's possible to stagger the deadlines for those, so I don't have to tackle both at the same time, then that gets my vote!

The manifest v3 deadline is unrelated to this deprecation deadline. You can express your concerns about the extensions deadline on their forum: https://groups.google.com/a/chromium.org/g/chromium-extensions. 

Cheers,

Tom

[Carl Turechek]

One more question is whether that will work on all browsers.. that could at least be considered as an improvement. Also, I'm subbed to this convo and haven't seen any notifications anywhere... Is it supposed to email me?

[Carl Turechek]

I think I'll pass on all that extra technical debt myself, already transferred over a million records to mysql after a few hours and am now sleeping soundly :) Good luck to the rest of the folks that come in late ... will the data be recoverable after the update?

On Wednesday, February 1, 2023 at 6:50:35 AM UTC-5 tste...@google.com wrote:

[Ben Morss]

Carl, the signs are promising for other browsers to implement all the APIs needed to run SQLite-over-Wasm. I'm optimistic!

Randy, how hard would it be to implement something that read user data from Web SQL and wrote it into a parallel table structure in SQLite? Both of these will coexist in Chromium for some time.

Let us know how this goes, if you could. I'd also like to be aware of other extensions out there that might be using Web SQL and could have missed our announcements....

[Randy Lauen]

Hi Ben,

I think that's what I'll experiment with first. I was hoping someone else had traveled this road already and had some advice. My tentative plan for migrating is to copy the WebSQL data to SQLite, but keep both implementations running side by side for a while. If anything goes wrong, users could switch back to WebSQL, at least for a while. I'm at the very early stages of figuring out the new SQLite API, though, so there's a long way to go.

I don't know of any other extensions using WebSQL. The name of my extension is History Trends Unlimited (Thomas asked about this earlier in the thread). I created it 10 years ago, even though WebSQL was already deprecated at that point. I figured the extension would eventually die when WebSQL was removed; I'm very happy that there's a path forward now. Many thanks to all those involved.

--Randy

[Thomas Steiner]

Hola Alfonso!

If you use Ext.data.proxy.SqlView, you internally use Web SQL according to the documentation at https://docs.sencha.com/touch/2.1.1/#!/api/Ext.data.proxy.Sql. So yes, your app will most likely be affected. 

Cheers,

Tom

On Fri, Feb 10, 2023 at 3:31 AM Alfonso Ochoa Legorreta <alego...@merza.com> wrote:

Hi, I'm from Mexico and I have an android app created with the Sencha Touch framework and I use WebSQL for now everything is going great. My question is, will I also be affected by these changes?

[Alfonso Ochoa Legorreta]

Hi, I'm from Mexico and I have an android app created with the Sencha Touch framework and I use WebSQL for now everything is going great. My question is, will I also be affected by these changes?

El jueves, 9 de febrero de 2023 a las 10:23:14 UTC-6, Randy Lauen escribió:

[AQ Q]

https://sqlite.org/releaselog/3_44_0.html

Recently, SQLite released version 3.44.0, introducing a series of security-related enhancements and improvements. Given the critical role of SQLite in Chrome's infrastructure, I would like to draw your attention to some security benefits associated with upgrading to this latest version:

SQLite_DBCONFIG_DEFENSIVE Enhancement: The SQLITE_DBCONFIG_DEFENSIVE setting now prevents the PRAGMA writable_schema from being turned on. This eliminates the potential risk associated with writable_schema and enhances the overall defensive posture of SQLite.

Innocuous Tagging of Virtual Tables: The built-in FTS3, FTS4, FTS5, RTREE, and GEOPOLY virtual tables are now tagged as SQLITE_VTAB_INNOCUOUS. This allows their usage inside triggers in high-security deployments, ensuring compatibility without compromising security.
ggggGG
Run-time Detection of Hardware Support: SQLite now performs run-time detection of whether the underlying hardware supports "long double" with precision greater than "double." This adaptive approach ensures that appropriate floating-point routines are used based on the hardware capabilities, mitigating potential vulnerabilities.

PRAGMA case_sensitive_like Deprecation: The deprecation of the PRAGMA case_sensitive_like statement addresses potential issues related to database corruption when the schema contains LIKE operators. By discontinuing its use, potential security concerns are proactively mitigated.

Considering the security improvements and advancements outlined above, I would like to advocate for the careful consideration of upgrading SQLite in Chrome to version 3.44.0. This update not only introduces new features but also strengthens the security posture of the SQLite integration within the Chrome environment.