Similar switching story. I'm very happy with an iPhone overall, but god damn they keyboard took some adjusting. The default keyboard on Pixels (GBoard?) is excellent. The autocorrect is also unimaginably better on the Pixel. It's embarrassing how bad the iPhone's autocorrect is. Not just missing obvious cases, but actively sabotaging correct cases.
I personally haven't found any keyboard that works better than gboard. And exactly because it's the only keyboard that just lets me type in two languages without having to "switch", and it does that well. Right now my spacebar just says "NL - EN" and it lets me combine Dutch and English just fine.
From my experience it is much worse than it used to be 5 years ago. I have been writing English, French, and to a lesser extent German on an iPhone since ~2008. Initially, the dumb autocorrect would just correct to the closer word in the dictionary corresponding to the current keyboard, but over time it would pick up more and more words I used regularly. At some point around 2018 or so, it was nearly flawless. I think it changed the dictionary depending on the language or the sentence, because I had different suggestions for the same mistyped word in the same document. Also, I assume that by then my personal dictionary was quite extensive.
And then they bragged about a new machine-learning improved keyboard and it went downhill. First, all keyboards became monolingual, which was a 10-years regression. And even in that language, it was very flakey. They added multi-language keyboards somewhat recently and it got slightly better, except that for some reason it changes the keyboard back to the English-only one regularly for no reason I can see.
It is maddening. For a couple of years it was fantastic.
And that’s not the worst. On the Apple Watch not only is the multilingual keyboard completely broken, but worse than that: if you change the language of the keyboard by long pressing the space button it shows the new language, but the autocorrect proceeds to just ignore it completely and autocorrects everything as if I were typing in the system language rather than the one I selected.
And contrary to the iPhone you can’t even disable autocorrect! This + the super-aggressive autocorrect of watchOS (the screen is small after all so you are likely to make a mistake and we better fix it automatically!) makes it an absolute NIGHTMARE to type on an Apple Watch in multiple languages. Your only option is to use speech to type because that one for some reason works when you change the language whereas the keyboard doesn’t care.
Edit: the language switch bug on watchOS seems to have finally been fixed on watchOS 26.1. The bug was already long present on watchOS 11, so not something that watchOS 26 introduced.
This. I use romanian, english and turkish at the same time. Sometimes goes sideways because we mix a lot of words in english and romaninan in the same sentence, but it's ok. No other keyboard comes close.
Multilingual typing is a godsend. I did have to tweak settings though, like disabling the "suggestion strip" (because sometimes I'd be typing fast and accidently click the GIF button, then an image, which in many apps sends it immediately without a draft which was extremely annoying).
It's abandoned and buggy. I'm surprised google hasn't just removed it from the store. I suspect as soon as it actually requires an update because of a change in the OS it will disappear.
Yes, I loved it, but it crashed in too many apps and I had to switch to the Apple one :(
Yeah I tried it and it doesn't stand up to it on Android in my experience. I figured I'd rather not give Google any data if the experience isn't going to be the same.
>autocorrect is also unimaginably better on the Pixel
Pixel user here. That depends on the language you're typing. Autocorrect and spellcheck, not just on Android but other Google products, will change correct danish to incorrect danish. It's infuriating. The issue I encounter most often happens because Google apparently assumes english grammar is universal, and insists on splitting compound words, which is never done in danish.
Danish is already being heavily eroded by foreign influence, and this isn't helping.
> It's odd to always say "Hashicorp, an IBM company". Looks like they want to assign blame.
All their branding does this now, including the HashiCorp logo on their website [0]. There's gotta be a name for this specific branding pattern, but I don't know it.
It’s endorsed branding. Basically when a parent company “endorses” its subsidiaries’ brands, but keep their own name (as opposed to renaming everything to IBM, like eg Google would do).
It's an optional tool that can be used to implement drivers now, not forced. If you don't like the idea of another language being supported for implementing a subset of kernel modules, I don't think you wouldn't enjoyed having a Linux machine anyways.
That's not the case. It's using Rust as a selling point. All the noise around using Rust is marketing. The fact that you think linux machines are enjoyed by only a specific group of people makes me happier with my choice
> That's not the case. It's using Rust as a selling point
"Rust as a selling point" was a big thing in 2018-2022ish. You see it a lot less of the "written in Rust" in HN headlines these days. Some people were very excited about Rust early on. What feels more common today are people who unnecessarily hate Rust because they saw too much of this hype and they (justifiably) got annoyed by it.
If there is a new, optional language to be added to Linux Kernel development, Rust makes sense. It's a low level, performant, and safe language. Introducing it for driver development has almost no impact on 99% of users, except maybe it'll safe them a memory related bug fix patch having to be installed at some point. Is Rust the "selling point" here, or is the potential to avoid an entire class of bugs the selling point?
> The fact that you think linux machines are enjoyed by only a specific group of people makes me happier with my choice
If by "specific group of people" you mean "people who will refuse to use an OS based on the implementation language(s)", then I guess so.
I don't mean to be rude (although it reads like it, apologies), but I just think that you're coming at this from a perspective of malice instead of what the goal was, which was to reduce bugs in kernel drivers, and not to pimp Rust as a programming language by getting it into a large software project.
No worries I didn't take offenses. I just disagree. The title should've been we reduced bugs in the kernel and here is some proof of that. The 2018-2022-ish hype (I call it bullying campaign) is still strong. Google recently did a blog post about Rust speeding up their development, in the age of LLMs, seriously! I can't stop lol'ing at that
That's just not true. Neither Linus Torvalds, nor the Linux Foundation, nor any major distro, nor anyone else who could conceivably be considered responsible for "marketing" Linux is saying you should use it because a small part of it is written in Rust.
I just went to ubuntu.com and the word "rust" does not appear anywhere on the front page. So what are you talking about?
Let's Encrypt was _huge_ in making it's absurd to not have TLS and now we (I, at least) take it for granted because it's just the baseline for any website I build. Incredible, free service that helped make the web a more secure place. What a wonderful service - thank you to the entire team.
The CEO at my last company (2022) refused to use Let's Encrypt because "it looked cheap to customers". That is absurd to me because 1), it's (and was at the time) the largest certificate authority in the world, and 2) I've never seen someone care about who issued your cert on a sales call. It coming from GoDaddy is not a selling point...
So my question: has anyone actually commented to you in a negative way about using Let's Encrypt? I couldn't imagine, but curious on others' experiences.
To be fair, for a CEO in 2022, EV certificates had only lost their special visualizations since September/October 2019 with Chrome 77 and Firefox 70 - and with all that would happen in the following months, one could be forgiven for not adapting to new browser best practices!
It was a red herring the entire time. At Shopify we made experiment regarding conversion between regular certs and EV before they stop being displayed and there was no significant difference. The users don't notice the absence of the fancier green lock.
I think the rebuttal to the CEO today is really very simple.
a) How many of the sites you visit everyday have DV and how many have EV certificates?
b) Name any site at all, that you have visited, where your behavior or opinion has changed because of the certificate?
In truth the green-bar thing disappeared on mobile long before desktop (and in some cases it was never present.)
In truth if you polled all the company staff, or crumbs just the people round the boardroom table (probably including the person complaining) a rounding error from 0 could show you how to even determine if a cert was DV or EV.
EV could have an inspector literally visit your place of business, and it would still have no value because EVs are invisible to site visitors.
Call me old-school, but I really liked how EV certs looked in the browser. Same with the big green lock icon Firefox used to have. I know it's all theatrics at best and a scam at worst, but I really feel like it's a bit of a downgrade.
Only IT understand any of this SSL/TLS stuff and we screwed up the messaging. The message has always been somewhat muddled and that will never work efficiently.
> Call me old-school, but I really liked how EV certs looked in the browser.
I agree, making EV Certs visually more important makes sense to people who know what it means and what it doesn't. Too bad they never made it an optional setting.
When you request an EV. They call you by the phone number that you give to ask if you requested a certificate. That was the complete extend of the validation.
I could be a scammer with a specificity designed domain name and they would just accept it, no questions asked.
> In addition to all of the authentication steps CAs take for DV and OV certificates, EV certificates require vetting of the business organization’s operational existence, physical address and a telephone call to verify the employment status of the requestor. [1]
Tying a phone number to a physical address and company is a lot more useful than just proof of control over a domain. Of course its not 100% fool proof and depends on the quality of the CA but still very useful.
> Tying a phone number to a physical address and company is a lot more useful than just proof of control over a domain.
It might be useful in some cases, but it is never any more secure than domain validation. Which is why browsers don't treat it in a special way anymore, but if you want you can still get EV certificates.
It was easy to provide the information for an existing business you're completely unrelated to. Reliably verifying that a person actually represents a company isn't possible in most of the world.
Many countries has official register of companies with at least post box address. Requiring to answer a physical letter sent to an address from the central register will be much more reliable.
IMO it would make sense to tie into the trademark system. Allowing companies to build a brand reputation and protect it from impersonators is literally the whole point of that part of our legal system.
Imagine if only the owner of the McDonald's trademark could issue a certificate which displays the McDonald's name and logo, for example.
Depends on the registrar. Globalsign required the phone number to be one publicly listed for the company in some business registry (I forget exactly which one), so it had to be someone in our main corporate office who'd deal with them on the phone.
Dun and Bradstreet (?). I believe I'm remembering this correctly. I still deal with a few financial institutions that insist on using an EV SSL certificate on their websites. I may be wrong, but I believe that having an EV SSL gives a larger insurance dollar amount should the security be compromised from the EV certificate (although I imagine it would be nearly impossible to prove).
When I last reissued an EV SSL (recently), I had to create a CNAME record to prove domain ownership, as well as provide the financial institution's CEO's information which they matched up with Dun & Bradstreet and called to confirm. The entire process took about three days to complete.
For an online business in a dubious (but legal) domain, my co-owner spent a few hundred bucks registering a business in New Mexico with a registered agent to get an EV cert.
I have an almost identical story except the state in question was Nevada. I’m curious what “dubious” domain it was, for me it was video game cheats. Maybe I’m actually the co-owner you’re talking about. :)
I'd love a referral to your certificate authority and rep - we go through a big kerfluffle each renewal period, only eventually receiving the certificate after a long exchange of government docs and CPA letters. For us, only the last step is the phonecall like you say.
This exchange seemingly proves the argument that user trust gained from the EV treatment is misplaced, and that the endeavor was a farce all along. It's not as though the user's browser was distinguishing the good CAs from the bad!
I disagree. I specifically said in my original comment they were very useful for those that knew what EV certs were and EV certs weren't.
You may not know that Digicert is a quality CA who wasn't going to risk their position as a CA to sign an EV cert for a typo squatting phishing site pretending to be PayPal but there are those who do. The green UI in chrome & firefox made finding all of this information out incredibly simple and obvious.
It was used correctly. What CAs wanted to sell wasn't something browsers wanted to support, and EV was the compromise. It just happens that what EV meant wasn't that useful irl.
What's the alternative, showing the company's unique registration ID?
CAs invented EVs because the wanted to sell something which could make them more money than DVs. The fact that company names aren't unique means that the whole concept was fundamentally flawed from the start: there is no identifier which is both human-readable and guaranteed to uniquely identify an entity. They wanted to sell something which can't exist. The closest thing we have got is... domain names.
The alternative would have been to have the CA use human judgement when approving EV certificates and reject applications from organizations whose names shadowed better-known firms, or to only accept applications from a select set of organizations (like, say, banks). But either of those possibilities would have increased the cost of the program and limited the pool of applicants, so CAs chose the cheap, easy path which led to EV certificates becoming meaningless.
How many CAs do you think there are? How many countries do you think they operate in?
Maybe we could augment the old EV cert indicator with a flag icon, but now there's yet another thing that users have to pay attention to. Maybe the CA/Browser Forum could run a clearinghouse for company names, but apart from trivial examples, there might very well be legitimate cases of two companies with the same name in the same country, just in different industries. Now do we augment the indicator with an industry icon too? Then the company changes its name, or forms a subsidiary relationship, or what have you. Now do we need to put "Meta (formerly Facebook)" or "Facebook (division of Meta)" etc. in the name?
There's just so many problems with the EV cert approach at Internet scale and they're largely beyond solvable with current infrastructure and end-user expectations.
How do you decide when a company is "well-known"? What's going to happen when there are two well-known companies with the same name or a very similar name? What if a well-known company in country A expands to country B, where a well-known company with that name (but active in a different industry) already exists? How are you going to deal with subsidiaries which are both legally and organizationally separate? Who gets to keep the EV when a company spins off a division but both parts retain the same name?
"Use human judgement" might work for trivial examples of fraud, but it quickly breaks down once you try applying it to the real world. Besides, how are you going to apply the same "human judgement" across hundreds of employees at dozens of CAs? If anything, you're just begging to get sued by large corporations whose complex situation fell on the wrong side of your human judgement.
The problem is that people wrongly believe that company names are unique. In reality you're just some paperwork and a token registration fee away from a name clash.
If anything, it's a disadvantage. People are going to be less cautious about things like the website's domain name if they see a familiar-sounding company name in that green bar. "stripe-payment.com" instead of "stripe.com"? Well, the EV says "Stripe, Inc.", so surely you're on the right website and it is totally safe to enter your credentials...
In many countries, company names are unique to that country. And combined with country TLDs controlled by the nation-state itself, it'd be possible for at least barclays.co.uk to be provably owned by the UK bank itself when a EV cert is presented by the domain.
In the US though, every state has it's own registry, and names overlap without the power of trademark protection applying to markets your company is not in.
Are company names even unique within the UK? Sure, there can be only one bank named Barclays because of trademark laws, but can't there be a company in a different sector with the same name? Like Apple the computer business vs Apple the record company?
Or don't you have small local businesses (restaurants, pubs, stores) with duplicate names as long as they're in different locations? I know here in Flanders we have, for example, tens if not more places called "Café Onder den toren" (roughly translated as "Pub beneath the tower"). Do all local businesses in the UK have different names?
That's not exactly a great example, is it? "Barclay" even has a disambiguation page on Wikipedia, because it's a reasonably common Scottish surname.
For example, there used to be a Scottish company constructing steam locomotives which traded under the "Barclays & Co" name - because it was founded by one Andrew Barclay. There's also the Barclay Academy secondary school, and a Bentley dealer which until recently operated as Jack Barclay Ltd.
And that's just the UK ones! Barclays operates internationally, which means they want "barclays.com", so suddenly there's also Barclay-the-record-label, Barclay-the-cigarette-brand, Barclay-the-liquor-brand, Barclay College, golf tournament The Barclays, Barclays Center (whose naming rights were bought by the bank, but they of course want their own completely distinct website), Barclay Theatre, three Barclay Hotels.
Of course there's also all the stuff under "Barkley", "Barkly", "Berkley", and probably a dozen other variations just waiting to be used to scam dyslexic Barclays custumers.
Barclays used to operate under Barclays Bank PLC. IMO, if disambiguation was problematic online they would have reverted back to that name.
You bring up good points, but I don't think that company naming has to be 100% proof against confusion, it's just one more helpful thing for consumers to identify whom they are doing business with.
In the case of close names like "Barkley", if they're doing banking, there is probably a trademark case against if they actually use it to confuse customers.
EV validated not only that a domain was under control of the server requesting the cert, but that the domain was under control of the entity claiming it.
I kind of wish they still had it, and I kind of wish browsers indicated that a cert was signed by a global CA (real cert store trusted by the browsers) or an aftermarket CA, so people can see that their stuff is being decrypted by their company.
Problem is, I can easily set up a company and get an EV cert for "FooBar Technologies, LLC" and phish customers looking for "FooBar Incorporated" or "International FooBar Corp.". Approximately zero users know the actual entity name of the real FooBar.
Even if the users knew exactly what the name of the entity whose website they wanted to visit was: that name is not unique, as is shown by the "Stripe, Inc" example in the parents linked blog post.
BIMI, as misguided as it is, does aim to solve this by tying registration to insanely high prices and government-registered trademark verification. You would have a hard time registering the Stripe trademark nowadays in a way that would get you a BIMI certificate for that name/logo.
But I'm glad that it hasn't caught on as strongly-expected by the public (or even commonly used). Big brands shouldn't be able to buy their way into inbox placement in ways that smaller companies can't replicate.
Trademarks are industry-specific. Ordinarily, a painting company called Stripe isn't going to cause confusion with the payment platform Stripe, so there's no reason to deny the trademark.
It's how you end up with both Apple Corps (the Beatles' record label) and Apple Computer (the tech company). They've been involved in quite a few lawsuits over the years, mostly because the tech company decided to expand into the multimedia business.
I once notified Porsche that one of their websites had an expired certificate, they fixed it within a couple of hours by using Let's Encrypt. It surprised me.
Let's Encrypt is to the internet what SSDs are to the PC. A level up.
I've seen people complain that Let's Encrypt is so easy that it's enabling the forced phaseout of long-lived certificates and unencrypted HTTP.
I sort of understand this, although it does feel like going "bcrypt is so easy to use it's enabling standards agencies to force me to use something newer than MD5". Like, yeah, once the secure way is sufficiently easy to use, we can then push everyone off the insecure way; that's how it's supposed to work.
Yeah, I hate how it made housing things locally without a proper domain name very difficult. My router _shouldn't_ have a globally recognized certificate, because it's not on a publicly visible host.
There's certainly advantages to easily available certificates, but that has enabled browsers and others to push too far; to be sure, though, that's not really a fault of Let's Encrypt, just the people who assume it's somehow globally applicable.
> My router _shouldn't_ have a globally recognized certificate, because it's not on a publicly visible host.
If you're not encrypting local network traffic then any rogue device on that network can decide to intercept it and steal your admin password. That's one of the biggest reasons why we adopted HTTPS in the first place - whether a host is public or not isn't relevant.
It doesn't need a "globally" recognized certificate signed by a public CA, self-signed ones are fine. At home I manage mine with XCA. I have a root CA that's installed on all of my devices, with name constrains set to ".internal", ensuring it can't be used to sign certificates for any other domains.
A related issue is that most consumer devices (both iPhone and current Android) make it impossible or extremely difficult to trust your own root CA for signing such certs.
A long time ago when I was playing with rolling my own PKI, each of Android, iOS, Chrome, Firefox, and even Internet Explorer allowed me to install a root CA by opening the .crt file. From what I remember, iOS popped up some warnings and added the cert as part of a profile, but it did work.
I know things like MDM/Intune/Group Policy/etc and such can A) faciliate doing this on a large number of devices and B) prevent users from doing this on their own.
Android is pretty easy, you just add it to the keystore and that's it. I've had my own CA long before Let's Encrypt, but now mostly only use it for non-public devices that can't easily use Let's Encrypt (printers, switches, etc).
You can add it to your user CA store, but no app will trust it since it's treated differently from the system CA store, which you can't modify without root or building your own ROM. In effect it is out of reach for most normal users, as well as people using security focused ROMs like Graphene, when ironically it can improve security in transit in many cases.
It's technically possible to get any Android app to accept user CAs. Unfortunately it requires unpacking it with apktool, adding a networkconfigoverride to the XML assets and pointing the AndroidManifest.xml to use it. Then restitch the APK with apktool, use jarsigner/apksigner and finally use zipalign.
Doesn't need a custom ROM, but it's so goddamn annoying that you might as well not bother. I know how to do these things; most users won't and given the direction the big G is heading in with device freedom, it's not looking all that bright for this approach either.
I don't want to trust my own root CA as I don't trust myself to keep it secure.
I want to important it only for a specific set of domains. "Allow this rootca to authenticate mydomain.com, addmanager.com, debuggingsite.com", which means even if compromised it won't be intercepting mybank.com
You can absolutely do that with name constraints extension set on the root CA certificate. You should verify compatibility but it's pretty universally supported on modern browsers and consumer devices last I checked.
If you generate the root CA sure. However name constraints aren't well supported.
A far better option would be to allow me, the user, to do this in the user agent. I can import my mitm cert and today I can trust it for "abc123.com" and point that to something I want to access in that manner for some reason, but tomorrow simply toggle that trust off.
If I find that I want to use a specific website and want to do something with the traffic, then I could point that DNS to my middle-box and turn that on in my browser. With name constraints I'd have to regenerate the root certificate with the new domain, and then re-import it.
the entire concept of the name constraints puts the power into the CA issuing person rather than the user.
Where are you finding that name constraints aren't supported? I've only come across that on embedded/IoT devices. They work fine for me across Firefox and Chrome on Linux, on Android, and they are supposed to work fine on Apple devices too.
> If I find that I want to use a specific website and want to do something with the traffic...
I agree but that's a different problem. If you just need a certificate for your router and some internal services (the original discussion), you can do that using an internal root CA and you have nothing to worry about as long as you using name constraints.
On IoT devices without nameConstraints support I just use an alternative CA certificate without name constraints (same key, different extensions).
Random anecdote: I have a device in which the http client can't handle https. Runs out of memory and crashes. Wasn't able to find a free host with a public http to host a proxy.
> Like, yeah, once the secure way is sufficiently easy to use, we can then push everyone off the insecure way; that's how it's supposed to work.
The problem is that this requires work and validation, which no beancounter ever plans for. And the underlings have to do the work, but don't get extra time, so it has to be crammed in, condensing the workday even more. For hobbyist projects it's even worse.
That is why people are so pissed, there is absolutely zero control over what the large browser manufacturers decide on a whim. It's one thing if banks or Facebook or other truly large entities get to do work... but personal blogs and the likes?
We've reached a point where securing your hobby projects essentially means setting the "use_letsencrypt = true" config option in your web server. I bet configuring it takes less time than you spent reading this HN thread.
And with regards to the beancounters: that is exactly why the browsers are pushing for it. Most companies aren't willing time and effort into proper certificate handling procedures. The only way to get them to secure their shit is by forcing them: do it properly, or your website will go offline. And as it turns out, security magically gets a lot more attention when ignoring it has a clear and direct real-world impact.
Cloudflare uses HTTP to connect to your website before caching the content. I’ve always found it highly insecure. You could have HTTPS with Letsencrypt, but you need to deactivate Cloudflare when you want to renew (or use the other validation that is complex enough that I didn’t succeed to do it).
Don't pick on this particular SSL requirement, pick on the deluge of requirements that only make sense for a site that sells something or handles personal data (i.e. has accounts). They get extended to $RANDOM_SITE that only serves static text and the occasional cat photo for no good reason except "your cats will be more secure!".
GP: At least on business plans this is incorrect, it defaults to (last time I checked) accepting any SSL certificate including self signed from edge to origin and it’s a low friction option to enforce either valid or provided CA/PubKey certs for the same path.
Parent: those innocuous cat photos are fine in the current political climate… “First they came for the cat pic viewers, but I did not speak up…”
How does SSL on a -ing public site protect you from being arrested by miniluv?
It’s public, you want everyone to see the cat photos, that’s why you set up the site. On the contrary, SSL certs mean another party through which miniluv can track you. They prove or are supposed to prove identity not hide it.
Sorry that wasn’t particularly clear, I was taking more about the general advantageous nature of normalising encryption.
WRT to another party to track you, one of the benefits of LE is that you only need to provide proof of domain ownership (eg dns txt) so the only tie back to you is whatever information you give to the registrar that you have to provide anyway.
The statement that Cloudflare uses HTTP to connect to your website can be false depending on how you configure it. For years, I have had personal websites with Cloudflare as the CDN and with Let’s Encrypt providing certificates on the web server. All I do is choose Full (Strict) in the TLS settings on Cloudflare. So the connection between the end user to Cloudflare and from Cloudflare to my web server are on HTTPS. No deactivation of Cloudflare required on my end during renewal (my web host, like many others, has the certificate generation automated and getting a TLS certificate just a toggle on my admin dashboard).
> That is why people are so pissed, there is absolutely zero control over what the large browser manufacturers decide on a whim. It's one thing if banks or Facebook or other truly large entities get to do work... but personal blogs and the likes?
Yep. There are plenty of things on the Internet for which TLS provides zero value. It is absolutely nonsensical to try to force them into using it, but the browser community is hell bent on making that bad decision. It is what it is.
I can understand this in in certain contexts, such as a site that exists solely to post public information of no value to an attacker.
A local volunteer group that posts their event schedule to the web were compelled to take on the burden of https just to keep their site from being labeled as a potential threat. They don't have an IT department. They aren't tech people. The change multiplied the hassles of maintaining their site. To them, it is all additional cost with no practical benefit over what they had before.
This is why more and more organizations get away with only having social media pages where they don't have to worry about security or other technical issues.
Unfortunately, placing the information on a social media page burdens the people seeking it with either submitting to the social media site's policies and practices, or else not having access to it. This is not a good substitute.
It also contributes to the centralization of the web, placing more information under the control of large gatekeepers, and as a side effect, giving those gatekeepers even more influence.
Most social media are free and easy to sign up for taking under a minute to do and have user bases that can be measured in the billions. Most people in the world are willing to follow the rules.
Most people don't use social media via the web. They use it via dedicated apps. I think it's natural that people who don't want to deal with the tech side of things will outsource it to someone else. The idea that everyone will host their own tech is unrealistic.
For now, in some jurisdictions, social media is "free" for your customers in the sense that it's supported by advertising.
It's not free for you of course because advertising isn't free and from their point of view what you'd be getting is free advertising so they want you to pay them to put it in front of your customers.
The work and technical expertise to setup let's encrypt is less than the work to register a domain, set up a web server, and configure DNS to point to it.
You seem to have missed what I wrote in the first place: They aren't tech people.
It is additional work, and requires additional knowledge.
It was also not available from most of the free web hosts that sites like these used before the https push. So investigating alternatives and migrating were required. In other words, still more work.
I only hear justified praises of letsencrypt. Also thanks to the EFF and developers of certbot, which massively improved the toolchain around certificate deployment. Not the favorite activity for admins, but this made processes like certificate renewal/revokation much more convenient.
I think the portion of users that check a certificate after the browser treated it as secure is well smaller than 1%, probably well below 0.1%. And I guess these TLS connoisseurs have a positive inclination to letsencrypt as well.
> The CEO at my last company (2022) refused to use Let's Encrypt because "it looked cheap to customers".
Spoken like a true dinosaur. How can a certificate based on open, public and proven secure protocols be cheap?
> So my question: has anyone actually commented to you in a negative way about using Let's Encrypt?
No, but I personally judge businesses which claim to be tech savvy if they don’t have an ACME issued certificate, because to me that instantly shows I’m not dealing with someone who has kept up with technology for the last 10 years.
Yeah you've correctly identified the mindset there that the leadership had in my case. They didn't want to upgrade to an in-support version of MySQL either...
I have also heard a negative about it being somehow "cheap" and we can "afford" a proper wildcard for our website from managers back in the day, like, few years ago. Never mind the hours wasted every year changing that certificate in every system out there and always forgetting a few.
Also a valid point from security people is that you leak your internal hostnames to certificate transparency lists once you get a cert for your "internal-service.example.com" and every bot in existence will know about it and try to poke it.
I solved these problems by just not working with people like that anymore and also getting a wildcard Let's Encrypt it certificate for every little service hosted - *.example.com and not thinking about something being on the list anymore.
There was a time when EV certificates were considered more trustworthy than DV certs. Browsers used to show an indication for EV certs.
Those days are long gone, and I'm not completely sure how I feel about it. I hated the EV renewal/rotation process, so definitely a win on the day-to-day scale, but I still feel like something was lost in the transition.
This was the only objection I had gotten about using letsencrypt 6 years ago but that guy is gone and now we either have letsencrypt or AWS certificates
I think I've seen one or two, and only because I noticed them as a weird callout in a $LARGE_FINANCE_INSTITUTION infosec bingo sheet. Of course I had to check that they really were running with OV certs.
Some of the outfits in that space will be heavily hit by the shortening certificate max-lifetimes, and I do hope that the insurance companies at some point also stop demanding a cert rotation before 90 days to expiry. It's a weird feeling to redline a corporate insurance policy when their standard requirements are 15 years out of date.
Before LE, we did lots of OV (which you generally could get a couple of for free from somewhere). We had to dig up stuff like a heating bill, because evidently that is proof of organizational control to some people.
Modern browsers are going out of their way to hide every bit of information about the website (including even the URL) — so I don't know how these customers would actually even find out what CA issued the certificate.
In Safari, I don't even know how to find that information anymore. When I want to check expiration dates for my own sites, I start Firefox.
It’s the symbol to the left of the URL > Show Certificate. They even make it available on iOS Safari (Page Info > Connection Security Details), but if it’s expired, you’ll know by the big red warning page.
I don't have that :-) — what I see when I click the thingamajig on the left side of the URL is a menu with "Hide Distracting Items", "Zoom", "Find" and "Website settings".
Well, either it isn't there in my Safari (macOS 15.7.2) or I can't find it.
I have found "Connection Security Details…" in the "Safari" menu, though. But my point still stands: average users won't see any certificate information without serious effort.
There are extended certificates that did matter in our sales process for some hosted solutions back about 15 years ago if I recall right… no one has ever cared since…
I used to deal with a couple people who were against any automatic or free certs. It was part of their jobs to procure the annual certs, look them over, present them to the developers and maintain automatic checks to regularly inspect the certificates. This was partly how they justified their jobs, but they relished the ceremony and being able to tell developers what to do, even if only for a few minutes a year. They repeatedly blocked introduction of LetsEncrypt.
Just checked. They’re still using that manually installed cert!
Many host providers (Those acquired by companies like Web.Com, allegedly) disable all ability to use outside certs since Google made encryption a requirement in Chrome Browser...
They do things like blocking containers & SSH to make installing free certs impossible.
They also have elevated the price of their own certs (that they can conveniently provide) to ridiculous prices in contrast to free certs their customers can't even use...
It would be a huge price-fixing scandal if Congress had any idea of how technology works.
Not only do they just allow you to import any certificate you want, but they literally have a button on the panel to get one from Let's Encrypt for free.
If you read into Web.Com, yes, they are quickly becoming a monopoly on host companies. They do not disclose many of the hosting companies they now own.
If you can find a company that allows clients to install Let's Encrypt Certs on shared hosting, please let me know.
Yeah, fair point. I have not used shared hosting for a long time now (static sites are easy/free to host, and dynamic ones don't play well with shared hosting), so I didn't know the Web.com story.
I used DreamHost in the past and they had a configuration option in their control panel to automatically install and maintain a Let's Encrypt certificate on your behalf [1]. If you are stuck with Web.com you may consider using a reverse proxy/CDN such as CloudFlare.
I will say, I have never before this season seen so many seemingly-legit fake web stores. All with their little lock icons in the address bar. I assume LLMs helped kick it into overdrive too
Conflating transport-layer encryption with authenticity is the problem. The former should always be standard, the latter is unrelated and IMO needs a different mechanism.
Absent widespread adoption of DNSSEC, which has just not happened at all, I don't see any alternative.
The authentication must be done before the encryption parameters are negotiated, in order to protect against man-in-the-middle attacks. There must be some continuity between the two as well, since the authenticated party (both parties can be authenticated, but only one has to be) must digitally sign its parameters.
Any competing authentication scheme would therefore have to operate at a lower layer with even more fundamental infrastructure, and the only thing we've really got that fits the bill is DNS.
This applies to grandparent too (for the record I largely agree with them) but the issue isn't just "authenticity" but "identification" -- there's no real attestation about who is in on the other end of the site. This identity was once at least somewhat part of the certificate itself.
Yes, it is fair to say that domain names are not the sum total of identity. However, the EV certificate experience showed that, at least in terms of WebPKI and the open Internet, there really isn't anything better than domains yet.
We have clear and seemingly easy go-to examples like proving that yes, this is THE Microsoft, and not a shady fly-by-night spoof in a non-extradition territory, but apart from the headline companies--who as of late seem to like changing their names anyway--this actually isn't easy at all.
Walled gardens like app stores have different trade-offs, admittedly.
The only pain point I had using letsencrypt, and it wasn 100% not their fault, was I tried using it to generate the certificate to use with FTPS authentication with a vendor. Since LE expires every 90 days and the vendor emails you every week when you’re 2 months from expiring, that became a pain point and it wasn’t easier to just by a 1 or 2 year cert from godaddy. Thank goodness that vendor moved to sftp with key authentication so none of that is needed anymore
has anyone actually commented to you in a negative way about using Let's Encrypt? I couldn't imagine, but curious on others' experiences.
One thing I heard recently which might be a valid point - that LE is based in US, which makes it a subject to US laws. Read from that what you will though.
No matter where they were based they would be subject to US laws since they offer services to US peoples. (similar to how everyone here always points out that US companies are subject to EU laws if they offer services in the EU).
Why is that problematic? They don't have your private keys and their "level of access" is equivalent to any other certificate authority that your browser trusts.
> Why is that problematic? They don't have your private keys and their "level of access" is equivalent to any other certificate authority that your browser trusts.
Let's Encrypt could stop issuing certificates to you, if the administration decided that necessary. This would at least disrupt whatever you were serving.
Not that I think this is likely, only possible.
I think LE clealy demonstrated the need for a accessible free ACME authority. But it is high time for more alternatives (EU and China at least).
FWIW: Everything around public infrastructure should be run decentralized not-for-profit using national resources. Things like DNS Registrars are silly if you think about it. They just buy it from TLD holders anyway.
Seconding the effect of Let's Encrypt on the world of TLS. I remember getting into web applications in the late 2000s and rolling my own certificates/CA and it was a huge, brittle pain. Now it's just another deployment checkbox thanks to LE.
> It coming from GoDaddy is not a selling point...
I just people who use GoDaddy. They were the one company supporting SOPA when the entire rest of the internet was opposed to SOPA. It's very obvious GoDaddy is run by "business-bros" and not hackers or tech bros.
> has anyone actually commented to you in a negative way about using Let's Encrypt?
A friend of mine has had a negative experience insofar as they are working for a small company, using maybe only 15–20 certs and one day they started getting hounded by Let's Encrypt multiple times on the email address they used for ACME registration.
Let's Encrcypt were chasing donations and were promptly told where to stick it with their unsolicited communications. Let's Encrypt also did zero research about who they were targetting, i.e. trying to get a small company to shell out $50k as a "donation".
My friend was of the opinion is that if you're going to charge, then charge, but don't offer it for free and then go looking for payment via the backdoor.
In a business environment getting a donation approved is almost always an entirely different process, involving completely different people in the company, than getting a product or service purchase approved. Even more so if, like Let's Encrypt, you are turning up on the doorstep asking for $50k a pop.
It's not something to stop using them over, but unsolicited solicitation emails are annoying at the least. It's definitely worth mentioning letting other people know they have warts too
>one day they started getting hounded by Let's Encrypt multiple times
>trying to get a small company to shell out $50k as a "donation".
>Even more so if, like Let's Encrypt, you are turning up on the doorstep asking for $50k a pop.
Does your friend have anything to corroborate this claim? Perhaps the email with identifying details censored?
I have a received an occasional email mentioning donations. They are extremely infrequent and never ask me for a specific amount. I would be incredibly surprised to see evidence of "hounding" and requests for $50,000.
All the usual phishing checks were done if that's what you're thinking.
In terms of the actual mail with identifying details removed, I'd have to go back and ask.
I did look before posting here as I thought they had already forwarded it to me, but it was last year, so I have almost certainly cleaned up my Inbox since. I'm not an Inbox hoarder.
> or just a "can you quickly make this boring func here that does xyz" "also add this" or for bash scripts etc.
I still write most of the interesting code myself, but when it comes to boring, tedious work (that's usually fairly repetitive, but can't be well abstracted any more), that's when I've found gen AI to be a huge win.
It's not 10x, because a lot of the time, I'm still writing code normally. For very specific, boring things (that also are usually my least favorite parts of code to write), it's fantastic and it really is a 10x. If you amortize that 10x over all the time, it's more like a 1.5x to 3x in my experience, but it saves my sanity.
Things like implementing very boring CRUD endpoints that have enough custom logic that I can't use a good abstraction and writing the associated tests.
I would dread doing work like that because it was just so mind numbing. Now, I've written a bunch of Cursor rules (that was actually pretty fun) so I can now drop in a Linear ticket description and have it get somewhere around 95% done all at once.
Now, if I'm writing something that is interesting, I probably want to work on it myself purely because it's fun, but also because the LLM may suck at it (although they're getting pretty damn good).
And I love it! The ocr/vision models are a literal life saver here. Translating websites in Safari? Even text in images gets translated, super convenient! The only gripe i have is that it tries to be smart and tries to detect addresses, phone numbers. If the address or phone number is part of a text it is nearly impossible to copy the whole text since the phone number gets prioritised over the text (so you can only copy or call the number… )
A small nitpick: the translation and data detectors pre-date Apple Intelligence.
I do indeed love these features. They have definitely had some regressions in the data detectors over the past few years. I assume that they only test these automatically in “ideal” contexts that don’t account for real life. Not sure. They used to be more reliable.
They absolutely are. And you can turn them off. My comment is more about the technology industry’s general insistence on shoving AI down your throat whether or not it’s useful, usable, or desired.
I’m hopeful that whatever combination of factors at Apple prevent that from happening remain. Otherwise I’ll have to start considering GrapheneOS and defaulting to my Debian-based MacBook.
No hate because this can't just run out of your pocket forever - it was generous of you to do it at all. That said, the text on the welcome screen is just wrong in that case.
Used his book to learn networking in the late 10s! It's a timeless book at this point. Using the C/Unix socket APIs as the foundation is fantastic. He dives into code and actual network function so well for such a quick read.
I'd be interested in a way to handle large swaths of simple tooling calling for LLMs (Anthropic recently had something about this, not sure if it would apply) so that they can know to _never_ attempt math, because that's not what they're for. Giving it a bunch of tools for things like arithmetic, date math, and other Wolfram style queries and making sure they always lean on those when appropriate would be fantastic.
reply