mlhpdx

Exactly that. No knock, no answer.

One of the fundamentally great things about the Wireguard protocol is the simplicity. A small codebase can implement it, and that’s lead to some great libraries and innovation.

Another great (and subtle) thing is the monotonically increasing sequence number. Note that it isn’t incrementing, like DTLS. This small thing makes it so much easier to implement with efficient concurrency, and event external state (i.e. distributed concurrency).

That latter bit we’ve done in our own library.

Edit: typo, don’t -> done

I’m optimistic about NHP being the middle ground solution for a lot of things. With OS support it can be transparent to users yet still effective.

Is the Network Infrastructure Hiding Protocol work at IEEE going to help thwart AI assisted attacks, if adopted?

Having employees (or system like bastion hosts) with unrestricted access is one of the recurring mistakes in such events. I can’t understand it.

> All of them modern "we keep your content safe" players

But they weren’t and probably aren’t and won’t be. They just put forth an image as much as needed to sell.

Congratulations on this automation, which I know from first-hand experience is very difficult to pull off.

Is the robot really working with individual boards and not panels? How do you deal with balancing copper area, and varying etch times?

People often focus on the assembly side as “hard” but quick-turn manufacturing of the PCB is vicious.

QUIC for embedded? I haven’t seen that, but there is a lot of DTLS. Particularly with 1.3, it makes QUIC look like a behemoth in code.

> Support for DTLS 1.3 (RFC 9147). Refer to the ossl-guide-dtlsv13(7) manual page for details.

DTLS 1.3 is a huge improvement over 1.2 for efficiency and simplicity. I can’t speak to the OpenSSL implementation but it’s great that support is finally released.

That’s pretty brazen, even in this day. If Perplexity is making money from a project to reverse engineer something patent protected, I’d imagine that would be crossing a line. Buy perhaps not in today’s world?

Edit: parent -> patent

I like the approach of rendering directly to SVG, which is what I want -- running layout once and caching the result in the browser or on the server side.

Putting reverse indexes in S3 alongside large aggregate log objects has been an effective pattern for more than a decade. With objects in cheap access modes and indexes in modes that are cheaper to access it becomes far more cost effective than most options (cheap S3 clones aside).

The earliest code I have to do this looks to have been created in 2012.

Separation of compute and storage is such a fabulous pattern.

The change in lifestyle expectations should be as well documented as the changes in social contact.

Most people did not go to bars. As with many things, an unrealistic image portrayed in media. Perhaps more did, but far from most.

A picnic is basically free, for those near enough to open spaces. Likewise for hikes, which I’ll happily pay to drive an hour or more to enjoy.

I don’t think money is a barrier to getting out.

When Oregon had only biannual legislative sessions there was a small, and by modern standards ineffective, lobbying system. Also very few “professional” politicians.

Then we went to our current system and both proliferated. In balance it seems to have been quite a mistake.

It would make a great documentary.

I have done the same. FWIW, a 2-3 hour block seems to be the sweet spot, as far as keeping it off the radar goes. Ironically, having multiple a week doesn’t seem to raise an eyebrow.

I’m trying to visualize the argument made that this was okay. I can’t.

I found SO pretty helpful and approachable in the day. Not perfect, but that’s true of anything involving people.

The link should have been: https://builder.aws.com/content/3Ik2uno1akahZ6d21Rg5Bl0lW1u/...

I have, at the risk of being a meme, put spreadsheets in cells via OLE. It was glorious.

Wow, what a disappointment. I’ve found it funny over the years when people are shocked to hear me talking about machining, when they themselves have woodworking tools. Cutting metal, cutting wood, even cutting paper - all useful for making and fixing.

I earned an MSME without ever learning to actually make things, so once I could afford it I bought a Sherline CNC mill and taught myself to use it. I made many mistakes but got there. I used it just last week to make a wind gauge mounting bracket for a 70 year old sailboat.

I liked that it was made in the USA and (at the time, pre mainstream internet) had a great community to learn from.

I know there are other options still, but Sherline has a fond place in my heart for how easy they made it to get started.

I hope that’s the case but I’d feel a lot better to see it in print.

Impressive technical work and authorship. My quibble, which seems significant in context, is what happened with AoT?

> so basically your service is to be treated as an Internet overlay

I don’t understand how that could be the takeaway. The service is just what it says on the homepage: a way to make datagram transports compatible with event driven architecture and serverless. I don’t think the word “overlay” appears anywhere. I get your point, but thats not at all the positioning. The SDLC and operations are what it’s about.

> End-Encryption with DTLS is possible by using SNI inspection on the Client Hello

Sure. In simple cases even that’s not necessary if a listener is tied to a single endpoint, right? But again, this service probably isn’t ideal for such cases — it would work, but I, for one, don’t see why it would be useful.

> … must be something you actively think about, then making a decision.

I think that’s exactly it; an engineering decision based on the constraints at hand.

For the most part the technology (and society) we have it built on that resolving in favor of trusting 3rd parties to some degree.

While small devices can technically do TLS, it’s a significant battery drain because of the acknowledgements (keeping the radio on while waiting). Anything battery powered is likely to eschew TLS for DTLS 1.2 + CID or TLS 1.3 with early data.

FWIW, Proxylity supports plain UDP as well as DTLS so it’s possible to build a paas-through proxy for DTLS to Lambda, for example. But then you’ll need to implement DTLS in Lambda. People have done it, but it’s a heavy lift.

The idea with the DTLS support is protecting content in traffic, and the handling it in your own AWS account. For some cases it isn’t acceptable to have Proxylity or AWS to have any chance to seeing the data. But for the most it’s not a problem and the convenience of what the service provides is worth it.

But I hear the concern. I guess I just expect folks will make good decisions for their use cases.

DTLS is TLS encrypted, so I think you're talking about plain UDP as the transport? There are use cases for that, for sure, but more for protected content over WireGuard or DTLS (we support both 1.2 and 1.3).

I understand the concern. It can be a great convenience to not run the servers yourself, as people have been doing for decades with respect to websites, apps and APIs. That's essentially the same model, with the host terminating HTTPS for you.

> ...lossy UDP

All networks are lossy, and all transports. The difference between UDP and TCP based transports is who decides how to handle it. With UDP the application developer decides; with TCP (and QUIC) the protocol decides. More and more projects are taking-on the reliability decision, for a lot of reasons that trace back to this difference.

> ..some random guys on the Internet

Essentially; and that's how everything starts. We've been in production since early last year and have maintained >99.99% availability. We're a certified partner with AWS, and have "qualified software" (it passed their security review), and our security posture report is available from AWS Marketplace. We aren't SOC-2 audited yet because we want to do it right rather than pay for a rubber-stamp report, and that takes time and a lot of money.

Your summary is about right, but the use case is simply not wanting to run always-on servers around the world (we have anycast IPs backed by handlers around the world). So it's convenience and scale first, and wanting to build with event-driven architectures second.

Yes, your point on security is correct. Since our service terminates the DTLS connection we could see the cleartext (just as any gateway service does, like AWS API Gateway, etc.). We don't touch it except as strictly needed to pass it to the configured integrations.

EDIT: FWIW, using a plain UDP handler you could implement DTLS handling that runs in your control, in which case payloads would be opaque to us. That's a bit of an effort, though. We were asked for this, so we built it.