Tag Archives: API

Announcing new Real-time Bidding experiments

Google is launching experiments that are intended to provide bidders with an opportunity to test and provide collaborative feedback on ads-privacy proposals–these are features intended to improve user privacy protections and provide mechanisms for testing Chrome Privacy Sandbox proposals. We strongly encourage interested bidders to sign up and participate! Three new experiments made available today are described below.

Experiment #1: TURTLEDOVE simulation

The RTB protocols and infrastructure have been updated to enable a server-side simulation of Chrome’s TURTLEDOVE proposal, as described in the TURTLEDOVE simulation proposal. Bidders interested in participating can reference the TURTLEDOVE RTB Simulation API guide to learn more about the specific API and protocol changes associated with this experiment. Along with these changes, a new biddingFunctions resource for managing bidding functions that are used in the server-side simulation was added to the Real-time Bidding API.

The goal of this simulation is to provide bidders with an opportunity to experiment with Chrome’s proposal before it is implemented in Chrome, so that participating bidders can provide feedback on its viability and effectiveness. The APIs and modified RTB workflow used in the server-side simulation are conceptually similar to the ones that Chrome may later implement for TURTLEDOVE, based on existing proposals and public design discussions. Feedback relevant to Google’s simulation should be directed to the ads-privacy issue tracker, whereas feedback relevant to the TURTLEDOVE proposal itself should be directed to Chrome’s TURTLEDOVE issue tracker. To report bugs or technical questions about this experiment, you may contact the [email protected] support alias.

Experiment #2: Federated Learning of Cohorts (FLoC)

Google will allow participating bidders to experiment with Chrome’s FLoC proposal by simulating FLoC cohorts on its servers, based on algorithms described in this Google Research & Ads whitepaper. To facilitate this experiment, a Floc message has been added to the BidRequest in the Google RTB protocol, and as an extension of the User object for Google’s OpenRTB implementation. The message is structured as follows:


message Floc {
// The value of a cohort ID – a string identifier that is common to a large
// cohort of users with similar browsing habits.
optional string id = 1;
// The type of the FLoC. See
// https://github.com/google/ads-privacy/blob/master/proposals/FLoC/FLOC-Whitepaper-Google.pdf.
enum FlocType {
// Default value that should not be used.
FLOC_TYPE_UNKNOWN = 0;
// FLoC simulated using affinity hierarchical clustering with centroids
// and feature extraction based on Topic categories as described in the
// whitepaper.

SIMULATED_AFFINITY_CLUSTERING_CENTROID_VERTICAL = 2;
// FLoC simulated using SortingLSH clustering algorithm and Domain One-hot
// encoding feature extraction as described in the whitepaper.
SIMULATED_SIMHASH_SORTING_LSH_DOMAIN_ONE_HOT = 3;
// FLoC simulated using a k Random Centers locality-sensitive hash
// function as described in
// https://github.com/google/ads-privacy/blob/master/proposals/FLoC/k-random-centers.md
// with Domain TF-IDF feature extraction as described in the whitepaper.
KCENTER_DOM_FILTERED_TFDIF = 4;
}
optional FlocType type = 2;
}

Only web requests are in scope for the FLoC simulation experiment. In practice, only a small percentage of bid requests for bidders opted-in to the experiment would include this message, and those that do would not include pseudonymous user identifiers such as google_user_id and hosted_match_data.

Floc would also not be populated as a result of privacy controls, such as when users opt out of personalized advertising. Upon winning impressions, bidders can render creatives as usual and use their cookie-based identifiers to attribute conversions–for instance–to measure how well different FLoCs correlate with conversions.

We encourage participants to use the issue tracker to leave feedback on the simulated cohort algorithms. One useful metric to include would be the conversion rates for each FlocType in the experiment, possibly in comparison to regular traffic, where bidders may rely on cookie-based identifiers for targeting and optimization.

Experiment #3: Exchange-enforced frequency capping

The RTB protocols have been updated to enable an experiment for the exchange-enforced frequency capping proposal, which intends to support the critical frequency capping use case for the inventory provided by a single exchange without reliance on user identifiers provided in bid requests. A FrequencyCap message has been added to the BidResponse in the Google RTB protocol, and as an extension of the Bid object for Google’s OpenRTB implementation. The message is structured as follows:


  message FrequencyCap {
// An ID that can represent a bidder's use-case for frequency capping; for
// example, it could represent their campaign, ad, line item, etc. It should
// not contain any user-specific information or identifiers.
optional string fcap_id = 1;

// The time units for which frequency caps can be enforced.
enum TimeUnit {
UNKNOWN_TIME_UNIT = 0;
MINUTE = 1;
DAY = 2;
WEEK = 3;
MONTH = 4;
// When INDEFINITE is used, time_range will be ignored. INDEFINITE means
// the frequency cap will be applied for a long period of time, (longer
// than a month) but not necessarily forever.
INDEFINITE = 5;
}

// The unit of time used to specify the time window for which a frequency
// cap applies.
optional TimeUnit time_unit = 2;

// The length of the time window, in units specified by time_unit, for which
// the frequency cap applies. For instance, if time_unit=WEEK and
// time_range=3, then capping is applied for a three week period. If the
// time_unit=INDEFINITE, this will be ignored.
optional int32 time_range = 3 [default = 1];

// The maximum number of impressions allowed to be shown to a user for
// the provided frequency_cap_id within the time window described by
// time_unit and time_range.
optional int32 max_imp = 4;
}


Additional information about this experiment can be found in the proposal, and we encourage participants to leave feedback in the issue tracker.

Mark Saniscalchi, Authorized Buyers Developer Relations

The API Registry API

We’ve found that many organizations are challenged by the increasing number of APIs that they make and use. APIs become harder to track, which can lead to duplication rather than reuse. Also, as APIs expand to cover an ever-broadening set of topics, they can proliferate different design styles, at times creating frustrating inefficiencies.

To address this, we’ve designed the Registry API, an experimental approach to organizing information about APIs. The Registry API allows teams to upload and share machine-readable descriptions of APIs that are in use and in development. These descriptions include API specifications in standard formats like OpenAPI, the Google API Discovery Service Format, and the Protocol Buffers Language.

An organized collection of API descriptions can be the foundation for a wide range of tools and services that make APIs better and easier to use.
  • Linters verify that APIs follow standard patterns
  • Documentation generators provide documentation in consistent, easy-to-read, accessible formats
  • Code generators produce API clients and server scaffolding
  • Searchable online catalogs make everything easier to find
But perhaps most importantly, bringing everything about APIs together into one place can accelerate the consistency of an API portfolio. With organization-wide visibility, many find they need less explicit governance even as their APIs become more standardized and easy to use.

The Registry API is a gRPC service that is formally described by Protocol Buffers and that closely follows the Google API Design Guidelines at aip.dev. The Registry API description is annotated to support gRPC HTTP/JSON transcoding, which allows it to be automatically published as a JSON REST API using a proxy. Proxies also enable gRPC web, which allows gRPC calls to be directly made from browser-based applications, and the project includes an experimental GraphQL interface.

We’ve released a reference implementation that can be run locally or deployed in a container with Google Cloud Run or other container-based services. It stores data using the Google Cloud Datastore API or a configurable relational interface layer that currently supports PostgreSQL and SQLite.

Following AIP-181, we’ve set the Registry API’s stability level as "alpha," but our aim is to make it a stable base for API lifecycle applications. We’ve open-sourced our implementation to share progress and gather feedback. Please tell us about your experience if you use it.

By Tim Burks, Tech Lead – Apigee API Lifecycle and Governance

Increasing shared external contact limit to 200,000 contacts

Quick launch summary 

Shared external contacts are users outside of your domain who you add to your company directory. Previously, there was a limit of 50,000 external contacts. Now that limit is 200,000. Additionally, the total storage limit has been increased from 20MB to 40MB. 

Shared external contacts help enable collaboration between users in your organization and any external users who they may need to communicate with frequently, such as consultants and partners. When a user is added as a shared external contact, users in your organization can find the profile information for them in many Google services, such as when they enter addresses in Gmail. 


Getting started 

Rollout pace 

Availability 

  • Available to Google Workspace Essentials, Business Starter, Business Standard, Business Plus, Enterprise Essentials, Enterprise Standard, and Enterprise Plus, as well as G Suite Basic, Business, Education, Enterprise for Education, and Nonprofits customers 

Resources Google Workspace 

Bringing breakout rooms in Google Meet to more Google Workspace customers

Quick launch summary

Last month, we launched breakout rooms in Google Meet to G Suite Enterprise for Education customers. We’re now making breakout rooms available to Google Workspace, Essentials, Business Standard, Business Plus, Enterprise Essentials, Enterprise Standard, and Enterprise Plus customers, as well as G Suite Business and Enterprise for Education customers.

In addition, we’re introducing the following new features to improve your experience in breakout rooms:
  • Ask for help: Participants can ask for help when they are in a breakout room, and the moderator can see the request from the moderator panel and join the breakout room.
  • Timer/countdown: The moderator can set up a timer for a breakout session. Participants will see a banner to keep track of how much more time they have in the breakout room. They’ll also be alerted when there are 30 seconds left so that they can wrap up the discussion and, when time is up, participants will be prompted to go back to the main call.
  • Additional supported participants: Dial-in phone participants can now be assigned to breakout rooms. Starting in two weeks, anonymous users will also be able to be added to breakout rooms.

Getting started

  • Admins: There is no admin control for this feature.
  • End users: This feature will be available by default. Visit the Help Center to learn more about using breakout rooms in Meet.

Rollout pace 

Availability

  • Available to Workspace Essentials, Business Standard, Business Plus, Enterprise Essentials, Enterprise Standard, and Enterprise Plus, as well as G Suite Business and Enterprise for Education customers
  • Not available to Workspace Business Starter, as well as G Suite Basic, Education, and Nonprofits customers

Resources

Roadmap

 

Introducing two BeyondCorp Alliance partner integrations for improved context-aware access

What’s changing 

We’re announcing new integrations with our BeyondCorp Alliance partners Check Point and Lookout. The integrations, initially available in beta, are built using the Devices API and enable customers to use third party signals in context-aware access decisions. 


Who’s impacted

Admins 


Why it’s important 

In the BeyondCorp security model, device inventory, state, and security posture are central to making context-aware access decisions. So far our context-aware access solution obtained these signals from first party (i.e. Google) sources, such as Endpoint Verification. However our vision has always been to help customers to fully leverage their existing investments in security tools and controls, add key functionality and signals to Google’s context-aware access to achieve superior access control security posture for our customers. The BeyondCorp Alliance is a group of partners that share our Zero Trust vision and who are committed to working with us to help our joint customers make it a reality. 


Today, we are excited to announce the first integrations (in beta) with our BeyondCorp Alliance partners Check Point and Lookout, to use third party signals in our context-aware access decisions. For example, the mobile threat defence system might detect malware on the device and notify Google about a reduced security assurance, and customer-defined access rules can reduce the level of access allowed from such devices, without impacting access for that user from other devices or for other users. The integrations are built using the new Devices API we announced earlier this year. The API was designed to be used by partners in the BeyondCorp Alliance to add device security metadata, and also by customers to manage their device fleet. 


Getting started 

  • Admins: Google customers who use Checkpoint or Lookout as their mobile threat defense solutions can benefit from the integration. Visit our Help Center for more information and to learn more about how to set up third-party partner integrations. You can also see blog posts by our partners to see more about how you can use Check Point or Lookout solutions as part of this integration. 
  • End users: No impact for end users. 

Rollout pace 

Availability 

  • Available to Enterprise Plus, Enterprise for Education, and Cloud Identity Premium customers 
  • Not available to Essentials, Business Starter, Business Standard, Business Plus, Enterprise Essentials, Enterprise Standard, Education, and Nonprofits customers 

Resources 

Use the Count API to estimate Vault API export sizes

Quick launch summary 

We’re adding a Count API to the Vault API. The Count API enables you to see the number of messages, files, or other data items that match a search query. 


You can use the number of items to estimate the size of the export, and then choose to proceed with the export or adjust the query to retrieve fewer items. This can help ensure a successful export by reducing the likelihood of export errors due to size. 


Getting started 

  • Admins: Visit the API documentation to learn more about the Count API and review an example
  • End users: No end user impact. 

Rollout pace 

Availability 

  • Available to Business Plus, Enterprise Standard, Enterprise Plus, Enterprise for Education, as well as other customers with the Vault add-on license 
  • Not available to Essentials, Business Starter, Business Standard, Education, and Nonprofits customers  

Resources 

Roadmap 

Use new APIs to understand and audit group memberships

What’s changing 

We’re launching new APIs in beta to help better identify, audit, and understand indirect group membership (also known as ‘transitive’ or ‘nested’ group membership, see explanation below). The indirect membership visibility, membership hierarchy, and check APIs are part of the Cloud Identity Groups API and enable you to: 
These APIs are currently available as an open beta, which means you can use it without enrolling in a specific beta program. Use our API documentation to learn more. 



Who’s impacted 

Admins and developers 



Why it’s important 

These features will help provide all of the information you need to create visualization of complex group structures and hierarchies. Having this kind of membership visibility can help you make decisions about who to add to or remove from your groups. 


Customers often use groups to manage access to content and resources within their organization. Using ‘nested’ groups is common as it can decrease duplication, simplify administration, and centralize access management. 


However, nested groups can create a complex hierarchy that can make it hard to understand who ultimately has access to content or resources and why they have access. These APIs simplify finding out these answers by making it easier to identify the direct and indirect members for a group. Some use cases include: 
  • A security team can quickly identify all group memberships and associated nested memberships when a bad actor account is identified. 
  • An admin could perform a deep-dive on group structure for audit and compliance. By using the APIs to list and validate direct and indirect members for groups with many nested groups. 
  • A developer could extract group information via the API and feed it to a visualization tool that supports DOT format to make auditing and visualizing complex nested structures easier. 


Additional details 

Indirect memberships, also known as transitive memberships, come from ‘nested’ groups. Nested groups refer to situations where groups are members of other groups. As a result, users in the sub-group are members of both groups. For example, group Y is a member of group X. Users in group Y are direct members of group Y and indirect members of group X. 


Getting started 

Rollout pace 

  • This feature is available now for all users in beta. 

Availability 

  • Available to Enterprise Standard, Enterprise Plus, Enterprise for Education, and Cloud Identity Premium customers 
  • Not available to Essentials, Business Starter, Business Standard, Business Plus, Education, Nonprofits, and Cloud Identity Free customers 

Resources 

Use new APIs to understand and audit group memberships

What’s changing 

We’re launching new APIs in beta to help better identify, audit, and understand indirect group membership (also known as ‘transitive’ or ‘nested’ group membership, see explanation below). The indirect membership visibility, membership hierarchy, and check APIs are part of the Cloud Identity Groups API and enable you to: 
These APIs are currently available as an open beta, which means you can use it without enrolling in a specific beta program. Use our API documentation to learn more. 



Who’s impacted 

Admins and developers 



Why it’s important 

These features will help provide all of the information you need to create visualization of complex group structures and hierarchies. Having this kind of membership visibility can help you make decisions about who to add to or remove from your groups. 


Customers often use groups to manage access to content and resources within their organization. Using ‘nested’ groups is common as it can decrease duplication, simplify administration, and centralize access management. 


However, nested groups can create a complex hierarchy that can make it hard to understand who ultimately has access to content or resources and why they have access. These APIs simplify finding out these answers by making it easier to identify the direct and indirect members for a group. Some use cases include: 
  • A security team can quickly identify all group memberships and associated nested memberships when a bad actor account is identified. 
  • An admin could perform a deep-dive on group structure for audit and compliance. By using the APIs to list and validate direct and indirect members for groups with many nested groups. 
  • A developer could extract group information via the API and feed it to a visualization tool that supports DOT format to make auditing and visualizing complex nested structures easier. 


Additional details 

Indirect memberships, also known as transitive memberships, come from ‘nested’ groups. Nested groups refer to situations where groups are members of other groups. As a result, users in the sub-group are members of both groups. For example, group Y is a member of group X. Users in group Y are direct members of group Y and indirect members of group X. 


Getting started 

Rollout pace 

  • This feature is available now for all users in beta. 

Availability 

  • Available to Enterprise Standard, Enterprise Plus, Enterprise for Education, and Cloud Identity Premium customers 
  • Not available to Essentials, Business Starter, Business Standard, Business Plus, Education, Nonprofits, and Cloud Identity Free customers 

Resources 

Lock files via the Google Drive API to prevent content edits

What’s changing 

You can now add and remove content restrictions via the Drive API. By using the new ContentRestriction API, any file type in Drive can be “locked,” preventing changes to the item’s content, title, and comments. 

Content restrictions can be added or removed via the API and removed via Google Drive on the web by any user who has at least editor access level for the item. 

Learn more about the new API functions in this Drive ContentRestriction (Locking) API documentation


Who’s impacted 

Admins, end users, and developers 


Why you’d use it 

While Google Drive’s collaborative editing and commenting features are often helpful and beneficial, sometimes it’s important to know that changes are not being made to a document. Locking a file with the ContentRestriction API can help accomplish this, and could be used to: 
  • Lock authoritative versions of documents to create “official” or “final” documents for record keeping. 
  • Prevent changes to documents that are involved in a workflow, automation, or business process. 
  • Freezing activity on a document for a period of reviews or audits. 

Getting started 

Rollout pace 

  • This feature is available now for all users. 

Availability 

  • Available to all customers 

Resources 

Roadmap 

Lock files via the Google Drive API to prevent content edits

What’s changing 

You can now add and remove content restrictions via the Drive API. By using the new ContentRestriction API, any file type in Drive can be “locked,” preventing changes to the item’s content, title, and comments. 

Content restrictions can be added or removed via the API and removed via Google Drive on the web by any user who has at least editor access level for the item. 

Learn more about the new API functions in this Drive ContentRestriction (Locking) API documentation


Who’s impacted 

Admins, end users, and developers 


Why you’d use it 

While Google Drive’s collaborative editing and commenting features are often helpful and beneficial, sometimes it’s important to know that changes are not being made to a document. Locking a file with the ContentRestriction API can help accomplish this, and could be used to: 
  • Lock authoritative versions of documents to create “official” or “final” documents for record keeping. 
  • Prevent changes to documents that are involved in a workflow, automation, or business process. 
  • Freezing activity on a document for a period of reviews or audits. 

Getting started 

Rollout pace 

  • This feature is available now for all users. 

Availability 

  • Available to Essentials, Business Starter, Business Standard, Business Plus, Enterprise Essentials, Enterprise Standard, Enterprise Plus, Education, Enterprise for Education, and Nonprofits customers

Resources 

Roadmap