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 also think Sherline machines have good value. Were they the cheapest, no, but they actually worked really well in my experience for their size. I only have their manual lathe, but it was a MUCH higher quality machine than my larger 7x14 from china. It just feels like everything is either a race to the bottom, enshittification and/or both right now.
Native AOT is seeing a lot of use within Microsoft products too. Some bits of the .NET SDK use it, and C# Dev Kit (the C# extension for VS Code) uses it extensively in version 11. It brings a lot of performance to .NET.
AoT uses the same codegen (mostly) as the JIT so if you see a JIT improvement it's possible NativeAOT/ilc picked up that improvement too.
Unless it's a runtime-only optimization, like guarded devirtualization... there's no straightforward way for an AOT compiler to do that without profiling data.
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.
I know it is a marketing thing, but I simply dislike someone offering a server calling it serverless.
That being said: OK, so basically your service is to be treated as an Internet overlay. That can be fine. But then you should point the advantages of that. Using anycast and your internal peerings, are you better at routing packets than BGP on the open Internet? Are you able to hole-punch NAT to connect two NATted endpoints?
If so, this would be a service I might want to use.
As others have pointed out: End-To-End-Encryption with DTLS is possible by using SNI inspection on the Client Hello packet. You either do that and advertise this as a secure service OR you say "this is unreliable unencrypted transport, do your own thing over it".
I just don't think you are explaining your value proposition properly.
> 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.
You provide a DTLS to clear-text proxy service, for applications where the client supports DTLS, but the server does not (or vice versa)?
Yeah, why did you build this? It's unclear what the value proposition is, paying for a MitM proxy. It effectively means it cannot be used with secrets, without trusting y'all to not be snooping?
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.
With all the man made EM emitters in the world, it seems like passively matching what can be “seen” to a database of known emitters (with signal profiles and locations) could be extremely accurate where people are (less helpful on the open ocean and remote wilderness). Similar to what’s already being done with Wi-Fi and Bluetooth but general purpose, perhaps?
They record spots for all wireless access points too, unless you opt-out by naming them certain ways and the surveillance-capitalism company decides to honor it. (e.g. The _nomap suffix.)
I hope some future Wifi standard makes it much easier to anonymize or obscure persistent access points.
That's always existed with Hidden SSID. If you are particularly paranoid you can set it up like that. But unless you insert personally identifiable info in your wifi name there is not really any privacy risk for this data being mapped.
> That's always existed with Hidden SSID. If you are particularly paranoid you can set it up like that.
It's actually the opposite, a hidden SSID will backfire and hurt your privacy when it comes to phones and laptops.
With a normal network, your phone can passively listen for when it approaches MyHomeNetwork and then connect. If you change that to a 802.11 hidden SSID, then whenever you aren't connected your phone will be constantly emitting a very distinctive mating-call: "Any hidden networks? Hello, if you're MyHomeNetwork, please then let me in." That makes it easy for someone to uniquely identify your phone as it moves around, and it also takes up more battery power with the often-fruitless transmissions.
Both issues could be reduced by restricting it to only auto-seek the SSID based on other clues, like GPS regions or neighbors' public SSIDs, but that usually isn't a feature.
> But unless you insert personally identifiable info in your wifi name there is not really any privacy risk for this data being mapped.
How often do you reset/rename it? Surely it's at least weird that some big companies, via sensors carried by your neighbors, know you moved your apartments from X to Y even when you don't use any of their products.
Some phone-apps will have access to the network name too, but that seems just marginally worse compared to other identifying info they could track and exfiltrate.
These are valid points, but I think the utility of being able to get location on your phone without power sucking GPS running all day is greater than the privacy risk of seeing when a wifi AP moved address. Which if you were so inclined, could be avoided by changing the wifi name each move.
This kind of project is so much fun and a great learning exercise. While I respect the tongue-in-cheek proposition, we really would benefit from a wider understanding of network protocols. Doing an exercise like this is eye opening.
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.
reply