05-06-2022, 07:32 PM
I think the common goal of both commercial competitors and state-based agencies would be to keep Pinephone and other Linux phones out of mainstream circulation. This could be best achieved surreptitiously by attacking individuals who might accelerate the uptake/mainstreaming of the device. Obviously highly technical users would, by their level of expertise, make much harder targets for saboteurs. The less technically-inclined user, however, is vulnerable. And that provides the opportunity to slow the uptake of these devices. The core tech users will continue to find genuine bugs and gradually correct them as we would all expect for a prototype device, while less technical users may experience attacks that manifest in ways that the developers never see.
As past and ongoing target of sabotage (vehicles, other equipment and phones/computers) I'd like to share some observations based on my own direct experience. The preferred approach of the saboteur when attacking offline devices seems to be: to enter your home or workplace surreptitiously in your absence and swap over your device with one of theirs. The replacement device they leave in place of yours has one or more prepared physical faults. This preparation approach allows the saboteur to test the fault and prove that it has the desired effect before deploying it. The saboteur also seems to value precision and economy, so tends to make the smallest gesture possible, intended to cause maximum harm. A simple example is a light panel of mine where I found one wire had been cut. I had the same thing happen with a portable vintage organ (musical instrument). One wire cut. In the most obvious and absolute example of substitution I've experienced, the brand logo on a pair of my headphones changed colour from silver to green!
I suspect, but cannot prove, that these same principles would apply to sabotage of online device(s)... that the hacker would replace or modify a single package/file on a Pinephone to cause maximum damage to a user's experience while remaining as difficult to detect as possible. If there is risk of detection, provided the saboteur can re-enter the device, they can restore the original package/file and exit covering their tracks. Else the hack is "papered over" when the OS or program in question is next upgraded.
If anyone's able or interested to troubleshoot for me next time this happens on my phone, could someone suggest the best way to take a rapid disk image of my phone's eMMC contents for diagnosis? I guess the easier alternative is to stick with running the OS from a microSD.
As past and ongoing target of sabotage (vehicles, other equipment and phones/computers) I'd like to share some observations based on my own direct experience. The preferred approach of the saboteur when attacking offline devices seems to be: to enter your home or workplace surreptitiously in your absence and swap over your device with one of theirs. The replacement device they leave in place of yours has one or more prepared physical faults. This preparation approach allows the saboteur to test the fault and prove that it has the desired effect before deploying it. The saboteur also seems to value precision and economy, so tends to make the smallest gesture possible, intended to cause maximum harm. A simple example is a light panel of mine where I found one wire had been cut. I had the same thing happen with a portable vintage organ (musical instrument). One wire cut. In the most obvious and absolute example of substitution I've experienced, the brand logo on a pair of my headphones changed colour from silver to green!
I suspect, but cannot prove, that these same principles would apply to sabotage of online device(s)... that the hacker would replace or modify a single package/file on a Pinephone to cause maximum damage to a user's experience while remaining as difficult to detect as possible. If there is risk of detection, provided the saboteur can re-enter the device, they can restore the original package/file and exit covering their tracks. Else the hack is "papered over" when the OS or program in question is next upgraded.
If anyone's able or interested to troubleshoot for me next time this happens on my phone, could someone suggest the best way to take a rapid disk image of my phone's eMMC contents for diagnosis? I guess the easier alternative is to stick with running the OS from a microSD.
For byte-sized tech and software tips check out my Danimations Digital Media tips channel on Youtube