[blink-dev] Re: Intent to Experiment: Shared Storage API

[Yoav Weiss]

LGTM to experiment, starting from M104.

On Wed, Jun 15, 2022 at 11:52 PM Josh Karlin  wrote:

>
> On Wed, Jun 15, 2022 at 5:02 AM Yoav Weiss  wrote:
>
>>
>>
>> On Friday, June 10, 2022 at 10:54:51 PM UTC+2 Josh Karlin wrote:
>>
>>> Contact emailscam...@chromium.org, yao...@chromium.org,
>>> erictrou...@chromium.org, jkar...@chromium.org ExplainerExplainer
>>>  (WICG proposal
>>> ) SpecificationTBD 
>>> SummaryShared
>>> Storage allows for unpartitioned storage (i.e. not partitioned by top-frame
>>> as is planned for other types of storage) that may only be read in a secure
>>> environment with carefully constructed output gates. This API is intended
>>> to support many cross-site use cases on the web while significantly
>>> decreasing cross-site user tracking.
>>>
>>> This I2E is for Shared Storage's first output gate, called selectURL. It
>>> allows Shared Storage to be used to select from a short list of URLS to be
>>> displayed in a Fenced Frame. Gates related to aggregate reporting will
>>> follow in future experiments.
>>>  Blink componentBlink>Storage
>>> 
>>> >SharedStorage TAG review
>>> https://github.com/w3ctag/design-reviews/issues/747 TAG review status
>>> Pending Risks Interoperability and Compatibility  Gecko/Webkit: No
>>> signal as we're first in the process of moving this into a community group.
>>>Web developers: No signals Other signals: WebView application risksDoes
>>> this intent deprecate or change behavior of existing APIs, such that it has
>>> potentially high risk for Android WebView-based applications?
>>>
>>>   No.
>>>   Goals for experimentationThe intent is for experimenters to try out
>>> Shared Storage and see how well it works for them. We expect there to be
>>> utility trade-offs and bumps along the road toward optimizing privacy. We
>>> also expect it may be necessary to change budgeting parameters and we
>>> intend to add new output gate algorithms along the way. So please
>>> experiment and provide feedback on the issue tracker to help us improve the
>>> API. Experiment ConfigurationThe origin trial for this experiment is
>>> shared among various Privacy Sandbox APIs. Our goal is to allow for
>>> coordinated experiments to be run by multiple different sites, across
>>> multiple APIs in one OT. This shared origin trial, Privacy Sandbox Ads
>>> APIs, is a third-party origin trial. To ensure that developers can run
>>> coordinated experiments without concern for exceeding page load usage
>>> thresholds, this Origin Trial is available for a subset of users by
>>> default. Therefore, it will be necessary to feature test to ensure that the
>>> API surface you want to use is available after providing your OT token. A
>>> second advantage of this configuration is that different experimenters will
>>> experiment with the same users, which enables coordination for APIs like
>>> FLEDGE across third parties.  Ongoing technical constraints
>>> As mentioned above, this experiment includes only the selectURL output
>>> gate of SharedStorage. We will follow up with aggregate reporting gates in
>>> future releases.
>>>
>>>
>>> DebuggabilityThere are no particular debugging APIs made available or
>>> Chrome DevTools integrations for this OT. Will this feature be
>>> supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS,
>>> Android, and Android WebView)?All but WebView. Is this feature fully
>>> tested by web-platform-tests
>>> 
>>> ?Internal platform tests exist, but they’re internal-only until we’re
>>> able to make the fenced frames test infrastructure external. Flag nameOn
>>> M104 or greater, the API can be enabled from
>>> `chrome://flags/#privacy-sandbox-ads-apis`, or by activating the
>>> `SharedStorageAPI`, `FencedFrames`, and `PrivacySandboxAdsAPIsOverride`
>>> features. Requires code in //chrome?Only for permission checks. Tracking
>>> bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1218540 Launch
>>> bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1218535 Estimated
>>> milestonesWe intend to begin experimenting in M104 as part of the Privacy
>>> Sandbox APIs Origin Trial
>>> 
>>> .
>>>
>>
>> What are the timelines for running the experiment? M104 till?
>>
>
> Hi Yoav,
>
> It's tied to the lifetime of the larger Privacy Sandbox Ads APIs OT, which
> is currently set to end in M104 although we anticipate asking for an
> extension soon to facilitate additional testing.
>

Makes sense!


>
>
>
>
>
>>
>>
>>>  Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/6256348582903808 This intent message
>>> was generated by Chrome Platform Status .
>>>

Re: [blink-dev] Is "Keyboard-focusable scroll containers" still in development?

[Xiaocheng Hu]

Hi Benjamin,

Last time it was unshipped due to breaking Web UI.

This is currently tracked by crbug.com/1040141 and owned by the DOM team.

I'll update the chromestatus.com entry accordingly.

On Wed, Jun 15, 2022 at 2:46 PM 'Benjamin Beaudry' via blink-dev <
blink-dev@chromium.org> wrote:

> Hi all,
>
> Is this feature still in development? Keyboard-focusable scroll
> containers - Chrome Platform Status (chromestatus.com)
> 
> It's currently sitting behind the runtime flag KeyboardFocusableScrollers,
> and it looks like it hasn't been modified in the last 4 years. I think the
> owner of that feature is not around anymore, so I'm wondering if someone
> picked it up or if it's just abandoned.
>
> Thanks,
> Ben
>
> --
> 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/CH2PR00MB08280D0E4086BCB206E809649BAD9%40CH2PR00MB0828.namprd00.prod.outlook.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/CAFqEGhbaQNc9SW%2BWrm3ST2qENu4Sdg29sRRkc39t9DazhPKEeA%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: Writable directory prompts for the File System Access API

[Joshua Bell]

Since this is an incremental addition to the existing FSA API, my guess is
that the positions there sufficient here:

Gecko: https://mozilla.github.io/standards-positions/#native-file-system
Webkit:
https://lists.webkit.org/pipermail/webkit-dev/2020-August/031362.html

These two engines give a Negative signal. I would not expect they would
comment further on this incremental addition.



On Wed, Jun 15, 2022 at 8:06 AM 'Austin Sullivan' via blink-dev <
blink-dev@chromium.org> wrote:

> No, I did not realize this was required? showDirectoryPicker() is
> currently only implemented for Chromium browsers
>
> On Wed, Jun 15, 2022 at 7:55 AM Yoav Weiss  wrote:
>
>>
>>
>> On Monday, June 13, 2022 at 1:58:43 PM UTC+2 Austin Sullivan wrote:
>>
>>> Contact emailsasu...@chromium.org
>>>
>>> ExplainerNone
>>>
>>> Specificationhttps://github.com/WICG/file-system-access/pull/300
>>>
>>> Summary
>>>
>>> Allow returning a directory with both read and write permissions in a
>>> single prompt for the File System Access API. Currently
>>> showDirectoryPicker() always returns a read-only directory (after showing a
>>> read access prompt), requiring a second permission prompt to get write
>>> access. This double-prompt is a poor user experience and contributes to
>>> confusion and permission fatigue among users.
>>>
>>>
>>> Adds an optional "mode" option to DirectoryPickerOptions which can be
>>> specified as "read" or "readwrite".
>>>
>>>
>>> Blink componentBlink>Storage>FileSystem
>>> 
>>>
>>> TAG reviewWe did not seek a TAG review given the small scope of this
>>> feature. This launch does not add any new capabilities, but merely provides
>>> the browser with enough information to combine two permission prompts into
>>> one.
>>>
>>
We have filed TAG design review requests for incremental additions to the
FSA API (examples: 1 ,
2 , 3
) - I think it's worth
doing here as well, although I expect support since it's following existing
patterns (using an enum value in an options dictionary, with a
reasonable/safe default).



>
>>> TAG review statusN/A
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>>
>>>
>>> *Gecko*: No signal
>>>
>>> *WebKit*: No signal
>>>
>>
>> Have you asked for signals? https://bit.ly/blink-signals
>>
>>
>>>
>>> *Web developers*: Strongly positive (
>>> https://github.com/WICG/file-system-access/issues/89)
>>>
>>> *Other signals*:
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such
>>> that it has potentially high risk for Android WebView-based applications?
>>>
>>> No
>>>
>>>
>>>
>>> Debuggability
>>>
>>> N/A
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?No - The File System
>>> Access API is not supported on Android
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?No
>>>
>>> Flag name
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bughttps://crbug.com/1115632
>>>
>>> Launch bughttps://crbug.com/1213159
>>>
>>> Estimated milestones
>>>
>>> 105
>>>
>>>
>>> Anticipated spec changes
>>>
>>> Open questions about a feature may be a source of future web compat or
>>> interop issues. Please list open issues (e.g. links to known github issues
>>> in the project for the feature specification) whose resolution may
>>> introduce web compat/interop risk (e.g., changing to naming or structure of
>>> the API in a non-backward-compatible way).
>>>
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/6383970247770112
>>>
>>> This intent message was generated by Chrome Platform Status
>>> .
>>>
>> --
> 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/CADs-7rEsYumZp%3Dd9VuzMixOq5xB7kD0HxrQ2QwYvLM_K%2B7LaLw%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+unsubscr...@chromium.org.
To view this discussion on the web visit 

RE: [blink-dev] Intent to Ship: Custom Highlight API

['Daniel Clark' via blink-dev]

> What's the feature detection/activation story here? Can developers use the 
> feature while it's partially supported? What would be the implications of 
> that?

Feature detection can be done by checking for the presence of CSS.highlights:

function supportsHighlightAPI() {
  return !!CSS.highlights;
}

For use cases where the highlights are key to the user experience (e.g. when 
used for an app's custom find-on-page implementation), developers should fall 
back to a polyfill for unsupported browsers. For use cases where highlights are 
only added for stylistic purposes, they could be omitted altogether when there 
isn't support.

A polyfill could be built for the feature that works by wrapping "highlighted" 
content in styled spans. This could get tricky to implement for cases involving 
many nested highlights (which is one thing that the API makes much easier), but 
it would work fine for most scenarios.

> We could send a ping notifying that Chromium is planning to ship.

I pinged the mozilla/standards-positions thread about this last week, still 
waiting to hear back 
https://github.com/mozilla/standards-positions/issues/482#issuecomment-1152601522.
 @Emilio, is there anything you'd be able to share 
about this?

> Can you ask for an explicit signal to see what their plans are on that front? 
> Is there an interop risk from their incomplete implementation?

I sent a 
mail to 
webkit-dev, awaiting response. I just took another look at their 
implementation, and they've done some work to bring it closer to the current 
state of the spec since last I checked. The remaining major difference I see is 
just the lack of support for live Ranges. I expect that they will close this 
gap prior to shipping the feature. If they don't then the difference could also 
be feature-detected by polyfills:

function supportsLiveRangeHighlights() {
  try {
new Highlight(new Range());
return true;
  } catch(ex) {
return false;
  };
}

-- Dan

From: Yoav Weiss 
Sent: Wednesday, June 15, 2022 1:32 AM
To: blink-dev 
Cc: Manuel Rego ; Sanket Joshi (EDGE) ; 
Fernando Fiori ; Bo Cupp ; Luis Juan 
Sanchez Padilla ; Delan Azabani 
; Emilio Cobos Alvarez ; Rick Byers 
; flo...@rivoal.net ; Daniel Clark 

Subject: Re: [blink-dev] Intent to Ship: Custom Highlight API


On Thursday, June 9, 2022 at 6:55:06 AM UTC+2 Manuel Rego wrote:
I'm biased here as I've been working on this feature myself, so I cannot
give an official LGTM.

Thanks for all the work since the previous intent thread, I believe this
is now in a way better status to ship.

I'd be fine giving a LGTM with the following caveats:
* As mentioned at the end of the email, HighlightOverlayPainting flag
gets enabled before shipping this (that flag fixes lots of bugs
regarding paining of CSS highlight pseudos).
* The following CSSWG issue gets resolved:
https://github.com/w3c/csswg-drafts/issues/6774
It looks like there's an agreement already but it'd be nice to confirm
it, as this might change behavior if a different decision is made.

Other than that I've just some minor comments inline.

On 08/06/2022 19:42, 'Daniel Clark' via blink-dev wrote:
> Risks
>
>
> Interoperability and Compatibility
>
> Low risk: This feature received positive support from Safari and Firefox
> at TPAC 2019. Safari is implementing it, Firefox has not yet made any
> clear indication on implementation.

What's the feature detection/activation story here? Can developers use the 
feature while it's partially supported? What would be the implications of that?


>
>
>
> /Gecko/: No clear signal
> (https://github.com/mozilla/standards-positions/issues/482
> 

[blink-dev] Re: Intent to Experiment: Shared Storage API

[Josh Karlin]

On Wed, Jun 15, 2022 at 5:02 AM Yoav Weiss  wrote:

>
>
> On Friday, June 10, 2022 at 10:54:51 PM UTC+2 Josh Karlin wrote:
>
>> Contact emailscam...@chromium.org, yao...@chromium.org,
>> erictrou...@chromium.org, jkar...@chromium.org ExplainerExplainer
>>  (WICG proposal
>> ) SpecificationTBD SummaryShared
>> Storage allows for unpartitioned storage (i.e. not partitioned by top-frame
>> as is planned for other types of storage) that may only be read in a secure
>> environment with carefully constructed output gates. This API is intended
>> to support many cross-site use cases on the web while significantly
>> decreasing cross-site user tracking.
>>
>> This I2E is for Shared Storage's first output gate, called selectURL. It
>> allows Shared Storage to be used to select from a short list of URLS to be
>> displayed in a Fenced Frame. Gates related to aggregate reporting will
>> follow in future experiments.
>>  Blink componentBlink>Storage
>> 
>> >SharedStorage TAG review
>> https://github.com/w3ctag/design-reviews/issues/747 TAG review status
>> Pending Risks Interoperability and Compatibility  Gecko/Webkit: No
>> signal as we're first in the process of moving this into a community group.
>>Web developers: No signals Other signals: WebView application risksDoes
>> this intent deprecate or change behavior of existing APIs, such that it has
>> potentially high risk for Android WebView-based applications?
>>
>>   No.
>>   Goals for experimentationThe intent is for experimenters to try out
>> Shared Storage and see how well it works for them. We expect there to be
>> utility trade-offs and bumps along the road toward optimizing privacy. We
>> also expect it may be necessary to change budgeting parameters and we
>> intend to add new output gate algorithms along the way. So please
>> experiment and provide feedback on the issue tracker to help us improve the
>> API. Experiment ConfigurationThe origin trial for this experiment is
>> shared among various Privacy Sandbox APIs. Our goal is to allow for
>> coordinated experiments to be run by multiple different sites, across
>> multiple APIs in one OT. This shared origin trial, Privacy Sandbox Ads
>> APIs, is a third-party origin trial. To ensure that developers can run
>> coordinated experiments without concern for exceeding page load usage
>> thresholds, this Origin Trial is available for a subset of users by
>> default. Therefore, it will be necessary to feature test to ensure that the
>> API surface you want to use is available after providing your OT token. A
>> second advantage of this configuration is that different experimenters will
>> experiment with the same users, which enables coordination for APIs like
>> FLEDGE across third parties.  Ongoing technical constraints
>> As mentioned above, this experiment includes only the selectURL output
>> gate of SharedStorage. We will follow up with aggregate reporting gates in
>> future releases.
>>
>>
>> DebuggabilityThere are no particular debugging APIs made available or
>> Chrome DevTools integrations for this OT. Will this feature be supported
>> on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and
>> Android WebView)?All but WebView. Is this feature fully tested by
>> web-platform-tests
>> 
>> ?Internal platform tests exist, but they’re internal-only until we’re
>> able to make the fenced frames test infrastructure external. Flag nameOn
>> M104 or greater, the API can be enabled from
>> `chrome://flags/#privacy-sandbox-ads-apis`, or by activating the
>> `SharedStorageAPI`, `FencedFrames`, and `PrivacySandboxAdsAPIsOverride`
>> features. Requires code in //chrome?Only for permission checks. Tracking
>> bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1218540 Launch
>> bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1218535 Estimated
>> milestonesWe intend to begin experimenting in M104 as part of the Privacy
>> Sandbox APIs Origin Trial
>> 
>> .
>>
>
> What are the timelines for running the experiment? M104 till?
>

Hi Yoav,

It's tied to the lifetime of the larger Privacy Sandbox Ads APIs OT, which
is currently set to end in M104 although we anticipate asking for an
extension soon to facilitate additional testing.





>
>
>>  Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/6256348582903808 This intent message
>> was generated by Chrome Platform Status .
>>
>

-- 
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] Is "Keyboard-focusable scroll containers" still in development?

['Benjamin Beaudry' via blink-dev]

Hi all,

Is this feature still in development? Keyboard-focusable scroll containers - 
Chrome Platform Status 
(chromestatus.com)
It's currently sitting behind the runtime flag KeyboardFocusableScrollers, and 
it looks like it hasn't been modified in the last 4 years. I think the owner of 
that feature is not around anymore, so I'm wondering if someone picked it up or 
if it's just abandoned.

Thanks,
Ben

-- 
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/CH2PR00MB08280D0E4086BCB206E809649BAD9%40CH2PR00MB0828.namprd00.prod.outlook.com.

[blink-dev] Re: Intent to Ship: forced-color-adjust: preserve-parent-color

[Sara Tang]

Hi, reviving this thread as the CSSWG resolution at [css-color] 
[css-color-adjust] Make system colors fully resolve (but flag they were 
system colors) thus reversing the resolution of #3847 · Issue #6773 · 
w3c/csswg-drafts (github.com) 
  has been reached (though 
the standards posiiton for this particular feature hasn't been updated 
yet).  preserve-parent-color value for forced-color-adjust CSS property · 
Issue #591 · mozilla/standards-positions (github.com) 
.

To summarize,
  - If both system colors and forced colors were resolved at compute time, 
`preserve-parent-color` would not be needed. This is similar to Mozilla, 
which gets the behavior of `preserve-parent-color` "for free".
  - The resolution of #6773 is to resolve system colors at compute time. 
Forced color are still resolved at used value time.
  - Thus, `preserve-parent-color` is still needed.

I believe we should now be unblocked to ship `preserve-parent-color` :)

Sara


On Sunday, November 21, 2021 at 1:10:54 PM UTC-8 Danny Holly wrote:

> cause no harm
>
> On Thursday, October 28, 2021 at 4:45:04 PM UTC-5 Sara Tang wrote:
>
>> Contact emails sar...@microsoft.com, alison...@microsoft.com
>>
>> Explainer 
>> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Accessibility/PreserveParentColor/explainer.md
>>
>> Specification 
>> https://www.w3.org/TR/css-color-adjust-1/#forced-color-adjust-prop
>>
>> Summary 
>>
>> Adds the ‘preserve-parent-color' value to the ‘forced-color-adjust' CSS 
>> property. When Forced Colors Mode is enabled, the ‘color’ property is 
>> inherited, and we’ve set ‘forced-color-adjust: preserve-parent-color', the 
>> ‘color’ property will compute to the used value of its parent. Otherwise, 
>> ‘forced-color-adjust: preserve-parent-color' value behaves the same as 
>> ‘forced-color-adjust: none’.
>>
>> Contact emails sar...@microsoft.com, alison...@microsoft.com
>>
>> Explainer 
>> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Accessibility/PreserveParentColor/explainer.md
>>
>> Specification 
>> https://www.w3.org/TR/css-color-adjust-1/#forced-color-adjust-prop
>>
>> Summary 
>>
>> Adds the ‘preserve-parent-color' value to the ‘forced-color-adjust' CSS 
>> property. When Forced Colors Mode is enabled, the ‘color’ property is 
>> inherited, and we’ve set ‘forced-color-adjust: preserve-parent-color', the 
>> ‘color’ property will compute to the used value of its parent. Otherwise, 
>> ‘forced-color-adjust: preserve-parent-color' value behaves the same as 
>> ‘forced-color-adjust: none’.
>>
>> *Motivation*
>>
>> * ‘forced-color-adjust' is a CSS property that allows developers to opt 
>> out of Forced Colors Mode.  Previously, there were 
>> two supported values: ‘auto’ and ‘none’, which can be used to 
>> control whether or not an element’s styles are adjusted by the UA in Forced 
>> Colors Mode. A third value, ‘preserve-parent-color', has recently been 
>> introduced in the spec, which provides similar behavior to ‘none’, 
>> except that it also allows an element to inherit its parent's 
>> used ‘color’ value. In other words, ‘preserve-parent-color' provides the 
>> ability for an element to inherit its parent’s Forced Colors Mode 
>> adjusted ‘color’ value.  The intention of ‘preserve-parent-color’ is to get 
>> a reasonable behavior for SVG icons that utilize ‘currentColor’ when 
>> styling ‘fill’ and ‘stroke’ in Forced Colors Mode, 
>> as described in [css-color-adjust-1] Spec currently breaks use of 
>> currentColor for SVG icons in WHCM · Issue #6310 · w3c/csswg-drafts · 
>> GitHub .  The use of 
>> ‘currentColor’ when styling an SVG icon is a common pattern used by authors 
>> to ensure an accessible experience in Forced Colors Mode. For example, in 
>> this sample logo,  an author 
>> would expect the logo to automatically adjust to use the ‘CanvasText’ 
>> system color for ‘fill’ and ‘stroke’ in Forced Colors Mode, as a result of 
>> setting each to ‘currentColor’.   This behavior, 
>> however, became broken when we moved from forcing colors at computed value 
>> time to used value time: [css-color-adjust-1] Is forced color computed or 
>> used value? · Issue #4915 · w3c/csswg-drafts · GitHub 
>> . Instead of inheriting 
>> ‘CanvasText’, as before, the above sample logo 
>>  would inherit the computed 
>> ‘color’ value of its parent, resulting in a logo that is no longer readable 
>> in Forced Colors Mode.  The new ‘preserve-parent-color' value was added to 
>> address this common SVG use case. By changing the default value of 
>> ‘forced-color-adjust’ for SVGs from ‘none’ to ‘preserve-parent-color', SVG 
>> icons that make use of ‘currentColor’ will now inherit the used ‘color’ 
>> value 

Re: [blink-dev] Intent to ship: Picture-in-Picture (Android)

[Chris Harrelson]

LGTM3

On Wed, Jun 15, 2022 at 8:53 AM Daniel Bratell  wrote:

> LGTM2
>
> /Daniel
> On 2022-06-15 10:01, Yoav Weiss wrote:
>
> LGTM1
>
> On Tue, Jun 14, 2022 at 6:00 PM 'François Beaufort ' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emails
>>
>> fbeauf...@chromium.org, liber...@chromium.org
>>
>> Explainer
>>
>> https://github.com/w3c/picture-in-picture/blob/main/explainer.md
>>
>> Specification
>>
>> https://w3c.github.io/picture-in-picture/
>>
>> Summary
>>
>> The Picture-in-Picture API allows websites to create a floating video
>> window that is always on top of other windows so that users may continue
>> consuming media while they interact with other sites or applications on
>> their device. This change only applies to  elements.
>>
>> Blink component
>>
>> Blink>Media>PictureInPicture
>> 
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/226
>>
>> TAG review status
>>
>> Issues addressed
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> Gecko: Defer (
>> https://mozilla.github.io/standards-positions/#picture-in-picture)
>>
>> WebKit: Positive - Shipped in Safari 13.1 (
>> https://developer.apple.com/documentation/safari-release-notes/safari-13_1-release_notes
>> )
>>
>> Web developers: Positive - Media players have adopted Picture-in-Picture
>> (VideoJS , Shaka Player
>> 
>> )
>>
>> Other signals:
>>
>> WebView application risks
>>
>> None
>>
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?
>>
>> No. Android WebView is still not supported.
>>
>> This feature was previously shipped for Windows, Mac, Linux, and Chrome
>> OS in 2018.
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/ibVPbqBQapU/m/eMblkidrAgAJ
>>
>> This intent is about requesting approval to ship on Android
>> http://crbug.com/964373
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> Yes. https://wpt.fyi/results/picture-in-picture
>> 
>>
>> Requires code in //chrome?
>>
>> Yes
>>
>> Tracking bug
>>
>> http://crbug.com/964373
>>
>> Sample links
>>
>> https://googlechrome.github.io/samples/picture-in-picture/
>>
>> Estimated milestones
>>
>> 105
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5729206566649856
>>
>> Links to previous Intent discussions
>>
>> Intent to Ship:
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/ibVPbqBQapU/m/eMblkidrAgAJ
>> --
>> 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/CAPpwU5%2BFP_C6D6eHMoUH0ARms8hmKW5icnXb_1UWTChJJOPt0w%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+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVhH1sQi4Y_zo6N%3DLDC908avWd3CQVjK%3DtXRs-4qaBzgw%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+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1694-c0d9-0926-5c15-4bba46b5ad9c%40gmail.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/CAOMQ%2Bw-UxJrPu%3DZsTLrf4vVTQVZgCse-_zQ5FUaDj0b6c7-EUg%40mail.gmail.com.

Re: [blink-dev] Intent to ship: Picture-in-Picture (Android)

[Daniel Bratell]

LGTM2

/Daniel

On 2022-06-15 10:01, Yoav Weiss wrote:

LGTM1

On Tue, Jun 14, 2022 at 6:00 PM 'François Beaufort ' via blink-dev 
 wrote:



Contact emails

fbeauf...@chromium.org, liber...@chromium.org


Explainer

https://github.com/w3c/picture-in-picture/blob/main/explainer.md



Specification

https://w3c.github.io/picture-in-picture/



Summary

The Picture-in-Picture API allows websites to create a floating
video window that is always on top of other windows so that users
may continue consuming media while they interact with other sites
or applications on their device. This change only applies to
 elements.


Blink component

Blink>Media>PictureInPicture




TAG review

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



TAG review status

Issues addressed


Risks



Interoperability and Compatibility


Gecko: Defer
(https://mozilla.github.io/standards-positions/#picture-in-picture
)


WebKit: Positive - Shipped in Safari 13.1

(https://developer.apple.com/documentation/safari-release-notes/safari-13_1-release_notes

)


Web developers: Positive - Media players have adopted
Picture-in-Picture (VideoJS
, Shaka Player
)



Other signals:


WebView application risks

None




Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, Chrome OS, Android, and Android
WebView)?

No. Android WebView is still not supported.

This feature was previously shipped for Windows, Mac, Linux, and
Chrome OS in 2018.

https://groups.google.com/a/chromium.org/g/blink-dev/c/ibVPbqBQapU/m/eMblkidrAgAJ




This intent is about requesting approval to ship on Android
http://crbug.com/964373 


Is this feature fully tested by web-platform-tests

?

Yes. https://wpt.fyi/results/picture-in-picture




Requires code in //chrome?

Yes


Tracking bug

http://crbug.com/964373 


Sample links

https://googlechrome.github.io/samples/picture-in-picture/



Estimated milestones

105


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5729206566649856



Links to previous Intent discussions

Intent to Ship:

https://groups.google.com/a/chromium.org/g/blink-dev/c/ibVPbqBQapU/m/eMblkidrAgAJ



-- 
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/CAPpwU5%2BFP_C6D6eHMoUH0ARms8hmKW5icnXb_1UWTChJJOPt0w%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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVhH1sQi4Y_zo6N%3DLDC908avWd3CQVjK%3DtXRs-4qaBzgw%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+unsubscr...@chromium.org.
To view this 

[blink-dev] Re: Intent to Ship: Writable directory prompts for the File System Access API

['Austin Sullivan' via blink-dev]

No, I did not realize this was required? showDirectoryPicker() is currently
only implemented for Chromium browsers

On Wed, Jun 15, 2022 at 7:55 AM Yoav Weiss  wrote:

>
>
> On Monday, June 13, 2022 at 1:58:43 PM UTC+2 Austin Sullivan wrote:
>
>> Contact emailsasu...@chromium.org
>>
>> ExplainerNone
>>
>> Specificationhttps://github.com/WICG/file-system-access/pull/300
>>
>> Summary
>>
>> Allow returning a directory with both read and write permissions in a
>> single prompt for the File System Access API. Currently
>> showDirectoryPicker() always returns a read-only directory (after showing a
>> read access prompt), requiring a second permission prompt to get write
>> access. This double-prompt is a poor user experience and contributes to
>> confusion and permission fatigue among users.
>>
>>
>> Adds an optional "mode" option to DirectoryPickerOptions which can be
>> specified as "read" or "readwrite".
>>
>>
>> Blink componentBlink>Storage>FileSystem
>> 
>>
>> TAG reviewWe did not seek a TAG review given the small scope of this
>> feature. This launch does not add any new capabilities, but merely provides
>> the browser with enough information to combine two permission prompts into
>> one.
>>
>> TAG review statusN/A
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>>
>>
>> *Gecko*: No signal
>>
>> *WebKit*: No signal
>>
>
> Have you asked for signals? https://bit.ly/blink-signals
>
>
>>
>> *Web developers*: Strongly positive (
>> https://github.com/WICG/file-system-access/issues/89)
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> No
>>
>>
>>
>> Debuggability
>>
>> N/A
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?No - The File System
>> Access API is not supported on Android
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?No
>>
>> Flag name
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://crbug.com/1115632
>>
>> Launch bughttps://crbug.com/1213159
>>
>> Estimated milestones
>>
>> 105
>>
>>
>> Anticipated spec changes
>>
>> Open questions about a feature may be a source of future web compat or
>> interop issues. Please list open issues (e.g. links to known github issues
>> in the project for the feature specification) whose resolution may
>> introduce web compat/interop risk (e.g., changing to naming or structure of
>> the API in a non-backward-compatible way).
>>
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/6383970247770112
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>

-- 
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/CADs-7rEsYumZp%3Dd9VuzMixOq5xB7kD0HxrQ2QwYvLM_K%2B7LaLw%40mail.gmail.com.

[blink-dev] Re: Intent to Ship: Writable directory prompts for the File System Access API

[Yoav Weiss]

On Monday, June 13, 2022 at 1:58:43 PM UTC+2 Austin Sullivan wrote:

> Contact emailsasu...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://github.com/WICG/file-system-access/pull/300
>
> Summary
>
> Allow returning a directory with both read and write permissions in a 
> single prompt for the File System Access API. Currently 
> showDirectoryPicker() always returns a read-only directory (after showing a 
> read access prompt), requiring a second permission prompt to get write 
> access. This double-prompt is a poor user experience and contributes to 
> confusion and permission fatigue among users.
>
>
> Adds an optional "mode" option to DirectoryPickerOptions which can be 
> specified as "read" or "readwrite".
>
>
> Blink componentBlink>Storage>FileSystem 
> 
>
> TAG reviewWe did not seek a TAG review given the small scope of this 
> feature. This launch does not add any new capabilities, but merely provides 
> the browser with enough information to combine two permission prompts into 
> one. 
>
> TAG review statusN/A
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>

Have you asked for signals? https://bit.ly/blink-signals
 

>
> *Web developers*: Strongly positive (
> https://github.com/WICG/file-system-access/issues/89)
>
> *Other signals*:
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that 
> it has potentially high risk for Android WebView-based applications?
>
> No
>
>
>
> Debuggability
>
> N/A
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, Chrome OS, Android, and Android WebView)?No - The File System 
> Access API is not supported on Android
>
> Is this feature fully tested by web-platform-tests 
> 
> ?No
>
> Flag name
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/1115632
>
> Launch bughttps://crbug.com/1213159
>
> Estimated milestones
>
> 105
>
>
> Anticipated spec changes
>
> Open questions about a feature may be a source of future web compat or 
> interop issues. Please list open issues (e.g. links to known github issues 
> in the project for the feature specification) whose resolution may 
> introduce web compat/interop risk (e.g., changing to naming or structure of 
> the API in a non-backward-compatible way).
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/6383970247770112
>
> This intent message was generated by Chrome Platform Status 
> .
>

-- 
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/6629a5b6-2256-4358-8453-7f241ccd9295n%40chromium.org.

[blink-dev] Re: Intent to Experiment: Shared Storage API

[Yoav Weiss]

On Friday, June 10, 2022 at 10:54:51 PM UTC+2 Josh Karlin wrote:

> Contact emailscam...@chromium.org, yao...@chromium.org, 
> erictrou...@chromium.org, jkar...@chromium.org ExplainerExplainer 
>  (WICG proposal 
> ) SpecificationTBD SummaryShared 
> Storage allows for unpartitioned storage (i.e. not partitioned by top-frame 
> as is planned for other types of storage) that may only be read in a secure 
> environment with carefully constructed output gates. This API is intended 
> to support many cross-site use cases on the web while significantly 
> decreasing cross-site user tracking.
>
> This I2E is for Shared Storage's first output gate, called selectURL. It 
> allows Shared Storage to be used to select from a short list of URLS to be 
> displayed in a Fenced Frame. Gates related to aggregate reporting will 
> follow in future experiments. 
>  Blink componentBlink>Storage 
> 
> >SharedStorage TAG review
> https://github.com/w3ctag/design-reviews/issues/747 TAG review status
> Pending Risks Interoperability and Compatibility  Gecko/Webkit: No signal 
> as we're first in the process of moving this into a community group.   Web 
> developers: No signals Other signals: WebView application risksDoes this 
> intent deprecate or change behavior of existing APIs, such that it has 
> potentially high risk for Android WebView-based applications?
>
>   No.
>   Goals for experimentationThe intent is for experimenters to try out 
> Shared Storage and see how well it works for them. We expect there to be 
> utility trade-offs and bumps along the road toward optimizing privacy. We 
> also expect it may be necessary to change budgeting parameters and we 
> intend to add new output gate algorithms along the way. So please 
> experiment and provide feedback on the issue tracker to help us improve the 
> API. Experiment ConfigurationThe origin trial for this experiment is 
> shared among various Privacy Sandbox APIs. Our goal is to allow for 
> coordinated experiments to be run by multiple different sites, across 
> multiple APIs in one OT. This shared origin trial, Privacy Sandbox Ads 
> APIs, is a third-party origin trial. To ensure that developers can run 
> coordinated experiments without concern for exceeding page load usage 
> thresholds, this Origin Trial is available for a subset of users by 
> default. Therefore, it will be necessary to feature test to ensure that the 
> API surface you want to use is available after providing your OT token. A 
> second advantage of this configuration is that different experimenters will 
> experiment with the same users, which enables coordination for APIs like 
> FLEDGE across third parties.  Ongoing technical constraints
> As mentioned above, this experiment includes only the selectURL output 
> gate of SharedStorage. We will follow up with aggregate reporting gates in 
> future releases.
>
>  
> DebuggabilityThere are no particular debugging APIs made available or 
> Chrome DevTools integrations for this OT. Will this feature be supported 
> on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and 
> Android WebView)?All but WebView. Is this feature fully tested by 
> web-platform-tests 
> 
> ?Internal platform tests exist, but they’re internal-only until we’re 
> able to make the fenced frames test infrastructure external. Flag nameOn 
> M104 or greater, the API can be enabled from 
> `chrome://flags/#privacy-sandbox-ads-apis`, or by activating the 
> `SharedStorageAPI`, `FencedFrames`, and `PrivacySandboxAdsAPIsOverride` 
> features. Requires code in //chrome?Only for permission checks. Tracking 
> bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1218540 Launch 
> bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1218535 Estimated 
> milestonesWe intend to begin experimenting in M104 as part of the Privacy 
> Sandbox APIs Origin Trial 
> .
>

What are the timelines for running the experiment? M104 till?
 

>  Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/6256348582903808 This intent message was 
> generated by Chrome Platform Status .
>

-- 
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/917590f9-b719-4bd9-9c4a-4a6d7e99d98cn%40chromium.org.

Re: [blink-dev] Intent to Ship: Custom Highlight API

[Yoav Weiss]

On Thursday, June 9, 2022 at 6:55:06 AM UTC+2 Manuel Rego wrote:

> I'm biased here as I've been working on this feature myself, so I cannot 
> give an official LGTM. 
>
> Thanks for all the work since the previous intent thread, I believe this 
> is now in a way better status to ship. 
>
> I'd be fine giving a LGTM with the following caveats: 
> * As mentioned at the end of the email, HighlightOverlayPainting flag 
> gets enabled before shipping this (that flag fixes lots of bugs 
> regarding paining of CSS highlight pseudos). 
> * The following CSSWG issue gets resolved: 
> https://github.com/w3c/csswg-drafts/issues/6774 
> It looks like there's an agreement already but it'd be nice to confirm 
> it, as this might change behavior if a different decision is made. 
>
> Other than that I've just some minor comments inline. 
>
> On 08/06/2022 19:42, 'Daniel Clark' via blink-dev wrote: 
> > Risks 
> > 
> > 
> > Interoperability and Compatibility 
> > 
> > Low risk: This feature received positive support from Safari and Firefox 
> > at TPAC 2019. Safari is implementing it, Firefox has not yet made any 
> > clear indication on implementation.


What's the feature detection/activation story here? Can developers use the 
feature while it's partially supported? What would be the implications of 
that?
  

>
> > 
> > 
> > 
> > /Gecko/: No clear signal 
> > (https://github.com/mozilla/standards-positions/issues/482 
> > ) 
>
> We could send a ping notifying that Chromium is planning to ship. 
>
> > /WebKit/: Positive. WebKit implemented the feature behind an 
> > experimental flag in 99: 
> > 
> https://developer.apple.com/safari/technology-preview/release-notes/#:~:text=Added%20support%20for%20rendering%20highlights%20specified%20in%20CSS%20Highlight%20API
>  
> > <
> https://developer.apple.com/safari/technology-preview/release-notes/#:~:text=Added%20support%20for%20rendering%20highlights%20specified%20in%20CSS%20Highlight%20API>.
>  
>
>
> I agree that it's positive WebKit has a WIP implementation. But just to 
> clarify the status Safari has an old version of this spec implemented, 
> and the implementation is not complete and not up to date regarding the 
> spec (e.g. https://bugs.webkit.org/show_bug.cgi?id=229797).


Can you ask for an explicit signal to see what their plans are on that 
front? Is there an interop risk from their incomplete implementation?
 

>
>
> Cheers, 
> Rego 
>

-- 
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/47e226a2-d00a-42fd-a846-6f506969228an%40chromium.org.

Re: [blink-dev] Intent to ship: Picture-in-Picture (Android)

[Yoav Weiss]

LGTM1

On Tue, Jun 14, 2022 at 6:00 PM 'François Beaufort ' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
>
> fbeauf...@chromium.org, liber...@chromium.org
>
> Explainer
>
> https://github.com/w3c/picture-in-picture/blob/main/explainer.md
>
> Specification
>
> https://w3c.github.io/picture-in-picture/
>
> Summary
>
> The Picture-in-Picture API allows websites to create a floating video
> window that is always on top of other windows so that users may continue
> consuming media while they interact with other sites or applications on
> their device. This change only applies to  elements.
>
> Blink component
>
> Blink>Media>PictureInPicture
> 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/226
>
> TAG review status
>
> Issues addressed
>
> Risks
>
> Interoperability and Compatibility
>
> Gecko: Defer (
> https://mozilla.github.io/standards-positions/#picture-in-picture)
>
> WebKit: Positive - Shipped in Safari 13.1 (
> https://developer.apple.com/documentation/safari-release-notes/safari-13_1-release_notes
> )
>
> Web developers: Positive - Media players have adopted Picture-in-Picture (
> VideoJS , Shaka Player
> )
>
> Other signals:
>
> WebView application risks
>
> None
>
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> No. Android WebView is still not supported.
>
>
> This feature was previously shipped for Windows, Mac, Linux, and Chrome OS
> in 2018.
> https://groups.google.com/a/chromium.org/g/blink-dev/c/ibVPbqBQapU/m/eMblkidrAgAJ
>
> This intent is about requesting approval to ship on Android
> http://crbug.com/964373
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Yes. https://wpt.fyi/results/picture-in-picture
> 
>
> Requires code in //chrome?
>
> Yes
>
> Tracking bug
>
> http://crbug.com/964373
>
> Sample links
>
> https://googlechrome.github.io/samples/picture-in-picture/
>
> Estimated milestones
>
> 105
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5729206566649856
>
> Links to previous Intent discussions
>
> Intent to Ship:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/ibVPbqBQapU/m/eMblkidrAgAJ
>
> --
> 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/CAPpwU5%2BFP_C6D6eHMoUH0ARms8hmKW5icnXb_1UWTChJJOPt0w%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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVhH1sQi4Y_zo6N%3DLDC908avWd3CQVjK%3DtXRs-4qaBzgw%40mail.gmail.com.

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

[Daisuke Enomoto]

Hello

Apologies for the confusion! The list of the top 100 pervasive payloads for
> use in the experiment is pending internal reviews and will be shared on
> this thread upon approval.


The list of the top 100 pervasive payloads can be found here
.
Please note that this list is only for the experiment purposes. On a side
note, the experiment is currently disabled in M103 after we found crashing
bugs, which we're actively investigating.


On Wed, Apr 27, 2022 at 9:55 AM Nidhi Jaju  wrote:

> Hi Noam,
>
> Apologies for the confusion! The list of the top 100 pervasive payloads
> for use in the experiment is pending internal reviews and will be shared on
> this thread upon approval.
>
> On Tue, Apr 26, 2022 at 11:24 PM Noam Rosenthal <
> noam.j.rosent...@gmail.com> wrote:
>
>> The summary says "payload list included below" - I can't find it
>> though... is the list included in one of the links?
>>
>> On Tuesday, April 26, 2022 at 4:03:11 PM UTC+3 mike...@chromium.org
>> wrote:
>>
>>> On 4/26/22 8:14 AM, Anne van Kesteren wrote:
>>> > On Tue, Apr 26, 2022 at 1:59 PM Daisuke Enomoto 
>>> wrote:
>>> >> Explainer
>>> >>
>>> >>
>>> https://docs.google.com/document/d/1pvaMg7J5beBXD7trzHJH_MDULc_wRHLx40MFYAmjknE/edit
>>> > This document isn't public.
>>>
>>> I just checked the settings, and it should be public now.
>>>
>>> > This particular technique has been discussed before, but there's a
>>> > flaw which wasn't mentioned in this email. The idea assumes that all
>>> > end users can access the same websites and also that all end users
>>> > visit similar websites. Neither of those is a given and as such end
>>> > users that for one reason or another only end up visiting one or two
>>> > websites that use a "pervasive payload" could be vulnerable to attack.
>>>
>>>

-- 
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/CAA5e69_EwFgahMf3xKKAAUnC%3DFkG-tfau_gwptbpKFf1YBLu7g%40mail.gmail.com.