Competence is expensive. Supply is low and demand is high.
What are you smoking? Shallow clones don't modify commit hashes.
The only thing that you lose is history, but that usually isn't a big deal.
--filter=blob:none probably also won't help too much here since the problem with node_modules is more about millions of individual files rather than large files (although both can be annoying).
I also find passkeys to be underwhelming and hope they don't catch on. It seems like a huge mire of complexity for very little gain. It seems like there are two main goals here:
- Don't sent secrets to the sever.
- Stop phishing.
Both great goals. However I wonder if we threw out the baby with the bathwater with passkeys.
A password manager is already a huge step to blocking phishing, because if the password doesn't auto-fill you get super suspicious. If you push your user to randomly generate their passwords then they also don't remember them so would have to look them up, then copy them over. If you are worried about users who are a risk to themselves you can make the route to extract a password from the password manager as complicated as you like.
As for not sending secrets to the server I think using a PAKE would have been a great option. If this was paired in a browser-integrated password manager it could be very secure. Think about some type of form field that can be filled with a password that isn't accessible to the page itself. The browser would then tag the password as PAKE and never expose it to the page again.
Another cool think able PAKE is that they can also authenticate the server. TLS-integrated SRP was very cool like this as you could have a self-signed certificate but verify it by entering your username and password. The UX may not have been good enough for public sites but it was an amazingly easy and secure option for private sites. This would actually be more secure than a PKI signed certificate as you aren't risking CA compromise. That being said integrating this with browsers with good UX may be quite difficult. I would love to see it.
But the biggest thing we lost was understandability. Even my grandmother understood what a password is. She knew how to back it up, how to transfer it to a new device. She could use it in two different browsers without setting up some multi-browser sync tool. She could write it in a notebook and log in at the library computer.
I really think that we should have just iterated on passwords. Switch to a PAKE and keep improving password-manager UX and pushing most users to auto-generated passwords. So much was lost by switching to a system that most users don't understand.
I wrote a blog about this a while ago. https://kevincox.ca/2022/04/07/passwords/
No, but it also doesn't make it any good to start with.
Not really. It is better than shitty JPEG encoders but not really much better than good ones. It's lossless was fairly good but still barely worth it. Really we should chuck it for JPEG XL but Google is strong-arming it for unknown reasons.
If the song is able to be freely distributed share a magnet link for an mp3, opus or flac file.
There are lots of reasons. Some off of the top of my head:
- People are more likely to shop there because they get "deals".
- People feel better about shopping there because they get "deals".
- More and better data for the business. (Associated with individuals over time rather than "anonymous" purchases, the also get extra info like a phone number that they can cross-reference)
- If you carry the card or app you will see it frequently and think about the store (free advertising).
- Often times you agree to some sort of marketing communication when you sign up.
- You usually get "points" which you need to come back again to use.
I think you are agreeing with me. I like Proton because it uses a standard protocol and it provides a migration path from unencrypted to encrypted.
PGP and GPG are effectively synonyms in this context. (GPG is just an implementation of PGP)
Yeah, this is one of the things that I quite like about Proton. It provides a migration path. You start sending and receiving plain-text mail (then encrypted before saving) but now you can use an open standard protocol to start communicating securely and Proton can slowly lose the ability to read much of your email.
IDK if the other "easy encrypted" providers just use standard PGP.
They are a powerful tool. They are controversial because they can be used for good and evil. For example even some FSF projects require copyright requirement: https://www.gnu.org/licenses/why-assign.en.html. (It used to be all projects, but many have them have switched to DCO, example glibc)
But of course it also means that an organization can take code in a GPL project and start disturbing closed-source versions.
See https://en.wikipedia.org/wiki/Contributor_License_Agreement#Relicensing_controversy for a basic overview.
Lots of projects will have a CLA that basically says "You assign copyright of your work to us" or some sort of unlimited rights grant to the project. So depending on the exact CLA the author may completely transfer ownership of the patch to the project, maintain ownership but grant the project a licence to do basically anything with it (including re-licencing) or for less strong CLAs just confirm that you license the code under the project license.
Once you push it once it is pretty fast.