많은 조직에는 brandx.site 및 fly-brandx.site와 같이 도메인 이름이 다른 관련 사이트가 있거나 example.com, example.rs, example.co.uk와 같이 국가별 도메인이 있습니다.
브라우저는 웹의 개인 정보 보호를 개선하기 위해 서드 파티 쿠키를 지원 중단하는 방향으로 전환하고 있지만, 이러한 사이트는 도메인 전반에서 상태를 유지하고 액세스해야 하는 기능(예: 싱글 사인온, 동의 관리)에 쿠키를 사용하는 경우가 많습니다.
퍼스트 파티 세트를 사용하면 퍼스트 파티와 서드 파티가 다르게 취급되는 상황에서 동일한 법인이 소유하고 운영하는 관련 도메인 이름을 퍼스트 파티로 취급할 수 있습니다. 퍼스트 파티 세트 내의 도메인 이름은 퍼스트 파티로 간주되며 퍼스트 파티 컨텍스트에서 설정하거나 전송하려는 쿠키에 라벨을 지정할 수 있습니다. 목표는 서드 파티의 교차 사이트 추적을 방지하면서 유효한 사용 사례를 중단하지 않는 경로를 유지하는 것입니다.
퍼스트 파티 세트 제안은 현재 테스트 단계에 있습니다. 작동 방식과 사용해 볼 수 있는 방법을 알아보려면 계속 읽어보세요.
퍼스트 파티 쿠키와 서드 파티 쿠키의 차이점은 무엇인가요?
쿠키는 본질적으로 퍼스트 파티 또는 서드 파티가 아닙니다. 쿠키가 포함된 현재 컨텍스트에 따라 다릅니다. cookie 헤더의 요청 또는 JavaScript의 document.cookie를 통해 설정할 수 있습니다.
예를 들어 video.site에 theme=dark 쿠키가 있는 경우 video.site를 탐색하고 video.site에 요청이 이루어지면 동일 사이트 컨텍스트이며 포함된 쿠키는 퍼스트 파티입니다.
하지만 video.site용 iframe 플레이어를 삽입하는 my-blog.site에 있는 경우 my-blog.site에서 video.site로 요청이 이루어지면 교차 사이트 컨텍스트가 되고 theme 쿠키는 서드 파티입니다.
쿠키 포함 여부는 쿠키의 SameSite 속성에 따라 결정됩니다.
SameSite=Lax,Strict또는None가 있는 Same-site 컨텍스트는 쿠키를 퍼스트 파티로 만듭니다.SameSite=None를 사용한 교차 사이트 컨텍스트는 쿠키를 서드 파티로 만듭니다.
하지만 항상 명확한 것은 아닙니다. brandx.site가 여행 예약 사이트이고 fly-brandx.site 및 drive-brandx.site를 사용하여 항공편과 렌터카를 구분한다고 가정해 보겠습니다. 방문자는 여정을 하나 예약하는 과정에서 이러한 사이트 간에 이동하여 다양한 옵션을 선택합니다. 선택한 '장바구니'가 이러한 사이트 전반에서 유지되기를 기대합니다. brandx.site는 SameSite=None 쿠키로 사용자의 세션을 관리하여 크로스 사이트 컨텍스트에서 이를 허용합니다. 단점은 이제 쿠키에 크로스 사이트 요청 위조 (CSRF) 보호가 없다는 점입니다. evil.site에 brandx.site에 대한 요청이 포함되어 있으면 해당 쿠키가 포함됩니다.
쿠키는 크로스 사이트이지만 모든 사이트는 동일한 조직에서 소유하고 운영합니다. 방문자는 또한 동일한 조직임을 이해하고 동일한 세션, 즉 공유 ID를 원합니다.
First-Party Sets 정책
퍼스트 파티 세트는 동일한 당사자가 소유하고 운영하는 여러 사이트에서 이 관계를 명시적으로 정의하는 메서드를 제안합니다. 이렇게 하면 brandx.site가 fly-brandx.site, drive-brandx.site 등과의 퍼스트 파티 관계를 정의할 수 있습니다.
다양한 개인 정보 보호 샌드박스 제안을 구동하는 개인 정보 보호 모델은 교차 사이트 추적을 방지하기 위해 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"]
}
세트의 각 구성원은 세트의 소유자를 다시 가리키는 정적 JSON 리소스도 호스팅합니다.
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에 요청을 전송하면 쿠키가 포함되지 않습니다.
SameParty가 광범위하게 지원될 때까지 SameSite 속성과 함께 사용하여 쿠키의 대체 동작을 정의합니다. SameParty 속성은 SameSite=Lax과 SameSite=None 사이의 설정을 제공한다고 생각할 수 있습니다.
SameSite=Lax; SameParty는 지원되는 경우 동일 당사자 컨텍스트를 포함하도록Lax기능을 확장하지만 지원되지 않는 경우에는Lax제한사항으로 대체됩니다.SameSite=None; SameParty는 지원되는 경우 동일 당사자 컨텍스트로만None기능을 제한하지만 지원되지 않는 경우에는 더 광범위한None권한으로 대체됩니다.
다음과 같은 추가 요구사항이 있습니다.
SameParty쿠키에는Secure가 있어야 합니다.SameParty쿠키에는SameSite=Strict이 포함되어 있으면 안 됩니다.
여전히 교차 사이트이므로 Secure가 필수이며 보안 (HTTPS) 연결을 통해 이러한 위험을 완화해야 합니다. 마찬가지로 교차 사이트 관계이므로 SameSite=Strict는 유효하지 않습니다. 세트 내에서 여전히 엄격한 사이트 기반 CSRF 보호를 허용하기 때문입니다.
퍼스트 파티 세트의 적절한 사용 사례는 무엇인가요?
퍼스트 파티 세트는 조직에서 여러 최상위 사이트에 공유 ID의 한 형태가 필요한 경우에 적합합니다. 여기서 공유 ID란 전체 싱글 사인온 솔루션부터 사이트 간에 공유 환경설정이 필요한 경우까지를 의미합니다.
조직에 다음과 같은 최상위 도메인이 다를 수 있습니다.
- 앱 도메인:
office.com,live.com,microsoft.com - 브랜드 도메인:
amazon.com,audible.com/disney.com,pixar.com - 현지화를 사용 설정하는 국가별 도메인:
google.co.in,google.co.uk - 사용자가 직접 상호작용하지는 않지만 동일한 조직의 사이트에서 서비스를 제공하는 서비스 도메인:
gstatic.com,githubassets.com,fbcdn.net - 사용자가 직접 상호작용하지 않지만 보안상의 이유로 존재하는 샌드박스 도메인:
googleusercontent.com,githubusercontent.com
어떻게 참여할 수 있나요?
위의 기준에 부합하는 사이트가 있다면 참여할 수 있는 여러 옵션이 있습니다. 가장 가벼운 투자는 두 가지 제안서에 관한 논의를 읽고 참여하는 것입니다.
테스트 단계에서는 --use-first-party-set 명령줄 플래그를 사용하고 쉼표로 구분된 사이트 목록을 제공하여 기능을 사용해 볼 수 있습니다.
다음 플래그를 사용하여 Chrome을 시작한 후 https://fps-member1.glitch.me/의 데모 사이트에서 이 기능을 사용해 볼 수 있습니다.
--use-first-party-set=https://fps-member1.glitch.me,https://fps-member2.glitch.me,https://fps-member3.glitch.me
이는 개발 환경에서 테스트하거나 SameParty 속성을 실시간 환경에 추가하여 퍼스트 파티 세트가 쿠키에 미치는 영향을 확인하려는 경우에 유용합니다.
실험 및 의견 보내기에 여유가 있다면 Chrome 버전 89~93에서 사용할 수 있는 퍼스트 파티 세트 및 SameParty의 오리진 트라이얼에 가입할 수도 있습니다.
출처 체험판의 쿠키를 업데이트하는 방법
출처 무료 체험에 참여하고 쿠키에서 SameParty 속성을 테스트하는 경우 다음 두 가지 패턴을 고려해 보세요.
옵션 1
먼저 SameSite=None로 라벨을 지정했지만 퍼스트 파티 컨텍스트로 제한하려는 쿠키가 있는 경우 SameParty 속성을 추가할 수 있습니다. 출처 무료 체험이 활성 상태인 브라우저에서는 쿠키가 세트 외부의 교차 사이트 컨텍스트로 전송되지 않습니다.
하지만 출처 체험판에 포함되지 않은 대부분의 브라우저의 경우 쿠키는 평소와 같이 교차 사이트로 계속 전송됩니다. 점진적 개선 접근 방식으로 생각해 보세요.
이전:
set-cookie: cname=cval; SameSite=None; Secure
이후:
set-cookie: cname=cval; SameSite=None; Secure; SameParty
옵션 2
두 번째 옵션은 더 많은 작업이 필요하지만 출처 트라이얼을 기존 기능과 완전히 분리할 수 있으며 특히 SameSite=Lax; SameParty 조합을 테스트할 수 있습니다.
이전:
set-cookie: cname=cval; SameSite=None; Secure
변경 후:
set-cookie: cname=cval; SameSite=None; Secure
set-cookie: cname-fps=cval; SameSite=Lax; Secure; SameParty
수신 요청에서 쿠키를 확인할 때는 관련 사이트가 세트에 있고 브라우저가 출처 체험판에 있는 경우에만 교차 사이트 요청에서 cname-fps 쿠키가 표시될 것으로 예상해야 합니다. 이 접근 방식은 이전 버전을 중단하기 전에 업데이트된 기능을 동시에 출시하는 것과 같습니다.
퍼스트 파티 세트가 필요하지 않은 이유는 무엇인가요?
대부분의 사이트의 경우 사이트 경계가 파티션 또는 개인 정보 보호 경계를 그릴 수 있는 적절한 위치입니다. 이는 CHIPS (독립적으로 파티션된 상태를 가진 쿠키)와 함께 제안된 경로로, 사이트에서 Partitioned 속성을 통해 선택 경로를 제공하여 이러한 중요한 교차 사이트 삽입, 리소스, API, 서비스를 계속 유지하면서 사이트 전반에서 식별 정보가 유출되는 것을 방지할 수 있습니다.
다음과 같은 경우에도 설정 없이 사이트가 정상적으로 작동할 수 있습니다.
- 다른 사이트가 아닌 다른 출처에서 호스팅합니다. 위의 예에서
brandx.site에fly.brandx.site및drive.brandx.site가 있는 경우 이는 모두 동일한 사이트 내에 있는 서로 다른 하위 도메인입니다. 쿠키는SameSite=Lax를 사용할 수 있으며 설정이 필요하지 않습니다. - 다른 사이트에 서드 파티 삽입을 제공합니다. 인트로에서
my-blog.site에 삽입된video.site의 동영상 예는 명확한 서드 파티 구분입니다. 사이트가 서로 다른 조직에서 운영하며 사용자는 이를 별개의 항목으로 인식합니다. 이 두 사이트는 함께 포함되어서는 안 됩니다. - 서드 파티 소셜 로그인 서비스를 제공합니다. OAuth 또는 OpenId Connect와 같은 것을 사용하는 ID 공급업체는 사용자의 원활한 로그인 환경을 위해 서드 파티 쿠키를 사용하는 경우가 많습니다. 유효한 사용 사례이지만 조직에 명확한 차이가 있으므로 퍼스트 파티 집합에는 적합하지 않습니다. WebID와 같은 초기 제안서에서는 이러한 사용 사례를 지원하는 방법을 모색하고 있습니다.