Re: [blink-dev] Re: Intent to Experiment: Element Capture

['Elad Alon' via blink-dev]

Thank you for the LGTMs.

A quick update that we have discussed the matter with the OT Core team, and 
it appears to us all better to have the breaking period between June 24 
(first day of break) and July 15 (first day of renewed experiment). This 
ensures that partners have time to mint a new token and roll it out to 
their production enviornment ahead of m127 shipping to Stable.

On Wednesday, May 15, 2024 at 4:41:36 PM UTC+2 Yoav Weiss wrote:

> LGTM3
>
> On Tue, May 14, 2024 at 8:40 PM Chris Harrelson  
> wrote:
>
>> LGTM2
>>
>> On Tue, May 14, 2024 at 11:36 AM Mike Taylor  
>> wrote:
>>
>>> OK - thanks for the clarification. I would ask that you get in touch 
>>> with every registered origin - expiring the experiment early may be 
>>> surprising.
>>>
>>> LGTM1 to experiment from M127 to M132 inclusive.
>>> On 5/14/24 12:08 PM, Elad Alon wrote:
>>>
>>> I'm asking for a break-off period starting July 1 and ending July 22 
>>> (inclusive). That means that the original trial will end on June 30, and be 
>>> restarted on July 23. This corresponds to breaking the original experiment 
>>> early during the cycle of what would have otherwise been its final 
>>> milestone (m126), the restarting the experiment over the m127-m132 range. 
>>> (CC Panos for feasibility.)
>>>
>>> On Friday, May 10, 2024 at 10:25:03 PM UTC+2 mike...@chromium.org wrote:
>>>
 Note: Because you're asking for a renewal of 6 milestones, this will 
 require 3 LGTMs.

 Can you clarify which milestones you're asking for? You've written 
 "(2024-May-14 to 2024-Jun-04)" - that range maps to M125 and M126 stable 
 releases.
 On 5/10/24 6:44 AM, 'Elad Alon' via blink-dev wrote:

 Hello Blink owners,

 We are asking for a breaking period of 3 weeks to this API, followed by 
 a renewed experiment for the traditional 6 milestones (2024-May-14 to 
 2024-Jun-04). A request 
  
 that seems similar to me was granted in January 2022 for another API, and 
 later shipped successfully with consensus with Mozilla and Apple.

 At the time of writing, we have public support 
 
  
 for this API from such companies as Zoom, Jitsi, Mux, DialPad, Whereby, 
 Intel and Tella. Tango’s co-founder wrote 
 
  
 “I can't emphasize enough how instrumental this specification would be for 
 our product and user experience.” However, none of them have signed up for 
 the OT as of yet. 

 From the OT perspective:

 This API allows Web developers to build novel new features; however, it 
 requires a non-trivial investment. We are hoping that after giving more 
 time, we will see more participation.

 From the standardization perspective:

 We need time to pick up discussions with Mozilla and Apple again. As 
 Chrome’s Security and Privacy experts do not share the concerns Mozilla 
 and 
 Apple have previously voiced, it stands to reason that additional 
 discussions will allow us to converge - and we will prioritize these 
 discussions now.

 Additionally, some possibilities remain for API changes that could 
 perhaps allow for a compromise, mostly around cross-origin isolation. 
 (Full 
 disclosure - this is not my ideal outcome, but it’s a fallback possibility 
 worth mentioning.)

 Progress made:

- 

Spec: The spec has evolved and is now more mature, dealing better 
with such edge cases as loss of “eligibility for restriction.”
- 

TAG: Previously we held off on the request for a TAG review until 
we got some more developer feedback about the API shape. Having 
 received 
this initial feedback, the TAG request 
 has now been 
submitted.
- 

Signals: Signals have been requested. Mozilla responded. We intend 
to prioritize this discussion with them now.
- 

Feedback: Outreach for feedback from the spec community - multiple 
issues 
 
were filed on the spec by Web developers.
- 

WPT: Coverage has recently been extended 

 
.


 Reasons to run a new trial:

 Gain additional feedback from new participants. Examples for remaining 
 areas where new feedback could help include:

Re: [blink-dev] Re: Intent to Experiment: Element Capture

[Yoav Weiss (@Shopify)]

LGTM3

On Tue, May 14, 2024 at 8:40 PM Chris Harrelson 
wrote:

> LGTM2
>
> On Tue, May 14, 2024 at 11:36 AM Mike Taylor 
> wrote:
>
>> OK - thanks for the clarification. I would ask that you get in touch with
>> every registered origin - expiring the experiment early may be surprising.
>>
>> LGTM1 to experiment from M127 to M132 inclusive.
>> On 5/14/24 12:08 PM, Elad Alon wrote:
>>
>> I'm asking for a break-off period starting July 1 and ending July 22
>> (inclusive). That means that the original trial will end on June 30, and be
>> restarted on July 23. This corresponds to breaking the original experiment
>> early during the cycle of what would have otherwise been its final
>> milestone (m126), the restarting the experiment over the m127-m132 range.
>> (CC Panos for feasibility.)
>>
>> On Friday, May 10, 2024 at 10:25:03 PM UTC+2 mike...@chromium.org wrote:
>>
>>> Note: Because you're asking for a renewal of 6 milestones, this will
>>> require 3 LGTMs.
>>>
>>> Can you clarify which milestones you're asking for? You've written
>>> "(2024-May-14 to 2024-Jun-04)" - that range maps to M125 and M126 stable
>>> releases.
>>> On 5/10/24 6:44 AM, 'Elad Alon' via blink-dev wrote:
>>>
>>> Hello Blink owners,
>>>
>>> We are asking for a breaking period of 3 weeks to this API, followed by
>>> a renewed experiment for the traditional 6 milestones (2024-May-14 to
>>> 2024-Jun-04). A request
>>> 
>>> that seems similar to me was granted in January 2022 for another API, and
>>> later shipped successfully with consensus with Mozilla and Apple.
>>>
>>> At the time of writing, we have public support
>>> 
>>> for this API from such companies as Zoom, Jitsi, Mux, DialPad, Whereby,
>>> Intel and Tella. Tango’s co-founder wrote
>>> 
>>> “I can't emphasize enough how instrumental this specification would be for
>>> our product and user experience.” However, none of them have signed up for
>>> the OT as of yet.
>>>
>>> From the OT perspective:
>>>
>>> This API allows Web developers to build novel new features; however, it
>>> requires a non-trivial investment. We are hoping that after giving more
>>> time, we will see more participation.
>>>
>>> From the standardization perspective:
>>>
>>> We need time to pick up discussions with Mozilla and Apple again. As
>>> Chrome’s Security and Privacy experts do not share the concerns Mozilla and
>>> Apple have previously voiced, it stands to reason that additional
>>> discussions will allow us to converge - and we will prioritize these
>>> discussions now.
>>>
>>> Additionally, some possibilities remain for API changes that could
>>> perhaps allow for a compromise, mostly around cross-origin isolation. (Full
>>> disclosure - this is not my ideal outcome, but it’s a fallback possibility
>>> worth mentioning.)
>>>
>>> Progress made:
>>>
>>>-
>>>
>>>Spec: The spec has evolved and is now more mature, dealing better
>>>with such edge cases as loss of “eligibility for restriction.”
>>>-
>>>
>>>TAG: Previously we held off on the request for a TAG review until we
>>>got some more developer feedback about the API shape. Having received 
>>> this
>>>initial feedback, the TAG request
>>> has now been
>>>submitted.
>>>-
>>>
>>>Signals: Signals have been requested. Mozilla responded. We intend
>>>to prioritize this discussion with them now.
>>>-
>>>
>>>Feedback: Outreach for feedback from the spec community - multiple
>>>issues
>>>
>>>were filed on the spec by Web developers.
>>>-
>>>
>>>WPT: Coverage has recently been extended
>>>
>>> 
>>>.
>>>
>>>
>>> Reasons to run a new trial:
>>>
>>> Gain additional feedback from new participants. Examples for remaining
>>> areas where new feedback could help include:
>>>
>>>-
>>>
>>>Uncover new edge cases which were not uncovered by the spec authors
>>>and reviewers, implementers and current OT participants. The current edge
>>>cases here
>>>
>>> 
>>>demonstrate how non-obvious these may be.
>>>-
>>>
>>>Validate (or refute) the assumptions we have made about the
>>>viability of an MVP that is missing some functionality. Examples:
>>>-
>>>
>>>   Events notifying apps when an element stops/starts being
>>>   “eligible for restriction”.
>>>   -
>>>
>>>   Mechanism to force elements into 

Re: [blink-dev] Re: Intent to Experiment: Element Capture

[Chris Harrelson]

LGTM2

On Tue, May 14, 2024 at 11:36 AM Mike Taylor  wrote:

> OK - thanks for the clarification. I would ask that you get in touch with
> every registered origin - expiring the experiment early may be surprising.
>
> LGTM1 to experiment from M127 to M132 inclusive.
> On 5/14/24 12:08 PM, Elad Alon wrote:
>
> I'm asking for a break-off period starting July 1 and ending July 22
> (inclusive). That means that the original trial will end on June 30, and be
> restarted on July 23. This corresponds to breaking the original experiment
> early during the cycle of what would have otherwise been its final
> milestone (m126), the restarting the experiment over the m127-m132 range.
> (CC Panos for feasibility.)
>
> On Friday, May 10, 2024 at 10:25:03 PM UTC+2 mike...@chromium.org wrote:
>
>> Note: Because you're asking for a renewal of 6 milestones, this will
>> require 3 LGTMs.
>>
>> Can you clarify which milestones you're asking for? You've written
>> "(2024-May-14 to 2024-Jun-04)" - that range maps to M125 and M126 stable
>> releases.
>> On 5/10/24 6:44 AM, 'Elad Alon' via blink-dev wrote:
>>
>> Hello Blink owners,
>>
>> We are asking for a breaking period of 3 weeks to this API, followed by a
>> renewed experiment for the traditional 6 milestones (2024-May-14 to
>> 2024-Jun-04). A request
>> 
>> that seems similar to me was granted in January 2022 for another API, and
>> later shipped successfully with consensus with Mozilla and Apple.
>>
>> At the time of writing, we have public support
>> 
>> for this API from such companies as Zoom, Jitsi, Mux, DialPad, Whereby,
>> Intel and Tella. Tango’s co-founder wrote
>> 
>> “I can't emphasize enough how instrumental this specification would be for
>> our product and user experience.” However, none of them have signed up for
>> the OT as of yet.
>>
>> From the OT perspective:
>>
>> This API allows Web developers to build novel new features; however, it
>> requires a non-trivial investment. We are hoping that after giving more
>> time, we will see more participation.
>>
>> From the standardization perspective:
>>
>> We need time to pick up discussions with Mozilla and Apple again. As
>> Chrome’s Security and Privacy experts do not share the concerns Mozilla and
>> Apple have previously voiced, it stands to reason that additional
>> discussions will allow us to converge - and we will prioritize these
>> discussions now.
>>
>> Additionally, some possibilities remain for API changes that could
>> perhaps allow for a compromise, mostly around cross-origin isolation. (Full
>> disclosure - this is not my ideal outcome, but it’s a fallback possibility
>> worth mentioning.)
>>
>> Progress made:
>>
>>-
>>
>>Spec: The spec has evolved and is now more mature, dealing better
>>with such edge cases as loss of “eligibility for restriction.”
>>-
>>
>>TAG: Previously we held off on the request for a TAG review until we
>>got some more developer feedback about the API shape. Having received this
>>initial feedback, the TAG request
>> has now been
>>submitted.
>>-
>>
>>Signals: Signals have been requested. Mozilla responded. We intend to
>>prioritize this discussion with them now.
>>-
>>
>>Feedback: Outreach for feedback from the spec community - multiple
>>issues
>>
>>were filed on the spec by Web developers.
>>-
>>
>>WPT: Coverage has recently been extended
>>
>> 
>>.
>>
>>
>> Reasons to run a new trial:
>>
>> Gain additional feedback from new participants. Examples for remaining
>> areas where new feedback could help include:
>>
>>-
>>
>>Uncover new edge cases which were not uncovered by the spec authors
>>and reviewers, implementers and current OT participants. The current edge
>>cases here
>>
>> 
>>demonstrate how non-obvious these may be.
>>-
>>
>>Validate (or refute) the assumptions we have made about the viability
>>of an MVP that is missing some functionality. Examples:
>>-
>>
>>   Events notifying apps when an element stops/starts being “eligible
>>   for restriction”.
>>   -
>>
>>   Mechanism to force elements into an “eligible for restriction”
>>   state.
>>   -
>>
>>Encourage future OT participation by Web developers, by demonstrating
>>that risks associated with relying on an origin 

Re: [blink-dev] Re: Intent to Experiment: Element Capture

[Mike Taylor]

OK - thanks for the clarification. I would ask that you get in touch 
with every registered origin - expiring the experiment early may be 
surprising.


LGTM1 to experiment from M127 to M132 inclusive.

On 5/14/24 12:08 PM, Elad Alon wrote:
I'm asking for a break-off period starting July 1 and ending July 22 
(inclusive). That means that the original trial will end on June 30, 
and be restarted on July 23. This corresponds to breaking the original 
experiment early during the cycle of what would have otherwise been 
its final milestone (m126), the restarting the experiment over the 
m127-m132 range. (CC Panos for feasibility.)


On Friday, May 10, 2024 at 10:25:03 PM UTC+2 mike...@chromium.org wrote:

Note: Because you're asking for a renewal of 6 milestones, this
will require 3 LGTMs.

Can you clarify which milestones you're asking for? You've written
"(2024-May-14 to 2024-Jun-04)" - that range maps to M125 and M126
stable releases.

On 5/10/24 6:44 AM, 'Elad Alon' via blink-dev wrote:


Hello Blink owners,


We are asking for a breaking period of 3 weeks to this API,
followed by a renewed experiment for the traditional 6 milestones
(2024-May-14 to 2024-Jun-04). A request
that
seems similar to me was granted in January 2022 for another API,
and later shipped successfully with consensus with Mozilla and Apple.


At the time of writing, we have public support

for
this API from such companies as Zoom, Jitsi, Mux, DialPad,
Whereby, Intel and Tella. Tango’s co-founder wrote

“I
can't emphasize enough how instrumental this specification would
be for our product and user experience.” However, none of them
have signed up for the OT as of yet.


From the OT perspective:

This API allows Web developers to build novel new features;
however, it requires a non-trivial investment. We are hoping that
after giving more time, we will see more participation.


From the standardization perspective:

We need time to pick up discussions with Mozilla and Apple again.
As Chrome’s Security and Privacy experts do not share the
concerns Mozilla and Apple have previously voiced, it stands to
reason that additional discussions will allow us to converge -
and we will prioritize these discussions now.


Additionally, some possibilities remain for API changes that
could perhaps allow for a compromise, mostly around cross-origin
isolation. (Full disclosure - this is not my ideal outcome, but
it’s a fallback possibility worth mentioning.)


Progress made:

 *

Spec:The spec has evolved and is now more mature, dealing
better with such edge cases as loss of “eligibility for
restriction.”

 *

TAG:Previously we held off on the request for a TAG review
until we got some more developer feedback about the API
shape. Having received this initial feedback, the TAG request
has now
been submitted.

 *

Signals:Signals have been requested. Mozilla responded. We
intend to prioritize this discussion with them now.

 *

Feedback:Outreach for feedback from the spec community -
multiple issues

were
filed on the spec by Web developers.

 *

WPT:Coverage has recently been extended

.


Reasons to run a new trial:

Gain additional feedback from new participants. Examples for
remaining areas where new feedback could help include:

 *

Uncover new edge cases which were not uncovered by the spec
authors and reviewers, implementers and current OT
participants. The current edge cases here

demonstrate
how non-obvious these may be.

 *

Validate (or refute) the assumptions we have made about the
viability of an MVP that is missing some functionality. Examples:

 o

Events notifying apps when an element stops/starts being
“eligible for restriction”.

 o

Mechanism to force elements into an “eligible for
restriction” state.

 *

Encourage future OT participation by Web developers, by
demonstrating that risks associated with relying on an origin
trial, while real, are 

Re: [blink-dev] Re: Intent to Experiment: Element Capture

['Elad Alon' via blink-dev]

I'm asking for a break-off period starting July 1 and ending July 22 
(inclusive). That means that the original trial will end on June 30, and be 
restarted on July 23. This corresponds to breaking the original experiment 
early during the cycle of what would have otherwise been its final 
milestone (m126), the restarting the experiment over the m127-m132 range. 
(CC Panos for feasibility.)

On Friday, May 10, 2024 at 10:25:03 PM UTC+2 mike...@chromium.org wrote:

> Note: Because you're asking for a renewal of 6 milestones, this will 
> require 3 LGTMs.
>
> Can you clarify which milestones you're asking for? You've written 
> "(2024-May-14 to 2024-Jun-04)" - that range maps to M125 and M126 stable 
> releases.
> On 5/10/24 6:44 AM, 'Elad Alon' via blink-dev wrote:
>
> Hello Blink owners,
>
> We are asking for a breaking period of 3 weeks to this API, followed by a 
> renewed experiment for the traditional 6 milestones (2024-May-14 to 
> 2024-Jun-04). A request 
>  that 
> seems similar to me was granted in January 2022 for another API, and later 
> shipped successfully with consensus with Mozilla and Apple.
>
> At the time of writing, we have public support 
> 
>  
> for this API from such companies as Zoom, Jitsi, Mux, DialPad, Whereby, 
> Intel and Tella. Tango’s co-founder wrote 
> 
>  
> “I can't emphasize enough how instrumental this specification would be for 
> our product and user experience.” However, none of them have signed up for 
> the OT as of yet. 
>
> From the OT perspective:
>
> This API allows Web developers to build novel new features; however, it 
> requires a non-trivial investment. We are hoping that after giving more 
> time, we will see more participation.
>
> From the standardization perspective:
>
> We need time to pick up discussions with Mozilla and Apple again. As 
> Chrome’s Security and Privacy experts do not share the concerns Mozilla and 
> Apple have previously voiced, it stands to reason that additional 
> discussions will allow us to converge - and we will prioritize these 
> discussions now.
>
> Additionally, some possibilities remain for API changes that could perhaps 
> allow for a compromise, mostly around cross-origin isolation. (Full 
> disclosure - this is not my ideal outcome, but it’s a fallback possibility 
> worth mentioning.)
>
> Progress made:
>
>- 
>
>Spec: The spec has evolved and is now more mature, dealing better with 
>such edge cases as loss of “eligibility for restriction.”
>- 
>
>TAG: Previously we held off on the request for a TAG review until we 
>got some more developer feedback about the API shape. Having received this 
>initial feedback, the TAG request 
> has now been 
>submitted.
>- 
>
>Signals: Signals have been requested. Mozilla responded. We intend to 
>prioritize this discussion with them now.
>- 
>
>Feedback: Outreach for feedback from the spec community - multiple 
>issues 
> 
>were filed on the spec by Web developers.
>- 
>
>WPT: Coverage has recently been extended 
>
> 
>.
>
>
> Reasons to run a new trial:
>
> Gain additional feedback from new participants. Examples for remaining 
> areas where new feedback could help include:
>
>- 
>
>Uncover new edge cases which were not uncovered by the spec authors 
>and reviewers, implementers and current OT participants. The current edge 
>cases here 
>
> 
>  
>demonstrate how non-obvious these may be.
>- 
>
>Validate (or refute) the assumptions we have made about the viability 
>of an MVP that is missing some functionality. Examples:
>- 
>   
>   Events notifying apps when an element stops/starts being “eligible 
>   for restriction”.
>   - 
>   
>   Mechanism to force elements into an “eligible for restriction” 
>   state.
>   - 
>
>Encourage future OT participation by Web developers, by demonstrating 
>that risks associated with relying on an origin trial, while real, are 
>partially offset by a commitment to keep the OT going until discussions 
>conclude.
>
>
> Thanks,
>
> Elad
> On Monday, November 27, 2023 at 4:00:11 PM UTC+1 Elad Alon wrote:
>
>> Thank you for updating, Jan-Ivar. I have now updated this information in 
>> the ChromeStatus 

Re: [blink-dev] Re: Intent to Experiment: Element Capture

[Mike Taylor]

Note: Because you're asking for a renewal of 6 milestones, this will 
require 3 LGTMs.


Can you clarify which milestones you're asking for? You've written 
"(2024-May-14 to 2024-Jun-04)" - that range maps to M125 and M126 stable 
releases.


On 5/10/24 6:44 AM, 'Elad Alon' via blink-dev wrote:


Hello Blink owners,


We are asking for a breaking period of 3 weeks to this API, followed 
by a renewed experiment for the traditional 6 milestones (2024-May-14 
to 2024-Jun-04). A request 
that 
seems similar to me was granted in January 2022 for another API, and 
later shipped successfully with consensus with Mozilla and Apple.



At the time of writing, we have public support 
for 
this API from such companies as Zoom, Jitsi, Mux, DialPad, Whereby, 
Intel and Tella. Tango’s co-founder wrote 
“I 
can't emphasize enough how instrumental this specification would be 
for our product and user experience.” However, none of them have 
signed up for the OT as of yet.



From the OT perspective:

This API allows Web developers to build novel new features; however, 
it requires a non-trivial investment. We are hoping that after giving 
more time, we will see more participation.



From the standardization perspective:

We need time to pick up discussions with Mozilla and Apple again. As 
Chrome’s Security and Privacy experts do not share the concerns 
Mozilla and Apple have previously voiced, it stands to reason that 
additional discussions will allow us to converge - and we will 
prioritize these discussions now.



Additionally, some possibilities remain for API changes that could 
perhaps allow for a compromise, mostly around cross-origin isolation. 
(Full disclosure - this is not my ideal outcome, but it’s a fallback 
possibility worth mentioning.)



Progress made:

 *

Spec:The spec has evolved and is now more mature, dealing better
with such edge cases as loss of “eligibility for restriction.”

 *

TAG:Previously we held off on the request for a TAG review until
we got some more developer feedback about the API shape. Having
received this initial feedback, the TAG request
has now been
submitted.

 *

Signals:Signals have been requested. Mozilla responded. We intend
to prioritize this discussion with them now.

 *

Feedback:Outreach for feedback from the spec community - multiple
issues
were
filed on the spec by Web developers.

 *

WPT:Coverage has recently been extended

.


Reasons to run a new trial:

Gain additional feedback from new participants. Examples for remaining 
areas where new feedback could help include:


 *

Uncover new edge cases which were not uncovered by the spec
authors and reviewers, implementers and current OT participants.
The current edge cases here

demonstrate
how non-obvious these may be.

 *

Validate (or refute) the assumptions we have made about the
viability of an MVP that is missing some functionality. Examples:

 o

Events notifying apps when an element stops/starts being
“eligible for restriction”.

 o

Mechanism to force elements into an “eligible for restriction”
state.

 *

Encourage future OT participation by Web developers, by
demonstrating that risks associated with relying on an origin
trial, while real, are partially offset by a commitment to keep
the OT going until discussions conclude.


Thanks,

Elad

On Monday, November 27, 2023 at 4:00:11 PM UTC+1 Elad Alon wrote:

Thank you for updating, Jan-Ivar. I have now updated this
information in the ChromeStatus entry. I am looking forward to
carry on the discussion about your position in your
standards-positions GitHub repo, in the Element Capture spec repo,
in the Screen Capture CG and in the WebRTC WG.

On Monday, November 27, 2023 at 3:53:51 PM UTC+1
jbru...@mozilla.com wrote:

The Gecko position has been updated to negative. See
https://github.com/mozilla/standards-positions/issues/857

On Monday, November 20, 2023 at 6:41:00 AM UTC-5 Elad Alon wrote:


Contact emails

elad...@chromium.org


Explainer

https://github.com/screen-share/element-capture/blob/main/README.md