Updated Next week Google is scheduled to release Chrome 80 to its stable channel, and says only 'a very modest amount of breakage' of websites is expected.
Google Chrome 80.0.3987.87 (offline installer) By Razvan Serea News Reporter Neowin Feb 5, 2020 00:06 EST Hot!
- Google Chrome is a fast, simple, and secure web browser, built for the modern web. Speed Chrome is designed to be fast in every possible way. It's quick to start up from your desktop, loads web pages in a snap, and runs complex web applications lightning fast.
- Per some reports on Google Chrome release (Chrome 80) on October 22nd there may impact to course tracking. Courses which are authored to be marked complete on-exit or posting data to an external URL may no longer report as complete. Similarly, learners' progressio.
The reason web publishers might see 'breakage' – which can mean anything from the loss of certain user-facing features to backend analytics errors – is that Chrome 80 handles HTTP cookies in a different way than its predecessors. The coming changes, intended to improve online security and privacy, mean that web developers need to explicitly declare in website code how they want cookies to be handled if they want to avoid potential problems.
HTTP cookies are files containing data keys and associated values and are created on a web user's local device through website code or server interaction to help with session management and to convey information, which may be necessary or may serve a publisher-oriented purpose like advertising or analytics. They're widely used (and misused) by third-party marketing firms for tracking user behavior and interests to serve targeted ads.
Concern about third-party cookies has proven sufficient that privacy-focused browsers like Brave, Firefox, and Safari have moved to block them by default, a situation that has prompted Google to plan on phasing them out within two years, while coming up with alternative web technology that can inform its core business - behavioral ad targeting.
But before that happens, cookie handling is being addressed because the status quo allows cross-origin information leakage and cross-site request forgery attacks. Google is doing so first in Chrome 80 on February 4, but Microsoft's Edge, now based on Chromium is expected to follow, and Mozilla's Firefox plans to do so as well.
Chrome 80's cookie code will look for the
SameSite
attribute in webpage HTML and will handle cookies according to the value assigned or by assuming a default value if none has been provided by a site developer.The
SameSite
attribute supports three primary values: SameSite=None
; SameSite=Strict
; and SameSite=Lax
.SameSite=None
is what a web developer would set to allow cookies in a third-party context. For Chrome 80, an additional flag, Secure
, will need to be set because without it, the browser will reject SameSite=None cookies.SameSite=None
is the current default and it's what a developer would want for a site that has widgets, embedded content, affiliate programs, advertising, or a login that works across multiple sites.![Google Chrome 80 Google Chrome 80](https://specials-images.forbesimg.com/imageserve/1188076554/960x0.jpg?fit=scale)
SameSite=Lax
places some restrictions on cookies for cross-origin requests. As the spec explains, it 'sends same-site cookies along with cross-site requests if and only if they are top-level navigations which use a 'safe' (in the [RFC7231] sense) HTTP method.'This setting is intended to be a middle ground that offers some protection against CSRF attacks via unsafe HTTP methods like POST.
And
SameSite=Strict
means cookies will only be sent in a first-party context.What makes Chrome 80's arrival such a potential problem is that it changes the browser's default behavior.
'Cookies that do not specify a
SameSite
attribute will be treated as if they specified SameSite=Lax
, i.e. they will be restricted to first-party or same-site contexts by default,' the Chromium Project's FAQ explains.Ifunia youtube downloader pro 7 0 0 8. That means websites using third-party cookies have to change their cookie setting code to specify
SameSite=None; Secure
or things may break.Companies like Adobe, Microsoft and Salesforce have been warning about that possibility. Earlier this week, Google's AMP (Accelerated Mobile Pages) project did the same.
About a week ago, Google engineer Lily Chen posted an update on
SameSite
code changes across the web and concluded, 'Overall, we believe the field trial results indicate a very modest amount of breakage.'According to Chen, Chrome maintains a Site Engagement Score (0-100) for every domain with which users interact. Google looked at scores for sites with noncompliant cookies to measure how much they matter to users.
'Of the requests that would have cookies blocked under
SameSite=Lax
by default, 79 per cent were to sites that the user had no engagement with (Site Engagement Score of 0.0), only 4 per cent were to sites with which the user had 'medium' levels of interaction (Site Engagement Score of 15.0 to 50.0), and fewer than 3 per cent were to sites with 'high' or 'max' engagement scores (over 50.0).'Brave, Google, Microsoft, Mozilla gather together to talk web privacy.. and why we all shouldn't get too much of it
READ MOREChen concludes that because the vast majority of affected requests are associated with sites that have little or no user engagement, most of the cookies that will be dropped by Chrome 80's changes will not be visible to users.
In an email to The Register, Augustine Fou, a cybersecurity and ad fraud researcher who advises companies about online marketing, said that while the cookie changes in Chrome 80 further concentrate Google's market power by making it more difficult for third-party ad tech to function, they do represent a real privacy win for consumers.
'It won't affect good publishers much – those publishers that didn't have egregious numbers of 3rd party trackers on their site doing god-knows-what,' Fou said. 'But it will negatively impact crappy long tail sites that were breaking or skirting the rules as much as possible before.'
'It won't affect marketers much either, because using hundreds of targeting parameters before drove no incremental business outcomes for them anyway. Hyper-targeting is the myth that ad tech companies want marketers to believe so they can sell more targeting parameters and charge higher CPMs.' ®
Updated to add
Though Chrome 80 is still slated to ship on February 4, 2020, Google now says, 'The SameSite-by-default and SameSite=None-requires-Secure behaviors will begin rolling out to Chrome 80 Stable for an initial limited population starting the week of February 17, 2020.'
Get ourTech Resources
The Google Chrome 80 release changes the default cross-domain (SameSite) behavior of cookies. This change enhances security and privacy, but requires customers and partners to test custom Salesforce integrations that rely on cookies. We support the ongoing effort to improve privacy and security across the web. We updated the SameSite attribute on cookies set by Salesforce. The fixes are in Spring '20 and they apply to Chrome 78 and later.
Where: This change applies to Lightning Experience and Salesforce Classic in all editions.
When: The Chrome 80 release started in February 2020, but Google has temporarily rolled back the SameSite changes until the summer of 2020 because of the extraordinary global circumstances due to COVID-19. For more information, see this Chromium blog post.
Salesforce is ready for the SameSite changes whenever Google rolls them out. If you made changes and tested in your org to prepare for Google's initial SameSite rollout in February 2020, you're ready too and there's nothing more for you to do.
Who: This change applies to Salesforce users of Google Chrome 80 release or later.
Why: Note these important changes for Chrome.
- Cookies don’t work for non-secure (HTTP) browser access, including any community, portal, site, or Outlook or Gmail integration in your org. Use HTTPS instead.
- Some custom integrations that rely on cookies no longer work in Google Chrome. This change particularly affects but is not limited to cross-domain communication, and integrations using iframes.
The SameSite attribute on a cookie controls its cross-domain behavior. This Chrome Platform Status explains the intent of the SameSite attribute. Sketch 48 1.
Google Chrome 80.0
“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.
Google Chrome 80 Cookies Change
How:
Google Chrome 800 Number
- Use HTTPS instead of HTTPTo require HTTPS access in your org, ensure that the following Session Settings in Setup are enabled. These settings are enabled by default but you should verify that HTTPS is required in your org.
- Require secure connections (HTTPS)
- Determines whether HTTPS is required to log in to or access Salesforce.
- In Spring ’20, we added a critical update that requires HTTPS connections to access Salesforce.
- Require secure connections (HTTPS) for all third-party domains
- Determines whether HTTPS is required for connecting to third-party domains.
If either of these settings is disabled, Salesforce may not be fully functional for Chrome users after the Chrome 80 release.- To require HTTPS access in communities, portals, or sites:
- From Setup, enter Sites in the Quick Find box, then select Sites.
- Click the site you want to edit, and ensure that the Require Secure Connections (HTTPS) checkbox is selected.
- To check whether your Salesforce Classic Canvas connected app works with HTTPS:
- In Salesforce Classic, from Setup, enter Canvas App Previewer in the Quick Find box, then select Canvas App Previewer.
- Click the app that you want to check. If the app loads, it means that the URLs are already set to use HTTPS. If the app doesn’t load in the previewer, update the Canvas App URL and Callback URL to use HTTPS.
- To update your Canvas connected app to HTTPS:
- In Salesforce Classic, from Setup, enter Create, and then click Apps.
- Select the Canvas connected app that you want to update.
- In the Canvas App URL field, update the URL to use HTTPS.
- In the Callback URL field, update the URL to use HTTPS.
- Click Save.
- Go back to the Canvas App Previewer and check that the app opens as expected.
Note
The first time that you navigate to the HTTPS URL, close and reopen tabs and clear your browser history.
- Test custom Salesforce integrations that rely on cookies owned and set by your integrationBefore the Chrome 80 release, test any custom Salesforce integrations that rely on cookies owned and set by your integration. If you find any regressions, update the SameSite attribute on cookies used for cross-domain communication to explicitly set SameSite=None; Secure. If you set a cookie in Apex, use the new SameSite attribute of the Cookie() constructor method.This Chromium blog post explains how to test the effect of the new Chrome behavior on your site or cookies before Chrome rolls out the SameSite changes. Navigate to chrome://flags and enable the “SameSite by default cookies” and “Cookies without SameSite must be secure” experiments. We recommend that you use the latest version of Chrome to test in a sandbox. The fixes in Spring ’20 apply to Chrome 78 and later.
Note
While you test your cookies, consider what’s the most secure SameSite value that works for each cookie. If a cookie is intended to be accessed only in a first-party context, you can apply SameSite=Lax or SameSite=Strict to prevent external access. Explicitly setting SameSite=Lax means that you’re not relying on default browser behavior.