Live data from Hacker News

So this guy is now S3. All of S3

chaos.social

241–250 of 522 posts

Re: So this guy is now S3. All of S3

#241
post #200

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?

That's the whole point. Chaz uploaded the file to his own s3 bucket. He is one of thousands (millions?) of people who could have done the same thing with their own s3 bucket. He was the first.

Re: So this guy is now S3. All of S3

#242
post #134

Earlier quoted context omitted.

[flagged]

To be fair, each of those is returning 429 at the time of this post.

Translating, I that's only the experience for "non logged in users". Mastodon isn't meant to handle load from the the anonymous public, it's meant for a federation of servers.

Re: So this guy is now S3. All of S3

#243
post #47

Earlier 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.

> Would be cool if a DNS server or provider offered credentials that could only do ACME challenges

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

#244

Earlier 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.

Not in an economy that demands rapid, scalable, and infinite growth.

Re: So this guy is now S3. All of S3

#245

Earlier 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!

The most important people to know about this stuff are the people for whom it's effectively part of how to do their job correctly. I know what it means if there's a flashing single amber light on a railway signal in my country, but it's not important that you know, and wouldn't be important if I'm wrong, however it's very important that the train driver knows what it means.

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

#246

Earlier 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.

There's already a strong precedent for something like .well-known being disregarded — the ~/.config directory. It's the same idea, a special directory starting with a dot, and the objection seems to be similar, that it's awkward. In the case of the config directory it's that the storage for an app is spread between multiple directories like ~/.local/share and ~/.cache instead of one directory like ~/.vim

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

#248
post #134

Earlier 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?

They redirect you if you aren't logged in so you can't use them as an anonymous proxy. If you're logged in on your homeserver, you'll get that server's view of the post.

Re: So this guy is now S3. All of S3

#250
post #134

Earlier 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?

The federation occurred when the post was made, it was sent out to other servers and stored there. Then it got served to those users directly, without further contacting chaos.social.

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.

Post reply on HN