31–40 of 75 posts
My takeaway: Do not install apps. Use websites. Apps have way too much permissions, even when they have "no permissions".
Huh. I don’t know that I’ve seen a whole domain name registered, for a paper on a single CVE, before.
Modern devices are simply too complex to be completely secure. We have this tendency of adding more and more "features", more and more functionality 85% of which nobody asked for or has use for. I believe that there will be a market for a small, bare bones secure OS in the future. Akin to how freeBSD is being run.
My takeaway: Do not install apps. Use websites. Apps have way too much permissions, even when they have "no permissions".
Similarly, software vendors want you to use apps for the same reason you don't want to use them. They'll rely on dark patterns to herd you to their native apps.
These two desires influence whether it's viable to use the web instead of apps. I think we need legislation in this area, apps should be secondary to the web services they rely on, and companies should not be allowed to purposely make their websites worse in order to get you on their apps.
> The attacks described in Section 5 take hours to steal sensitive screen regions—placing certain categories of ephemeral secrets out of reach for the attacker app. Consider for example 2FA codes. By default, these 6-digit codes are refreshed every 30 seconds [38]. This imposes a strict time limit on the attack: if the attacker cannot leak the 6 digits within 30 seconds, they disappear from the screen
> Instead, assuming the font is known to the attacker, each secret digit can be differentiated by leaking just a few carefully chosen pixels
It's not exactly a new technique but it's effective for most super targeted attacks, honestly it seems if you were this inclined to be able to get a specific app on the users phone, you might as well just work off the Android app you've already gotten delivered to the users phone. Like Facebook. Throw a privacy notice to the users "This app will take periodic screenshots of your phone" You'd be amazed how many people…
A patch for the original vulnerability is already public: https://android.googlesource.com/platform/frameworks/native/... and explicitly states in the commit message that it tries to defeat "pixel stealing by measuring how long it takes to perform a blur across windows." The researchers aren't releasing their code because they found a workaround to the patch. Then there's a bunch of "no GPU vendor has committed to pa…
P.S.: where did you see this discussion?
It's not exactly a new technique but it's effective for most super targeted attacks, honestly it seems if you were this inclined to be able to get a specific app on the users phone, you might as well just work off the Android app you've already gotten delivered to the users phone. Like Facebook. Throw a privacy notice to the users "This app will take periodic screenshots of your phone" You'd be amazed how many people…
My takeaway: Do not install apps. Use websites. Apps have way too much permissions, even when they have "no permissions".
Earlier quoted context omitted.
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…