2024년 1월 4일 Chrome에서는 기본적으로 서드 파티 (3P) 쿠키에 대한 웹사이트 액세스를 제한하는 추적 보호 기능을 사용자 1% 에게 도입했습니다. 2025년 초에 Chrome은 서드 파티 쿠키를 완전히 단계적으로 지원 중단할 것으로 예상됩니다.
클래스룸 부가기능에서 영향을 받는 사용자 여정은 최소 2개입니다.
Google 싱글 사인온 (SSO) 흐름
새 탭에서 사용자를 실행
Google SSO
Google SSO 흐름 중에 사용자는 Google 계정에 로그인하고 데이터 공유에 동의하는 대화상자로 이동합니다.
그림 1. iframe 내에서 SSO 중에 발생하는 세 가지 쿠키 컨텍스트 시각화: (1) 최상위 Classroom 앱, (2) 서드 파티 삽입 iframe (이 경우 localhost의 DavidPuzzle), (3) 최상위 OAuth 대화상자
일반적인 부가기능 구현에서는 이 로그인 프로세스가 완료되면 세션 쿠키가 설정됩니다. 삽입된 컨텍스트에 있는 부가기능 iframe이 이제 세션 쿠키와 함께 다시 로드되어 사용자가 인증된 세션에 액세스할 수 있습니다. 하지만 서드 파티 쿠키가 사용 중지되면 애드온 iframe과 같은 삽입된 컨텍스트의 사이트가 각 최상위 컨텍스트의 쿠키에 액세스할 수 없습니다. 클래스룸 부가기능의 경우 사용자가 인증된 세션에 액세스할 수 없으며 로그인 루프에 갇히게 됩니다.
삽입된 iframe 컨텍스트에서 세션 쿠키를 설정하는 구현의 경우 삽입된 사이트가 파티셔닝된 쿠키 (삽입자와 삽입된 도메인 모두에서 키가 지정된 쿠키)를 설정하고 액세스할 수 있는 CHIPS API를 사용하여 이 문제를 완화할 수 있습니다. 하지만 로그인 대화상자의 최상위 컨텍스트에서 세션 쿠키를 설정하는 구현은 iframe에서 파티션을 나누지 않은 쿠키에 액세스할 수 없어 로그인이 차단됩니다.
새 탭
이와 비슷한 이유로 사용자가 애드온 iframe에서 쿠키 기반 인증 세션을 가지고 있고 iframe이 활동을 위해 사용자를 새 최상위 탭으로 실행하는 경우 최상위 탭은 iframe에서 파티셔닝된 세션 쿠키에 액세스할 수 없습니다. 이렇게 하면 iframe 세션 상태가 새 탭 활동에 유지되지 않으므로 사용자가 새 탭에서 다시 로그인해야 할 수 있습니다.
CHIPS API는 설계상 이 문제를 해결할 수 없습니다. 파티셔닝된 iframe 쿠키는 최상위 컨텍스트에서 액세스할 수 없습니다.
개발자 작업
Chrome에서 서드 파티 쿠키를 단계적으로 폐지함에 따라 부가기능이 의도한 대로 계속 작동하도록 하기 위해 고려해야 할 몇 가지 조치가 있습니다.
Storage Access API 살펴보기 모든 부가기능 구현의 경우 Storage Access API (SAA)를 살펴보는 것이 좋습니다. SAA를 사용하면 iframe이 iframe 컨텍스트 외부에서 쿠키에 액세스할 수 있습니다. SAA는 현재 Chrome에서 사용할 수 있으며 클래스룸 앱에서 지원됩니다.
FedCM 선택 또한 GIS, Google 계정으로 로그인 라이브러리를 사용하는 경우 ID팀의 공식 안내는 FedCM을 선택하는 것입니다. 이는 서드 파티 쿠키 기능을 대체하지는 않지만 결국 서드 파티 쿠키 지원 중단의 일환으로 GIS에서 필요하게 됩니다. FedCM은 현재 Chrome에서 사용할 수 있으며 클래스룸에서 지원되지만 동작과 기능은 아직 개발 중이며 의견을 수렴하고 있습니다.
GIS로 마이그레이션 지원 중단된 GSIv2 라이브러리(Google 로그인 라이브러리라고도 함)를 사용하는 경우 향후 GSIv2 지원이 불확실하므로 GIS로 마이그레이션하는 것이 좋습니다.
지원 중단 트라이얼 지연 신청 Chrome은 비광고 사용 사례에서 서드 파티 쿠키 지원 중단의 영향을 지연할 수 있도록 지원 중단 트라이얼을 제공하고 있습니다. 신청이 승인되면 2024년까지 서드 파티 쿠키를 사용 설정된 상태로 유지하면서 SAA와 같은 장기 솔루션으로 이전하는 동안 애드온에서 사용할 수 있는 토큰이 제공됩니다. 신청 후에는 중단 보고서의 버그 ID 또는 링크를 제공하라는 메시지가 표시됩니다. Google팀에서 이미 클래스룸 부가기능에 대해 이 문제를 신고했으므로 이 버그를 제공할 수 있습니다.
[null,null,["최종 업데이트: 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."]]
