Other calculator apps that might have different privacy policies, and who might call home to Google and Facebook despite reporting "no data collected", and which might disappear from the app store because it costs $100/year to have the privilege of providing a free app (e.g. as happened with OpenCalc. https://github.com/breeko/OpenCalc/issues/3 )
I'm happy this isn't just me. Apple's calculator app is a showcase for some of their most obtuse UX decisions.
IO-blocking animations are everywhere on iOS, and sometimes they result in overlap (e.g. you can activate a widget and open an app if you press an app icon too fast after opening a folder). But having buttons on iOS animate in response to touch but not engage any further is mindblowing and infuriating.
It's also filled with obtuse interactions. (Did you know the iPhone's calculator app has extra buttons? You have to use the control center, unlock your screen rotation, and then rotate your phone to access it.) (Did you know you can erase digits by swiping left or right on them? You can't _access_ the hidden digits of precision this way.)
Telegram's E2EE isn't available for group chats. It's not on by default for other chats, so most or all of your chats are probably just transport encrypted. Further, they rolled their own crypto (bad), MTProto2, which has a number of problems (but is not necessarily broken)
This places Telegram's security stance below that of even Instagram or Facebook (which also has optional E2EE chats, but uses the Signal protocol, which is considered better than MTProto2.)
First, it's not either-or. You can match against zxcvbn strength and some passwordlist.
Second, think of the output of zxcvbn as a very weak hash with a low collision rate. E.g. 'correct-battery-horse-staple' maps to an estimated 213811968952000000000 guesses. In addition to being potentially algorithmically reversible, attackers can simply perform an offline attack against the value 213811968952000000000. So, this metric should never be exposed (e.g. in log files, on screen, etc.)
Third, having the estimated entropy helps a lot when password cracking. If you have the password hash digest and the zxcvbn metrics, then it makes the cracker's job much easier by reducing the search space. (Think, going from checking each molecule of an apple to checking only each molecule on the peel of an apple.)
Further, it's not perfect. The zxcvbn library I used suggests 'correct-battery-horse-staple' is a very strong password!
Yes, I'm very very familiar with this :) I stand by my assertion, "correct-horse-battery-staple" is a weak password to use today. Zxcvbn reporting it as secure is an example of where it's weak.
That XKCD comic came out August 2011, and this article was released April 2012, eight months later. At the time, it made sense to use that as an example of a "highly entropic password" in a blogpost targeting a general technical audience.
It has now been 156.5 months since that comic was released, and 164.5 since zxcvbn was originally trained on its 2011 dataset. "Correct-horse-battery-staple" and its variations are widely used strings and is no longer an example of a strong password.
It's worth being careful about our definition of entropy. The same highly-entropic source generates "hunter2" just as often as it generates "aaaaaaa" just as often as it generates "jpnj6i3".
A "good password" is one that is unlikely to be guessed by an offline cracker. But there are countless strategies an attacker might choose, most of which involve taking a list of passwords and applying rules to them. This is why a highly-entropic source is important (e.g. of all the 32-character passwords, 'weak' ones like "aaaaa..." make a negligible percentage of them) as well as uniqueness ("mP7t6e8TAH..." is a weak password the moment it's leaked in a breach.)
You can't know what strategy the attacker will pick beforehand-- the idea is that it's negligibly likely that an attacker chooses a strategy that cracks your password in a few guesses.
Zxcvbn intentionally takes compromises to be a performant best-effort estimation of how many guesses an attacker would take for your password. (It would improve its estimation of guesses by actually trying to guess your password with `hashcat` and the antipublic combolist, or whatever people are using nowadays, but then it would take eons to provide an estimation rather than milliseconds.)
I've had a very bad experience with Liberty Mutual following a data opt-out from another service. They sent me on a runaround, ending with an email saying to follow "this link" to verify myself. (There was no link, only sketch.) I ended up getting a human on a phone through special means, and they sent me a fixed email with a working link.
I should be hearing back from them in the next 32 days, as this was 13 days ago.
I got a quote from them and immediately initiated a data removal request. It seems like it went through, got a link in the email. Thanks for the reminder that I might need to follow up to make sure they followed through.
BitTorrent uses something called a "distributed hash table", for which there exist services to search it (btdig, etc). You can use one of those alongside the torrent name (NPD) to find it.
I haven't downloaded it, but my understanding is that the data comes compressed and with a (weak) password.
Speaking as a Calyx user since 2020, the install experience was a bit finnicky, and it required no ongoing manual maintenance. My understanding is the web installer is pretty easy now though.
One caveat: Unlocking the bootloader deletes the disk. This is a reasonable security measure, but it means you don't want to use the phone for anything important before installing Graphene.
reply