The Beta channel has been updated to 105.0.5195.28 for Windows,Mac and Linux.
A full list of changes in this build is available in the log. Interested in switching release channels? Find out how here. If you find a new issues, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.
feed_label field in ShoppingSetting for Shopping & Performance Max campaigns in the UI and API. Due to this change, you may begin seeing campaigns with feed_labels set in the UI and API for certain merchants. Campaigns with geoTargeting and the appropriate target countries are set in Merchant Center.sales_country in Google Ads API), with the option to provide additional target countries once the feed has been created. Starting in August 23, 2022, we will make the following changes to how target countries are organized in the Merchant Center UI: feed_label that can accept any string, including any existing 2 letter CDLR country code.additional countries field will be renamed target countries, and will include all countries you want the feed to target.sales_country field for all available Shopping campaign types, including Performance Max, will eventually be replaced by feed_label. Note that we will keep the sales_country field for backwards compatibility until at least Q2 2023. Right now, you can continue to use sales_country in your campaigns.feed_label in Google Merchant Center or the Content API. Feed labels let you group different offers according to a common trait, like language (or a country, as you’ve currently been doing). You can also use feed_labels in Google Ads campaigns to target the relevant offers (all products with the same Merchant Center feed label).feed_label will show based on the following: feed_label will automatically be set to the two-letter territory code of the existing sales_country field to avoid interrupting existing targeting.feed_label and not a sales_country field, we recommend you update your code by August 23, 2022 to accommodate customers who will use campaigns that only have a feed_label (without a sales_country).
Benji Rothman, Content API for Shopping Team
targetCountry field for newly inserted products and the country field for new datafeeds may be empty in the Content API for Shopping. While targetCountry and country are now deprecated, there are no plans to remove these fields from v2.1 to preserve backward compatibility. We recommend using feedLabel to name new products and feeds, and using the shipping field to specify the countries to target.feedLabel field beginning in late August, we recommend you update your code to support the feedLabel field.targetCountry or datafeeds without a country.feedLabel field to the products resource. As of August 8, 2022, feedLabel can only accept and return two-letter CLDR territory codes. Products now require either targetCountry or feedLabel. As long as the feedLabel set is a valid two-letter CLDR code, targetCountry will be backfilled for compatibility.REST ID). feedLabel now replaces targetCountry as the third component of the identifier, so it is no longer just a valid two-letter CLDR code. You can find an example shown here.feedLabel doesn’t impact targeting. This means if you use feedLabel instead of targetCountry, you need to specify all countries you want to target in the shipping attribute.feedLabel via the API or the Merchant Center. You’ll still be able to use a two-letter country code in targetCountry for backwards compatibility.feedLabel that isn’t a CLDR territory code, the API will return those products without a targetCountry or those datafeeds without a country. Instead, only their feedLabel will be populated. This may break your codebase if your implementation expects a value in targetCountry for products or a value in country for datafeeds.targetCountry, you are not required to make any changes at this time, as the feedLabel value in the products REST ID will be identical to the targetCountry you inserted.feedLabel in Merchant Center or the API that is not a CLDR territory code, we highly recommend you update your codebase to use feedLabels on all product insertions instead of targetCountry to avoid issues with your API integration.feedLabel instead of targetCountry, even if the feedLabel is a CLDR territory code, will not automatically target that country. You must explicitly set the countries you want to target via the shipping field.feedLabel field set, not the country field, unless you explicitly set the feedLabel to a CLDR territory code.feedLabels on all datafeeds instead of country to avoid issues with your API integration.targetCountry and datafeeds without a country before August 23, 2022.feedLabel that is not a valid two-letter CLDR territory code. When this product is returned via products.list, you could encounter issues if your implementation expects a value in targetCountry.feedLabel and no country field. When this datafeed is returned via datafeeds.list, you could encounter issues if your implementation expects a value in country.products.list.targetCountry field does not exist on the product.datafeeds service will begin to return feedLabel on all datafeeds, which will be the country value if that is how the datafeed was created. The datafeeds service will also return the country field if the feedLabel is a valid country code for backwards compatibility.
Benji Rothman, Content API for Shopping Team
Cover of the medieval cookbook. Title in large letters kernel Exploits. Adorned. Featuring a small penguin. 15th century. Color. High quality picture. Private collection. Detailed.
The Linux kernel is a key component for the security of the Internet. Google uses Linux in almost everything, from the computers our employees use, to the products people around the world use daily like Chromebooks, Android on phones, cars, and TVs, and workloads on Google Cloud. Because of this, we have heavily invested in Linux’s security - and today, we’re announcing how we’re building on those investments and increasing our rewards.
In 2020, we launched an open-source Kubernetes-based Capture-the-Flag (CTF) project called, kCTF. The kCTF Vulnerability Rewards Program (VRP) lets researchers connect to our Google Kubernetes Engine (GKE) instances, and if they can hack it, they get a flag, and are potentially rewarded. All of GKE and its dependencies are in scope, but every flag caught so far has been a container breakout through a Linux kernel vulnerability. We’ve learned that finding and exploiting heap memory corruption vulnerabilities in the Linux kernel could be made a lot harder. Unfortunately, security mitigations are often hard to quantify, however, we think we’ve found a way to do so concretely going forward.
When we launched kCTF, we hoped to build a community of Linux kernel exploitation hackers. This worked well and allowed the community to learn from several members of the security community like Markak, starlabs, Crusaders of Rust, d3v17, slipper@pangu, valis, kylebot, pqlqpql and Awarau.
Now, we’re making updates to the kCTF program. First, we are indefinitely extending the increased reward amounts we announced earlier this year, meaning we’ll continue to pay $20,000 - $91,337 USD for vulnerabilities on our lab kCTF deployment to reward the important work being done to understand and improve kernel security. This is in addition to our existing patch rewards for proactive security improvements.
Second, we’re launching new instances with additional rewards to evaluate the latest Linux kernel stable image as well as new experimental mitigations in a custom kernel we've built. Rather than simply learning about the current state of the stable kernels, the new instances will be used to ask the community to help us evaluate the value of both our latest and more experimental security mitigations.
Today, we are starting with a set of mitigations we believe will make most of the vulnerabilities (9/10 vulns and 10/13 exploits) we received this past year more difficult to exploit. For new exploits of vulnerabilities submitted which also compromise the latest Linux kernel, we will pay an additional $21,000 USD. For those which compromise our custom Linux kernel with our experimental mitigations, the reward will be another $21,000 USD (if they are clearly bypassing the mitigations we are testing). This brings the total rewards up to a maximum of $133,337 USD. We hope this will allow us to learn more about how hard (or easy) it is to bypass our experimental mitigations.
The mitigations we've built attempt to tackle the following exploit primitives:
Out-of-bounds write on slab
Cross-cache attacks
Elastic objects
Freelist corruption
With the kCTF VRP program, we are building a pipeline to analyze, experiment, measure and build security mitigations to make the Linux kernel as safe as we can with the help of the security community. We hope that, over time, we will be able to make security mitigations that make exploitation of Linux kernel vulnerabilities as hard as possible.
As we announced in June, we’re upgrading the Google Duo experience to include all Google Meet features and bringing our two video calling services together into a single solution. This upgrade, which started rolling out last month, gives everyone access to new features like scheduling and joining meetings, virtual backgrounds, in-meeting chat and more, in addition to your current video calling features.
Additional meeting features let you start an instant video call with your entire study group or connect with your colleagues at a recurring scheduled time. Before you join a meeting, you’ll be able to change your background or apply visual effects. During the meeting, you’ll also be able to use in-meeting chat and captions for more ways to participate.
We’re also launching live sharing for Google Meet. Live sharing allows all meeting participants to interact with the content that’s being shared. So whether you’re co-watching videos on YouTube, curating a playlist on Spotify, taking turns while playing games like Heads Up!, UNO! Mobile or Kahoot! during an ice breaker, everyone will be able to join in on the action.
Over the past few weeks, we’ve started rolling out these new features to your Duo app, and now, users are beginning to see their app name and icon update to Google Meet. This upgrade will take place throughout the month across mobile and tablet devices, and will come later for other devices. To ensure a smooth transition, keep your app updated to the latest version.
If you’re using the existing Google Meet app, there will be no change to your experience. Your existing Meet app and icon will change to Google Meet (original). You can continue using this app to join and schedule meetings, but we recommend using the updated Google Meet app to get combined video meeting and calling features all in one place. We will continue to invest in bringing more features to Google Meet to help people to connect, collaborate and share experiences on any device, at home, at school and at work.
We're committed to making the transition as smooth as possible. For more information, please see our Help Center.
Hi everyone! We've just released Chrome Beta 105 (105.0.5195.26) for Android. It's now available on Google Play.
You can see a partial list of the changes in the Git log. For details on new features, check out the Chromium blog, and for details on web platform updates, check here.
If you find a new issue, please let us know by filing a bug.
Krishna Govind
Google Chrome
.png)
.png)
.jpg)
