I just tried Bun to make a script to copy files from a service we were moving off of to S3 and it's pretty great.
Instead of having to tinker with my package.json, tsconfig.json, etc. to get everything just right, it works right of the box the way you expected with `bun init`.
Then it's just `bun run index.ts`.
And it's fast!
Node is great but there's just too many options to configure. I appreciate that Bun went ahead and made a bunch of assumptions and pulled commonly used stuff directly into it.
I'm aware of that initial support, I've been followed that since they added the experemental flag.
As far as I know, it requires some non-standard usages in TS code, like adding the .ts extension to your imports at the top of your TypeScript files. It doesn't support .tsx files or any TypeScript feature that requires more than type striping. The initial support is appreciated, but it's not on part with Deno or Bun yet.
TL;DR you will still need to work on adding proper TypeScript support anyway, compared to Bun.
How do you explain the fact that car manufacturers can and do build plants in Mexico and use cheap labour there, but still can’t compete with Chinese manufacturers?
Labour cost isn’t the problem, the problem is that US innovation has stagnated and now his to rely on protectionism to compete.
I feel like I just enumerated several ways that China is overwhelmingly cheaper than practically any other advanced economy. But I will try to spell it out even more.
Labor is almost certainly not as cheap in Mexico as it is in China. China still enjoys benefits of "developing nation" status despite being very advanced when it comes to manufacturing. There are many variables when it comes to productivity such as the amount of investment, the size of the workforce, and government subsidies. If you believe in specialization, then having a much larger population to work (as also consume the product) is a big advantage. The Chinese government is heavily involved with its domestic businesses, from literally owning them to spying on their behalf, to putting up roadblocks for any competition. Mexico might be as advanced as China if we had outsourced everything to them instead of China, but I'm sure that did not make sense when we started doing it and it probably still does not.
There's nothing magic about China. It's just got lots of people and cheap labor, and a bunch of policies that are unfair to the rest of the world. They have a head start of about 30+ years on Mexico and other competition. The US and euro nations have let everything basically rot for 30+ years instead as everything got shipped to China. It's not that we can't do anything that they can do in principle, but it takes time and investment and the result is hard-pressed to make enough money due to the fact China can do it cheaper. In most cases Western manufacturing was better than Chinese for the longest time, but we basically taught them all our trade secrets without them sharing back any knowledge. We don't have a large pool of workers with manufacturing experience as they do, because of the outsourcing.
We have some subsidies, but they pale in comparison to what China does and come with random obligations like quotas per ethnicity or sexual orientation. TSMC complained about this stuff recently. They got billions of dollars in subsidies but still struggle to hire the right people locally in the US.
It takes decades for some of these industries to build up, even going back to the university training pipeline. The idea of pushing a "service economy" is a costly mistake that nearly all Western countries fell into. At some point, China and other manufacturing-based nations will refuse to take worthless Western currencies in exchange for their goods. That is, unless we have something real to offer in exchange.
1. Given that Mom doesn't understand the bulk of the prompt, should we take away the prompt and encrypt the e-mail; i.e. treat the e-mail in a way she doesn't understand? (Maybe! After all sending an e-mail over TCP/IP and SMTP, and adding various headers and whatnot also treats it in ways Mom doesn't understand, and those have to be done. Or maybe not. Encryption literally obliterates the content, making it unreadable without the key.)
2. Your mom would likely understand "If unsure, answer No", and end up sending a normal e-mail. That text should be in bold, probably. Some of the verbiage could be behind some "learn more" link, where there is space and scope for a better explanation.
It is probably better if the switch is on the receiver's side, as some kind of Boolean field in the key registration record.
Given that mom isn't going to understand any of the prompt, and presumably has no pressing care or need for encrypting an email, the sensible default would be to send email unencrypted unless she expressly asks otherwise.
It is pretty interesting seeing the various different design philosophies for computer UIs compete in this thread:
the typical Linux approach (ask the user a convoluted question, expect them to understand it and expect an informed response - if/when the user selects wrong, tough shit)
the Windows approach (ask a convoluted question but give an out for the 99% of people who don't understand it - if the user still selects wrong, tough shit)
the Apple approach (don't ask the question at all and choose a sensible default, because 99% won't care - 99% of users get the exact result they wanted to begin with)
Hi! Proton crypto team lead here. Our motto is "Privacy by default". We're aiming to fulfill that mission as much as is practically possible. In this case, looking up keys on keys.openpgp.org caused an issue for this user because they didn't know they have a key there. We'll try to make that more clear in the received (encrypted) emails - and we might look into opting out somehow.
However, we don't want to make it opt-in if we can avoid it, even if that's what would make sense for Linux, Windows and Apple; it's not what would make sense for Proton. You can't change the world by copying someone else :)
"Privacy by default" is a good motto when the mechanisms used to ensure privacy actually work most of the time. I'm sure that between ProtonMail users, it does indeed work most (if not all) of the time.
But once you leave the ProtonMail ecosystem, I expect you'll find that enabling PGP automatically doesn't work most or all of the time. It likely only works occasionally or even rarely.
> You can't change the world by copying someone else :)
Please take this as gently as I intend it: ProtonMail is unlikely to change the world on user privacy, at least when it comes to email. Larger providers are too entrenched, and most people won't care enough about privacy to change their email address (and very few people have a custom email domain to move between providers).
At any rate, it seems like you're copying Facebook: "move fast and break things". Not great when we're talking about messaging. You're breaking email for some people, and some of those people are your users. OP may not be one of your users, but OP's mom is, and you have broken her ability to send her son email with this misguided policy.
Obviously, rolling out end-to-end encryption in a federated system is difficult. We need to start somewhere, but obviously the outcome for OP was not ideal. That being said, we haven't actually had that many complaints about rolling this out. We'll still work to improve it further, obviously, and reduce failure cases like this. And, we'll take the feedback on board about moving more carefully and communicating such changes better.
> most people won't care enough about privacy to change their email address
Note that with this change, you don't need to change providers to get end-to-end encrypted email: you can let your email client or a browser plugin (like FlowCrypt or Mailvelope) handle OpenPGP for you, and (let it) upload your key to keys.openpgp.org, and we'll send you encrypted email. Obviously, signing up for Proton is still easier, but email is a federated system, and so I think it's important to invest in the feasibility of federated E2EE as well :)
Are you aware of any ergonomic solution for iOS, or for people that don't want to risk giving a browser extension full access to their webmail?
Otherwise, it seems like you're fine with breaking email delivery to everybody using that ever having published an OpenPGP key (and verified their email address) to the public keyserver.
> We'll try to make that more clear in the received (encrypted) emails
This seems like the ideal. If the message could look like
> This message from mom@protonmail.com was encrypted by PGP using the public key for foo@gmail.com retrieved from www.keys.openpgp.org
> -- BEGIN PGP MESSAGE --
...
Would that leak anything the email provider and every forwarding server couldn't already have known? Not sure if clients support this kind of mix of plaintext and PGP: of course you could put the metadata in the headers, but clients won't show random new headers by default and Google isn't going to help you encrypt messages they would prefer to read.
All of this is public information, so it shouldn't leak anything. So indeed we'll look into whether we can make this information show up in an interoperable way.
I suggest Proton to stick with the WKD procedure. Having CNAME record pointing to wkd.keys.openpgp.org or serving the public key on openpgpkey.example.org subdomain can be indicators showing that the receiver is willing to received email encrypted with the public key served via WKD. Otherwise, no need to fetch the key from public keyservers.
Why make unencrypted the default? For https, encrypted has become the default. Users don't need to understand certificates at all, but it works. We should have the same for email.
But that does require all clients to make this easy for the user.
Or realists that think that encryption-by-default needs to be designed very differently from PGP, and that forcing people into something brittle will not win any sympathy.
I think at this point I would consider a formatter essential for working with a team. It helps make code style opinionated and fixed and I have no surprises when reading code. No one doing weird formatting to align random things. Any formatting tool that allows for pages upon pages of options is simply not something I want to deal with. Something like black, gofmt and prettier is vital
Bike shedding. I say this as somebody who has written a once prominent JavaScript code beautifier. Automating code beautification is a nice to have. It becomes essential when developers cannot be bothered to focus on more important things because either more important things are too challenging for the given developers or because the given developers want to feel more important than their contributions/decisions are actually worth.
Auto formatting tools like prettier and black didn’t use to be essential but they’re quickly becoming essential. Just look at the growth curves for pip and npm installs. I for one feel like my editor is broken if it doesn’t auto format on save.
Instead of having to tinker with my package.json, tsconfig.json, etc. to get everything just right, it works right of the box the way you expected with `bun init`.
Then it's just `bun run index.ts`.
And it's fast!
Node is great but there's just too many options to configure. I appreciate that Bun went ahead and made a bunch of assumptions and pulled commonly used stuff directly into it.