581–590 of 796 posts
Wow, I also received the same phishing email even though my packages only have a few hundred downloads a week (eg. bsky-embed). So I guess a lot more accounts/packages might be affected than the ones stated in the article
Did you receive the email in a similar time window? I'm trying to think of ways to scan other repositories for signs of compromise.
Earlier quoted context omitted.
> This isn’t exactly true. My password manager fails to recognise the domain I’m on, all the time. I have to go search for it and then copy/paste it in. I'd probably go looking for a new password manager if it fails to do one of the basic features they exist for, copy-pasting passwords defeats a lot of the purpose :) > That being said, if you’re making login pages I think we're doomed on this front already. My previo…
> I'd probably go looking for a new password manager if it fails to do one of the basic features they exist for, copy-pasting passwords defeats a lot of the purpose :) This isn’t the fault of the password managers themselves, but devs not putting the right metadata on their login forms, or havo the password field show only after putting in the email address, causing the password input to fail to be filled, etc.
Earlier quoted context omitted.
> I'd probably go looking for a new password manager if it fails to do one of the basic features they exist for, copy-pasting passwords defeats a lot of the purpose :) This isn’t the fault of the password managers themselves, but devs not putting the right metadata on their login forms, or havo the password field show only after putting in the email address, causing the password input to fail to be filled, etc.
or switching to some generic-sounding domain during login
Earlier quoted context omitted.
I mostly agree and I do use one. You only need read the whole thread however to see reasons why this would sometimes not be enough: sometimes the password manager does not auto-fill, so the user can think it's one of those cases, or they're on mobile and they don't have the extension there, or... As a matter of fact, he does use one, that didn't save him, see: https://news.ycombinator.com/item?id=45175125
> sometimes the password manager does not auto-fill So pick one that does? That's like its top 2 feature > he does use one He doesn't since he has no autofill installed, so loses the key security+ convenience benefit of automatch
Earlier quoted context omitted.
Consider adding the widget/action to your quick actions: then to don't need to copy paste at least
For those of us unfamiliar, can you describe the resulting UI pattern? Do you give focus to the password field and then tap a button at the top of the notification shade which automatically types (or gives a choice, if multiple are saved) whatever the password manager has for that site? I'm slightly surprised that something running in that context would know what site the browser has open.
Earlier quoted context omitted.
> sometimes the password manager does not auto-fill So pick one that does? That's like its top 2 feature > he does use one He doesn't since he has no autofill installed, so loses the key security+ convenience benefit of automatch
Mobile autofill requires you to make other security compromises.
Earlier quoted context omitted.
> So pick one that does? That's like its top 2 feature Still doesn’t work 100% of the time, because half of the companies on earth demote their developer time to breaking 1995-level forms. That’s why every popular password manager has a way to fill passwords for other domains, why people learn to use that feature, and why phishers have learned to convince people to use that feature. WebAuthn prevents phishing. Passwo…
Then good password managers will still show you only the logins for that domain. If the login is on another domain then you would have saved it anyways when first logging in/registering and if the site moved then you can get suspicious and check carefully first.
Earlier quoted context omitted.
Things like this are good illustrations as to why many feel that the entire JS ecosystem is broken. Even if you have a standard lib included in a language, you wouldn't expect a bigger binary because of the standard lib. The JS solution is often more duct tape on top of a bad design. In this case tree shaking, which may or may not work as intended.
I agree with you, but I'd ask- what other language needs to distribute to an unknown runtime environment over the network? If it's the browser's job to implement the standard library, how do you ensure that all browsers do this in a compliant and timely fashion? And if not, how do you optimise code-on-demand delivery over the internet? I don't deny there are/could be solutions to this. But historically JS devs have w…
Alternatively, because there are now (often ridiculous) build systems and compilation steps, we might expect similar behavior to other compiled binaries. Instead we get the worst of both worlds.
Yes, JS as it is is some kind of standard, but at a certain point we might ask, "Why not throw out the bad designs and start from scratch?" If it takes ten years to sunset the garbage and offer a compatibility shim, that's fine. All the more reason to start now.
A purely compiled WASM approach with first class DOM access or a clean scripting language with a versioned standard lib, either option would be better than the status quo.
Earlier quoted context omitted.
> The problem is email as it’s used currently. The solution is to not use email. No. The problem is unsigned package repositories. The solution is to tie a package to an identity using a certificate. Quickest way I can think off would be requiring packages to be linked to a domain so that the repository can always check incoming changes to packages using the incoming signature against the domain certificate.
And one pwned domain later, we are back in square one.
1. It's an extra step: before you pwn the package, you need to pwn a domain.
2. When a domain is pwned, the packages it signs can be revoked with a single command.