Marker & security.

[ArthurSonzogni]

We discussed this morning about the new marker proposal: https://github.com/w3ctag/design-reviews/issues/682

My understanding is that it gives developers the capability to know if below the deepest frame of JS execution (same-origin or CORS), there are frames associated with GC, style, layout, paint, ...

In the absence of JS execution on the current stack, those new tasks are also reported, which allows observing what the web browser do in the general scope.

"GC" and maybe "paint" may be maliciously used to leak informations about cross-origin opaque resources owned by the document, or activities of other cross-origin documents hosted by the same process. At the margin, maybe also some cross-process activity if GC correlates with memory pressure?

@shhnjk security review: https://github.com/shhnjk/shhnjk.github.io/tree/main/investigations/js-self-profiling#conclusion showed we don't have to require cross-origin isolation on the original JS self-profiling proposal. Here, markers change the previous assumptions. I was wondering what kind of decision you were going to take here and what others think about it.

[ArthurSonzogni]

+CC @shhnjk, @arturjanc

[cnpsc]

Thanks for the feedback @ArthurSonzogni.

"GC" and maybe "paint" may be maliciously used to leak informations about cross-origin opaque resources owned by the document, or activities of other cross-origin documents hosted by the same process. At the margin, maybe also some cross-process activity if GC correlates with memory pressure?

For markers attributable to a document such as style, layout and paint, implementers may only attach the corresponding marker if the responsible document is same origin with the Profiler.

Since GC is not attributable to an origin, we could potentially mitigate information leakage by requesting cross-origin isolation to surface GC markers. Regarding cross process activity, is it possible to monitor GC activity with existing features such as weak-ref or Measure-memory ?

[ArthurSonzogni]

For markers attributable to a document such as style, layout and paint, implementers may only attach the corresponding marker if the responsible document is same origin with the Profiler.

Yes, I agree filtering those tasks with "who" is the responsible document is necessary to prevent one document from spying on the other. I think it might be the case with 'paint' tasks when two cross-origin same-site documents are loaded together in the same process.

I am not very knowledgeable about style/layout/paint events, so not totally confident this is going to be sufficient after that. I remember outside of GC events, @arturjanc talked about 'paint' event that might be dangerous to expose as is. Would you remember what you had in mind?

Since GC is not attributable to an origin, we could potentially mitigate information leakage by requesting cross-origin isolation to surface GC markers.

I think that should be sufficient, since cross-origin-isolation implies everything loaded in the process can be read from any origins, and every document/subresources have explicitly agreed being put in this position. From there, surfacing the GC activity probably doesn't give additional leverage.

Regarding cross process activity, is it possible to monitor GC activity with existing features such as weak-ref or Measure-memory ?

Yes, I believe you can probably correlate global memory pressure with its effects on weakRef or performance.measureMemory(). I think I agree with that.

[cnpsc]

Thanks for the details @ArthurSonzogni I'm assuming that the pain event issue may be related to exposing a proxy to the time taken to render an opaque origin resource that wouldn't pass the TAO check. Similar consideration are discussed for the Element Timing API https://wicg.github.io/element-timing/#sec-security where it is mentioned that such attack is possible but impractical today. CCing @chrishtr it would be awesome if you could help us identify a POC to discuss those concerns.

With the consideration that each UA limit the minimum sampling interval I wonder if adding a paint tag can be considered a new practical attack compared to the existing method.

[chrishtr]

@npm1 (co-editor of Element Timing) is a good contact for further questions.

[npm1]

In Element Timing, we do not expose the render time of the image if the TAO checks don't pass. That said, you can already obtain image decoding times via decode(), see https://github.com/WICG/element-timing/issues/65.

I guess the question here is whether the paint of two documents hosted within the same renderer process happens in the same task or in separate tasks. If it happens in the same task then this API would leak some additional information (although the attacks you could create from that seem kinda fuzzy to me at the moment). This is a question for the paint team, no?

[ArthurSonzogni]

Hi, Are you going to gate the whole extension behind cross-origin isolation, or just some kind of tasks like GC?

I believe you need cross-origin-isolation for GC and it should be sufficient for other kind of tasks. With the cross-origin-isolated capability, the document can read the whole process's memory and browsers enforces that every documents/resources are public or have explicitly opted-in for this.

If cross-origin-isolation is already a requirement, then I was thinking we probably won't have to go into further thinking for the other kinds (?)

[cnpsc]

@ArthurSonzogni , COI isn't a requirement today as we were hoping it would be limited to GC marker but with the concerns raised about some of the rendering markers it makes sense to limit the extension being COI.

[ArthurSonzogni]

Thanks!

I just flipped the launch bug security bit. For transparency and give anyone the opportunity to challenge this, here is my message:

Launch bug

----------------- The whole feature has been put behind cross-origin-isolation: https://github.com/WICG/js-self-profiling/pull/63 I think we are happy with this result. Please let us know if you need to change this constraint in the future. Some justification for future readers: In a cross-origin-isolated page, we already assume the main document can read the whole process memory via the Spectre vulnerability. So it can already in theory leak cross-origin resources and cross-origin iframe's data. This is okay, because the resources loaded in the process are either public (= not valuable to the attacker) or have given an explicit opt-in being embedded cross-origin. As a result, exposing tasks from type: "script", "gc", "style", "layout", "paint", "other" shouldn't give more informations than what is already available in this context. One can probably imagine correlating GC events frequency with global memory pressure, we already have weakRef or performance.measureMemory(), which could give similar signals. -----------------

[cnpsc]

@ArthurSonzogni do you see any potential security risk to expand the tags to parsing and compile per https://github.com/WICG/js-self-profiling/issues/71 ?

[aluhrs13]

@cnpsc @ArthurSonzogni - Looking at this conversation, setting aside 'gc', it seems like the paint-related markers are similar to Long Animation Frames would it be possible to reconsider the COI restriction on the paint-related markers for similar reasons?

cc @noamr

[noamr]

@cnpsc @ArthurSonzogni - Looking at this conversation, setting aside 'gc', it seems like the paint-related markers are similar to Long Animation Frames would it be possible to reconsider the COI restriction on the paint-related markers for similar reasons?

cc @noamr

LoAF specifically doesn't expose paint markers for these exact reasons. It exposes style and layout markers that are already observable in other ways.

[mhanley00]

Hey there! Where would I find the compilation markers for whether web assembly is loaded or not?