I never intended it to be a side project, I just liked the extension and started contributing heavily to it, to the point where I became the maintainer for the next several years.
I get about that amount per month in GitHub Sponsorships. Not nearly worth the amount of time I put into it, but it’s relatively effortless work. It makes my regular work on other GitHub projects more enjoyable (due to the features that Refined GitHub adds)
I used it a lot when i was required to use github. In fact, i think i used to send you a lot of patches on npm stuff. I recall sending open source sponsorship requests often but never heard of any follow up.
Thankfully not required to suffer github anymore. Specially now that their search is so bad. I dont' even want to imagine the work you had "refining" their new code viewer :)
The fun part is that they completely botched an experience that iOS can delivery natively. I built a mini app to extract the HSL stream from a URL and have iOS play it. It usually solves my problems with it: https://arte.vercel.app/
Thanks for the note! I had no idea. And that makes it all the weirder that Google postponed things, especially because it seems the community is relying on Google to provide guidance on how to do a lot of things with MV3.
Look into chrome.storage.session, they created it explicitly to allow in-memory storage for those scenarios. Not as easy as just setting a property, but good enough.
I'd be curious about latency for frequent access and the 1MB quota. I think that may make it a similar solution on the surface, but fairly limited in usage.
I was powering a fairly large amount of state, to the point we had to diff state changes due to browser message costs. It was difficult to write, but was incredibly powerful.
No security system is absolute, and treating all threats as equally possible leads to terrible security decisions like not using printed recovery codes for fear of them getting stolen. You must pick a threat model before you can evaluate the security of a system.
Treating printed paper codes as "widely known" and effectively useless simply because they could theoretically be stolen is silly. In a reasonable threat model for almost all people, the intersection of the set of threats that might get access to printed paper codes and the set of threats that might hack/phish your password is very small. The vast majority of threats are still protected against, while the very real possibility of being locked out of your account is drastically reduced. It's a good trade for almost everyone.
I don't disagree with this, I disagree with the way you formulated it initially. There's a difference between sharing recovery codes with 2-3 trusted people vs. posting them literally everywhere which your original post seemed to imply.
Yea but the chances of some dude in Bangladesh finding out your 2fa code because you lost your wallet approaches 0%. Joe Blow from Kentucky ain’t gonna be the one stealing your account.
They are, however, secret codes, and should be regarded as confidential. Just because you can divulge them without direct harm does not mean you should publish them on billboards and Facebook for safekeeping.
This is true but isn't relevant to my advice. If you can't see the difference between keeping a nondescript piece of paper at the bottom of a drawer at your parents' house and posting it on Facebook then you should not be making any decisions relevant to security. And using the word "secret" causes people to treat the codes as more precious than they really are, and make bad decisions like not printing them at all.
1. System reports "print out these recovery codes and deposit them in multiple places so you will never lose access to your account". User John Doe posts his security codes on his Facebook page and gets hacked.
2. System reports "print out these security codes and store them in a safe place". User prints them out and stores them in a drawer, but his house burns down and the user loses access forever.
Both scenarios are shitty, but I think 1 is more likely.
Of course, you could write a detailed guideline on where to store your codes, and that you should share them with some trusted people but not everyone etc. But who's gonna read that?
People who understand security already take threat models into account, but those who don't need very simple guidelines.
Italy has SPID. It’s a federated login system based on your fiscal code (every Italian has one). You can use it to log into any government service and potentially banks and such. If you do lose access to your 2FA (required, it’s your phone), you can:
- re-verify yourself with the provider, with a real ID
- get a new ID with another provider, which still points to the same fiscal code
As a global solution, it would be great to have a “real identity provider” that offers this but also allows me to log into services without giving them too much information.
Apple ID seems relatively good for this given that it lets me hide the address and change my name during registration.
Digital menus aren't bad, but very few can implement them effectively. I do like having access to the menu for the whole dinner though and not have to wait for the waiter, ever.
In general, yeah, give me a piece of paper, there are far more people who can print some text than developers who can make a decent menu page — and it's quite sad, given it should just be a single, flat HTML page with an "index"
