I wonder what the equivalent data are for iPhone to Android switchers. It could also be similarly high, suggesting consumers are switching in higher numbers both ways?
If I could only pick one, it would be Dynalist [0]. I know it's essentially just another webapp (with mobile apps) for writing lists, but for some reason is the first one I actually found myself using, both at work and personally.
I primarily use it to keep work logs, write high-level system designs, remember dinner recipes - or generally anything valuable or useful that can be expressed in list form.
This isn't strictly true. I know in South London that Tesco orders are not "picked from local stores by hand" - they're packed in and dispatched from the same enormous warehouses and depots that supply the stores, and there's some degree of automation involved (although not to the same level of Ocado.)
That doesn't mean much half of the applications you install and run these days are just wrappers for web components where quite often the logic outside of the initialization is not in the app it self.
I use the standard hardware encryption of my SSD (a Samsung 830 in my 2012-era Dell XPS 13), which requires I enter the passphrase when I turn my machine on.
Advantages:
- OS neutral
- Seemingly as fast as running 'unencrypted'
(I assume performance is identical, the only
difference being the passphrase is stored in
my head rather than the BIOS)
Disadvantages:
- Limited to an 8-char (!) ASCII passphrase
- I've no idea how secure it really is
- Can't audit the algorithm (not that I have
the technical ability to)
Encryption is done in drive hardware, so copying the drive is possible via hardware attacks but would be a pretty involved lab operation. Would definitely take longer and require more sophistication than many in-practice crypto exploits.
a 256-bit AES key might take eternity, but if it's derived directly from 8-char ASCII the search space is tiny. Somewhat does depend on how it's actually implemented in hardware, however.
The 8 char password does not decrypt the key; it unlocks/retrieves it. The drive will only allow a fixed number of attempts. Once past the 10 or whatever allowed attempts, an attacker needs to brute force the full encryption key. It should be a very similar scheme to what you get with a modern smartphone, such as a new iPhone. (Not one of the older iphones the FBI cracked recently, a new one with a Secure Enclave.)
What stops the attacker from just imaging the drive in its encrypted state and continuing to run attacks on the 8 char password well in excess of 10 attempts?
The drive controller does not allow you to read the encrypted form of the data out. This kind of drive-encryption is the same as the common ATA lock command (implemented in your BIOS and the drive controller), but the drive controller actually encrypts the data as well as just refusing to work without being unlocked first.
This relates to my "does depend on how it's actually implemented in hardware, however." comment.
This can be implemented in secure hardware (and without getting into attacks against that), you can make a password attempt, but can't modify the counter which tracks how many incorrect attempts have been made. Sufficient incorrect attempts will see the key material destroyed.
It does actually encrypt your data, and if it's correctly implemented, it's fine. Those drives sell for a few years now and not a single exploit is known.
You're correct, it's not going to stop someone who knows exactly what they're doing and has the time/patience/tools to brute force. But it is enough to stop casual thieves from stealing more than just hardware, which is (fortunately) my main concern.
It reminds me of how I set a boot password in the BIOS on my HP laptop. I now have forgot the admin password in order to remove that "feature". I have no idea how I can fix it. The laptop is bricked. I can't install Linux on it because it is set not to boot from USB or CD/ROM
I had a Pentium III based HP laptop that stored the password on a chip that didn't require a battery to evade such a trick. The only fix was using the backdoor password that could be generated by using the serial number of the laptop (HP required proof of ownership, but I had dumpster dived this from their offices). The backdoor password was retrieved by wiring 50 USD to a fellow in the czech republic who had the keygen tool HP support would use.
Check HP for the service manual for your laptop. This is generally a standard goal the manual will give steps for. Usually all you need is a screwdriver of the right size and a bit of guts to pull apart bits of plastic, though I find my confidence that I'm not destroying anything is greatly enhanced when I'm following the manual and have reasonable confidence all the screws are out properly.
I had the same issue with a second hand HP laptop. However, I could still log in as administrator on the Windows install, enabling me to dump the flash memory used to store the BIOS firmware and configuration, which included the password hash. Some reverse engineering later, and I was able to brute force the hash successfully. So that could be an option if the password is not stored in battery-backed memory, and you have a bit of time on your hands to get stuck into the BIOS internals.
Why?! Surely this is the optimum time to provide source code, given the amount of trust one has to place in these things to not lose/misplace your data.
Especially when crypto is involved. Given the large number of completely broken cryptosystems, making this open source will give it a fighting chance to not be entirely broken.
Anything that handles critical data and sends it encrypted to third parties needs to be open source in this day and age or wont be used by people who take their data serious. Actually it doesn't even need to be sent to third parties to hit the open source requirement. Having crypto involved like you said is reason enough.
As long as 'free for personal use' means 'closed source' then at least I would have a hard time trusting a tool backing up personal files into public cloud storage without transparency about how the crypto is implemented. I suspect that may also be the case for much of your 'personal use' target audience.
A thought: Do you think people would pay collectively (given the chance) like a fundraiser to publish the source, when a certain limit is reached? Maybe even pay the developer's bills that way? I wonder..
