Live data from Hacker News

CloudFlare Is Now a Google Cloud Platform Technology Partner

blog.cloudflare.com

71–80 of 88 posts

Re: CloudFlare Is Now a Google Cloud Platform Technology Partner

#71
post #64

Earlier quoted context omitted.

What CloudFlare logs: https://blog.cloudflare.com/what-cloudflare-logs/

Thank you for the link. It was a simple and yet detailed. Wish more companies took time to explain parts of their privacy policy. However my concern is more to do with thinking as an outsider. I have toyed with idea of a company that requires establishment of trust among users. Although it may seem as simple as do no evil on the surface, it is an extremely hard undertaking. The thing with Cloudflare is that its niche…

This might be interesting: https://blog.cloudflare.com/protecting-free-expression-onlin...

Re: CloudFlare Is Now a Google Cloud Platform Technology Partner

#72

Earlier quoted context omitted.

Go on App Engine has been in beta for years

Sure, a GA product like App Engine often has features that are in Alpha/Beta/Experimental states. That different than the major product being in a pre-release state.

Why? The point is, Google has a habit of releasing tons of shiny new Cloud Platform services (whether they're considered "separate products", part of an existing product, or whatever), but keeps them in alpha/beta for a long time. Go support has been there for years, and it's still "experimental". Some of the new products released last year at I/O 2014 are still in alpha, and we're already approaching I/O 2015. Pedantry aside, this deserves discussion.

Re: CloudFlare Is Now a Google Cloud Platform Technology Partner

#73

Earlier quoted context omitted.

In my defense, I was assuming SNI (aka the modern internet), and that the IP was reachable by those you care for it to be reachable by. Ignoring these issues, is there an "engineering" reason why a single IP won't work, in terms of, for example, hardware can't demultiplex the aggregate ingress volume of CloudFlare and handle DOS mitigation? I guess I'm asking this because of how woeful looking the "load-balancing" so…

I work for a major CDN that uses anycast, and there are a number of reasons. I won't go into too many of them, but quickly: 1) Anycast doesn't give you fine grain control. Once we announce our anycast routes, what traffic actually gets sent where is out of our control - it is based on the peering arrangements of our transit providers. If we need to balance traffic between our pops, we need finer grained control than…

> 2) IP addresses get blocked for all sorts of reasons (looking at you China!) If all customers were on one IP address, as soon as China decides to block one customer, they are all blocked.

Feature, not a bug.

Re: CloudFlare Is Now a Google Cloud Platform Technology Partner

#75

Earlier quoted context omitted.

What CloudFlare logs: https://blog.cloudflare.com/what-cloudflare-logs/

However, there is no way to verify that is all they log. CloudFlare gets to see the cleartext of all traffic they serve as they MITM HTTPS connections.

[deleted]

Re: CloudFlare Is Now a Google Cloud Platform Technology Partner

#76

Earlier quoted context omitted.

What CloudFlare logs: https://blog.cloudflare.com/what-cloudflare-logs/

However, there is no way to verify that is all they log. CloudFlare gets to see the cleartext of all traffic they serve as they MITM HTTPS connections.

From an engineering feasibility/cost standpoint: there is no scenario in which they could log (as in packet capture) and dedupe all traffic without a nation-state-like (alphabet orgs, interested companies a la Google) budget.

CloudFlare's (non-enterprise) prices simply aren't even in the required order of magnitude.

Now: whether or not metadata, request bodies, etc. are logged, and to what scale, is another story/discussion of possibility.

At some small, targeted scale, it's safe to say that total duplication (certainly request bodies, etc.) is possible, if they were so interested.

Re: CloudFlare Is Now a Google Cloud Platform Technology Partner

#78
post #69

Earlier quoted context omitted.

They also capture all your content and communications.

More specifically - they terminate your SSL connections, thereby having the cleartext of your traffic - and doing whatever their NSL/gag-order requires them too do before fetching/forwarding your request to the appropriate chache/endpoint.

Which, more specifically, could happen at AWS, GCE, Azure, or your local colo- wherever you happen to terminate SSL.

Save for the scenario of expensive, relatively difficult-to-implement pieces of crypto hardware (and even then, a nation-state could probably defeat it), your traffic is likely vulnerable to determined aggressors.

It's one thing to possess such high-end, esoteric security technology, it's another thing entirely to implement it (and protection for other far more realistic attack vectors) at a CloudFlare-number (or other CDN) of global locations.

Re: CloudFlare Is Now a Google Cloud Platform Technology Partner

#79
post #59

Recently I have been getting cautious about Cloudflare. I do use them and like them a lot, also enjoy reading their technical blogposts. However from a privacy stand point it makes me feel uneasy. Cloudflare is just everywhere now: HN, Stackoverflow, Reddit and countless other sites. You can block a cookie, connection to a third party script, but how do you block an internal proxy? All your cookies, credentials, heck…

No, you're not being paranoid. The internet started off as a de-centralized system and now we are seeing the emergence of more and more silos, cloudflare is another one of these (albeit a special one and run by people that I would trust more than those running some of the other silos).

Re: CloudFlare Is Now a Google Cloud Platform Technology Partner

#80
post #72

Earlier quoted context omitted.

Sure, a GA product like App Engine often has features that are in Alpha/Beta/Experimental states. That different than the major product being in a pre-release state.

Why? The point is, Google has a habit of releasing tons of shiny new Cloud Platform services (whether they're considered "separate products", part of an existing product, or whatever), but keeps them in alpha/beta for a long time. Go support has been there for years, and it's still "experimental". Some of the new products released last year at I/O 2014 are still in alpha, and we're already approaching I/O 2015. Pedan…

And...so what? Why does it deserve discussion. Sure, Google openly has always favored a practice of releasing products/features very early to to validate them and evolve them through real-world use with willing early adopters that accept the risks associated with potentially unstable feature sets of not-yet-stable products.

What's the issue, here?

Post reply on HN