zlacker

[parent] [thread] 6 comments
1. stevek+(OP)[view] [source] 2023-05-04 19:38:47
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.
replies(2): >>9dev+73 >>bisby+n8
2. 9dev+73[view] [source] 2023-05-04 19:54:50
>>stevek+(OP)
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.

replies(1): >>stevek+e6
◧◩
3. stevek+e6[view] [source] [discussion] 2023-05-04 20:09:25
>>9dev+73
> 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.

4. bisby+n8[view] [source] 2023-05-04 20:20:07
>>stevek+(OP)
"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"

replies(1): >>mtae+sa
◧◩
5. mtae+sa[view] [source] [discussion] 2023-05-04 20:31:09
>>bisby+n8
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!
replies(2): >>i_am_j+sf >>accoun+Mv1
◧◩◪
6. i_am_j+sf[view] [source] [discussion] 2023-05-04 20:57:00
>>mtae+sa
>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.

◧◩◪
7. accoun+Mv1[view] [source] [discussion] 2023-05-05 08:51:42
>>mtae+sa
With any kind of authentication when you have an insecure method it does not mather whether you also have a more secure method - your authentication is only as good as the weakest alternative.
[go to top]