If you do that, it won't actually send very much traffic to the victim site, and you'll find your zone suspended pretty quickly. :)

As with any anti-abuse measures, though, it's best if we don't describe in detail what steps we've taken to prevent this sort of attack.

I don’t agree that it’s best you don’t describe anti-abuse techniques. I’d be impressed if your manager agrees. I’ll argue points if you like.

Can you talk about topology relative to ingress and origin? Eg. is execution pinned in select PoPs per ‘region’ or all? Unrelated, I also wonder about retention of edge cache, is it purged via LRU or similar?

Personal note, I was excited to get the early access email, feels like an excellent offering; I’ll be flexing it soon, have some ideas—been getting an HLS system online in the past month using RasPi+CF without a hiccup (720p@4500kbps) and it’s open source/libre, comparable to YT/Twitch—info incl. design/ lectures in profile.

Also read above, congrats on what must’ve been a good year! Speaks well of your org that you’ve been able to deliver and talk freely.

> I’d be impressed if your manager agrees.

I am his manager and I agree with him

I assumed that’d be the case. What’s the average response and resolution time for pro customers? Difference for free customers? How’s your escalation process, if I may ask? (PagerDuty, etc). Can you speak to false positive rates? I break things and run media channels, would instaquit for plan B if there were an issue. (Don’t mess with my paper is the stem of my concern). I’ve designed and built a similar offering at a big B2B company and we spent considerable time coming up with heuristics to plug the gaping holes possible in this kind of system, hence false positive concerns. I’m also a CF partner. Thanks in advance for any insights or pointers.

I'm probably the better person to answer these questions, since I'm the one who designed the anti-abuse measures in question.

If I understand correctly, you're worrying about false positives, i.e. your site accidentally gets shut down because we incorrectly believe you're launching a DDoS. This is not a plausible outcome of the measures we've currently implemented.

As a CF partner, you should feel free to arrange a private conversation if you are still concerned.

> Can you talk about topology relative to ingress and origin? Eg. is execution pinned in select PoPs per ‘region’ or all?

Nope. Every Worker is distributed to every location. Requests are handled at whatever PoP they arrive at.

> I also wonder about retention of edge cache, is it purged via LRU or similar?

TBH I'm not that familiar with the inner workings of our HTTP cache, but I would assume so?

Unless to the cache item expired first, yes

Great! Thanks

Do CloudFlare Workers require external HTTP endpoints to have CORS headers like Javascript within webpages need?

No.

CORS is designed to protect two things:

- The user's cookies for other origins, which the browser will normally send on any request to those origins.

- Behind-the-firewall servers that might be accessible from the user's browser but not from the public internet.

Neither of these things apply to Workers: a Worker obviously has no access to the browser's cookie jar, nor does it have the ability to see behind-the-firewall services since it's not behind-the-firewall.

CORS does NOT protect against DDoS: Typically, CORS does not prevent you from sending requests; it prevents you from seeing the content of the responses. Any web site in a browser can use an <img> tag or submit an invisible <form> to cause a cross-origin request, CORS or not -- but it can't read what comes back.

So, Cloudflare Workers do not enforce CORS. We've implemented different measures specifically to mitigate DDoS.