[HN Gopher] So this guy is now S3. All of S3
___________________________________________________________________
So this guy is now S3. All of S3
Author : aendruk
Score : 364 points
Date : 2023-05-04 18:54 UTC (4 hours ago)
(HTM) web link (chaos.social)
(TXT) w3m dump (chaos.social)
| [deleted]
| jacooper wrote:
| 429 too many requests
| arianvanp wrote:
| This is why mastodon , webfinger and ACME uss .well-known uri
| prefix. .well-known is reserved and you can't e.g. make a bucket
| named .well-known
|
| It's funny the bluesky devs say they implemented "something like
| webfinger" but left out the only important part of webfinger that
| protects against these attacks in the first place. Weird
| oversight and something something don't come up with your own
| standards
| benatkin wrote:
| .well-known seems unintuitive
|
| Also the penalty isn't very high here. Someone impersonated a
| domain on a burgeoning protocol for a short while. So what?
| ceejayoz wrote:
| > .well-known seems unintuitive
|
| We're talking about folks setting up a custom domain for a
| personal social media presence. If they can handle
| nameservers and DNS records, they can handle a folder with a
| dot in the name.
| catchnear4321 wrote:
| but it disappears when you add the dot.
| benatkin wrote:
| 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.
| thwarted wrote:
| 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.
| jascination wrote:
| I use S3 for a simple app landing page and I use .well-known
| for deeplinks... Unless I'm misunderstanding your comment which
| I probably am.
| roblabla wrote:
| Yes, but you don't have access to s3.amazonaws.com/.well-
| known, only to yourdomain.s3.amazonaws.com/.well-known.
| bscphil wrote:
| > This is why mastodon , webfinger and ACME uss .well-known uri
| prefix
|
| This is not how Mastodon does verification (at least not the
| main method). Mastodon doesn't just link users -> domain. It
| can link user -> webpage, for example to link social profiles
| between sites.
|
| If you have a website with user generated content, and a user
| can set an arbitrary html attribute (rel="me") in a link
| pointing back to their profile, they can claim ownership of the
| page on Mastodon. Likewise, if they can set a link tag in the
| head element of the page for some reason.
|
| Presumably this is somewhat harder to exploit than a (new,
| poorly thought out) dependency on a static file under /xrpc,
| but Mastodon does introduce more authentication footguns for
| sites than just .well-known!
| https://docs.joinmastodon.org/user/profile/#verification
|
| Edit: authentication -> verification, since Mastodon
| distinguishes between the two (see below)
| madeofpalk wrote:
| Neither of these are 'authentication'
|
| You're thinking of how Mastodon does verified links. You
| could do something similar, provide a verified link on your
| profile to a file in an S3 bucket, but there's very utility
| (or risk) in that.
|
| Mastodon also allows you to be discoverable via a custom
| domain, using .well-known as parent mentioned
| https://docs.joinmastodon.org/spec/webfinger/
| https://www.hanselman.com/blog/use-your-own-user-domain-
| for-...
| bscphil wrote:
| I'm thinking, mainly, of how these features are exposed in
| the UI and how users experience it. What matters is that
| users take (rightly or wrongly) a verified profile link to
| mean "I control this webpage". So e.g. if you could verify
| a Twitter handle on Mastodon, it would mean "if you trust
| the identity of this Twitter handle, you should also trust
| the validity of this Mastodon user". That's extremely
| important to get right no matter what you call it.
|
| I'm not sure what Bluesky was _attempting_ to do here but
| what they achieved in practice was allowing a user to claim
| control of a domain by claiming control of a page. But if
| you allow user generated content on the home page of your
| site, there 's not a distinction (from a Mastodon user
| point of view) between the two. It's effectively the same
| problem if I can "verify" yourdomain.com on Mastodon - and
| my point is that you can do that without using .well-known.
| itslennysfault wrote:
| Nostr too
| Nick87633 wrote:
| What about serving the challenge file from the root or a near-
| root of the fully qualified url? Like
| www.domain.com/mastodon.txt or abc.freehost.com/mastodon.txt?
|
| Maybe I'm old but what are some popular use cases for
| webfinger? (I'm just learning about it now)
| tingletech wrote:
| .well-known is basically the same idea
| https://datatracker.ietf.org/doc/html/rfc5785
| ownagefool wrote:
| Or why not just serve it from www.domain.com/.well-known so
| we only have one thing to block. :p
| arianvanp wrote:
| That is basically the idea of .well-known
|
| Webfinger is when you want to multiplex multiple identities
| on a single domain
|
| E.g. https://example.com/.well-
| known/webfinger?resource=nick@exam...
|
| Will serve the challenge proving your handle is
| @nick@example.com
| chrismorgan wrote:
| 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 you're running something
| vaguely like S3, you'll want to make sure users can't create
| files at the top level of your domain matching at least those
| names.
|
| But nothing new should use anything other than /.well-known/
| for domain-scoped stuff, or else you run into exactly this
| problem.
| jrockway wrote:
| I learned something new today. I guess .well-known's
| purpose isn't well known!
| cesarb wrote:
| > 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 you're running
| something vaguely like S3, you'll want to make sure users
| can't create files at the top level of your domain matching
| at least those names.
|
| I also recall /crossdomain.xml as an important one;
| allowing users to create an arbitrary file matching that
| name could allow certain kinds of cross-site attacks
| against your site.
| ehPReth wrote:
| I _think_ crossdomain.xml died with Flash but I could be
| wrong, does anyone know?
| roblabla wrote:
| None of the standardized web technologies use
| crossdomain.xml, but I think Acrobat Reader still uses it
| for... stuff. And acrobat _still_ has a browser plugin,
| so I guess it 's still a potential vector for abuse.
| [deleted]
| bowmessage wrote:
| s3 supports my-bucket.s3-us-west-2.amazonaws.com style URLs
| as well
| sergiotapia wrote:
| Mastadon has no chance if every time something becomes a little
| bit viral it's instance dies over the traffic.
| rvz wrote:
| It really just can't scale. Unsurprisingly.
| ryeights wrote:
| Let's be honest... Mastodon was never going to make it outside
| niche technical circles, regardless of scaling. It's a fun
| project though.
| bombcar wrote:
| Mastodon is a bunch of individual instances of varying power
| but maybe they should build in something that detects load and
| archived itself and redirects to the archive.
| [deleted]
| BulgarianIdiot wrote:
| I see just error 429 can someone please explain?
| tech234a wrote:
| They switched it to make the page redirect to the Web Archive
| for now.
| justinc8687 wrote:
| https://archive.is/fM06z
| Nick87633 wrote:
| Seems like the crypto crowd is moving on to creating flaky
| decentralized twitter clones now
| ShamelessC wrote:
| Was just about to say, I thought this level of acronym-based
| gatekeeping was reserved for web5 shits.
| [deleted]
| mikeryan wrote:
| Bluesky was started within Twitter as a federated social
| protocol in 2019. Spun out in 2021 as a standalone company and
| it was also being used in the Crypto group at Twitter until
| Elon came in.
|
| I'm sure just because of its age and principals involved it's
| been heavily influenced by the crypto crowd.
|
| But suddenly, without anything else really stepping in to fill
| the void, it's the Twitter alternative of the day. Anyway not
| surprised to find some gotcha's like this all things
| considered.
| steveklabnik wrote:
| > I'm sure just because of its age and principals involved
| it's been heavily influenced by the crypto crowd.
|
| It builds off of several specifications that came from the
| crypto crowd. It does not use a proof of stake or proof of
| work blockchain, though, so depending on how you use the
| words "crypto" and "blockchain," it either is or is not those
| things.
| Nick87633 wrote:
| [flagged]
| ShamelessC wrote:
| It got hugged to death too. Icing on the cake.
| steveklabnik wrote:
| The link is to mastadon, not bluesky.
| bombcar wrote:
| Talking about a flaky twitter clone in another flaky
| twitter clone. It's inception!
| nkozyra wrote:
| Twitter's already flaky enough, these are just faithful
| Twitter clones.
| grrdotcloud wrote:
| Without understanding all the context, why not just serve files
| directly from your smartphone? You can approve your own contact
| list and share keys.
|
| Yes, of course bandwidth is a concern, but then again there
| should be our way to monetize, and that's entirely possible using
| direct payments which already exist.
|
| A little bit of cashing, CDN, and your phone as the initial file
| server. Tag a photo or video has shared.
|
| Really it's just an RSS feed and CDN.
| silisili wrote:
| I think this is not about using s3 to serve files, but someone
| having verified owning s3 on bsky by putting some challenge
| file in his bucket. My guess, also missing context.
| steveklabnik wrote:
| That is correct.
|
| 1. Bluesky allows you to use a domain as a handle by creating
| a TXT record on an _atproto subdomain of the domain you wish
| to use (see https://mxtoolbox.com/SuperTool.aspx?action=txt%3
| a_atproto.s... for mine)
|
| 2. You can _also_ serve up your DID by having the URL
| "https://<handle>/xprc/com.atproto.identity.resolveHandle"
| return the DID.
|
| 3. AWS buckets have the URL structure
| http://s3.amazonaws.com/[bucket_name]/
|
| 4. register "xrpc" as an S3 bucket, drop a file named
| "com.atproto.identity.resolveHandle" with the correct JSON in
| it
|
| 5. boom! your username can now be s3.amazonaws.com
|
| Hope that helps.
| justinsaccount wrote:
| Sounds like Bluesky screwed up by not implementing the
| https://publicsuffix.org/ list
| steveklabnik wrote:
| The root cause here IMHO is more subtle than that, but I
| do agree that implementing that at some point is probably
| a good idea.
| silisili wrote:
| Thanks for the explanation. Kinda surprised xrpc hadn't
| been registered as a bucket name long ago. Or maybe it was.
| schlarpc wrote:
| Just created it yesterday. I don't think there's as much
| incentive to squat on the S3 namespace like there is for
| domain names.
| Sohcahtoa82 wrote:
| Yeah, a bucket name isn't the face of your company.
|
| At a previous company I worked at, every bucket had the
| company name prefixed. Never had a problem with
| squatters.
|
| I wonder if Amazon actually has any policies to prevent
| squatting.
| anaganisk wrote:
| Like Pied Piper? If yes, there is an entire show on it.
| fuckyah wrote:
| [dead]
| quickthrower2 wrote:
| [flagged]
| pfraze wrote:
| bluesky dev here. whoops.
|
| as others mentioned, not a hard fix.
| medler wrote:
| What is the easy fix? Use the .well-known/ standard instead of
| the current mechanisms, and roll back verification for anyone
| who's already been verified with the flawed approach?
| mempko wrote:
| Is Bluesky trying to Microsoft (embrace, extend, extinguish)
| the fediverse? And also how long until Twitter 2.0 or X app
| uses AT to skirt any regulation or risk around moderation?
| steveklabnik wrote:
| (not paul)
|
| Given that the AT Protocol is not compatible with
| ActivityPub, I don't see how the first step, let alone the
| second or third, is an accurate description of the dynamics
| at play here.
|
| > And also how long until Twitter 2.0 or X app uses AT
|
| Ironically, pre elon-buys-twitter, it did in fact look like
| Twitter was going to end up implementing AT, if all went to
| plan. But then post acquisition, if anything, that looks
| _less_ likely.
| kodah wrote:
| Hilarious though! I'm guessing this is the kind of stuff the
| Beta was supposed to find. Any other cool/funny bugs y'all have
| found?
| pfraze wrote:
| I created a rich text system for posts to handle things like
| links and mentions with the eventual goal of it being the
| basis for all kinds of rich text (bolding, italics, spoiler
| tags, etc)
|
| the flexibility bit us on the butt. people started faking
| mentions via the APIs and one user figured out he could pack
| 1000 mentions into one "@everyone" and cause us all to get
| notified. pretty predictable in hindsight but I dropped the
| ball there
| jesprenj wrote:
| Any sufficiently complicated C or Fortran program contains
| an ad hoc, informally-specified, bug-ridden, slow
| implementation of half of Common Lisp.
|
| http://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule
| gowld wrote:
| Do you have a public test suite so we can see how solid your
| protocol is?
| [deleted]
| [deleted]
| jonty wrote:
| This is the second time one of my posts has caused issues for the
| chaos.social admins. I am so, so sorry.
|
| The hacker news DDOS is real.
|
| Previously: https://news.ycombinator.com/item?id=34691489
| BHSPitMonkey wrote:
| Sorry for what, offering a free lesson in cache optimization?
| :)
| JdeBP wrote:
| The interesting thing to consider is that someone who is
| popular to read may well be as much of a headache for the local
| sysop as someone who is a frequent target for attacks. How long
| until they have a 'bot that just 429s all of your posts on
| sight, do you think? (-:
| JdeBP wrote:
| On a more serious note: Given that many user communities in
| the FediVerse are people conscious of their privacy and of
| suffering pile-ons by large majorities of outsiders, I wonder
| how many more examples of this there will be before people
| start asking the developers for out-of-the-box defaults that
| simply blacklist all requests that come in with referrer
| headers containing news.ycombinator.com and other similar
| "Slashdotting" sites.
|
| It's not beyond the bounds of possibility. Compare
| https://github.com/mastodon/mastodon/issues/15431 .
| mal-2 wrote:
| Yeah that's kind of what I'm thinking, this is a specific
| use case that's not hugely important - people from outside
| the network trying to access a post but not having a home
| server to do so. I would love a world where HN can link to
| a `fedi://` URL that doesn't open on chaos.social at all,
| but on my server.
| scythmic_waves wrote:
| I have no idea what this means. Can someone explain?
| steveklabnik wrote:
| I did over here https://news.ycombinator.com/item?id=35820670
| m348e912 wrote:
| 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.
| ShadowBanThis01 wrote:
| It's ridiculous that this is not in the title.
| runnerup wrote:
| FWIW it seemed obvious to me. I think a minority of people
| who play in this space can't conceptualize others'
| understandable ignorance of the norms and axioms.
|
| https://xkcd.com/2501/
| olddustytrail wrote:
| You got all that from a "429 Too Many Requests". That's
| an impressive level of deduction Holmes!
| runnerup wrote:
| Hahahahah. Try https://media.discordapp.net/attachments/1
| 043284184698994700... to see what the conversation is
| about!
| mypalmike wrote:
| The title doesn't even mention bluesky, the all-important
| context here.
|
| *Edit: typo
| ranting-moth wrote:
| It's unfortunate that such a bright man has written such
| a comment.
| steveklabnik wrote:
| Hacker News discourages "editorializing" the title, which
| means there's incentive to repeat what's being linked to
| exactly.
|
| Most of the time, it's a good thing, but in cases like this
| is where this falls over.
|
| (You can also see this in the other direction parent
| comment, for what it's worth, "Jack Dorsey's New Twitter"
| isn't really accurate, as far as I'm concerned. It is more
| informative overall, though.)
| ShadowBanThis01 wrote:
| Describing or at least providing context is not
| editorializing. I don't know how this "discouragement" is
| phrased, but it should instead encourage (if not require)
| that titles mean something to a general audience (at
| least as represented by HN's users).
|
| I am routinely down-modded and even banned for merely
| asking for more-descriptive titles. It's anti-user, anti-
| community, anti-usefulness, and douchey.
|
| All we needed here was, at least, "Bluesky Social allows
| domain hijacking" or whatever it's actually doing (which
| I don't have a grasp of, even after following the cryptic
| link).
|
| Or even just "This guy is now all of S3 on Bluesky
| Social." But that wouldn't be as click-baity, would it?
| steveklabnik wrote:
| > Describing or at least providing context is not
| editorializing.
|
| Absolutely. I'm not saying that I think that the title
| here is good. Just that I understand why it ended up as
| the title.
|
| > I don't know how this "discouragement" is phrased,
|
| You can find the guidelines here:
| https://news.ycombinator.com/newsguidelines.html
|
| To quote the relevant part:
|
| > Otherwise please use the original title, unless it is
| misleading or linkbait; don't editorialize.
|
| That's it.
|
| > (which I don't have a grasp of, even after following
| the cryptic link)
|
| I described it over here, if you're still curious:
| https://news.ycombinator.com/item?id=35820670
| ta-run wrote:
| >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?
| m348e912 wrote:
| 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.
| Dalewyn wrote:
| I would argue this is worse (and more hilarious) than Musk
| buying and giving out checkmarks for people.
| paxys wrote:
| This is a terrible implementation of domain verification. dns-01
| and http-01 are more or less standardized at this point. Use
| them, and don't roll your own. Reference:
| https://letsencrypt.org/docs/challenge-types/.
| elliottinvent wrote:
| They definitely should have used HTTP-01 if they're doing
| verification on the web, but since this is about using a domain
| as identity this really belongs in DNS.
|
| The issue with DNS-01 (and HTTP-01 to a lesser extent) as
| someone else mentioned is that the user friction is really
| high.
|
| I've been working on a solution to this that I've been meaning
| to post to HN and this seems like as good an opportunity as any
| so here it is: [1]
|
| It's a method of storing a hashed (and optionally salted)
| verifiable identifier (think email or mobile) at a subdomain to
| prove authority for a domain.
|
| 1. https://www.domainverification.org
| steveklabnik wrote:
| > this really belongs in DNS.
|
| And the primary way of identifying yourself _is_ in fact DNS.
|
| > I've been working on a solution to this
|
| Your solution is almost identical to the BlueSky one: put a
| TXT record at _atproto.<domain> that resolves to a DID. The
| difference is that they mandate the DID spec and you do not.
| Which is totally fine! Just figured I'd let you know :)
| elliottinvent wrote:
| Thanks for taking a look and for your comment.
|
| Another key difference is that the _atproto TXT record is
| discoverable since it's always at _atproto. Whereas the
| "verifiable identifier" I use isn't discoverable because
| it's hashed and used as a dns label.
|
| The ultimate goal here would be for these records to be
| populated by domain registrars upon a domain being
| registered (with registrant's permission obviously).
|
| This could create a kind of fast lane for domain
| verification across providers like Google Ads, Facebook,
| Office365 and everyone else that requests DNS verification.
|
| The worst thing is that hundreds of providers request
| domain verification TXTs at the zone apex:
|
| dig target.com TXT
| bob1029 wrote:
| 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?
| ilyt wrote:
| DNS challenge is required for wildcards on LE at the very
| least.
|
| But the reason for HTTP is pretty simple - it's extremely
| easy to implement. You only need to tell your ops to redir a
| subdomain to your app and you're done, you don't need DNS
| with API that have narrow enough permission to allow that one
| team in whole company to generate ACME stuff; most providers
| ACLs on DNS end at "this client have acesss to that domain
| via API".
| zippergz wrote:
| 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 managed DNS. Yeah, you can argue that those companies
| are broken, but as an outsider I have no influence over that.
| The result was just that they couldn't use our product. On
| the flip side, we had consumer and small business customers
| who had purchased domains through simple webhosting things
| that didn't give them the required level of access to create
| a record (and/or they couldn't figure out how to do it). We
| eventually added an HTTP option and the success rate and time
| to success both improved hugely.
| reaperducer wrote:
| _Especially for business accounts, the level of friction
| was STUNNING._
|
| Honestly, that's a feature, not a bug.
| unethical_ban wrote:
| If you're suggesting it's good that a simple technical
| decision/review/implementation took months, you're wrong.
| CydeWeys wrote:
| Anything touching the DNS records for the root of your
| entire web presence is not simple and needs substantial
| review.
| unethical_ban wrote:
| Adding a new DNS record for a new, specific purpose is
| simple and low-impact, technically.
| UncleEntity wrote:
| ...which gets promptly forgotten about after it's initial
| use case and years later your user database gets sold on
| the internet.
|
| How many "low-impact" things have been compromised over
| the years, I wonder?
| throwaway60607 wrote:
| That's exactly why DNS verification is a overkill.
| belltaco wrote:
| For representing and verifying identity, it should need
| director level approval.
| unethical_ban wrote:
| Yes.
| iudqnolq wrote:
| That's an overly technical way of looking at things. This
| issue is a whoopsie, not a catastrophic failure at AWS.
| It doesn't actually represent identity that much because
| anything critical has humans in the loop. The bank won't
| accept this as proof of identity. NYT won't accept this
| as proof of identity: if this bluesky account confessed
| AWS murders puppies NYT would call somebody they know at
| Amazon to check.
|
| A company blog is a much bigger vulnerability when it
| comes to representing and verifying identity. Rather than
| let somebody fake identify to a computer system it allows
| faking identity to humans reading it. Yet I don't think
| most places require director signoff to post.
| masukomi wrote:
| > If you want to really prove someone owns a domain, make
| them change an authoritative DNS record.
|
| You're not wrong (ignoring how easy it is to hack DNS), but
| at the same time it's hard enough to get people to buy their
| own domain name, nevermind understand the system well enough
| to add a TXT record.
|
| It's a strategy that's fine to implement when your target
| audience is server admins. It's a terrible strategy when your
| target audience is everyday users who you hope own their own
| domain. Doubly so in a world where owning your own domain is
| so rare for individuals.
| NavinF wrote:
| Sure, adding a TXT record to verify domain ownership is
| fairly common and lots of tools still use it. But you either
| have to self host DNS (yet another container to maintain) or
| use your provider's API (yet another credential, yet another
| mailing list to subscribe to for inevitable breaking changes
| to the API).
|
| In contrast, HTTP based verification often has built-in
| support with your webserver (Caddy) or only requires copy-
| pasting a few lines to your docker compose file.
|
| There are edge cases, but they're also widely exploited so
| you won't run into them if you follow best practices.
| CameronNemo wrote:
| 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.
| yokem55 wrote:
| acme-dns[1] is probably what you might want if you are up
| for running your own bit of infra. Implements a simple rest
| api for changing the txt records for acme verifications and
| nothing more. It works nicely as a delegated nameserver.
|
| [1] https://github.com/joohoi/acme-dns
| gregmac wrote:
| HTTP-01 works really well for when you host a custom domain
| on a SaaS application. The domain ownership stays with the
| customer, and all they have to do is CNAME/ANAME to your
| server. No messing with DNS TXT or NS records, 3rd party DNS
| provider API keys, etc.
| throwawaaarrgh wrote:
| Both http and dns verification are stupid. Neither of them
| prove you own the domain.
|
| http verification proves you temporarily control IP space
| relative to a viewer. dns verification proves you temporarily
| control name resolution relative to a viewer.
|
| Both are trivially hacked, multiple ways. By the time someone
| finds out you did it ( _if_ they closely monitor CT logs,
| which nobody does) you 've already had hours, days, weeks to
| run a MITM on any domain you want. The attack only has to
| work once, on any of 130+ CAs.
|
| The solution is registrar-level proof. Cert request signed by
| the private key of the domain owner, sent to the registrar to
| verify, the registrar signs it if its true, it's sent to the
| CA who can see the registrar signed it. Now you know for a
| fact the domain owner asked for the cert. The only possible
| attack is to steal all three of the owner's private key, the
| registrar's private key, and a CA's private key.
|
| I have been shouting about this for 10 years, none of the
| industry incumbents care. The internet is run by morons.
| nijave wrote:
| Doesn't mandatory DNSSEC also fix this?
| justin_oaks wrote:
| I can get behind registrar-level proof. And I can see why
| it won't happen, and it isn't because it's a bad idea.
|
| One problem I see is the extra overhead for the registrars.
| Now they have one more thing to do: verify (sign)
| certificate requests. That extra work is probably enough to
| get registrars to push back against such a system.
|
| The registrar would be assuming some of the functions of a
| CA. This would make it easier for a single entity be both
| registrar and CA. That would threaten the business model
| CAs and thus they'd push back against such a system.
|
| If the CA were responsible for getting the registrar's
| verification for a certificate request then that'd add
| extra work for CAs, and thus the CAs would push back
| against it. If the domain owner was responsible for getting
| the registrar's verification for a certificate before
| submitting it to a CA, then the domain owners would be
| against it.
|
| And this is all assuming that people could agree on a
| common set of protocols or data formats for this new
| system.
| xp84 wrote:
| > extra overhead for the registrars. Now they have one
| more thing to do:
|
| I suppose I only take issue with "more" - as it stands
| don't registrars do effectively nothing today besides
| print money? It seems like the kind of business that
| doesn't require much that isn't already automated, and
| where the only reason I don't have a successful registrar
| business is that the contracts with whoever owns the
| actual TLDs are difficult to get. Perhaps they need to
| look out for DMCA letters? Idk maybe I'm way off, feel
| free to correct me if anyone knows it's a difficult job.
| brazzy wrote:
| > I have been shouting about this for 10 years, none of the
| industry incumbents care. The internet is run by morons.
|
| Or maybe, just maybe, hear me out on this... maybe your
| proposal is not as smart as you think it is.
|
| For one thing:
|
| > Cert request signed by the private key of the domain
| owner, sent to the registrar to verify, the registrar signs
| it if its true
|
| What exactly does the registrar verify, and how?
| mikea1 wrote:
| > ...dns verification proves you temporarily control name
| resolution relative to a viewer.
|
| > Both are trivially hacked, multiple ways.
|
| I'm genuinely curious how it is trivial to "control
| [authoritative] name resolution relative to a viewer".
| LawTalkingGuy wrote:
| It's not as much that it's trivial (but it seems like it
| always is because social engineering never stops working)
| but that once the attacker has authed they can generally
| delete whatever extra file or record they made and stay
| authed, potentially hiding the attack.
|
| Whereas, if that required a signature from a private key,
| with a counter or other log of use in the TPM, it'd be
| caught by an audit without having to notice the symptoms.
|
| I know that in security design that I've been involved
| with there's a lot more scrutiny given to each use of a
| privileged key than there is to making sure that all
| website logging lists each file in the directory at each
| request, or logging the full public state of your DNS
| every minute. Requiring a signed request makes the
| attacker come in through the front door.
| chrismorgan wrote:
| Convenience. DNS is routinely not automatable by API, or
| inconvenient to automate. HTTP, however, is normally easy to
| work with.
| AdamJacobMuller wrote:
| It's not even that it's not automatable, it's just that it
| follows a completely different control scheme and path than
| DNS.
|
| for 99.99% of cases when a domain is pointed at me and I
| want to serve an SSL certificate for it, I can answer an
| HTTP-01 challenge. Needing to orchestrate a DNS challenge
| will always be a more complicated external thing.
|
| HTTP challenge (and TLS-ALPN) are in-band, DNS is out-of-
| band.
| AdamJacobMuller wrote:
| It's not about proving ownership, if it was about proving
| ownership we would do this via something at the registrar
| level.
|
| It's about proving /control/. If a domain name is pointed to
| me (my IP/CNAME) I control it and it is reasonable to allow
| that person to issue an SSL certificate for a domain (or
| subdomain) under their control. If you, as the domain owner,
| want to restrict that, CAA exists as your tool to do so.
| [deleted]
| paxys wrote:
| If you control a domain's DNS entry but I can serve arbitrary
| content to users from its servers, who really owns the
| domain?
| retrocryptid wrote:
| Does anyone have a screenshot? I'm getting a 429.
| mjhea0 wrote:
| https://web.archive.org/web/20230504185520/https://chaos.soc...
| retrocryptid wrote:
| Thx. Also. Yikes!
| jwilk wrote:
| https://archive.is/fM06z
| xwdv wrote:
| [flagged]
| ldoughty wrote:
| It's not that hard to modify code.. and I'd argue it's new
| enough that people should expect growing pains if they want to
| be early adopters...
|
| "Death" of a product for one bug? ....
| xwdv wrote:
| This was a simple thing, the fact they got it so wrong only
| makes me wonder what other bad choices have been made.
| Matticus_Rex wrote:
| Have you... ever worked at a software startup?
| efitz wrote:
| If you want to prove domain ownership, you have to do it at the
| domain level.
|
| The ability to serve a file "www.example.com" in no way
| demonstrates ownership of "example.com"; it demonstrates that you
| control www.example.com.
|
| If you want to prove ownership of a second level domain you must
| do it through a record in DNS, or through demonstrating control
| of something that is publicly known to control the domain such as
| the administrative contact emails.
|
| This really is a solved problem in the PKI space; they should
| have borrowed that rather than invent their own.
| steveklabnik wrote:
| As said multiple times in this thread, the primary way of
| identifying yourself in this protocol _is_ a TXT record in DNS.
| JdeBP wrote:
| Things to learn about the FediVerse from the 429 error:
|
| * The FediVerse is lots of WWW sites. Some are WWW-hosting
| companies showing off, with all of the acoutrements of high-end
| WWW sites, including CloudFlare protection and lots of tweaking
| of the back end stuff. Others are one-person sites where someone
| has just set up the vanilla
| Mastodon/Pleroma/Pixelfed/Friendica/whatever software on a cheap
| hosted VM somewhere. There are lots of in-betweens. I have an
| account on two sites, at each of the aforementioned extremes, one
| with well over 20,000 users and the other with around 40.
|
| * It's really easy to deny service to the one-person sites, and
| many of the low-end ones.
|
| * Chaos.Social's about page explains that it's a couple of people
| running a WWW site in their spare time on spare hardware. That's
| a _little_ misleading, as they 've upgraded the hardware a bit.
| But it's still 2 people, with ~5800 users. For more, start at
| https://meta.chaos.social/resources .
|
| * There's nothing global in the FediVerse. Nothing gets sent
| everywhere. _Some_ commenters here can see the post cached by
| their local WWW sites where they have accounts. But I 'm in the
| opposite situation: _None_ of the places where I have accounts
| have cached that post, and since the Chaos.Social sysop put the
| 429 error in place to combat the server overloading, they
| actually _cannot_ pull that post with just its URL entered
| directly, although simple tricks like searching for
| @jonty@Chaos.Social instead and reading the user timeline work
| just fine.
|
| * There's nothing global in the FediVerse. Using the
| aforementioned trick, I see a different view of the thread from
| Mastodon.Scot to what I see from Toot.Wales, and both of those
| are different to what's seen from other places.
| jesprenj wrote:
| So server software is not written with high performance in
| mind?
|
| I've read somewhere that federation is done via regular HTTP
| requests which ends up really hogging down servers if someone
| has a lot of followers.
| afavour wrote:
| Mastodon is written in Ruby on Rails and there are some
| inherent performance issues with that, it generates a huge
| number of Sidekiq jobs that can bog down a server quite
| easily. There are other, non-Ruby implementations aiming for
| compatibility with the Mastodon API though, so I'm curious to
| see how it will all shake out.
| bee_rider wrote:
| Most of us are just browsing for interesting light reading
| anyway, so blocking us if they can't serve a Hackernews worth
| of users seems basically... like an appropriate amount of
| robustness, for light reading.
|
| Maybe the FediVerse is just not friendly to the idea of a
| "global top among thousands of users" rating.
| eqvinox wrote:
| Just FYI, that 429 was explicitly placed on the specific URL HN
| links to. The remainder of chaos.social is up and running
| perfectly fine.
|
| [Edit: already mentioned above, I just misread it.]
| JdeBP wrote:
| The aforementioned trick wouldn't work if it wasn't. But
| before the 429 error was put into place the entire site was
| affected across the board by Hacker News. See
| https://chaos.social/@ordnung/110312020977014678 .
| eqvinox wrote:
| Ah, yes, sorry, I misunderstood your comment. My bad.
| bradfitz wrote:
| Here's the original email where I proposed .well-known:
|
| https://mailarchive.ietf.org/arch/msg/apps-discuss/1_a06NU8z...
|
| > 1) I feel that /host-meta is too casual of a name and prone to
| collisions. It matches /^[\w\\-]+$/, which I think is a subset of
| a fair number of sites' usernames."
|
| ...
|
| > i.e. put something ugly and weird in there, like a semicolon,
| to minimize the chance that it interferes with people's existing
| URL structure.
| jmccarthy wrote:
| And later, how the semi became the dot:
| https://mailarchive.ietf.org/arch/msg/apps-discuss/j6KWTSTVC...
|
| Fun bit of history!
| sam_goody wrote:
| Am getting a 429 error. Can someone please fill me in on what was
| here?
| Pxtl wrote:
| I mean I think you could also do this on Mastodon but it would
| just show a "verified" highlight for amazon s3 in your profile,
| not that it would get verified as your username.
| daenney wrote:
| No, you can't. To own s3.amazon.com the HTML on that exact
| domain and not a sub path needs to have a specific link back to
| your profile on it.
| chrismorgan wrote:
| I don't know what specifically you're speaking of, but for the
| stuff I know of, Mastodon uses WebFinger, which puts the
| important stuff inside /.well-known/, and .well-known should be
| blacklisted as a "username" in any of these sorts of systems,
| for this very reason. (https://www.rfc-editor.org/rfc/rfc8615
| specifies the /.well-known/ path prefix.)
| Pirate-of-SV wrote:
| Any domain on the public suffix list should just be ignored I
| suppose. https://publicsuffix.org/list/
| pornel wrote:
| It'd be nice as an extra precaution, but please don't build
| things that rely on the Public Suffix List for security (this
| list by its nature is only a laggy incomplete approximation of
| the actual use of domains).
| Drblessing wrote:
| Kiss of death
| tech234a wrote:
| They switched it to make the page redirect to the Web Archive
| for now.
| elijahbenizzy wrote:
| OK, this is a very cool method of verification for a social
| network but they goofed. Everyone goofs. In this thread folks
| being like "this is a bunch of jokers", yeah, I think they
| learned their lesson about rolling their own domain verification
| and everyone had some fun.
| verdverm wrote:
| It's not just this incident, like not reading your own ToS to
| know what is in there, they seem to be sloppy
| sn_master wrote:
| Isn't this how over a decade ago people "hacked" Google by
| hosting a similar file on google sites/blogs when that was a
| thing? How's anyone still using this method for verification in
| this day and age :/
| NavinF wrote:
| > 429 Too Many Requests
|
| Aight, level with me: Is every mastodon server running on a
| Raspberry Pi?
| i-am-gizm0 wrote:
| Looks like we hugged it to death
| colpabar wrote:
| Sites like HN and that other one should track this. It could
| work like flagging - if enough people mark it as hugged to
| death (HTD), it would say so next to the link. Maybe it could
| even redirect to an archive if it's currently HTD.
| yieldcrv wrote:
| lightly blew in its general direction to death
| neogodless wrote:
| No trouble viewing it from another Mastodon server:
|
| https://hachyderm.io/@jonty@chaos.social/110307532115312279
|
| EDIT: Ah I guess if you're not logged into a hachyderm.io
| account, you get forwarded. So probably don't use the above
| link.
| bombcar wrote:
| That just redirected me to too many requests.
| [deleted]
| jeroenhd wrote:
| The server itself seems to work fine. It only seems to be this
| specific post that's being 429'd. I'm guessing it's some kind
| of anti-DDoS setup kicking in.
|
| Mastodon is also quite heavy to host, my single user instance
| will easily gobble up several gigabytes of memory if you let
| it. There are more efficient ActivityPub servers but
| specifically Mastodon seems to be written for running
| efficiently on huge servers.
| tethys wrote:
| From the instance admins:
|
| > We just started serving a http 429 error on the exact url of
| the post. So everything should go back to normal now.
| vultour wrote:
| So to answer GP's question, yes.
| chrishas35 wrote:
| If you go to the user's profile and then to the post, it
| seems to be okay. So perhaps also looking at Referrer.
| None4U wrote:
| Doing such a thing never requests to the page that is
| linked, so it makes sense that nothing is blocking it
| rvz wrote:
| Just look at it failing the HN hug of death. If this one can't
| survive techies on a orange site rushing to the site then it
| cannot possibly survive a lotus of users from Twitter or TikTok
| rushing into any post on Mastodon, bringing it flat on to the
| floor.
|
| I can only see Mastodon centralizing to cope with the load. But
| a server going down on this load from HN tells us it is no
| where near ready to handle an insurmountable amount of users or
| even begin to challenge Twitter which hosts 220M+ users every
| single day.
| colonwqbang wrote:
| Twitter is pretty sluggish, to be fair. 7 seconds to load and
| render a single tweet on mobile.
|
| https://pagespeed.web.dev/analysis/https-twitter-com-
| realDon...
|
| Mastodon.social is actually much faster on this particular
| benchmark. So maybe there is hope.
| jeromegv wrote:
| Mastodon user count has mostly been a steady growth. So far
| it hasn't really failed at a high level. We aren't in Bitcoin
| territory, the network isn't really slower than it was a year
| ago even if number of user is much higher. It's mostly
| distributed among many instances.
| isclever wrote:
| Maybe, but the admin commented it was intentional for that
| specific post, it was slowing down the entire site.
| NavinF wrote:
| > slowing down the entire site
|
| This is mind-blowing. Last I checked, the front page of HN
| sends tens of requests per second to each link. There are
| humans who can pack envelopes faster than the typical
| mastodon server can answer GETs. I'd love to see someone
| benchmark the top servers for a few seconds to see what it
| takes to break a reasonable latency SLA.
| bombcar wrote:
| It has been 20+ years since slashdotting with the requisite
| hardware and connection upgrades and still things fall
| over.
| fafzv wrote:
| [flagged]
| crooked-v wrote:
| Clearly they're not microservicing hard enough.
| b33j0r wrote:
| I suggest making the current team explain to 4 new teams
| how to port it to something fast, like elixir and rust
| (both!)
|
| Probably messaging with pulsar and the build system from
| python 4, too.
|
| I read this in a whitepaper. Let's do this, guys! ;)
| [deleted]
| olliecornelia wrote:
| Aren't federated services grand?
| mal-2 wrote:
| Tell me you don't understand it without telling me...
|
| This message was federated to multiple servers efficiently
| and each of them is now serving it. What you're doing here is
| exactly _not_ a federated service.
|
| https://mastodon.social/@jonty@chaos.social/1103075321453803.
| ..
|
| https://mastodon.sdf.org/@jonty@chaos.social/110308018473644.
| ..
|
| https://universeodon.com/@jonty@chaos.social/110307532251412.
| ..
|
| It looks like these links auto-redirect when I access them
| from here, but when you access them from the homeserver they
| are served without redirect. The content is accessible
| everywhere in the network.
| benlivengood wrote:
| To be fair, each of those is returning 429 at the time of
| this post.
| [deleted]
| hgsgm wrote:
| 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.
| shawabawa3 wrote:
| > It looks like these links auto-redirect when I access
| them from here, but when you access them from the
| homeserver they are served without redirect
|
| "Works on my machine" isn't going to cut it for running a
| popular social network
|
| Nobodies going to go around searching for mirrors, they'll
| just leave and go back to twitter
| bee_rider wrote:
| They will just miss out on low-effort posts from sites
| with semi-technical populations, like this one. It isn't
| a big loss really.
| mal-2 wrote:
| HN always manages to be arrogantly incorrect, love to see
| it. It works on everyone's machine. We all saw this post
| yesterday, served from our home server.
| latency-guy2 wrote:
| I can't see it today. I won't remember about looking at
| your post tomorrow, but I will remember that your website
| didn't work for a few hours yesterday, so I probably will
| not visit again.
|
| I don't really care how you implement your fediserve
| gimmick, I haven't received it. Seems like lots of people
| will not receive it either.
| mal-2 wrote:
| Ok, suit yourself. I use it everyday without issue. This
| is one particular use case which is not the one users
| normally need - external visitors without a home server
| who want to see the content. If you had a home server you
| could find this trivially.
|
| The one big change that I would like to see is for fedi
| to have its own URL scheme, because this URL doesn't need
| to point at chaos.social at all. Then you could open it
| on your home server.
|
| If you just don't feel like signing up for a home server
| then it will always look clunky to you, oh well.
| vultour wrote:
| All of these redirect to web.archive.org. Are they using it
| to offload traffic? That doesn't seem very nice.
| mal-2 wrote:
| No, all of these redirect to the original server when
| viewed by not-logged-in users. The original server has
| chosen to redirect to web.archive.
| neogodless wrote:
| Found a similar situation, but I think the key is mostly if
| you're on one of those servers and seek out the content or
| if you're _logged into_ one of those servers, it won 't
| forward you (even if you click it from here, assuming same
| browser/container).
| deckard1 wrote:
| one alt-social crumbling from throwing rocks at another alt-
| social
|
| This is peak Web 5.0 right here.
| jaeh wrote:
| chaos.social is run by the chaos computer club, you can assume
| that they configured it that way on purpose.
|
| my profile, on the same server, loads fine.
| _emacsomancer_ wrote:
| for the time being, archive.org has a snapshot of it:
| https://web.archive.org/web/20230504185520/https://chaos.soc...
| jszymborski wrote:
| This post is on the front of HN. Many a larger website have
| succumbed to HN's warm embrace.
| yreg wrote:
| Isn't HN pretty small? This post has <400 upvotes over 3
| hours. There can't be 1000x that amount of lurkers can there?
| weglasern wrote:
| Not really: hhttps://leah.is/posts/scaling-the-mastodon/ They
| just got 6 times the normal requests:
| https://chaos.social/@ordnung/110312089838674624
| shawabawa3 wrote:
| unfortunately this is exactly why mastodon won't work
|
| I already don't trust mastodon links because 9 times out of
| 10 they simply don't work. Everyone's tiny hobby server falls
| over when one post gets big, and obviously not everyone is
| going to scale their servers to support the load of a viral
| post that might happen once every 6 months and will be 100x
| their base load
| neoromantique wrote:
| Mastodon is by design about small niche communities rather
| than centralised twitter alternative.
| rvz wrote:
| That is not the point.
|
| If someone sent any link or post that is from that
| Mastodon instance and it went viral, the entire instance
| will be sent to the ground and out for hours, making the
| post unavailable to be viewed.
|
| The worst part is journalists and the media have to be
| told that posting a link from a 'small niche community'
| on Mastodon will send a flood of traffic that will knock
| it down offline also giving the impression to others that
| it is not ready for mainstream at all or even ready to
| onboard on tens or hundreds of millions of users, daily
| like Twitter.
| phatfish wrote:
| That is the benefit of centralization, the experience for
| the end user can be controlled completely. Maybe a Mastodon
| friendly web cache that anyone running a semi-serious
| instance could easily opt into (for a fee) is needed. As a
| hedge to keep your Raspberry Pie instance online if
| something goes viral.
|
| As a community effort where no one is expecting to get rich
| it might work.
| datadeft wrote:
| Because it is webscale.
| popey wrote:
| You can also see the same "toot" as a "tweet":
| https://twitter.com/jonty/status/1653915932677271552
| sidmitra wrote:
| For those not getting the context(like me), this seems to be
| about the Bluesky Social(https://bsky.app/), a twitter
| alternative.
| pyentropy wrote:
| Further context: Bluesky lets you use a domain name you own as
| a user handle.
|
| The official method is to set a TXT record, but apparently
| their "AT protocol" also lets you confirm a domain by serving
| `GET
| your.domainname.com/xrpc/com.atproto.identity.resolveHandle`
|
| and `xrpc` was available as an S3 bucket name :)
| mwint wrote:
| Stunning that there are (were) any 4-char bucket names left.
| CydeWeys wrote:
| I guess I'm not too surprised in that, unlike domain names,
| these aren't obviously exposed to end users, so terseness
| doesn't particularly matter. Verbose and descriptive is
| honestly better for most names.
| mikepurvis wrote:
| And given that bucket names are a giant shared namespace,
| there's absolutely an incentive toward lots of prefixing
| to help ensure you get the ones you want.
| ec109685 wrote:
| Path based bucket addressing isn't supported anymore, so
| this must be a legacy bucket:
| https://aws.amazon.com/blogs/aws/amazon-s3-path-
| deprecation-...
| voxic11 wrote:
| Path style access is supported for new buckets, at least
| for now
|
| https://docs.aws.amazon.com/AmazonS3/latest/userguide/acc
| ess...
| steveklabnik wrote:
| The person who did it is in this thread, and apparently
| you are not correct. It was created yesterday:
| https://news.ycombinator.com/item?id=35821113
|
| (I don't know anything about this personally, but since a
| lot of people are indicating an interest in this detail
| of the story, figured I'd try and surface that link
| better!)
| electroly wrote:
| No, they indefinitely delayed that deprecation. It's
| still delayed. I bet[1] it never happens. They haven't
| figured out what to do with S3 VPC endpoints and buckets
| with dots in the name, which both to this day require
| path-based addressing and are both completely legitimate
| uses. They just stopped talking about this plan entirely
| and it's been years; I think it's dead.
|
| [1] If they ever actually turn off path-style addressing,
| come find me and I'll PayPal you a dollar. I don't think
| it'll ever happen.
| 88913527 wrote:
| N=1, but it appears users often create long and overly
| verbose bucket names.
| armchairhacker wrote:
| How does Bluesky compare to Mastodon? (Other than letting you
| register S3 as your user handle)
| steveklabnik wrote:
| Here's how I think about it:
|
| * ActivityPub -> AT Protocol (https://atproto.com/)
|
| * Mastadon -> Bluesky (https://blueskyweb.xyz/)
|
| Right now, federation is not turned on for the Bluesky
| instance.
|
| There are differences in both, however. I'm not going to
| speak about my impressions of the Mastadon vs Bluesky teams
| because frankly, Mastadon never really caught on with me, so
| they're probably biased. ('they' being my impressions, that
| is, I just realized that may be ambiguous.)
|
| At the protocol level, I haven't implemented ActivityPub in a
| decade, so I'm a bit behind developments there personally,
| but the mental model for AT Protocol is best analogized as
| git, honestly. Users have a PDS, a personal data server, that
| is identified by a domain, and signed. The location of the
| PDS does not have to match the domain, enabling you to do
| what you see here: a user with a domain as their handle, yet
| all the PDS data is stored on bluesky's servers. You can make
| a backup of your data at any time, and move your PDS
| somewhere else with ease (again, once federation is actually
| implemented, the path there is straightforward though). This
| is analogous to how you have a git repository locally, and on
| GitHub, and you point people at the GitHub, but say you
| decide you hate GitHub, and move to GitLab: you just upload
| your git repo there, and you're good. Same thing, except
| since identity is on your own domain, you don't even need to
| do a redirect, everything Just Works.
|
| This analogy is also fruitful for understanding current
| limitations: "delete a post" is kind of like "git revert"
| currently: that is, it's a logical deletion, not an actual
| deletion. Enabling that ("git rebase") is currently underway.
| Private messaging does not yet exist.
|
| Anyway if you want to know more the high-level aspects of the
| docs are very good. Like shockingly so.
| https://atproto.com/guides/overview They fall down a bit once
| you get into the details, but stuff is still changing and the
| team has 10,000 things to do, so it's understandable.
| givemeethekeys wrote:
| Sometimes it feels like companies fund weak competitors to
| discourage / drown out competition.
| [deleted]
| Ciantic wrote:
| Solution is also on the works like use /.well-known/, so this is
| more like funny, rather than a big problem.
|
| Key to trick was to have bucket named "xrpc" and store a file
| there:
| https://s3.amazonaws.com/xrpc/com.atproto.identity.resolveHa...
|
| There is also another funny thing in the image, the user posting
| about is sending one from "retr0-id.translate.goog", which is
| odd. Somehow he has got
| https://retr0-id.translate.goog/xrpc/com.atproto.identity.re...
| to redirect to his page, and gotten that handle as well.
| matoro wrote:
| Google Translate recently moved translated web pages to domains
| like this. If you plug a webpage into GT it will put the
| translated content under <domain>-<tld>.translate.goog. This
| user's actual domain is https://retr0.id
| chrismorgan wrote:
| Eh, it's worse than just funny; it's concerning, because they
| should have known about and easily avoided this kind of
| vulnerability, it's standard stuff you have to think about. So
| what else have they missed?
| steveklabnik wrote:
| This is a private beta. Nobody is suggesting that any of this
| be used for anything serious just yet. Development happens
| out in the open, you can go find out what else they've missed
| by doing the work, or by waiting until others you trust have
| done so.
|
| I myself have had an account for like a month now, but only
| started really using it a week ago, because that calculus
| changed for me, personally.
|
| Like, it's not even possible to truly delete posts at the
| moment. This all needs to be treated as a playground until
| things mature.
|
| This isn't even the first "scandal" related to this feature
| already!!!! There is another hole in what currently exists
| that allowed someone to temporarily impersonate a Japanese
| magazine a few weeks back.
| YtvwlD wrote:
| Okay, yes, but this indicates that they didn't read the
| ActivityPub before developing their own new shiny protocol.
| rchaud wrote:
| The pull of NIH is a strong one.
| steveklabnik wrote:
| I don't personally believe that one mistake indicates
| ignorance of an entire topic.
| seba_dos1 wrote:
| In general - no, but this kind of fundamental mistake
| might.
| steveklabnik wrote:
| I hope I never work on software you folks use. The grand
| claims about something that is not even hard to fix is
| just wild to me.
| seba_dos1 wrote:
| Being easy to fix is completely irrelevant. The thing is
| that it's easy to avoid. The only way to end up there is
| to not put any thought into the domain verification
| scheme before deploying it. Any kind of review would
| catch it. _That 's_ what makes it look really bad.
| [deleted]
| gowld wrote:
| What about the next 500 easy-to-fix bugs?
|
| Is there a public test suite?
| steveklabnik wrote:
| > Is there a public test suite?
|
| The entire specification (which is admittedly incomplete)
| and implementation are open source.
|
| I am not aware of a dedicated test suite for alternative
| implementations. It's too early, IMHO. I personally would
| much prefer the team to focus their time elsewhere for
| the time being.
| ShroudedNight wrote:
| My instincts may be way off-base, but if I was developing
| a protocol at the core of my product vision, even if
| there was only one implementation, I would a want an
| authoritative test suite. I wouldn't trust myself not to
| integrate load-bearing idiosyncrasies (and bugs,
| honestly) otherwise.
| steveklabnik wrote:
| I mean, I don't think you're incorrect, but I do think
| that like, semantics matters here. There is a test suite,
| of their implementation. Just because they have not
| extracted it and made it easily re-usable for alternative
| doesn't mean that they don't have checks to ensure
| regressions don't appear, you know?
|
| They already build off of many related specifications,
| which have independent implementations, and a lot of the
| core protocol is RPC style, with schemas that they do
| publish. So there's already a lot of rigidity here for
| alternative implementations to use in a way that is
| extremely likely to be compliant.
|
| I guess another way of putting it is "I don't exactly
| disagree with you but doing that takes work, and we're at
| the stage of this stuff where that work is being done, so
| expecting it right now feels premature to me." The spec
| isn't "released" or "done," it's in development.
| 9dev wrote:
| Dunno. That's such a fundamental piece of thinking you just
| have to come across in the design phase, I don't know how
| you would build a beta that didn't avoid the issue in the
| first place unless you had a flawed take on security in the
| first place.
| steveklabnik wrote:
| It is surely easy to cast stones at a single bug, but I
| don't think that's the right way to look at things.
| 9dev wrote:
| I wouldn't have made my remark if this would just be a
| bug, though. We're looking at a bespoke domain ownership
| verification mechanism that doesn't handle its primary
| usecase well, failing at something solved in lots of
| different ways over the past _decades_.
|
| I have written atrocious bugs over the years, so I'm
| definitely not in the stone casting business here.
| However, I can't see this as simply a bug, rather than a
| fundamental design flaw. And if an entity is both
| becoming infamous for reinventing the wheel, _and_
| attempting to fill a sensitive niche, I feel it has
| somewhat of an obligation to accept criticism such as
| that.
| steveklabnik wrote:
| > We're looking at a bespoke domain ownership
| verification mechanism that doesn't handle its primary
| usecase well
|
| Okay this is exactly what I mean. How well do you know
| the AT Protocol? Because this comment seems to indicate
| you just learned about it from this link, yet you're
| still making grand claims like this.
|
| This method of validating your identity isn't the primary
| one. It's not even documented! It was added two weeks
| ago, as an API endpoint to help serve moderation and
| administrative needs. Turns out the URL structure of the
| rest of the API is a bad call for this endpoint.
|
| > and attempting to fill a sensitive niche,
|
| If you want to criticize AT Protocol on privacy issues,
| there are far more important things that _are_ closer to
| the fundamental aspect of the design to criticize.
| bisby wrote:
| "We'll build our own validation instead of using one of
| the existing standards that make perfect sense." is not
| just "a single bug". It's a flaw in architecture.
|
| A PR of "Change external domain validation to use .well-
| known (or DNS01, etc)" is not a "bugfix"
| mtae wrote:
| okay so clearly you don't know what you're talking about
| because they do use existing standards/DNS as the primary
| way to validate domain ownership. It's free to not say
| anything and read the comments first before going off
| about something!
| i_am_jl wrote:
| >okay so clearly you don't know what you're talking about
| because they do use existing standards/DNS as the primary
| way to validate domain ownership.
|
| I'm not going to speak for the commenter you're replying
| to, but I don't think anyone here is talking about the
| standards-compliant, DNS-based domain verification
| system. I think we're all talking about the non-
| standards-compliant, /xrpc/-path verification.
| codetrotter wrote:
| Are there any Rust implementations of the protocol yet :vv:
| steveklabnik wrote:
| Multiple, in varying degrees of maturity. And I'm also
| writing one from scratch, don't know if I'll bother to
| share it with anyone though, I just want to learn more
| deeply, and implementation is the best way to do that.
|
| I have my eyes on https://github.com/sugyan/atrium as a
| foundational library in this space, and expect folks to
| coalesce on it. But we'll see.
| capableweb wrote:
| Wouldn't be funny if it was a public beta that they want
| people to use for serious stuff. But it's neither serious, a
| beta or public, but basically a private alpha for playing
| around, so i'd be a bit lenient on screwups.
| btown wrote:
| Wait - nobody had ever created a bucket named xrpc before,
| ever? I would have imagined that short s3 buckets were squatted
| similar to domain names. (Or maybe they were, and it's this
| person who did so!)
| bombcar wrote:
| Reminds me of people taking the username "admin" or
| "hostmaster" at a free email service and being able to get
| domain verification emails.
| ShamelessC wrote:
| [flagged]
| throw7 wrote:
| [flagged]
| alexcroox wrote:
| Unless it's been recently updated their help article only lists
| TXT record for verification
| https://blueskyweb.xyz/blog/4-28-2023-domain-handle-tutorial
| steveklabnik wrote:
| Everything is moving _very_ quickly, this is just generally the
| case for anything related to at protocol /bluesky (which is
| fine, they've been _quite_ busy).
| ehPReth wrote:
| is blueskyweb.xyz an official site for them? I've only seen
| bsky.social which now redirects to.. bsky.app? (if so couldn't
| the web stuff live on.. bsky.app?)
|
| edit: bsky.app links to blueskyweb.xyz so I guess so. weird.
| 1970-01-01 wrote:
| [flagged]
___________________________________________________________________
(page generated 2023-05-04 23:00 UTC)