growse

Apple and Google don't need the passkey spec to mandate that you only use their services from non rooted Google/ Apple devices. They could do it before passkeys existed, and they can do that right now if they wanted to.

What's any of that got to do with passkeys and attestation?

Flags Wikipedia articles where the subject's parents also have Wikipedia pages. Draw your own conclusions.

A clock ticking every second is generating an event every second.

If you sample the CPU usage at 1Hz, the metric is attached to the tick event.

What I find confusing about this is that otel is two things.

1. A spec 2. A ref implementation

Similar to other projects (e.g. python), if there's complaints about (2), that should trigger an ecosystem of alternative implementations that are guaranteed to be compatible because of (1).

I suspect there's actually quite a few private, separate otel implementations. Maybe these just aren't being contributed as oss?

> Summary: it's not DNSSEC itself, it's DNS providers like Cloudflare returning incorrect data to make responses shorter and avoid switching to TCP.

I feel like we need the angry goose meme here.

"But why are those providers returning incorrect data?"

> No one.

I thought everyone was "trying so hard to re-invent PGP".

> we do need a single key that can be used for all those things

We do? This is not obvious. Why does my disk encryption key need to be the same that I use to sign binaries that I release?

Who's reinventing a tool that can do all that?

> Everyone is trying so hard to re-invent PGP

Which bit of PGP?

I don't know enough about either the technical nuance or the political drama, but some observers have noted that GnuPG's implementation is (deliberately?) incompatible with the IETF's standards. It's not clear why.

https://floss.social/@hko/116459621169318785

Maybe your company's ISP is CGNat'ting you?

A non-trivial minority of the time, they don't support IPv4 either!

I do similar, but frame it in terms of dependencies.

The database can live without the web server, but the web server doesn't work without the database.

Therefore webserver ---> database.

Key thing in that these deployment / context / container diagrams don't have a temporal axis. If you want to represent a flow, then you want a diagram where time has directionality, like a sequence diagram.

If I accidentally yank the power cable out of my load balancer, I can plug it back in and I'm back up and running.

If I cock up my DNSSEC config, nobody can resolve any records under my org's domain (goodbye internal email!) and you've got to twiddle your thumbs for a period of time waiting for various timeouts to pass (go ask Slack how it went for them).

These things are not the same.

> As if DNS isn't a major contributing to A LOT of downtime. That doesn't mean it's not worth doing not investing in making deployment more seamless and less error prone.

Ah yes. Let's take something that's prone to causing service issues and strap more footguns to it.

It's not worth it, because the cost is extremely quantifiable and visible, whereas the benefits struggle to be coherent.

That entire post is that you should enable DNSSEC because it's "more secure", and there are no reasons not to.

"More secure" begs the question "against what?", which the blog post doesn't seem to want to go into. Maybe it's secure from hidden tigers.

My favourite DNSSEC "lolwut" is about how people argue that it's something "NIST recommends", whilst at the same time the most recent major DNSSEC outage was......... time.nist.gov! (https://ianix.com/pub/dnssec-outages.html)

If you're in (for example) a CI context and do a git checkout @tag, there's no guarantee that you'll get the same content as the last time you fetched that tag.

Tags are not immutable.

> Why is entitlement to others labor the moral position, instead of the immoral position?

You seem to be mistaking me for someone arguing that anyone is entitled to others' labour?

The social contract is found (and implicitly negotiated) in the interactions between humans, ie: society.

It's a social contract, which for many people is a moral contract.

> CABF started imposing restrictions on the public CA operators regarding the issuance of non-HTTPS certificates.

The restriction is on signing non web certificates with the same root/intermediate as is part of the WebPKI.

There's no rule (that I'm aware of?) that says the CAs can't have different signing roots for whatever use-case that are then trusted by people who need that use case.

> [citation needed]

My citation is the membership of the CAB.

> IMHO "other relying-party software applications" can include XMPP servers (also perhaps SMTP, IMAP, FTPS, NNTP, etc).

This may be your opinion, but what's the representation of XMPP etc. software maintainers at the CAB?

The CAB is only concerned with the WebPKI. This means HTTPS.

There's loads of non web, non HTTPS TLS use cases, it's just the CAB doesn't care about those (why should it?).

> if we could of built it much closer to the WCML

Knocking down half the towns that the WCML runs through to build more tracks carrying trains that aren't going to stop there would be neither easier nor cheaper than HS2.

> But you write it as if it's in contradiction with my point, which I'm not seeing.

My point was that a community is members + values + practices + other stuff. In the case where one member who wants to upend the values and practices of an existing community, "just fork it" is an entirely reasonable response.

I rarely see good faith engagements being immediately shut down with "just fork it" (you'd never accept issues / MRs!). Instead it's usually used as a last resort when the "exploiter" doesn't get their way and starts whining about it.

If a change is proposed that's completely counter to a community's stated values, then I guess "fork it" is a more appropriate immediate response, because it's hard to see how such a clash could be resolved without fundamental change.

Edit

> Every community is the sum of its members

A community is much more than the sum of it's members.

The subtext here is that there's a difference between someone saying "I don't like this community, I'm going to make my own" and "I don't like this community, I'm going to change it".

Building communities is hard. It's not obvious why someone who wants a community on their terms gets to piggyback on an existing community rather than putting the effort in to make their own.

The point of "just fork it" is that if your ideas are popular, then sustainability shouldn't be a problem.

I don't remember if this is in the original text, but is there a time constraints on distributing the source on request?

If a user asks for the source, and the distributor says "sure" and then delivers it 12 months later, have they violated the license?

> I have generally told that story with the ISV anonymized -- but you clearly found an example where I named them.

It was on one of the OaF podcasts about dtrace. I worked for Reuters at the time and contempt for their customers was definitely a thread that ran through some parts of that org, even as it made a bunch of us feel very icky.

(I still have a side quest to find / talk to some of the people involved on 'our' side of the fence about this!)

There's a bus factor equivalent with the cloud, too. The power to severely disrupt your service (either accidentally, or on purpose) rests with a single org (and often, a single compliance department within that org).

Ironically, this becomes more of a concern the larger the supplier. AWS can live with firing any one of their customers - a smaller outfit probably couldn't.

And this speaks to the lack of alignment about what's good for the decision makers Vs what's good for the customer.