Re: [blink-dev] Intent to Deprecate and Remove: WebSQL in non-secure contexts

['Ben Morss' via blink-dev]

*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


On Thu, Feb 2, 2023 at 6:13 PM Carl Turechek  wrote:

> 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?
>
> On Wednesday, February 1, 2023 at 6:50:35 AM UTC-5 tste...@google.com
> wrote:
>
>> Hey Randy,
>>
>> On Tue, Jan 31, 2023 at 10:51 PM Randy Lauen  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
>>
>

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA6%2Bj4tCitkONY%3DhR51WVz%3DSHXECY3B2KP3UWZpbO6dBFZ0P8Q%40mail.gmail.com.

Re: [blink-dev] Intent to Deprecate and Remove: WebSQL in non-secure contexts

['Ben Morss' via blink-dev]

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


On Wed, Dec 14, 2022 at 4:36 PM Michal Šimonfy 
wrote:

> 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
> On Wednesday, December 14, 2022 at 5:36:31 PM UTC+1 mo...@google.com
> wrote:
>
>> 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.
>>
>>
>> On Wed, Dec 14, 2022 at 9:26 AM Michal Šimonfy 
>> wrote:
>>
>>> Hello there!
>>>
>>> will WebSQL continue to be available in Chrome extensions (through the
>>> chrome-extension:// scheme)?
>>>
>>> Thank you!
>>>
>>> All the best,
>>> Michal
>>>
>>> On Tuesday, December 13, 2022 at 8:59:39 PM UTC+1 mo...@google.com
>>> wrote:
>>>
 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 miight work?

 All best,

 Ben


 On Fri, Dec 9, 2022 at 11:06 AM Carl Turechek 
 wrote:

> 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:
>
>> Yes. Carl, does your app depend on Web SQL, webkitStorageInfo, or
>> something else?
>>
>> On Thu, Dec 8, 2022 at 6:55 PM Carl Turechek 
>> 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.
>>
>>
>>>
>>> On Wednesday, November 16, 2022 at 1:22:34 PM UTC-5 mo...@google.com
>>> wrote:
>>>
 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.


 On Mon, Nov 14, 2022 at 11:51 AM 'Thomas Steiner' via blink-dev <
 blin...@chromium.org> wrote:

Re: [blink-dev] Intent to Deprecate and Remove: WebSQL in non-secure contexts

['Ben Morss' via blink-dev]

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.


On Wed, Dec 14, 2022 at 9:26 AM Michal Šimonfy 
wrote:

> Hello there!
>
> will WebSQL continue to be available in Chrome extensions (through the
> chrome-extension:// scheme)?
>
> Thank you!
>
> All the best,
> Michal
>
> On Tuesday, December 13, 2022 at 8:59:39 PM UTC+1 mo...@google.com wrote:
>
>> 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 miight work?
>>
>> All best,
>>
>> Ben
>>
>>
>> On Fri, Dec 9, 2022 at 11:06 AM Carl Turechek 
>> wrote:
>>
>>> 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:
>>>
 Yes. Carl, does your app depend on Web SQL, webkitStorageInfo, or
 something else?

 On Thu, Dec 8, 2022 at 6:55 PM Carl Turechek 
 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.


>
> On Wednesday, November 16, 2022 at 1:22:34 PM UTC-5 mo...@google.com
> wrote:
>
>> 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.
>>
>>
>> On Mon, Nov 14, 2022 at 11:51 AM 'Thomas Steiner' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> The developer-facing documentation is being updated in
>>> https://github.com/GoogleChrome/developer.chrome.com/pull/4299.
>>>
>>> On Sat, Nov 12, 2022 at 12:26 AM Ayu Ishii 
>>> wrote:
>>>
 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

 On Wednesday, June 1, 2022 at 7:49:00 PM UTC-7 Ayu Ishii wrote:

> Thank you all for the approvals!
> And thank you miketaylr@ for the HTTPArchive analysis!
>
> On Wednesday, June 1, 2022 at 1:12:55 PM UTC-7 Mike Taylor wrote:
>
>> On 6/1/22 3:52 PM, Yoav Weiss wrote:
>>
>> LGTM3
>>
>> On Wed, Jun 1, 2022 at 8:58 PM Mike Taylor 
>> wrote:
>>
>>> On 6/1/22 1:34 PM, Chris Harrelson wrote:
>>>
>>>
>>> On Tue, May 31, 2022 at 8:26 PM Ayu Ishii 
>>> 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 ri

Re: [blink-dev] Intent to Deprecate and Remove: WebSQL in non-secure contexts

['Ben Morss' via blink-dev]

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
miight work?

All best,

Ben


On Fri, Dec 9, 2022 at 11:06 AM Carl Turechek 
wrote:

> 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:
>
>> Yes. Carl, does your app depend on Web SQL, webkitStorageInfo, or
>> something else?
>>
>> On Thu, Dec 8, 2022 at 6:55 PM Carl Turechek  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.
>>
>>
>>>
>>> On Wednesday, November 16, 2022 at 1:22:34 PM UTC-5 mo...@google.com
>>> wrote:
>>>
 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.


 On Mon, Nov 14, 2022 at 11:51 AM 'Thomas Steiner' via blink-dev <
 blin...@chromium.org> wrote:

> The developer-facing documentation is being updated in
> https://github.com/GoogleChrome/developer.chrome.com/pull/4299.
>
> On Sat, Nov 12, 2022 at 12:26 AM Ayu Ishii  wrote:
>
>> 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
>>
>> On Wednesday, June 1, 2022 at 7:49:00 PM UTC-7 Ayu Ishii wrote:
>>
>>> Thank you all for the approvals!
>>> And thank you miketaylr@ for the HTTPArchive analysis!
>>>
>>> On Wednesday, June 1, 2022 at 1:12:55 PM UTC-7 Mike Taylor wrote:
>>>
 On 6/1/22 3:52 PM, Yoav Weiss wrote:

 LGTM3

 On Wed, Jun 1, 2022 at 8:58 PM Mike Taylor 
 wrote:

> On 6/1/22 1:34 PM, Chris Harrelson wrote:
>
>
> On Tue, May 31, 2022 at 8:26 PM Ayu Ishii 
> 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
>

Re: [blink-dev] Intent to Deprecate and Remove: WebSQL in non-secure contexts

['Ben Morss' via blink-dev]

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

On Thu, Dec 8, 2022 at 6:55 PM Carl Turechek  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.
>
> On Wednesday, November 16, 2022 at 1:22:34 PM UTC-5 mo...@google.com
> wrote:
>
>> 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.
>>
>>
>> On Mon, Nov 14, 2022 at 11:51 AM 'Thomas Steiner' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> The developer-facing documentation is being updated in
>>> https://github.com/GoogleChrome/developer.chrome.com/pull/4299.
>>>
>>> On Sat, Nov 12, 2022 at 12:26 AM Ayu Ishii  wrote:
>>>
 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

 On Wednesday, June 1, 2022 at 7:49:00 PM UTC-7 Ayu Ishii wrote:

> Thank you all for the approvals!
> And thank you miketaylr@ for the HTTPArchive analysis!
>
> On Wednesday, June 1, 2022 at 1:12:55 PM UTC-7 Mike Taylor wrote:
>
>> On 6/1/22 3:52 PM, Yoav Weiss wrote:
>>
>> LGTM3
>>
>> On Wed, Jun 1, 2022 at 8:58 PM Mike Taylor 
>> wrote:
>>
>>> On 6/1/22 1:34 PM, Chris Harrelson wrote:
>>>
>>>
>>> On Tue, May 31, 2022 at 8:26 PM Ayu Ishii 
>>> 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.
>>
>> 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
>>>
>>>
>>>

 - Ayu

 On Monday, May 30, 2022 at 10:57:01 PM UTC-7 Mike West wrote:

> 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
>
>
> On Fri, May 27, 2022 at 2:18 AM Ayu Ishii 
> wrote:
>
>>
>> *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
>> 
>>
>>
>>>

Re: [blink-dev] Intent to Deprecate and Remove: WebSQL in non-secure contexts

['Ben Morss' via blink-dev]

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.


On Mon, Nov 14, 2022 at 11:51 AM 'Thomas Steiner' via blink-dev <
blink-dev@chromium.org> wrote:

> The developer-facing documentation is being updated in
> https://github.com/GoogleChrome/developer.chrome.com/pull/4299.
>
> On Sat, Nov 12, 2022 at 12:26 AM Ayu Ishii  wrote:
>
>> 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
>>
>> On Wednesday, June 1, 2022 at 7:49:00 PM UTC-7 Ayu Ishii wrote:
>>
>>> Thank you all for the approvals!
>>> And thank you miketaylr@ for the HTTPArchive analysis!
>>>
>>> On Wednesday, June 1, 2022 at 1:12:55 PM UTC-7 Mike Taylor wrote:
>>>
 On 6/1/22 3:52 PM, Yoav Weiss wrote:

 LGTM3

 On Wed, Jun 1, 2022 at 8:58 PM Mike Taylor 
 wrote:

> On 6/1/22 1:34 PM, Chris Harrelson wrote:
>
>
> On Tue, May 31, 2022 at 8:26 PM Ayu Ishii  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.

 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
>
>
>
>>
>> - Ayu
>>
>> On Monday, May 30, 2022 at 10:57:01 PM UTC-7 Mike West wrote:
>>
>>> 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
>>>
>>>
>>> On Fri, May 27, 2022 at 2:18 AM Ayu Ishii  wrote:
>>>

 *Contact emails *a...@chromium.org, jsb...@chromium.org,
 ajayrahate...@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 

Re: [blink-dev] Intent to Remove: window.webkitStorageInfo

['Ben Morss' via blink-dev]

Thanks for doing this, Ayu. Once our mechanisms are in place for informing
partners more thoroughly, I think these deprecations will be simpler!



On Fri, Aug 19, 2022 at 10:07 AM Mike Taylor  wrote:

> Thanks for the heads up Ayu.
>
> On 8/18/22 8:47 PM, Ayu Ishii wrote:
>
> Hi everyone,
>
> Updating the thread to inform that we have decided to extend the target
> milestone until we've properly informed our partners. Will update the
> thread again when we have a new target.
>
> Thanks,
> Ayu
> On Tuesday, August 9, 2022 at 7:57:19 AM UTC-7 jmedley via Chromestatus
> wrote:
>
>> My notes say this is shipping in 106. Regardless, please enter the
>> shipping milestone in the correct fields. (Click Edit all fields, the
>> scroll to the bottom.) Thanks, Joe
>>
> --
> 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+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/13fd6dd9-aceb-4fd8-af25-4603d523c478n%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+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f2fa2d9e-1da7-edec-5fe6-9a28fede890e%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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA6%2Bj4tgtKytkE2AogMd1XfwA2bzka67yOmYtNNXn99snmfirQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Multi-Screen Window Placement

['Ben Morss' via blink-dev]

Thanks for weighing in, everyone. Glad to see these approvals coming in!

Ben

On Wednesday, February 23, 2022 at 8:57:57 AM UTC-5 mk...@chromium.org 
wrote:

> LGTM3. Thanks for the work y'all have done with the security and privacy 
> teams to get this in the right place. I believe permissions folks want to 
> follow up about the shape of the final implementation from a UX 
> perspective, so please ensure that you chat with +Illia Klimov and/or +Balazs 
> Engedy before flipping the flags, but I think you're good to go from a 
> web platform perspective.
>
> Thanks!
>
> -mike
>
>
> On Wed, Feb 23, 2022 at 2:07 PM Yoav Weiss  wrote:
>
>> LGTM2
>>
>> This seems like an important use-case to tackle!
>>
>> On Tue, Feb 22, 2022 at 9:37 PM 'Ajay Rahatekar' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> Hello Blink APi owners,
>>>
>>> Please let us know if you need more details. The team is targeting 
>>> shipping the API in M100 and would be very appreciative of early 
>>> feedback/approval to meet the milestone timeline requirements.
>>>
>>> Thanks in advance.
>>>
>>> Ajay
>>>
>>> On Friday, February 18, 2022 at 7:28:50 AM UTC-8 mike...@chromium.org 
>>> wrote:
>>>
 Hi Michael,

 I think you and team have done a great job incorporating TAG and API 
 ergonomics feedback (hi Jake!) as well as privacy concerns. Nice work.

 LGTM1.

 On 2/14/22 8:28 PM, Michael Wasserman wrote:

 Contact emails 

 m...@chromium.org


 Explainer 

 https://github.com/webscreens/window-placement


>> Great explainer! Thanks for that!! 
>>
>>>
 Specification 

 https://webscreens.github.io/window-placement/

 Design docs  https://web.dev/multi-screen-window-placement/ 
 Summary 

 Adds new screen information APIs and makes incremental improvements to 
 existing window placement APIs, allowing web applications to offer 
 compelling multi-screen experiences.

 The existing singular window.screen offers a limited view of available 
 screen space, and window placement functions generally clamp bounds to the 
 current screen. This feature unlocks modern multi-screen workspaces for 
 web 
 applications.

 Blink component 

 UI>Browser>WebAppInstalls>Desktop 
 

 Search tags 

 window placement 
 , screen 
 enumeration 
 , window 
 , open 
 , moveTo 
 , moveBy 
 , requestFullscreen 
 , screen 
 , display 
 , monitor 
 , multi-screen 
 , multi-display 
 , multi-monitor 
 , cross-screen 
 , cross-display 
 , cross-monitor 
 

 TAG review 

 https://github.com/w3ctag/design-reviews/issues/413 
 https://github.com/w3ctag/design-reviews/issues/522 
 https://github.com/w3ctag/design-reviews/issues/602

 TAG review status 

 Issues addressed

 Risks 
 Interoperability and Compatibility 

 Feature detection of new screen information APIs and Permission API 
 integration allows sites to handle different levels of feature support. 
 The 
 Screen IDL interface duplicates EventTarget members for RuntimeEnabled 
 experimentation without changing the stable JS API; this will be rectified 
 after launch approval.

 Existing window placement APIs generally use compatible multi-screen 
 coordinates, but implementations often restrict bounds to the current 
 screen. We expect low levels of risk in supporting permitted cross-screen 
 placement requests, and falling back on legacy same-screen behavior 
 otherwise.

 A detailed assessment of API design risks, including Wayland 
 compatibility, multiple virtual workspaces/desktops, and more, can be 
 found 
 at: <
 https://docs.google.com/document/d/19u5fRKs8iWlpecKBSlfQ6JKrcP4emwK0M_6TNhfz0gs
 >

 API surface changes made during the second origin trial are limited to 
 some minor renames, the removal of two un

Re: [blink-dev] Intent to Ship: Multi-Screen Window Placement

['Ben Morss' via blink-dev]

+morss@ as well

On Wednesday, February 16, 2022 at 11:26:20 AM UTC-5 Ajay Rahatekar wrote:

> +ajayrahatekar@
>
> On Tuesday, February 15, 2022 at 8:27:55 AM UTC-8 ikilp...@chromium.org 
> wrote:
>
>> On Mon, Feb 14, 2022 at 5:28 PM Michael Wasserman  
>> wrote:
>>
>>> Contact emails
>>>
>>> m...@chromium.org
>>>
>>>
>>> Explainer
>>>
>>> https://github.com/webscreens/window-placement
>>>
>>> Specification
>>>
>>> https://webscreens.github.io/window-placement/
>>>
>>> Design docs https://web.dev/multi-screen-window-placement/
>>> Summary
>>>
>>> Adds new screen information APIs and makes incremental improvements to 
>>> existing window placement APIs, allowing web applications to offer 
>>> compelling multi-screen experiences.
>>>
>>> The existing singular window.screen offers a limited view of available 
>>> screen space, and window placement functions generally clamp bounds to the 
>>> current screen. This feature unlocks modern multi-screen workspaces for web 
>>> applications.
>>>
>>> Blink component
>>>
>>> UI>Browser>WebAppInstalls>Desktop 
>>> 
>>>
>>>
>> This isn't a great component for code that lives within Blink. Can we 
>> create a new component for anything screen API related with the team 
>> working on this responsible for triaging these bugs?
>>
>> E.g. something like Blink>Screen or Blink>ScreenAPIs
>>
>> Specifically any code that lives within Blink should have a Blink 
>> component due to how top level triage works.
>>
>> Search tags
>>>
>>> window placement 
>>> , screen 
>>> enumeration 
>>> , window 
>>> , open 
>>> , moveTo 
>>> , moveBy 
>>> , requestFullscreen 
>>> , screen 
>>> , display 
>>> , monitor 
>>> , multi-screen 
>>> , multi-display 
>>> , multi-monitor 
>>> , cross-screen 
>>> , cross-display 
>>> , cross-monitor 
>>> 
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/413 
>>> https://github.com/w3ctag/design-reviews/issues/522 
>>> https://github.com/w3ctag/design-reviews/issues/602
>>>
>>> TAG review status
>>>
>>> Issues addressed
>>>
>>> Risks
>>> Interoperability and Compatibility
>>>
>>> Feature detection of new screen information APIs and Permission API 
>>> integration allows sites to handle different levels of feature support. The 
>>> Screen IDL interface duplicates EventTarget members for RuntimeEnabled 
>>> experimentation without changing the stable JS API; this will be rectified 
>>> after launch approval.
>>>
>>> Existing window placement APIs generally use compatible multi-screen 
>>> coordinates, but implementations often restrict bounds to the current 
>>> screen. We expect low levels of risk in supporting permitted cross-screen 
>>> placement requests, and falling back on legacy same-screen behavior 
>>> otherwise.
>>>
>>> A detailed assessment of API design risks, including Wayland 
>>> compatibility, multiple virtual workspaces/desktops, and more, can be found 
>>> at: <
>>> https://docs.google.com/document/d/19u5fRKs8iWlpecKBSlfQ6JKrcP4emwK0M_6TNhfz0gs
>>> >
>>>
>>> API surface changes made during the second origin trial are limited to 
>>> some minor renames, the removal of two unimplemented screen properties, and 
>>> support for permission policy. An exploratory permission-gated capability 
>>> to swap the screen of fullscreen windows without a user gesture was 
>>> reverted to enhance usable security. See <
>>> https://github.com/webscreens/window-placement/blob/main/CHANGES.md>
>>>
>>> The spec is being incubated in the W3C Second Screen CG <
>>> https://webscreens.github.io/cg-charter> and is pending adoption by the 
>>> W3C Second Screen WG 
>>>
>>> Gecko: No signal (
>>> https://github.com/mozilla/standards-positions/issues/542) We requested 
>>> a position and are waiting for feedback. Firefox supports cross-screen 
>>> window.open/move*() requests. This work partly pursues compatibility 
>>> with that behavior.
>>>
>>> WebKit: No signal (
>>> https://lists.webkit.org/pipermail/webkit-dev/2021-June/031903.html) We 
>>> requested a position and are waiting fo