It's a cool and interesting type of attack, but I really don't care for the breathless clickbait headlines that are sourced to a few security researchers demonstrating an attack in a lab, that has already been patched against and has never been seen in the wild.
> Android allows apps to call other apps? While remaining in the foreground? How does that work?
From the paper:
Recall from Section 2.1 that when a caller activity sends an intent to a callee activity, Android moves the callee activity to the foreground (along with its task’s back stack if android:-launchMode="singleTask") and moves the caller activity to the background.
However, despite no longer being in the foreground, the caller activity is still allowed to send intents that start additional activities from the background. For example, the caller activity can send another intent to launch a second callee activity.
In this case, the second callee moves to the foreground, while the first callee is moved to the background. Further, SurfaceFlinger treats the window of the second callee as being overlaid in front of the window of the first callee.
In our framework, the attacker app leverages this behavior to layer a stack of semi-transparent activities in front of a newly launched victim activity. In the following, we describe how the attacker uses this stack and SurfaceFlinger’s APIs to isolate, enlarge, and transmit individual pixels from the victim activity.
> Requires a victim to first install a malicious app on an Android phone or tablet
As Raymond Chen/Old New Thing likes to say this rather requires being on the other side of this airtight hatchway. You can allow apps to do things on your device.
That the app does not require permissions is the notable bit here. I do not know the mobile system, but I thought apps were supposed to be firewalled from each other unless given explicit grants.
The obvious joke, how long has Facebook been using this exploit?
Several preinstalled bloatware stores such as Galaxy Store, Moto apps and so forth will default to opt-in to automatically installing 'recommended apps and games' - essentially spyware garbage they get kickbacks from - in the background, plus several flagship phones now come with Temu preinstalled.
The 90% of non technically-savvy Android users are 100% exposed to the OP exploit.
The app needs to be opened by the user for the exploit to work, as seen in the video the researchers published, so the surface attack is big but not that big.
I have definitely opened the wrong app by accident on a smartphone - super easy to tap the wrong thing in a variety of situations (grasping at an awkward angle to snap a photo, pocket taps, etc).
> That the app does not require permissions is the notable bit here.
The article mentions that "the attacker renders something transparent in front of the target app". I would have thought that sort of thing would require the "appear on top" permission.
Yes, just because a popular blog about a infamously insecure operating system shrugged off certain classes of security problems as “you’re holding it wrong” two decades ago, OS security should be held to the same standard as that piece of shit OS forever. Nothing to see here.
Edit: IIRC the original argument was more reasonable, but it has since been abused in all kinds of situations to make low effort putdowns, like this one.
Raymond Chen's saying is about trust boundaries. That if there's no trust boundary defined, or if a defined boundary is being crossed with consent, then it is unsound to claim there being a security vulnerability (which would be a behavior that allows for crossing a trust boundary without consent).
This doesn't apply in this case, as (usermode apps') screen capturing does require permission, and applications can specifically opt-out from being captured by apps even with that permission, which Google Authenticator does have set. So a trust boundary is being violated, therefore this is a legitimate security issue by his logic.
> The new attack, named Pixnapping by the team of academic researchers who devised it, requires a victim to first install a malicious app on an Android phone or tablet.
I think it speaks about the security of Android that this makes the news. Coming from Windows, Android always felt as a MUCH more secure Operating System, not just a similar quality Operating System with touch controls and support for smaller hardware.
It also requires that whatever information the attacker is looking for has been displayed on the screen, so for example my banking app (like most banking apps I guess) masks my 4 digit passcode with asterisks so it is likely safe from this specific attack
PD: I just checked and it also doesn't change the color of the pressed keys or any other visual feedback that an attacker might use.
That's a bit silly since seat belts were never designed or intended to protect against missiles. If a missile blows up your car that's no fault of your seat belt. You should expect android to prevent other apps from knowing what other apps you have installed and prevent them from accessing data they display though.
There should be a new, stronger word for these kinds of attacks. Like clevevil, or clevil. Yes, pixnapping is clevil. We should strive for the opposite: livelc.
> Google has attempted to patch Pixnapping by limiting the number of activities an app can invoke blur on. However, we discovered a workaround to make Pixnapping work despite this patch. The workaround is still under embargo.
Great, google's security policy ending up being a zeroday. Exactly as denied and exactly as predicted by the community.
I'm confused. They're saying that the original patch was incomplete and that they believe they've re-broken it, but that they aren't publishing the updated attack because the report is embargoed (presumably to update the fix).
What is the security policy you'd like to see here? If the researchers were to publish the updated attack before mitigation then that WOULD be a zero day!
The embargo refers to Google's update policy since a couple months ago, which means that for three months, updates are on-hold and only shared with "selected vendors" and not the public.
Essentially the dumping strategy of open source that Apple has been doing for years.
Read the LineageOS blog article for more details on why stripping history and publishing only a tarball might be seen as the most stupid development practice ever.
Yeah, that's not the sense of "embargo" used in the text you quoted. I think you're arguing about something else. AOSP not getting prompt security patches is indeed a problem, but it's not relevant here. Per the article there is no fix for the updated attack.
> Yeah, that's not the sense of "embargo" used in the text you quoted. I think you're arguing about something else. AOSP not getting prompt security patches is indeed a problem, but it's not relevant here. Per the article there is no fix for the updated attack.
I'm not sure you are aware that the embargo references an NDA that you have to sign in order to get the updated sources/patches before the 3-months delay until it is released to the public.
Then guess what an NDA has to do with the condition of "being allowed" or "not being allowed" to publicly disclose a security bug that you've found.
This really needs to be the link. The article is phrased as if this was a zero day exploiting some kind of 2FA bug, but the actual meat is that it's a novel and really interesting new kind of attack vector (albeit not a particularly practical one) that no one had thought about before.
Yes, but "side channel attack" isn't much of a description, is it? You can't just declare "I make a side channel attack!"[1], you need to invent one.
In this case it turns out that the hardware rendering of the zoom animation in the blur effect of stacked activities on the screen left crumbs that can be detected in the alien context. I certainly didn't know that. Did you know that? I don't think anyone knew that! It's "novel".
> Does Google plan to patch these APIs?
>
> Google has attempted to patch Pixnapping by limiting the number of activities an app can invoke blur on. However, we discovered a workaround to make Pixnapping work despite this patch. The workaround is still under embargo.
Can I assume this is being exploited in the wild? Some black hats must be smart enough to figure out the workaround on their own.
Just use the Google Authenticator's "Privacy Screen" which requires a PIN, pattern, or biometric verification to open the app. This renders this hack unusable ;-)
Unless you social engineer to export the auth code as QR, take a screenshot, extract the secret key which is pretty much in plain bytes and use it to generate TOTP.
This attack seems to be explicitly exploiting the Android rendering pipeline through a side-channel.
Wayland, once hardened with security-context doesn't directly expose anything worrying (clipboard stealing is possible but would require window focus or the generation of a window which grabs focus). It remains to be seen if there are side-channels hiding somewhere in it or in the various GPU stacks.
Would you buy a hammer that can't ever hurt your thumb? What implications would that have? Would that be a good hammer?
Bad opinion time that I hope will maybe at least be thought provoking: I would hope a malicious app I willingly installed will be able to behave maliciously. Our security bureaucracy is going to grow exponentially and people are still going to be stealing people's shit, because people need to be able to access their shit and people are dumb.
While I appreciate the sentiment of fighting against oversecure features. This is a great security feature. The Windows OS model started development in the 90s, before the internet or even malware was popular. Android started development around 2010 and was able to provide a security design that contemplated risks of malware and internet.
In Windows installing malware compromises other applications, while in Android, your other apps are safe. In this news, this security mechanism fails. To denounce that the mechanism is completely useless is quite stupid, you just outed yourself as someone who doesn't have any security responsibilities and shouldn't have.
There was a time when we would have said something similar for table saws that cannot cut off your finger. Might be a little harder to pull off the trick with a hammer, but it just seems like another engineering problem. And it would make for a very expensive hammer.
It probably wouldn't be classified as a hammer anymore. You're comparing apples and oranges. Now when you show me the manual hand saw that can avoid cutting off your fingers you'll have an accurate comparison.
Because we're not comparing air nailers or electric nail guns or screw guns. It was about a hammer.
Your comparison is so ridiculous because the table saw did not obsolete any other kind of saw. It was only a new type of saw that allowed for some types of sawing to be done much easier.
The saw stop wasn't a replacement for manual saws. Table saws existed (and still exist!) and have a nasty habit of removing people's fingers. The saw stop was designed as a better table saw.
The point being that it's wild to start with the idea that hammers must be a danger to thumbs, and then double down by trying to claim that any hammer that wasn't a danger to thumbs wouldn't be called a hammer. Getting a table saw with a saw stop on it doesn't make it not a table saw.
But table saws are a replacement for manual saws. Table saws weren't invented first. Table saws fulfilled a niche use case for sawing. So by that saw stop is a replacement for a manual saw.
If you've ever used a hammer, a tool that has been around for tens of thousands of years, you will know by it's very nature of its operation it is a danger to thumbs. Trying to think that you can do "on an iPhone" and start with the assumption that a hammer fulfilling the functions and utility that it has and has had for 10,000 years cannot be a danger to thumbs is an erroneous thought and it shows the height of hubris.
Can you have tools that fulfill some of the functions of the hammer that are not dangerous to thumbs? Absolutely and we have those already. Any of the automatic nailers have built-in safety features to prevent accidents. Sometimes people disable those safety features because they do cause problems in legitimate use cases but they are built with those safety features. This would be analogous to saw stop which works in table saws which is a very limited saw.
Just like a table saw cannot fulfill all of the functions of a hand saw. A device that pounds nails or other things that has features to prevent it from accidentally hitting thumbs would not be able to fulfill all of the functions of the hammer.
From what we've seen with saws, this is your example not mine, all of the electric saws that have ever been built have never been able to eliminate the usefulness or utility of the simple handsaw which is dangerous to use. So where is the hubris to say that because you can invent a safer nailing device, which they have, it will somehow supplant and replace the hammer? The evidence says that's not the case.
I think we've almost certainly bottomed this out, but I feel obligated to point out that table saws can do a bunch of things that are borderline impossible with a hand saw. Table saws are not a replacement for hand saws. The fact that hand saws and table saws both have blades with teeth is about where the similarities end.
You're forgetting that table saws were invented thousands of years after hand saws. Master Craftsman used hand saws to do all of the things that are done with table saws. Many things are much easier on a table saw and much faster to do than with a hand saw. They are absolutely a replacement for hand saws that fulfill a niche. I suspect you haven't done a lot of actual woodworking for you to make this statement like this.
Just because we use table saws to rip lumber or massive table saws to cut up trees into lumber doesn't mean that no one could have created lumber prior to the invention of the table saw. We just factually know that's not true. Faster, easier, better, absolutely but all of it could be done and was done with hand saws. Maybe you're thinking the hand saw is limited to this simple hand saw that we have now or a simple Japanese hand saw and not the actual large hand saws that took two people to operate but are still hand saws that come with all of the dangers of the hand saw.
Everybody knows about saw stop. But in what way does a table saw compare with a hammer? If you were comparing it to an air nailer, or an electric nail gun, or an electric screw gun, which all can have safety features that require certain things to be met before it will fire then you have a comparison.
If you want to compare the hammer to something that saws you would compare it to a handsaw. Show me the hand saw that cannot damage your fingers.
You must think you're very smart but I don't think you've done any manual labor in your life. Because the table saw never obsoleted any other type of existing saw. It was simply a new tool that enhanced the ability to do certain types of sawing. The more you limit a function of something the easier it is to put guardrails around it. That was the original poster's point. You can limit Android to the point that it is nearly useless or useless only for the most basic of tasks but then you remove the power of it but you do not remove the need for all of the other tasks.
Table saws with saw stop still necessitate hand saws in some circumstances. Power nailers that have safety features that prevent their discharge and unsafe ways do not obsolete hammers.
They're called rubber mallets and they are useful in a number of situations where you want to
> I would hope a malicious app I willingly installed will be able to behave maliciously.
You should be able to install an app that has continuous access to your screen but that doesn't mean that continuous access to your screen is something you should have to grant to every piece of software that runs on your computer.
You can hurt your thumb with a rubber mallet. Maybe the better metaphor would be kids' safety scissors which I guess represents the iPhone, but I'd still rather go with the Android (regular scissors) because I'm an adult and I'll take responsibility for the risks of using the more powerful tool.
I think one can still build a product that has a level of guard rails without impacting usability.
I also think iOS is more of an opinionated 'set of shears'. E.g. 'Right Hand only Scissors made from proprietary parts, made to only cut objects that 80% of scissor users need to cut' if we were to go down the road of analogies.
Funnily enough Google Android is removing the ability for unsigned non-adb APKs. I would suggest your 'regular' scissors will be slightly bluntened in the upcoming Android 16 OS release.
Not being able to run arbitrary code that Apple hasn't given me permission to run doesn't meet my standard of powerful. I won't trade my freedom for a little extra security.
The issue isn't that a trojan gives the attacker access to things they shouldn't have access to, the problem is that android gives the trojan access to things it shouldn't so that the data it collects can be passed back to the attacker.
That's not what's happening here. The attack is exploiting a side channel of the rendering behavior, not reading the screen. There's no particular reason to believe that iOS is immune to something like this, though certainly no claim has been made. It's a new idea, it'll take a while for people to puzzle through the implications.
How are you sure? This isn't abusing some poorly secured screenshot API, this is a timing attack on the GPU rendering process and impacts a wide range of GPUs.
This attack measures the time needed to draw each pixel which varies due to graphical data compression. It is based on the "GPU.zip" vulnerability which was shown to affect most modern GPUs, including from Apple.
Android supremacy at its finest. I would never recommend a family member buying one. The history of this kind of thing is long and keeps continuing to happen.
It's a cool and interesting type of attack, but I really don't care for the breathless clickbait headlines that are sourced to a few security researchers demonstrating an attack in a lab, that has already been patched against and has never been seen in the wild.
Good thing every Android phone gets fresh updates all the time then.
with detailed changelogs!
"Security and Stability Improvements", part 413.
In Android world, there is not such thing as "has been patched". It is always A complex situation with all different OEMs, devices and versions.
The patch was committed about 3 months ago, possibly available to OEMs as binary earlier, but devices are probably just receiving these patches.
I bet at least half of all affected Android devices in the world have not got the patch yet if I am optimistic. It's probably near 80-90%.
> has already been patched against
... has not been (effectively) patched against, as it happens. Maybe in December!
I'm stuck on the part of the attack where the malicious app opens another app:
> 2. Attacker app opens Google Authenticator's main activity
> 3. Attacker app opens a stack of activities to include graphical operations on pixels displayed by Google Authenticator's main activity
Android allows apps to call other apps? While remaining in the foreground? How does that work? I don't think iOS allows this.
> Android allows apps to call other apps? While remaining in the foreground? How does that work?
From the paper:
Recall from Section 2.1 that when a caller activity sends an intent to a callee activity, Android moves the callee activity to the foreground (along with its task’s back stack if android:-launchMode="singleTask") and moves the caller activity to the background.
However, despite no longer being in the foreground, the caller activity is still allowed to send intents that start additional activities from the background. For example, the caller activity can send another intent to launch a second callee activity.
In this case, the second callee moves to the foreground, while the first callee is moved to the background. Further, SurfaceFlinger treats the window of the second callee as being overlaid in front of the window of the first callee.
In our framework, the attacker app leverages this behavior to layer a stack of semi-transparent activities in front of a newly launched victim activity. In the following, we describe how the attacker uses this stack and SurfaceFlinger’s APIs to isolate, enlarge, and transmit individual pixels from the victim activity.
So kinda like Strandhogg and Tap jacking had a horrible security breach baby
What I got from the article is the malicious app could read the SMS or email which may contain a 2FA code.
> Requires a victim to first install a malicious app on an Android phone or tablet
As Raymond Chen/Old New Thing likes to say this rather requires being on the other side of this airtight hatchway. You can allow apps to do things on your device.
That the app does not require permissions is the notable bit here. I do not know the mobile system, but I thought apps were supposed to be firewalled from each other unless given explicit grants.
The obvious joke, how long has Facebook been using this exploit?
Several preinstalled bloatware stores such as Galaxy Store, Moto apps and so forth will default to opt-in to automatically installing 'recommended apps and games' - essentially spyware garbage they get kickbacks from - in the background, plus several flagship phones now come with Temu preinstalled.
The 90% of non technically-savvy Android users are 100% exposed to the OP exploit.
The app needs to be opened by the user for the exploit to work, as seen in the video the researchers published, so the surface attack is big but not that big.
I have definitely opened the wrong app by accident on a smartphone - super easy to tap the wrong thing in a variety of situations (grasping at an awkward angle to snap a photo, pocket taps, etc).
I recommend the program universal android debloater, it will uninstall all those apps
Unless the manufacturer has placed their malware loader into the “nodisable” list.
Motorola are assholes and now prevent you from using pm to disable any of their malware loader apps on most of their phones.
> That the app does not require permissions is the notable bit here.
The article mentions that "the attacker renders something transparent in front of the target app". I would have thought that sort of thing would require the "appear on top" permission.
This sounds like a trick I read about years ago. Disappointing if it hasn’t been fixed.
> The obvious joke, how long has Facebook been using this exploit?
They were caught exfiltrating data fron phones, with no visible Facebook app installed, only the background one.
Yes, just because a popular blog about a infamously insecure operating system shrugged off certain classes of security problems as “you’re holding it wrong” two decades ago, OS security should be held to the same standard as that piece of shit OS forever. Nothing to see here.
Edit: IIRC the original argument was more reasonable, but it has since been abused in all kinds of situations to make low effort putdowns, like this one.
It can happen quickly. The app itself might be legit, but it may be based in a SDK which is either malicious or compromised.
And there are a lot of automatically installed junk apps on most phones. And every OTA update seems to add more.
Raymond Chen's saying is about trust boundaries. That if there's no trust boundary defined, or if a defined boundary is being crossed with consent, then it is unsound to claim there being a security vulnerability (which would be a behavior that allows for crossing a trust boundary without consent).
This doesn't apply in this case, as (usermode apps') screen capturing does require permission, and applications can specifically opt-out from being captured by apps even with that permission, which Google Authenticator does have set. So a trust boundary is being violated, therefore this is a legitimate security issue by his logic.
> The new attack, named Pixnapping by the team of academic researchers who devised it, requires a victim to first install a malicious app on an Android phone or tablet.
I think it speaks about the security of Android that this makes the news. Coming from Windows, Android always felt as a MUCH more secure Operating System, not just a similar quality Operating System with touch controls and support for smaller hardware.
It also requires that whatever information the attacker is looking for has been displayed on the screen, so for example my banking app (like most banking apps I guess) masks my 4 digit passcode with asterisks so it is likely safe from this specific attack
PD: I just checked and it also doesn't change the color of the pressed keys or any other visual feedback that an attacker might use.
Right, but if you were using TOTP or SMS 2FA, because said bank is a "global leader" but hasn't evolved their end user tech in a long time...
https://0x0.st/XJZT.jpg
That's a bit silly since seat belts were never designed or intended to protect against missiles. If a missile blows up your car that's no fault of your seat belt. You should expect android to prevent other apps from knowing what other apps you have installed and prevent them from accessing data they display though.
In other news, there are substances in the household that are so dangerous that it can can kill you.
First it requires the user take buckets of ammonia and bleach and mix them together.
To be fair, it's more like, you can buy a bottle of ammonia, and then get poisoned by eating an apple.
This is a really interesting new side channel attack. One I had never considered before; it’s like rowhammer but for the screen. Clever. Also evil.
Clever and evil.
There should be a new, stronger word for these kinds of attacks. Like clevevil, or clevil. Yes, pixnapping is clevil. We should strive for the opposite: livelc.
Source: https://www.pixnapping.com/
Quote:
> Google has attempted to patch Pixnapping by limiting the number of activities an app can invoke blur on. However, we discovered a workaround to make Pixnapping work despite this patch. The workaround is still under embargo.
Great, google's security policy ending up being a zeroday. Exactly as denied and exactly as predicted by the community.
Also, this is the direct paper link: https://www.pixnapping.com/pixnapping.pdf
I'm confused. They're saying that the original patch was incomplete and that they believe they've re-broken it, but that they aren't publishing the updated attack because the report is embargoed (presumably to update the fix).
What is the security policy you'd like to see here? If the researchers were to publish the updated attack before mitigation then that WOULD be a zero day!
The embargo refers to Google's update policy since a couple months ago, which means that for three months, updates are on-hold and only shared with "selected vendors" and not the public.
Essentially the dumping strategy of open source that Apple has been doing for years.
Read the LineageOS blog article for more details on why stripping history and publishing only a tarball might be seen as the most stupid development practice ever.
[1] https://lineageos.org/Changelog-30/
[2] GrapheneOS discussion about embargo https://news.ycombinator.com/item?id=45158523
Yeah, that's not the sense of "embargo" used in the text you quoted. I think you're arguing about something else. AOSP not getting prompt security patches is indeed a problem, but it's not relevant here. Per the article there is no fix for the updated attack.
> Yeah, that's not the sense of "embargo" used in the text you quoted. I think you're arguing about something else. AOSP not getting prompt security patches is indeed a problem, but it's not relevant here. Per the article there is no fix for the updated attack.
I'm not sure you are aware that the embargo references an NDA that you have to sign in order to get the updated sources/patches before the 3-months delay until it is released to the public.
Then guess what an NDA has to do with the condition of "being allowed" or "not being allowed" to publicly disclose a security bug that you've found.
[1] https://android.googlesource.com/platform/docs/source.androi...
This really needs to be the link. The article is phrased as if this was a zero day exploiting some kind of 2FA bug, but the actual meat is that it's a novel and really interesting new kind of attack vector (albeit not a particularly practical one) that no one had thought about before.
I would not say "no one had thought about before".
Side channel attack is not a novel idea, just not used to find Android bugs like this.
> Side channel attack is not a novel idea
Yes, but "side channel attack" isn't much of a description, is it? You can't just declare "I make a side channel attack!"[1], you need to invent one.
In this case it turns out that the hardware rendering of the zoom animation in the blur effect of stacked activities on the screen left crumbs that can be detected in the alien context. I certainly didn't know that. Did you know that? I don't think anyone knew that! It's "novel".
[1] Shades of Michael Scott declaring bankruptcy.
> Does Google plan to patch these APIs? > > Google has attempted to patch Pixnapping by limiting the number of activities an app can invoke blur on. However, we discovered a workaround to make Pixnapping work despite this patch. The workaround is still under embargo.
Can I assume this is being exploited in the wild? Some black hats must be smart enough to figure out the workaround on their own.
Just use the Google Authenticator's "Privacy Screen" which requires a PIN, pattern, or biometric verification to open the app. This renders this hack unusable ;-)
Unless you social engineer to export the auth code as QR, take a screenshot, extract the secret key which is pretty much in plain bytes and use it to generate TOTP.
Curious if the same technique would also work on Wayland, given one of its design goals is higher cross-app security compared to Xorg.
This attack seems to be explicitly exploiting the Android rendering pipeline through a side-channel.
Wayland, once hardened with security-context doesn't directly expose anything worrying (clipboard stealing is possible but would require window focus or the generation of a window which grabs focus). It remains to be seen if there are side-channels hiding somewhere in it or in the various GPU stacks.
Would you buy a hammer that can't ever hurt your thumb? What implications would that have? Would that be a good hammer?
Bad opinion time that I hope will maybe at least be thought provoking: I would hope a malicious app I willingly installed will be able to behave maliciously. Our security bureaucracy is going to grow exponentially and people are still going to be stealing people's shit, because people need to be able to access their shit and people are dumb.
> requires no [Android] permissions
I think this is the part people are upset about
While I appreciate the sentiment of fighting against oversecure features. This is a great security feature. The Windows OS model started development in the 90s, before the internet or even malware was popular. Android started development around 2010 and was able to provide a security design that contemplated risks of malware and internet.
In Windows installing malware compromises other applications, while in Android, your other apps are safe. In this news, this security mechanism fails. To denounce that the mechanism is completely useless is quite stupid, you just outed yourself as someone who doesn't have any security responsibilities and shouldn't have.
> Would you buy a hammer that can't ever hurt your thumb?
Yes.
I believe those hammers are made by Nerf. Now go build a house with one.
There was a time when we would have said something similar for table saws that cannot cut off your finger. Might be a little harder to pull off the trick with a hammer, but it just seems like another engineering problem. And it would make for a very expensive hammer.
It probably wouldn't be classified as a hammer anymore. You're comparing apples and oranges. Now when you show me the manual hand saw that can avoid cutting off your fingers you'll have an accurate comparison.
Because we're not comparing air nailers or electric nail guns or screw guns. It was about a hammer.
Your comparison is so ridiculous because the table saw did not obsolete any other kind of saw. It was only a new type of saw that allowed for some types of sawing to be done much easier.
I'll bite, I guess.
The saw stop wasn't a replacement for manual saws. Table saws existed (and still exist!) and have a nasty habit of removing people's fingers. The saw stop was designed as a better table saw.
The point being that it's wild to start with the idea that hammers must be a danger to thumbs, and then double down by trying to claim that any hammer that wasn't a danger to thumbs wouldn't be called a hammer. Getting a table saw with a saw stop on it doesn't make it not a table saw.
But table saws are a replacement for manual saws. Table saws weren't invented first. Table saws fulfilled a niche use case for sawing. So by that saw stop is a replacement for a manual saw.
If you've ever used a hammer, a tool that has been around for tens of thousands of years, you will know by it's very nature of its operation it is a danger to thumbs. Trying to think that you can do "on an iPhone" and start with the assumption that a hammer fulfilling the functions and utility that it has and has had for 10,000 years cannot be a danger to thumbs is an erroneous thought and it shows the height of hubris.
Can you have tools that fulfill some of the functions of the hammer that are not dangerous to thumbs? Absolutely and we have those already. Any of the automatic nailers have built-in safety features to prevent accidents. Sometimes people disable those safety features because they do cause problems in legitimate use cases but they are built with those safety features. This would be analogous to saw stop which works in table saws which is a very limited saw.
Just like a table saw cannot fulfill all of the functions of a hand saw. A device that pounds nails or other things that has features to prevent it from accidentally hitting thumbs would not be able to fulfill all of the functions of the hammer.
From what we've seen with saws, this is your example not mine, all of the electric saws that have ever been built have never been able to eliminate the usefulness or utility of the simple handsaw which is dangerous to use. So where is the hubris to say that because you can invent a safer nailing device, which they have, it will somehow supplant and replace the hammer? The evidence says that's not the case.
I think we've almost certainly bottomed this out, but I feel obligated to point out that table saws can do a bunch of things that are borderline impossible with a hand saw. Table saws are not a replacement for hand saws. The fact that hand saws and table saws both have blades with teeth is about where the similarities end.
You're forgetting that table saws were invented thousands of years after hand saws. Master Craftsman used hand saws to do all of the things that are done with table saws. Many things are much easier on a table saw and much faster to do than with a hand saw. They are absolutely a replacement for hand saws that fulfill a niche. I suspect you haven't done a lot of actual woodworking for you to make this statement like this.
Just because we use table saws to rip lumber or massive table saws to cut up trees into lumber doesn't mean that no one could have created lumber prior to the invention of the table saw. We just factually know that's not true. Faster, easier, better, absolutely but all of it could be done and was done with hand saws. Maybe you're thinking the hand saw is limited to this simple hand saw that we have now or a simple Japanese hand saw and not the actual large hand saws that took two people to operate but are still hand saws that come with all of the dangers of the hand saw.
Would you buy an electric saw that cannot damage your fingers?
https://www.youtube.com/watch?v=oQu3ccfl7Ow
Or you would yell at a cloud?
Everybody knows about saw stop. But in what way does a table saw compare with a hammer? If you were comparing it to an air nailer, or an electric nail gun, or an electric screw gun, which all can have safety features that require certain things to be met before it will fire then you have a comparison.
If you want to compare the hammer to something that saws you would compare it to a handsaw. Show me the hand saw that cannot damage your fingers.
You must think you're very smart but I don't think you've done any manual labor in your life. Because the table saw never obsoleted any other type of existing saw. It was simply a new tool that enhanced the ability to do certain types of sawing. The more you limit a function of something the easier it is to put guardrails around it. That was the original poster's point. You can limit Android to the point that it is nearly useless or useless only for the most basic of tasks but then you remove the power of it but you do not remove the need for all of the other tasks.
Table saws with saw stop still necessitate hand saws in some circumstances. Power nailers that have safety features that prevent their discharge and unsafe ways do not obsolete hammers.
https://tvtropes.org/pmwiki/pmwiki.php/Main/Metaphorgotten
> Would that be a good hammer?
They're called rubber mallets and they are useful in a number of situations where you want to
> I would hope a malicious app I willingly installed will be able to behave maliciously.
You should be able to install an app that has continuous access to your screen but that doesn't mean that continuous access to your screen is something you should have to grant to every piece of software that runs on your computer.
You can hurt your thumb with a rubber mallet. Maybe the better metaphor would be kids' safety scissors which I guess represents the iPhone, but I'd still rather go with the Android (regular scissors) because I'm an adult and I'll take responsibility for the risks of using the more powerful tool.
I think one can still build a product that has a level of guard rails without impacting usability.
I also think iOS is more of an opinionated 'set of shears'. E.g. 'Right Hand only Scissors made from proprietary parts, made to only cut objects that 80% of scissor users need to cut' if we were to go down the road of analogies.
Funnily enough Google Android is removing the ability for unsigned non-adb APKs. I would suggest your 'regular' scissors will be slightly bluntened in the upcoming Android 16 OS release.
Why are you speaking like having a secure device and a powerful device are exclusive options?
Not being able to run arbitrary code that Apple hasn't given me permission to run doesn't meet my standard of powerful. I won't trade my freedom for a little extra security.
More accurate title: "There's a new trojan out for android. Like any trojan, it gives the attacker access to things they shouldn't have access to"
The issue isn't that a trojan gives the attacker access to things they shouldn't have access to, the problem is that android gives the trojan access to things it shouldn't so that the data it collects can be passed back to the attacker.
Don't worry you won't be able to install the bad application in the first place thanks to the new ID backed app signature.
Could this be mitigated by introducing some random timing jitter during rendering?
And they can’t with iPhones?
iOS doesn't let apps silently screen record.
That's not what's happening here. The attack is exploiting a side channel of the rendering behavior, not reading the screen. There's no particular reason to believe that iOS is immune to something like this, though certainly no claim has been made. It's a new idea, it'll take a while for people to puzzle through the implications.
How are you sure? This isn't abusing some poorly secured screenshot API, this is a timing attack on the GPU rendering process and impacts a wide range of GPUs.
No. This isn't Spectre/Meltdown for GPUs, it takes advantage of SurfaceFlinger giving apps information on what's drawn behind them.
This attack measures the time needed to draw each pixel which varies due to graphical data compression. It is based on the "GPU.zip" vulnerability which was shown to affect most modern GPUs, including from Apple.
Neither does Android. This is a timing attack on rendering.
You can't put one app on top of another, so that mitigates at least the 1st stage of this kind of attack.
TL;DR; This is a timing attack on rendering that allows capture of screen data.
tl;dr: This hack is "using a timing attack exploiting the GPU's graphical data compression to try finding out the color of the pixels."
Tldr: this is a timing-based side channel in GPUs allowing and attacker to read pixels from the screen without special privs.
Side channels are why we can't have nice things.
Android supremacy at its finest. I would never recommend a family member buying one. The history of this kind of thing is long and keeps continuing to happen.