undefined | Better HN

0 pointsZiiS5mo ago0 comments

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.

0 comments

charcircuit5mo ago

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.

hamandcheese5mo ago

> 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.

jasonjayr5mo ago

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.

ZiiSOP5mo ago

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

IshKebab5mo ago

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?

j / k navigate · click thread line to collapse