많은 조직에는 도메인 이름(예: brandx.site, fly-brandx.site)이 서로 다른 관련 사이트 또는 국가별 도메인(예: example.com, example.rs, example.co.uk 등)이 있습니다.
브라우저는 웹의 개인 정보 보호를 개선하기 위해 서드 파티 쿠키를 지원 중단하는 방향으로 나아가고 있지만, 이와 같은 사이트에서는 여러 도메인에서 상태를 유지하고 액세스해야 하는 기능(예: 싱글 사인온(SSO) 및 동의 관리)을 위해 쿠키를 사용하는 경우가 많습니다.
퍼스트 파티 세트를 사용하면 동일한 항목이 소유하고 운영하는 관련 도메인 이름이 퍼스트 파티와 서드 파티가 다르게 취급되는 상황에서 퍼스트 파티로 취급될 수 있습니다. 퍼스트 파티 집합 내의 도메인 이름은 동일 당사자로 간주되며, 동일 당사자 컨텍스트에서 설정 또는 전송되도록 의도된 쿠키에 라벨을 지정할 수 있습니다. 목표는 유효한 사용 사례를 위반하지 않는 경로를 유지하면서 서드 파티의 크로스 사이트 추적을 방지하는 것 사이의 균형을 찾는 것입니다.
퍼스트 파티 세트 제안서는 현재 테스트 단계에 있습니다. 계속 읽어보고 작동 방식과 사용해 볼 수 있는 방법을 알아보세요.
퍼스트 파티 쿠키와 서드 파티 쿠키의 차이점은 무엇인가요?
쿠키는 본질적으로 퍼스트 파티 또는 서드 파티가 아니며 쿠키가 포함된 현재 컨텍스트에 따라 다릅니다. 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가 포함된 동일 사이트 컨텍스트는 쿠키를 퍼스트 파티로 만듭니다.SameSite=None가 포함된 교차 사이트 컨텍스트는 쿠키를 서드 파티로 만듭니다.
하지만 항상 명확하지는 않습니다. brandx.site가 여행 예약 사이트이고 fly-brandx.site 및 drive-brandx.site도 사용하여 항공편과 렌터카를 분리한다고 가정해 보겠습니다. 방문자는 하나의 여정을 예약하는 동안
이러한 사이트 사이를 오가며 다양한 옵션을 선택합니다.
이러한 사이트 전체에서 선택한 '장바구니'가 그대로 유지되기를 기대합니다. brandx.site는 SameSite=None 쿠키로 사용자의 세션을 관리하여 크로스 사이트 컨텍스트에서 이를 허용합니다. 단점은 이제 쿠키에 교차 사이트 요청 위조 (CSRF) 보호가 없다는 것입니다. evil.site에 brandx.site에 대한 요청이 포함되어 있으면 해당 쿠키가 포함됩니다.
쿠키는 크로스 사이트이지만 이러한 모든 사이트는 동일한 조직에서 소유하고 운영합니다. 방문자는 또한 하나의 조직임을 이해하고 서로 간에 동일한 세션, 즉 공유 ID를 원합니다.
퍼스트 파티 세트 정책
퍼스트 파티 세트는 동일 당사자가 소유하고 운영하는 여러 사이트에서 이 관계를 명시적으로 정의하는 방법을 제안합니다. 이렇게 하면 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는 전체 싱글 사인온(SSO) 솔루션부터 사이트 간 공유 환경설정에 이르기까지 모든 것을 의미합니다.
조직에 다음과 같은 여러 최상위 도메인이 있을 수 있습니다.
- 앱 도메인:
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 (Cookies Having Independent Partitioned State)와 함께 제안되는 경로입니다. 이 경로는 Partitioned 속성을 통한 선택 경로를 사이트에 제공하여 중요한 교차 사이트 삽입, 리소스, API, 서비스를 계속 유지하면서 사이트 간 식별 정보 유출을 방지합니다.
다음은 세트 없이도 사이트가 문제없이 작동할 수도 있음을 의미합니다.
- 다른 사이트가 아닌 다양한 출처에서 호스팅하는 경우 위의 예에서
brandx.site에fly.brandx.site와drive.brandx.site가 있다면 이 둘은 모두 같은 사이트 내의 서로 다른 하위 도메인입니다. 쿠키는SameSite=Lax를 사용할 수 있으며 설정이 필요하지 않습니다. - 다른 사이트에 서드 파티 삽입을 제공한 경우 인트로에서
my-blog.site에 삽입된video.site의 동영상 예는 명확한 서드 파티 분할입니다. 이러한 사이트는 여러 조직에서 운영되며 사용자는 사이트를 별도의 항목으로 간주합니다. 이 두 사이트는 한 세트에 포함되어서는 안 됩니다. - 서드 파티 소셜 로그인 서비스를 제공합니다. OAuth 또는 OpenId Connect 등을 사용하는 ID 공급업체는 더 원활한 사용자 로그인 환경을 위해 서드 파티 쿠키를 사용하는 경우가 많습니다. 유효한 사용 사례이지만 조직에는 분명한 차이가 있으므로 퍼스트 파티 세트에는 적합하지 않습니다. WebID와 같은 초기 제안서에서는 이러한 사용 사례를 지원하는 방법을 모색하고 있습니다.