calling out the app engine team on ssl for custom domains

[Amir More]

Hi

(I apologize, it's a long one).

I'm calling out the app engine team on how they've handled issue 792 - ssl/https support on google apps domains, and would like a straightforward answer to the current status of this issue.

Before I get into how the team has dealt with the issue and my problem with it, I'd like to make a few observations:

1. The engineers on the GAE team have known about the lack of SNI on IE in XP for quite some time (see comment #48 - quoting an IRC session).  We can safely regard August 2009 as a point of time at which GAE engineers knew about this problem.

2. The issue was market as Started in October 2010.  The GAE team and/or it's decision makers have clearly chosen to work on this issue.  This is non-trivial given the success of GAE which, as usual, has lead to a queue of dev tasks far larger than the capacity of the team.  In other words, this issue is decidedly important enough to work on that dev resources are prioritized to work on it.

3. In the last two Google I/O events, the issue of SSL on google apps / custom domains has been prominently displayed as a feature which will be available 'soon', whether as part of GAE for Business (available by EOY 2010) or as a feature that's on deck for general availability.

4. Despite the issue of SNI and IE/XP, there appear to be a handful of possible solutions to overcome the limitations it presents.  More on this later.

5. Other features which have been taken on by the team and were expected to take a relatively long time to bring to fruition have been declared as such.  For example, if we look at the Full-Text Search issue, it was marked as Started back in October 2009, but with the following text:

"I'm marking this issue as "Started" but I want to set expectations appropriately: 

This is a major undertaking and this will not happen soon, even by the most generous definition of soon."

Given these observations - it is understandable and acceptable that there are factors beyond the control of the team; namely that the lack of support for SNI in IE on Windows XP presents a technical obstacle.  On the other hand, the recurring assurances that this issue is being worked on, and in some cases promised to land about a year ago, leads one to believe that regardless of the SNI problem the feature will be generally available in the near term future.

Case in point: "SSL access on custom domains" has been on the roadmap since May 2010, updated around the time of I/O 2010.  Given the heading "..Most of these features here are intended to be launched within the following six months. .." it should come as no surprise that a sizable number of developers are quite irate over the fact that we are now well into September 2011 and yet no sign of SSL for custom domains, for better or for worse.

At no less than a keynote speech of I/O 2010, given in front of thousands of developers, Kevin Gibbs says in regards to App Engine for Business (@113:12): "..That means we're putting our money where our mouth is when it comes to the reliability of your business.  And finally, it also comes with two additional key features that we had heard almost every enterprise needs: SSL for your company's domain and SQL databases.  That's right.  You heard me right."

On the other hand, a full year later, at a fireside chat from I/O 2011 the SSL issue comes up a few times and at some point Peter Mckenzie, who claims responsibility for SSL, says (@26:35):

"We are actively working on it and making good progress.  We can't give a date, but it's certainly high priority.  To be honest, we would have liked to have launched it by now, but it's certainly foremost in my thoughts, and in the thoughts of several others of my team."

.. immediately followed by a moment of candor by Brett Slatkin, who jokingly suggests we get everyone to install a browser with SNI and/or move to IPv6.

I'm calling out the app engine over what has happened over the course of 2-3 years on this issue.  First, the issue is accepted in 2009 and marked as 'started', despite the known SNI problem.  Next, in 2010 it's added to the roadmap, announced in a keynote and given an approximate ETA of EOY 2010.  Yet a year later, all of a sudden they don't have a date and are throwing around remarks about how they would have liked to launch it by now.

The duplicitous and shady behavior on the issue of SSL on custom domains is, in googley terms, a form of evil.

On a personal note: You'll have to take my word for it that I had attended I/O 2011 and brought up the issue at App Engine office hours before the fireside chat.  One of the engineers (may have been Brett, I can't recall) started explaining the whole SNI issue.  There were a couple of GAE developers there who heard our discussion and chimed in that they just send their users to the *.appspot.com for registration and no one complained, and that maybe I should do that too.  I was a bit shocked that the App Engine team didn't think that was a bad idea (if my cryptography professor heard about this he would go into quite a rant over it).  When I brought up the fact that I had a startup project that was waiting for SSL on a custom domain, I got reply along the following lines: "Your business shouldn't be waiting on a future feature." (again, not exact words but along those lines).

I'm calling out the team on their hypocrisy.  On the one hand, the whole point of Google I/O is to get developers involved with features that haven't come out yet so that when they do come out they can be immediately used in applications consumed by the public/enterprise.  Android SDKs with features that aren't rolled out yet, HTML5/Chrome features that aren't out yet (hello Native Client) and App Engine features as well are introduced and described at length, no doubt with the goal of being used by developers.  App Engine's FTS feature works in the SDK but not in production yet - so does that mean I shouldn't build an application that relies on FTS until it is available in production?  Native Client arrived in the Stable Channel this past month - so should developers not develop games or apps with NaCl until it is stable?  On the other hand, the GAE team says a developer shouldn't be waiting on a future feature?  Even if it was announced at a keynote speech over a year ago?  At the very least there are conflicting messages.

So, where are we now?  As the team has said numerous times in their own words, the SSL on custom domains issue is clearly a top priority.  While they would certainly be grateful if IE on XP would disappear overnight, this is clearly not the case.  At the current rate it would take at least a few years until the market share of IE/XP would be negligible (say less than one percent).  Worldwide IPv6 deployment doesn't seem to be doing any better.

It seems that the GAE team and/or the googlers who are in charge have made a choice to either do nothing and wait for IPv6 / no more IE on XP or find a workaround.

There is at least one trivial and costly but effective way to solve the problem.  Google can buy enough static IPv4 IPs so that each app engine app paying for SSL on a custom domain has a number of static IPs corresponding to front end servers / load balancers in numerous data centers all over the world.  Google can set up a dns service which services only app engine apps with SSL so that a non-SNI enabled request will get a static IP mapped to a custom domain with SSL which will answer with the succeeding SSL request to that static IP with the correct certificate for the SSL handshake.  Yes, its expensive.  The engineers have no doubt thought about this option given how trivial it is.  Earlier this year MS bought 660,000 IPv4 addresses from Nortel for about $7m.  Given that market price and that there are probably less than 500,000 app engine apps (I suspect we would have heard from the GAE team if there were 1 million apps), the rough order of magnitude of money needed to acquire 10 IP addresses for each app engine app is around $70m (10 IPs for multiple end points in different data centers).  Considering that only a fraction of apps need / will pay for SSL on a custom domain, it is entirely reasonable for Google to use a custom DNS with static IPs to serve GAE apps with SSL on custom domains.  Given a cost of ~$100 per app engine app (say $7 per IP, 10 IPs per app and some profit) there's even an outlook for ROI.

Therefore there exists at least one possible and viable solution to get around the unfortunate SNI issue.  There are probably a handful of other solutions.

So, Google App Engine Team, which is it:

1. Are we all going to wait for IPv6 or IE on XP to go away, which is why you don't have a date?

2. Are you developing a workaround and are planning to release some form of SSL on custom domains in the near future (say, before GAE leaves preview)?

A straightforward answer would be appreciated by your users.

Thanks

Amir

[Brandon Wirtz]

Amir,

 

While I can certainly relate that a Lack Of SSL is a severe limitation of GAE, I also (not being a Google Employee) can say it is likely not GAE’s fault.  Google as a whole likely, but I very much suspect that because SSL works on appspot.com domains. When working in a large company often you have to deal with the relationships between your group and other groups. If a feature requires that the infrastructure team, or the apps for domains team, or the Google Edge Cache team make a change, or all 3 make a change, GAE team is limited in how fast they push an item through.  Often other groups have minimal incentive to add a feature that doesn’t impact their performance metrics.

 

If it is in fact a GAE issue, consider this… Right now you have the ability to resolve this issue:

 

Set up a Squid/Proxy somewhere at Secure.YourDomain.com that proxies requests to https://YourApp.Appspot.com

 

In 2014 XP will be End Of Lifed and the issue will be quick to resolve.

As IPv6 approaches IP’s will not have significant cost and the issue will be quick to resolve.

 

From a business standpoint, This is a “New Feature” that attracts “new” clients. SQL support was something that existing customers were already solving through other solutions, or were fighting through the SQL to GQL conversion issues of their code.  CPU Cycles that were being sent to SQL running on Amazon via HTTP requests and other methods were all CPU cycles that GAE was losing, AND giving up market share to competitors.  If you want this feature to come faster, use a Squid, implement it yourself, and make sure every time someone else asks about it you point out “I had to solve this issue using a Squid Hosted at Amazon. It would be nice if I only had to pay one Cloud Provider”  so that the guys on the GAE team aren’t attacked for not implementing it, and are given ammo to go to other teams, their executives, and whoever else and say “this is costing us money, and making us look like schmucks”

 

-Brandon

 

Brandon Wirtz BlackWaterOps: President / Lead Mercenary
Work: 510-992-6548 Toll Free: 866-400-4536 IM: dra...@gmail.com (Google Talk) Skype: drakegreene BlackWater Ops

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/GFb6thDYs6IJ.
To post to this group, send email to google-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.

[Amir More]

Hi Brandon,

Regarding your resolution of setting up a squid/proxy that forwards requests to https://*.appspot.com somewhere:

Having all your traffic go through a single server on AWS or other VPS to proxy requests for google app engine is equivalent to buying a top of the line super-car, ripping out it's four-digit horse power engine and strapping it to a moped with the goal of using said turbo-charged moped for a road trip from new york to california, all because the super-car is too wide for some of the roads you might encounter.  It might work but you're doing it wrong.

Let's try to go with the flow: I'll see your "proxy/squid set up somewhere" and raise you a multinational dns provider with name servers on most continents with geolocation rules to forward dns requests to the CNAME of a multi-zone load balancer at the nearest AWS region out of 5 worldwide; each region's ELB configured to forward to auto-scaling health-checked linux instances balanced across all availability zones, each instance running a modified linux kernel optimized for the sole purpose of being a web proxy, running either varnish or nginx as a front end, using a SPDY library for SSL requests to app engine (yeah, the app engine front end has SPDY - GAE team didn't even know about it for a while).  It would be best to have the AWS ELB use SSL with SPDY to talk to the instances but we'll let that slide.

Yet, still, this solution is sub par considering:

1. There's hardly any point to serving static files from GAE, might as well serve them from your proxy.  Yay, more locations to push to :) Or you could have your proxy be a literal cache and time out files but then you'd have to either push a cache flush or use cache busters for your content.  IMO both reek of an equally vile stench.

2. It's likely the Channel API won't work with all those middle men.  If the GAE team starts using websockets (or regular tcp/ip sockets while we're at it) we'd be back to the drawing board.  Also various other APIs might be negatively affected or require some tinkering (blobstore upload, XMPP and task queue API)

3. Consistently added latency in the best case - you have the added latency of initiating an SSL handshake with the proxy.  Given a solution with a load balancer you'd have two handshakes, and depending on how they're set up either one or both of them will be full SSL handshakes (not just TCP handshakes)

4. Additional highly varying latency in the worst case - what happens when the GAE or production teams move the instances serving GAE requests to another data center?  Your users would see a sudden jump in latency since the proxy they're working with takes longer to reach the GAE domains/ips it's been working with.  It'll take a while for new geolocation rules at the dns level meant to counter the effect to kick in due to dns caching.

5. It's expensive.  The cheapest single server solution is more expensive than the GAE $9/app/month under the new pricing model.  The full-blown AWS solution is somewhere around $1k a month.  Not including the labor and maintenance required for the custom linux image.

There are probably more issues but those are the best I could think of off the top of my head.

I think there is no reason to believe that internal politics at google are holding this issue back.  Also I can't find a reason to believe that google is an organization set up such that the GAE team and/or their product/project managers need to give financial incentives to other teams just to get a major feature out the door.  I'm not saying there aren't internal politics because there probably are.  I'm just saying that a feature of this type seems like something that, at worst, would be arbitrated quickly by a manager high enough on the corporate ladder to see the detrimental effect of not finishing this feature a full year after it was announced at a major company event.

Regarding 2014 - I agree.. in that MS and their products will be synonymous with myspace by then to developers.  But you can't deny the size of MS and their existing install base.  EOL for XP doesn't necessarily mean that bureaucratic organizations like government offices will have upgraded by 2014.

IPv6.. the jury's still out on that one.

The question remains - are we waiting for 2014 or whichever decade will bring IPv6 / end of IE on XP or is there something in the works?

I don't take issue with which decision the GAE team made, but with the fact that they're zigzagging on the availability of the feature.

Amir

[Brandon Wirtz]

I disagree.  I would bet money that Putting a Squid in front of your app would make it faster. Page Level Caching and the ability to put your Image assets in cache are going to make things faster.

 

Also I didn’t say “single” there are plenty of solutions that would do PLC from multiple locations.  Your budget constraint is a limitation.  Not to sound cold, but you knew going in to GAE that HTTPS wasn’t supported, and would have to use an external solution work.  As such it is hard for me really feel that your complaint about having to use an external solution is founded.

 

GAE zigzags, I chalk up to Politics like I said.  I’m sure all the GAE guys know they want HTTPS to work, and I’m sure that they feel silly that it is a feature that doesn’t work. 

--

You received this message because you are subscribed to the Google Groups "Google App Engine" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/9Rs5wZemfCEJ.

[Gregory D'alesandre]

Hey Guys,

I'll try to answer as directly as possible.  We want SSL on custom domains to work.  We are working on getting it to work.  We've been working on it for a very long time now.  Amit, you said you feel as if there have been conflicting messages, while the timeframe has taken longer than we wanted, we've been working on it the whole time and have repeatedly stated that.  As Brandon appropriately highlights there are some things that are in your direct control to just build and some things that aren't.  SSL for custom domains means changing parts of Google's infrastructure to do things that it was not originally designed to do.  We are working with a number of teams at Google to make this happen and we are making progress, but we aren't done yet.

We don't have a date to announce because we'd rather announce it when its done than give you an estimate that could be wrong (and you could be depending on).  We are not building a workaround mostly because as Brandon highlighted workarounds exist so we are putting out time into building the right solution and getting that done as soon as possible.

I hope that helped to clarify,

Greg D'Alesandre

Senior Product Manager, Google App Engine

[Jeff Schnitzer]

Try this out:

http://blog.cloudflare.com/ssl-on-custom-domains-for-appengine-and-other

When our business is ready to launch, this is our intended plan for
always-SSL for our app. Cloudflare does edge caching for all content
too - possibly better than Google's (wholly undocumented and not
guaranteed) edge cache.

I hate to plug a solution that I haven't tried yet, but it looks
promising. Try it out and let me know, or you can wait for my report
towards the end of the year.

Jeff

[johnP]

Jeff - thanks for the link to Cloudflare. It certainly seems like an
interesting option. The risk with implementing them is that it's one
more layer that can fail. Does anyone else have feedback about how
well it works? Also, does anyone have thoughts on whether the other
benefits of Cloudflare (edge-caching and security layer) is relevant
to Appengine users, is it essentially redundant?

[Steve Sherrie]

I too wonder about the availability of cloud fare. I'd like to find out
how it goes for you if you end up using it.

Steve

[Brandon Wirtz]

You will be most unhappy. Many of my SEO clients are FORMER cloudflare
users who found out the hard way that when Cloudflare mistakes Google Bot
for a DDoS Attack they get delisted, or when one of Google's Human Quality
validation techs visit the site and get a captcha challenge they get
Delisted.

Cloudflare also has issues that because adult sites often use it, that they
get blocked by large organizations firewall.

-----Original Message-----
From: google-a...@googlegroups.com
[mailto:google-a...@googlegroups.com] On Behalf Of Steve Sherrie
Sent: Saturday, September 24, 2011 11:51 AM
To: google-a...@googlegroups.com
Subject: Re: [google-appengine] Re: calling out the app engine team on ssl
for custom domains

Steve

--

[Steve Sherrie]

There ya go then.

Steve

[Richard Logwood]

Hi Greg,

Thanks for the insights. While I know everyone who tracks this issue would really appreciate an estimate of any kind, the lack of one raises the priority for implementing a custom domain SSL work around for some users.

Given the discussion in this thread about CloudFlare and reverse proxies, would it be possible for Google to weigh in on some recommended approaches and provide perspective on some of the stated pros and cons discussed here? I think this would be a great help to the community at large today while Google works on the future solution.

Many Thanks,

Richard

[Matthew Prince]

Brandon is both right and wrong. I'd suggest you take his comments with a bit of a grain of salt since he starting a fledging CloudFlare-like service called CDN In A Box. The short answer is: CloudFlare today will not hurt your SEO (and in fact usually helps it fairly significantly) and provides a high availability solution to the AppEngine SSL problem.

Here's the longer answer:

When CloudFlare first began, we did have challenges with Google's crawler. While Brandon's reasoning may seem sound, it's actually an incorrect diagnosis. It was a puzzle for us for a while until we learned what the actual issue was by talking directly with the head of the Google Crawl team. At the root of the problem is the fact that Google sets crawl velocity based on an IP address. If multiple sites share an IP address and one of them has an issue then Google turns down crawl velocity in order to make sure they aren't contributing to excess load on the server that may be causing the problem.

CloudFlare clusters multiple sites behind a pool of IP addresses. If one of those sites has an issue, we faithfully pass through the server error response code. Google's crawler was picking up that error response code and turning down crawl velocity for all the sites using that IP address. As a result, sites that weren't having issues but shared a CloudFlare IP with sites that were had their crawl rates decreased and therefore their SEO hurt.

Google's crawl team had seen this problem before with other major CDNs like Akamai. The way they had dealt with it there was by detecting the CDN's CNAME in the DNS chain and writing a special rule for the crawler. In our case, a CloudFlare CNAME would not always appear in the DNS chain since we may return an IP address of our proxies directly as an A Record, so the solution for other CDNs would not work.

We worked directly with the Google crawl team, as well as the crawl teams from other major search providers, in order to come up with a solution. Today, there are special rules in place for CloudFlare's IP ranges that assign the highest crawl velocity to sites using the IPs. We have an established channel to feed new CloudFlare IPs to the crawl teams as we are allocated them. You can see this yourself if your site is behind CloudFlare by logging in to Google Webmaster Tools and seeing that the option to adjust your crawl rate is no longer available. Search engines know we can handle their maximum crawl load, so they hammer away at us -- which is great for our users. While Brandon is correct that this was a problem before, our work with search crawl teams turned this problem into a feature and it is part of the reason why today being on CloudFlare can help your overall SEO. If you're interested in learning more, I've written about this on our blog:

http://blog.cloudflare.com/cloudflare-and-seo

And, related:

http://blog.cloudflare.com/losing-seo-link-juice-to-traditional-cdns

In terms of SSL and AppEngine, we had a number of users ask if we could help. We spent a significant amount of time building a cloud-based solution that allowed for custom domains to have SSL. Since we'd already built the frontend of that, it was relatively easy for us to extend the solution to the backend and, essentially, mask AppEngine's non-custom domain with your own custom domain. It was minor feature for us, but we've been surprised by how many AppEngine users have adopted it.

Today, CloudFlare powers more than 100,000 websites. We typically will double the performance of a site and add a security layer which you can enable or disable depending on your preferences. If there are ways in which we can make CloudFlare better for the AppEngine community, please don't hesitate to let us know.

Cheers,

Matthew Prince

CEO, CloudFlare

@eastdakota

[Matthew Prince]

Take Brandon's comments with a bit of a grain of salt given that he's trying to launch a CloudFlare-like competitor called CDN in a Box. Here's info on CloudFlare and SEO addressing his speculated concerns:

http://blog.cloudflare.com/cloudflare-and-seo

Short summary: we actually markedly improve most sites' SEO and can help AppEngine users get SSL on a custom domain.

As to the topic at hand, a number of users requested that we provide a way to allow SSL on AppEngine. We added a simple feature to support it and have been surprised how many people have taken advantage of it. Implementing SSL in a cloud-based environment is non-trivial and we spent more than a year, had to form several key partnerships, and developed significant technology, in order to get it to work reliably before we launched CloudFlare. If there are further ways we can help the AppEngine developer community, let us know.

[John Roberts]

I work at CloudFlare, to make my biases crystal clear.

Our service is not harmful to SEO. Here's two blog posts on the topic:

http://blog.cloudflare.com/cloudflare-and-seo

http://blog.cloudflare.com/losing-seo-link-juice-to-traditional-cdns

Brandon, I'm surprised by your assertions, which don't reflect the reality of the more than 100,000 websites using CloudFlare today. We're serving more than 15 billion pageviews/month to more than 350 million unique users/month for our customers' websites.

Brandon, I hope you've shared your background with this audience, so your biases are similarly clear.

On the original topic of this thread -- as posts in issue 792 show, we took steps in July to make SSL available to GAE customers, and we'll continue to do so. We're not a host, and don't see GAE as competition. When GAE offers SSL, customers can still benefit from a global CDN with security by using CloudFlare in conjunction with GAE.

If there are any CloudFlare specific questions, happy to answer them.

John Roberts

first name at cloudflare dot com

[Jeff Schnitzer]

Thank you for taking the time to explain the details.

Jeff

> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.

> To view this discussion on the web visit

> https://groups.google.com/d/msg/google-appengine/-/XNFWzT0YH3gJ.

[Brandon Wirtz]

I have said multiple times our customers don’t align at all, and we started CDN in a Box as a result of the needs of clients who were experiencing issues with CF.  

 

CiaB doesn’t do SSL at all.

 

My concerns aren’t speculated. 

 

http://www.google.com/#sclient=psy-ab&hl=en&source=hp&q=%22This+restriction+will+disappear+when+no+more+harmful+behavior+is+detected.%22&pbx=1&oq=%22This+restriction+will+disappear+when+no+more+harmful+behavior+is+detected.%22&aq=f&aqi=&aql=1&gs_sm=e&gs_upl=18730l20344l2l20823l3l3l0l0l0l0l91l149l2l2l0&bav=on.2,or.r_gc.r_pw.r_cp.&fp=44341265e68b94f2&biw=1021&bih=567

Check out all of these sites that CF has presented the Captcha to Google Crawler. Do this twice and all of a sudden that ranking you had for “Ice cream San Francisco” goes away.

 

 

 

From: google-a...@googlegroups.com [mailto:google-a...@googlegroups.com] On Behalf Of Matthew Prince
Sent: Saturday, September 24, 2011 8:16 PM
To: google-a...@googlegroups.com
Subject: Re: [google-appengine] Re: calling out the app engine team on ssl for custom domains

 

Take Brandon's comments with a bit of a grain of salt given that he's trying to launch a CloudFlare-like competitor called CDN in a Box. Here's info on CloudFlare and SEO addressing his speculated concerns:

--

You received this message because you are subscribed to the Google Groups "Google App Engine" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/_Wllc7sraMMJ.

[Brandon Wirtz]

And I should clarify… Putting “Facebook.Yourdomain.com” on CF for https requests from Facebook, (leaving the rest of the application running not on CF) is probably not a horrible idea.  You’d only be putting user experience at risk if a captcha appeared or CF throttled the connection in a strange way, not your entire site.

[Brandon Wirtz]

In case that Google link didn’t make sense…   That’s 2500 sites (2.5% of CF’s Site base) that have had their site present Google bot with an access denied error.  Not with a 500 error, Not with a 403. With a perfectly happy 200.

 

As to my loyalties and background… CDNinaBox runs on GAE. I’m not likely to make any money selling it to GAE users.

 

Currently CDN In A Box has 150-ish Domains running on it.  Our typical customer is on the service less than 90 days before we move them to a bigger solution, or resolve their issues.  The sites that are on longer are small sites that aren’t looking to scale.  CDN in a Box does NOT view CF as a competitor, we do view them as a lead generator for our SEO services at BlackWaterOps.com in fact, we would make the most money if more people would join Cloud Flare.

 

And when comparing our bias, consider that CF only shows up in this forum when they want to bash me, bash GAE, or claim they handle Proxies correctly and that GAE treats them unfarely. I’m here every day. Multiple times a day, and have maybe promoted my products or services 10 times, and those were for people who were considering building what I already had built, not because I was going to get rich on $20 a month. (I can’t even make that back on the 45 minute call I have with most of those people to help them figure out their issues).

 

 

Brandon Wirtz BlackWaterOps: President / Lead Mercenary
Work: 510-992-6548 Toll Free: 866-400-4536 IM: dra...@gmail.com (Google Talk) Skype: drakegreene BlackWater Ops

 

 

 

 

 

From: google-a...@googlegroups.com [mailto:google-a...@googlegroups.com] On Behalf Of Brandon Wirtz

Sent: Monday, September 26, 2011 12:39 PM
To: google-a...@googlegroups.com

[Matthew Prince]

That's a great list that actually doesn't prove what you think, but it does turn out to prove one of CloudFlare's value propositions. If you look down the list you'll find that a majority are *.blogspot.com domains. By definition, since blogspot.com users can't subdeligate the DNS of blogspot.com subdomains, they cannot be on CloudFlare. So what are they?

Turns out they're pages that web scrapers have pulled from our customers' sites that we've blocked. The content farmer scrapers have then recreated our challenge page on free services like Blogspot. In other words, these aren't CloudFlare's customers, they're people trying to steal content from CloudFlare's customers that we've stopped.

Awesome!

I did find a small handful of actual CloudFlare customers on that list. I dug into them further. While I can't explain their rationale, they've all explicitly blocked Google's crawler from visiting their site, an odd preference we've helped them enforce. I can't find a single example of a challenge page where we've misclassified the Google crawler which makes sense since we've worked directly with the Google crawl team to make sure our service plays well with them.

[Louis Le Coeur]

1.5.5 SDK release and still no mention of SSL whatsoever...

It seems now certain that we won't have it by the end of the year. And it's starting to get really frustrating, at a time where browser support is ubiquitous enough for an SNI-only solution.

When I see all of their other announcements, I can't help thinking : 99.95% SLA? conversion API? but why on earth do they even work on this? why don't they put 100% of their resources on SSL? Do they listen to us at all? And it's a shame because we'd certainly be able to appreciate their otherwise excellent work if they solved this bottleneck.

"When you send a rocket to the moon, focus on the engine first, not the leather seats".

[jon]

+1

On Oct 14, 8:07 pm, Louis Le Coeur <louis.leco...@gmail.com> wrote:
> 1.5.5 SDK release and still no mention of SSL whatsoever...
>
> It seems now certain that we won't have it by the end of the year. And it's
> starting to get really frustrating, at a time where browser support is
> ubiquitous enough for an SNI-only solution.
>
> When I see all of their other announcements, I can't help thinking : 99.95%
> SLA? conversion API? but why on earth do they even work on this? why don't
> they put 100% of their resources on SSL? Do they listen to us at all? And
> it's a shame because we'd certainly be able to appreciate their otherwise
> excellent work if they solved this bottleneck.
>

> *"When you send a rocket to the moon, focus on the engine first, not the
> leather seats".*

[Gregory D'alesandre]

In case you hadn't seen this, I'm sure you'll be happy to know that SSL is now in Trusted Tester: http://groups.google.com/group/google-appengine/browse_thread/thread/d7fb200cbe9d2010#

I DID say we were going to release this as soon as possible and, well, here we are :)

Greg

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.