[google-appengine] Re: SSL support
I share your sentiment about the SSL support 100%... it's great to finally
have it but the reality is the ecosystem just isn't ready for SNI yet.
There are still too many browsers that don't support SNI including the
Kindle Fire and every other pre-Ice Cream Sandwich Android device (of which
there are many). To be honest I expect Google to be a better steward of
the Internet. Proper SSL support should be encouraged and offered as an
inherent part any professional web development platform. SSL should NOT be
treated as a major feature upgrade where cost becomes a deciding factor for
adoption. By favoring SNI Google is compromising the integrity of the
browser experience anytime the overwhelming majority of Android users
browse to a secure App Engine site.
The non-SNI supporting browsers I've tested generate big ol' certificate
warnings and strongly encourage users NOT to continue browsing to the site.
Users generally have a choice to continue or not but the warnings sound
quite ominous and make it seem like your illegitimate site is pretending to
be someone else's legitimate site ("the certificate this site is using was
issued for another web address"). Unfortunately, adopting SNI right now
just pollutes the browsing experience and makes your site seem shady.
With Internet Explorer if the user clicks through the certificate warning
and continues to you site, the URL input bar stays highlighted with a red
background and an intimidating "certificate error" message is displayed to
the right of the URL.
I'm all for Google profiting from App Engine but it seems like there are
enough other opportunities for that since they monitor and charge for just
about everything else. I'm still hoping there's enough "don't be evil"
within Google that they decide to favor a seamless browsing experience over
a pay-for-proper-security profit grab. Perhaps in another 3-5 years the
ecosystem will be more accommodating of SNI but unfortunately that day
isn't here yet.
On Wednesday, July 18, 2012 3:02:20 PM UTC-4, GAEfan wrote:
>
> So happy to see SSL support finally here, but a bit disappointed. VIP
> seems the way to go, but at $99 per month, it is cost prohibitive for some
> of our apps. So, I am asking for feedback from others who have implemented
> SNI. From my understanding, there are still many visitors with older
> browsers who will not be able to use it. Is that correct?
>
> Looking at recent stats, we have 16% of our visitors with IE 6 or 7. And
> an astounding 43% with XP or previous versions of Windows. Not to mention
> those with Safari/Win, or older Android OS. What will these visitors see
> when they try to access an SNI-SSL page?
>
> Any problems/issues encountered with SNI implementations? Older browsers?
> International visitors? Frankly, at $108/year PLUS the certificate, even
> SNI-SSL is expensive. But $1200/year, plus cert, for VIP is not feasible
> for smaller apps. (IMO, $108/year should cover virtual IP). Sticking with
> our appspot URLs for SSL until this is ready for prime time. We are not
> willing to abandon even a small single-digit percentage of our users.
>
> Also, I recently was told that some search engines use the IP address in
> page ranking. Shared IPs are penalized. Had not heard that before, and
> not sure that is accurate, as a majority of sites are on shared-IPs.
>
> Your feedback greatly appreciated.
>
>
>
--
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/-/HUXzIEE43doJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.
[google-appengine] Re: SSL support
> site seem shady. With Internet Explorer if the user clicks through the > certificate warning and continues to you site, the URL input bar stays > highlighted with a red background and an intimidating "certificate error" > message is displayed to the right of the URL. > IE8 doesn't work at all for us with SNI: "Internet Explorer cannot display the webpage" Talking about costs, something like Page Speed is terribly expensive, and also Cloud Storage, an extra bill... -- 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/-/c2M8xhINiLcJ. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
Re: [google-appengine] Re: SSL support
http://blorn.com/post/20185054195/ssl-for-your-domain-on-google-app-engine
It still works and it's still $20/mo. Yes, it's unencrypted between
CF and Google. Assuming you aren't taking credit cards directly, is
that a problem?
Jeff
On Wed, Jul 18, 2012 at 2:39 PM, Doug Anderson wrote:
> I share your sentiment about the SSL support 100%... it's great to finally
> have it but the reality is the ecosystem just isn't ready for SNI yet.
> There are still too many browsers that don't support SNI including the
> Kindle Fire and every other pre-Ice Cream Sandwich Android device (of which
> there are many). To be honest I expect Google to be a better steward of
> the Internet. Proper SSL support should be encouraged and offered as an
> inherent part any professional web development platform. SSL should NOT be
> treated as a major feature upgrade where cost becomes a deciding factor for
> adoption. By favoring SNI Google is compromising the integrity of the
> browser experience anytime the overwhelming majority of Android users browse
> to a secure App Engine site.
>
> The non-SNI supporting browsers I've tested generate big ol' certificate
> warnings and strongly encourage users NOT to continue browsing to the site.
> Users generally have a choice to continue or not but the warnings sound
> quite ominous and make it seem like your illegitimate site is pretending to
> be someone else's legitimate site ("the certificate this site is using was
> issued for another web address"). Unfortunately, adopting SNI right now
> just pollutes the browsing experience and makes your site seem shady. With
> Internet Explorer if the user clicks through the certificate warning and
> continues to you site, the URL input bar stays highlighted with a red
> background and an intimidating "certificate error" message is displayed to
> the right of the URL.
>
> I'm all for Google profiting from App Engine but it seems like there are
> enough other opportunities for that since they monitor and charge for just
> about everything else. I'm still hoping there's enough "don't be evil"
> within Google that they decide to favor a seamless browsing experience over
> a pay-for-proper-security profit grab. Perhaps in another 3-5 years the
> ecosystem will be more accommodating of SNI but unfortunately that day isn't
> here yet.
>
>
> On Wednesday, July 18, 2012 3:02:20 PM UTC-4, GAEfan wrote:
>>
>> So happy to see SSL support finally here, but a bit disappointed. VIP
>> seems the way to go, but at $99 per month, it is cost prohibitive for some
>> of our apps. So, I am asking for feedback from others who have implemented
>> SNI. From my understanding, there are still many visitors with older
>> browsers who will not be able to use it. Is that correct?
>>
>> Looking at recent stats, we have 16% of our visitors with IE 6 or 7. And
>> an astounding 43% with XP or previous versions of Windows. Not to mention
>> those with Safari/Win, or older Android OS. What will these visitors see
>> when they try to access an SNI-SSL page?
>>
>> Any problems/issues encountered with SNI implementations? Older browsers?
>> International visitors? Frankly, at $108/year PLUS the certificate, even
>> SNI-SSL is expensive. But $1200/year, plus cert, for VIP is not feasible
>> for smaller apps. (IMO, $108/year should cover virtual IP). Sticking with
>> our appspot URLs for SSL until this is ready for prime time. We are not
>> willing to abandon even a small single-digit percentage of our users.
>>
>> Also, I recently was told that some search engines use the IP address in
>> page ranking. Shared IPs are penalized. Had not heard that before, and not
>> sure that is accurate, as a majority of sites are on shared-IPs.
>>
>> Your feedback greatly appreciated.
>>
>>
> --
> 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/-/HUXzIEE43doJ.
>
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.
Re: [google-appengine] Re: SSL support
Hi all,
I am the Product Manager on App Engine responsible for SSL.
There seems to be a little bit of confusion about how VIPs can be used. A
single VIP can be used for a number of applications via the use of a
wildcard or multi-domain/SAN certificate. Multiple domain (domain.com and
domain.net) support can be achieved by adding the additional domain as an
alias of your primary domain and using a multi-domain/SAN certificate.
Regarding the concerns about browser support for SNI, SNI is supported by
most modern browsers with a few exceptions, notably Internet Explorer and
Safari on Windows XP as well as Android 2.2 and below. Please note that
this is not all browsers on Windows XP simply IE and Safari, Chrome and
Firefox will work on XP without issue.
I would also like to clarify what happens when a user with a browser that
does not support SNI visits an App Engine application being served over
SNI. If the page is being served over HTTP there will be no issues. If the
site is being served over HTTPS the browser will be unable to connect.
This is a decision we made to stop users being presented with security
warnings which may give them a negative impression of the site. We
recommend warning users who visit your application (over HTTP) using a
browser that does not support SNI to install a browser which does support
SNI (such as Chrome or Firefox) .
I hope this addresses some of the questions raised in this thread.
Cheers,
Cayden Meyer
Product Manager, Google App Engine
On 19 July 2012 10:07, Jeff Schnitzer wrote:
> http://blorn.com/post/20185054195/ssl-for-your-domain-on-google-app-engine
>
> It still works and it's still $20/mo. Yes, it's unencrypted between
> CF and Google. Assuming you aren't taking credit cards directly, is
> that a problem?
>
> Jeff
>
> On Wed, Jul 18, 2012 at 2:39 PM, Doug Anderson
> wrote:
> > I share your sentiment about the SSL support 100%... it's great to
> finally
> > have it but the reality is the ecosystem just isn't ready for SNI yet.
> > There are still too many browsers that don't support SNI including the
> > Kindle Fire and every other pre-Ice Cream Sandwich Android device (of
> which
> > there are many). To be honest I expect Google to be a better steward of
> > the Internet. Proper SSL support should be encouraged and offered as an
> > inherent part any professional web development platform. SSL should NOT
> be
> > treated as a major feature upgrade where cost becomes a deciding factor
> for
> > adoption. By favoring SNI Google is compromising the integrity of the
> > browser experience anytime the overwhelming majority of Android users
> browse
> > to a secure App Engine site.
> >
> > The non-SNI supporting browsers I've tested generate big ol' certificate
> > warnings and strongly encourage users NOT to continue browsing to the
> site.
> > Users generally have a choice to continue or not but the warnings sound
> > quite ominous and make it seem like your illegitimate site is pretending
> to
> > be someone else's legitimate site ("the certificate this site is using
> was
> > issued for another web address"). Unfortunately, adopting SNI right now
> > just pollutes the browsing experience and makes your site seem shady.
> With
> > Internet Explorer if the user clicks through the certificate warning and
> > continues to you site, the URL input bar stays highlighted with a red
> > background and an intimidating "certificate error" message is displayed
> to
> > the right of the URL.
> >
> > I'm all for Google profiting from App Engine but it seems like there are
> > enough other opportunities for that since they monitor and charge for
> just
> > about everything else. I'm still hoping there's enough "don't be evil"
> > within Google that they decide to favor a seamless browsing experience
> over
> > a pay-for-proper-security profit grab. Perhaps in another 3-5 years the
> > ecosystem will be more accommodating of SNI but unfortunately that day
> isn't
> > here yet.
> >
> >
> > On Wednesday, July 18, 2012 3:02:20 PM UTC-4, GAEfan wrote:
> >>
> >> So happy to see SSL support finally here, but a bit disappointed. VIP
> >> seems the way to go, but at $99 per month, it is cost prohibitive for
> some
> >> of our apps. So, I am asking for feedback from others who have
> implemented
> >> SNI. From my understanding, there are still many visitors with older
> >> browsers who will not be able to use it. Is that correct?
> >>
> >> Looking at recent stats, we have 16% of our visitors with IE 6 or 7.
> And
> >> an astounding 43% with XP or previous versions of Windows. Not to
> mention
> >> those with Safari/Win, or older Android OS. What will these visitors
> see
> >> when they try to access an SNI-SSL page?
> >>
> >> Any problems/issues encountered with SNI implementations? Older
> browsers?
> >> International visitors? Frankly, at $108/year PLUS the certificate,
> even
> >> SNI-SSL is expensive. But $1200/year, plus cert, for VIP is not
> feasible
> >
Re: [google-appengine] Re: SSL support
Hi Cayden,
thanks for your input, but I have to ask, in what way does preventing a
browser from connecting to a site not give the visitor a negative
impression of that site? Is it better that the visitor thinks the site is
not available at all?
I think you may be downplaying the number of incompatible browsers in use
today. Ignoring XP, Google's Nexus One got Android 2.2 just 2 years ago, a
common contract period for mobiles.. so how many pre-2.2 Android phones
have been sold since then?
Just to clarify.. your suggested solution, if using SNI to provide a secure
website and wanting to somewhat support non-SNI browsers would be:
- never publicise secure urls
for each connection:
- detect the browser and decide whether or not the browser supports SNI (a
mostly accurate guess based on a list of browsers in your code)
- either redirect to the secure url, warn the user and tell them to
install a new browser, or just serve up the unsecured content.
cheers,
J
On Thu, Jul 19, 2012 at 1:18 PM, Cayden Meyer wrote:
> Hi all,
>
> I am the Product Manager on App Engine responsible for SSL.
>
> There seems to be a little bit of confusion about how VIPs can be used. A
> single VIP can be used for a number of applications via the use of a
> wildcard or multi-domain/SAN certificate. Multiple domain (domain.com and
> domain.net) support can be achieved by adding the additional domain as an
> alias of your primary domain and using a multi-domain/SAN certificate.
>
> Regarding the concerns about browser support for SNI, SNI is supported by
> most modern browsers with a few exceptions, notably Internet Explorer and
> Safari on Windows XP as well as Android 2.2 and below. Please note that
> this is not all browsers on Windows XP simply IE and Safari, Chrome and
> Firefox will work on XP without issue.
>
> I would also like to clarify what happens when a user with a browser that
> does not support SNI visits an App Engine application being served over
> SNI. If the page is being served over HTTP there will be no issues. If the
> site is being served over HTTPS the browser will be unable to connect.
> This is a decision we made to stop users being presented with security
> warnings which may give them a negative impression of the site. We
> recommend warning users who visit your application (over HTTP) using a
> browser that does not support SNI to install a browser which does support
> SNI (such as Chrome or Firefox) .
>
> I hope this addresses some of the questions raised in this thread.
>
> Cheers,
>
> Cayden Meyer
> Product Manager, Google App Engine
>
>
>
> On 19 July 2012 10:07, Jeff Schnitzer wrote:
>
>> http://blorn.com/post/20185054195/ssl-for-your-domain-on-google-app-engine
>>
>> It still works and it's still $20/mo. Yes, it's unencrypted between
>> CF and Google. Assuming you aren't taking credit cards directly, is
>> that a problem?
>>
>> Jeff
>>
>> On Wed, Jul 18, 2012 at 2:39 PM, Doug Anderson
>> wrote:
>> > I share your sentiment about the SSL support 100%... it's great to
>> finally
>> > have it but the reality is the ecosystem just isn't ready for SNI yet.
>> > There are still too many browsers that don't support SNI including the
>> > Kindle Fire and every other pre-Ice Cream Sandwich Android device (of
>> which
>> > there are many). To be honest I expect Google to be a better steward
>> of
>> > the Internet. Proper SSL support should be encouraged and offered as an
>> > inherent part any professional web development platform. SSL should
>> NOT be
>> > treated as a major feature upgrade where cost becomes a deciding factor
>> for
>> > adoption. By favoring SNI Google is compromising the integrity of the
>> > browser experience anytime the overwhelming majority of Android users
>> browse
>> > to a secure App Engine site.
>> >
>> > The non-SNI supporting browsers I've tested generate big ol' certificate
>> > warnings and strongly encourage users NOT to continue browsing to the
>> site.
>> > Users generally have a choice to continue or not but the warnings sound
>> > quite ominous and make it seem like your illegitimate site is
>> pretending to
>> > be someone else's legitimate site ("the certificate this site is using
>> was
>> > issued for another web address"). Unfortunately, adopting SNI right now
>> > just pollutes the browsing experience and makes your site seem shady.
>> With
>> > Internet Explorer if the user clicks through the certificate warning and
>> > continues to you site, the URL input bar stays highlighted with a red
>> > background and an intimidating "certificate error" message is displayed
>> to
>> > the right of the URL.
>> >
>> > I'm all for Google profiting from App Engine but it seems like there are
>> > enough other opportunities for that since they monitor and charge for
>> just
>> > about everything else. I'm still hoping there's enough "don't be evil"
>> > within Google that they decide to favor a seamless browsing experience
>> over
>> > a pay-for-proper-securi
Re: [google-appengine] Re: SSL support
Hi Jason, We offer both SNI and VIP to give you options between price and better browser compatibility. If it is important to you to have full compatibility with all browsers or a particular subset that does not support SNI such as Android 2.2 then using a VIP is the best option. If you wish to use SNI and give users without SNI support the best possible experience then there are a few things you can do such as what I suggested in my previous post. Your summary of my suggestion is one way of supporting non-SNI browsers when using SNI. In the case of Android 2.2 or below, apart from the suggestions already mentioned there is also the option of having an Android application which connects securely to your application's appspot.com address. Cheers, Cayden Meyer Product Manager, Google App Engine On 19 July 2012 14:03, Jason Galea wrote: > Hi Cayden, > > thanks for your input, but I have to ask, in what way does preventing a > browser from connecting to a site not give the visitor a negative > impression of that site? Is it better that the visitor thinks the site is > not available at all? > > I think you may be downplaying the number of incompatible browsers in use > today. Ignoring XP, Google's Nexus One got Android 2.2 just 2 years ago, a > common contract period for mobiles.. so how many pre-2.2 Android phones > have been sold since then? > > Just to clarify.. your suggested solution, if using SNI to provide a > secure website and wanting to somewhat support non-SNI browsers would be: > > - never publicise secure urls > for each connection: > - detect the browser and decide whether or not the browser supports SNI > (a mostly accurate guess based on a list of browsers in your code) > - either redirect to the secure url, warn the user and tell them to > install a new browser, or just serve up the unsecured content. > > cheers, > > J > > > > > On Thu, Jul 19, 2012 at 1:18 PM, Cayden Meyer wrote: > >> Hi all, >> >> I am the Product Manager on App Engine responsible for SSL. >> >> There seems to be a little bit of confusion about how VIPs can be used. A >> single VIP can be used for a number of applications via the use of a >> wildcard or multi-domain/SAN certificate. Multiple domain (domain.comand >> domain.net) support can be achieved by adding the additional domain as >> an alias of your primary domain and using a multi-domain/SAN certificate. >> >> Regarding the concerns about browser support for SNI, SNI is supported by >> most modern browsers with a few exceptions, notably Internet Explorer and >> Safari on Windows XP as well as Android 2.2 and below. Please note that >> this is not all browsers on Windows XP simply IE and Safari, Chrome and >> Firefox will work on XP without issue. >> >> I would also like to clarify what happens when a user with a browser that >> does not support SNI visits an App Engine application being served over >> SNI. If the page is being served over HTTP there will be no issues. If the >> site is being served over HTTPS the browser will be unable to connect. >> This is a decision we made to stop users being presented with security >> warnings which may give them a negative impression of the site. We >> recommend warning users who visit your application (over HTTP) using a >> browser that does not support SNI to install a browser which does support >> SNI (such as Chrome or Firefox) . >> >> I hope this addresses some of the questions raised in this thread. >> >> Cheers, >> >> Cayden Meyer >> Product Manager, Google App Engine >> >> >> >> On 19 July 2012 10:07, Jeff Schnitzer wrote: >> >>> >>> http://blorn.com/post/20185054195/ssl-for-your-domain-on-google-app-engine >>> >>> It still works and it's still $20/mo. Yes, it's unencrypted between >>> CF and Google. Assuming you aren't taking credit cards directly, is >>> that a problem? >>> >>> Jeff >>> >>> On Wed, Jul 18, 2012 at 2:39 PM, Doug Anderson >>> wrote: >>> > I share your sentiment about the SSL support 100%... it's great to >>> finally >>> > have it but the reality is the ecosystem just isn't ready for SNI yet. >>> > There are still too many browsers that don't support SNI including the >>> > Kindle Fire and every other pre-Ice Cream Sandwich Android device (of >>> which >>> > there are many). To be honest I expect Google to be a better steward >>> of >>> > the Internet. Proper SSL support should be encouraged and offered as >>> an >>> > inherent part any professional web development platform. SSL should >>> NOT be >>> > treated as a major feature upgrade where cost becomes a deciding >>> factor for >>> > adoption. By favoring SNI Google is compromising the integrity of the >>> > browser experience anytime the overwhelming majority of Android users >>> browse >>> > to a secure App Engine site. >>> > >>> > The non-SNI supporting browsers I've tested generate big ol' >>> certificate >>> > warnings and strongly encourage users NOT to continue browsing to the >>> site. >>> > Users generally have a choice to
Re: [google-appengine] Re: SSL support
> > Hi Cayden, > Thank you for responding, as this is an extremely important issue. Google has always stated their objective was to make the internet better, faster, easier. However, this SSL solution is a less-than-expected solution. 1) Charging $99/month for an acceptable solution puts a real roadblock in the SSL chain. Shouldn't Google want to make SSL ubiquitous, as part of their objective? $99/year is more of an acceptable rate, though still about double what it should be. $1200/year prices SSL out of the budget for smaller apps, and seems usurious. 2) I, too, think you are downplaying the incompatibility of the SNI solution. I believe that somewhere near 15% of visitors cannot use the SNI solution. We are not willing to block even 1% of our visitors. We pay Google AdWords too much to get them, just to turn them away again. I cannot believe Google would even consider SNI is an acceptable solution, turning away web visitors. 3) Detecting browsers and redirecting is a waste of resources. 4) Serving insecure content (when security is warranted) is unacceptable. 5) Breaking the security chain without informing the visitor is unacceptable. 6) Detecting browsers, and serving up a "Go away and download a better browser" message is absurd! Talk about giving the visitor a negative impression of your site. In summary, SNI is a poor solution, and not up to Google standards. VIP is a fine solution, but priced absurdly. -- 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/-/rbFBHQ4R29EJ. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
Re: [google-appengine] Re: SSL support
We were happy enough to go with the SNI solution. We don't have mobile users on our web interface, and we are yet to receive a complaint from an irate Windows XP user. We detect what browser and OS a client has, and if it's not SNI friendly we show them a warning: http://imgur.com/a/Axzur As you can see from the table in the above link even on XP you have options (via other browsers that suck less). On 19 July 2012 15:54, GAEfan wrote: > Hi Cayden, >> > > Thank you for responding, as this is an extremely important issue. > Google has always stated their objective was to make the internet better, > faster, easier. However, this SSL solution is a less-than-expected > solution. > > 1) Charging $99/month for an acceptable solution puts a real roadblock in > the SSL chain. Shouldn't Google want to make SSL ubiquitous, as part of > their objective? $99/year is more of an acceptable rate, though still > about double what it should be. $1200/year prices SSL out of the budget > for smaller apps, and seems usurious. > 2) I, too, think you are downplaying the incompatibility of the SNI > solution. I believe that somewhere near 15% of visitors cannot use the SNI > solution. We are not willing to block even 1% of our visitors. We pay > Google AdWords too much to get them, just to turn them away again. I > cannot believe Google would even consider SNI is an acceptable solution, > turning away web visitors. > 3) Detecting browsers and redirecting is a waste of resources. > 4) Serving insecure content (when security is warranted) is unacceptable. > 5) Breaking the security chain without informing the visitor is > unacceptable. > 6) Detecting browsers, and serving up a "Go away and download a better > browser" message is absurd! Talk about giving the visitor a negative > impression of your site. > > In summary, SNI is a poor solution, and not up to Google standards. VIP > is a fine solution, but priced absurdly. > > > -- > 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/-/rbFBHQ4R29EJ. > > To post to this group, send email to google-appengine@googlegroups.com. > To unsubscribe from this group, send email to > google-appengine+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
Re: [google-appengine] Re: SSL support
On Thursday, July 19, 2012 7:10:44 AM UTC+2, Cayden Meyer wrote: > > > We offer both SNI and VIP to give you options between price and better > browser compatibility. > Thanks, Cayden, but hopefully you can explain something I'm a bit confused about. What is Cloudflare doing that Google can't (or won't) with respect to SSL? Browsers don't seem to be restricted on the CF solution. Why can't Google simply re-create a CF-like SSL proxy within Google, with similar costs? -- 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/-/WB_sMUMpzikJ. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
Re: [google-appengine] Re: SSL support
The most basic question here is how Google can justify the costs they are having with providing dedicated IP V4 addresses. In one of the Google IO sessions got mentioned that it would cost them a lot of money to provide dedicated IP's, therefore $99 would be a reasonable price tag ..?! Come on - have a look at EC2. What do you pay there per dedicated IP address? Right, zero! They won't event charge you additional fees for running SSL traffic through their ELB load balancers. It's the same costs, HTTP or HTTPS don't matter. And when it comes to additional IP's, here's what's the 'industry standard' costs are: $0.005 per additional Elastic IP address associated with a running instance per hour on a pro rata basis That's right, max $ 3.72 per month. Give me a break, but as long as the VIP costs aren't lowered to industry standard prices I have no intentions in moving any of my EC2 user facing frontend stuff over to App Engine. -- 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/-/bzm_ilNDzmkJ. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
Re: [google-appengine] Re: SSL support
Just to follow up, 1.75 years later... Year to date, via analytics: 64% of our visitors use Windows 13% of those use XP 31% of those use IE So, that equals 2.6% of our visitors. 4% of our visitors use Android, of various versions. I am not sure which version, if any, fixed the SNI certificate security warning. So, if we used the SNI version, somewhere between 4-6% of our visitors would not be able to use the SSL. That is still too high. We spend too much to get our visitors, to just send 5% of them away with a bad experience. We could try redirecting the XP/IE and Android visitors to the secure appspot domain. Still not ideal, but a solution. A much better solution would be $99 per year for VIP. -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/d/optout.
Re: [google-appengine] Re: SSL support
> > Just to follow up, 1.75 years later... > > Year to date, via analytics: > > 64% of our visitors use Windows > 13% of those use XP > 31% of those use IE > > So, that equals 2.6% of our visitors. 4% of our visitors use Android, of > various versions. I am not sure which version, if any, fixed the SNI > certificate security warning. > > So, if we used the SNI version, somewhere between 4-6% of our visitors > would not be able to use the SSL. That is still too high. We spend too > much to get our visitors, to just send 5% of them away with a bad > experience. > > We could try redirecting the XP/IE and Android visitors to the secure > appspot domain. Still not ideal, but a solution. > > A much better solution would be $99 per year for VIP. > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/d/optout.
Re: [google-appengine] Re: SSL support
+1 I've always said SSL on GAE should be free... Google should encourage secure connections. App Engine has us surrounded with enough other toll booths that charging for SSL seems completely unnecessary. It sets the baseline cost artificially high for apps that want to use a custom domain (I have to believe most apps want security these days with their custom domain). - Doug On Friday, March 7, 2014 5:27:31 PM UTC-5, GAEfan wrote: > > Just to follow up, 1.75 years later... >> >> Year to date, via analytics: >> >> 64% of our visitors use Windows >> 13% of those use XP >> 31% of those use IE >> >> So, that equals 2.6% of our visitors. 4% of our visitors use Android, of >> various versions. I am not sure which version, if any, fixed the SNI >> certificate security warning. >> >> So, if we used the SNI version, somewhere between 4-6% of our visitors >> would not be able to use the SSL. That is still too high. We spend too >> much to get our visitors, to just send 5% of them away with a bad >> experience. >> >> We could try redirecting the XP/IE and Android visitors to the secure >> appspot domain. Still not ideal, but a solution. >> >> A much better solution would be $99 per year for VIP. >> > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/d/optout.
[google-appengine] Re: SSL support - urllib2.HTTPSHandler() does not exist?
Appengine does not support urllib, instead use urlfetch http://code.google.com/appengine/docs/python/sandbox.html see http://code.google.com/appengine/docs/urlfetch/overview.html 2008/12/22 govno3...@gmail.com : > > Does python running inside appengine support SSL? I'm getting error > that urllib2.HTTPSHandler() does not exist: > > AttributeError: 'module' object has no attribute 'HTTPSHandler' > > So the question is: can app engine connect to outside world using SSL? > > > > -- Barry - www.nearby.org.uk - www.geograph.org.uk - --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
