App developers have repeatedly stated that offering those options increases user account creation. There is lower friction to using “login with <big tech>” than to create username/password creation flow. My guess is that most of the world hasn’t figured out a password manager workflow that works for them (or they aren’t willing to pay for it).
The ease of suspend isn’t the problem here. It’s that there is functionally no recourse once the suspension happens, justified or not.
The only people who seem to get un-suspended are the ones who can generate news media outrage or who can call their friend who is a director/exec at the company. (Obviously this intuition is flawed, but it’s hurting the reputations of these SaaS providers.)
As someone with deep experience in MIME encoding/parts, HTML for emails, and email client support for different HTML/CSS/image content, this is a sinkhole.
The world will be better off when we fork HTML so there is one standard email-safe version that all modern email clients support natively. There’s entirely too much security surface area to put arbitrary HTML into emails and expect any 2 email clients to render it correctly / the same.
> There’s entirely too much security surface area to put arbitrary HTML into emails ...
We manage it with browsers though.
Don't get me wrong, I've never liked html in emails to begin with. It's the same issue that markdown and every other rich text system has regarding where to draw the line. HN even strips most emojis (and I think that's a good thing).
When emojis are stripped on one website, users of that website understand it’s a product limitation.
When links work on one email client but not another, that’s a huge issue for the email sender and a lot of headache to learn/study the differences between email clients and the stack they are built on.
The difference between HTML and CSS properties supported on different email clients is WILD.[1] the rendering differences are significant, as are the man hours required to get emails to mostly look predictable on the breadth of email clients in use today.
And remember that every time there is a browser engine (or even just a fork) people have to maintain it. They need to develop features, squash bugs, patch security issues, pull from upstream, coordinate with downstream forks, etc. webmail providers are SaaS but have to have intricate and accurate understanding of every browser parse / rendering bug/permutation and a deep understanding of all of the legit HTML/CSS/JavaScript/DOM/XML/images/URLs (including weird ones like data: blobs) supported by every browser.
“we manage it” is doing an insane amount of hiding the complexity there.
I never claimed email clients were uniform (that would obviously be incorrect). I responded to "too much security surface area" with "browsers seem to manage it". The security is clearly a solvable problem because we all use the solution every day.
In your analogy, different email clients equate to different products (ie websites). I agree that it's a headache for users. My point was that it's not an unsolvable security issue but rather an unsolvable lack of agreement about what should and shouldn't be included in a rich text representation, or if email should even use rich text at all for that matter.
Discussion of the MIME part’s encoding as being an inefficient size is missing the forest for the trees.
The entire message is (or can be) compressed before transmission (eg. When IMAP has DEFLATE enabled).
Just because an intermediate encoding step expands binary to make it text safe doesn’t mean it has to stay uncompressed during the entire existence of that MIMe message.
If all you need is file transfer even the message header is a lot of overhead (how much overhead depends on the client and how many devices handle the message). Mail servers don't always handle large files very well either. Even if they upload correctly downloading can be difficult. It's not uncommon for a single message with a large attachment to clog a mailbox and prevent other messages from being sent/received. That said, I'm not even saying it can't/wont work, just that there's better options for sending files and there are certainly better MUAs than outlook.
I’m not arguing for Outlook. I wouldn’t touch that POS unless I was forced to.
But maybe it’s just easier to not have to teach an astronaut to use another app. If they are using Outlook in space, it’s probably the same app and server they use on the ground.
Of course FTP or RSYNC or whatever would be slightly more efficient for the transfer or more capable or retrying / resuming. I’m not arguing that either.
Sometimes it’s more important that the astronaut doesn’t have to learn another app instead/ system.
Sometimes it’s better to choose a less efficient system that is less prone to accidental destructive. It’s not like anybody ever screwed up a sync command and accidentally wiped a directory or anything.[1]
I don’t think you can write off Apple or Microsoft just because Thiel made some investment in them.
Being the VC to a company’s round B, C, and D (adding up to maybe 40% ownership/control) is VERY different from simply throwing some money at a trillion dollar company to see some returns.
Small correction: it’s not the ink that is toxic, but the chemicals added as a coating to help the ink develop. Still pretty bad for you though. Some stores have bisphenol free receipts (especially those that are all about natural and plastic-free goods), but they are rare.
I’m guessing you mean “does” in the sense of a user-facing feature.
I’ve heard that LinkedIn searches for several hundred known browser plugins to identify potential abusive users. If the “simple chat apps” aren’t doing that, then it’s apples-to-oranges.
App developers have repeatedly stated that offering those options increases user account creation. There is lower friction to using “login with <big tech>” than to create username/password creation flow. My guess is that most of the world hasn’t figured out a password manager workflow that works for them (or they aren’t willing to pay for it).
reply