W3C home > Mailing lists > Public > public-web-perf@w3.org > October 2015

[minutes] 20151027 Web Performance face-to-face

From: Philippe Le Hegaret <plh@w3.org>
Date: Thu, 29 Oct 2015 03:08:53 +0900
To: public-web-perf <public-web-perf@w3.org>
Message-ID: <56310F35.4050006@w3.org>
Available at
   http://www.w3.org/2015/10/26-webperf-minutes.html

Text version:

               Web Performance Working Group Teleconference

    See also: [2]IRC log

       [2] http://www.w3.org/2015/10/26-webperf-irc

Attendees

    Present
           Yoav, plh, Ilya, Todd, Xiaoqian, Nick Doty (morning),
           Bartek (morning)

    Regrets
    Chair
           Ilya & Todd

    Scribe
           plh, nick, xiaoqian

Contents

      * [3]Topics
          1. [4]Frame timing
          2. [5]Page Visibility
          3. [6]preload
          4. [7]Beacon
          5. [8]Network Error Logging
          6. [9]Primer
          7. [10]CustomPerformanceEntry
          8. [11]redirects
          9. [12]Priorities and next charter
      * [13]Summary of Action Items
      __________________________________________________________

Frame timing

    yoav: I believe Intersection observer will help answer my RUM
    use cases
    ... still need to talk to David Baron about :visited

    Ilya: looking at implementation feedback

    Todd: new proposal needs to be circulated within MS
    ... current proposal seems acceptable

    Ilya: google and firefox did implementations of the first
    proposal

    <plh> ACTION: plh to clean up frame timing [recorded in
    [14]http://www.w3.org/2015/10/26-webperf-minutes.html#action01]

    <trackbot> Created ACTION-166 - Clean up frame timing [on
    Philippe Le Hégaret - due 2015-11-03].

Page Visibility

    <plh> [15]https://github.com/w3c/page-visibility/pull/16

      [15] https://github.com/w3c/page-visibility/pull/16

    Todd: you could merge the PR for the time being while still
    figuring if we got the right task source
    ... do we have tests for PV?
    ... our interop is weak when you include life cycles

    Ilya: firefox fires a transition from visible to hidden when
    the page is being unloaded

    plh: we need a test for prerender

    <plh> ACTION: plh to look into testing prerender in Page
    Visibility [recorded in
    [16]http://www.w3.org/2015/10/26-webperf-minutes.html#action02]

    <trackbot> Created ACTION-167 - Look into testing prerender in
    page visibility [on Philippe Le Hégaret - due 2015-11-03].

    Ilya: in FF, they fire hidden hidden in all cases

    Ilya: I don't think we need to transition when it's unloaded
    ... we could tell devs that they should always listen to
    visibility events, ie background transition or close tabs
    ... but that's handle by pagehide
    ... ie we could use a combination of visitibilityState and
    pagehide

    <plh> [17]https://github.com/w3c/page-visibility/issues/18

      [17] https://github.com/w3c/page-visibility/issues/18

    Ilya: no explicit definition of when the page is unloaded
    ... with the new update

    speculation that an example in the spec might have lead to
    hidden being true while a tab is being unloaded in some
    implementations

    <plh> [discussion regarding differences between pagehide and
    unload]

    Resolved: publish page visbility as a Working Draft

    <plh> ACTION: plh to publish PV2 [recorded in
    [18]http://www.w3.org/2015/10/26-webperf-minutes.html#action03]

    <trackbot> Created ACTION-168 - Publish pv2 [on Philippe Le
    Hégaret - due 2015-11-03].

preload

    Ilya: implemented in blink. needs to get it shipped and align
    in the spec.
    ... need to talk to the webkit folks
    ... push and preload don't connect but there are some use cases
    for preload that can be resolved with push
    ... [19]http://www.w3.org/TR/preload/#issue-1
    ... we need to define the caching more formaly
    ... there is magic there
    ... we retain the page for the navigation session if no cache
    is requested
    ... if preload is activated
    ... fetch needs tobe aware since the subsequent fetch will need
    to take it into account

      [19] http://www.w3.org/TR/preload/#issue-1

    yoav: in terms of interop, do prefetch live for the duration of
    the next navigation?

    Todd: we don't do preload and preconnect yet

    Ilya: for preload, it's a declarative fetch, so I don't think
    we're exposing anything special here in terms of security and
    privacy

    yoav: depending on the cross origin attribute and the as, we
    would send credentials

    Ilya: if I do a preload with as image, no credentials. if I add
    crossorigin, we'll add them

    plh: maybe we should say that preload is equivalent to adding
    an image

    nick: can we list what it means to be equivalent?

    plh: we would be duplicating other specs by doing so.
    ... not the right approach imho

    yoav: the only difference here is that these fetch don't block
    and can start early
    ... header based csp are taking into account

    Ilya: we don't say that we process the csp headers are
    processed atomically

    <plh>
    [20]http://www.w3.org/TR/resource-hints/#security-and-privacy

      [20] http://www.w3.org/TR/resource-hints/#security-and-privacy

    yoav: csp can prevent from the preload to happen
    ... csp is about protecting the html, not the link headers

    Ilya: if you start touse link headers, you should move the csp
    into link headers as well

    Ilya: fetch was updated to add a check at the exit
    ... the ordering of link/meta between preload and csp isn't
    relevant. the implementation may do preemptive fetch on preload
    and have to discard it because of csp
    ... the question here because the impact on caching

Beacon

    Ilya: step 10 of processing model
    ... the mode is "CORS"
    ... it means the origin you send the request must respond with
    two headers
    ... ... we don't care about the response
    ... we should change it not to use "CORS"
    ... we need to check that we're not breaking anything
    ... otherwise we're forcing the origin to respond with dynamic
    headers

    Todd: indeed, it's unecessary
    ... for the spec, you would preflight and not send the POST

    Ilya: there could be a beacon-age
    ... that nobody implements
    ... but it would force a preflight
    ... it also depends on the content type
    ... a blob would trigger a preflight

    nick: form submission implies no new headers
    ... so due to beacon-age and content type, we're increasing the
    potential attack area
    ... servers have to accomodate POST request from crossorigin
    that look like post submission
    ... but if you get things that aren't like post submission,
    that's different

    yoav: I've never seen crf protection as a strick headers check

    nick: the conditions we have in cors. we're changing the
    assumption on form submissions.

    yoav: can we include the beacon age in the data?

    plh: no because we allow abitrary post

    Todd: if we remove beacon-age and restrict to form-data, we are
    the same as forms

    nick: it wouldn't create new attack surfaces indeed

    plh: are we llike xhr then?

    yoav: no, because of cors

    nick: you could force cors, ie preflight request

    Todd: can we make it beacon age a simple header?

    nick: user agents dont preflight in case of new headers
    ... (according to Jonas)

    Ilya: we should clarify beacon-age with respect with user
    agents added headers
    ... are user agent addefd headers treated simple headers

    <plh> (that's issue 1)

    Todd: should we only send form-data , even if it's a blob?

    nick: that seems confusing

    Ilya: I don't think we have telemetry on media type usage for
    beacon
    ... half the time, people just send a uri
    ... the whole payload thing isn't used

    Todd: folks with more advanced payload are probably sending
    json

    Ilya: the fetch spec doesn't do anything smart with json object

    Todd: ie you're responsible for the serilization and then fetch
    send a string

    Ilya: correct

    nick: if you send a different content type, you culd incurred
    the preflight

    Todd: cost is non-trivial

    Ilya: current implementation aren't doing preflight
    ... if type comes from a blob

    plh: so we're breaking CORS and fetch specs then

    yoav: I understand when you don't arbitrary headers, but the
    mime types...
    ... I think the restriction on mime types is uncessary

    plh: we should stop by the webapp secs
    ... and talk about this over with them

    <plh> [Todd is updating
    [21]https://github.com/w3c/beacon/issues/10 ]

      [21] https://github.com/w3c/beacon/issues/10

    nick: [22]https://github.com/w3c/beacon/issues/9

      [22] https://github.com/w3c/beacon/issues/9

    nick: "This specification defines an interoperable means for
    site developers to asynchronously transfer small HTTP data from
    the User Agent to a web server."
    ... doesn't say what the spec does

    editorial comments in this email:
    [23]https://lists.w3.org/Archives/Public/public-web-perf/2014Ju
    l/0109.html

      [23] 
https://lists.w3.org/Archives/Public/public-web-perf/2014Jul/0109.html

    not small and "asynchronous" doesn't quite capture what the
    spec is about

    nick: separate privacy considerations from security
    considerations
    ... privacy concern is the browser making a request on you
    behalf after you closed the page
    ... are the users going to be aware of that?

    <plh> .... similar geafencing
    ... you might have a different IP adress
    ... we had a discussion about this in web platform yesterday
    but no conclusion
    ... at the very least, we should mention it in the privacy
    section

    Ilya: we don't want to block on unload
    .... ie avoid sync XHR
    ... you can use beacon to send things every 2 hours

    Todd: with beacon-age, you have the ability to send it much
    later
    ... but no one implements it

    nick: we need some guidances to implementrs on what to tell the
    users when sending a quest after the close

    yoav: how is that different from background syncs in service
    workers?

    nick: same issue :)

    Todd: it may be simplier to spec it down for the short term

    Ilya: agents could pile up beacons to wait for the next network
    request

    Ilya: perharps we should more clearly define beacon-age?
    ... what are the use cases for beacon age?

    nick: the processing model speaks about multiple attempts

    Todd: but with service workers, it seems handled now

    plh: at the minimum, we should say it's sent after the close

    nick: even if we say it's equivalent to an existing practice,
    it would affect users

    nick: do UAs have the option to desactivate beacon?

    plh: no, like we don't have the option to desactivate XHR.
    Beacon is generic, not restricted to telemetry data

    Ilya: we limit body size in chrome

    nick: if it's only used for telemetry, what do you do in
    private mode?
    ... you might want to add a note in privacy sectio that you
    considered the case of giving the user the ability to
    desactivate beacons and decided against it.
    ... I'm not sure you want to say that the user can't have the
    ability to deactivate it, just because it's obviously true that
    user agents can turn off beacon functionality or do whatever
    the user wants
    ... but you could explain why you're not putting conditions on
    when Beacon is used, because you think there is an advantage to
    users on the whole

    Ilya: btw, our size limit is 64Kb

Network Error Logging

    looking at the open issues

    ilya: how are the NEL requests treated? client requests?
    ... NEL. you as an origin have registered to receive error
    reports
    ... some site embeds your widget, and you want to know when
    your social media widget has failed to load
    ... but if the embedding site has a service worker that
    intercepts requests
    ... the service worker might pass through the request, which
    might fail
    ... the report shouldn't be sent to the embedding site owner,
    but to the widget owner
    ... any other report should be treated as client requests which
    bypass service workers

    todd: should we go over network error logging in more detail?

    ilya: lots of things could go wrong: DNS failures, route
    issues, etc. you as a site owner have no way to observe that
    this failure happened
    ... large vendors have nodes around the world that will ping
    their site to try to identify these failures and work around
    them
    ... NEL is supposed to notify you that we have failed to reach
    your site
    ... specify a report-uri on a first successful reach, the
    report-uri should be a different domain, on a different subnet,
    etc.

    Bartek: would be good to have more than one endpoint

    ilya: yes, we do support that, with fallback through the list
    ... modified after HSTS, can note that it applies to all
    subdomains as well
    ... a well-structured report of failure, including the
    resolving IP address

    Bartek: have a list of items in notes that I would like in
    addition

    todd: would be great to have those as Github issues

    ilya: are the errors that we define here reasonable?
    ... this is restricted to HTTPS origins, and the report
    location must also be HTTPS

    [note, "trustworthy origins" is out of date terminology]

    ilya: noticed that we have multiple places in the Web platform
    that are delivering reports
    ... would like to extract that into one common thing, a group
    of report uris
    ... then other specs can reference this to say, "queue a report
    to group Security"

    todd: privacy questions regarding these general out of band
    reporting mechanisms?

    npdoty: sure, it was debated regarding csp, for example

    plh: we could say for this spec, the user agent should provide
    a way to disable NEL
    ... worth it to mention in the NEL spec that user agents should
    provide a way to disable NEL reports
    ... question about whether SHOULD or MAY

    ilya: the out of band reporting just has general restrictions,
    like clearing the cache
    ... but for particular specs that have reporting, they should
    specify when to send requests, when they might not want to
    ... the general out of band reporting is just under mkwest's
    repo for now

    Bartek: what if we have reporting list not as a fallback, but
    simultaneous to more endpoints for auditing purposes?

    ilya: could you do that yourself?

    Bartek: you could, and it would be more efficient, but auditors
    might want independent reports
    ... for example, if ads are served from within our origin

    ilya: the fact that the user agent delivers it doesn't make it
    provably, just a convenience
    ... wouldn't want to open it up to a very large list

    Bartek: potentially lack of trust between parties

    todd: if there are particular regulatory requirements, that
    might make it easier
    ... what if we had a concrete number: 2 or 3

    npdoty: can we provide the assumption that error reporting
    uri's should be common across users? if so, it would make it
    easier to detect abuse for supercookies

    ilya: there are use cases where you would want the value to
    differ, between regions, for example

    bartek__: could also have the report-uri in the DNS record (as
    a TXT record, say)
    ... as a fallback if you never successfully reached the server

    ilya: interesting, please raise

    todd: could ship with a pre-loaded list in browsers, like with
    HSTS pre-load list

    bartek__: dns should be considered as a fallback, just in case
    you can't load the policy on first load

    [humorous tangent about how much policy can be pushed into DNS
    records]

    ilya: don't typically load all DNS TXT records

    npdoty: but would only need to when you had a network failure
    ... DNS doesn't give you the security of HTTPS

    ilya: yeah, so DNSSEC?
    ... some information is reported that others wouldn't have
    received

Primer

    <xiaoqian> primer ->
    [24]http://siusin.github.io/perf-timing-primer/

      [24] http://www.w3.org/ip

    <igrigorik> Andy's waterfall repo:
    [25]https://github.com/andydavies/waterfall

      [25] https://github.com/andydavies/waterfall

    <igrigorik> [26]https://github.com/addyosmani/timing.js/

      [26] https://github.com/addyosmani/timing.js/

    plh: should we use perf observers in examples?

    Ilya: let's rule that we need at least one shipping
    implementation before we use those in the primer

    Xiaoqian: should I list/describe every attribute for entries?

    plh: nope. goal is intro here. folks should look at specs for
    list/description

    TODO: update graphics, add links to caniuse, add link to
    timing.js, add one sentence or two on frame timing and server
    timing, then ship

CustomPerformanceEntry

    Ilya: how about we allow apps to add their own performance
    entry objects in the timeline so that one can observe those?

    Todd: that would allow the use case of adding your own payload
    to an entry
    ... sounds cool
    ... and it cleans up the story around clear*

    plh: we should open an issue/feature request

    Ilya: I'll open one

    <igrigorik> [27]https://github.com/w3c/user-timing/issues/3

      [27] https://github.com/w3c/user-timing/issues/3

    Ilya: but it means we would allow huge payload into the
    observers and those are doing deep clones...

    Todd: that's actually a diff between Edge and Chrome/FF in
    getEntries*. Edge does a deep clone before returning the
    entries, others don't.

redirects

    Ilya: besides security/privacy, what's the hold?

    Todd: not a high priority

    Ilya: we already reveal the fact that there was at least on
    redirect (since we return 0)
    ... but we don't say how many

    plh: is this what you meant? -> //TAO only Redirect Timing{ URL
    }

    Ilya: Not exactly.

    yoav: just the entries

    plh: Resource Timing{
    ... redirectCount;
    ... redirect URL
    ... }
    ... if I have two with the same name

    yoav: you can link everything back together
    ... If you go to HTTP server, we can expose it
    ... expose Redirect there will be a concern

    todd: you couldn't make guess

    plh: change 2 attrs only, redirectend and redirect start

    Ilya: yeah, drop them

    todd: you are also missing info about the chain

    yoav: if redirect, you can change your cookie

    plh: if I have a redirect in the middle

    Ilya: it will take longer

    plh: I won’t get url in the end, so I won’t expose that

    yoav: you can measure the time you took
    ... if you want to avoid this expose privacy problem, you will
    have to remove from a lot html

    todd: that’s why we hide a lot of redirects
    ... image people are choosing to expose, can we add the
    feature?
    ... if a website choose redirect as feature...
    ... can you get the data? with xhr?

    Yoav: if you site tell you to expose, redirects maybe the same
    pattern
    ... TAO is already used today

    Todd: Google phone has already turn TAO on

    Yoav: If FB has no interest to expose TAO

    Ilya: their widget do

    Yoav: if we review all the redirect there, will it be private
    proper?
    ... let bring it to the Security folks

    todd: strange to turn it on... go to log in server, use cookie,
    user redirect just not enough

    Ilya: this question is a block of a lot of others
    ... privacy issue will be a major change to the API

    todd: I'd not recommend change the API in this way, what about
    NT-2?

    plh: unless we are told NT do not get into the buffer

    todd: more entries?

    Ilya: back cases are ad force users to change
    ... when you click those links, you are force to change

    plh: any option is not to change RT and NT, and provide another
    entry
    ... listen to resource, will have to do sth to get redirect

    todd: have buffer on server time

    Ilya: leave it as it is
    ... for those new to the API, just look at Observer

    Todd: yeah, historical reasons

    plh: entry type for redirect will be what?

    Ilya: resource
    ... call it a new thing?

    Todd: that will cause sudden changes for redirects in timeline
    ... RT with TAO, if no TAO, no redirects

    plh: keep redirectCount in RT

    Ilya: we need a new name

    plh: get a R-entry for A

    Ilya: B, C will never be seem today, name for B's entry will
    have some info about A

    plh: if a is a fetch start C

    Ilya: it should be the fetch start of A

    yoav: people will assume that /TR is not the latest draft

    plh: that's not true with the auto-publication system

Priorities and next charter

    plh: our goal is try to apply the auto-pub system and have as
    less worry as possible

    todd: which are the spec we want to move?

    plh: hr-2, pr-2

    todd: pr-2 is a clean up for the failures in pr-1?
    ... how about RT?

    plh: never shipped a level 1

    todd: but 3 vendors implement it

    plh: but it relies on PR-2, may need a clean-up version, but
    not touch the ED

    Todd: User Timing? 3 implementations

    plh: That's already a REC
    ... UT-2, same as RT, need a subset

    Todd: already UT REC, not sure that's necessary to subset UT
    ... for the specs blocked by performance Observer, how long do
    we need to wait?

    Ilya: We don't know the intention of Moz yet

    plh: HR-2, need a test for worker. PR-2, need to clean up the
    test suite

    Todd: We have written quite a few test in the past 6 month,
    we'd like to share them with W3C
    ... but there are a lot of spec corner cases in those cases

    plh: Do we want to write test case for corner cases?
    ... Beacon, will need to write another python parser under
    w-p-t
    ... I will need to fire an issue, and James will add support
    for that

    yoav: there are some blink test for Beacon. How do you get
    resource response in w-p-t?

    plh: I wrote a test that can explain the process

    Ilya: RIC, no update on implementation

    Todd: It's on my list
    ... Beacon in apps, what if it's closed? f.ex. WebView

    Ilya: Independent to vendors

    Todd: Resource Hints...

    plh: How can we prove implementation?
    ... how about a pre-fetch from the server?

    todd: browsers can be triggered...

    yoav: pre-connect should be a separate host

    todd: need a new case for each attribute

    plh: We'll need commends from WebDriver folks

    Todd: pre-fetch and pre-render are implemented by Firefox

    plh: Is it possible for you to write a query for the usage?

    Todd: not sure
    ... pre-connect smells the highest one

    Ilya: It isn't ready yet
    ... the issue refers to Fetch

    todd: same as SW

    Ilya: Telconf ... any complain?

    Yoav: I can do later

    todd: it's difficult to schedule a time from Asia and the
    chairs

    resolve: 1 hour early

    todd: we should switch goal for the next charter

    Ilya: we got feedback from Moz

    plh: we can do some minor update, add the primer

    todd: and Memory API

    Ilya: we should start from use cases

    yoav: let's create a report and collect use cases

    Ilya: a general use case report

    plh: we have a repo for WebPerf, which is a good place for that
    report

Summary of Action Items

    [NEW] ACTION: plh to clean up frame timing [recorded in
    [28]http://www.w3.org/2015/10/26-webperf-minutes.html#action01]
    [NEW] ACTION: plh to look into testing prerender in Page
    Visibility [recorded in
    [29]http://www.w3.org/2015/10/26-webperf-minutes.html#action02]
    [NEW] ACTION: plh to publish PV2 [recorded in
    [30]http://www.w3.org/2015/10/26-webperf-minutes.html#action03]
Received on Wednesday, 28 October 2015 18:09:06 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 28 October 2015 18:09:06 UTC