autotldr@lemmings.world
on 31 May 21:30
nextcollapse
This is the best summary I could come up with:
Forbes uncovered a seriously dated NSA document outlining the best practices for keeping your phone safe from bad actors in the digital space.
The phones depicted are a 2010s-era iPhone with the original push-button Home button and a Samsung Galaxy smartphone.
Over a dozen tips are included, ranging from “considering using Biometrics” to “only use original charging cords.” It’s all fundamental stuff you’ve seen before, but the advice that’s got everyone’s ears perked up is the NSA’s suggestion to power your device off and back on weekly.
It’s a simple way to either force a waning software update or clear any background apps and memory leaks that might contribute to a too-hot-too-handle metal phone.
I’m a frequent restarter because I have cell signal issues in my area—a quick reboot usually does the trick, though not without my heart beating rapidly as I wait to see those mobile service bars return.
The Google Pixel doesn’t have a scheduled offering, but there is an option you can toggle on to have the device automatically restart once it receives an over-the-air (OTA) software update.
The original article contains 314 words, the summary contains 181 words. Saved 42%. I’m a bot and I’m open source!
henfredemars@infosec.pub
on 31 May 21:52
nextcollapse
You do it because it makes an attacker’s life harder because now I have to find two bugs instead of one.
The entire boot chain of the phone up to the apps you run are verified successively by the component that loads it. A digital signature helps ensure that only trustworthy code ever runs. A bug must be found to bypass these checks to load malware code. For example, a bug in the image code in a web browser might cause loading of code that isn’t checked. This way the malware gets smuggled onto the phone.
This means that if you get hacked via one bug and malware is loaded, the attacker has to work harder to solve the problem of how do I convince the phone to load it again at boot because the code it’s made of isn’t going to be approved code. When you reboot, you are effectively forcing a validation that all the code you have running is authentic, which would exclude the malware. Trick me once sure, can you survive a full pat down? Probably not. It’ll get caught.
Unless I have a second bug to fool the normal code loading systems too, the malware can’t run. You have to go back and trigger the first bug again somehow, which places more strain on the attacker.
cranakis@reddthat.com
on 31 May 22:08
nextcollapse
Thanks for taking the time to write that out. I found it really helpful.👍
Personally, I restart mine maybe once a week. No need to go crazy with it, but it helps make life harder for bad actors and might make your phone run better.
I can’t blatantly associate this account with other identities but I’ll say that I’ll be at DEFCON32 sniffing the air and shaking hands on the Wild Wild West of the open LAN.
I insert a lie or two about real life details every now and then to mitigate profiling. But the gist of what I write is always me.
If you have a blog where you talk about that, I would like to read it.
some_boring_username@lemm.ee
on 31 May 22:26
nextcollapse
Exactly, as you already explained in detail this is primarily for security.
GrapheneOS has a feature to set a time after which the phone reboots in case there was no unlock. So in case a bad actor gets your phone they only have that time with a running system after the first unlock. However, if you use it normally, and unlock it in regular intervals it does not auto-reboot. This is especially neat if your threat level is not “investigative journalist” or “political activist on the run”, because then you can set the time to a longer interval and the phone does not reboot every night when you are asleep which also leads to the SIM card being locked and nobody being able to call you…
I remember this feature, and I wish it was a standard Android feature. It sounds like it would be trivial to implement and could be completely optional.
Pixels with grapheneos can reboot automatically after a number of hours with the screen off (unattended because you are sleeping). But this would also interfere with Whatsapp backup, which happens overnight.
But that only works for untrusted code escaping a sandbox, right? It does not help with malicious code embedded into legitimate seeming apps. The later vector seems easier, especially on Android, no?
I don’t really consider a malicious app to be an exploit. In this case, the software is doing exactly what it was designed to do – malicious activity. It’s not being manipulated to perform unintended operations through the exploitation of a software bug. Code signing and secure boot are not effective in the face of intentionally shipping malicious code to end users. It’s designed to frustrate actual hackers.
For malicious-by-design apps, we rely on a central app store that hopefully reduces the number of bad apps in circulation. If you publish malware, eventually you get caught and we know who you are. Sandboxing with a permissions system helps prevent apps from performing actions contrary to the user’s interests. E.g. why is my flashlight app asking for my contacts when I pressed ‘change color?’
If you directly exploit your way in, it’s harder to know who did this and why because you didn’t go through any central vetting or accountability system, and you’re not so easily bound by the permissions system. It depends on what your bad guy’s goals are, what they want, whom they’re targeting. Force your way in the back entrance, crawl through an open window (like a weak security setting), or lie your way in the front door (trojan)? It depends.
None of it is perfect, but I’m sure OS design experts would love to hear about better solutions if any exist.
wouldn’t a malicious app still be an exploit though? I’d say that if I download an app for playing a game, but instead it was designed to also upload my private photos to the attacker’s server, i’d say that’s still exploiting. It’s just exploiting my expectations of what the app should do, rather than leveraging a system weakness (which it probably does, anyway)
You’d have to grant the app permission to access your photos. At this point, I would say the problem is more the person in the driver’s seat. You can’t really protect the user from themselves. If you had a legitimate reason to grant access to your photos, then we definitely have a problem.
You can think of this as a kind of exploit if you prefer. However, this becomes a permissions and ecosystem and reputation issue and not really a technical software one. Because you’re looking at a totally different set of tools, I think it’s useful to restrict exploit to refer only to bugs.
You could take that argument one step further and ask what if my new phone comes with preinstalled malware? The system collapses if you can’t have some level of trust the software you’re running.
Idk man I just do it when my phone won’t ring when I get a call from my dad or doctor or something, so I have to go delete the voicemail and call them back. So like, every couple of weeks. I think it’s a Samsung thing, happened on my last phone too.
Nothing wrong with that. I don’t think it’s a mistake to not reboot your phone until you need to. It’s your phone. It’s not like rebooting your phone will save lives or the planet.
My wife doesn’t even use a lock screen password. I’m interested in the nuances of such things.
Reboot Daily: According to research from Amnesty International and Citizen Lab, Pegasus often relies on zero-click 0-days with no persistence. Regular daily reboots can help clean the device, making it necessary for attackers to repeatedly reinfect, thereby increasing the chances of detection over time.
For a case with persistence, Lookout notes another bug was required and details the extra work.
recursive_recursion@programming.dev
on 31 May 21:53
nextcollapse
TL;DR:
Restarting your phone once a week can help improve performance and security.
this is the same for routers and it’s commonly known as a power refresh
Not always. Some phones will do a sort of "soft" reboot, which doesn't actually go through the entire boot process, but is more like logging out of the active OS user and back in, reloading some of the OS but not all.
Pretty sure a system update would trigger a full reboot, though, but I've seen the option for this sort of partial reboot in the power menu on some devices in the past.
cyberpunk007@lemmy.ca
on 31 May 23:02
nextcollapse
well, I mean… anything can leak memory. but yeah, enterprise/carrier grade devices are designed to be in continuous use for years and they generally do that pretty well.
sugar_in_your_tea@sh.itjust.works
on 31 May 23:38
nextcollapse
Even then, some places will reboot on a schedule when nobody should be using it.
I have some entry level “enterprise” hardware (Mikrotik router and Ubiquiti access point) and I auto-reboot mine weekly. In addition to maintaining performance and minor security wins, it also helps ensure everything csn survive a reboot (e.g. all configurations have persisted to disk).
It’s good practice. Some people brag about continuous uptime, I see it as a liability.
cyberpunk007@lemmy.ca
on 01 Jun 00:10
nextcollapse
It’s good practice for patching purposes. You should always be maintaining stable OS versions and a memory leak or the like is fairly uncommon. I think I’ve seen it once in my career on a particular check point OS version.
sugar_in_your_tea@sh.itjust.works
on 01 Jun 02:16
collapse
Yeah, I’m more worried about keeping up on patches and ensuring things will start back up properly than memory leaks. But minor security and performance wins are nice too.
dustyData@lemmy.world
on 01 Jun 01:14
nextcollapse
That’s why all master systems have a backup At least on datacenters 10 years ago is how we did it. We could run a patch, system update, data backup, system restart or whatever it was required to almost any piece of kit on the racks without losing continuity of service. Just do the backup first, then the same operation on the master, if any of them fails the whole architecture is designed to pick up the tasks and continue as if nothing wrong is going on. It was expensive, but they were mission critical banking infrastructure. The thing only went out for account balancing, but it was at 3am when it was likely that no one would need it, and even then for the user there was no loss of service. Transactions still went through, just with a couple of hours of delay for the whole ordeal to sync up.
Absolutely. Nothing scarier than rebooting the computer or router that’s been running for 10 years.
I also enjoy exercising software blue/green rotation weekly. Even if no code changes, have it roll to the alternate infra on an automated schedule. Is a great habit to get into and helps any engineer sleep better. It also results in providing very accurate downtime recovery numbers - not estimates.
Phone batteries are typically designed to last around 2 years before they really degrade because a lot of people buy new ones around every 2-3 years.
When the battery can’t sustain the same throughput, the phone can handle this in one of two ways.
Slow the phone down. This is what Apple does and why people with iPhones 2 years old complain the new update slowed their phone down.
Don’t slow it down but if the throughput drops below what’s needed, die and reboot. This is what your phone is doing.
Getting a new battery will probably stop this behavior (and for iPhone users reading this, getting a new battery for a 2 year old phone will make your phone faster).
My phone is 3 years old and is still going strong. The battery feels the same to me as the day I bought it, but I also don’t consume a full battery in a day.
Didn’t really have much installed aside from revanced and Firefox
ElderWendigo@sh.itjust.works
on 01 Jun 02:06
nextcollapse
This is gonna sound odd, but have you cleaned out the USB port lately? Weird stuff happens when pocket lint collects in there. I thought mine had a dead port until I picked out (with a non-conductive toothpick) the lint I didn’t realize had accumulated.
jbk@discuss.tchncs.de
on 01 Jun 09:44
nextcollapse
Don’t e.g. alarm apps not work after that until you unlock your phone since the device data decryption keys weren’t kept in RAM after rebooting? I have that feature off since I don’t want that to happen. Afaik AOSP has added that to make installing updates more seamless, but it’d be useful for this too. (And since Samsung usually sucks at improving their already self-made stuff to align with AOSP, like Virtual A/B updates, I’m just assuming this)
MeatsOfRage@lemmy.world
on 01 Jun 12:55
nextcollapse
Android auto fails to load for me so often I’m pretty much restarting every day anyway
Really? My S22u is super stable. I don’t think it’s ever crashed. The current up time is 377 hours. But that’s only because of the 6.1 update a few weeks ago.
It’s a feature. <img alt="" src="https://lemmy.world/pictrs/image/35279297-d86f-400b-9b9c-ea7e9ba8834f.png">
variants@possumpat.io
on 31 May 22:11
nextcollapse
I remember my old phone had the option to auto reboot and I had it set to like 3am but now I don’t see that option on newer phones. My previous phone didn’t even have a reboot option I had to shut it down and power it back up
hal_5700X@sh.itjust.works
on 01 Jun 00:27
collapse
For Samsung phones. Go to Settings -> Device Care -> Under Performance you will see Auto Optimization -> At the bottom of the page you will see Auto Restart -> Restart on Schedule -> Done.
For iOS they do; I would assume for Android they will as well. It would be pretty bad if an automatic update stopped you from waking up in the morning…
variants@possumpat.io
on 01 Jun 03:10
nextcollapse
I’ve noticed my phone doesn’t initialize anything until I unlock it then it takes a while for it to boot up and all that but also I haven’t seen it reboot on its own, it usually gives you a prompt
TIL, I use GOS and never thought to look, I just see a banner saying there’s been updates and I’ve got “update and restart now”, “schedule restart” and “I’ll restart myself when ready” (or some such).
The main purpose of this is actually security. Because when the device is in BFU (before first unlock) state, it's much harder to gain access to the data (without the correct unlock credentials). During the reboot, the encryption keys are wiped from RAM, making it essentially impossible to access the device, since brute-force unlock attempts are prohibited by Weaver API, which is enforced by the Titan M2 hardware security module. You can read more about this at https://grapheneos.org/faq#encryption
I will give that a read. I have been unintentionally using this feature, anytime I expect I won’t use the GOS pixel for a bit I restart it, I’ve also found it disables biometrics as a security measure. Cool stuff.
It doesn't intentionally disable biometrics. Disabling biometrics is just a logical consequence of wiping the encryption keys from RAM. Your data is encrypted with your password as the key (not exactly, it first goes through a key derivation function, but the PIN/password is the entry point for the KDF). Your biometric information can't decrypt your data, as your data is not encrypted with your biometric information as the key. When using biometrics, the encryption key is kept in RAM, and the biometric data is only validated by the OS. No actual decryption occurs here. The data on your phone is only being decrypted during the first unlock after a reboot. That's why security states are grouped into BFU (before first unlock) and AFU (after first unlock).
I’d love to see your list of “stupid” things… not immoral, vicious, incendiary, criminal, etc…but stupid. None of those things is stupid if they are also your fundamental mandate.
pewgar_seemsimandroid@lemmy.blahaj.zone
on 02 Jun 09:04
collapse
iPhone batteries are small in general. My GF’s iPhone se (don’t ask me which gen) barely lasted half a day, and took hours to charge. So a couple of years ago I bought her a Z Flip 3 for her birthday because all the girls in the Korean shows she watches had that phone at the time. Now her battery actually lasts a full day, and the phone charges to full in 45 minutes.
The larger iPhones easily last a day. The SE (any gen) are fairly small and thin and don’t have very large batteries. The 12 and 13 mini are also very small and thus don’t have much battery life. If you have a regular sized iPhone or even a Max, battery life is fine, on the bigger ones good even.
I’m just going to assume that you’re right because I know nothing about Apple devices and their capabilities.
ObsidianZed@lemmy.dbzer0.com
on 01 Jun 15:52
nextcollapse
I use Tasker automation that reminds me to reboot after my phone has been up for awhile. I don’t think I’d like an auto reboot feature. I don’t even like it when I can’t postpone a software update until a time convenient for me.
drawerair@lemmy.world
on 02 Jun 00:01
nextcollapse
I’m doubtful. I wanna hear more from security experts.
The bootloader of your phone (if locked) is one of the most secure parts. It’s very hard to get into a modern phones bootloader. In contrast, finding an exploit in a running phone is a lot more feasible.
If a vulnerability was abused to get into your running phone, it will persist until the phone reboots, and the bootloader verifies the core parts of the operating system at startup. In order to persist past a reboot, malware like that would need a vulnerability in the bootloader, or a bypass for its integrity checks.
Alongside that, any background services (“daemons”) that got stuck or became slow over time are forced to restart. Operating system updates can be applied, and working memory is cleared.
In general, it’s just good advice to just reboot your phone once in a while. There’s no harm in doing so.
GrapheneOS has an option to restart the phone after a given time without any successful unlock. I have it set to 8 hours, so it reboots every night. Shorter is possible.
A freshly restarted phone is in its safest state. Necessary to input the unlock code, strict minimum required processes running in the background.
threaded - newest
This is the best summary I could come up with:
Forbes uncovered a seriously dated NSA document outlining the best practices for keeping your phone safe from bad actors in the digital space.
The phones depicted are a 2010s-era iPhone with the original push-button Home button and a Samsung Galaxy smartphone.
Over a dozen tips are included, ranging from “considering using Biometrics” to “only use original charging cords.” It’s all fundamental stuff you’ve seen before, but the advice that’s got everyone’s ears perked up is the NSA’s suggestion to power your device off and back on weekly.
It’s a simple way to either force a waning software update or clear any background apps and memory leaks that might contribute to a too-hot-too-handle metal phone.
I’m a frequent restarter because I have cell signal issues in my area—a quick reboot usually does the trick, though not without my heart beating rapidly as I wait to see those mobile service bars return.
The Google Pixel doesn’t have a scheduled offering, but there is an option you can toggle on to have the device automatically restart once it receives an over-the-air (OTA) software update.
The original article contains 314 words, the summary contains 181 words. Saved 42%. I’m a bot and I’m open source!
You do it because it makes an attacker’s life harder because now I have to find two bugs instead of one.
The entire boot chain of the phone up to the apps you run are verified successively by the component that loads it. A digital signature helps ensure that only trustworthy code ever runs. A bug must be found to bypass these checks to load malware code. For example, a bug in the image code in a web browser might cause loading of code that isn’t checked. This way the malware gets smuggled onto the phone.
This means that if you get hacked via one bug and malware is loaded, the attacker has to work harder to solve the problem of how do I convince the phone to load it again at boot because the code it’s made of isn’t going to be approved code. When you reboot, you are effectively forcing a validation that all the code you have running is authentic, which would exclude the malware. Trick me once sure, can you survive a full pat down? Probably not. It’ll get caught.
Unless I have a second bug to fool the normal code loading systems too, the malware can’t run. You have to go back and trigger the first bug again somehow, which places more strain on the attacker.
Thanks for taking the time to write that out. I found it really helpful.👍
I love to talk about computer security. I don’t get the chance often enough.
I hope you get more chances to do so; you explained the situation in a much better way than the article and convinced me to reboot my phone.
You restart your phone because of security.
I ‘restart’ my phone, because it’s overheated and lost its battery % to 0.
We’re not the same.
Thank you, friend. You’ve convinced me to restart my phone.
Personally, I restart mine maybe once a week. No need to go crazy with it, but it helps make life harder for bad actors and might make your phone run better.
I hope to hear you* on Darknet Diaries hahaha
I can’t blatantly associate this account with other identities but I’ll say that I’ll be at DEFCON32 sniffing the air and shaking hands on the Wild Wild West of the open LAN.
I insert a lie or two about real life details every now and then to mitigate profiling. But the gist of what I write is always me.
If you have a blog where you talk about that, I would like to read it.
Exactly, as you already explained in detail this is primarily for security.
GrapheneOS has a feature to set a time after which the phone reboots in case there was no unlock. So in case a bad actor gets your phone they only have that time with a running system after the first unlock. However, if you use it normally, and unlock it in regular intervals it does not auto-reboot. This is especially neat if your threat level is not “investigative journalist” or “political activist on the run”, because then you can set the time to a longer interval and the phone does not reboot every night when you are asleep which also leads to the SIM card being locked and nobody being able to call you…
I remember this feature, and I wish it was a standard Android feature. It sounds like it would be trivial to implement and could be completely optional.
I wonder if tasker could do it… 🤔
I don’t think applications can reboot the phone.
Technically they can…but it requires root which within the context of this conversation yeah, you’re right, lol
I miss my BlackBerry and it’s scheduled reboot option
Pixels with grapheneos can reboot automatically after a number of hours with the screen off (unattended because you are sleeping). But this would also interfere with Whatsapp backup, which happens overnight.
Samsung phones also have a reboot schedule option
And in addition to that, they also have automatic reboot if the phone detects performance degradation.
Where?
Settings > Device care > Auto optimization > Auto restart
Thanks!
But that only works for untrusted code escaping a sandbox, right? It does not help with malicious code embedded into legitimate seeming apps. The later vector seems easier, especially on Android, no?
I don’t really consider a malicious app to be an exploit. In this case, the software is doing exactly what it was designed to do – malicious activity. It’s not being manipulated to perform unintended operations through the exploitation of a software bug. Code signing and secure boot are not effective in the face of intentionally shipping malicious code to end users. It’s designed to frustrate actual hackers.
For malicious-by-design apps, we rely on a central app store that hopefully reduces the number of bad apps in circulation. If you publish malware, eventually you get caught and we know who you are. Sandboxing with a permissions system helps prevent apps from performing actions contrary to the user’s interests. E.g. why is my flashlight app asking for my contacts when I pressed ‘change color?’
If you directly exploit your way in, it’s harder to know who did this and why because you didn’t go through any central vetting or accountability system, and you’re not so easily bound by the permissions system. It depends on what your bad guy’s goals are, what they want, whom they’re targeting. Force your way in the back entrance, crawl through an open window (like a weak security setting), or lie your way in the front door (trojan)? It depends.
None of it is perfect, but I’m sure OS design experts would love to hear about better solutions if any exist.
Your explanations really are poetry.
Aww, thank you!
wouldn’t a malicious app still be an exploit though? I’d say that if I download an app for playing a game, but instead it was designed to also upload my private photos to the attacker’s server, i’d say that’s still exploiting. It’s just exploiting my expectations of what the app should do, rather than leveraging a system weakness (which it probably does, anyway)
You’d have to grant the app permission to access your photos. At this point, I would say the problem is more the person in the driver’s seat. You can’t really protect the user from themselves. If you had a legitimate reason to grant access to your photos, then we definitely have a problem.
You can think of this as a kind of exploit if you prefer. However, this becomes a permissions and ecosystem and reputation issue and not really a technical software one. Because you’re looking at a totally different set of tools, I think it’s useful to restrict exploit to refer only to bugs.
You could take that argument one step further and ask what if my new phone comes with preinstalled malware? The system collapses if you can’t have some level of trust the software you’re running.
Idk man I just do it when my phone won’t ring when I get a call from my dad or doctor or something, so I have to go delete the voicemail and call them back. So like, every couple of weeks. I think it’s a Samsung thing, happened on my last phone too.
Nothing wrong with that. I don’t think it’s a mistake to not reboot your phone until you need to. It’s your phone. It’s not like rebooting your phone will save lives or the planet.
My wife doesn’t even use a lock screen password. I’m interested in the nuances of such things.
Guessing Pegasus and their ilk have an easy way around this
Nope! From Kaspersky:
For a case with persistence, Lookout notes another bug was required and details the extra work.
TL;DR:
Restarting your phone once a week can help improve performance and security.
I wonder if the regular updates mine does count.
Yes, a reboot is a reboot. As long as the boot sequence cycles through where the code is validated, you’re good.
Not always. Some phones will do a sort of "soft" reboot, which doesn't actually go through the entire boot process, but is more like logging out of the active OS user and back in, reloading some of the OS but not all.
Pretty sure a system update would trigger a full reboot, though, but I've seen the option for this sort of partial reboot in the power menu on some devices in the past.
Maybe home grade routers.
well, I mean… anything can leak memory. but yeah, enterprise/carrier grade devices are designed to be in continuous use for years and they generally do that pretty well.
Even then, some places will reboot on a schedule when nobody should be using it.
I have some entry level “enterprise” hardware (Mikrotik router and Ubiquiti access point) and I auto-reboot mine weekly. In addition to maintaining performance and minor security wins, it also helps ensure everything csn survive a reboot (e.g. all configurations have persisted to disk).
It’s good practice. Some people brag about continuous uptime, I see it as a liability.
It’s good practice for patching purposes. You should always be maintaining stable OS versions and a memory leak or the like is fairly uncommon. I think I’ve seen it once in my career on a particular check point OS version.
Yeah, I’m more worried about keeping up on patches and ensuring things will start back up properly than memory leaks. But minor security and performance wins are nice too.
That’s why all master systems have a backup At least on datacenters 10 years ago is how we did it. We could run a patch, system update, data backup, system restart or whatever it was required to almost any piece of kit on the racks without losing continuity of service. Just do the backup first, then the same operation on the master, if any of them fails the whole architecture is designed to pick up the tasks and continue as if nothing wrong is going on. It was expensive, but they were mission critical banking infrastructure. The thing only went out for account balancing, but it was at 3am when it was likely that no one would need it, and even then for the user there was no loss of service. Transactions still went through, just with a couple of hours of delay for the whole ordeal to sync up.
Absolutely. Nothing scarier than rebooting the computer or router that’s been running for 10 years.
I also enjoy exercising software blue/green rotation weekly. Even if no code changes, have it roll to the alternate infra on an automated schedule. Is a great habit to get into and helps any engineer sleep better. It also results in providing very accurate downtime recovery numbers - not estimates.
I leak memory all the time
If my router rebooted once a week, it would be in the trash can.
Feels like I need to reboot my iPhone daily in order to keep applications and tabs from being terminated from out of memory issues as quickly.
I have an old-ass iPhone XS and don’t run into this issue. But mine has a LOT of storage so maybe that helps?
Restarting anything with a chip in it once and a while is good practice.
Jokes on them, my S22 Ultra restarts in it’s own. Even when I don’t want it to.
It’s a feature! Device Failed Successfully.
Sounds like my wife’s old Samsung phone as well… I’m sensing a common theme…
And my old note 4 too…
Replace your battery.
Your phone is 2 years old.
Phone batteries are typically designed to last around 2 years before they really degrade because a lot of people buy new ones around every 2-3 years.
When the battery can’t sustain the same throughput, the phone can handle this in one of two ways.
Slow the phone down. This is what Apple does and why people with iPhones 2 years old complain the new update slowed their phone down.
Don’t slow it down but if the throughput drops below what’s needed, die and reboot. This is what your phone is doing.
Getting a new battery will probably stop this behavior (and for iPhone users reading this, getting a new battery for a 2 year old phone will make your phone faster).
Edit: Seems some of you don’t believe me looking at the downvotes. Look at number 8 in this list: helpdeskgeek.com/…/why-your-android-phone-keeps-r…
I have an s22 ultra as well, and it’s fine? Sounds more like they have some rogue apps causing the restart.
Half life is typically probabilistic.
You were lucky. They were not.
Doubt it but it is what it is. Have a nice night!
My phone is 3 years old and is still going strong. The battery feels the same to me as the day I bought it, but I also don’t consume a full battery in a day.
Didn’t really have much installed aside from revanced and Firefox
This is gonna sound odd, but have you cleaned out the USB port lately? Weird stuff happens when pocket lint collects in there. I thought mine had a dead port until I picked out (with a non-conductive toothpick) the lint I didn’t realize had accumulated.
Don’t e.g. alarm apps not work after that until you unlock your phone since the device data decryption keys weren’t kept in RAM after rebooting? I have that feature off since I don’t want that to happen. Afaik AOSP has added that to make installing updates more seamless, but it’d be useful for this too. (And since Samsung usually sucks at improving their already self-made stuff to align with AOSP, like Virtual A/B updates, I’m just assuming this)
Android auto fails to load for me so often I’m pretty much restarting every day anyway
Really? My S22u is super stable. I don’t think it’s ever crashed. The current up time is 377 hours. But that’s only because of the 6.1 update a few weeks ago.
It’s a feature. <img alt="" src="https://lemmy.world/pictrs/image/35279297-d86f-400b-9b9c-ea7e9ba8834f.png">
I remember my old phone had the option to auto reboot and I had it set to like 3am but now I don’t see that option on newer phones. My previous phone didn’t even have a reboot option I had to shut it down and power it back up
I’m using Automate for this purpose, it’s a very simple flow:
<img alt="" src="https://infosec.pub/pictrs/image/244a3743-8018-4c3b-a4c8-d80043ca90d1.jpeg">
play.google.com/store/apps/details?id=com.llamala…
For Samsung phones. Go to Settings -> Device Care -> Under Performance you will see Auto Optimization -> At the bottom of the page you will see Auto Restart -> Restart on Schedule -> Done.
Would alarms work after a restart if I don’t unlock ot first?
For iOS they do; I would assume for Android they will as well. It would be pretty bad if an automatic update stopped you from waking up in the morning…
I’ve noticed my phone doesn’t initialize anything until I unlock it then it takes a while for it to boot up and all that but also I haven’t seen it reboot on its own, it usually gives you a prompt
I have childhood memories of feature phones that would trigger alarms even when the phones were turned off.
I’ve tested this and they do still work
Awesome thank you for your testing
Wait…the NSA did something good. WTF.
Coming from the 9000 series, I am wondering what do you like about the 5700 series HAL?
GrapheneOS has a convenient auto-reboot feature
TIL, I use GOS and never thought to look, I just see a banner saying there’s been updates and I’ve got “update and restart now”, “schedule restart” and “I’ll restart myself when ready” (or some such).
The main purpose of this is actually security. Because when the device is in BFU (before first unlock) state, it's much harder to gain access to the data (without the correct unlock credentials). During the reboot, the encryption keys are wiped from RAM, making it essentially impossible to access the device, since brute-force unlock attempts are prohibited by Weaver API, which is enforced by the Titan M2 hardware security module. You can read more about this at https://grapheneos.org/faq#encryption
I will give that a read. I have been unintentionally using this feature, anytime I expect I won’t use the GOS pixel for a bit I restart it, I’ve also found it disables biometrics as a security measure. Cool stuff.
It doesn't intentionally disable biometrics. Disabling biometrics is just a logical consequence of wiping the encryption keys from RAM. Your data is encrypted with your password as the key (not exactly, it first goes through a key derivation function, but the PIN/password is the entry point for the KDF). Your biometric information can't decrypt your data, as your data is not encrypted with your biometric information as the key. When using biometrics, the encryption key is kept in RAM, and the biometric data is only validated by the OS. No actual decryption occurs here. The data on your phone is only being decrypted during the first unlock after a reboot. That's why security states are grouped into BFU (before first unlock) and AFU (after first unlock).
Thank you for your in depth explanation, hope your comments help many others on top of myself.
This! Actually a great feature on GrapheneOS, been using it for over a year now.
Samsung has had the auto reboot feature for a long time too.
Samsung - auto-restart
Samsung phones have an option of scheduled autorestart; I have mine set to restart once every week at a scheduled time.
LineageOS has this option too. The whole system crashes and restarts randomly once a week /s
Just once a week? They must be improving.
iphones just do weird shit after a while so that you can’t go on without a restart. truly smart
Oh. I had a habit of taking the battery out of that laggy shit, then turning it on again.
Update your spyware regularly
finaly the nsa doesn’t do something stupid
I’d love to see your list of “stupid” things… not immoral, vicious, incendiary, criminal, etc…but stupid. None of those things is stupid if they are also your fundamental mandate.
✨ Us government instance discovered ✨
You may have missed the joke
My iPhone 13 mini‘s battery is so small that I involuntarily restart it at least once every two weeks
iPhone batteries are small in general. My GF’s iPhone se (don’t ask me which gen) barely lasted half a day, and took hours to charge. So a couple of years ago I bought her a Z Flip 3 for her birthday because all the girls in the Korean shows she watches had that phone at the time. Now her battery actually lasts a full day, and the phone charges to full in 45 minutes.
The larger iPhones easily last a day. The SE (any gen) are fairly small and thin and don’t have very large batteries. The 12 and 13 mini are also very small and thus don’t have much battery life. If you have a regular sized iPhone or even a Max, battery life is fine, on the bigger ones good even.
I’m just going to assume that you’re right because I know nothing about Apple devices and their capabilities.
I use Tasker automation that reminds me to reboot after my phone has been up for awhile. I don’t think I’d like an auto reboot feature. I don’t even like it when I can’t postpone a software update until a time convenient for me.
I’m doubtful. I wanna hear more from security experts.
The bootloader of your phone (if locked) is one of the most secure parts. It’s very hard to get into a modern phones bootloader. In contrast, finding an exploit in a running phone is a lot more feasible.
If a vulnerability was abused to get into your running phone, it will persist until the phone reboots, and the bootloader verifies the core parts of the operating system at startup. In order to persist past a reboot, malware like that would need a vulnerability in the bootloader, or a bypass for its integrity checks.
Alongside that, any background services (“daemons”) that got stuck or became slow over time are forced to restart. Operating system updates can be applied, and working memory is cleared.
In general, it’s just good advice to just reboot your phone once in a while. There’s no harm in doing so.
“you do need to restart your phone regularly to rid it of demons”
typo: “daemons”, not “demons”.
Miners. Not minors! (Galaxy Quest)
Sounds kinda cyberpunk
GrapheneOS has an option to restart the phone after a given time without any successful unlock. I have it set to 8 hours, so it reboots every night. Shorter is possible.
A freshly restarted phone is in its safest state. Necessary to input the unlock code, strict minimum required processes running in the background.