Google has quietly launched a CDN
venturebeat.com
venturebeat.com
You'll know an Akamai competitor when you see it as it will handle video and large files.
This Google offering is limited to files below 4MB, which precludes most video.
Really this is a CloudFront competitor, but even then... it is only offering a very basic set of features to do with the caching, rather than anything else CloudFront is doing.
Further, the logic of what is cached is very basic: https://cloud.google.com/compute/docs/load-balancing/http/cd...
This all serves one goal: Reduce your Google bill by caching more and preventing it reach the server. How it does this is extremely basic, and it has limitations (check the cache invalidation gotchas).
The best way to reduce your Google, Amazon S3, and other bills remains to use a CDN in front of it that is cheaper than the storage behind it. The basic features of that you should care about is how easy is it get stuff into cache, serve it over https:// and invalidate it at will. Advanced features should look at DDoS costs (are you paying when you get attacked?), whether there are PoPs/edges where your market is, and then anything specific to your product, though you've usually made a selection before you get this far.
As I understand it, there's not a lot of dogfooding (let alone cooperation!) between GCP and Google.
(The 800+ is just estimate based on research we did recently, Google does not reveal publicly how many edges on GGC they have , more here http://blog.speedchecker.xyz/2015/11/30/demystifying-google-... )
self.response.cache_control = 'public'
self.response.cache_control.max_age = 300
I digress.
Alpha, is what the Article says. Which means not ready, and changing in development quite a lot.
What compounds the problem with China is that the chinese are very much used to requesting an english language variant of the webstore as its often cheaper. This circumvents the CDN however as all stateful requests are routed to foreign servers making their experience really slow.
Also there's the chinese web license process that you have to go through to even host a website in china.
I cannot convince myself not to use a politically neutral company (or China friendly) like AWS, Azure.. when I am considering the CDN service.
Eg: examplecdn.com instead of cdn.example.com
Each cookie has a path set to it and browsers will obey it, this includes inter-domain paths and restrictions. If you want you can go even further and assign a cookie to a specific URI path so the cookie will only be issues to pages that fall under www.example.com/private/ for example if that's what the path is set too.
And the fact that big sites use it doesn't mean that they were "well written", Google mostly issues only tracking cookies for wildcard domains like .google.com as far as private cookies go they usually would be issued for each domain individually (play.google.com etc.). Issuing authentication cookies to wildcard domains and root paths isn't advisable even if some big sites do it doesn't mean you should take it as an example :)
P.S. I really hate "Google and Facebook are doing it" as an example, even if they are you most likely aren't either of them, not even close they have quite different considerations than you. Even when they do things which aren't best practice or common sense it doesn't mean that you should decide to take the same path, both Google and Facebook have plethora of ways to ensure account security including quite decent activity heuristics, they have many ways of detecting attacks such as XSS, and they have most likely a much better process of ensuring that vulnerable pages do not go live or do so quite rarely. Unless you can say the same then do not use them as an excuse, you do not need to issue cookies to wildcard domains and you can restrict them to certain paths, and you better do so because you do not have many other mitigating controls in place as the big players do.
My point still stands, though: the point of cookieless domains is not security, but bandwidth. And there are legitimate reasons to have top-level domain cookies - sharing authentication state between subdomains is a common example - which would prevent a subdomain from being used as a CDN, without receiving cookies.
Another big one is security of cookies and data, like you mentioned. Most of the time CDNs will return an access allow origin * header. This is literally the worst thing you can do for security of your users if they have a secret cookie. A different domain minimizes the risk of making a mistake to zero since it is completely separate, and is easier since you don't need any nginx funny business proxy passing to a server with static assets with a location directive.
The allow access origin * is a death sentence that breaks same origin policy if you make a mistake.
You share quite a bit of things with your CDN quite often various API keys, as well as SSL certificates unless you do not serve your main content over SSL in the first place.
Most (I'm pretty sure all) CDN's give you the ability to set your own CORS policy if you see a CDN on cdn.example.com returns allow origin * then it means it's user did not set the CORS headers properly. Also the CDN can return allow allow and it still will not make a difference if you issue your cookies to the proper domain and path e.g. www.example.com/account if that's the domain and path there is no way a modern browser will attach that request to anything which doesn't sit on www.example.com and is located under /account.
If you issue your auth cookies to .example.com and the / path don't be surprised why ever XSS and other client side attacks end up compromising your users, you can have 100 XSS's in your site, you can have a shitty CORS policy and if your cookies are issued and restricted properly it's more likely than not that those vuln's could not be leveraged to compromised your users' sessions (not through a classic session theft that is).
I cant discuss your whole comment because it's long and I'm on a phone.
"If you issue your auth cookies to .example.com and the / path don't be surprised why ever XSS and other client side attacks end up compromising your users, you can have 100 XSS's in your site, you can have a shitty CORS policy and if your cookies are issued and restricted properly it's more likely than not that those vuln's could not be leveraged to compromised your users' sessions (not through a classic session theft that is)."
There is so much wrong about this paragraph. Who needs session theft in the scenario you provide..
If you have 100s of XSS on your site and a bad CORs policy there is a lot an attacker can do... Data exfiltration is very easy if you can execute js and so are things like XSRF.
A correct path and domain setting for cookies is important but web security is a lot harder than your acting like it is..
Using a CDN on a sub domain will not affect the security of your cookies if you issue them properly, it should not even be a consideration given the privilege level you already grant your CDN provider.