How are you approaching AI tools for your end users?
Hi everyone, AI tools are quickly becoming part of everyday workflows — and with Gemini now integrated into ChromeOS, many IT teams are having to make decisions sooner rather than later. For some organisations, enabling AI features is about boosting productivity and helping users work smarter. For others, questions around data governance, security, user readiness, and change management mean a more cautious approach makes sense. Google has been framing this shift around the idea of the browser becoming an intelligent, secure control point for work — where AI assistance lives closer to the user, but within managed boundaries. On ChromeOS, that shows up through Gemini being embedded into the OS experience, helping with things like summarising content, drafting text, or getting contextual assistance, without stepping outside enterprise controls. I’m curious how people are thinking about this in practice: What’s your current stance on Gemini or AI tools for end users — enabled by default, restricted, piloting, or more of a wait-and-see approach? What factors matter most in that decision for you — security, compliance, user behaviour, demonstrated value, or something else? How are you thinking about balancing innovation with control as AI becomes more embedded into ChromeOS and the browser? There’s no right or wrong answer here — it’d just be great to hear how different teams are approaching this as the landscape continues to evolve.
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
