I wouldn't say it's without pay. It's in the job description when you're hired and the pay should compensate for that. SREs are typically paid very well.
I'm not sure there's a realistic alternative. If you need to generate a key then it has to happen somehow on unsupported platforms. You can check Enabled() if you need to know and intend to do something different but I assume most of the time you run the same function either way you'd just prefer to opt into secret mode if it's available.
This is not what secret.Enabled() means. But it probably illustrates that the function needs to be renamed already. Here's what the doc comment says:
// Enabled reports whether Do appears anywhere on the call stack.
In other words, it is just a way of checking that you are indeed running inside the context of some secret.Do call; it doesn't guarantee that secret.Do is actually offering the protection you may desire.
One of the goals here is to make it easy to identify existing code which would benefit from this protection and separate that code from the rest. That code is going to run anyway, it already does so today.
It can be more complicated depending on your environment but I'd prefer instead to use a Pub/Sub pattern instead. You can have a generic topic if you want to model it like the generic table but it handles retries, metrics, scaling, long-running, etc all for you. If you are running in the cloud then Pub/Sub is something you don't need to maintain and will scale better than this solution. You also won't need to VACUUM the Pub/Sub solution ;)
What's the payment threshold? I assume you're paying 2.9% and $0.30 (or around there) for the transaction. You charge that to the customer but what if their bill is $0.01, are you really going to make them pay $0.32 for $0.01 of usage? How do you expect SaaS providers to communicate that on their pricing page? If they charge $0.01 per request and the end-user makes 100 requests their bill is actually $1.33 which means the actual per-request charge is $0.0133.
Several years ago Stripe offered more favorable pricing for small transactions but it's my understanding that that pricing is no longer available to new Stripe businesses.
If a customer's balance is under $1 at the end of the month, we delay charging them for up to 60 days and send email reminders. If it's still under $1 after 60 days, we charge at least $0.50 and credit the difference (after fees) to their account for future use.
They MITM the real sign-in on NPM. So NPM actually sent them a 2FA but the user entered it on the phishing site. The attacker then relayed that to the real NPM.
Just 64 characters but they do integrate with a password manager and have a 1-click button to add it. The integration was pretty seamless and saved it in 1Password.
If you're in a group and someone is backing up the messages, it only affects your messages in that group. All of your other chats are still secure as long as you're not using the backup frature.
You (and Signal) can't control how the recipient handles your messages if you're not using disappearing. They could be copying and pasting your messages or taking screenshots. I don't see how the backup feature is any different.
