Hi Evan, Thanks for your detailed analysis! This is extremely helpful. We're aware of the issues now, but they may be challenging to solve. We're working on it.
Best, Josh Estelle Senior Software Engineer Google Translate On Aug 25, 8:53 am, Evan wrote: > Hello all, > > I've decided to start one final thread regarding the SSL issue, which > will hopefully lead to a constructive conversation that leads to a > permanent fix once and for all. > > The issue: you embed Google's website translator (http:// > translate.google.com/translate_tools) on your site, only to find that > if your site uses SSL, IE greets you with that lovely security prompt > about secure and insecure items. > > To answer the immediate questions: > Yes, Google knows about the issue. > No, Google has not given a timeframe on when it will be fully > resolved. > > Please don't post to this thread to ask when/if this has been fixed. > There are discussions all over this group about this issue. My goal is > to promote a constructive conversation, hopefully with the > participation of someone from Google (wink, wink Josh) that helps lead > to this issue being resolved. > > Some background on the issue: > > Originally, when Google released this tool, they had not prepared it > for use in SSL sites yet (although there were hints in their code that > they had planned on supporting SSL eventually). Many elements were > statically called via the JS and CSS to load via HTTP, not HTTPS. This > of course would trigger the security prompt in IE. > > On February 16th, Josh from Google acknowledged the issue after it had > been reported and confirmed in this > thread:http://groups.google.com/group/google-translate-general/browse_thread... > > Two days later, on February 18th, Josh mentioned that he had > implemented the fix on their end and that it would be pushed out a few > days later. On March 3rd, Josh confirmed that the fix was live and > that we could start referencing the element.js file via https:// to > resolve the issue. > > Following that, people continued to complain that they were still > experiencing the same issue, however Josh confirmed that all of the > resources were being loaded correctly via SSL. > > So what's going on here? Well, I decided to finally spend some time > really digging into the issue to find out what's going on, and I think > I've got if figured out for the most part. > > Josh did indeed solve most of the issues and all of the elements > really are loading via SSL as Josh insists... However, the claims > about still getting the security warnings after the fix are, indeed, > valid. Here is what's going on: > > Issue #1: Cookies being set by the translate.googleapis.com andwww.google.com > servers are causing the eyeball with a red warning icon (indicating > blocked cookies) to appear in IE with default security settings. It > doesn't matter if the resources are loaded via SSL or not, IE will > show the little warning icon no matter what as long as those servers > are returning the Set-Cookie header. The problem-files include: > > https://www.google.com/images/cleardot.gifhttps://www.google.com/intl/{locale}/images/logos/translate_logo_sm.pnghttps://www.google.com/images/zippy_minus_sm.gifhttps://www.google.com/images/zippy_plus_sm.gifhttps://translate.googleapis.com/translate_static/js/element/main.jshttps://translate.googleapis.com/translate_static/css/translateelemen...https://translate.googleapis.com/translate_static/img/mini_google.pnghttps://translate.googleapis.com/translate_static/img/te_bk.gifhttps://translate.googleapis.com/translate_static/img/loading.gifhttps://translate.googleapis.com/translate_static/img/te_ctrl3.gifhttps://translate.googleapis.com/translate_a/l?client=te&hl={lang}&cb=_callbacks_._{callback} > I'm not positive if requests > tohttps://translate.googleapis.com/translate_static/js/element/hrs.swf > are trying to set a cookie, but in my testing, that request was > working fine as-is. > > Issue #2: The JS > inhttps://translate.googleapis.com/translate_static/js/element/main.js > is dynamically creating some iframe elements, which is exposing an > obscure IE bug that falsely triggers the "This page contains secure > and nonsecure items." warning... The cause of this is the JS > generating an iframe with either no src attribute or an src attribute > of something like, javascript:''. The solution (work-around) is to set > the src attribute to a blank file that's hosted via https; something > like /static/blank.html. I imagine this could be done conditionally > for only the affected version of IE to avoid unnecessary HTTPS > requests, and that Google could make it point to a blank file on their > servers to keep the issue transparent to people implementing the > website translator. If Google does this, I'd like to just remind them > to make sure that the additional blank file being requested also does > _not_ attempt to set any cookies, else we'll still end up getting that > warning icon in the status bar of IE. > > I've implemented a quick and dirty fix on our site that addresses the > above issues. I manually patched the main.js for the iframe issue > (pointed them to a blank file on our server) and hosted the static > elements on our own server to prevent the cookie problem (I also > updated translateelement.css and did some other proxy magic for the > dynamic bits that I won't go into here). You can test it out for > yourself to see that it works onhttps://www.southwestmedical.com/ > (translate widget is on the bottom right) > > I've published an uncompressed version of what I did to the main.js > for > reference:https://www.southwestmedical.com/js/google-translate-https-fix-main.j... > Each modification is below a commented out version of the original > line... You can find my modifications by searching the file for the > word "iframe" or " //". I'm publishing the patched code for reference > ONLY, to help move us toward a fix. I do not recommend others try to > duplicate my work-around, as it's not a clean way to address the > issue, it's fairly complicated (there's more going on behind the > scenes than just the patched main.js), and it's subject to breaking in > the future if Google changes anything on their end. > > Hopefully these extra details help Google to finally get this issue > fully resolved though! I'd really like to finally see this issue put > to rest and be able to get rid of the ugly patched code on our site. > If anyone has any questions or constructive input to add, feel free to > post. > > For what it's worth: my development environment is Fedora 13 and I did > testing on XP SP3 with IE6 via VirtualBox OSE. I have verified my > solution is working on IE6+ on Windows, the latest Opera on Windows > and Linux, the latest Firefox on Windows and Linux, and the latest > Chrome on Windows and Linux. At the moment, I do not have a Mac for > testing. If I test any additional configurations, I'll follow up. > > I also noticed a couple of unrelated bugs, that maybe deserve their > own thread: > - In every browser I tested except for Chrome (5.0.375.127 on Windows > and Linux), the translate widget seems to "remember" what language it > was on and initiate the translation again once a subsequent page > loads. In Chrome, it always goes reverts back to no translation when > you go to another page. > - In the latest Safari (5.0.1 on Windows, did not test on a Mac) the > translate widgit does not seem to appear at all. I haven't looked into > the code to see if this is an intentional omission, or if it's > actually a bug, but figured I'd mention it anyway. > > Thanks, > Evan -- You received this message because you are subscribed to the Google Groups "General" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-translate-general?hl=en.
