I do the same as the person you're responding to. There is no '+' in my email, I just create random strings @mydomain. It's impossible for a scammer to know they all go to one inbox.
It may partially be because of vendor lock-in, but I think the real reason is security. For example with Apple's Secure Enclave hardware, you give secret-generation responsibility to this chip, and can never see the value. I use it for SSH private keys, which are meant to be disposable/changeable. As much as I want to own and control all my data, I personally think this is pretty good footgun protection, and I'm ok with being unable to export my passkeys from 1password (and for the record, 1password does not prohibit TOTP exports).
If the private key is actually stored in an unbeatable enclave, then fine. Apple’s implementation puts them in your iCloud account, which whilst it is overall locked via the Secure Enclave, the passkeys are most certainly not.
I don’t have a need for a level of security where exporting my private key to, say, Best Buy is impossible.
pip is so easy, but unfortunately i've found that if you add package signatures to requirements.txt, pip chokes on it when installing it later. And subdependencies aren't always named perfectly, e.g. they might specify ~=1.4, and a subdependency that what was once 1.4.0 is now 1.4.27, and incompatible or compromised.
conda is so heavyweight installing whole pre-approved builds. and the command line options I find extremely frustrating.
I need supply chain security and perfectly reproducible builds, so poetry was the only real option.
wouldn't `pip freeze > requirements.txt` solve your problem? It will list everything currently installed, including transitive dependencies at currently installed and working versions
I'm seeing all sorts of negative takes on this. But I read one interesting take on reddit from a father of 2 kids with DMD that had a very specific and logical reason for supporting it (other than the treatment helped his kid).
Essentially the efficacy test is a 3 point scale that measures standing and walking. It's not granular enough to get real statistical significance on, and never will be unless another kind of test is defined. So the tests are basically always doomed to fail rigid scrutiny by the FDA.
In the meantime they're getting dramatically effective results, and Peter Marks is bucking the FDA's traditionally conservative stance to make the product available to the few who desperately need it. I'll eat my words if someone finds he was paid off for this. I think is a truly miraculous kind of therapy, and I hope to one day have regularly available gene therapy for my own afflictions.
I think the point is that building any kind of tool to enable this is surface area for an attack. The design choice is to remove any possibility of that happening at all.
In this day and age, why does Thunderbird still ask for my password to store locally instead of using a standard OAuth flow? Every time I consider using Thunderbird, I just can't bring myself to enter a password. It feels like such an antiquated violation and gaping security hole.
I'm not sure what you mean, I just added a new Gmail account to test and it went through the normal OAuth flow. I didn't have to enter any password into Thunderbird itself, just the Gmail OAuth popup.
Thunderbird supports using TLS client certificates or Kerberos as alternatives to a password for IMAP access.
When you do choose to store a password locally, it's stored encrypted using a second password of your choice.
Since the end result of an OAuth login is a "token" (password...) stored on your machine, I think the difference is pretty marginal either way. But I do hear they're working on OAuth-for-IMAP support. If it were more standardized they probably would have implemented it sooner.
Some email providers support oauth. For some of those (Microsoft and Google), Thunderbird does support the oauth flow. However, how you connect oauth to email is not really standardised, so my understanding is even though "it's all oauth", these implementations are a lot more vendor specific than you'd expect.
Also the need for the email client to have a relationship with the oauth provider is probably a discouragement for some of the smaller email providers to move to oauth.
As far as I know there are only two email providers that support OAuth: Gmail and Microsoft. Each uses their own standard to do it, but both are fully supported in Thunderbird with no passwords stored locally.
This has never happened in the United States, and every expert out there says there is no sign of any kind of effort or legislation to do so. Involuntarily losing access to old cars is an imagined problem.
There's a gigantic difference. You stare at a handheld device when typing. When you're driving you need to feel what you're touching, otherwise you have to take your eyes off the road.
Yes it was a big, hairy investment for someone to submit a tiny change. But it was also the gigantic moat that kept bad actors away. I for one am thankful core python remains clean and safe because of this.
