Google Using Enhanced Encryption to Protect Cookies
Just over a week after – once again – putting off plans to kill off third-party cookies in its Chrome browser, Google is rolling out another layer of protection aimed at protecting Microsoft Windows users from information-stealing malware.
The company in its new Chrome 127 is adding Application-Bound Encryption to the browser to bolster the defenses it already uses – Data Protection API (DPAPI) – to protect sensitive secrets on Chrome running on Windows systems.
DPAPI “protects the data at rest from other users on the system or cold boot attacks. However, the DPAPI does not protect against malicious applications able to execute code as the logged in user – which infostealers take advantage of,” Will Harris, a member of Google’s Chrome Security Team, wrote in a blog post. Now, with App-Bound Encryption, “rather than allowing any app running as the logged in user to access this data, Chrome can now encrypt data tied to app identity, similar to how the Keychain operates on macOS.”
Along with DPAPI for Windows, Chrome secures sensitive information – not only cookies, but also other data like passwords – using Keychain services for macOS. For Linux, Chrome uses a system-provided wallet like kwallet for gnome-libsecret. Google’s plan is to first introduce the App-Bound Encryption service to cookies in Chrome 127, then expand this protection to other information, such as passwords, payment data, and similar persistent authentication tokens, which should protect users from infostealer malware.
“App-Bound Encryption relies on a privileged service to verify the identity of the requesting application,” Harris wrote. “During encryption, the App-Bound Encryption service encodes the app’s identity into the encrypted data, and then verifies this is valid when decryption is attempted. If another app on the system tries to decrypt the same data, it will fail.”
Boxing Out Bad Actors
The service runs with system privileges, so bad actors can get past it simply by convincing a user to unwittingly run a malicious application. To reach the cookie, the malware would need to get system privileges or inject code into Chrome – something legitimate software doesn’t do – which could trigger the system’s antivirus protections and possibly be detected.
It makes it more costly for threat actors to steal data and “also makes their actions far noisier on the system. It helps defenders draw a clear line in the sand for what is acceptable behavior for other apps on the system,” he wrote. “Our other recent initiatives such as providing event logs for cookie decryption work in tandem with this protection, with the goal of further increasing the cost and risk of detection to attackers attempting to steal user data.”
One caveat is that with App-Bound Encryption, the encryption key is bound to the machine itself. For enterprises where Chrome profiles roam over multiple systems, the service won’t work correctly.
Continuing Anger Over Decision
Whether this will reduce some of the blowback from Google’s decision to delay deprecating third-party cookies altogether remains to be seen. The company initially said it would begin to do away with the cookies in early 2022. That deadline changed to late 2023 and then moved to the second half of 2024 before it was again put on the back burner.
Others, including Apple with Safari and Mozilla with Firefox, already had made their move with their browsers, finding alternatives several years ago to third-party cookies.
Google’s plan was to introduce its Privacy Sandbox to both improve the online privacy of users while keeping advertisers on the browser despite the changes they’d have to make in their operations. They would have had to adopt Privacy Sandbox APIs, which would let them continue to put relevant ads in front of users.
The ripple through the publishing and advertising space if the cookies went away would be significant, given that Google owns more than half of the browser market.
Giving Users Choice
Anthony Chavez, vice president of Privacy Sandbox, wrote in a blog post July 22 that the APIs have the potential to address these at-times competing goals and will improve over time. Still, it would involve “significant work” by publishers and advertisers, so Google opted for a proposal that includes continuing to work on Privacy Sandbox while giving users an informed choice for protecting their web browsing experience, a decision that could be changed if needed.
Google is working through this idea with regulators, Chavez wrote.
“As this moves forward, it remains important for developers to have privacy-preserving alternatives,” he wrote. “We’ll continue to make the Privacy Sandbox APIs available and invest in them to further improve privacy and utility.”
The decision didn’t sit well with privacy advocates. Hadley Beeman, with the World Wide Web Consortium (W3C), wrote this week that Google’s announcement came as a surprise and “undermines a lot of the work we’ve done together to make the web work without third-party cookies.”
The group has been working with Google on the Privacy Sandbox initiative, with Beeman writing that “third-party cookies are not good for the web. They enable tracking, which involves following your activity across multiple websites.”
Others were taking a more middle-of-the-road perspective.
“I think everyone realized third-party cookies aren’t long for this world, but Google has faced so much regulatory scrutiny as of late that they’re probably unable or unwilling to be the one destroying publisher revenue singlehandedly with a hurried rollout of Privacy Sandbox APIs,” one user said in a Reddit discussion. “New solutions will slowly but surely in the months and years to come, but for now, everyone can stop panicking over what’s to come in the next 6 months is all.”
