Overview
The Chrome 80 release, scheduled for February 2020, changes the default cross-domain (SameSite) behavior of cookies. This change enhances security and privacy, but requires customers and partners to test custom integrations that rely on cookies.
The SameSite
attribute on a cookie controls its cross-domain behavior. This Chrome Platform Status explains the intent of the SameSite
attribute.
“SameSite is a reasonably robust defense against some classes of cross-site request forgery (CSRF) attacks, but developers currently need to opt in to its protections by specifying a SameSite attribute. In other words, developers are vulnerable to CSRF attacks by default. This change would allow developers to be protected by default, while allowing sites that require state in cross-site requests to opt in to the status quo’s less-secure model.”
If no SameSite
attribute is specified, the Chrome 80 release sets cookies as SameSite=Lax
by default. Up until the Chrome 80 release, the default is SameSite=None
. After the Chrome 80 release, developers can still opt in to the status quo of unrestricted use by explicitly setting SameSite=None; Secure
.
For more information, see this Chromium blog post.
When Will the Chrome 80 SameSite Changes Go Live?
Google’s SameSite Updates page indicates that the SameSite changes will begin rolling out to Chrome 80 Stable for an initial limited population starting the week of February 17, 2020.
Google stages the stable rollout of Chrome and individual capabilities over time so that any issues can be detected early and addressed before they reach all users. Even though the Chrome 80 release is scheduled to start on February 4, the SameSite changes in Chrome 80 won’t roll out until February 17 or later.
Would AgilePoint NX apps get affected?
If no SameSite attribute is specified, the Chrome 80 release sets cookies as SameSite=Lax by default. Up until the Chrome 80 release, the default is SameSite=None. This means that any first party cookie which was set by the AgilePoint NX module will still continue to be accessible in AgilePoint.
None of the AgilePoint NX modules get affected by this change as they do not rely on cross-domain cookies or resources. All of the AgilePoint NX cookies are only accessed from the domain they are created. As per our test results, following OOTB AgilePoint NX apps continue to work
- AgilePoint NX Portal
- AgilePoint NX App for SharePoint Online
- AgilePoint NX for SharePoint OnPremises
- AgilePoint NX App for Outlook
- AgilePoint NX App for Salesforce
- AgilePoint NX Mobile App for iOS
- AgilePoint NX Mobile App for Android
- Native embedding of AgilePoint NX components in custom portal
There are few key points to be kept in mind
- If you create a custom page using Page Builder module, where you refer to any external resource like a link to an image or video hosted on 3rd party site, any cookie created by that 3rd party site will get blocked by Chrome unless it is marked as SameSite=None. For example, some of the YouTube cookies are still not marked as SameSite=None but does not affect its functionality. If your page functionality depends on this external cookie, that might not work. It is not common scenario but you should check any custom page you have created by turning this feature on before the actual roll out to entire user base by following steps mentioned in Chrome article mentioned earlier in the first section.
- AgilePoint NX eForms does not use any cross domain content except while rendering maps from Google and Bing. The maps itself seem to work as these are mostly tracking cookies and even if they are blocked they are not affecting functionality and eventually Google will change the SameSite setting for those cookies. However if you have written any custom JavaScript in a form where you’ve generated a custom cookie which you use in an external resource which is loaded in the form through an Iframe or otherwise, then that code might have to be evaluated to see the impact. However, this is not common to have such code in your eForms and if you have any such logic in your app, it should be evaluated by your app developer as only your app developer would know why such logic was used. We recommend not to have such cookies created in forms.
- Please note that the Collaboration module in AgilePoint NX Portal does connect to Yammer which is hosted by Microsoft and is considered a cross domain request. However, Microsoft has taken care of adding SameSite=None for its cookie to allow cross domain cookie access, hence it continues to work.
- If you are rendering Work Center and Forms outside of AgilePoint NX Portal in a 3rd party portal, and you have got the native embedding done through AgilePoint Professional Services assistance, that should continue to work, as we are not creating any cross domain cookies and everything is rendered natively in that 3rd party portal. However, we still recommend verifying that everything works by enabling the experimental features in Chrome before you roll out Chrome 80 to entire user base.
- If you use 3rd party authentication or do any other custom integrations using Iframe, those need to be tested before mass rollout.
What Do I Need to Do?
We recommend NOT to upgrade your entire user base to Chrome 80 for next 3-4 weeks or untill you have completed your smoke testing and eventually roll it out gradually after testing is done as explained below.
Though NONE of the out of the box AgilePoint NX modules and apps seem to be affected, there might be some custom implementation done by your developer as explained in previous section, which might get affected. Even though such customization are rare, we highly recommend to test all your apps and forms before rolling out Chrome 80 to your user base.
Moreover, if you have created any custom portal of your own, where you use AgilPoint API’s to bring data but have your own custom UI created, those screens should be tested for any impact. Such UI maintenance would be outside the scope of AgilePoint.
Our recommendation is to selectively upgrade couple of the team member’s laptop to Chrome 80 after 18th Feb and perform a smoke test to see that all your apps, forms and custom portal pages continue to work before you roll out Chrome 80 to rest of user base. Please note that this feature will be enabled by Chrome after 17th Feb so if upgrades are done before that date, testing results won’t be uncovering any potential issues. Therefore, please make sure the apps are tested after Feb 18th on a stable Chrome 80 release before it is certified to be applied to all users.
If you wish to start testing before the Feb 18th release, this Chromium blog post explains how to test the effect of the new Chrome behavior on your site or cookies you manage by navigating to chrome://flags
and enabling the “SameSite by default cookies” and “Cookies without SameSite must be secure” experiments. However please make sure final testing is done on a stable Chrome 80 release after Feb 18th.
If you face any issues with any existing application while rendering in Chrome but works in other browser, first check the Chrome developer tool to see if any of your cookies were blocked. If it does not work in other browsers as well, it might be some other issue with app logic and should be analyzed by application developer at your end. At this time, none of the AgilePoint features are impacted so issue most likely might be somewhere else in your app and not tied to this change introduced by Chrome. If you feel issue is due to this new behavior from Chrome, open Chrome developer tool and if you DO NOT see a message like this in console window of developer tool, then the issue is not tied to Chrome 80.
Even if you see a similar message in console window of developer tool for Chrome, please inspect it carefully to see if the cookie belongs to domain associated with your AgilePoint server. If it has a different domain then it is not tied to AgilePoint. One of the external resources you might be referring to is dependent on cookie. For e.g. in the above screenshot, it shows domain as http://login.microsoftonline.com/ which does not belong to AgilePoint or its installed products. Sometimes an external cookie might be getting blocked but that does not affect functionality. For example, at the time of writing this article, some of the YouTube and Google Map cookies are still not marked as SameSite=None but does not affect its functionality as those are just tracking cookies. There are still quite a lot of website on internet including popular ones which are not yet compliant with the new recommendation from Chrome.
Only Chrome 80+ sets SameSite=Lax
by default. If you encounter an issue with an integration after rolling out the Chrome 80 release, you can temporarily use an unaffected browser, the mobile app, or an older version of Chrome while you implement a fix.
We will continue our testing and monitoring initiative after Feb 18th to see if there is any issue introduced by stable release of Chrome 80. In the lead up to this change, we will use this Knowledge article to capture updates and additional information, so be sure check it periodically.
If you need any assistance from AgilePoint on this topic, please contact AgilePoint Support for more details.