Related
Even if one has installed some kind of lockdown/tracking software + lock pattern there is always the possibility that a thief would know how to reflash and/or wipe the phone or be able to use Google to find out how.
Has anyone worked on adding the possibility of locking access to fastboot, recovery and OS boot? (Password protecting adb would also be a nice addition.)
There is not much these forums about it. Here is a thread that died: http://forum.xda-developers.com/showthread.php?t=531225
I would be fine with compiling my own recovery image if that is what it takes to get my own password, but I guess fastboot is the biggest concern.
I hope some smart developers will take their time to read this and think about it. Let's hear some input on how big of a task this is. I am sure it can be done, so take the challenge and show us some love.
wow this is an awesome idea. ya because apps like mobiledefense or wavesecure would be useless if the thief knows how to wipe the phone. this would be great and i would love to see it work. i dont know crap about making my own recovery or else i would do it if thats what it means to make my own password protected recovery. but like u said, fastboot is a greater challenge.
I could see recovery maybe having this but the bootloader you are out of luck unless you have a dev or holiday version of the nexus. We currently cant flash custom SPL's because they are sig checked.
What happens when you forget your password? Brick?
MatMew said:
What happens when you forget your password? Brick?
Click to expand...
Click to collapse
Damn if you forget it than you are just too stupid, lol Jk
but good question, however i don't think any development on this will be done anytime soon, id definitely support it though if it ever starts.
Locking the SPL would require us to be able to write/flash one, which is currently impossible
Maybe a petition to google to set forth this new option then?
Because I was thinking the same thing...our laptops can do it, because duh, if someone steals your lappy they could just wipe to get the hardware so we can put a BIOS password so even thats impossible.
Our so 'open' phones should follow suit...please google, read this. It would be a fantastic option, that way its rendered completely useless to anyone that steals it and is smart with them (aka anyone reading these forums ).
THANKS
I want it
I've been thinking of how to 'secure' my phone's data again since I unlocked the bootloader... but this would be the way.
The feature request goes like this: Password protect the bootloader both for fastboot and getting into recovery (the option to start recovery should be password protected). A wipe is required in order to reset the password.
An additional and optional theft lock (along the lines of what the OP wants) would disable the password reset/wipe feature altogether, essentially bricking the phone if the password is unknown. Not exactly what I want (I just want my data to be safe), but should be easy enough to add both options if we have the code and can flash the SPL.
Obviously this is going nowhere if we can't flash the SPL, but there's no harm in putting this out there for Google to include in the next signed SPL.
Everyone should realize that unlocking the bootloader essentially puts all the data on your phone out there for anyone to grab without a password, given that they know a few things about fastboot/recovery. This is likely why Google forces a wipe when you originally unlock. We 'unlockers' should be given a way to get that security back.
We'd also need to find a way to 'type' a password (for the recovery option) while in the bootloader, since there's no keyboard. You could use the volume toggle to cycle through letters or numbers, but this puts this option far past a 'trivial' change to the SPL code. This may be why Google didn't include the option in the beginning.
theslam08 said:
Maybe a petition to google to set forth this new option then?
Because I was thinking the same thing...our laptops can do it, because duh, if someone steals your lappy they could just wipe to get the hardware so we can put a BIOS password so even thats impossible.
Our so 'open' phones should follow suit...please google, read this. It would be a fantastic option, that way its rendered completely useless to anyone that steals it and is smart with them (aka anyone reading these forums ).
THANKS
Click to expand...
Click to collapse
A computer bios password only keeps people from changing bios settings. They can still format the hard drive.
bubbahump said:
I've been thinking of how to 'secure' my phone's data again since I unlocked the bootloader... but this would be the way.
The feature request goes like this: Password protect the bootloader both for fastboot and getting into recovery (the option to start recovery should be password protected). A wipe is required in order to reset the password.
An additional and optional theft lock (along the lines of what the OP wants) would disable the password reset/wipe feature altogether, essentially bricking the phone if the password is unknown. Not exactly what I want (I just want my data to be safe), but should be easy enough to add both options if we have the code and can flash the SPL.
Obviously this is going nowhere if we can't flash the SPL, but there's no harm in putting this out there for Google to include in the next signed SPL.
Everyone should realize that unlocking the bootloader essentially puts all the data on your phone out there for anyone to grab without a password, given that they know a few things about fastboot/recovery. This is likely why Google forces a wipe when you originally unlock. We 'unlockers' should be given a way to get that security back.
Click to expand...
Click to collapse
This would be really great... an idea, if ever possible, to overcome the bricking phone by password being lost, is somehow emailing it to the registered google account... or maybe sending an sms to a known phone number that was registered before...
dalingrin said:
A computer bios password only keeps people from changing bios settings. They can still format the hard drive.
Click to expand...
Click to collapse
Actually you can set an ON-BOOT password, which will prevent it from being booted at all without the password. Unfortunately, it is not that great a security measure, since you can just reset the BIOS using the jumper on the motherboard. Also, every BIOS manufacturer leaves a backdoor in case of forgotten passwords, just do a Google search for BIOS DEFAULT PASSWORDS.
But, the main thing to remember here is that we do not have a keyboard, and very limited buttons to use. So, what are you thinking of using? A combination of buttons (similar to the quick-reboot)? Or, cycling through with the volume/trackball, kind of like on a briefcase/suitcase (argh, imagine the frustration).
The next thing would be the implementation of such an idea.
If the SPL is to be modified to be password protected, we would need to source code - which I don't think is available.
If the recovery is to be password protected, it would need to have immediate access to a rewriteable portion of the internal memory for storage/retrieval of said password (as would the SPL, but first things first - gotta have the source).
A simple qwerty on-screen keyboard and using the trackball to select characters would work fine. Up and down with volume keys or whatever to type in characters is not a viable option for long passwords.
It seems all this would be of no use without the possibility of flashing our own SPL, so I guess this is a bigger task than I thought at first. We all know SPL's have been hacked many times before, so I believe it can be done on the Nexus One too. But, because of the already unlocked SPL opening up flashing heaven, I am not so sure anyone is going to use any time on figuring it out.
This is what we are left with:
1. Find a way to flash a custom SPL. Piece of cake right?
2. Create an SPL with the possibility of adding password protected fastboot/recovery. Protecting boot will probably not be necessary, as it would make it impossible to trace a stolen phone.
Let me comment on the privacy issue: I am not really very concerned about the data on my phone. Of course I would not want all the pictures and videos I have shot to fall into the hands of complete strangers, but I try not to keep secret/sensitive data on my phone. It is not really very difficult to take the sdcard and put it in any other device or card reader to get all the data off of it. All the password protection in the world will never get us around some physical security. (Maybe I should make another request for encrypting the sdcard?)
What I want is to be able to somehow find the bastard(s) that took my mobile and get it back without it being wiped first. Though there is always the risk that they would not get past the unlock pattern and just throw it away right away. Let's just hope they left it powered on within network coverage.
How does Android store Gmail login credentials? Are the information cookie-like (only session information) or is there an actuall password (encrypted or not, doesn't matter) stored somewhere? If the latter than that would be very bad for the security of the Gmail account (most critical apps there are Mail and Checkout). It would probably be a good idea to change the Gmail password as soon as one starts missing his Android phone.
--
One way of increasing the odds to get a stolen phone back would be to flash a custom ROM with an embeded and preconfigured security application that installs automatically and silently after a wipe. Not perfect because a thief could just flash another ROM but there's a greater chance of a device getting wiped than not getting wiped, right?
I guess a password in recovery would add an extra percentage to those odds too.
So much for this request. Someone moved us to Q&A, so I guess this is doomed for now. We'll just have to keep our phone safe.
maedox said:
So much for this request. Someone moved us to Q&A, so I guess this is doomed for now. We'll just have to keep our phone safe.
Click to expand...
Click to collapse
Sorry for the bump. But seriously this is a must.
Any Nexus with unlocked bootloader leaves the internal memory unprotected (All your photos in DCIM folder, etc).
You just need to enter fastboot and flash a custom recovery.
Hello
Well i have a phone that has exactly what was being mentioned in this thread and i have literally tried everything everyone is saying about flashing, etc.
Up until recently, the corporation I work for only authorized blackberry devices to sync with the exchange servers. They've just recently started allowing iPhones and certain android devices to do the same.
On the corp intranet page that deals with this it explains that once you setup activesync a phone lock passcode is required, screen timeout of less than 15min is required, and 5 incorrect passcode attempts, lost/stolen, or something like leaving the company will result in a wipe that will affect non work related data loss as well. The next sentence then says that if it can't be wiped remotely it is the employee's responsibility to do so.
I don't know if some of that wording is from the blackberry only days or what.
If I were to go ahead and get authorization for this, would setting up an activesync with the corporation exchange server really allow them to wipe my phone, including personal data? Would it really make my phone require a passcode and limit my screen timeout all by just syncing?
I just don't know what kind of control simply setting up an activesync account is really possible.
I hate using our web access bc it requires and id and 2 passwords and even though I can use lastpass to make that easier its still slow/inconvenient.
I don't want to ask IT about all this bc I don't want them to think I'm trying to get around the system or give me an incorrect answer (fortune 100 company, they deal with a lot and don't know everything about everything ).
One of the features introduced in Froyo with Exchange/ActiveSync support was remote wipe. I believe they'll have no problem wiping your phone, unless you disconnect that account first.
Jack_R1 said:
One of the features introduced in Froyo with Exchange/ActiveSync support was remote wipe. I believe they'll have no problem wiping your phone, unless you disconnect that account first.
Click to expand...
Click to collapse
I'm actually less concerned with wiping than I am with being forced (by that I mean them somehow enforcing my settings such that I can't make my screen timeout longer than 15min or have to use a passcode to come out of sleep). I've never lost a phone and am willing to deal with consequences of not having a damn unlock code. I just don't want my phone to be locked into particular settings. Hope that makes sense.
I ask because after installing stock MRA58R the contents of my N6 were still visible in Windows Explorer. So I reformatted userdata & cache, and then used the new NRT 2.0.7 to flash MRA58R again - wipe, no root, no recovery, no no-encrypt, just bog-standard install. The "Encrypting device" appeared for literally a few seconds, and now as it's sitting re-installing my apps from Google I can still see the contents of internal memory in Explorer. No USB debug, just a "Use USB for file transfer".
I have a multi-digit PIN on the phone, set up as part of the initialisation process.
I went through all this because my wife's phone was stolen last weekend and it was a wake-up call for me about my data security.
I'm sure I'm being particularly stupid. Can someone please educate me?
Thanks...
And maybe I'm answering my own question...
The contents are visible to me because I entered the device PIN?
Anyone without the PIN gets to see nothing?
And that includes any access via ADB/fastboot?
But is this any different from a non-encrypted device?
dahawthorne said:
Anyone without the PIN gets to see nothing?
Click to expand...
Click to collapse
It is a method to store data that is only readable with the key used for encryption.
Your pin is something different and is used for access permission of a device.
Thanks, but my understanding is that the device PIN is the encryption key. You can't set encryption without having a device PIN. What else could it possibly be using?
So I guess I still don't understand if having my device encrypted is any better than having a simple PIN-secured unencrypted device. If someone can see my data via bootloader mode or some other back door how secure is it?
If I look at an encrypted file I expect to see hieroglyphics. That's not what I'm seeing here. I see either nothing at all because the device isn't recognised by my PC, or I have full access to the data.
So what effect should I expect to see that is different/more secure than a simple PIN-protected device? What's the actual benefit of encryption?
dahawthorne said:
Thanks, but my understanding is that the device PIN is the encryption key. You can't set encryption without having a device PIN. What else could it possibly be using?
So I guess I still don't understand if having my device encrypted is any better than having a simple PIN-secured unencrypted device. If someone can see my data via bootloader mode or some other back door how secure is it?
If I look at an encrypted file I expect to see hieroglyphics. That's not what I'm seeing here. I see either nothing at all because the device isn't recognised by my PC, or I have full access to the data.
So what effect should I expect to see that is different/more secure than a simple PIN-protected device? What's the actual benefit of encryption?
Click to expand...
Click to collapse
Ill be honest. Your device is only as secure as the person that steals it. No amount of security has been 100% proven to prevent the data being attainable if they have access to the device its self. While I am not saying the average thieve will be bale to do it but, then all they care about is the device and end up wiping the device and reselling it without a care about the info inside it.
dahawthorne said:
Thanks, but my understanding is that the device PIN is the encryption key.
Click to expand...
Click to collapse
That wouldn't be a good encryption, you usually need at least 256 bits to encrypt a volume. The pin is only to unlock the encryption key that's stored on a separate partition. Also to unlock the phone.
If you stick a USB cable into a phone that's on, it switches to USB charging mode by default, so you need to unlock it to change it to MTP or Camera. If you want to connect as USB debugging, you first must allow the new computer's fingerprint to connect, so you need the pin to unlock the phone again.
If encryption is used correctly, then you must enter your pin to resume boot. But you can just set MTP as default connection in a custom ROM, build it as userdebug that doesn't require ADB fingerprint, and set pin for unlocking lock screen only
Thanks, people. It looks like encryption is pretty well pointless then if any Tom, **** or Harry can just install a new ROM or recovery and get access to the data... Burning my battery for nothing but a lot of security hot air...?
Speaking of which, I've just rebooted my phone and despite having checked the "Require passcode to start Android", which actually did work at least once (meaning I had to enter a PIN 3 times, for Android, SIM and device), this time there was no Android challenge, only SIM & device.
This security really isn't up to the job at all.
That is incorrect. With out knowing the key, as long as you select require pon at boot, the only thing they could do is reformat your phone and continue using it. No matter what, the key to your data is needed to access it.
dahawthorne said:
Thanks, people. It looks like encryption is pretty well pointless then if any Tom, **** or Harry can just install a new ROM or recovery and get access to the data... Burning my battery for nothing but a lot of security hot air...?
Click to expand...
Click to collapse
I really don't get where this comes from?!? It's a very serious security measure, and it's really not its fault if people dynamite holes into the phone's security like using userdebug builds, and having custom recoveries.
The point is, you have to decide if you want a phone open for modding and to use to store sensitive data on it. There isn't a system that really can accommodate both.
But if you don't have any sensitive data on your phone then encrypting is really pointless.
Thanks again, guys.
@scryan - "select require pin at boot" - does this mean the "require PIN before starting Android"? This is what I mentioned I had but now I don't. An extra layer of security disappeared for no reason I can think of, and I see no option to switch it back on, since the only time it was offered to me was during the initial setup. I still have SIM lock and device lock, but more is better, no?
@istperson - I get the trade-off between security and flexibility. I would consider my photos, for example, to be secure data - even if I'm happy showing them to people I know, I don't want strangers poking around in them.
So bottom line - I still see no argument that says that encryption provides something that the PIN doesn't. How exactly is a PIN-protected encrypted phone more secure than a PIN-protected unencrypted phone?
Edit: I found the "require PIN on boot" option in one of the security tabs, and it appears to work. Back to 3 levels of security, but still in the dark about encryption benefits.
dahawthorne said:
So bottom line - I still see no argument that says that encryption provides something that the PIN doesn't. How exactly is a PIN-protected encrypted phone more secure than a PIN-protected unencrypted phone?
Click to expand...
Click to collapse
If they hit you on the head, take your phone, tear it apart, and remove the sdcard, it won't be readable because of the encryption. If it's unencrypted they can access every data.
But don't store naked selfies on you phone. or in the cloud, then you're safe.
Also the pin to boot doesn't go away by itself without tinkering. Go back to Settings/Security and switch on the Require pin to boot, or whatever it's called.
Basically encryption is how the data is stored on the device. Instead of the normal readable format, its scattered all around in a pattern that requires a key to calculate how to put it all back together.
When you computer goes to read a file, it pulls out a chunk of data, looks at what the right pattern is, then ignores the pieces it doesn't need.
When you phone is running you dont see any of this, because your phone is always in the middle decoding.
If I tried to access your data by circumventing the OS and its checks, all I would see was scrambled randomness.
Decent little wiki entry from arch linux
https://wiki.archlinux.org/index.php/Disk_encryption#How_the_encryption_works
Its more aimed at computers, but its the same thing...
"it won't be readable because of the encryption."
That I understand - thanks. I suppose I was just a bit uneasy because it seems a bit too simple to get in, but obviously tinkering with my own device is far simpler than tinkering with someone else's.
I'll put this one to bed now. I'm very grateful for everyone's patience in answering my questions.
So I just updated to B360 last Thursday, and so far no major issues.
However one which is particularly annoying, is that of Device Policy. One of my Google Apps accounts I need for work enforces device policy, and it keeps prompting me that it requires that the device be encrypted, and require a PIN on restart.
However, the device is encrypted (or if it's not, Device Policy didn't seem to care before), and it does ask for the PIN on restart. I removed the account entirely and uninstalled device policy, then readded both, to no avail. Device policy still complains about both of them and refuses to let the account sync.
Has anyone else experienced this issue, or have any does anyone have any suggestions? I could wipe the device and try that, but I don't want to go to all that effort unless I know it'll fix it.
Hi there,
After the advice of John on this thread
https://groups.google.com/a/googlep...forums.com?utm_medium=email&utm_source=footer
I finally got passed the boot loop after another attempt. I am travelling in China and this country is so beautiful that I could not stand living without a camera. So I simply tried again and it worked. (I have a software VPN that helps to reach the Google servers).
So I have setup a hosted network on my Windows 10 device with the VPN on it and went ahead with the install.
It went all fine (a bit longer as the packets have to transit via San Fransico hardware VPN hosted by VPN Express) however once I'm on the "Verifying your account" page, I enter my email and it grays out in the wait of completion but it rolls and rolls, it never ends.
I have searched on Google search engine about documentation to fix that quick and I ended in an ocean of people running around like headless chickens, sake oil dealers etc etc. So what's all these hurdles about this FPR thing???
I am scared.
I am in china and my phone helps me to get around.
It's now a useless paper weight.
What if I end up in a trap because I asked some people for my way and I get hurt? Am I allowed to blame the new fancy "security" policies?
PLEASE HELP ME FAST - I NEED URGENT ASSISTANCE - I will be refreshing my email every 30mns from now.
vonz33 said:
Hi there,
After the advice of John on this thread
https://groups.google.com/a/googlep...forums.com?utm_medium=email&utm_source=footer
I finally got passed the boot loop after another attempt. I am travelling in China and this country is so beautiful that I could not stand living without a camera. So I simply tried again and it worked. (I have a software VPN that helps to reach the Google servers).
So I have setup a hosted network on my Windows 10 device with the VPN on it and went ahead with the install.
It went all fine (a bit longer as the packets have to transit via San Fransico hardware VPN hosted by VPN Express) however once I'm on the "Verifying your account" page, I enter my email and it grays out in the wait of completion but it rolls and rolls, it never ends.
I have searched on Google search engine about documentation to fix that quick and I ended in an ocean of people running around like headless chickens, sake oil dealers etc etc. So what's all these hurdles about this FPR thing???
I am scared.
I am in china and my phone helps me to get around.
It's now a useless paper weight.
What if I end up in a trap because I asked some people for my way and I get hurt? Am I allowed to blame the new fancy "security" policies?
PLEASE HELP ME FAST - I NEED URGENT ASSISTANCE - I will be refreshing my email every 30mns from now.
Click to expand...
Click to collapse
There are a few options you can take (if you have an unlocked bootloader). The quickest would be to simply delete the SetupWizard apk from TWRP.
Another option is to download and flash a ROM without Google Apps (make sure to download the camera apk of your choice- whether it be Snap or Google Camera).
Finally, you could try another VPN service (or server).
Go to a country that allows Google services to be used, or simply be patient as the VPN is apparently the problem. Your last two questions are likely rhetorical, but if you end up in a trap and get hurt it's your fault, not Google's. So no, you can't blame them for their Factory Reset Protection.
The "issue" with FRP is a simple one. It requires knowing the last Google account used and its password. This affects two different groups of people: those with "burner" accounts, and resellers.
In the case of the burner accounts people create a Google account with a password and don't bother to remember it because they don't want to give any information to Google. Then when they have to reset their devices for whatever reason FRP kicks in and they're screwed. Since they don't know the Google account or password they can't get back into the device.
The resellers purchase used devices and try to move them. However the person selling the device often does not clear out the account information from the device or does not remove the device from their account. When the device is sold the new owner attempts to enter their information and gets tripped up by FRP as they don't have the last Google account and its password.
"Burner" accounts are a pathway to disaster. Resellers are a bit more careful, and instances of FRP on a used device from a reseller have gone down.
negusp said:
There are a few options you can take (if you have an unlocked bootloader). The quickest would be to simply delete the SetupWizard apk from TWRP.
Another option is to download and flash a ROM without Google Apps (make sure to download the camera apk of your choice- whether it be Snap or Google Camera).
Finally, you could try another VPN service (or server).
Click to expand...
Click to collapse
Thanks for these options!
Yes, good old TWRP... Good option however since the phone is not rooted it would require a way to root it via fastboot flash, and also a way to push TWRP the same way.
I would perhaps rather downgrade to 6.0 or even 5.0 to see if I get lucky.
I could also buy a new phone here but the pricings are rather prohibitive and the models they have would be of no use outside of China.
I have tried mucking around with other VPNs today, it allowed me to go one or 2 steps further but the procedure finally s+++t itself in the end.
I should be in Vietnam tomorrow so hopefully the local telecom towers will allow me to finish my install....
I have no idea how i'm going to tell the taxi driver that I need to go to the train station without a portable system like an android phone, time is a bit short to chase down a paper dictionary.
If you still have some more leads on your TWRP methods that would solve this, please post ahead. I have no guarantees that Vietnam will solve this at this point in time.
Cheers mate.
Strephon Alkhalikoi said:
Go to a country that allows Google services to be used, or simply be patient as the VPN is apparently the problem. Your last two questions are likely rhetorical, but if you end up in a trap and get hurt it's your fault, not Google's. So no, you can't blame them for their Factory Reset Protection.
The "issue" with FRP is a simple one. It requires knowing the last Google account used and its password. This affects two different groups of people: those with "burner" accounts, and resellers.
In the case of the burner accounts people create a Google account with a password and don't bother to remember it because they don't want to give any information to Google. Then when they have to reset their devices for whatever reason FRP kicks in and they're screwed. Since they don't know the Google account or password they can't get back into the device.
The resellers purchase used devices and try to move them. However the person selling the device often does not clear out the account information from the device or does not remove the device from their account. When the device is sold the new owner attempts to enter their information and gets tripped up by FRP as they don't have the last Google account and its password.
"Burner" accounts are a pathway to disaster. Resellers are a bit more careful, and instances of FRP on a used device from a reseller have gone down.
Click to expand...
Click to collapse
Not Google's fault? Lets unpack this one... I am a council fixing up a foot path. The engineers have let a slight gap in the concrete due to a fabrication method process. If you trip and hurt yourself it's your fault yeah?
Secondo, it's not Google's job to make my phone safe from thieves, it's mine. Why in hell would they make my life complicated because some idiots spends $2000 on a phone a forget it in a taxi, I don't want to have to do all these things, I just want my phone to be able to be serviced easily. and especially if i'm in a critical area, my safety is more important than these people's concerns about thieves. An the cherry on the pie is that today with the cloud sync technology, who cares in the first place.
""Burner" accounts are a pathway to disaster." Mate, look up the word disaster's definition from the dictionary and see if it applied to a chum that has got his phone stolen and get back to me with that.
Kind regards
I normally don't dissect posts but...
vonz33 said:
]Not Google's fault? Lets unpack this one... I am a council fixing up a foot path. The engineers have let a slight gap in the concrete due to a fabrication method process. If you trip and hurt yourself it's your fault yeah?
Click to expand...
Click to collapse
It's not Google's fault as you have alternative options you could take. For instance, a dedicated GPS receiver from Garmin or Tom Tom. I keep both a Garmin GPS and a street atlas in my car as a backup to my N6 and I live stateside. Should I encounter an issue, I have a means to get where I need to go. It's called "being prepared".
Your argument is a strawman argument, because Google's Android software is working as intended. Your argument might have more weight if there was a bug in the software that prevented you from using it. FRP is not a bug.
Secondo, it's not Google's job to make my phone safe from thieves, it's mine. Why in hell would they make my life complicated because some idiots spends $2000 on a phone a forget it in a taxi, I don't want to have to do all these things, I just want my phone to be able to be serviced easily. and especially if i'm in a critical area, my safety is more important than these people's concerns about thieves. An the cherry on the pie is that today with the cloud sync technology, who cares in the first place.
Click to expand...
Click to collapse
Bit of a strawman here as well, as the issue isn't the person accidentally leaving his device in a taxi, but the person who gets their device stolen. Add to that the hyperbole of a $2,000 phone and you have a funny comment.
This is Google complying with California's kill switch law that went into effect two years ago. Since people travel in and out of California all the time and it's nearly impossible to target devices with "California-only" firmware Google implemented FRP worldwide. The entire idea of FRP is to make the phone impossible to use if it is stolen.
""Burner" accounts are a pathway to disaster." Mate, look up the word disaster's definition from the dictionary and see if it applied to a chum that has got his phone stolen and get back to me with that.
Kind regards.
Click to expand...
Click to collapse
The situation you describe is exactly why FRP was implemented on devices. Burner accounts will lead to disaster because it is inevitable that the owner will have to reset his device for whatever reason. When he does, he's screwed. I will clarify one thing here: when I refer to a "Burner" account I refer to an account with a random string of letters and numbers used for both email address and password with the express purpose of preventing Google from tying data collected from the device to the owner of that device. Ideally, if you really want to use a throwaway account, you at least make up an email address and password that are both easy to remember.
For the record, here's the definition of "disaster". Definition 3 applies to this conversation.
dis·as·ter (dəˈzastər)
noun
1. a sudden event, such as an accident or a natural catastrophe, that causes great damage or loss of life. "159 people died in the disaster"
synonyms: catastrophe, calamity, cataclysm, tragedy, act of God, holocaust; accident. "a subway disaster"
2. denoting a genre of films that use natural or accidental catastrophe as the mainspring of plot and setting.
modifier noun: disaster. "a disaster movie"
3. an event or fact that has unfortunate consequences. "a string of personal disasters"
synonyms: misfortune, mishap, misadventure, mischance, setback, reversal, stroke of bad luck, blow. "a string of personal disasters"
P.S. When quoting something written in quotes, double quotes are replaced with single quotes. Thus, in quoting me you want to say, "'Burner' accounts are a pathway to disaster."