scottmotte

I'm the creator of Node dotenv and I gave this a lot of thought a couple years back. I put together a whitepaper on this. Ultimately your secrets do still have to hit your environment. But at-rest they should be split from the environment. Today I think that is encrypting your .env file and keeping the decryption key separate. Bring the decryption key only at runtime inside your environment.

https://dotenvx.com/whitepaper.pdf

Cryptographic systems are mostly designed for machines, not humans. We end up staring at long strings. I wanted to experiment with how to better visualize them - in a more human way. The result is KEYSEE⎔. Try it out and hope you enjoy! There is also a whitepaper that goes into more details (under the /api section).

> If you did 'dotenvx run -- env', all your secrets would be printed right there in plaintext

Same for sops.

> The equivalent in vercel would be encrypted in the database (the encrypted '.env' file), with a decryption key in the backend

The encrypted .env file is actually committed to source code, and the decryption key is placed in Vercel's environment variables dashboard. The attacker only gained access to the latter here if using dotenvx so they can't get your secrets. Unless they also gained access to the codebase in which they have terabytes of data to go through and match up private keys from the database with encrypted .env files from the source code exfiltration - much more effort for attackers.

Creator of dotenvx here.

There is no silver bullet, but Dotenvx splits your secrets into two separate locations.

1. The private decryption key - which lives on Vercel in this example 2. The encrypted .env file which lives in your source code pushed to Vercel

Attackers only got access to the first (as far as I know was reported). So your secrets would be safe in this attack if using Dotenvx. (A private key is useless without its corresponding encrypted .env file. Attackers need both.)

The whitepaper goes into the problem and solution in more detail: https://dotenvx.com/whitepaper.pdf

Encrypting your .env file with dotenvx, or something similar, can help mitigate this need for trust.

> developers could still potentially commit private keys the repo or commit the decrypted env file

to prevent this, use:

$ dotenvx ext precommit --install

I've tried all four, and Render is the closest experience to Heroku. It still isn't as easy to use as Heroku, but it is close.

> people are most comfortable being around people like themselves

Inertia. This is everything. It takes effort to be around people unlike those currently around you.

We all have personal biases against the strata economically above us and below us. I think most of the individuals that move up economically are able to get beyond these biases for one reason or another. Otherwise, even the most hardworking individuals tend to self-sabotage when they start to feel out of place.

I love the look of the Punkt. I ordered one 3 years ago but because of delays, and then Covid, gave up on receiving it. They issued me a refund but I'd still like to get one - in a reasonable amount of time.

Anyone have one and like it? Or recommend a different dumb phone?

1. On twitter

2. Start building. It will attract people. Don't go out and find them.

I posted this myself as well a couple days ago.

I was personally interested in HCQ before Trump ever tweeted it - turning it political. It was looking promising and still does.

After further personal study, I would like the conversation to continue.

Generic drugs [1]

[1] https://energycommerce.house.gov/sites/democrats.energycomme...

Yeah it would be great to see some numbers from anyone who might have them. I'd put money on SPAs being slower, inside the bell curve than, than the average traditional page load app.

Why hasn't someone built an email system that only accepts signed payloads?

Email would only be allowed into my inbox if it was signed. Then, layer 2, it would only allow signed emails from senders whom I've accepted their public key.

A separate tab would show me all incoming request to accepts public keys (request to send email)

Now to opt-in to a marketing email I first accept their public key. To opt-out I delete their public key. Their email now goes to /dev/null.

Senders wouldn't have to re-implement unsub/subscribe, spammers would be /dev/nulled, and we could later add encryption on top of signing as a requirement.

I wish there was a standardized or common methodology for classifying notifications. App developers could adopt this and consumers could take the pattern with them across all types of interfaces - desktop, smartphone, speakers, tv. Maybe someone knows if any government entity or force has a methodology for this?

That's a novel thought. I imagine then the native mail apps would expand in settings in order to block some bad senders from abusing that email header.

Tangentially related, iOS mail app has a VIP setting.

[1] https://support.apple.com/lv-lv/HT207213#vip

I believe that is for the all-in-one option. And I do not believe Authorize.net offered that a decade back. Anyways, if you already have your merchant account, it is only 10cents a transaction.

That brings me back. I remember Authorize.net before there was the ActiveMerchant gem (ruby).

Have you used Stripe as well? Authorize.net always got the job done. Then Stripe came along. I was honestly surprised of its success at the time. It was mainly just more of a joy to use - not cheaper or much easier. Just 'fun' as I remember it.

Doesn't Google Analytics support this using user IDs?

Novel and I like the mental model. It seems like this pushes more of the management to the user - to manage the key. Or providing the user nice consumer tools to manage the key - adjacent to your core product. The hard part here is probably getting consumers to use/download/install that tool.