Re: WebPerfWG call - May 19th 10am PST

And the actual links for the minutes
<https://docs.google.com/document/d/e/2PACX-1vRRGtuzCb4u7GfOPBFKW4xUbpahnsKCudnX69uDQbHnwLPPllwxiJJJup3YdgeUNT90C2dPkkGzDNwP/pub>
and video <https://youtu.be/eHwpVA7033I>...

On Fri, May 29, 2020 at 10:48 AM Yoav Weiss <yoav@yoav.ws> wrote:

> Hey folks,
>
> Minutes and video from the call are now available. Copying the minutes
> here for safe keeping:
>
> WebPerfWG call - May 21st 2020
>
> Participants
>
> Yoav Weiss, Michal Mocny, Nic Jansma, Steven Bougon, Philippe Le Hegaret,
> Nicolás Peña, Alex Christensen, Annie Sullivan, Gilles Dubuc, Michelle Vu,
> Next Meeting
>
> June 4th @ 10am PST / 1pm EST
> CFC for Group Extension
>
>    -
>    https://lists.w3.org/Archives/Public/public-web-perf/2020May/0002.html
>    <https://www.google.com/url?q=https://lists.w3.org/Archives/Public/public-web-perf/2020May/0002.html&sa=D&ust=1590744916366000>
>    - Philippe: No feedback on mailing list
>    - Yoav: Haven’t seen any objections
>    - Decision - Extend the charter
>
> IssuesResourceTiming Information Types
>
>    - Presentation
>    <https://www.google.com/url?q=https://docs.google.com/presentation/d/1C9_T72vW137NeG6NmRAKxn6PAWGq1hC5AYexfWL2KRg/edit%23slide%3Did.p&sa=D&ust=1590744916367000>
>    - Yoav: We need to better categorize the types of information that
>    ResourceTiming is exposing, and see what different opt-ins fit for which
>    types of information
>    - ... RT historically only exposed timing information (DNS, TCP, TTFB,
>    etc)
>    - ... we have a bunch of feature requests for processing time, and
>    already expose it through Element Timing’s rendering time
>    - ... sensitivity of this information varies
>    - ... DNS, TCP and TLS information doesn't not expose anything
>    user-specific to that origin.  It can expose information related to the
>    user's network status, but that can also be gathered elsewhere
>    - ...TTFB, processing time can expose information about that user (how
>    long it takes to generate user-specific data)
>    - ... Sizing information such as encoded-, decoded- and transfer-size
>    exposes information about the user through the content they load
>    - ... i.e. through tranferSize, exposing the credentialed resource
>    size and header size can give information about login state and other
>    sensitive information
>    - ... transferSize also reveals caching information or whether it was
>    re-validated.  We have feature requests related to code caching and/or
>    explicitly caching information.  This is potentially sensitive today
>    (exposing the user history), but we say this is OK because this can also be
>    reliably exposed in other ways.
>    - ... But in a double-key-cached world, this will no longer be
>    sensitive information, and would potentially not require an opt-in
>    - ... This is my opinion as an editor of ResourceTiming, and I have
>    not yet solicited feedback from Chrome/security folks.
>    - Philippe: What’s double-keyed caching?
>    - Yoav: Keying the resource based on both its URL and the top-level
>    domain that requested it. Shipped in Safari in 2012, Chrome to switch to
>    that soon.
>    - ... Next is protocol information via nextHopProtocol, and some
>    requests for cipher information and Server IP.  One of the issues that PING
>    has opened is that it can reveal information about one's network (e.g.
>    proxy settings).  We think this could also be detected by characteristics
>    of resource loads (e.g. H1 vs H2 load differences)
>    - ... Some of this information could possibly be handled by
>    ServerTiming instead.  If that's not the case, we need to decide if this
>    information is OK to expose, and if so, it doesn't match any of the
>    existing opt-ins (which we'll talk about later)
>    - ... Last we have initiator information, initiatorType, and a
>    proposal for more details about the initiator elements.  I don't think this
>    exposes new sensitive information, but we need to make sure of that. We
>    know that we need to make sure we don’t exepose post-redirect URLs.
>    - ... Finally we have requests for Status Code and Content Type, and
>    this is sensitive information as it can reveal details about the user if
>    the content is credentialed.
>    - ... We also have a proposal by Nic about automatic reporting of a
>    frame to its parent about its resources.  This might be a separate thing
>    with its own Opt-In.
>    - .... We have a few opt-ins available: Timing-Allow-Origin, used for
>    opting in timing and size information.
>    - ... Cross-Origin-Resource-Policy - a relatively new opt-in that
>    signifies a resource can be safely embedded by other content, even in a
>    world with Spectre and Meltdown.
>    - ... CORS allows complete sharing of the resource across different
>    origins
>    - ... How do we map the types of information to those opt-ins?
>    - ... Timing-Allow-Origin would expose timing information, and not
>    much else.  For developer recommendations it seems that it's perfectly OK
>    to add TAO for public resources, and slightly personalized resources.
>    - ... Cross-Origin-Resource-Policy should be OK to reveal sizing
>    information (similar to measureMemory API).  From my perspective it also
>    seems safe to expose timing information in those cases, similar to what TAO
>    does.  We could turn this on for public resources for those which may not
>    be CORS fetched.
>    - ... CORS content is fully exposed.  Timing, sizing and response
>    information is OK to expose.
>    - … Thoughts?
>    - Nic: Helpful to scope the different buckets and map them to opt-ins.
>    - Michal: How would conflicting headers affect this?
>    - Yoav: I think CORS either passes or fails, and if it fails, it
>    doesn't apply.  Then if TAO is on the resource and it passes, it would
>    apply.
>    - ... Ideally, CORS is a stronger policy than CORP, which is stronger
>    than TAO, so the strongest that passes would apply
>    - Steven: How do we effectively explain this to the community?
>    - Yoav: Agreed that explaining this already is and could be a challenge
>    - ... I'm hoping that the “layered” opt-ins would be easier to
>    explain. CORS is complex, CORP is a bit simpler. There are a bunch of new
>    capabilities bound behind CORP, so that might motivate people to understand
>    CORP beyond performance APIs
>    - Nic: We would need good documentation in the spec itself
>    - Yoav: This could affect the RUM community.  In cases where CORS is
>    enabled but not TAO, RUM would be able to get more timing information
>    automatically.  But in cases where there’s TAO but not CORS, they'd just
>    get timing information and not size info.
>    - Steven: Would like to see some sort of guide or table which
>    describes what happens in each case or bucket when these headers apply
>    - Michal: Where I'm concerned is that it's not self-documenting based
>    on the header name, where if you just have Timing-Allow-Origin it's not
>    obvious what's missing.
>    - Yoav: a shame that they’re not self-explanatory. We can use work to
>    define the relationship between CORS and CORP to also include TAO.
>    - Alex: We do agree if you have access to the content bytes, then
>    access to the timing information is less sensitive.  We have similar
>    assumptions for WebRTC. We need to help people understand the principle.
>    - ... The only detail about this that I kind of disagree with is that
>    the timing info about the DNS data and how easy it is to measure it outside
>    of this API
>    - Yoav: The way that I thought about it is there are ways of measuring
>    hosts that are expected to not resolve, to time DNS
>    - … Will run this proposal by folks and let y’all know how it goes.
>
> ResourceTiming
>
>    - https://github.com/w3c/resource-timing/issues/222
>    <https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/222&sa=D&ust=1590744916373000>
>
>
>    - Yoav: Mostly discussed by the above
>
>
>    - https://github.com/w3c/resource-timing/issues/223
>    <https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/223&sa=D&ust=1590744916374000>
>
>
>    - Yoav: Similar issue
>
>
>    - https://github.com/w3c/resource-timing/issues/215
>    <https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/215&sa=D&ust=1590744916374000>
>
>
>    - The step to queue a task to run fire a buffer full event should
>    specify its source
>    - Yoav: Editorial, I will just do that
>
> PerformanceTimeline
>
>    - https://github.com/w3c/performance-timeline/issues/167
>    <https://www.google.com/url?q=https://github.com/w3c/performance-timeline/issues/167&sa=D&ust=1590744916375000>
>
>
>    - Is the observer buffer of a PerformanceObserver a
>    PerformanceObserverEntryList or a PerformanceEntryList?
>    - Yoav: Editorial, moved to Level 2
>
> NavigationTiming
>
>    - https://github.com/w3c/navigation-timing/issues/125
>    <https://www.google.com/url?q=https://github.com/w3c/navigation-timing/issues/125&sa=D&ust=1590744916376000>
>
>
>    - PerformanceNavigationTiming needs a realm
>    - Yoav: Need realm to create NavigationTiming entry, but navigation
>    may get started before the document exists
>    - Nicolás: Keep variables around until document is created, Editorial
>    - Yoav: Is there any other precedence for objects created before the
>    document?
>    - Nicolás: Not sure
>    - Alex: question. Can we move the entry creation until the navigation
>    has ended?
>    - Yoav: The early creation enables folks to migrate from NavTiming L1
>    which reported things as they?
>
>
>    - https://github.com/w3c/navigation-timing/issues/126
>    <https://www.google.com/url?q=https://github.com/w3c/navigation-timing/issues/126&sa=D&ust=1590744916377000>
>
>
>    - Possibility to get the HTTP status code from the Response Header
>    - Yoav: We also have a feature request for this for ResourceTiming
>    - Yoav: Non-actionable for the moment
>    - Nicolás: Why not actionable?
>    - Yoav: We could make it a feature request for L3. NEL may resolve the
>    use cases
>    - Nic: NEL gives you an out-of-band signal, but doesn’t enable you to
>    correlate RUM with it
>    - Yoav: So there’s a case to be able to tell apart your 200s from your
>    500s?
>    - Nic: Akamai customers are using that, and we’re routing the status
>    codes through the HTML to expose it.
>    - …: It’s hard to tie NEL with the rest of your data: session ID, etc.
>    RUM is easier.
>    - Yoav: Also, NavigationTiming has no opt-in issues
>    - Nic: AI to add Akamai use-case to Github issue
>    - Yoav: OK, so we can label it as a feature request for L3
>
> UserTiming
>
>    - https://github.com/w3c/user-timing/issues/69
>    <https://www.google.com/url?q=https://github.com/w3c/user-timing/issues/69&sa=D&ust=1590744916380000>
>
>
>    - Allow performance.measure() to specify optional color parameter, to
>    be used by perf visualizations in devtools
>    - Yoav: Request to send colors along with marks/measures for use in
>    developer tools. Feels overly specific.
>    - Michal: We could look at how the console handles coloring.  Maybe
>    could be a part of the details object that's a convention per browser.
>    - Yoav: Agree that it seems like a better way to tackle this. Might be
>    interesting to loop in devtools folks.
>    - Michal: Console API accepts CSS properties, with a whitelisted set
>    of properties they can specify
>
>
>    - https://github.com/w3c/user-timing/issues/68
>    <https://www.google.com/url?q=https://github.com/w3c/user-timing/issues/68&sa=D&ust=1590744916381000>
>
>
>    - Allow marks and measures to be shown in developer tooling without
>    adding it to the performance timeline
>    - Annie: Ideally these would be handled by the developer tooling
>    folks. There was also an issue around UserTiming slowness in Chromium that
>    is also conflated here.
>    - Nicolás: I don’t get how would these entries be created in developer
>    tooling but not remain in memory
>    - Yoav: console calls might not do much when dev tools are closed, but
>    not sure this is true
>    - Nicolás: Feels like they want a "debug mode" for their profiling
>    which could be something they handle instead of building it into UserTiming
>    - Annie: They get that today by turning marks and measures on and the
>    off.
>    - Yoav: This might be better handled in user-land. I’ll loop in the
>    devtools folks.
>
>
>
> On Tue, May 19, 2020 at 12:00 AM Yoav Weiss <yoav@yoav.ws> wrote:
>
>> Hey all,
>>
>> Let's talk <https://meet.google.com/agz-fbji-spp> webperf tomorrow!
>>
>> On the agenda
>> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.5n0fwahptcja>,
>> we have a bunch of issues to discuss for Resource Timing, Performance
>> Timeline, Navigation Timing and User Timing. But beyond that, I'd love to
>> discuss the different information *types* that Resource Timing exposes
>> and the various opt-ins that this information is currently barred behind,
>> and what that should look like in the future.
>>
>> As always, the call will be recorded and posted online.
>>
>> Cheers :)
>> Yoav
>>
>