Live data from Hacker News

The fastest de-referer service... with AWS Global Accelerator

lifeofguenter.de

51–60 of 79 posts

Re: The fastest de-referer service... with AWS Global Accelerator

#51

It is 2021, and AWS Global Accelerator still does not support IPv6. Google Cloud has supported this on their global anycast load balancers since September 2017.

Google doesn't own nearly as many IPs as Amazon, so they have to do better at IPv6. AWS is incentivized to keep the world IPv4 as long as possible.

Re: The fastest de-referer service... with AWS Global Accelerator

#52
post #50
post #33

Earlier quoted context omitted.

This is technically correct but don’t rely on caching to solve this problem. Unless you’re getting a ton of widespread traffic you’ll probably be getting more cache misses than you expect - every time I did client-side monitoring, the DNS 90th percentile was quite notably higher than the 50th.

The trend has definitely been towards lower and lower TTLs with cloud deployments and such. What used to be a 1 day TTL with a static host is now 5 minutes in the cloud. Servers that use geo DNS (EDNS-Client-Subnet) also cause considerable cache misses since the caching becomes very granular.

Good points - also people started using more TLDs and hostnames as the average page started loading different service endpoints directly in the client, and I got the impression that a fair number of places were slow to increase their DNS cache sizes.

Re: The fastest de-referer service... with AWS Global Accelerator

#53
post #26
post #15

Full disclosure, I work at Fly.io now. This exact setup is easier on Fly.io - our proxy layer runs in 20 regions worldwide with anycast, so your requests hit the nearest region and quickly terminate TLS there. You can also run any Docker container, and either choose regions to run them in, or just set the min/max and ask us to start and stop containers in whichever region has demand, so your deployment follows the su…

Do you have your own servers or you build your service on top of the aws/gcp/azure?

We have our own servers.

Re: The fastest de-referer service... with AWS Global Accelerator

#54
post #53
post #26

Earlier quoted context omitted.

Do you have your own servers or you build your service on top of the aws/gcp/azure?

We have our own servers.

If I'm not mistaken, you were using Equinix Metal (formerly Packet) at some point. Did that change?

Re: The fastest de-referer service... with AWS Global Accelerator

#55

Neat, I didn't know AWS had an AnyCast service like that. The Cloudflare workers issue is a bit disappointing, I remember their blog about eliminating cold starts and how clever it seemed, but I guess it's still not there? On another note have you evaluated fly.io at all for this? This looks right in their wheelhouse of many regions + AnyCast + IPv6, and I could definitely see configuration being simpler with them th…

The latency that this individual was experiencing with Workers wayyyyy back in 2019 was not caused by cold starts, but rather a bug in the workers runtime which caused rare but long pauses. Specifically, the bug involved a hash map with a broken hash function. Here's me publicly facepalming over the issue at the time: https://twitter.com/KentonVarda/status/1189966124688953344

But that was two years ago, Workers has grown ~an order of magnitude since then (both traffic and team size), and such a bug would be immediately noticed today.

The article author says that after the fix he still wasn't happy with performance, but I don't know what he was experiencing exactly. We've done a lot of other things to improve performance since then; it may very well be better today.

Re: The fastest de-referer service... with AWS Global Accelerator

#56

In the context of the problem being solved – removing Referer headers – isn't this optimising the wrong thing? Almost every browser, except for IE, supports the `Referrer-Policy` header. We should be aiming to avoid additional redirects, not to make them faster.

I would say the vast majority of solutions do it properly, and it's hard to fathom why someone would ever use a service like this. Quite aside from adding additional latency, improve privacy/security by looping in another party? That does not follow.

Set the header and call it a day, and at this point browsers should default to same-origin. The only outlier is IE 11, with 0.5% usage, and it is so grossly out of date it's pretty reasonable to just dump.

I remember in the very early Internet trying to raise an alarm that a lot of people didn't realize the privacy implications of referral headers (run a website and you could find all sorts of crazy niche discussion forums, see the resources people were referencing, etc). I certainly am not claiming prescience, but it was amazing how little anyone cared. Mind you, I also once promoted the notion that browsers should only ever send strongly, expensively domain-specific hashed passwords from password elements, and that too was pooh poohed. Several billion pwned passwords later...

Re: The fastest de-referer service... with AWS Global Accelerator

#57
post #53

Earlier quoted context omitted.

We have our own servers.

If I'm not mistaken, you were using Equinix Metal (formerly Packet) at some point. Did that change?

Kind of! We still use Equinix Metal in some regions. Leasing servers and buying colo isn't all that different from Equinix Metal so I'd class that as "our own hardware".

Re: The fastest de-referer service... with AWS Global Accelerator

#59

In the context of the problem being solved – removing Referer headers – isn't this optimising the wrong thing? Almost every browser, except for IE, supports the `Referrer-Policy` header. We should be aiming to avoid additional redirects, not to make them faster.

I would say the vast majority of solutions do it properly, and it's hard to fathom why someone would ever use a service like this. Quite aside from adding additional latency, improve privacy/security by looping in another party? That does not follow. Set the header and call it a day, and at this point browsers should default to same-origin. The only outlier is IE 11, with 0.5% usage, and it is so grossly out of date…

Won't a JS-based backup work for 95% of 0.5%? So, there are many, many options on the table.

Re: The fastest de-referer service... with AWS Global Accelerator

#60
I think you could run this service on CloudFront Functions, if you didn't mind using a Refresh header instead of the meta tag.

(CloudFront Functions can't generate body content, but it looks like this service works by responding with a refresh meta tag. So if you change that to a Refresh header you wouldn't need to write the body.)

CloudFront functions run on the 200+ edge locations of CloudFront and, according to the docs, have sub-millisecond startup times. So might be a viable option?

Post reply on HN