TPAC Web Performance WG meeting -- 22 Sep 2016

inconsistent implementation of Timing-Allow-Origin

igrigorik: background
... it doesn't allow '*'

annevk: yep, you can't use '*'

igrigorik: we did some tests. some sites use workers. that's why we need that.
... do we need to introduce syntax?
... test to allow two origins, Chrome doesn't work.
... Firefox combine both headers with comma and then time origins don't work
... should we change the spec definition?

yoav: We need to change all implementations in that way

annevk: That's going to happen

igrigorik: In RT, use the origin-list-or-null definition from rfc6454

annevk: That's fine
... suggest you should discuss with WebAppSec folks about this solution

RESOLUTION: Update TAO to #( origin-or-null / wildcard )

annevk: the other thing about TAO is you don't require that... worth checking
... we should integrate with Fetch to make sure that works

igrigorik: right, maybe set Level 2 stuff

Beacon integration with Fetch API

<annevk> The other thing about TAO was about redirect handling, but it seems the semantics do match CORS there

igrigorik: if we do post, your Fetch may stop twice
... when we define Beacon, we have note for reasonable size
... we can do streams, if the environment obj goes away

toddreifsteck: if the stream have not finish when the environment obj ends, that's the problem

igrigorik: should we consider not allow stream

annevk: sounds ok, some one needs to define the process model

toddreifsteck: if we get this to work, for old browsers, there should be a fallback

annevk: we haven't added it to the spec, depends on the GC

igrigorik: if we are going to throw the error

annevk: type error perhaps
... should be able to expose more detail

igrigorik: would be good to have more detail from fetch

toddreifsteck: RT is some browsers has problems on this

igrigorik: it might help to get CORS information
... for same origins, we don't open more connection

annevk: if there are connection error, just expose one bit

igrigorik: if you using same orgins, you already open the DNS

toddreifsteck: do we need to add some to fetch to get information for the body?

annevk: that design was wrong, only the first argument make sense to me

yoav: Do we want a separate flag for Beacon?

[yes]

rniwa: What's the timing for send beacon?

igrigorik: when page is closed, all requests must be sent

annevk: Should the flag tie to keep-alive?

igrigorik: we don't want to over specify it, in v1 keep it simple and allow UA to implement it

rniwa: keep-alive might involve delay

annevk: it don't allow initiating new Fetch
... so should be a problem

toddreifsteck: we have keep-alive as a short term flag we should add to
... does the developers use coalescing?

n8s: perhaps, once it's enable

toddreifsteck: we should keep on the discussion for coalescing

Mechanism to translate timestamps between globals

https://github.com/w3c/hr-time/pull/29 background

igrigorik: we exposed HR time, which is useful for many use cases
... we also have time origin, for worker, it's fine as it has its own time origin
... but you will get difference value if you have many workers along the timeline
... question is how to translate the time stamp between workers

toddreifsteck: there's a lot of trade off

igrigorik: opt1 -> see fig.
... we need a timestamp to tell you what is the zero time

bz: date time doesn't affect date now, when it change timezone

igrigorik: is it a problem to expose the whole timeline?

rniwa: might be a problem
... you need to set it as a top level changes

toddreifsteck: why/

rniwa: most UA isolate iframes, when the monotonic clock starts, it will...

igrigorik: opt2. use a pick obj, and get a timeOrigin back
... then figure out what's the offset

n8s: when you post message in the SW, if the window is not ready

bz: the SW will set zero offset before sending
... it can still send the message
... what will the SW do about the global offset?

n8s: the window can separately upload the data

toddreifsteck: windows can collaborate things

igrigorik: what we need is a HR timestamp to coordinate

yoav: if we expose the timestamp, can we reset and start over for privacy need?

bz: global timeline, is it cross origin?

toddreifsteck: UAs use fingerprints

bz: to implement, browsers start a monotonic clock
... create timestamp

yoav: if the users have change the clock between the stamps were created
... the offset between those clock

toddreifsteck: is it an important leap but?

igrigorik: we don't need to visit it twice
... the zero of the global clock

rniwa: in the current world, you can reset it

yoav: no... cross site, SW

rniwa: iframes for the same origin, you don't expose it, right?

igrigorik: how do you implement it?

rniwa: hash map?

toddreifsteck: fingerprint, is it reusable?

rniwa: it's trackable

bz: we have two clocks which is in-sync
... it's unreliable if the clocks start drifting

toddreifsteck: currently it's visible to the pages

bz: for the prospect of browser, only system clocks available

rniwa: there may be a timing attack

igrigorik: some browser will limit the HR time to ms

toddreifsteck: you can make it close to HRtime now

yoav: we are not 100% sure there will be privacy concern

n8s: if there's time attack, perhaps you want less data

toddreifsteck: this explosion doesn't add anything to the concern of time attack

igrigorik: if you already in the top level, you can grab and send

rniwa: you do need other origin to cooperate with you

igrigorik: I'm not convince there will be privacy concern
... we expose something, we are not sure it's bad or not

rniwa: how do you want to coordinate the time between the different processes?

bz: each process will have its own zero time and offset

yoav: can they be sync once in a while?

bz: donno

rniwa: if one of the monotonic clock drifts, how do you collaborate?

yoav: correct your measurement once drifting

toddreifsteck: Is it actually a thing that happen significantly often in reality?
... we say "could"

yoav: when you reset your computer

rniwa: I don't have more information, only a concern

toddreifsteck: in windows, resetting only happen in a long period of time

igrigorik: does this give us any improvement to expose the drift?

yoav: you will be able to correct the drift only no process if holding the obj
... if you correct the drift, all the translations will excuse

rniwa: what if you kept a bunch of timestamps, how will you translate them?

bz: every time you create a time origin...

toddreifsteck: there's a method in windows

igrigorik: we have a global time clock...

bz: it will be heavy performance price

igrigorik: we can't solve it without the support of lower level

bz: they can sync up in some way
... what's problem are we going to solve with time origin?
... have a nice API

toddreifsteck: this only help solve fingerprints with tracking

igrigorik: perhaps we should go to the security team

toddreifsteck: we shouldn't hold the shipping just because the sec team is not sure
... if everyone just add their offset to the timeline, perhaps is the simplest way

igrigorik: send it in a global time?

toddreifsteck: You have a JS client, your code is running on the client, does it make it easier to grab the info and send it to the cloud?

igrigorik: when is the message be pushed?
... either the sender and receiver can do the translation
... if receiver do the translation, that will clarify it a bit

rniwa: You don't want to translate the time before sending...
... if the tracking concern is not an issue
... you don't have to do anything except sending the data

igrigorik: How does this API work with SPA?

keiji: if there's a new page view

igrigorik: Should be a concept for multiple time origins?

nolanlawson: the platform has the ability to offer performance.now

toddreifsteck: performance.mark works

n8s: marking RT seems be worry

bz: the only thing changes is the final calculation
... once you allow resetting performance.now

igrigorik: the SPA discussion will affect the above time-origin issue
... for purpose of translate time, we move forward with that
... expose an attribute that give you the global time
... we can close that and also update the privacy discussion

toddreifsteck: and info the sec people we are going to ship it

bz: send some mails to the sec people

shubhiepanicker: yep, continue the SPA discussion, with more use cases

User-Timing: SYNTAX_ERR exception

https://github.com/w3c/user-timing/issues/1 -> background

igrigorik: suggest we freeze the list of attributes on NT1 and move on

toddreifsteck: if you parse a string, that doesn't match anything, that's the case it will throw

SPA apps and Perf APIs

shubhiepanicker: Developers detect the navigation, loading, ..., by guessing
... it makes sense to provide APIs on it
... it could be a new thing, to expose these informations
... even you ask the users to annotate it, they wont

Performance Timeline case sensitivity issue

background

plh: [test results]
... getEntriesByName is worse, the implementations are consistent

yoav: I'd expect that's a string comparison

annevk: if you give the input to two places, e.g., one is fetch, they wont find it
... there's no way to tell if it's a URL or not
... sad but reasonable
... perhaps parse the URL, if it fails, treat it as somethings else; otherwise serialize it
... for future, try to make it enum

toddreifsteck: in Javascript, when you create an object, if you add attributes in it, they are case sensitive

igrigorik: Chrome is case insensitive for type

annevk: in general, you want to do case sensitive
... URL are kind of case insensitive

<scribe> ACTION: plh to update the test, and the pull request [recorded in http://www.w3.org/2016/09/22-webperf-minutes.html#action01]

<trackbot> Created ACTION-172 - Update the test, and the pull request [on Philippe Le Hégaret - due 2016-09-29].

yoav: Do we need to figure out the usage before changing the behaviour?

igrigorik: I'll make the argument

shubhiepanicker: developers have no way to identify

toddreifsteck: How to make the existed things good enough?

yoav: what's missing?
... when navigation started, third party provider can not detect it
... when is the page loaded
... finish painting...

nolanlawson: anything require users to write code can be done with polyfill
... prefer to talk about those can't be done by polypill

igrigorik: for SPA, when there's a react, it relies on what's the platform
... it will be nice to have easier way to detect this kind of information

keiji: How expensive is this?

toddreifsteck: SPA observer?
... make a list, and then see what can we do

rniwa: end of loading for some apps is difficult to identify

yoav: hash change?

paul: developers might choose to push once

nolanlawson: perhaps some events to notify XHR loading is over

yoav: network idle?

toddreifsteck: we need more data to talk about this topic

rniwa: implementation for each application differs, difficult to identify navigation starts or ends

shubhiepanicker: reasonable to go back to talk to them

toddreifsteck: invite them to the call on Wed
... we would like to solve the problem

rniwa: we need to define the problem and use cases
... e.g. if there's SW, do they want to info about the things inside SW

shubhiepanicker: we shouldn't come up with complexity metrics

toddreifsteck: there are some information that only the apps can tell

igrigorik: we have to agree on what the things are

rniwa: when network starts, if there are still plenty of dependencies...

toddreifsteck: elements on long tasks

paul_irish: we are already talking about supporting showing user timing and time line

igrigorik: it's excited to get user timing visible

toddreifsteck: do we want to prefix it?
... spa-*?

yoav: make them more meaningful

paul_irish: some apps have lots of mark names

nolanlawson: dev tools should have that

paul_irish: yep, especially for Web Components
... you visually see the name

igrigorik: you can subscribe to the events, and get it to the timeline

nolanlawson: so the hash change is there... sounds like an easy win

toddreifsteck: Do you want the info in the PerfObserver?
... cons and pos

nolanlawson: if you use push state, if you use refreshing, there nothing in the server

rniwa: you can still use hash and benefit from it

yoav: they are using hash to track changes for the server list things...

rniwa: there's no reason keep using hash

<rniwa> because pushState and popState has the same capability as overriding location.hash.

igrigorik: I'll open bugs on the repo and we can continue the discussion
... should we introduce some structure data expect for the nicks in user timing?
... provide some ways to register a mark on the timeline?

yoav: there is no other space on the timeline

rniwa: once you do that, you will have an API for the browsers to get name and so on.

paul_irish: custom type is prefer

rniwa: perhaps more natural to sub-category

igrigorik: any metrics with spa- will be paint in different colour?

rniwa: [fig 2.]

igrigorik: we need convention for the timeline to identify those names
... having these information will make the timeline more useful

rniwa: we should have the option for the perf marks to be added to the timeline

Battery usage, CPU usage, Device properties

n8s: we should come up with a good defination

toddreifsteck: NetInfo is current in WICG

https://wicg.github.io/netinfo/ -> NetInfo

igrigorik: NetInfo exposes connection type

n8s: most people is always on 3G, but the speed is hard to detect

igrigorik: one problem is we don't want to send user video when they are in 3G

n8s: yep, for the cost

rniwa: why does the connection type help?

n8s: we have a connection class lib, we open source it

toddreifsteck: browsers should have it

yoav: it tell you something, but not everything

rniwa: perhaps just look at your TCP

igrigorik: we have product using this api

n8s: yep, we use connection class to detect information e.g. how long does the TCP lasts

<nolanlawson> facebook connection class: https://github.com/facebook/network-connection-class

<yoav> I wrote a bit on that in the past: https://blog.yoav.ws/adapting_without_assumptions/

igrigorik: what people is a magical solution, but it's impossible to provide everything
... NetInfo is part of this solution

toddreifsteck: using both RT and NetInfo together... you might get something closed

yoav: we wouldn't be able to offer precise info about bandwidth, for privacy reasons

igrigorik: Battery API works in Chrome

n8s: connection and CPU are the big ones

yoav: Apps like Uber considered Battery as big thing

toddreifsteck: Battery is not something web developers will consider in a common case

igrigorik: there's an attribute about the time info of battery

toddreifsteck: perhaps remind the status about the battery when they request expensive actions

GuidoGrassel: that will be a very helpful information to write good apps

igrigorik: AT&T has a tool to give you an estimate about the battery status

toddreifsteck: the start status, and the end status

igrigorik: when it comes to isolation

rniwa: the definition for good shape, i.e. 10%, can differ from the prospect of user and UA
... wouldn't it better for the system to notify the user?
... because the browser may not be the main reason

yoav: low power will be interesting to expose

shubhiepanicker: it's good enough to provide a signal for the users
... the problem is how to measure

igrigorik: largest consumer is screen, 2nd is network

rniwa: we don't want to update these datas too frequently for the cost

igrigorik: if memory is low, do you get notification?

rniwa: yes
... notify whenever the status changes

<rniwa> The proposal was to have three states: memory usage is low, high, and critical

toddreifsteck: modern OS acts similarly

<rniwa> And page gets a notification whenever the status changes

nolanlawson: Do we need normal?

yoav: if you are at low, you would like to know if you are out of low

rniwa: in iOS it's difficult to get the critical moment

toddreifsteck: same as windows

rniwa: you only get notified if you are about to be killed

toddreifsteck: I hope to have these in all browsers

rniwa: memory is the most frequency crash reason for us, good to have these

igrigorik: Chrome will exposed some inform, but only in window, not worker

toddreifsteck: this is the warning API

igrigorik: it's useful to have high pressure warning

yoav: start a thread on WICG to get more feedback

igrigorik: last f2f meeting we agreed on to ask feedback from the sec team to see if it's reasonable

rniwa: yes it's

n8s: you can only consider the case in the same network

toddreifsteck: If I'm using 2M memory, which is high, do we want to trigger a callback?

rniwa: fire if it's not normal at the first time

yoav: if we want to add a memory hint using service worker...

n8s: it will be helpful to ask the best case

rniwa: the browser can't determine it

toddreifsteck: Would perfect not get to high too soon

rniwa: when you open the browser and watch video, if you have kill all background, by using high memory you will get low memory
... we don't know why the browser is in high memory at the first place
... best start from the low state

toddreifsteck: You don't get a memory hint at the beginning of the work

igrigorik: if you are in a low memory device, does the system immediate send a notification?

n8s: you can always create the baseline

yoav: targeting at developing countries, for low memory devices, by doing progressive enhancement, if browser support advanced API, it must be with high memory...
... hard work can't determine the memory state
... if you are running canvas and workers, if it's doable

n8s: FB classify devices by years

rniwa: what would that be if we expose something here?

n8s: information about the best case is sufficient

toddreifsteck: if you are native app, can you detect this?
... is the processor status available to the apps?

igrigorik: getCPUInfo, get MemoryInfo ... and compose these informs

<nolanlawson> facebook device-year-class: https://github.com/facebook/device-year-class

toddreifsteck: collect these informations and jump to the relevant status

rniwa: don't like the idea to keep updating the definition of low-end and high-end

yoav: the app used to work on this phone, when the browser get updated

n8s: perhaps based on numbers

<scribe> ACTION: n8s to write a proposal on processor speed & memory [recorded in http://www.w3.org/2016/09/22-webperf-minutes.html#action02]

<trackbot> Created ACTION-173 - Write a proposal on processor speed & memory [on Nathan Schloss - due 2016-09-29].

igrigorik: the apps get killed when the tab crashes

toddreifsteck: do we need to report back somehow?

igrigorik: nice to know if the apps get killed

n8s: yep, when the browser is doing a clean up
... will it help if SW can kill or report?

igrigorik: good to know if app is getting killed

nolanlawson: Do a sendBeacon if the app get killed, but SW sounds a better solution

igrigorik: please use page visibility instead of onload on these ...
... unload is not reliable

toddreifsteck: would like to deepen the crash thing when we are clear about reporting

rniwa: if the page keep crashing, we might refuse to load

nolanlawson: may be valuable to have information why the page crashes

n8s: that will involve more work
... get feedback that drifting between time origins (unix) shouldn't be a big issue

- DRAFT -

TPAC Web Performance WG meeting

22 Sep 2016

Attendees

Contents