[webkit-dev] Reminder: WebKit SVN tree clousures (March 2021)

[Ling Ho via webkit-dev]

Hello,

The 2nd maintenance mentioned in my previous email will take place this 
coming weekend as planned.


The WebKit SVN tree will be closed during:
*Begin*: Friday, March 19th, 2021. 5pm (PDT)
*End*: Monday, March 22nd, 2021. No later than 6pm (PDT)

...
Ling Ho

On 2/24/21 5:26 PM, Ling Ho wrote:

Hello WebKit,

Due to planned infrastructure maintenance, our critical continuous 
integration services (EWS and post-commit bots) will be unavailable 
during the following weekends:


*Dates*:
*Begin*: Friday, March 5th, 2021. 5pm (PST)
*End*: Monday, March 8th, 2021. No later than 6pm (PST)

*Begin*: Friday, March 19th, 2021. 5pm (PDT)
*End*: Monday, March 22nd, 2021. No later than 6pm (PDT)

To avoid accumulating difficult to diagnose regressions during this 
lengthy outage, *WebKit SVN tree will be closed*.


Please email ad...@webkit.org if you have any questions or concerns.

Thanks,

...
Ling Ho 


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for position: Aligning high-resolution timer granularity to cross-origin isolated capability

[Geoff Garen via webkit-dev]

For the 100 microsecond value — our research suggests that you need a much 
higher value in vulnerable contexts.

For the guaranteed isolated case — have you considered the use of high 
precision time to carry out non-Spectre timing attacks?

Thanks,
Geoff

> On Mar 17, 2021, at 3:38 AM, Yoav Weiss via webkit-dev 
>  wrote:
> 
> Hey folks,
> 
> We recently changed  the HR-time spec 
>  to better align its resolution clamping with 
> cross-origin isolated capability 
> ,
>  and now I'm interested in shipping this change in Chromium.
> In practice that means that Chromium would be reducing its resolution in 
> non-isolated contexts (regardless of the platform's site-isolation status) to 
> 100 microseconds, and increasing it in cross-origin isolated contexts (even 
> in platforms without site-isolation, e.g. Android) to 5 microseconds.
> 
> As WebKit already clamps those timers to 1ms (AFAIK), I'd mostly like your 
> position on the latter. Would y'all be interested in increasing timer 
> granularity in contexts which have guarantees against pulling in cross-origin 
> resources without their opt-in?
> 
> I'd appreciate your thoughts on the matter.
> 
> Cheers :)
> Yoav
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Request for position: Aligning high-resolution timer granularity to cross-origin isolated capability

[Yoav Weiss via webkit-dev]

Hey folks,

We recently changed  the HR-time
spec  to better align its resolution
clamping with cross-origin isolated capability
,
and now I'm interested in shipping this change in Chromium.
In practice that means that Chromium would be reducing its resolution in
non-isolated contexts (regardless of the platform's site-isolation status)
to 100 microseconds, and increasing it in cross-origin isolated contexts
(even in platforms without site-isolation, e.g. Android) to 5 microseconds.

As WebKit already clamps those timers to 1ms (AFAIK), I'd mostly like your
position on the latter. Would y'all be interested in increasing timer
granularity in contexts which have guarantees against pulling in
cross-origin resources without their opt-in?

I'd appreciate your thoughts on the matter.

Cheers :)
Yoav
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev