See also: IRC log
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 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].
<plh> 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 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> 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 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].
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
... 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
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> 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
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 https://github.com/w3c/beacon/issues/10 ]
nick: 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: 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
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
<xiaoqian> primer -> http://siusin.github.io/perf-timing-primer/
<igrigorik> Andy's waterfall repo: https://github.com/andydavies/waterfall
<igrigorik> 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
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> 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.
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
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