Edward Snowden's New Research Aims to Keep Smartphones from Betraying Owners
theintercept.com
theintercept.com
Probably confirmation bias or maybe I'm subconsciously hearing the interference in speakers and taking the hint from there. It doesn't happen every time and I don't receive a lot of calls.
HN seems a decent place to settle it once and for all.
However, this would be pretty easy to test! Just have a friend call you at random times throughout a 2-hour interval or something, and record every time you think the phone is about to ring, and every time it actually does. If there's a close enough correlation between the two, that's fairly persuasive evidence.
Case in point, the woman who can smell Parkinson's disease, to some ridunculous p-value.
http://www.scientificamerican.com/article/one-woman-s-abilit...
Some effects published in medical journals have a less convincing p-value.
A decent dev machine for $2K-ish, save for a major flaw: "coil whine"[1]. Very annoying when working in silent environments. Frustratingly random as well - for me, backlight on/off, usb connect/disconnect and scrolling on browsers would change the whine frequency noticably. [2]
It is possible that you can hear something similar from your MBP - however it is very unlikely that this has anything to do with any of the radios.
I miss the good old days when you knew your PC was busy by the HD sounding like a thousand monkeys tap-dancing shakespear.
[1] https://en.wikipedia.org/wiki/Coil_noise
[2] BTW, Dell denies this issue, claiming it was fixed before 9333. Users disagree: https://www.reddit.com/r/Dell/comments/47g46m/lets_investiga...
Is this true? What about heat radiation for example. We can feel that.
And we can see/sense changes in electromagnetic fields: http://www.nature.com/ncomms/journal/v2/n6/full/ncomms1364.h...
I can imagine cell frequencies would be even more likely due to smaller antennae for the higher frequency.
There's definitely doubt about their conclusion when they can't reproduce something and then declare it busted -- absence of evidence is not evidence of absence.
Another observation though: I worked professionally with radar systems for a while and IIRC one of the oldtimers mentioned one isolated case where a person had been able to tell when a certain radar was transmitting in his sector. (Radars often only transmit in sectors turning away from the population.)
But, to be honest, I haven't heard about it anywhere else and most people who claim to sense that kind of radiation either refuses to undergo blind studies or fail them so if you treat this as anything but an old wives tale you have to do your research :-)
Anecdotally: I can definitely "feel" large AC transmission lines. They do have an audible buzz, however the "feeling" sensation seems distinct to me. My experience is from hiking the Appalachian Trail, which spends days outside of cell phone range, and then crosses regional transmission lines periodically.
So if that observation is not pure illusion or auditory synesthesia (perhaps a fully deaf person can assist here?), it would seem to follow that there is a mechanism to sense EM radiation, and it is simply a matter of whether the perceptive threshold has been met, which would obviously vary from person to person and even from instant to instant.
The story: this pastor, and only this pastor, would make wireless microphones in certain frequencies act up.
Eventually the audio team found out that somehow this particular pastor worked as an antenna for a particular frequency, matching a nearby radio transmitter, that due to its enormous size would overpower the microphone transmission and corrupt the data.
I also knew somebody who had to use wind-up pocket watches, because quartz wristwatches would always skew when he wore them, but would keep time fine when removed.
Weird stuff. Who knows.
http://journal.frontiersin.org/article/10.3389/fncel.2014.00...
I have no idea on what field intensities are sufficient to influence the neurons.
[EDIT] http://electronics.stackexchange.com/questions/38838/powerin...
Alternatively some use an iPod with only Signal installed. As stubborn Moxie requires access to the address book [2], the iPod address book is exclusively used for Signal addressees.
[0] https://www.theiphonewiki.com/wiki/DFU_Mode#Entering_DFU_Mod...
At that point just walking around with a powered off device makes more sense than DFU.
I wasn't aware that an iDevice comes out of DFU mode after some time, please enlighten us. According to the instructions [0] I understand you need a special set of actions to return to the normal firmware.
DFU has a single purpose: wait for an Apple-signed firmware file to be sent to it over USB for it to execute. You seem to indicate that it's something you would carry your phone around in...in which it would just reboot into iOS after awhile.
Asking the obvious: Have you booted an iOS device into DFU mode before? Maybe the iPhone Wiki made it sound like it is a "mode" you can boot iOS into? I am not sure exactly what you think it is, but again, the device screen is completely black and indistinguishable from being off, OS is not booted and nothing is happening at all, besides the fact that (again) it is indeed on and "spinning" as it waits for the USB interrupt.
There are many options and as always in security/warfare/sports/etc the best defense depends on the attacker, the circumstances, the capabilities of the defender etc. DFU mode probably is one more option in a list of options and it has the advantage that it is available most of the times (it has to be practiced as always in security/warfare/sports/etc) and, for now, probably not hacked. If Will Strafach shows us that an iDevice reboots out of DFU mode after some time, that is one more thing to take in consideration. Or if it is not possible to carry an iDevice around in DFU mode, it might be useful only in limited cases.
As previously mentioned, it seems that you have the idea that DFU is a "mode" that you can boot iOS into. This is absolutely not the case, the device screen is completely black and the device appears to be completely off, because it almost is, it's just "spinning" and waiting for the USB interrupt.
The reason I am very adamant about this is because your comment was upvoted when the advice would serve no purpose to someone who needed it.
If you do not believe the device will reboot, go get an iPhone now and boot into DFU mode while plugged in. Then look at your computer and wait for it to recognize the DFU connected device (only way to know when it's in DFU versus being off). Then unplug it and watch, it will reboot into normal iOS at some point (or power itself off if battery is low, depends, same point though).
How did we get to this point, where our personal computing devices are completely out of our basic control? We live in bizarro world.
That's why they're using a completely separate piece of hardware.
If you participate in the design of a phone that broadcasts its position in dangerous situations without the user knowing this, and subsequently gets them killed, maybe you're so far down the line and organizationally have so many people between you and them that you don't notice the small amount of blood on your hands.
Just by existing we all cause trouble, but I'd like to see a bit more ethical sense among those who are directly enabling the current oppressive state.
Share with us what you're doing to fight the problem, aside from posting on HN. If it can solve all the problems, I'm sure we'll all join up.
That same message, when presented to a large enough group where the responsibility is sufficiently diffused, is simply shrugged off. This is human nature and as such can be relied upon to supply endless weaponry and surveillance tools to our betters.
It's Snowden's fault that he has, in this environment where having minimal conscience is an asset, an over developed sense of ethics. Which unfortunately can't make up for the rest of our lack of it.
The phone OS is as much in control of that radio (at best) as your laptop is in control of the ISP router.
Let's forget everything aside from GSM for a moment.
The GSM/LTE/whatever radio runs very closed source firmware. This communicates with the very closed source CPU and other subsystems, controlled by the very closed source OS. On top of that you run various other closed source apps, opening potentially malicious documents and browsing potentially malicious links.
In theory nothing goes wrong. When you hit 'airplane mode', the OS tells the radios to STFU. In practice, anything could go wrong - maliciously or not. Your phone could have been "jailbroken" without your knowledge by a 0-day exploit, effectively negating the OS security. Once the bad guys are in your OS, they may as well update your baseband firmware to do whatever they want. Or any of the other firmware/drivers/ICs that they are able to access. Or CPU microcodes. Anything.
Ideally you would have a phone with a physical switch, powering off all radios. Not politely instructing them to please cease functioning, but actually power them the f... off. This almost never happens. I have a hardware switch on my laptop - this doesn't actually cut the power to the wireless radios. If/when the firmware is compromised, it is as useless as the Wifi LED indicators.
So, great, you'll say - implement that rather than build a whole new system to babysit your smartphone stack. Make a hardware switch that powers off all radio subsystems. Even if that were possible, your iPhone would not like a subsystem disappearing from existence. It isn't designed to handle that contingency and will surely fail in spectacular ways.
Hence, tapping into debug ports/buses/etc and trying to monitor traffic that way.
The analog way[1] may make more sense, but usability would probably be restricted. I'm fairly certain Snowden has heard of faraday cages.
[1] https://www.amazon.com/FawkesBOX-Smart-phone-Faraday-Cage/dp...
Change is never impossible for something we ourselves design and manufacture.
>The GSM/LTE/whatever radio runs very closed source firmware.
This seems like a problem that could be fixed.
>Your phone could have been "jailbroken" without your knowledge by a 0-day exploit, effectively negating the OS security.
Probably sounds quaint, but run SW from a ROM.
>Make a hardware switch that powers off all radio subsystems. Even if that were possible, your iPhone would not like a subsystem disappearing from existence. It isn't designed to handle that contingency and will surely fail in spectacular ways.
You seem to be saying that the iPhone SW can't be altered to tolerate the disappearance of a subsystem, I just don't believe this is true. It's a poor excuse to do nothing.
If humans are incapable of writing secure SW, then put in one or more physical switches that powers down all transmitters, and write SW that can adapt to this. Don't tell me that's impossible or even all that difficult.
>This seems like a problem that could be fixed.
The problem is that it's illegal to reflash the firmware, because the Radio Frequency Giveaway Committee* is scared that people would abuse that to send on frequencies that they haven't permitted.
*Probably not the official name.
Even your CPU accepts firmware updates - in the form of microcode updates. There is no ROM any more :/ It wouldn't fix much either - find a bug/vuln in the ROM and those devices are owned "for life", since they can't be patched.
> You seem to be saying that the iPhone SW can't be altered to tolerate the disappearance of a subsystem, I just don't believe this is true. It's a poor excuse to do nothing.
I'm describing the situation as I see it today. It could; it won't. Apple has no incentive. Their shit is super secure already, haven't you heard?
> If humans are incapable of writing secure SW
We kind of are. Consumers don't really care until their inbox lands on wikileaks. @hillary waves
The point happened when those devices were being common enough so that there is a good enough opportunity to use it as an intelligence and information gathering tool.
Not saying it's right or wrong, but until around 2010, smartphones were not mainstream enough for the government to be interested. If you're a government and you have a lot of resources, things get done pretty quickly, especially in sensitive matters like this one.
> our personal computing devices are completely out of our basic control
I can't speak about the security of the latest iOS versus the latest custom ROMs. There may be a reason he didn't recommend these. Or maybe he knows some people are too attached to Apple to move away and is trying to do the best he can for them.
And if you are truly paranoid, it's simple to disassemble the phone and look for/remove any backup batteries. I know, I had to pull the backup battery from my wife's Moto G after it fell in the sink.
I see the argument that there is a use case for the smartphone for taking pictures while operating without radios. But wouldn't a better solution then be a compact digital camera and a notebook? You can invent your own code for note taking that becomes arbitrarily hard to break. You can disguise a compact camera as a smartphone using just a case and a hot glue gun.
There are also many times that people have been unhappy because I have my phone off and unable to reach me. There are also other times you want to be available.
Unfortunately, if your phone is owned then they can just exfiltrate the data when normal data transfer occurs. The data will still need to be stored for transmission later though.
With the iphone, you also need to monitor Bluetooth and WiFi in addition to cellular activity. Hopefully they will also monitor these.
The one in my old Atrix was a good 250mAh.
When a phone is off or out of power, is the baseband periodically pinging cell towers?
Also how do you trigger an emergency call ? manufacturer embeds a special firmware so you don't have to boot the main OS and only use energy for the call ?
As for what the full intended purpose and potential capabilities of these secondary batteries are, I have no idea since that's not documented. I do know that it's for a whole lot more than an RTC, however.
I'd love for it to be true though.
You are thinking about the wrong one.
(good luck, as this is false)
I'm not sure I like your attitude. This is readily available information
This doesn't even make much sense to me. Assuming you're talking about emergency calls, the application processor is necessary for dialing. You'd need to power the entire phone including the screen to make an emergency call.
0: http://www.popsci.com/sites/popsci.com/files/styles/large_1x...
Much less conspicuous if you're in public under physical surveillance, and provides options for phones with non-removable batteries assuming the right modifications are made.
You need to prevent the thing from recording you in the first place.
As someone who knows a bit about computer security I find it mindblowing that journalists would go into war zones and expect to be stealthy with their smartphones in their pockets but they apparently are willing to risk their lives for their iPhones, so the best we can do is offer tools to mitigate the risks.
I mean, I'm a programmer, I am not an expert on sigint stuff, but I don't think it's very hard to innovate in intelligence gathering technologies.
http://neo900.org/stuff/cccamp15/ccc2015talk/neo900-wpwrak_C...
In addition to the required hardware modification, a sufficiently nefarious attacker might be able to spoof test points. RF power detection, on the other hand, can't lie. If it's going to communicate, the phone must transmit.
An RF-detection tool would be as easy as a phone case (and could double as a backup battery for the phone). It'd be far simpler and easier to adopt than directly hacking on the hardware.
Edit: My concerns are partially addressed in the actual paper: https://www.pubpub.org/pub/direct-radio-introspection
Along the same lines, but only successful if the user isn't looking, would be to use the flashlight LED.
Or maybe very short low power vibrations, if the receiving microphone is on the same surface.
All of these require somewhat particular situations, but fun to think about in any case :)
</plug>
Interestingly enough, after some fiddling I could get it from my speakers to phone mic, and phone speakers to laptop mic, but only in the audible spectrum, not in the ultrasonic. Only response I got was one time, an error--probably one packet that failed the CRC check, but the rest of the time nothing.
I didn't have time to mess with the code and try different modulation frequencies yet. But it's definitely a cool toy! :D
I'm also curious to hear what the error was. Do you mean an error occurred in the JS console? That isn't supposed to happen in any event.
If you want to more thoroughly test, try https://quiet.github.io/quiet-profile-lab although it's worth noting that this tool can only work on one device, transmitting to itself
Finally, it's intended to be a production library, not just a toy ;)
edit: it's worth noting that if your receiver is Firefox, you'll never get anything from ultrasonic. That's because firefox resamples to 32kHz, cutting off any frequencies above 16kHz
I used Chromium Linux on the laptop and and Chrome for Android on the phone end. I normally use Firefox as my main browser but I opted for Chrome because I assumed it was a PoC and you'd need a lot of uninteresting work to make it smoothly cross-browser and most people here develop for Chrome first--I'd save that effort for the weaponised exploit ;) Or production library, in your case ;) (what is the use case there btw?)
Thanks for the heads-up on Firefox's resampling, so I know not to try that ;) Wonder if they chose that for security reasons? Seems a solid protection exactly against this. If so, then comes the question how good their lowpass (resampling) filter is, if nothing leaks through and you can't secretly grab ultrasonics anyhow via longer statistical methods trying to infer which freqs are aliased and which aren't :)
So, I tried the audible signal first, to be sure it was making sound (I have my Firefoxes locked down rather tightly, JACK and PulseAudio often fight, so unless it's a mediaplayer or audio-production tool, it doesn't make sound usually). But Chromium did (after re-enabling Pulse). I got decent results for both ways (sometimes partial text, I didn't try images), so recording worked too and the multimedia JS code seems to work fine.
One idea on that end; And I never wrote JS audio (I plan to, though) so I don't know if this is hard, but maybe next to the "listen" buttons, you could add a simple VU-meter bar for the mic, so I can clap my hands and check if the mic is indeed receiving (maybe your profile-lab already does this, havent checked).
The error I saw looked like an intentional popup-message you wrote in the code. It was a modal DIV popup, styled like the site, more like a debug message perhaps. I didn't quite understand it, so I don't remember it exactly: that it received 1/100 packets, and failed checksum ... sorry I can't be more specific, I only saw it once. It seemed to indicate it detected one packet but it was an incorrect one, or something similar. Given the config mentions CRC checks, I assumed it was that.
I didn't check the JS console for messages, but the behaviour of the site didn't indicate to me that there were actual JS errors.
Extra info: The sound from Chromium Linux was played through high quality large speakers, the microphone is built-in (Eee 1215B netbook, rather old thingy) so probably not very good. On the phone side, it's running Cyanogenmod on a Samsung S4. I believe the mic on the phone is better than on the laptop because it's rather old and quite noisy.
Is there a reason the profile-lab tool only works for one device transmitting to itself? Cause that's part of the fun (yeah yeah no toy :p), transmitting data between two devices that have no connection to each other. If I was to be thorough, I'd set it to airplane mode just to prove the fact :)
I'll have another play with quiet.js and also the quit-profile-lab. If I see the error message again or find anything I didn't describe above, I'll report back. If you got any specific things you'd like me to test, let me know.
First, I played again with quiet.js
This time it seemed harder to get it to detect even audible signals. I'm pretty sure I don't have more background noise today than yesterday, but my laptop fan can be pretty loud (and is less than a foot from the mic), so maybe it's spinning louder today.
I have to hold my phone (mic) real close to the speakers to get it to do anything (yesterday as well, btw). The other way around, I also have to hold my phone (speakers) real close to the laptop mic. But IMHO that might be more expected since the phone speakers are so tiny and tinny, and the laptop mic is so crappy.
I also got the error messages again! (and I misremembered, they're not modal). Seems it's just the message you get when it loses some packets. Yesterday I just happened to get either 100% loss or perfect transmission, so it wasn't immediately clear what ".. set the volume to 50%. Packet Loss: 1/1 (100%)" meant. For a production library, I'd definitely take note, for usability. I'd like to have a clear indication that the mic is actually receiving (can be very minimal, even just a little circle that fades from black to red depending on the level). Also "set volume to 50%" is (for me at least) quite ambiguous :) I have ALSA, Jack and Pulse applying their dB levels, through my laptop jack to my stereo amp which has again a big volume button, I won't even ask what is 50% here, because there is no answer :) I presume this is to prevent distortion artifacts, which may be present on phone and laptop speakers (but not my big ones ;) Are there maybe any modulation schemes that are (somewhat) robust against (overdrive/amp) distortion?
Here's screenshots of the messages: http://imgur.com/a/4x3Tu . First one is mobile (receiving), also IIRC that's the exact message I got yesterday on the laptop. The second one is from the laptop today (also receiving), only after seeing that message I understood what the earlier really meant because the numbers were more arbitrary ;) (1/15 7%)
I didn't try the ultrasonic frequencies because I couldn't get the audible ones to work reliably (I'll leave the no-fun debugging of something you can't hear to the professionals ;) )
Then I tried the quiet-profile-lab. I can't get it to work. The mic frequency spectrum visualiser works well, showing frequencies as expected, also for other sounds like clapping my hands. But "Frames Received" stays at 0. Screenshot: http://i.imgur.com/Jj0UWwx.png -- I set the centre frequency to 8kHz for this one, because it has a lot of noise on the low and the high ends. The low noise is probably the crappy mic, but the high-freq noise is somewhat surprising to me. I'm not sure at what freq my laptop-fan is whooshing, but it sounds like a low-mid tone plus mid/high-mids noise to me (based on the sound, not visualiser). Also tried other centre-frequencies, no luck.
Oh WOW, trying quiet-profile-lab on my phone, the mic is so much clearer, it's not even funny, check the screenshots: http://i.imgur.com/iUpWpOW.jpg http://i.imgur.com/MtrEYrb.jpg loud and clean signal at 4kHz (centre freq) and a much quieter harmonic at 8kHz (and you can even see a tiny 3rd hardmonic at 12kHz). And also in the ultrasound, look at this nice clean spectrum: http://i.imgur.com/9DUO7V7.jpg
So, I guess if you guys want to improve accuracy on crappy systems like my laptop, you may get much better results after a noise-removal filter? From experience a lot of my laptop mic's noise is quite stationary. A tip: the Audacity wiki on its noise-removal filter is quite extensive, technical and informative. Also the (C++) source code for that filter is surprisingly readable (bit long, but most of it is comments). Reading it, I gained a lot of respect for that feature and believe it's one of the better ones out there (definitely in FOSS).
Sorry I'm not going to play with the quiet-profile-lab on my phone much further, because it's not a toy and I've already spent 1.5 hour on my saturday evening ;-) [what can I say, I love DSP, and I love side-channels]
Friendly advice on the quiet-profile-lab UI (even though it's not for production): You got the settings left and the output right. Occasionally, a change in settings wasn't always applied right away, so I figure it would be nice if the output column would display a short summary of the parameters on the left, that it is currently playing.
I'm not that familiar with various modulation / operating modes, but I assume the flow goes like: listen to sound > detect a packet > decode+checksum the packet. Maybe it'd be nice to visualise this onto a slow-moving (cyclical buffer) waveform of the mic input: black=just sound, blue=possible packet, red=decoded bad checksum, green=decoded correct checksum.
So! I hope this extensive feedback is useful to you! Sorry if it's a bit rambling but it's weekend so I'm not going to edit (the thread is old enough I'm sure no one will mind this mammoth post). If you make got a cool new feature or improvement in your library, I'd love to hear about it and you can hit me via email (see my profile).
afterthought: it's kind of disturbing the difference in perceived level between 14.5 and 15.5 kHz, I can hear it but need to turn it up quite a bit, I am 35 years old. Even higher and it disappears further but replaced by a cleaner mid-frequency "windy" noise (that isn't quite there at lower centre freqs). quite a difference from when I tested my hearing range using pure sine tones generated in audacity (when you do this, tip: always add a fade-in otherwise the click makes it even harder to tell if you're hearing something or not). also I really feel for the person who has to test this setup every day ;-) given it's a serieous project, do you ever invite kids into your office? I work with kids in a creative science-lab / hackerspace type of centre, so we did the hearing tests a couple of times, as I said for the 15kHz I need to turn it up to be able to hear it clearly, when I did that with kids in the room (ages 9-13) they were all like "AAAAAAAAAAAA TURN THAT OFF!!" at the level when I felt, "I can comfortably detect this tone". And kids can easily hear a few kHz's higher than that even. But for me, the perceived level sharply plummets after a certain frequency. So maybe interesting to check, those sounds you perceive as barely audible might be distressingly loud beeps for other people. (fun fact: on the low end, 20-30Hz, seems we're all pretty much equal regardless of age--you need quality headphones to test those freqs though or the sound you think you hear is in fact harmonics from distortion).
Overall, I'm not really sure how much faith I'd place in noise reduction here. I feel that in general, applying another non-linear process to the signal may just make matters worse. It's hard for me to say since all of the noise I've encountered has been low-frequency ambient/fan noise, which can be easily avoided by just shifting the signal further up. At any rate, the process of cancelling noise for human speech versus modulated tones would look completely different. The hardest obstacles to overcome so far have been non-linear blocks in the receiver, which cause much more distortion than tinny speakers or a mediocre mic.
Firefox downsamples in order to save CPU cycles on noise reduction and echo cancellation.
Also yeah, I forgot about the div that gets added. Since that page is just a demo, I don't necessarily see any reason to display additional receiver info. The hope is that this is a workable library that won't put a lot of burden on the end-user in order to confirm it's working. Perhaps all that's missing here is looking at signal energy just to confirm that the mic isn't muted, and displaying something if it is.
The lab only transmits to itself because of UI sync difficulties. It is on my road map to come back to this later, but essentially the issue is that the receiver has to have the same setup as the transmitter, which would require some out-of-band method to sync up. Running it on my laptop seems to be a perfectly workable way to test the config.
did you mean to say "sub 20 Hz"? or rather the ultrasound between 20kHz and 22kHz?
it's a bit ambiguous cause both 20 Hz and kHz are lower and upper ranges of human hearing, respectively.
if you meant the lower, then no. mobile speakers already almost entirely lack power in the musical bass frequencies (50-150Hz roughly), let alone the infrasonic ones. if the speaker would even have a response to such a signal, it's not going to have a lot of range. .. a sub-20Hz audio signal has a wavelength of more than 17 metres in air, I'm not sure if that's physically impossible, but I'm having a hard time imagining that tiny tweeter to manage such a signal (my knowledge is mostly with digital signal processing, not entirely sure about what speakers can do, Bose has done some pretty amazing room-shaking bass with very clever tiny speakers, that seemed impossible to me as well, has to be some trick there). And then, doing it without getting harmonics in the audible spectrum! :)
I'm guessing it comes down to making sure the signal is from the phone and not from an external source.
All modern wireless protocols have multiple devices share a single frequency range. Thus just listening for traffic on those ranges with an antenna will produce false positives.
Seems to me that removing the battery would be safer.
https://github.com/mtker/MT6735_Longcheer
Actually there is some .o files in the baseband but easy to pull apart in IDA. Each one relates to a single .c and there are export symbols.
My initial thought was they'd have to redesign it for every phone, but that's not necessarily the case. If eaves dropping is such a concern for you, I would think you would be okay with not having the latest gen phone. Or having an old one just for these sorts cases.
I suppose the concern then shifts to whether this device is easily subverted, or whether it's easy to determine if it has been subverted.
1. add a physical "off" switch that cuts battery power to everything
2. (Hard Mode) Cut power to all radio chips/subsystems (GSM, WIFI, bluetooth) while leaving the rest smartphone operational for taking pictures or recording audio?
Basically, a radio firewall. So you can enforce absolute radio silence if needed. And log the signals.
But trying to solve an obvious problem (proprietary basebands, phones, and hardware) with bandage solutions kicks the problem down the road. We need to liberate the hardware eventually for liberty's sake.
And if you are in war zone - using a phone with removable battery is absolutely mandatory IMO.
https://security.stackexchange.com/questions/65382/is-it-pos...
Do you have a vested interest in the matter?
Or in an iPhone?
No? Yeah...