[blink-dev] Re: Intent to Ship: Local Fonts Access API

['Joshua Bell' via blink-dev]

FYI, non-normative note added. I also followed up on the questions in the
Moz standards position thread, added a few more notes to the spec as well.

On Wed, Apr 27, 2022 at 9:01 AM Alex Russell 
wrote:

> A non-normative note in the spec sounds good. Wouldn't want to block
> shipping on it.
>
> On Wednesday, April 27, 2022 at 2:05:53 AM UTC-7 Yoav Weiss wrote:
>
>> If we're going with exposing byte-by-byte representation of the fonts on
>> the user's filesystem, we should make that slightly more explicit. Maybe
>> add a note to
>> https://wicg.github.io/local-font-access/#font-representation-data-bytes
>> clarifying that point?
>>
>> I *think* that lack of normalization should resolve the issues Anne was
>> concerned about in https://github.com/WICG/local-font-access/issues/20,
>> where different normalization algorithms result in compatibility issues. I
>> also *think* it should resolve Tess' concerns RE user assumptions of the
>> fonts being Open-Type. Can you clarify those points with them?
>>
>> On Monday, April 25, 2022 at 6:12:00 PM UTC+2 Alex Russell wrote:
>>
>>> Normalisation isn't usually a goal for users that want the actual bytes
>>> of the local font in order to do the rendering themselves and can be an
>>> active non-goal given the ways that folks want to do custom grouping,
>>> enumeration, and rendering. Partners have consistently asked us not to
>>> remove information and I've never heard of a request for normalisation from
>>> a partner.
>>>
>>> This is in line with not adding OTS sanitisation for these files  (we
>>> don't need to when the OS rendering pipeline isn't at potential risk), and
>>> highlights the way that the current design is isomorphic with local file
>>> access.
>>>
>>> I've LGTM'd it in the tool as a result.
>>>
>>> Thanks to everyone at Google for continuing to push this forward.
>>>
>>> Best Regards,
>>>
>>> Alex
>>>
>>> On Thursday, April 21, 2022 at 9:46:15 AM UTC-7 Joshua Bell wrote:
>>>
 On Wed, Apr 20, 2022 at 4:21 AM Yoav Weiss 
 wrote:

>
>
> On Wed, Apr 13, 2022 at 6:46 PM Joshua Bell  wrote:
>
>> On Wed, Apr 13, 2022 at 6:36 AM Yoav Weiss 
>> wrote:
>>
>>> Also, any learnings/feedback from the Origin Trial?
>>>
>>>
>> Not distinct from the dev trial (i.e. developers trying the API
>> behind a flag). There was a feature request for additional metadata which
>> was implemented, then the request was withdrawn so that code was backed
>> out. Other requests are marked as "enhancements" in the issue tracker, 
>> e.g.
>> font modification timestamps.
>>
>>
>>> On Wednesday, April 13, 2022 at 3:35:02 PM UTC+2 Yoav Weiss wrote:
>>>
 On Friday, April 8, 2022 at 8:15:42 PM UTC+2 Ajay Rahatekar wrote:

> Contact emails
>
> ds...@chromium.org, jsb...@chromium.org
>
> Explainer
>
> https://github.com/WICG/local-font-access
>
> Specification
>
> https://wicg.github.io/local-font-access/
>
> Design docsDesign Doc: https://bit.ly/2HWBOLi
> 
>
> Blog: https://web.dev/local-fonts/
>
>
> Summary
>
> Gives web applications the ability to enumerate local fonts and
> some metadata about each. Today, no API exists to provide a list of 
> local
> fonts to web applications.
>
> Also gives web applications access to the font data as a binary
> blob, allowing those fonts to be rendered within their applications 
> using
> custom text stacks.
>
> Blink component
>
> Blink>Fonts
> 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/400
>
> TAG review status
>
> Pending
>
> RisksInteroperability and Compatibility
>
> This API has been designed to support feature detection to allow
> applications to gracefully degrade based on the capabilities 
> different user
> agents offer.
>
> We expect developers using this API to design their web
> applications to use web-based fonts as the primary set of font 
> choices, but
> allow users to opt-in to take advantage of their local fonts for 
> specific
> design needs.
>
> If this feature were removed from the platform, web applications
> would lose the ability to enumerate local fonts and retrieve font 
> data but
> otherwise are expected to continue to function.
>
> Gecko: https://github.com/mozilla/standards-positions/issues/401
>

Re: [blink-dev] Intent to Ship: Digital Goods API 2.1

['Rouslan Solomakhin' via blink-dev]

> Estimated milestones
> We would like to ship DGAPI v2.1 in M102.

Hello,

FYI, the team has decided to postpone DGAPI v2.1 release to M103.

Let me know if you have any questions. Thank you!

Cheers,
Rouslan

On Friday, April 15, 2022 at 3:10:43 PM UTC-4 yoav...@chromium.org wrote:

> LGTM3
>
> On Fri, Apr 15, 2022, 18:20 Rouslan Solomakhin  
> wrote:
>
>>
>>
>> On Fri, Apr 15, 2022 at 9:44 AM Mike Taylor  wrote:
>>
>>> On 4/15/22 12:31 AM, Yoav Weiss wrote:
>>>
>>> On Mon, Apr 11, 2022 at 4:45 PM Rouslan Solomakhin  
>>> wrote:
>>>
 Contact emails 

 gle...@chromium.org, rou...@chromium.org

 Explainer 

 https://github.com/WICG/digital-goods/blob/main/explainer.md#api-v21

 Specification 

 https://wicg.github.io/digital-goods/

 Difference between 2.0 and 2.1 
 

 Design docs 

 https://github.com/WICG/digital-goods/blob/master/explainer.md


 https://docs.google.com/document/d/1Jbt2Mzt-xg1cWVlFScBQsoX_pE8Kg1gYpulxUSV8FM0/edit

 Summary 

 We would like to ship a non-breaking addition to the existing Digital 
 Goods API. This change:

- 

Adds to DigitalGoodsService:
- 
   
   Promise> listPurchaseHistory();
   - 

Adds to ItemDetails:
- 
   
   ItemType type;
   - 
   
   sequence iconUrls;
   - 
   
   unsigned short introductoryPriceCycles;
   - 

Adds enum ItemType.


 Use of the new methods/fields will require developers to update 
 supporting code in their apps, such as Android Browser Helper 
 .

>>>
>>> Am I correct to assume that if developers don't update their code, 
>>> nothing will break?
>>>
>>> AFAICT from reading the spec diff, these changes are purely additive. 
>>> LGTM2 assuming Rouslan can verify our understanding. :)
>>>
>>
>> That is correct. If web developers do not update their code, nothing will 
>> break. Updating the supporting code is required only to access the new 
>> features. 
>>
>>>
 Blink component 

 Blink>Payments 
 

 Search tags 

 payments , billing 
 

 TAG review 

 https://github.com/w3ctag/design-reviews/issues/571 

 TAG review status 

 TAG continues to think of DGAPI as a “product-specific API within one 
 company.”

 Other issues addressed.

 Risks Interoperability and Compatibility 

 Similar to Payment Request: this API is used to talk to specific store 
 backends, and so its usage is tailored to the specific store. The reason 
 it's a proposed web standard is so that the same code (which is specific 
 to 
 one store) is portable across browsers.

 Gecko: No signal (
 https://github.com/mozilla/standards-positions/issues/349) Requested 
 2020-05-27

 WebKit: No signal (
 https://lists.webkit.org/pipermail/webkit-dev/2021-October/032001.html) 
 Requested 2021-10-08

 Web developers: Positive (
 https://discourse.wicg.io/t/proposal-web-payments-digital-product-management-api/4350
 )

 Other signals: rouslan@ presented DGAPI at 2021 TPAC 
  (meeting 
 notes ) and at a PWA 
 Dev Sync 
  
 (meeting notes 
 ).
  
 Other browser implementers and app stores do not appear to have immediate 
 plans to engage with DGAPI. There were some questions, no objections.

 Ergonomics 

 Used in tandem with the Payment Request API.

 WebView Application Risks 

 This API is disabled in WebView.


 Debuggability 

 We have had several requests from developers to make the API easier to 
 debug, but it is difficult due to the interaction with a backing service 
 based in an app/store context. We are looking for suggestions (
 https://github.com/WICG/digital-goods/issues/33) on how we might 
 improve the debuggability of the API.

 Is this feature fully tested by web-platform-tests 
 
 ? 

 The tests are in 
 //third_party/blink/web_tests/wpt_internal/digital-goods.

 Flag name 
>>>

Re: [blink-dev] Intent to Extend Origin Trial: Trial for SharedArrayBuffers in non-isolated pages on Desktop platforms

[Mike Taylor]

On 4/27/22 12:26 PM, Lutz Vahl wrote:



On Wed, Apr 27, 2022 at 5:14 PM Chris Harrelson 
 wrote:




On Wed, Apr 27, 2022 at 6:04 AM Lutz Vahl  wrote:


  Contact emails

v...@chromium.org cl...@chromium.org


Explainer


https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k




Specification

https://tc39.github.io/ecma262/#sec-sharedarraybuffer-objects



Design docs Including the new security requirements


https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer



Discussion how and what to gate

https://github.com/whatwg/html/issues/4732



Summary

‘SharedArrayBuffers’ (SABs) on desktop platforms are
restricted to cross-origin isolated environments, matching the
behavior we've recently shipped on Android and Firefox. We've
performed that change in Chrome 92. A reverse OT was started
to give developers the option to use SABs in case they are not
able to adopt cross origin isolation yet.

We’ve received lot’s of feedback that adopting COOP/COEP is
hard (details below). Therefore I’m asking for your approval
to extend the SAB reverse OT again from M103untilM113(branch
point 2023-03-23). This is an estimation - Can we come back to
y'all in 6 months with a report on progress and usage to
justify that extension and agree on the final milestone?


Experimental timeline / plan for all new capabilities needed
to replace the OT

The SAB restriction in M92 went smoothly without any major
issues in the wild because we offered the reverse OT. We’ve
received lots of feedback that adopting COOP/COEP is hard and
sometimes impossible. Therefore the reverse OT is currently
the only way to enable SABs for some sites within Chromium.
Chromestatus is showing that SABs in none COI context are
being used on ~0.36%

page
loads.


This seems off by a factor of 10. The real number seems to be
0.036% or so
,
right? Can you highlight why it's important to extend for 10 more
milestones for such a small percentage of traffic? Will the sites
in question completely break for some reason, or just behave the
same as in non-chromium browsers?

That's on me: 0.036% 
 is 
correct!
Some sites use SAB to gain extra performance on chromium based 
browsers in some cases 3P content is using SABs. Some might work 
without the OT others will break based on how they identify their code 
path to be used.


The list of OT registrations is ~500 and most of them mentioned to be 
blocked by 3Ps to deploy COOP+COEP broadly.
We're happy to extend the OT to give them time to adopt. Do you 
(and/or other API owners) think this is not required based on the low 
usage?


Looking at the use counter data, usage was around 0.17% when the last 
request to extend this deprecation trial was made (in Sept of '21). 
Since then, it seems like usage decreased quite a lot but has been 
basically flat since November of '21 when it was at 0.031% (it's looks 
to have grown a tiny bit to 0.037% as of April).


Do we know who the 3Ps are who are holding back migration for the rest, 
and what their plans are?





To overcome this limitation and make adoption possible more
broadly (public feedback
), we’re working
on multiple solutions

(all
shared timelines are WIP):


1.

COEP:credentialless
-
https://crbug.com/1218896 

COEP:credentialless causes no-cors cross-origin requests not
to include

credentials (cookies, client certificates, etc...). Similarly
to require-corp, it can be used to enable
cross-origin-isolation. Some developers are blocked on a set
of dependencies which don't yet assert that they're safe to
embed in cross-origin isolated environments.

This mechanism was shipped in M96. (Adoption is already at
0.02%

[blink-dev] Re: FYI Privacy Sandbox Ads APIs origin trial

[John Delaney]

The unified origin trial for the Privacy Sandbox relevance and measurement 
APIs (Topics, FLEDGE and Attribution Reporting) is available in Chrome 
Beta.  We plan to ramp up to approximately 50% of the Chrome Beta 
population within the next two weeks.  We will continue to run the origin 
trial in Chrome Beta to evaluate the functionality of the APIs and the 
accompanying user controls.   Technical testing is an important first step 
in the origin trial process;  developers are encouraged to provide feedback 
on API functionality, documentation and ease of integration.  To get 
support, report issues, or provide feedback please see these resources for 
Topics 
,
 
FLEDGE 

 
and Attribution Reporting 
.
 
 

We will provide updates soon on when we expect to advance the origin trial 
to Chrome Stable, with increased traffic volume to support additional 
testing.

On Friday, April 8, 2022 at 4:17:12 PM UTC-4 John Delaney wrote:

> Hi blink-dev,
>
> This is a heads-up that there will be a shared origin trial for three new 
> APIs.
>
> The "Privacy Sandbox Ads APIs" origin trial will include:
>
>- Attribution Reporting API: 
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/jEnNpideO1Y/m/nlEDdjmnCgAJ
>- FLEDGE: 
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/0VmMSsDWsFg/m/_0T5qleqCgAJ
>- Topics API: 
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/oTwd6VwCwqs/m/jPkW3T-mCgAJ
>
>
> Please see each API’s Intent to Experiment for additional details.
>
> We have published separate guidance on how this shared origin trial will 
> work, and how developers can participate once available here:
>   
> https://developer.chrome.com/blog/privacy-sandbox-unified-origin-trial/
>
> Thanks!
>

-- 
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/020d05e9-8522-44c8-bd0c-87c0b6af121bn%40chromium.org.

Re: [blink-dev] Request to Extend Experiment: Web app launch handler

['Ibrahim Karahan' via blink-dev]

+Joyce Toh  FYI

On Thu, Apr 28, 2022 at 2:36 AM Alan Cutter  wrote:

>
>
> On Wednesday, 27 April 2022 at 8:14:05 pm UTC+10 Yoav Weiss wrote:
>
>> Hey Alan!
>>
>> Our policy
>> 
>> on Origin Trial extensions recently
>> 
>> changed, and we now require to see significant progress on various
>> shipping-related work before approving extensions (for 3 milestones at a
>> time).
>> Have y'all started working on a spec, signal requests
>> , WPTs, etc?
>>
>> Since the policy change is recent, we may be able to provide affordances
>> (e.g. a 1 milestone extension) to enable you to catch up on such work if
>> you haven't done that yet.
>>
>
> Oof, wasn't expecting this. Thanks for the helpful links, I've
> reprioritised my immediate workload to have this spec progress happen
> sooner. The 1 milestone extension would be appreciated in the meantime.
> So far all I have is an explainer
> , positive
> dev feedback
> ,
> TAG approval
>  
> and
> crickets on a request for Mozilla position
> .
> I will spin up on getting a draft spec written (re-requesting a spec
> mentor as my existing one went on extended leave) and reach out for more
> feedback from the spec community.
>
>
>>
>> Aside: It seems like this thread was not picked up by our tooling due to
>> using the wrong title ("Request" rather than "Intent") and a mismatched
>> Chrome Status entry.
>> /cc +Jason Robbins 
>>
>
> My bad; the dangers of copy paste. D:
> I wasn't able to find a clean template on chromestatus.com but I might be
> holding the tool wrong.
>
> Corrected version:
>
> *Tracking bugs*
> https://bugs.chromium.org/p/chromium/issues/detail?id=1231886
> https://bugs.chromium.org/p/chromium/issues/detail?id=1247817
>
>
> *Link to entry on the Chrome Platform Status*
> https://www.chromestatus.com/feature/5722383233056768
>
>
>>
>> On Tue, Apr 26, 2022 at 5:18 AM 'Alan Cutter' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emails
>>>
>>> alancut...@chromium.org
>>>
>>> Original I2E
>>>
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/wNOClobsLrs
>>>
>>> Explainer
>>>
>>> https://github.com/WICG/sw-launch/blob/main/launch_handler.md
>>>
>>> Summary
>>>
>>> Adds a "launch_handler" app manifest member that enables web apps to
>>> customise their launch behaviour across all types of app launch
>>> triggers (start menu launch, link capture, share target, etc.). Example
>>> usage: { "name": "Example app", "start_url": "/index.html",
>>> "launch_handler": { "route_to": "existing-client-navigate" } } This
>>> will cause all launches of the Example app to focus an existing app window
>>> and navigate it (if it exists) instead of always launching a new app window.
>>>
>>>
>>> Blink component
>>>
>>> Blink>AppManifest
>>> 
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/683
>>>
>>> TAG review status
>>>
>>> Closed. Satisfied to see this move ahead but keeping in mind
>>> compatibility with the MiniApp lifecycle
>>> .
>>>
>>>
>>> Risks:Interoperability and CompatibilityGecko: No signal
>>> 
>>> Web developers: Strong positive signals on the previous Declarative
>>> Link Capturing origin trial
>>> ,
>>> strong positive signals from the origin trial so far
>>> 
>>> .
>>>
>>> Experiment Summary
>>>
>>>
>>> https://docs.google.com/document/d/1t60YeQ-d-FSr9i91jvylW6sA7_R4jDnX1G4_PDfssYE/edit?usp=sharing
>>>
>>>
>>> Experiment Goals
>>>
>>>  - Test the new syntax with "existing_client_navigate" removed.
>>>
>>>  - Give more opportunities to gather feedback on the "route_to":
>>> "existing-client-retain" behaviour that wasn't present in the DLC origin
>>> trial.
>>>
>>>
>>> Experiment Timeline
>>>
>>> Previous: M97 to M102.
>>>
>>> Requested: M103 to M108.
>>>
>>> Reason this experiment is being extended
>>>
>>> The shape of the API changed 
>>> to address TAG feedback on default behaviours.
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?
>>>
>>> No, desktop only.
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 

Re: [blink-dev] Intent to Experiment: Load common payloads from privacy-preserving single-keyed cache

['Joe Medley' via blink-dev]

What is that?

I'm trying to understand what this is because I need or may need to explain
it in writing to the external world in a few weeks. I've never heard of a
CacheTransparancy flag.
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Thu, Apr 28, 2022 at 1:26 AM Adam Rice  wrote:

> Finch flag?
>
>
> CacheTransparency (but the code is not landed yet).
>
> On Thu, 28 Apr 2022 at 03:07, Joe Medley  wrote:
>
>> Finch flag?
>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Wed, Apr 27, 2022 at 2:30 AM Adam Rice  wrote:
>>
>>> What is an 'off-by-default experiment'? Is that a dev trial flag?
>>>
>>>
>>> Just an ordinary experiment, behind a flag which is off-by-default. So
>>> most users get the default behaviour (no single-keyed cache), except for
>>> those in the experimental group.
>>>
>>> On Wed, 27 Apr 2022 at 00:50, Joe Medley  wrote:
>>>
 What is an 'off-by-default experiment'? Is that a dev trial flag?
 Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195 <(816)%20678-7195>
 *If an API's not documented it doesn't exist.*


 On Tue, Apr 26, 2022 at 4:59 AM Daisuke Enomoto 
 wrote:

> Contact emails
>
> ri...@chromium.org, nidhij...@chromium.org, denom...@chromium.org
>
> Explainer
>
>
> https://docs.google.com/document/d/1pvaMg7J5beBXD7trzHJH_MDULc_wRHLx40MFYAmjknE/edit
>
> Specification
>
> N/A (because there are no web-exposed changes)
>
> Summary
>
> This limited experiment measures how much "pervasive payloads"
> contribute to the performance impact of the split HTTP cache in each 
> Chrome
> channel over a three-week period. Pervasive payloads are those third-party
> payloads included on at least 500 sites and fetched at least 10M times in 
> a
> month, based on Chrome's analysis (payload list included below). This
> experiment further measures the impact on Core Web Vitals metrics of
> restoring pervasive payloads (and only pervasive payloads) to a
> single-keyed cache regime. The privacy benefits of the split HTTP cache 
> are
> preserved.
>
> Blink component
>
> Blink>Network
> 
>
> Motivation
>
> Browsers split HTTP caches based on the top-frame visited origin
> (“double-keyed” or "triple-keyed" caching) to prevent sites from tracking
> users via a timing attack on a cross-site client cache.
>
> Chrome’s analysis estimates that split caching results in a 3%
> increase in cache misses, i.e. fetches for which a payload exists in the
> cache of the user's device, but is unavailable to the page because it was
> fetched by the user while loading a page from a different origin. This
> results in approximately 4% more total bytes being fetched over the 
> network.
>
> Our analysis further revealed that many of the redundant fetches
> caused by split caching were for common payloads associated with 
> displaying
> user content (libraries, fonts, widgets, ads) or common payloads that
> assist in operating online businesses (analytics). The delayed arrival of
> these common payloads resulted in visible "jank" for users, impacting
> performance metrics like LCP , FCP
>  and CLS . This jank has
> been associated with negative effects to online business' engagement and
> conversion rates. Furthermore, delayed loads of analytics and ads payloads
> can result in missed ads impressions and dropped analytics hits.
>
> Initial public proposal
>
> This experiment sends a list to Chrome of 100  pairs whose
> payloads are considered pervasive (the "pervasive payloads list"). During
> the three-week experiment period, if Chrome fetches a payload that matches
> both the URL and its hash on the pervasive payloads list, it is inserted
> into a local single-keyed cache. This payload is then available for use by
> Chrome when loading pages on other sites that include the matching URL. 
> All
> other fetches for URLs not on the pervasive payloads list are cached
> according to the existing split HTTP cache.
>
> The hash covers the payload body and most response headers, except for
> those which change on every response.
>
> To ensure we do not degrade the privacy profile of any users during
> this experiment, only users with third-party cookies currently enabled 
> will
> be eligible for the experiment. We will compare the experience of users in
> experiment and control arms according to total bytes loaded and 

Re: [blink-dev] Intent to Deprecate and Remove: Battery Status API in Insecure Origins

[Raphael Kubo da Costa]

Back when I sent the original Intent to Deprecate and Remove email, I 
checked the samples from the previous quarter listed in chromestatus.com 
and surveyed some 50 websites.


Some of them were no longer using the Battery Status API from an 
insecure context (either because they had switched to HTTPS or because 
they had stopped embedding whatever was using it before), but 43 had a 
match in the form of trackers, embedded YouTube videos, Facebook widgets 
and, in 2 cases, other trackers that also performed feature detection.


Today I surveyed another 40 from the previous quarter. All of them were 
either using Yandex trackers and/or embedded YouTube videos; a single 
one was using another tracker that also performed feature detection 
before using the API.


I ended up doing these checks manually; I can try to perform some larger 
queries via HTTPArchive if preferred.


On 28-04-2022 13:12, Yoav Weiss wrote:
OK, if you ran through a sample of users and saw none of them break, 
that's reassuring. How many users have you sampled?


At the same time, I'm not aware of a real way in IDL today to indicate 
that an API is not accessible in non-secure contexts and at the same 
time to have such access trigger a warning.






On Thu, Apr 28, 2022 at 12:04 PM Raphael Kubo da Costa 
 wrote:


I tend to agree with Mike here; none of the users of
navigator.getBattery() in insecure contexts I checked in the past
(via chromestatus.com ) would break with
this change, as they're all checking if it's available first
(including the largest user so far, YouTube), which makes sense
since other engines don't ship this API.

What I can do is write another CL that adds a new Blink runtime
feature set to experimental and updates the current deprecation
message and mentions the feature will be removed in M104, not
M103. What's not clear is whether it would be possible to warn
users if the feature flag is on and a website tries to use the
Battery Status API in an http page, as adding something like
[SecureContext=MyFeatureFlag] to the IDL files would prevent the
code where the warning would go from even being reached if
MyFeatureFlag is on.

With that said, I guess it's up to the API owners to decide on the
course here?

On 26-04-2022 09:47, Mike West wrote:

I'm less worried about this than Yoav is. Given the lack of
support in any other browser, and the progressive-enhancement
nature of this API, it's difficult for me to imagine embedded
content visibly breaking at scale. If y'all do some spot-checking
of the sites currently showing up through HTTP Archive, and have
some evidence of the lack of user-visible breakage, I'd be
comfortable without the additional complexity of percentage
rollouts through Finch.

If we do decide that that's necessary, we'll need to make sure
that we have some sort of reasonable error message in the console
so that the subset of developers who do experience some sort of
breakage have a chance of understanding why.

-mike

On Monday, April 25, 2022 at 9:36:26 PM UTC+2 Yoav Weiss wrote:

I think it'd be better to add a feature flag disabled by
default, and then work with someone at Google to enable it on
the server side for a release, before enabling it in code.
That way it'd be easy to revert this in case this
unexpectedly breaks things.

On Mon, Apr 25, 2022 at 5:00 PM Raphael Kubo da Costa
 wrote:

Thanks, Yoav. I've submitted
https://chromium-review.googlesource.com/c/chromium/src/+/3605588
to implement this change. There's never been a feature
flag for this though (in M99 we just added a deprecation
warning), should I add one now?

On 25-04-2022 16:40, Yoav Weiss wrote:

The LGTMs you got on this thread should be enough.
Please make sure to monitor any issues related to this,
and revert if needed. (while keeping the feature flag
around to enable urgent re-activation of this if
breakage turns out to be untenable)

On Thu, Apr 21, 2022 at 3:00 PM Raphael Kubo da Costa
 wrote:

Hi everyone,

M103 is here, so I'd like to double-check if I can
go ahead and stop exposing the Battery Status API to
insecure origins as described below. The numbers in

https://chromestatus.com/metrics/feature/timeline/popularity/2199
remain flat (as explained, the percentage is pretty
high but most of it comes from embedded https
YouTube videos, trackers and RUM (real user
monitoring) code in https pages.

Do I start another thread and get new LGTMs for the
actual removal?

On 

Re: [blink-dev] Intent to Deprecate and Remove: Battery Status API in Insecure Origins

[Yoav Weiss]

OK, if you ran through a sample of users and saw none of them break, that's
reassuring. How many users have you sampled?

At the same time, I'm not aware of a real way in IDL today to indicate that
an API is not accessible in non-secure contexts and at the same time to
have such access trigger a warning.





On Thu, Apr 28, 2022 at 12:04 PM Raphael Kubo da Costa <
raphael.kubo.da.co...@intel.com> wrote:

> I tend to agree with Mike here; none of the users of
> navigator.getBattery() in insecure contexts I checked in the past (via
> chromestatus.com) would break with this change, as they're all checking
> if it's available first (including the largest user so far, YouTube), which
> makes sense since other engines don't ship this API.
>
> What I can do is write another CL that adds a new Blink runtime feature
> set to experimental and updates the current deprecation message and
> mentions the feature will be removed in M104, not M103. What's not clear is
> whether it would be possible to warn users if the feature flag is on and a
> website tries to use the Battery Status API in an http page, as adding
> something like [SecureContext=MyFeatureFlag] to the IDL files would prevent
> the code where the warning would go from even being reached if
> MyFeatureFlag is on.
>
> With that said, I guess it's up to the API owners to decide on the course
> here?
>
> On 26-04-2022 09:47, Mike West wrote:
>
> I'm less worried about this than Yoav is. Given the lack of support in any
> other browser, and the progressive-enhancement nature of this API, it's
> difficult for me to imagine embedded content visibly breaking at scale. If
> y'all do some spot-checking of the sites currently showing up through HTTP
> Archive, and have some evidence of the lack of user-visible breakage, I'd
> be comfortable without the additional complexity of percentage rollouts
> through Finch.
>
> If we do decide that that's necessary, we'll need to make sure that we
> have some sort of reasonable error message in the console so that the
> subset of developers who do experience some sort of breakage have a chance
> of understanding why.
>
> -mike
>
> On Monday, April 25, 2022 at 9:36:26 PM UTC+2 Yoav Weiss wrote:
>
>> I think it'd be better to add a feature flag disabled by default, and
>> then work with someone at Google to enable it on the server side for a
>> release, before enabling it in code.
>> That way it'd be easy to revert this in case this unexpectedly breaks
>> things.
>>
>> On Mon, Apr 25, 2022 at 5:00 PM Raphael Kubo da Costa <
>> raphael.kubo.da.co...@intel.com> wrote:
>>
>>> Thanks, Yoav. I've submitted
>>> https://chromium-review.googlesource.com/c/chromium/src/+/3605588 to
>>> implement this change. There's never been a feature flag for this though
>>> (in M99 we just added a deprecation warning), should I add one now?
>>>
>>> On 25-04-2022 16:40, Yoav Weiss wrote:
>>>
>>> The LGTMs you got on this thread should be enough. Please make sure to
>>> monitor any issues related to this, and revert if needed. (while keeping
>>> the feature flag around to enable urgent re-activation of this if breakage
>>> turns out to be untenable)
>>>
>>> On Thu, Apr 21, 2022 at 3:00 PM Raphael Kubo da Costa <
>>> raphael.kubo.da.co...@intel.com> wrote:
>>>
 Hi everyone,

 M103 is here, so I'd like to double-check if I can go ahead and stop
 exposing the Battery Status API to insecure origins as described below. The
 numbers in
 https://chromestatus.com/metrics/feature/timeline/popularity/2199
 remain flat (as explained, the percentage is pretty high but most of it
 comes from embedded https YouTube videos, trackers and RUM (real user
 monitoring) code in https pages.

 Do I start another thread and get new LGTMs for the actual removal?

 On 13-01-2022 16:09, Raphael Kubo Da Costa wrote:

 *Contact emails *raphael.kubo.da.co...@intel.com, reil...@chromium.org

 *Explainer*
 None

 *Specification *https://w3c.github.io/battery
 *Summary *Deprecate and remove the Battery Status API on insecure
 origins, such as HTTP pages or HTTPS iframes embedded in HTTP pages.
 *Blink component *Blink>BatteryStatus
 
 *Motivation *The Battery Status API allows web developers to have
 access to, among other things, a system's battery charging level and
 whether it is being charged. It is a powerful feature that has been around
 for over a decade and, as such, was originally designed with different
 security constraints.


 https://www.chromium.org/Home/chromium-security/deprecating-powerful-features-on-insecure-origins
 mentions how powerful features should not be exposed on insecure origins.
 We would like to add the [SecureContext] attribute to the spec's Web
 IDL so that navigator.getBattery() and the BatteryManager interface are
 only avail

Re: [blink-dev] Intent to Deprecate and Remove: Battery Status API in Insecure Origins

[Raphael Kubo da Costa]

I tend to agree with Mike here; none of the users of 
navigator.getBattery() in insecure contexts I checked in the past (via 
chromestatus.com) would break with this change, as they're all checking 
if it's available first (including the largest user so far, YouTube), 
which makes sense since other engines don't ship this API.


What I can do is write another CL that adds a new Blink runtime feature 
set to experimental and updates the current deprecation message and 
mentions the feature will be removed in M104, not M103. What's not clear 
is whether it would be possible to warn users if the feature flag is on 
and a website tries to use the Battery Status API in an http page, as 
adding something like [SecureContext=MyFeatureFlag] to the IDL files 
would prevent the code where the warning would go from even being 
reached if MyFeatureFlag is on.


With that said, I guess it's up to the API owners to decide on the 
course here?


On 26-04-2022 09:47, Mike West wrote:
I'm less worried about this than Yoav is. Given the lack of support in 
any other browser, and the progressive-enhancement nature of this API, 
it's difficult for me to imagine embedded content visibly breaking at 
scale. If y'all do some spot-checking of the sites currently showing 
up through HTTP Archive, and have some evidence of the lack of 
user-visible breakage, I'd be comfortable without the additional 
complexity of percentage rollouts through Finch.


If we do decide that that's necessary, we'll need to make sure that we 
have some sort of reasonable error message in the console so that the 
subset of developers who do experience some sort of breakage have a 
chance of understanding why.


-mike

On Monday, April 25, 2022 at 9:36:26 PM UTC+2 Yoav Weiss wrote:

I think it'd be better to add a feature flag disabled by default,
and then work with someone at Google to enable it on the server
side for a release, before enabling it in code.
That way it'd be easy to revert this in case this unexpectedly
breaks things.

On Mon, Apr 25, 2022 at 5:00 PM Raphael Kubo da Costa
mailto:raphael.kubo.da.co...@intel.com>> wrote:

Thanks, Yoav. I've submitted
https://chromium-review.googlesource.com/c/chromium/src/+/3605588

to implement this change. There's never been a feature flag
for this though (in M99 we just added a deprecation warning),
should I add one now?

On 25-04-2022 16:40, Yoav Weiss wrote:

The LGTMs you got on this thread should be enough. Please
make sure to monitor any issues related to this, and revert
if needed. (while keeping the feature flag around to enable
urgent re-activation of this if breakage turns out to be
untenable)

On Thu, Apr 21, 2022 at 3:00 PM Raphael Kubo da Costa
mailto:raphael.kubo.da.co...@intel.com>> wrote:

Hi everyone,

M103 is here, so I'd like to double-check if I can go
ahead and stop exposing the Battery Status API to
insecure origins as described below. The numbers in
https://chromestatus.com/metrics/feature/timeline/popularity/2199

remain flat (as explained, the percentage is pretty high
but most of it comes from embedded https YouTube videos,
trackers and RUM (real user monitoring) code in https pages.

Do I start another thread and get new LGTMs for the
actual removal?

On 13-01-2022 16:09, Raphael Kubo Da Costa wrote:


*Contact emails *raphael.kubo.da.co...@intel.com
,
reil...@chromium.org 


*Explainer*
None

*Specification *https://w3c.github.io/battery

*Summary *Deprecate and remove the Battery Status API on
insecure origins, such as HTTP pages or HTTPS iframes
embedded in HTTP pages.
*Blink component *Blink>BatteryStatus


*Motivation *The Battery Status API allows web
developers to have access to, among other things, a
system's battery charging level and whether it is being
charged. It is a powerful feature that has been around
for over a decade and, as such, was originally designed
with different security constraints.


https://www.chromium.org/Home/chromium-security/deprecating-powerful-features-on-insecure-origins

mentions
how powerful features should 

Re: [blink-dev] Re: Intent to Ship: Restrict Gamepad usage

['Artur Janc' via blink-dev]

Great, thanks for the update.

-A

On Thu, Apr 28, 2022 at 4:57 AM Matt Reynolds 
wrote:

> Yes, there will be a separate intent for the change to require a secure
> context. We're making this change first since it's not expected to break
> anything while the secure context change will break API access from
> non-secure contexts.
>
> I put together some notes on my current plans in Securing Gamepad API in
> Chrome
> 
>  and
> will update that if anything changes.
>
> - Matt
>
> On Wed, Apr 27, 2022 at 1:45 AM Artur Janc  wrote:
>
>> Hey folks,
>>
>> Can you share a little bit about your future plans to restrict the use of
>> Gamepad API? Implementing Permissions Policy integration sounds good, but
>> without the restriction to secure contexts and changing the default
>> allowlist to 'self' it doesn't seem like we're substantially locking down
>> the API. Are you planning to do this in subsequent intents?
>>
>> Thanks!
>> -Artur
>> On Tuesday, April 26, 2022 at 8:10:17 PM UTC+2 Matt Reynolds wrote:
>>
>>> Chrome 103
>>>
>>> On Mon, Apr 25, 2022 at 7:33 AM jmedley via Chromestatus <
>>> admin+...@cr-status.appspotmail.com> wrote:
>>>
 Which version of Chrome are you hoping to ship this in?

 --

>>> 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/39989e05dd7b742d%40google.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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPYVjqptiVH%3DGhimidzL%3DpcVXcTr_gtdQscmEeoHgyaDoxhfFA%40mail.gmail.com.

Re: [blink-dev] Intent to Experiment: Load common payloads from privacy-preserving single-keyed cache

[Adam Rice]

>
> Finch flag?


CacheTransparency (but the code is not landed yet).

On Thu, 28 Apr 2022 at 03:07, Joe Medley  wrote:

> Finch flag?
> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>  816-678-7195
> *If an API's not documented it doesn't exist.*
>
>
> On Wed, Apr 27, 2022 at 2:30 AM Adam Rice  wrote:
>
>> What is an 'off-by-default experiment'? Is that a dev trial flag?
>>
>>
>> Just an ordinary experiment, behind a flag which is off-by-default. So
>> most users get the default behaviour (no single-keyed cache), except for
>> those in the experimental group.
>>
>> On Wed, 27 Apr 2022 at 00:50, Joe Medley  wrote:
>>
>>> What is an 'off-by-default experiment'? Is that a dev trial flag?
>>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>>> 816-678-7195 <(816)%20678-7195>
>>> *If an API's not documented it doesn't exist.*
>>>
>>>
>>> On Tue, Apr 26, 2022 at 4:59 AM Daisuke Enomoto 
>>> wrote:
>>>
 Contact emails

 ri...@chromium.org, nidhij...@chromium.org, denom...@chromium.org

 Explainer


 https://docs.google.com/document/d/1pvaMg7J5beBXD7trzHJH_MDULc_wRHLx40MFYAmjknE/edit

 Specification

 N/A (because there are no web-exposed changes)

 Summary

 This limited experiment measures how much "pervasive payloads"
 contribute to the performance impact of the split HTTP cache in each Chrome
 channel over a three-week period. Pervasive payloads are those third-party
 payloads included on at least 500 sites and fetched at least 10M times in a
 month, based on Chrome's analysis (payload list included below). This
 experiment further measures the impact on Core Web Vitals metrics of
 restoring pervasive payloads (and only pervasive payloads) to a
 single-keyed cache regime. The privacy benefits of the split HTTP cache are
 preserved.

 Blink component

 Blink>Network
 

 Motivation

 Browsers split HTTP caches based on the top-frame visited origin
 (“double-keyed” or "triple-keyed" caching) to prevent sites from tracking
 users via a timing attack on a cross-site client cache.

 Chrome’s analysis estimates that split caching results in a 3% increase
 in cache misses, i.e. fetches for which a payload exists in the cache of
 the user's device, but is unavailable to the page because it was fetched by
 the user while loading a page from a different origin. This results in
 approximately 4% more total bytes being fetched over the network.

 Our analysis further revealed that many of the redundant fetches caused
 by split caching were for common payloads associated with displaying user
 content (libraries, fonts, widgets, ads) or common payloads that assist in
 operating online businesses (analytics). The delayed arrival of these
 common payloads resulted in visible "jank" for users, impacting performance
 metrics like LCP , FCP  and
 CLS . This jank has been associated with
 negative effects to online business' engagement and conversion rates.
 Furthermore, delayed loads of analytics and ads payloads can result in
 missed ads impressions and dropped analytics hits.

 Initial public proposal

 This experiment sends a list to Chrome of 100  pairs whose
 payloads are considered pervasive (the "pervasive payloads list"). During
 the three-week experiment period, if Chrome fetches a payload that matches
 both the URL and its hash on the pervasive payloads list, it is inserted
 into a local single-keyed cache. This payload is then available for use by
 Chrome when loading pages on other sites that include the matching URL. All
 other fetches for URLs not on the pervasive payloads list are cached
 according to the existing split HTTP cache.

 The hash covers the payload body and most response headers, except for
 those which change on every response.

 To ensure we do not degrade the privacy profile of any users during
 this experiment, only users with third-party cookies currently enabled will
 be eligible for the experiment. We will compare the experience of users in
 experiment and control arms according to total bytes loaded and page
 performance metrics like the Core Web Vitals .

 The pervasive payloads list was produced by crawling the web and
 aggregating the most commonly referenced third-party resource URLs included
 in HTML content. We then used pseudonymous URL-keyed metrics from Chrome to
 estimate the traffic to sites and the number of impressions of third-party
 resources. Individually identifiable browsing or search histories were not
 used in the creation of the pervasive payload list (for mo