Hiện tại, các nhà phát triển đã có thể sử dụng rộng rãi tiện ích bổ sung của Google Lớp học! Vui lòng xem tài liệu về tiện ích bổ sung để biết thêm thông tin.
Vào ngày 4 tháng 1 năm 2024, Chrome đã ra mắt tính năng Chống theo dõi. Theo mặc định, tính năng này hạn chế quyền truy cập của trang web vào cookie của bên thứ ba (3P) đối với 1% người dùng. Vào đầu năm 2025, Chrome dự kiến sẽ loại bỏ hoàn toàn cookie của bên thứ ba.
Có ít nhất 2 hành trình của người dùng bị ảnh hưởng trong các tiện ích bổ sung của Lớp học:
Quy trình đăng nhập một lần (SSO) của Google
Chuyển người dùng sang thẻ mới
Google SSO
Trong quy trình SSO của Google, người dùng sẽ được chuyển đến một hộp thoại để đăng nhập vào Tài khoản Google và đồng ý chia sẻ dữ liệu.
Hình 1. Hình ảnh minh hoạ 3 bối cảnh cookie khác nhau trong quá trình đăng nhập một lần từ bên trong iframe: (1) ứng dụng Lớp học cấp cao nhất, (2) iframe được nhúng của bên thứ ba (DavidPuzzle trên localhost trong trường hợp này) và (3) hộp thoại OAuth cấp cao nhất.
Trong quá trình triển khai tiện ích bổ sung thông thường, cookie phiên sẽ được đặt khi hoàn tất quy trình đăng nhập này. iframe của tiện ích bổ sung (trong bối cảnh được nhúng) sẽ được tải lại, hiện có cookie phiên, cho phép người dùng truy cập vào phiên đã xác thực của họ. Tuy nhiên, khi cookie của bên thứ ba bị vô hiệu hoá, các trang web trong một bối cảnh được nhúng (chẳng hạn như iframe của tiện ích bổ sung) sẽ không thể truy cập vào cookie từ các bối cảnh cấp cao nhất tương ứng. Đối với các tiện ích bổ sung của Lớp học, người dùng không thể truy cập vào phiên được xác thực của họ và bị mắc kẹt trong vòng lặp đăng nhập.
Đối với những hoạt động triển khai đặt cookie phiên trong ngữ cảnh iframe được nhúng, bạn có thể giảm thiểu vấn đề này bằng CHIPS API. API này cho phép các trang web được nhúng đặt và truy cập vào cookie được phân vùng (cookie được khoá trên cả miền của trình nhúng và miền được nhúng). Tuy nhiên, những hoạt động triển khai đặt cookie phiên trong bối cảnh cấp cao nhất của hộp thoại đăng nhập sẽ không thể truy cập vào cookie chưa phân vùng trong iframe, ngăn chặn quá trình đăng nhập.
Tab mới
Vì những lý do tương tự, nếu người dùng có một phiên được xác thực dựa trên cookie trong iframe của tiện ích bổ sung và iframe này khởi chạy người dùng vào một thẻ cấp cao nhất mới cho một hoạt động, thì thẻ cấp cao nhất sẽ không thể truy cập vào cookie phiên được phân vùng từ iframe. Điều này ngăn trạng thái phiên iframe duy trì hoạt động trên thẻ mới và có thể buộc người dùng đăng nhập lại trong thẻ mới, chẳng hạn.
Theo thiết kế, CHIPS API không thể giải quyết vấn đề này; các cookie iframe được phân vùng không thể truy cập trong ngữ cảnh cấp cao nhất.
Hành động của nhà phát triển
Bạn nên cân nhắc một số hành động để đảm bảo tiện ích bổ sung của bạn tiếp tục hoạt động như dự kiến khi Chrome loại bỏ dần cookie của bên thứ ba.
Chọn sử dụng FedCM. Ngoài ra, nếu bạn sử dụng GIS, thư viện Đăng nhập bằng Google, hướng dẫn chính thức của nhóm Nhận dạng là chọn sử dụng FedCM. Điều này không thay thế các chức năng của cookie bên thứ ba nhưng cuối cùng sẽ được yêu cầu trong GIS như một phần của việc ngừng sử dụng cookie bên thứ ba. FedCM hiện có trong Chrome và được hỗ trợ trong Lớp học, nhưng hành vi và các tính năng vẫn đang được phát triển và chúng tôi luôn sẵn sàng tiếp nhận ý kiến phản hồi.
Di chuyển sang GIS. Nếu bạn sử dụng thư viện GSIv2 không được dùng nữa (còn gọi là thư viện Đăng nhập bằng Google), thì bạn nên di chuyển sang GIS vì chúng tôi chưa rõ có tiếp tục hỗ trợ GSIv2 hay không.
Đăng ký dùng thử phiên bản không dùng nữa muộn hơn. Chrome đang cung cấp một thử nghiệm ngừng sử dụng để cho phép các trường hợp sử dụng không liên quan đến quảng cáo trì hoãn các tác động của việc ngừng sử dụng cookie của bên thứ ba. Nếu được chấp nhận, bạn sẽ nhận được một mã thông báo mà bạn có thể dùng trong tiện ích bổ sung để giữ cho cookie của bên thứ ba được bật cho nguồn gốc của bạn cho đến năm 2024, trong khi di chuyển sang một giải pháp lâu dài như SAA. Sau khi áp dụng, bạn sẽ được yêu cầu cung cấp mã lỗi hoặc đường liên kết cho báo cáo lỗi. Nhóm của chúng tôi đã báo cáo vấn đề này cho tiện ích bổ sung của Lớp học và bạn có thể cung cấp lỗi này.
[[["Dễ hiểu","easyToUnderstand","thumb-up"],["Giúp tôi giải quyết được vấn đề","solvedMyProblem","thumb-up"],["Khác","otherUp","thumb-up"]],[["Thiếu thông tin tôi cần","missingTheInformationINeed","thumb-down"],["Quá phức tạp/quá nhiều bước","tooComplicatedTooManySteps","thumb-down"],["Đã lỗi thời","outOfDate","thumb-down"],["Vấn đề về bản dịch","translationIssue","thumb-down"],["Vấn đề về mẫu/mã","samplesCodeIssue","thumb-down"],["Khác","otherDown","thumb-down"]],["Cập nhật lần gần đây nhất: 2025-08-29 UTC."],[],[],null,["# Prepare for the third-party cookie deprecation\n\n| **Warning:** Chrome has [announced](https://privacysandbox.com/news/privacy-sandbox-update/) that **third-party (3P) cookies are no longer being deprecated** . The guidance described here is no longer necessary, and **add-ons should not be impacted in\n| early 2025**. However, Chrome intends to further elevate user choice around 3P cookies, so there could still be a future where 3P cookie access is more limited than it is today. Therefore, this guide might still be helpful for developers interested in understanding how 3P cookies are used in add-ons and future-proofing against potential changes in 3P cookie availability as the Chrome user experience evolves.\n\nThis guide helps you understand the impact and necessary changes to your add-on\nintroduced by [Chrome ending support for third-party cookies](https://privacysandbox.com/intl/en_us/open-web/#how-works-on-web-hero).\n\nOverview\n--------\n\nOn **January 4, 2024** , Chrome introduced [Tracking Protection](https://blog.google/products/chrome/privacy-sandbox-tracking-protection/), which restricts\nwebsite access to third-party (3P) cookies by default, to 1% of users. In\n**early 2025** , Chrome expects to [phase out 3P cookies completely](https://privacysandbox.com/intl/en_us/open-web/#the-privacy-sandbox-timeline).\n\nAt least two user journeys are impacted in Classroom add-ons:\n\n1. The Google single sign-on (SSO) flow\n2. Launching users into new tabs\n\n### Google SSO\n\nDuring the Google SSO flow, users are navigated to a dialog to sign into their\nGoogle Account and consent to data sharing.\n\n**Figure 1.** Visualization of the three different cookie contexts during SSO\nfrom within an iframe: (1) the top level Classroom app, (2) the 3P embedded\niframe (DavidPuzzle on localhost in this case), and (3) the top level OAuth\ndialog.\n\nIn a typical add-on implementation, a session cookie is set at the completion of\nthis sign-in process. The add-on iframe, which is in an *embedded context* , is\nreloaded, now with the session cookie, allowing the user to access their\nauthenticated session. However, when 3P cookies are disabled, sites in an\nembedded context like add-on iframes can't access cookies from their respective\n*top level* contexts. For Classroom add-ons, the user is unable to access their\nauthenticated session and becomes stuck in a sign-in loop.\n\nFor implementations that set the session cookie in the embedded iframe context,\nthis issue can be mitigated by the [CHIPS API](https://developers.google.com/privacy-sandbox/3pcd/chips), which allows embedded sites to\nset and access partitioned cookies (cookies keyed on both the embedder and\nembedded domain). However, implementations that set the session cookie in the\ntop level context of the sign-in dialog are unable to access the unpartitioned\ncookie in the iframe, preventing sign-in.\n\n### New tabs\n\nFor similar reasons, if a user has a cookie-based authenticated session in an\nadd-on iframe, and the iframe launches the user into a new top level tab for an\nactivity, the top level tab is unable to access the partitioned session cookie\nfrom iframe. This prevents iframe session state from persisting to the new tab\nactivity and might force the user to sign in again in the new tab, for example.\nThe [CHIPS API](https://developers.google.com/privacy-sandbox/3pcd/chips) is not able to resolve this issue, by design; the partitioned\niframe cookies are inaccessible in a top level context.\n\nDeveloper actions\n-----------------\n\nThere are a few actions you should consider to ensure your add-on continues to\nfunction as intended as Chrome phases out 3P cookies.\n\n1. **Audit** [3P cookie usage](https://developers.google.com/privacy-sandbox/blog/cookie-countdown-2023oct#audit) in your add-on's critical user journeys. More specifically, [test with 3P cookies disabled](https://developer.chrome.com/blog/cookie-countdown-2023oct/#test) to evaluate the impact for your specific implementation.\n2. **Explore Storage Access API** . For all add-on implementations, we recommend\n that you explore the [Storage Access](https://developers.google.com/privacy-sandbox/3pcd/storage-access-api) API (SAA). SAA enables iframes to\n access their cookies outside the iframe context. SAA is available in Chrome\n today, and is supported by the Classroom app.\n\n | **Note:** If your SSO flow does not set cookies in the dialog context and your add-on does not launch users into top-level tabs, you might not need SAA. Explore the simpler [CHIPS API](https://developers.google.com/privacy-sandbox/3pcd/chips) to see if it meets your needs.\n3. **Opt-in to FedCM** . In addition, if you use [GIS](https://developers.google.com/identity/gsi/web/guides/overview), the Sign in with Google\n library, the official guidance from the Identity team is to [opt-in to\n FedCM](https://developers.google.com/identity/gsi/web/guides/fedcm-migration). This does not replace 3P cookie capabilities but it will eventually\n be required in GIS as part of the 3P cookie deprecation. FedCM is available\n in Chrome today and supported in Classroom, but behavior and features are\n still [under development](https://github.com/fedidcg/FedCM) and open to feedback.\n\n4. **Migrate to GIS** . If you use the deprecated [GSIv2 library](https://developers.google.com/identity/sign-in/web/sign-in), also known as\n the Google Sign-In library, it is strongly recommended that you [migrate to\n GIS](https://developers.google.com/identity/gsi/web/guides/migration), as support for GSIv2 going forward is unclear.\n\n5. **Apply for a deprecation trial delay** . Chrome is offering a [deprecation\n trial](https://developers.google.com/privacy-sandbox/blog/third-party-cookie-deprecation-trial) to allow non-advertising use cases to delay the effects of the 3P\n cookie deprecation. If accepted, you'll be given a token that you can use in\n your add-on to keep 3P cookies enabled for your origin through 2024, while\n migrating to a long term solution like SAA. After [applying](https://developers.google.com/privacy-sandbox/blog/third-party-cookie-deprecation-trial#apply_for_the_deprecation_trials), you'll be\n asked to provide a bug ID or link for a breakage report. Our team has\n already filed this for Classroom add-ons and you can provide [this bug](https://issuetracker.google.com/issues/273552829).\n\n| **Warning:** Developers who are accepted into the deprecation trial will automatically have 3P cookies enabled during a [grace period](https://developers.google.com/privacy-sandbox/blog/third-party-cookie-deprecation-trial#:%7E:text=We%20acknowledge%20that,the%20grace%20period) even without the token in their app. Be aware of this caveat if you'd like use the 1% deprecation to test your how your add-on functions without 3P cookies.\n| **Note:** The deprecation trial is intended for *existing* applications. If you're building an add-on today, plan to build with SAA or another implementation that allows the add-on to function without 3P cookies. You might not qualify for the deprecation trial if you don't already have an affected application.\n| **Note:** Chrome has [announced a timeline](https://privacysandbox.com/intl/en_us/news/update-on-the-plan-for-phase-out-of-third-party-cookies-on-chrome/) shift in the 3P cookie phaseout from the second half of 2024 to early 2025. This change might impact duration of the deprecation trial, and this page will be updated to reflect changes."]]
