How is the age of a package calculated? If the publishing date of a package is obtained from the package's metadata defined by the package author, (just like Git commit dates are defined by the Git committer), then that would defeat the purpose of this new feature. The whole purpose of this feature is to protect from malicious or compromised package authors. Instead, it is necessary to query the package registry, trusting the package registry for the age of the package, rather than the package author. I presume this is how it works.
Basically we severed connection to the public npm registry completely earlier in the week whilst this worm plays out.
Unfortunately there wasn't a way to do this without taking our cached "good" public packages down as well, so we later replicated the good cached packages into a new standalone private registry to be the new upstream.
The bit that was not obvious in the moment but self evident once we realised is that the registry we're using took the copy time as the publish time, and therefore our new 2 week delay is rejecting the copied packages...
So sample size of one, but the registry we're using is definitely using upload time not any metadata in the packages themselves. Good to know the filtering is working.
I can understand it. Ordinary users were getting locked out of their accounts when losing their phones. Some of those stories hit HN.
Don't disable cloud sync unless you have a backup of all your TPTP secret keys. It's dangerous to advise people to disable cloud sync without mentioning backups. Being locked out of thousands of dollars in your crypto account is as damaging as losing that crypto to hackers.
In that case wouldn't you be better off just disabling 2FA? The problem with the cloud sync is that users like the one in the article think they have 2FA but in fact if their Google account is compromised all their accounts using Google Authenticator TOTP second factors are also compromised.
TOTP isn't that great, you should definitely use a hardware and/or pass key for important and financial services. That said your cloud synced Google Authenticator can be behind a Google account with strong 2FA (i.e. not SMS nor TOTP), then it's mostly fine.
The lesson here is really not to ever share codes you receive by SMS, and preferably disable phone as recovery and second factor.
I agree. I wonder if there is a good compromise between convenience and security, though. For example, before allowing Google Authenticator to sync for the first time on a new device, maybe notify the user on all devices and enforce a 72-hour delay, or wait until the user approves the new device using an old device (in a way that is hard for a scammer to pass off as legitimate).
I've received a phishing email from an @paypal.com email address. (The From: header showed an @paypal.com email address.) Fortunately, the text of the email itself was fishy enough to make me realise it wasn't legitimate. I have no idea how it passed spam filters. I reported the email to both PayPal and my email provider, and I never heard back.
Gaza Sky Geeks [0] is/was a startup accelerator or tech hub in Gaza, with backing from people from Mercy Corps, Google and Microsoft. Needless to say, their activities have been severely interrupted by the violence since October 7th, 2023. I'm subscribed to their email newsletter, and the updates are heart-breaking.
If anyone from Gaza Sky Geeks is reading this, please consider sharing those updates on your blog as well as on your email newsletter, so that they can be shared more widely.
I use https://song.link (or Odesli). It finds the link to the song on Spotify, Apple Music, YouTube, YouTube Music, Pandora, Deezer, SoundCloud, Tidal, Amazon Music, AudioMack, Anghami, Napster, Yandex and BoomPlay, maybe more.
odesli.co: https://album.link/s/1eDOxiSqqxS8jSgDCsaC38 - no less than eleven different links to stream, though about half of them didn't have anything when I clicked on them. And three links to buy it, too.
I got similar results with my previous two purchases, clipping.'s Dead Channel Sky and Captain Ahab's The End of Irony. IDHS said "not available on other platforms" while odesli.co turned up close to a dozen links to stream each, and three places to buy them. Maybe IDHS works better if you're not a fiftysomething lady with hilariously obscure taste, I dunno?
odesli: https://album.link/i/1736268193 - 14 streaming links, 3 purchase. Including working links to Deezer and Soundcloud that IDHS didn't turn up despite saying those are the places you can start from.
If I buy something, not only should I be allowed to keep it until I die, but I should also be allowed to pass it on to someone else after I die. I should also be allowed to give it or to sell it even before I die. That's currently impossible with many of these so-called digital purchases.
It's a huge bummer that Steam has trained a whole generation to give up their right to own a game disc they can loan, trade or resell. And see it as a good thing because now all their games are in one "place".
Steam came at a time where publishers were already fighting to stop resells. For instance copy protection was abused to expand to single use codes.
In a way, the lower price of Steam helped swallow the disappearance of the second hand market. I see the point, but wouldn't set it as a positive thing (neutral at most?)
What about server-generated passwords, like API keys? That would solve the main problem with passwords, namely, that people reuse the same weak password everywhere. I doubt it would be as popular as user-selected passwords, but I still wonder why no website has tried it.
I agree. I was expecting the author would implement debouncing or throttling to reduce the number of unnecessary requests, alongside fixing the data race issue. Here's an excellent article on debouncing and on throttling, and the difference between them:
reply