-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cross-origin timeline support #207
Comments
It seems to me that not exposing these entries to One of the main reasons we (RUM provider / boomerang.js) still rely on Once |
I've moved the synchronous |
Just to reillustrate my question in the call - Looks like in the current proposal, documents can broadcast any entries which means entries that were broadcasted from a different window can also be broadcasted out. Consider a case where A embeds B and B embeds C, B can broadcast entries from C to A, even if C only specifies B explicitly. I think this needs be handled by the proposal such that A can only receive entries from subdocuments that specifies A explicitly. |
If C exposes its entries to B, it trusts B to not abuse that privilege. B can then communicate this data by many means to A, even if we block broadcasting in this particular API. |
That's true, but this still might be a footgun if developers have to remember to not rebroadcast entries that they received from their own children, in order to not cause a cascade of entries up the tree. It might make sense to just drop any entries from the list which have a |
What I meant to say is that given that the information can be shared by other means, there's no security benefit from blocking its broadcast. (but there may be ergonomic ones - e.g. enable C to only broadcast to B and not elsewhere) |
For posterity, we had discussed this in the April 13th, 2023 W3C WebPerf call. Notes: https://docs.google.com/document/d/1fIgfd7ONz-sES55qRFHQI_eQUnynnyX2Asrs-cwAQ_Q/edit# |
Yeah, so effectively once you allow someone to read your timeline, then it's up to the other player to not doing evil things. And this sounds bad... |
#202 has been open for a while, but we should really have an issue for larger discussion :)
The overall plan is roughly as specified in Cross-frame Performance Timeline, which is:
source
reference on timeline entries which points to thewindow
of the frame where they originatedThe current concrete proposal for each of these is:
PerformanceObserverInit
gains one new key:includeFrames
. This is a boolean, defaulting to false, and can be used like this:share-performance-timeline-with
, which takes a list of origins (possibly*
) with which the framed document consents to share its timeline entries. Examples of its usage would look like:source
member ofPerformanceEntry
refers to thewindow
of the frame in which the entry was generated.It is an open question whether we want to, or can support this functionality on the synchronous timeline API methods
getEntries
,getEntriesByName
andgetEntriesByType
. Because it requires cross-origin communication, this almost certainly would have to block while waiting for a response from child frames, possibly for a long time.Those APIs may be useful, and are often easier to use than the
PerformanceObserver
API, but it may not be worth making them slower to support cross-origin frames. People who are writing new code to gather that data could just be encouraged to migrate toPerformanceObserver
at the same time.The text was updated successfully, but these errors were encountered: