この記事は Johan Euphrosine、Ethan Mahintorabi による Google Open Source Blog の記事 "GlobalFoundries joins Google's open source silicon initiative" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 ...
この記事は Johan Euphrosine、Ethan Mahintorabi による Google Open Source Blog の記事 "GlobalFoundries joins Google's open source silicon initiative" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Google は、カスタムチップを開発するデベロッパーや企業のコミュニティを成長させ、オープンソース ハードウェア関連のエコシステムを活性化するため、昨年より無料のオープンソース チップの設計と製造プログラムを拡大する計画に懸命に取り組んでいます。

今回、このプログラムの拡大と、GlobalFoundries とのパートナーシップについてお知らせします。私たちは合同で、GlobalFoundries 180MCU テクノロジー プラットフォームのプロセス デザインキット（PDK）を Apache 2.0 ライセンスのもとで公開します。合わせて、Efabless プラットフォームでオープンソース設計の製造を行う無償チップ実現プログラムも公開します。このオープンソース PDK は、GF との継続的なパートナーシップから生まれた初めての成果です。GF には、テクノロジーと製造技術に関する膨大で広範な専門知識があります。それを土台として、半導体の開発や製造をより身近なものにし、イノベーションを推進するために、今後も共同作業を進めていきたいと考えています。
GF180MCU 1P5M 5 メタル スタックアップ、9kA トップメタル、M3 層と M4 層の間の MIM

Google はこのプログラムを SkyWater Technologies と合同で開始し、SkyWater の PDK の 1 つを Apache 2.0 ライセンスで公開しました。この 2 年間で 6 回のシャトルを後援し、オープンソース コミュニティから 350 点を超える独自の設計の申請を受け、そのうち約 240 点の設計が無償で製造されました。


この新しいパートナーシップは、半導体メーカーのエコシステム市場にとって 1 つの節目を意味します。それを過小評価することはできません。

パンデミックの影響により、世界では、この数年間でデジタル技術の採用がかつてないほど急加速しました。技術トレンドによって、人々の生活のあらゆる側面が変化しています。その結果、GlobalFoundries によると、半導体メーカーの収益の約 73% がモバイル、IoT、自動車などの高成長市場関連になっています。この変化は、半導体産業の「新しい黄金時代」につながるだけでなく、業界としてイノベーションを定義したり実現したりする方法に構造的変化をもたらします。

GlobalFoundries によると、180nm を使用する応用分野は、現在世界全体で年間 1,600 万ウエハーの規模になっています。2026 年には、それが 2,200 万枚以上に増加する見込みです。

180nm の応用分野は、モーター コントローラ、RFID、汎用 MCU と PMIC といった市場に加え、IoT センサー、二重周波数 RFID、モーター ドライブなどの新たな分野によって牽引され続けています。

GlobalFoundries と Google の共同作業によって、こういった応用分野や高成長領域で設計に携わるチップ エンジニアのイノベーションが推進されます。またそれは、半導体メーカーのエコシステムでオープンソース モデルを実現できることを明確に示すものでもあります。

GF 180nm テクノロジー プラットフォームは、大量生産、価格、電圧オプションに関連する新機能をオープンソース チップ設計者に提供します。この PDK には、以下の標準セルが搭載されています。
  • デジタル標準セルライブラリ（7 トラックと 9 トラック）
  • 低（3.3V）、中（5V、6V）、高（10V）の電圧オプション
  • SRAM マクロ（64x8、128x8、256x8、512x8）
  • I/O とプリミティブ（レジスタ、キャパシタ、トランジスタ、eFuse）セルライブラリ
オープンソースの PDK が増えることは、オープンソース チップ開発エコシステムの次のような発展にとって、重要なステップです。
  • オープンソース EDA ツールに複数のプロセス テクノロジーのサポートを追加できる
  • 研究者は、複数のテクノロジー ベースラインで再現性のある設計を実現できる
  • 人気のオープンソース IP ブロックを別のプロセス テクノロジーに移植できる
私たちだけでは、これを作り上げることはできません。ソフトウェア デベロッパーやハードウェア エンジニア、研究者や学部生、愛好家や業界の専門家、スタートアップ企業や業界関係者の皆さんの力が必要です。皆さんの新鮮なアイデアと豊富な経験を、オープンソース チップのエコシステムの拡大に役立てていただけることを期待しています。

ご興味がある方はぜひ、下記をご覧ください :
Posted by Johan Euphrosine、Ethan Mahintorabi – ハードウェア ツールチェーン チーム

この記事は David Wihl による Google Ads Developer Blog の記事 "Performance Max upgrade has started" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

2 月と 数か月前にお知らせしたとおり、既存のものと今後登録されるスマート ショッピング キャンペーン（SSC）は、2022 年 7 月から 9 月の間に自動的に P-MAX キャンペーンにアップグレードされます。セルフ アップグレードは 2022 年 4 月に始まりました。自動アップグレードも始まっており（関連ブログ投稿）、2022 年 9 月 30 日までに完了する予定です。このブログ投稿では、API デベロッパー向けに詳しい追加情報をお伝えします。

この記事は David Wihl による Google Ads Developer Blog の記事 "Performance Max upgrade has started" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

2 月と 数か月前にお知らせしたとおり、既存のものと今後登録されるスマート ショッピング キャンペーン（SSC）は、2022 年 7 月から 9 月の間に自動的に P-MAX キャンペーンにアップグレードされます。セルフ アップグレードは 2022 年 4 月に始まりました。自動アップグレードも始まっており（関連ブログ投稿）、2022 年 9 月 30 日までに完了する予定です。このブログ投稿では、API デベロッパー向けに詳しい追加情報をお伝えします。

2022 年 7 月 25 日より、アクティブまたは一時停止の SSC が ない アカウント（新規アカウント含む）で、SSC の作成ができなくなりました。

アクティブまたは一時停止の SSC が ある アカウントでは、SSC から P-MAX への自動アップグレードが行われると、UI、API、Google 広告スクリプト、Google 広告エディタなど、すべての機能から新規 SSC を作成できなくなります。

Google Ads API v11 には、新しい UpgradeSmartShoppingCampaignToPerformanceMaxRecommendation 最適化案の種類が含まれており、デベロッパーが指定した SSC を P-MAX キャンペーンにアップグレードできるようになっています。これは、まだ自動アップグレードされていないアカウントにも適用されます。

1 月のブログ投稿で触れたように、ローカル キャンペーンも P-MAX に自動アップグレードされます。今後の Google Ads API リリースには、新しい最適化案の種類が追加される予定です。これにより、デベロッパーは、対象のローカル キャンペーンを P-MAX キャンペーンにアップグレードできるようになります。

追加情報

ご質問やさらにサポートが必要なことがありましたら、フォーラムからご連絡ください。


この記事は Johan Euphrosine, Ethan Mahintorabi による Google Open Source Blog の記事 "SkyWater and Google expand open source program to new 90nm technology" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
この記事は Johan Euphrosine, Ethan Mahintorabi による Google Open Source Blog の記事 "SkyWater and Google expand open source program to new 90nm technology" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

この度、Google は SkyWater Technology とのパートナーシップを拡大することをお知らせします。私たちは、SkyWater の商用 90nm 完全空乏型シリコン オン インシュレータ（FDSOI）CMOS プロセス テクノロジーである SKY90-FD 用のオープンソース プロセス デザインキット（PDK）をリリースするために、協力して作業を進めています。SKY90-FD は MIT Lincoln Laboratory の 90nm 商用 FDSOI テクノロジーに基づいており、設計者はこれを利用して複雑な集積回路を作成し、さまざまな用途に活用できます。

この 2 年の間に、Google と SkyWater Technology のパートナーシップのもとで、あらゆるデベロッパーがアクセスできるオープンなチップが生まれています。その始まりは SKY130 PDK のオープンソース リリースで、その後にオープンソース ハードウェア エコシステムのデベロッパー向けの一連の無償製造シャトルが続きました。これまでに Google は、Efabless プラットフォームで 6 つのシャトルをサポートし、364 件以上のコミュニティ申請を受けて 240 の設計を製造しています。この種のパートナーシップは世界初で、これまでにめざましい成果をあげています。
最新の MPW-6 シャトルでは、24 か国のさまざまなコミュニティから 90 件の申請を受けました。


今後数か月間で、SkyWater Technology と密接に連携しつつ、新しい SKY90-FD PDK を Apache 2.0 ライセンスのもとでリリースする予定です。また、追加の Open MPW シャトルを計画し、Efabless プラットフォームによってこの新しい 90nm FDSOI テクノロジー向けのオープンソース設計の製造も行いたいと考えています。

オープンソースの PDK を通じてさまざまなテクノロジーにアクセスできることは、オープンなチップのエコシステムの拡大と強化にとって欠かせないことであると確信しています。
  • デベロッパーは、親しんだプロセスノードの制約を超え、既存の設計や新しい設計で、異なる性能、消費電力、領域のトレードオフを模索できます。
  • 研究者は、異なるテクノロジーで研究を再現し、さまざまな性能指数を実現できます。
  • ツールの管理者は、テクノロジーのバックエンドを汎用化し、複数のプロセスをサポートできます。
  • コミュニティは、PDK の構造化、配布、管理の方法を改善できます。
SKY90-FD は 90nm FDSOI プロセスです。従来の CMOS BULK プロセスとは異なり、SKY90-FD には基板と上部シリコン層との間に薄い絶縁材料の層があるのが特徴です。この薄い酸化プロセスのおかげで、トランジスタを BULK プロセスよりも大幅に薄くすることができます。それによって素子を「完全空乏」にできるので、製造プロセスを簡素化できます。この絶縁が追加されることで、寄生リーク電流が大幅に減少して接合容量が下がり、さまざまな環境条件下でスピードと消費電力性能が向上します。

SKY90-FD プロセス スタック トポロジの特徴は、主な相互接続用の 5 つの薄い銅ベースの金属層と、それより高い電流を流せる厚みのある 2 つの追加 Al（アルミニウム）金属層。

このオープンソース PDK は今年中にリリースされる予定です。そこからさまざまな新しい用途が生まれるのが楽しみです。皆さんの感想をお待ちしています。また、オープンなチップのコミュニティから、ますますたくさんの画期的なプロジェクトのアイデアが生まれることを期待しています。

それまでの間は、オープンなチップの探求を始めることができるように、https://developers.google.com/silicon のリソースやリンクを確認しておきましょう。


Posted by Johan Euphrosine、Ethan Mahintorabi – ハードウェア ツールチェーン チーム

この記事は Josh Radcliff による Google Ads Developer Blog の記事 "Upcoming changes to conversion action management" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

2022 年 8 月 22 日より、 ConversionAction リソースの  include_in_conversions_metric フィールドが読み取り専用になります。この値を設定しようとするリクエストは、 FieldError.IMMUTABLE_FIELD エラーになります。

この変更を行う理由
この記事は Josh Radcliff による Google Ads Developer Blog の記事 "Upcoming changes to conversion action management" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

2022 年 8 月 22 日より、ConversionAction リソースの include_in_conversions_metric フィールドが読み取り専用になります。この値を設定しようとするリクエストは、FieldError.IMMUTABLE_FIELD エラーになります。

この変更を行う理由
Google 広告にコンバージョン目標を追加する作業の一環として、include_in_conversions_metric フィールドに代わって新しい primary_for_goal フィールドが導入されます。新しいフィールドへの移行作業が簡単になるように、すべてのアカウントで目標を有効化していたときは、Google Ads API から非推奨の include_in_conversions_metric フィールドを設定する操作は許可されていました。その場合、primary_for_goal は API が適切に自動更新してくれます。ただし、現時点ですべての Google 広告アカウントでコンバージョン目標が有効になっていることから、primary_for_goal との競合を防ぐため、include_in_conversions_metric を設定できないようにします。

必要な対応
include_in_conversions_metrics を設定しているすべてのコードを変更し、代わりに primary_for_goal を設定するようにします。さらに、レポートで conversion_action.include_in_conversions_metric フィールドを使っているアプリケーション ロジックがないか確認し、ある場合は変更してください。primary_for_goal 設定が入札やレポートに与える詳しい影響の説明は、コンバージョン目標のガイドに記載されています。

ご質問やサポートが必要なことがありましたら、フォーラムからご連絡ください。

Posted by Thanet Knack Praneenararat - Ads Developer Relations Team

この記事は Google オープンソース セキュリティ チーム、Brandon Lum、Oliver Chang による Google Security Blog の記事 "SBOM in Action: finding vulnerabilities with a Software Bill of Materials" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

昨年は、ソフトウェア部品表（Software Bills of Materials、 SBOM）を採用しようという機運が業界全体で高まりました。SBOM とは、ソフトウェアをビルドするために必要なコンポーネント、ライブラリ、モジュールをすべて列挙したものです ...
この記事は Google オープンソース セキュリティ チーム、Brandon Lum、Oliver Chang による Google Security Blog の記事 "SBOM in Action: finding vulnerabilities with a Software Bill of Materials" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

昨年は、ソフトウェア部品表（Software Bills of Materials、SBOM）を採用しようという機運が業界全体で高まりました。SBOM とは、ソフトウェアをビルドするために必要なコンポーネント、ライブラリ、モジュールをすべて列挙したものです。2021 年のサイバーセキュリティに関する米国大統領令を受けて、私たちが使うソフトウェアが何でできているのかを理解する手段として、このソフトウェア部品表が注目されています。基本的な考え方は、他者が作ったものも含め、すべての部品について把握していなければ、特定のソフトウェアに含まれるリスクは判断できないというものです。SBOM への関心の高まりは、米国国立標準技術研究所（NIST）がソフトウェアの SBOM 情報の提供を必須としたセキュア ソフトウェア開発フレームワークを公開したことで、さらに押し上げられることになりました。しかし、業界で SBOM を生成して共有する手法が進展しつつある今、SBOM をどのように活用すればよいのでしょうか。

SBOM を生成するだけでは、まだ道半ばです。あるソフトウェアの SBOM が準備できたら、それを既知の脆弱性リストにマッピングして、脅威を及ぼしかねないのはどのコンポーネントかを確認する必要があります。この 2 つの情報源を結びつけることで、利用者はソフトウェアに含まれているものだけでなく、そのリスクや修正すべき問題があるかどうかも把握できます。

このブログ投稿では、大規模で重要なプロジェクトである Kubernetes から SBOM を取得し、オープンソースのツールを使ってそこに含まれる脆弱性を特定するプロセスを示します。私たちの例の成功は、完全な SBOM が作られるのを待たなくても、SBOM と一般的な脆弱性データベースとのマッピングを始められることを示しています。2 つのデータソースを結びつける際の現在の制限に対処するために SBOM 作成者が少しの更新を行うだけで、このプロセスは、平均的なソフトウェア利用者が簡単に使えるものになります。

OSV: SBOM と脆弱性を結びつける

以下の例では、Kubernetes を取り上げます。大規模プロジェクトである Kubernetes では、SBOM 情報を伝達するためのオープンな国際基準（ISO）である Software Package Data Exchange（SPDX）形式で SBOM が提供されています。SBOM を提供しているすべてのプロジェクトにも、同じ考え方が当てはまるはずです。SBOM を提供していないプロジェクトでは、Kubernetes が作成した同じ bom ツールを使って独自の SBOM を生成できます。

今回は、この SBOM を Open Source Vulnerabilities（OSV）データベースにマッピングすることにしました。このデータベースでは、オープンソース パッケージのバージョンやコミット ハッシュとマッピングできる形式で脆弱性が記述されています。OSV データベースはこの点でも優秀で、標準形式が提供され、複数のエコシステム（Python、Golang、Rust など）やデータベース（Github Advisory Database（GHSA）、Global Security Database（GSD）など）からの情報が集約されています。

SBOM とデータベースを結びつけるために、SPDX の spdx-to-osv ツールを使います。このオープンソース ツールは SPDX の SBOM ドキュメントを受け取り、OSV 脆弱性データベースに照会をし、ソフトウェアで宣言されているコンポーネントに含まれる脆弱性の一覧を返します。
例 : Kubernetes の SBOM

最初の手順は、Kubernetes の SBOM をダウンロードすることです。Kubernetes の SBOM は公開されており、プロジェクト、依存関係、バージョン、ライセンスについての情報が含まれています。次に示す簡単な curl コマンドで、誰でもダウンロードできます。

# Kubernetes SPDX ソース ドキュメントをダウンロードする

$ curl -L https://sbom.k8s.io/v1.21.3/source > k8s-1.21.3-source.spdx


次の手順では、SPDX の spdx-to-osv ツールを使って Kubernetes の SBOM と OSV データベースを結びつけます。

# SPDX SBOM 情報を受け取り、それを OSV 脆弱性にマッピングする spdx-to-osv ツールを実行する

$ java -jar ./target/spdx-to-osv-0.0.4-SNAPSHOT-jar-with-dependencies.jar -I k8s-1.21.3-source.spdx -O out-k8s.1.21.3.json


# 出力された spdx-to-osv ツールの OSV 脆弱性を表示する

$ cat out-k8s.1.21.3.json

…

{

  "id": "GHSA-w73w-5m7g-f7qc",

  "published": "2021-05-18T21:08:21Z",

  "modified": "2021-06-28T21:32:34Z",

  "aliases": [

    "CVE-2020-26160"

  ],

  "summary": "Authorization bypass in github.com/dgrijalva/jwt-go",

  "details": "jwt-go allows attackers to bypass intended access restrictions in situations with []string{} for m[\"aud\"] (which is allowed by the specification). Because the type assertion fails, \"\" is the value of aud. This is a security problem if the JWT token is presented to a service that lacks its own audience check. There is no patch available and users of jwt-go are advised to migrate to [golang-jwt](https://github.com/golang-jwt/jwt) at version 3.2.1",

  "affected": [

    {

      "package": {

        "name": "github.com/dgrijalva/jwt-go",

        "ecosystem": "Go",

        "purl": "pkg:golang/github.com/dgrijalva/jwt-go"

      },

…




ツールの出力から、Kubernetes の v1.21.3 には、脆弱性 CVE-2020-26160 があることがわかります。この情報は、このソフトウェアを運用するリスクを管理するために追加のアクションが必要かどうかを判断する際に役立つ可能性があります。たとえば、ある組織が Kubernetes の v1.21.3 を使っている場合、会社のポリシーに基づいてデプロイされたソフトウェアを更新するという対策をとることが考えられます。そうすれば、この脆弱性を悪用した攻撃から組織を守ることができます。

SBOM ツールの改善提案

spdx-to-osv ツールを動作させるには、いくつかの小さな変更を行い、SBOM が提供する情報のあいまいさを排除する必要がありました。
  • 現在の bom ツールの実装では、バージョンがパッケージ名の中に含まれています（gopkg.in/square/go-jose.v2@v2.2.2）。SPDX 形式ではバージョン番号が別のフィールドに格納されているため、この接尾辞を取り除かないと、照合させることができませんでした。
  • この bom ツールで作成した SBOM では、エコシステムが特定できません。エコシステムがないと、どのライブラリやパッケージが影響を受けるかを確実に自動判定することはできません。エコシステムによって影響の有無が異なる場合、脆弱性スキャナが誤判定を引き起こす可能性があります。SBOM でライブラリやパッケージのバージョンが区別されていれば、利便性がさらに高まります。
ただし、これらは比較的小さなハードルで、手動で多少の調整をするだけで、うまくツールを実行できました。今後、このプロセスを簡単に実行できるように、次の提案により SBOM 生成ツールを改善したいと考えています。

  • SBOM ツールの作成者は、ソフトウェアに含まれるすべてのパッケージについて、Purl などの識別スキームによる参照を追加すべきです。この種の識別スキームがあれば、エコシステムを特定できるとともに、前述の接尾辞のようなパッケージ記述子の小さな揺れに対するスキームの柔軟性が向上するので、パッケージの識別も容易になります。SPDX ではこれをサポートするために、Purl の外部参照やその他のパッケージ識別スキーマの外部参照を使用しています。
SBOM の未来

SBOM の当初の目的である「ソフトウェアの脆弱性リスク管理を支援する」が実現されつつあることは明らかです。今回の例では OSV データベースを照会しましたが、近いうちに、他の脆弱性データベースに SBOM データをマッピングしたり、VEX などの新しい標準を使ったりすることもできるようになるでしょう。VEX では、ソフトウェアの脆弱性が軽減されているかどうかについての追加情報が提供されます。

SBOM の採用が広がり、ツールの改善が続けば、そう遠くないうちに、すべてのソフトウェアで SBOM のリクエストやダウンロードができるようになるでしょう。さらに、利用するソフトウェアの脆弱性も把握できるようになるかもしれません。今回の例を通して、SBOM と脆弱性データベースを結びつけるうえでの問題が解消されたときに、SBOM で何が実現できるかを垣間見ることができました。それこそ、使うソフトウェアのリスクに関する不安が軽減された新たな日常です。
 
spdx-to-osv ツールの作成者で、このブログ投稿に貢献いただいた Source Auditor 社の Gary O'Neall 氏に深く感謝いたします。


Posted by Eiji Kitamura - Developer Relations Team

この記事は Thanet Knack Praneenararat による Google Ads Developer Blog の記事 "Announcing v11 of the Google Ads API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 ...
この記事は Thanet Knack Praneenararat による Google Ads Developer Blog の記事 "Announcing v11 of the Google Ads API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

この度、Google Ads API の v11 リリースをお知らせします。v11 の一部の機能を使うには、クライアント ライブラリとクライアントのコードをアップグレードする必要があります。更新版のクライアント ライブラリとコードサンプルも公開されました。

 

主な機能は以下のとおりです。さらに詳しく知りたい方へ
以下のリソースが役立ちます。ご質問やさらにサポートが必要なことがありましたら、フォーラムからご連絡ください。

Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team

この記事は Chromium Blog の記事 "Chrome 104 Beta: New Media Query Syntax, Region Capture, and More" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2022 年 6 月 23 日の時点で Chrome 104 はベータ版です。PC 向けの最新版は Google.com で、Android では Google Play ストアでダウンロードできます。

この記事は Chromium Blog の記事 "Chrome 104 Beta: New Media Query Syntax, Region Capture, and More" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2022 年 6 月 23 日の時点で Chrome 104 はベータ版です。PC 向けの最新版は Google.com で、Android では Google Play ストアでダウンロードできます。

リージョン キャプチャ

PC 版の Chrome で、セルフキャプチャした動画トラックをトリミングできるようになります。ウェブアプリでは、getDisplayMedia() を使ってタブを動画でキャプチャすることができます。ウェブアプリでリージョン キャプチャを使うと、トラックをトリミングしてコンテンツの一部を削除できます。通常、この機能は、リモートに共有する前に利用します。

たとえば、ビデオ会議が組み込まれた生産性向上ウェブアプリがあるとします。ウェブアプリのビデオ会議で画面の一部（下の図の赤線部分）をトリミングすることで、映像がループする現象を回避できます。詳細については、リージョン キャプチャでタブ共有を改善するをご覧ください。

リージョン キャプチャ ウィンドウ: 青い部分がブロードキャストされるコンテンツ、赤い部分がトリミングされるコンテンツ。


メディアクエリ レベル 4 構文と評価

メディアクエリを使うとレスポンシブ デザインを実現できます。また、ビューポートの最小サイズや最大サイズを確認できるレンジ機能は、メディアクエリを使っているサイトの約 80% で利用されています。

メディアクエリ レベル 4 仕様には、このレンジ クエリの新構文が含まれており、通常の算術比較演算子を使って範囲を記述できるようになっています。また、論理演算子 or および not、ネスト、"unknown" の評価機能もサポートされます。たとえば、これまでのメディアクエリは次のように記述されていました。

@media (min-width: 400px) { … }

これを、次のように記述できるようになります。

@media (width >= 400px) { … }

詳細については、Chrome 104 のレンジ メディアクエリの新構文をご覧ください。

オリジン トライアル

このバージョンの Chromium では、以下のオリジン トライアルがサポートされます。オリジン トライアルとして新機能を試して、ユーザビリティ、実用性、有効性についてのフィードバックをウェブ標準コミュニティに提供することができます。以下の項目を含め、現在 Chromium でサポートされているオリジン トライアルに登録するには、Chrome オリジン トライアル ダッシュボードをご覧ください。Chrome のオリジン トライアルの詳細については、ウェブ デベロッパーのためのオリジン トライアル ガイドをご覧ください。Microsoft Edge は、Chrome とは別に独自のオリジン トライアルを行っています。詳細については、Microsoft Edge オリジン トライアル デベロッパー コンソールをご覧ください。

新しいオリジン トライアル

focusgroup

focusgroup CSS プロパティを使うと、キーボードの矢印キーを使ってフォーカス可能な要素間でフォーカスを移動する操作を改善できます。ブラウザにこの機能を追加することで、整合性、ユーザー補助、相互運用性に欠けるカスタム ソリューションを使うことなく、フォーカス操作を制御できるようになります。Microsoft Edge のオリジン トライアルにはこちらから登録できます。このトライアルは、107 まで行われる予定です。

クレジット カード保存のオプトアウト

Secure Payment Confirmation において、今後の購入を簡単にするためにクレジット カードのデータを保存する機能をオプトアウトできるようになります。この新機能を使うには、PaymentRequest() コンストラクタの最初のパラメータとして渡す methodData.data で、showOptOut を true に設定します。次に例を示します。

const methodata = [{ 
  …
  data: {
    …
    showOptOut: true
    …
  }
}];
const request = new PaymentRequest(methodData, details);

実際の例は、デモでご覧いただけます。このオリジン トライアルにはこちらから登録できます。このトライアルは、Chrome 106 まで行われる予定です。

Shared Element Transition

Shared Element Transition を使うと、シングルページ アプリケーション（SPA）で洗練された画面遷移を作成できます。見栄えのよい画面遷移を最小限の開発作業で作成でき、デフォルトのアニメーション プロパティを使うことも、独自の遷移効果をカスタマイズして希望どおりの画面遷移を実現することもできます。画面遷移は CSS プロパティを使って宣言的に設定します。詳細については、Shared Element Transition をご覧ください。オリジン トライアルへの登録は、ダッシュボードから行うことができます。

完了したオリジン トライアル

Chrome で以前にオリジン トライアルが行われていた以下の機能は、現在デフォルトで有効化されています。

推測ルール

推測ルールは、ウェブ コンテンツで特定の URL のプリフェッチまたはプリレンダリングを許可する仕組みを提供します。次に例を示します。

<script type="speculationrules">
  {
    "prefetch": [
      {"source": "list", "urls": ["/weather/kitchener", "/weather/seattle", "/weather/tokyo"]}
    ]
  }
</script>

ウェブバンドルによるサブリソースの読み込み

ウェブバンドルによるサブリソースの読み込みは、多数のリソースを効率的に読み込む方法です。この機能を使うには、特定のリソースが特定の URL でウェブバンドルから提供されることをウェブページで宣言します。次に例を示します。

<script type="webbundle">
{
   "source": "https://example.com/dir/subresources.wbn",
   "resources": ["https://example.com/dir/a.js", "https://example.com/dir/b.js", "https://example.com/dir/c.png"]
}
</script>

ウェブバンドルの詳しい作成方法については、ウェブバンドルを使ってみるをご覧ください。ウェブバンドルによるサブリソースの読み込みの詳細については、ウェブバンドルによるサブリソースの読み込みのオリジン トライアルをご覧ください。

インストールした PC ウェブアプリ向けのウィンドウ コントロール オーバーレイ

PC でウェブアプリのクライアント領域を拡張し、タイトルバー領域を含むウィンドウ全体を覆うことができるようになりました。その場合、ウィンドウ コントロール ボタン（閉じる、最大化 / 復元、最小化）はクライアント領域の上に重なって表示されます。ウェブアプリのデベロッパーは、ウィンドウ コントロール オーバーレイを除くウィンドウ全体の描画と入力ハンドリングをする必要があります。この機能を使うと、デベロッパーはインストールされた PC ウェブアプリをプラットフォームのアプリのように見せることができます。

今回のリリースに追加されたその他の機能

Cookie の Expires / Max-Age 属性の上限

明示的に Expires / Max-Age 属性を指定して Cookie を設定する場合、400 日を超える日付は設定できなくなります。これまでは制限がなかったので、有効期限が数千年の Cookie も可能でした。これは、仕様の変更に従ったものです。

400 日は、13 か月に近いきりのいい数であることから選ばれました。これだけの期間があれば、ほぼ 1 年に 1 度しかアクセスしないサイト（健康保険の給付金を選ぶサイトなど）も問題なく動作します。

CSS object-view-box

object-view-box プロパティを使うと、イメージの一部を指定して、置換対象となる要素のコンテンツ ボックスに描画できます。これにより、CSS シャドウのような適切な ink-overflow 動作を維持しながら、カスタムのグローやシャドウを適用したイメージを作成できるようになります。詳細については、CSS object-view-box プロパティの紹介をご覧ください。

全画面表示機能の委譲

全画面表示機能の委譲をすると、ある Window から別の信頼する Window に requestFullscreen() を呼び出す機能を移管することができます。これは、送信元の Window がユーザーによって一時的にアクティブ化され、それが解除された後に行われます。この機能は、Chrome 100 に含まれる汎用委譲メカニズムに基づいています。

マルチスクリーン ウィンドウ配置 : 全画面表示コンパニオン ウィンドウ

全画面表示コンパニオン ウィンドウを使うと、ユーザーが 1 度アクティブ化するだけで、全画面表示コンテンツとポップアップ ウィンドウを別の画面に配置できます。デモが公開されており、ソースコードは GitHub にあります。

Web Bluetooth API のパーミッション ポリシー

Web Bluetooth をパーミッション ポリシーで制御できるようになります。トークンの名前は "bluetooth" で、デフォルトの許可リストは 'self' です。

overflow-clip-margin の visual-box

overflow-clip-margin プロパティは、要素のコンテンツがクリッピングされずに描画できる範囲を指定します。この機能により、visual-box 値を使って参照ボックスを設定できるようになります。この参照ボックスが、コンテンツをクリッピングするオーバーフロー クリップのエッジを定義します。

Async Clipboard API のウェブ カスタム フォーマット

ウェブ カスタム フォーマット機能により、標準化されたウェブ カスタム フォーマットを使って、サニタイズされていない任意のペイロードを読み書きできるようになります。また、一部の限定された OS 固有のフォーマットを読み書きすることもできます（以前のアプリをサポートするため）。

コンテンツがウェブからのものであることを示すため、ブラウザはクリップボードのフォーマットの名前を標準化された方法で難読化します。そのため、プラットフォームのアプリケーションは、サニタイズされていないコンテンツを受け入れるかどうかを選択できます。

オペレーティング システムのクリップボードを通してウェブとプラットフォーム アプリケーションの間でデータ ペイロードを交換したいウェブアプリ デベロッパーもいるかもしれません。Clipboard API は、特によく使われる標準データタイプ（テキスト、イメージ、リッチテキスト）をすべてのプラットフォームでサポートしています。ただし、この API はロングテールな特殊フォーマットまでは対応していません。特に、現在のウェブ プラットフォームでは、カスタム フォーマット、TIFF（大型イメージ フォーマット）などの非ウェブ標準フォーマット、docx（ドキュメント フォーマット）などの独自フォーマットはサポートされません。

WebGL の描画キャンバス カラー マネジメント

仕様に従い、Chromium の WebGL 実装で以下の指定ができるようになります。

  • 描画バッファのカラースペース
  • コンテンツをテクスチャとしてインポートする際に変換するカラースペース

以前のバージョンの Chrome では、両方とも既定の sRGB となっていました。現在のバージョンより、"display-p3" も利用できるようになります。

サポートの終了と機能の削除

このバージョンの Chrome では、以下のサポートの終了と機能の削除が行われます。現在サポートが終了している機能と以前に削除された機能のリストは、ChromeStatus.com をご覧ください。

ファイルシステム URL にアクセスするサードパーティ コンテンツのブロック

iframe はファイルシステム URL に移動することができなくなります。トップフレームのファイルシステム URL への移動は、Chrome 68 で削除されています。

非標準クライアント ヒント モードの削除

4 つのクライアント ヒント（dpr、width、viewport-width、device-memory）にはデフォルトの許可リスト self がありますが、Android では仕様とは異なり、デフォルトの許可リスト * があるかのように動作します。この点が修正され、これらのヒントで明示的な委譲が必須となるため、Android でのプライバシーが改善されます。

U2F API（Cryptotoken）の削除

Chrome で以前にセキュリティ鍵を操作するために使われていた U2F API のサポートが終了します。U2F セキュリティ鍵自体は非推奨ではなく、今後も動作し続けます。

影響を受けるサイトは、Web Authentication API に移行する必要があります。もともと U2F API で登録された認証情報は、ウェブ認証経由でチャレンジできます。U2F API でサポートされる USB セキュリティ鍵も、Web Authentication API のサポート対象です。

U2F は Chrome オリジナルのセキュリティ鍵 API で、フィッシングに強い 2 要素認証システムを構築するために、サイトから USB セキュリティ鍵に公開鍵認証情報を登録して、チャレンジできるようにします。U2F はオープンなウェブ標準になることはなく、Web Authentication API（Chrome 67 でリリース）に取り込まれました。Chrome は FIDO U2F JavaScript API を直接サポートすることはありませんでしたが、同等の機能を持つ chrome.runtime.sendMessage() メソッドを提供する Cryptotoken と呼ばれるコンポーネント拡張機能を公開しました。U2F と Cryptotoken は確実にメンテナンス モードに入っており、ここ 2 年間にわたって Web Authentication API への移行が推奨されています。

Reviewed by Eiji Kitamura - Developer Relations Team