Skip to Content

Security Protections May Break Embedded Google Forms for Some Users

Info & Background

A potentially annoying protection–which all modern browsers enforce–may be to blame for embedded Google Forms to not load for some users. There is a possibility that other Google services, or other embedded widgets from any site, could break under similar conditions.

Jump to a workaround.

Background

Recently web services was contacted for help with a problemistic, embedded Google form. Neither the containing page changed or form were changed recently, but the problems came up anyways. The form simply showed as a blank white area of the page. Not all users saw this behavior, alternatively seeing the form as usual.

It was found that the people who could not load the form were using a browser which had previously logged into a Google (or @cas.uoregon.edu email) Service, which changes the behavior of Google Forms. No solution exists to prevent this on the user’s end, but workarounds do.

Symptoms

The following would likely be observed on an affected embed:

  • inconsistent problems loading the page containing the embedded form, doc, spreadsheet, etc.
  • inconsistent success or failure loading the page on different computers for the same user
  • for those who could not load the embedded form, only a blank “frame” or rectangular white area will appear ; the page should not hang when loading, it simply wouldn’t try to load the form (at least because of this problem)
  • privileges to see the form are not to blame (is public)

Cause

The inability to load the form was caused by a protection put in place to prevent cross-site attacks and other potential security concerns on the web. All modern browsers should honor this standard. Google’s signin page notifies the browser that the page should only load if it is in its own window (or tab), but never in a frame. Google Forms are added to a page by “embedding” their page into a frame (iframe). Generally this is fine, as long as the form is public or the user has some sort of key to load the form.

If a user has a cookie which identifies that they have recently signed into Google, Google will forward the form page to the signin page (even if the form is public). It does so because some info can be pulled into the form when they sign in, as a courtesy enabled by the form builder, so the user does not have to type their name and phone number (etc.) into 50,000 forms during their lifetime. Although their intentions are good, the login page has a setting which blocks loading in frames (passed as part of the headers which describe page properties). This is the situation which is to blame.

Solution

None, see workaround.

There is no solution to prevent this problem, and hopefully never will be because of security concerns (unless Google changes the way Drive technology is set up).

Workaround

The user should be told, or instructions added to the page, to please do one of these four options (in my personal order of preference):

  1. load the page using a private session/window/tab (called Incognito for Chrome, Private Window for Firefox, Private Browsing for Safari, and InPrivate for Internet Explorer)
  2. load the page using a different browser which has not logged into Google (at least recently)
  3. reload the page after first clearing or disabling their cookies (at least the Google ones)
  4. link to the form using the shareable link (provided by google) instead, or in addition to, embedding

Credit

This forum discussion led me to the workaround and cause for this problem: https://productforums.google.com/d/topic/docs/StVq39J3lCA/discussion

– Cameron Seright, Analyst Programmer