Clarification on Google Workspace Context-Aware Access vs Chrome Enterprise Premium Context-Aware Access
Hi everyone, I’m hoping to get some clarification on the differences between Google Workspace Context-Aware Access (CAA) and Chrome Enterprise Premium Context-Aware Access. From what I understand, both allow conditional access controls based on user, device, and context, but I’m not fully clear on where the separation lies between them. For example: Does Workspace CAA mainly govern access to Google Workspace apps like Gmail and Drive, while Chrome Enterprise Premium CAA extends those controls to managed browsers and web apps? How do policy management and enforcement differ between the two? Are there separate admin configurations, or do they integrate within the same console? I also noticed that Context-Aware Access now supports OIDC, and that CAA for OIDC apps can be configured at the OU level. Does this capability apply to both Workspace and Chrome Enterprise CAA, or is it specific to one of them? If anyone has experience managing both solutions — or can share any official documentation that clarifies the distinctions — I’d really appreciate your insights. Thanks in advance,
DnsOverHttpsTemplatesWithIdentifiers forcibly hashes all variables, making them useless
Hi folks, This post relates to a recent change in the DnsOverHttpsTemplatesWithIdentifiers setting, which appears to no longer allow for plaintext variables to be passed to the DNS-over-HTTPS resolver, and everything is now forcibly hashed, with no ability to turn this off and restore original behavior. While I understand the reason for this, when it comes to public DNS resolvers, this change now poses a major hindrance to end users who use private DNS resolvers, and WANT to pass plaintext identifying information (USER_EMAIL specifically) to the DNS-over-HTTPS resolver, so they can see who is responsible for the DNS traffic on the other end, in the Analytics and DNS logs that are streamed into the SIEM. Considering DNS payload is already encrypted (DOH is used) and the org admin wants to see the plaintext identifiers, this poses a major UX issue since now they cannot correlate activity easily, and requires creation of mapping files, and constant need to sync them out of band. Without this, you see useless hashes that don't serve a purpose. We feel there should be a setting that allows the admin of an organization to pass plaintext identifiers if they so choose to, as it poses no security issues for private DNS resolvers, over HTTPS. Are there any plans to restore this original behavior, or at least offer a setting to allow it to behave as it did before, and not hash these variables? Thanks
The Strategic Roadmap of ChromeOS: Why Developers are the Bridge to High-Quality Users
This is a strategic follow-up to your previous discussion. It frames the developer community not just as a niche group of fans, but as the strategic bridge to Google’s ultimate high-value market. Here is a draft for your new post: Title: The Strategic Roadmap of ChromeOS: Why Developers are the Bridge to High-Quality Users Hi Lynda and the Community, Thank you for the thoughtful response to my previous post regarding the stability of the platform. After reviewing the 2024 blog post, “Building a Faster, Smarter Chromebook Experience with the Best of Google,” I’ve been reflecting on how Google can best navigate its engineering direction while protecting that "robust foundation" we discussed. To understand where ChromeOS should go, I believe we need to look at the three distinct categories of users the OS serves: 1. The Occasional Internet User (The Foundation) These users need a secure portal to the web. ChromeOS already masters this category through the Chrome Browser. It is fast, simple, and the entry point for millions. 2. The Developer (The Strategic Intermediary) This is where the platform shows its true engineering strength. Through Crostini and the Debian VM, ChromeOS is a dream for Linux-experienced users. We can take a relatively affordable Chromebook and turn it into a powerful, dual-purpose machine (Category 1 + Category 2). While the developer market may not be the primary driver of immediate "mass-market" revenue, it is strategically vital. Developers are the stress-testers. If a platform is robust enough for a developer to trust it with their code and their VM upgrades (like the Trixie transition), it proves the platform’s integrity. 3. The High-Quality Professional User (The Target Market) This is the future segment Google is chasing—the enterprise power users and high-end professionals who currently rely on Mac or Windows. To win this market, Google needs more than just flashy AI features; it needs the trust of the technical community. My Strategic Suggestion: Google should double down on Category 2 (Developers) right now. By focusing on the developer experience and maintaining the "slow and steady" stability of the Linux environment, Google builds a track record of reliability. Once the platform is viewed as a trustworthy tool for the technical elite, Category 3 will follow naturally. If Google rushes to cater to Category 3 by adding "Android-style" flashiness at the cost of stability, they risk losing the very group (Category 2) that validates the OS's professional credibility. Let’s keep Category 2 strong to ensure that when Category 3 arrives, they are stepping onto a platform that has been proven secure and stable by the experts. Best regards, Christophe_Roux
