How we’re increasing transparency for gen AI content with the C2PA
Source: AI
New beta available that restricts access to folders in Google Drive
What’s changing
Who’s impacted
Why it’s important
Additional details
- Shared drive managers can always access folders with limited-access
- Folder owners can always access limited-access folders in their My Drive
Getting started
- Admins: Eligible customers can express interest in the beta here. We’ll begin accepting domains into the program in the coming weeks. Once accepted into the beta, visit the Help Center to learn more about folders with limited access.
- End users:
- As a shared drive manager or My Drive folder owner, go to your shared drive > choose the folder you want to limit access > click the overflow menu > share > select share settings in the top right corner > click limited access to “Folder Name”. Visit the Help Center to learn more about folders with limited access.
- For users whose access has been limited, you will see the folder name, but the folder will be grayed out:
Availability
- Business Standard, Plus
- Enterprise Standard, Plus
- Essentials Starter, Enterprise Essentials, Enterprise Essentials Plus
- Education Fundamentals, Standard, Plus, the Teaching & Learning Upgrade
- Nonprofits
Resources
Source: Google Workspace Updates
Adding multi-monitor support to Google Slides
What’s changing
Who’s impacted
Why it matters
Getting started
- Admins: There is no admin control for this feature.
- End users: You can enable this feature by using “Presentation display options”. Visit the Help Center to learn more about presenting slides with other monitors.
Rollout pace
- Rapid Release domains: Gradual rollout (up to 15 days for feature visibility) starting on September 16, 2024
- Scheduled Release domains: Gradual rollout (up to 15 days for feature visibility) starting on September 30, 2024
Availability
- Available to all Google Workspace customers, Workspace Individual Subscribers, and users with personal Google accounts
Resources
Source: Google Workspace Updates
A breakthrough in wildfire detection: How a new constellation of satellites can detect smaller wildfires earlier
Source: AI
New Search experiences in South Africa: Badges and refinement chips
Source: Google Search Central Blog
8 formas de explorar, aprender y honrar la herencia latina con Google
Source: The Official Google Blog
Explore, learn about and honor Latino heritage with Google
Source: The Official Google Blog
A new path for Kyber on the web
We previously posted about experimenting with a hybrid post-quantum key exchange, and enabling it for 100% of Chrome Desktop clients. The hybrid key exchange used both the pre-quantum X25519 algorithm, and the new post-quantum algorithm Kyber. At the time, the NIST standardization process for Kyber had not yet finished.
Since then, the Kyber algorithm has been standardized with minor technical changes and renamed to the Module Lattice Key Encapsulation Mechanism (ML-KEM). We have implemented ML-KEM in Google’s cryptography library, BoringSSL, which allows for it to be deployed and utilized by services that depend on this library.
The changes to the final version of ML-KEM make it incompatible with the previously deployed version of Kyber. As a result, the codepoint in TLS for hybrid post-quantum key exchange is changing from 0x6399 for Kyber768+X25519, to 0x11EC for ML-KEM768+X25519. To handle this, we will be making the following changes in Chrome 1311:
- Chrome will switch from supporting Kyber to ML-KEM
- Chrome will offer a key share prediction for hybrid ML-KEM (codepoint 0x11EC)
- The PostQuantumKeyAgreementEnabled flag and enterprise policy will apply to both Kyber and ML-KEM
- Chrome will no longer support hybrid Kyber (codepoint 0x6399)
Chrome will not support Kyber and ML-KEM at the same time. We made this decision for several reasons:
- Kyber was always experimental, so we think continuing to support it risks ossification on non-standard algorithms.
- Post-quantum cryptography is too big to be able to offer two post-quantum key share predictions at the same time.
- Server operators can temporarily support both algorithms at the same time to maintain post-quantum security with a broader set of clients, as they update over time.
We do not want to regress any clients’ post-quantum security, so we are waiting until Chrome 131 to make this change so that server operators have a chance to update their implementations.
Longer term, we hope to avoid the chicken-and-egg problem for post-quantum key share predictions through our emerging IETF draft for key share prediction. This allows servers to broadcast what algorithms they support in DNS, so that clients can predict a key share that a server is known to support. This avoids the risk of an extra round trip, which can be particularly costly when using large post-quantum algorithms.
We’re excited to continue to improve security for Chrome users, against both current and future computers.
Notes
-
Chrome Canary, Dev, and Beta may see these changes prior to Chrome 131. ↩