It appears I have stepped right into controversy yet again. Usually I’m in hot water for saying: “security doesn’t have to be perfect--there are disregarded concessions,” but here I’m arguing the opposite.
@"Upstate1618"#p219994 This suggestion is completely wrong. Pixel phone does not use SSD.
https://en.wikipedia.org/wiki/Solid-state_drive#Ball_grid_array_form_factors
The SSD wiki has emmc & UFS in this section--the storage used in phones. Phones use NAND chips. Pixels certainly don't have spinning rust inside.
raccoondad 100%, this will actually lower your devices life, as the SSD can only be written into so many times.
I addressed that this technically leaves an unoticeable trace.
Here is a 5-year-old, middle-of-the-road SSD's datasheet:
https://download.semiconductor.samsung.com/resources/data-sheet/Samsung_NVMe_SSD_980_Data_Sheet_Rev.1.1.pdf
Warranty
MTBF = 1,500,000 hours
TBW = 600 x capacity
Let's be generous to your arguement and say businesses clamp warranty claims to: <10%. 90% of drives will exceed these writes and hours.
Let's give a generous 10 hours write time.
10h/1.5E6h = 0.0007% usage
1.3c/600c = 0.002% usage
Real-world usage is less than this as explained above.
Speaking of, my Pixel 6 is 4.5 years old and GOS says it has 92% SSD life remaining. We can extrapolate this to an estimated 56 year lifespan. If you'll excuse my boldness, I'd say I'm above avg in terms of writes.
raccoondad A factory reset deletes data irrevocably.
raccoondad A factory reset destroys every file irrevocably.
No. A factory reset deletes nothing save for the encryption key. I explained this all above.
Let's say that I create a secret language by moving the last letter in every word to the beginning of the word. I wrote how to decypher my writings. I am 5 years old and a bully steals my diary. I destroy the instructions. 15 year old Timmy will figure out how to read my secret encryption. The data exists.
This is SHA1's history and SHA256's future.
raccoondad This will lower device life expectancy and leave no meaningful security benfits, any potential ciphertext will most likely not even be oberwritten due to SSD firmware protections, the initial install is all that is required
I explained this already. wear-leveling is negated, over-provisioning is a factor.
raccoondad There is no 'replacing' data and 'marking' data for deletion.
You are right that you cannot write zeros over a specific file. Will my 100% drive utilization overwrite a lot of files?
raccoondad The initial suggestion on filling your SSD is not accurate and isn't a standardized method of securely erasing data in any capacity. Its never been
A review on data deletion strategies.
1) ATA secure erase / nvme sanitize
Broken in most NAND controllers that storage manufacturers purchase.
Even vendor-provided “secure erase” commands (e.g., ATA SECURITY ERASE UNIT) may not guarantee full physical sanitization: in 68% of tested NVMe drives (2023 NIST IR 8457 lab validation), residual data persisted
-https://lifetips.alibaba.com/tech-efficiency/secure-erase-methods-probably-wont-work-on-your-solid-s
68% failure rate is unsafe to trust alone. GOS doesn't use this to the best of my knowledge.
2) Delete the encryption key
The country that is hostile to OP can hold onto and clone the drive until SHA256 is broken.
3) Physically destroy the drive
98% of people will fail this objective. Drill a hole and snap it in half. Every NAND chip must be completely destroyed. This option is not available to OP, who requires a functional phone.
4) Overwrite the entire drive
Let's give a generous 10% over-provision. I completely fill the drive and thus--actually--destroy 91% of the data (1/1.1=0.91). I delete files, wear-leveling kicks in, and I fill it again.
raccoondad You are mistaking unencrypted HDD wiping concepts like DoD 5220.22-M
No, I am simply leveraging mathematical truths in our favor.
A U B >= A
(realistically, "=" shouldn't be there)
Layered security right? My approach will surely be safer than simply deleting a key and there’s little to sacrifice--no harm done.
raccoondad 100%, this will actually lower your devices life, as the SSD can only be written into so many times.
People who value longevity follow best practices by burning in a drive to check for failures immediately upon arrival, due to the bathtub curve of failures.
badblocks > smartctl -t long /dev/sdX || nvme device-self-test /dev/nvmeX -s 2
Upstate1618 Any other steps are recommended against.
I'd be interested in seeing a source for my recommendation being explicitly recommended against.
Upstate1618 What are you talking about? The suggestion is awfully wrong and makes no sense.
This sounds like I'll be appealing to hubris more than anything else.