App developers can already dynamically mark their windows as secure which should prevent any other app from reading the pixels it rendered. The compositor composites all windows, including secure windows and applies any effects like blur. No apps are supposed to be able to see this final composited image, but this attack uses a side channel they found that allows apps on the system to learn information about the pixels within the final composition.

The attack needs you to be able to alter the blur of pixels in a secure window; this could be forbidden. A secure window should draw 100% as requested or not at all.

The blur happens in the compositor. It doesn't happen in the secure windows.

>A secure window should draw 100% as requested or not at all.

Take for example "night mode" which adds an orange tint to everything. If secure windows don't get such an orange tint they will look out of place. Being able to do post processing effects on secure windows is desirable, so as I said there is a trade off here in figuring out what should be allowed.

> Take for example "night mode" which adds an orange tint to everything. If secure windows don't get such an orange tint they will look out of place. Being able to do post processing effects on secure windows is desirable, so as I said there is a trade off here in figuring out what should be allowed.

That seems well worth the trade to me.

These sort of restrictions also often interfere with accessibility and screen readers.

Either the screen reader is built into the OS as signed + trusted (and locks out competition in this space), or it's a pluggable interface, that opens an attack surface to read secure parts of the screen.

Yes; that is a perfect example of where I would prefer security over not looking out of place.

Right but night mode is built into the OS so you can easily make an exception (same for things like toasts). Are there use cases where you need a) a secure window, and b) a semi-transparent app-controlled window on top of it?