Earlier quoted context omitted.
If you can upload a custom file to a domain/subdomain, bluesky social (Jack Dorsey's new twitter) uses it to verify you are the owner of the domain. Chaz uploaded his custom file to their Amazon s3 bucket and now since he was the first one to do it, his account is now associated with Amazon S3.
>Chaz uploaded his custom file to their Amazon s3 bucket their is who exactly? and why does bsky associate it with the s3 domain if it's just a file in a random bucket?
So this guy is now S3. All of S3
241–250 of 522 posts
Re: So this guy is now S3. All of S3
#242Earlier quoted context omitted.
[flagged]
To be fair, each of those is returning 429 at the time of this post.
Re: So this guy is now S3. All of S3
#243Earlier quoted context omitted.
I don't get http-based verification in general. If you want to really prove someone owns a domain, make them change an authoritative DNS record. Everything else feels like it is begging for edge cases to crop up. Why should my social media or SSL certificate vendor care about my web servers?
I think people don't want to put DNS admin credentials in places where they might get leaked. Would be cool if a DNS server or provider offered credentials that could only do ACME challenges and not change any other records.
There's nothing preventing you from making the DNS record a CNAME to something under a zone that you're allowed to modify.
This is how one of my setups works; _acme-challenge.someservice.example.net is a CNAME to someservice.acme.example.net, and acme.example.net is served by a bind9 that allows dynamic zone updates based on TSIG-signed DNS update requests over WireGuard.
So the machine that hosts someservice has a DDNS key that signs DNS update requests for someservice.acme.example.net, and bind9 is configured to allow that key to change that record.
Re: So this guy is now S3. All of S3
#244Earlier quoted context omitted.
I worked on a product that required DNS changes to set up. Especially for business accounts, the level of friction was STUNNING. We had it take months to get set up because the contact had to submit a ticket to IT, write up the business justification, get director level approval, get security approval, and so on before it could get done. We had customers who couldn't even figure out which group in their company manag…
Especially for business accounts, the level of friction was STUNNING. Honestly, that's a feature, not a bug.
Re: So this guy is now S3. All of S3
#245Earlier quoted context omitted.
The /.well-known/ path prefix is the standard name to use ( https://www.rfc-editor.org/rfc/rfc8615 ) so that any sort of “we’ll host user content from our domain” thing can block it. (Hosting user content from the user’s domain is fine and doesn’t need this restriction.) A few things are effectively grandfathered in due to their vintage: /favicon.ico, /sitemap.xml and /robots.txt are the three that occur to me—so if…
I learned something new today. I guess .well-known's purpose isn't well known!
You'd hope that people doing job X would seek at least some insight into whether there are best practices for doing X, even if it's not a regulated job where you're required by law to have proper training. Not so much unfortunately.
Example: Many years ago now, early CA/B Forum rules allowed CAs to issue certificates for DNS names under TLDs which don't exist on the Internet. So e.g. back then you could buy a cert for some.random.nonsense and that was somehow OK, and people actually paid for that. It's worthless obviously, nobody owns these names, but until it was outlawed they found customers. But, even though the list of TLDs is obviously public information, some CAs actually didn't know which ones existed. As a result some companies were able to tell a real public CA, "Oh we use .int for our internal services, so just give us a certificate for like www.corp-name.int" and that worked. The CAs somehow didn't realise .int exists, it's for International Organisations, like ISO or the UN, and so they issued these garbage certificates.
[Today the rules require that publicly trusted CAs issue only for names which do exist on the public Internet, or which if they did exist would be yours, and only after seeing suitable Proof of Control over the name(s) on the certificate.]
Re: So this guy is now S3. All of S3
#246Earlier quoted context omitted.
They can and probably should but what if they decide not to? That's the problem with expecting people to agree with and follow standards.
If they decide not to, then they get all the capabilities, responsibilities, and level of participation that come with not following a standard that others are expecting. You've effectively described what happens when people don't agree.
https://wiki.archlinux.org/title/XDG_Base_Directory
I support both well-known and XDG because I think the benefit outweighs that perhaps they could have been designed better. But I don't think that those who opt out of it could only be doing so out of ignorance.
Re: So this guy is now S3. All of S3
#247Re: So this guy is now S3. All of S3
#248Earlier quoted context omitted.
[flagged]
Okay, I guess I'm not getting it either, but how is it federated/decentralized if they all redirect to the original server which throws a 429?
Re: So this guy is now S3. All of S3
#249Re: So this guy is now S3. All of S3
#250Earlier quoted context omitted.
[flagged]
Okay, I guess I'm not getting it either, but how is it federated/decentralized if they all redirect to the original server which throws a 429?
To understand how it's decentralized, search for @jonty@chaos.social on your own fediverse home server and the post will pop up.
There's a particular user story here which is a bunch of people who don't have accounts on any server, wanting to see the content from a central location (chaos.social). I do think it's worth talking about this story and ways to fix it but it's not really accurate to blame it on the federation behavior.