No, it was more broad than just SE domains, but trying to detect whether a site is suitable for passkeys support automatically is quite the challenge. Some don't allow themselves to be crawled so require manual verification.
HN user
Scott_Helme_
Security Researcher, Entrepreneur and International Speaker.
Find me at:
https://scotthelme.co.uk https://report-uri.com
I'm not entirely sure that it does, which bit of passkeys are you concerned most with?
This is fixed now: https://whynopasskeys.com/country/se
Interesting, could you link me to some of those sites so I can investigate?
I can kind of see it, but you can also just use an authenticator from any manufacturer, or have multiple types that you use? I'm just curious what I'm overlooking.
What's the concern with using passkeys?
I did try to make it clear in the article.
We're powering 2 x EVs, have two adults working from home full time, I have a server rack under the stairs, and we have a hot tub outside.
Absolutely — tariff choice, storage, and automation make a huge difference.
The article isn’t claiming this setup is universally optimal, just showing what’s possible when those pieces are combined and used deliberately.
We had an expensive solar install due to restrictions around our roof, so the solar would typically have been cheaper.
Another consideration is that battery installations in the UK are charged at 20% VAT, but if they're installed as part of a solar installation, they're charged at 0% VAT. So even if your main interest is in getting the batteries, a small solar install might make sense because of the savings.
The only restriction placed on you is the export rate, which is provided to you by the DNO here in the UK. We had a limit of 3.8kW placed, which is programmed in to the batteries by the installer.
Octopus also have more flexible battery export tariffs if you want to explore those: https://octopus.energy/smart/flux/
Nah, there's no Bitcoin mining, honest!
How did you know about my laser?!
Thanks! Sometimes the simple tricks are the best ones :)
There is no reason to differentiate between free certificates and paid certificates. The process works in exactly the same way for either.
They're all 3 certificates long (leaf/intermediate/root) apart from Let's Encrypt which, due to their cross-signature, are 4 certificates long for ECC.
If you were to use the same private key for the 4 certificates then you could seamlessly switch between whichever leaf certificate you wanted to serve to the client. I'm not aware of the ability to send multiple leaf certificates to a client for consideration though.
Let's Encrypt can issue from an ECC chain, I've tweeted[1] the details on how to enable your account for that.
[1] https://twitter.com/Scott_Helme/status/1392101598852222976
If you get a 1 year certificate then yeah, but otherwise no. The requirement to re-validate the DNS record comes not from the CA or the use of ACME, but the Baseline Requirements[1] §4.2.1, to prove you are still in control of the domain on a somewhat regular basis to obtain new certificates. Every 3 months is more frequent than is required, but there is still a regular (398 day) DCV requirement.
[1] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-...
That's not what I asked, that's a straw man.
Browser vendors have tested the efficacy of the current EV indicator, resulting in the current action.
If you feel that testing an alternative indicator consistent with other platforms is a good idea, then perhaps that's where the CAs should start their research.
But, didn't browser vendors do that and that's why the EV indicator is being moved to a less prominent location?..
As the organisations that stand to benefit financially from selling these indicators, perhaps it's CAs that should invest in the research? CAs seem to constantly point at the browsers as the party responsible for doing that research, but I don't see why.
The only way you could do that is on a hosted platform where they do maintenance for you. There's no way a server would last online for decades without being patched, it would have been hosed countless times over by now.
Installing certs is just as regular as installing patches, do it every 6 months if you like, but certainly not every 10+ years!!
I expected less to be honest. The adult entertainment industry has been on a huge drive to encryption recently. It makes sense if you think about the content they serve, I guess people want more privacy there!
I'd really recommend watching the video in this blog post: https://www.troyhunt.com/heres-why-your-static-website-needs...
My guess would be that maybe sites have different infrastructure in different regions and maybe they aren't completely aligned on their progress. I really don't know why you'd intentionally have it like that.
It might also be useful to note I have a HSTS Cheat Sheet for more info: https://scotthelme.co.uk/hsts-cheat-sheet/
"Please put yourself in the shoes of someone actually operating a site." - I run 8 sites right now and one of them is processing 10,000,000,000+ requests a month. I speak from a position of experience on this topic.
"Every single issue mentioned in that post only affects end-users. Not a single issue for the operator" - so don't care about the user and the risks we expose them to, only ourselves? This isn't really an approach I'm happy taking.
Which is insanely difficult to do at scale and would take a considerable amount of time and resources. Not to mention being really obvious! I'm happy with making things crazy hard for the bad actors out there.
Have a look at this post: https://www.troyhunt.com/heres-why-your-static-website-needs...
Our accuracy rate is currently around 99.6% so we're doing pretty well but of course I don't think it can ever be 100% either.
The biggest thing we've come across so far is geo-sensitive handling of requests. Some sites will redirect you to HTTPS or not based on where you are making the request from! This of course means you might see HTTPS and we see HTTP.
I think it's still fair to include those sites in this case because they aren't serving all traffic securely.