[날짜] 퍼스트 파티 세트 및 SameParty 속성

많은 조직들이 다음과 같이 서로 다른 도메인 이름을 가진 관련 사이트를 보유하고 있습니다. brandx.sitefly-brandx.site, 또는 다음과 같은 다른 국가의 도메인 example.com, example.rs, example.co.uk

브라우저는 서드 파티 쿠키를 만드는 방향으로 나아가고 있습니다. 더 이상 사용되지 않음 개인 정보 보호를 개선하고자 했으나, 이와 같은 사이트는 주로 개인 정보 보호를 위해 여러 도메인에서 상태를 유지하고 액세스해야 하는 기능 (예: 싱글 사인온(SSO), 동의 관리)

퍼스트 파티 세트는 다음에서 소유하고 운영하는 관련 도메인 이름을 허용할 수 있습니다. 같은 법인이 제1사와 그 외의 경우에는 다르게 취급됩니다. 도메인 내의 도메인 이름은 퍼스트 파티 쿠키는 동일 파티로 간주되며, 퍼스트 파티 쿠키는 전송 의도를 명시해야 합니다. 목표는 제3자의 크로스 사이트 추적을 방지하는 동시에 유효한 사용 사례를 위반하지 않는 경로를 유지합니다.

퍼스트 파티 세트 제안서는 현재 테스트 중입니다. 이 단계를 계속 읽으면서 작동 방식을 알아보세요. 시도해 볼 수 있습니다.

퍼스트 파티 쿠키와 서드 파티 쿠키의 차이점은 무엇인가요?

쿠키는 본질적으로 퍼스트 파티 또는 서드 파티가 아니며 현재 사용 중인 컨텍스트가 포함됩니다. 이는 cookie 헤더 또는 JavaScript의 document.cookie를 통해 가능합니다.

예를 들어 인터넷을 탐색할 때 video.sitetheme=dark 쿠키가 있는 경우 video.site에 대한 요청이 video.site에 전송된 경우 이는 동일 사이트입니다. 컨텍스트와 포함된 쿠키는 퍼스트 파티 쿠키입니다.

하지만 my-blog.site 페이지에 iframe 플레이어가 삽입된 경우 video.site: my-blog.site에서 video.site로 요청이 이루어진 경우 크로스 사이트 컨텍스트이고 theme 쿠키는 서드 파티 쿠키입니다.

두 가지 컨텍스트에서 video.site의 쿠키를 보여주는 다이어그램 최상위 컨텍스트도 video.site인 경우 쿠키는 동일한 사이트입니다. 최상위 컨텍스트가 my-blog.site이며 iframe에 video.site가 있는 경우 쿠키는 크로스 사이트입니다.

쿠키 포함은 다음과 같이 쿠키의 SameSite 속성에 따라 결정됩니다.

  • 동일 사이트 컨텍스트SameSite=Lax, Strict 또는 None는 쿠키를 퍼스트 파티로 만듭니다.
  • SameSite=None를 사용하는 크로스 사이트 컨텍스트는 쿠키가 서드 파티 쿠키가 됩니다.

하지만 항상 명확하게 할 수 있는 것은 아닙니다. brandx.site이(가) 여행이라고 가정해 보겠습니다. fly-brandx.sitedrive-brandx.site를 이용해 별도의 항공편과 렌터카를 렌트할 수 있습니다. 한 여정을 예약하는 동안 방문자는 이러한 사이트를 오가며 다양한 옵션을 선택할 수 있습니다. '장바구니' 이 사이트 전반에 걸쳐 지속될 수 있습니다. brandx.site SameSite=None 쿠키로 사용자 세션을 관리하여 다음을 허용합니다. 교차 사이트 컨텍스트입니다. 단점은 쿠키에 크로스 사이트가 없다는 것입니다. 위조 (CSRF) 보호를 요청합니다. evil.sitebrandx.site이면 해당 쿠키가 포함됩니다.

쿠키는 크로스 사이트이지만 모든 사이트는 동일한 도메인에 의해 소유 및 운영됩니다. 되었습니다. 방문자는 또한 해당 업체가 같은 조직임을 이해하고 동일한 세션, 다시 말해 동일한 세션 간에 ID가 공유됩니다.

사이트가 동일한 퍼스트 파티 세트에 속한 경우 쿠키가 크로스 사이트 컨텍스트에 계속 포함될 수 있지만 세트 외부의 크로스 사이트 컨텍스트에 대해서는 거부되는 방식을 보여주는 다이어그램

퍼스트 파티 세트 정책

퍼스트 파티 세트는 이 관계를 명시적으로 정의하는 방법을 사용하여 이러한 관계를 동일한 당사자가 소유하고 운영하는 캠페인입니다. 이렇게 하면 brandx.site에서 다음을 실행할 수 있습니다. fly-brandx.site와의 퍼스트 파티 관계 정의 drive-brandx.site

개인 정보 보호 모델은 다양한 개인 정보 보호 샌드박스 제안은 Google ID를 사용하여 크로스 사이트 추적을 방지합니다. 사용자 식별에 사용할 수 있는 정보에 대한 액세스를 제한합니다.

여러 크로스 사이트 컨텍스트에서 동일한 서드 파티 쿠키에 액세스할 수 있는 파티션을 나누지 않은 상태를 보여주는 다이어그램과 대조적으로, 각 최상위 컨텍스트에 개별 크로스 사이트 쿠키 인스턴스가 있어 이러한 사이트 간의 연결 활동을 차단하는 파티션을 나눈 모델입니다.

기본 옵션은 사이트별로 파티셔닝하는 것이지만, 이 경우 많은 퍼스트 파티 데이터를 brandx.site 예는 퍼스트 파티가 더 클 수 있음을 보여줍니다. 훨씬 더 효과적입니다.

모든 사이트가 동일한 집합에 속한 경우 한 세트의 쿠키 인스턴스가 크로스 사이트 컨텍스트에 포함되는 방식을 보여주는 다이어그램

퍼스트 파티 세트 제안서의 중요한 부분은 정책이 오용을 방지할 수 있습니다 예를 들어 퍼스트 파티 세트는 관련 없는 사이트에서 사용자 정보를 교환하거나 동일한 법인이 소유하지 않은 사이트의 경우 이 아이디어는 퍼스트 파티 세트는 사용자가 퍼스트 파티로 이해하는 것으로 매핑되며 다른 당사자 간에 ID를 공유하는 방법으로 사용되지 않습니다.

사이트에서 퍼스트 파티 세트를 등록하는 한 가지 가능한 방법은 제안 도메인 그룹을 공개 추적 프로그램 (예: 전용 GitHub 저장소)를 사용하여 브라우저를 만족시키는 데 필요한 정보와 함께 정책

퍼스트 파티 세트 어설션이 정책에 따라 확인되면 브라우저에서 업데이트 프로세스를 통해 세트 목록을 가져옵니다.

오리진 트라이얼에는 최종적이지 않은 정의된 정책이 있지만 원칙은 다음과 같습니다. 유지될 가능성이 높음:

  • 자사 집합에 포함된 도메인은 동일한 업체에서 소유하고 운영해야 합니다. 되었습니다.
  • 사용자가 그룹으로 인식할 수 있어야 합니다.
  • 도메인마다 공통의 개인정보처리방침을 공유해야 합니다.
를 통해 개인정보처리방침을 정의할 수 있습니다.

퍼스트 파티 세트를 정의하는 방법

조직 퍼스트 파티의 구성원과 소유자를 확인한 후 설정할 때 중요한 단계는 승인을 위해 제안된 세트를 제출하는 것입니다. 정확한 아직 논의 중입니다.

퍼스트 파티 세트를 선언하려면 구성원과 소유자가 나열된 정적 JSON 리소스를 선언합니다. 각 도메인의 최상위 레벨의 /.well-known/first-party-set에서 호스팅해야 합니다. 포함된 도메인입니다.

brandx 퍼스트 파티 세트의 예에서 소유자 도메인은 에서 팔로우 중 https://brandx.site/.well-known/first-party-set:

{
 
"owner": "brandx.site",
 
"version": 1,
 
"members": ["fly-brandx.site", "drive-brandx.site"]
}

또한 세트의 각 멤버는 집합의 소유자입니다. https://fly-brandx.site/.well-known/first-party-set에는 다음 사항이 있습니다.

{ "owner": "brandx.site" }

그리고 https://drive-brandx.site/.well-known/first-party-set에서:

{ "owner": "brandx.site" }

퍼스트 파티 세트에는 다음과 같은 몇 가지 제약이 있습니다.

  • 집합에는 소유자가 한 명만 있을 수 있습니다.
  • 멤버는 한 세트에만 속할 수 있으며 중복되거나 혼합되어서는 안 됩니다.
  • 회원 목록은 비교적 사람이 쉽게 읽을 수 있도록 만들어졌으며 너무 큽니다.
를 통해 개인정보처리방침을 정의할 수 있습니다.

퍼스트 파티 세트는 쿠키에 어떤 영향을 주나요?

쿠키와 일치하는 재료는 제안된 SameParty입니다. 속성을 사용합니다. SameParty 지정 는 컨텍스트가 동일한 퍼스트 파티를 최상위 컨텍스트로 설정합니다.

즉, brandx.site가 이 쿠키를 설정하는 경우:

Set-Cookie: session=123; Secure; SameSite=Lax; SameParty

그런 다음 방문자가 fly-brandx.site 상태이고 요청이 다음으로 이동하면 brandx.site이면 session 쿠키가 해당 요청에 포함됩니다. 예를 들어 퍼스트 파티 세트에 포함되지 않은 다른 사이트인 경우 hotel.xyz, brandx.site에 요청을 전송하면 쿠키가 포함되지 않습니다.

설명된 대로 크로스 사이트 컨텍스트에서 허용되거나 차단된 brandx.site 쿠키를 보여주는 다이어그램

SameParty가 널리 지원될 때까지는 SameSite 속성을 함께 사용하여 다음 작업을 수행하세요. 쿠키의 대체 동작을 정의합니다. SameParty를 생각하면 됩니다. 속성에 SameSite=LaxSameSite=None입니다.

  • SameSite=Lax; SamePartyLax 기능을 확장하여 지원되는 경우 동일 당사자 컨텍스트가 포함되지만 Lax로 대체됩니다. 될 수 있습니다
  • SameSite=None; SameParty에서 다음과 같이 None 기능을 제한합니다. 동일한 당사자 맥락만 지원되며 더 넓은 범위의 맥락으로 대체됩니다. 권한이 없으면 None 권한을 반환합니다.

다음과 같은 몇 가지 추가 요건이 있습니다.

  • SameParty 쿠키에는 Secure포함되어야 합니다.
  • SameParty 쿠키에는 SameSite=Strict가 포함되면 안 됩니다.

Secure은(는) 여전히 크로스 사이트이므로 필수이며 이를 완화해야 합니다. 위험을 감수할 수 있습니다 마찬가지로 이것은 SameSite=Strict은(는) 여전히 다음을 허용하므로 유효하지 않습니다. 보안 툴을 기반으로 구축되었습니다.

퍼스트 파티 세트에 적합한 사용 사례는 무엇인가요?

퍼스트 파티 세트는 조직이 다음과 같은 형태를 갖추어야 하는 케이스에 적합합니다. 서로 다른 최상위 사이트 간에 공유 ID를 공유할 수 있습니다 이 경우 공유 ID 완전한 싱글 사인온(SSO) 솔루션에서부터 공유 클라우드를 필요로 하는 것까지 사이트 전반의 환경설정

조직에서 다음과 같은 최상위 도메인을 사용하고 있을 수 있습니다.

  • 앱 도메인: office.com,live.com, microsoft.com
  • 브랜드 도메인: amazon.com, audible.com / disney.com, pixar.com
  • 현지화를 사용할 국가별 도메인: google.co.in, google.co.uk
  • 사용자가 직접 상호작용하지 않지만 제공하는 서비스 도메인 동일한 조직의 사이트에 있는 서비스: gstatic.com, fbcdn.netgithubassets.com
  • 사용자가 직접 상호작용하지 않지만 존재하는 샌드박스 도메인 보안 사유: googleusercontent.com, githubusercontent.com

어떻게 참여할 수 있나요?

위의 기준과 일치하는 일련의 사이트가 있는 경우 많은 옵션이 있습니다. 가장 간단한 방법은 읽기 및 조인을 수행하는 것입니다 다음 두 가지 제안에 대한 논의를 살펴보겠습니다.

테스트 단계에서 --use-first-party-set 명령줄 플래그 및 쉼표로 구분된 목록 제공 사이트 수

다음 데모 사이트에서 시도해 볼 수 있습니다. 시작 후 https://fps-member1.glitch.me/ 다음 플래그가 포함된 Chrome:

--use-first-party-set=https://fps-member1.glitch.me,https://fps-member2.glitch.me,https://fps-member3.glitch.me

이는 개발 환경에서 테스트하거나 실제 환경에 SameParty 속성을 추가하여 쿠키에 영향을 주게 됩니다.

실험과 의견을 공유할 여유가 있다면 퍼스트 파티 세트 및 SameParty 이 버전은 Chrome 버전 89부터 93까지 사용할 수 있습니다

오리진 트라이얼의 쿠키를 업데이트하는 방법

오리진 트라이얼에 참여하여 다음에서 SameParty 속성을 테스트하는 경우 다음과 같은 두 가지 패턴을 고려해야 합니다.

옵션 1

첫째, SameSite=None로 라벨이 지정되지만 퍼스트 파티 컨텍스트로 제한하려는 경우 SameParty 속성을 지정해야 합니다. 오리진 트라이얼이 활성화된 브라우저에서는 쿠키가 세트 외부의 크로스 사이트 컨텍스트에서 전송되지 않습니다.

그러나 대부분의 오리진 트라이얼 이외의 브라우저에서는 쿠키가 계속 전송됩니다. 크로스 사이트를 이용하는 것입니다. 이를 점진적인 개선 방법으로 간주하세요.

변경 전: <ph type="x-smartling-placeholder">set-cookie: cname=cval; SameSite=None; Secure</ph>

변경 후: <ph type="x-smartling-placeholder">set-cookie: cname=cval; SameSite=None; Secure; SameParty</ph>

옵션 2

두 번째 옵션은 추가 작업이지만 원본을 완전히 분리할 수 있습니다. 무료 체험판으로 대체되며 구체적으로는 SameSite=Lax; SameParty 조합

변경 전: <ph type="x-smartling-placeholder">set-cookie: cname=cval; SameSite=None; Secure</ph>

변경 후:

set-cookie: cname=cval; SameSite=None; Secure
set-cookie: cname-fps=cval; SameSite=Lax; Secure; SameParty

수신되는 요청에서 쿠키를 확인할 때는 관련된 사이트가 다음에 있는 경우 크로스 사이트 요청의 cname-fps 쿠키 브라우저가 오리진 트라이얼에 있는지 확인합니다. 이 접근 방식을 업데이트된 기능을 동시에 출시하지 않으면 있습니다.

퍼스트 파티 세트가 필요하지 않은 이유는 무엇인가요?

대부분의 사이트는 사이트 경계선을 사용하여 경계 또는 프라이버시 경계입니다. Google에서 제안하는 경로입니다. CHIPS (독립적으로 파티셔닝된 쿠키) 상태)가 있어야 합니다. 여전히 중요한 크로스 사이트를 갖도록 Partitioned 속성을 통해 라우팅합니다. 리소스, API 및 서비스를 삽입하고, 이를 통해 사용자 식별 정보를 유용한 정보를 얻을 수 있습니다.

별도의 작업 없이 사이트가 괜찮을 수도 있다는 점을 고려할 때 세트:

  • 다른 사이트가 아닌 다른 출처에서 호스팅하는 경우 위의 예에서 brandx.sitefly.brandx.sitedrive.brandx.site이(가) 있으면 동일한 사이트 내의 서로 다른 하위 도메인 쿠키는 SameSite=Lax로 설정하면 별도의 설정이 필요하지 않습니다.
  • 다른 사이트에 삽입한 타사 콘텐츠를 제공하는 경우 인트로에서 my-blog.site에 퍼간 video.site의 동영상이 명확한 서드 파티임 나누기 때문입니다. 여러 조직에서 운영하는 사이트이며 사용자가 이를 볼 수 있습니다. 별도의 항목으로 처리합니다 이 두 사이트는 같은 세트에 포함되어서는 안 됩니다.
  • 서드 파티 소셜 로그인 서비스를 제공하는 경우 다음을 사용하는 ID 공급업체 OAuth 또는 OpenId 연결과 같은 항목은 종종 서드 파티 쿠키를 사용하여 사용자를 위해 더 원활한 로그인 환경을 제공합니다. 유효한 사용 사례이지만 그렇지 않습니다. 조직에 분명한 차이가 있으므로 퍼스트 파티 세트에 적합합니다. WebID 같은 초기 제안은 이러한 사용 사례를 지원하는 방법을 모색합니다.