Google은 제3자 쿠키가 사라지는 것처럼 보이면서, Chrome 브라우저를 사용하여 사용자를 프로파일링하는 FLoC이라는 기술을 발명했습니다.
이 기술은 크게 비판받고 있으며, 웹사이트나 애플리케이션은 Permissions-Policy: interest-cohort=() 헤더를 보내서 이 기술에서 옵트아웃할 수 있습니다.
우리는 2021년 웹에서 광고가 중요한 기둥이라고 생각하지만, 물론 이를 큰 프라이버시 문제로 보는 많은 커뮤니티도 있습니다.
Discourse 설치에서 이 기술에서 옵트아웃하는 가장 빠른 방법은 테마 컴포넌트의 /head에 meta 태그를 추가하는 것입니다: @supermathie가 지적했듯이, 이것이 작동할지 확실하지 않습니다.
<meta http-equiv="Permissions-Policy" content="interest-cohort=()"/>
하지만 이것이 코어에서 체크박스로 제어되는 ‘실제’ HTTP 헤더가 될 수도 있습니다.
고맙습니다. 저도 동의합니다. 이것이 표준 선택지가 되어야 합니다.
여기에서 헤더를 확인할 수 있으며, 현재 이 사이트는 옵트아웃(opt-out)을 보내지 않습니다:
이 방법이 동작하지 않는다고 말하는 사람들만 본 적이 있습니다. 이건 실제 헤더여야 한다고 생각합니다.
웹사이트와 사용자 양쪽 모두에서 옵트아웃(Opt-out)을 선택할 수 있는 방식은 새로운 웹 플랫폼 기능을 도입하는 데 현실적인 방안이 아닙니다.
특히 헤더는 모든 요청에서 전송되어야 하며, 주요 포럼 도메인에 대한 방문과 동등한 효과를 갖는 모든 고유한 CDN URL도 고려해야 합니다.
cdn.forum.example.com은 forum.example.com과 정확히 동일한 예측력을 가집니다.
이 시점에서 이루어지는 어떠한 변경도 본질적으로 무작위적인 동기에서 비롯됩니다. 구글이 메커니즘에 대한 연구 기회도, 정책 변경에 대한 가시성도 거의 없이 웹 전체가 혼란에 빠지도록 강요하는 것은 합리적인 의사결정에 도움이 되지 않습니다.
정말 그 말씀이 맞습니다. 전적으로 동의합니다.
그런데도…
구글이 그렇게 하고 있는데, 우리는 그저 가만히 앉아 아무것도 하지 않아도 되는 걸까요? 우리가 원하든 원하지 않든, 좋든 나쁘든 구글은 이미 그렇게 하고 있습니다.
FLoC에 대한 논의가 워드프레스 프로젝트에서 이루어졌는데(불행히도 "어떻게"의 문제가 "여부"의 문제보다 더 중심이 되는 것 같습니다).
감사합니다. 검색을 해보니 관련 논의는 여기에 있고, 중요한 논거(강조는 제가 했습니다)는 다음과 같습니다.
이걸 하지 않는 게 낫습니다. 이는 여러 가지 레이스 조건을 초래할 뿐만 아니라, HTTP 레벨에서만 비활성화할 수 있는 기능들도 생기기 때문입니다. CSP로 인해 이런 혼란이 생긴 적이 있었는데, 그걸 반복하고 싶지 않습니다. 모든 호스팅 제공업체가 적절한 헤더 구성 옵션을 제공하도록 장려합시다.
FLoC은 정말 나쁘지만, 워드프레스의 제안도 완벽하지 않은 것 같습니다. 헤더를 수정하는 요소가 매우 많기 때문에, 이 모든 것을 어떻게 고려할 수 있을까요?
현재로서는 Chrome 이외의 어떤 브라우저를 사용하는 것이 유일한 신뢰할 수 있는 해결책입니다. 지시문으로 Google에 크롤링이나 추적을 요청하지 말라고 하더라도, Google이 권장하는 방식으로 설정하더라도 항상 존중받지 못하는 경우가 많았습니다.
그러니까 워드프레스의 세상에서는 웹마스터가 헤더 설정을 위해 호스팅 제공업체와 직접 대응해야 합니다. (수정: 오, 아래에서 수정 사항 확인하세요.)
하지만 디스커스의 세상에서는 도커 이미지를 통해 사이트의 웹 존재감, 헤더 포함 모든 것을 설정할 수 있습니다.
위험할 만큼만 아는 수준이지만, 다음과 같은 위치에 헤더 설정이 있는 것을 볼 수 있습니다.
/var/discourse/shared/standalone/letsencrypt/http.header
/var/discourse/templates/web.ssl.template.yml
따라서 웹마스터의 정책에 따라 적절한 헤더를 설정하는 것이 디스커스의 범위 내에 있다고 느낍니다.
일부 디스커스 관리자는 아무 조치도 취하지 않을 수도 있고, 일부는 상황을 지켜보기를 원할 것이며, 다른 일부는 커뮤니티를 대신하여 FLoC 추적에 옵트아웃(Opt-out)하고 구글에게 신호를 보내기를 원할 수 있습니다.
저는 옵트아웃을 원합니다.
Add a custom HTTP header to requests made to your Discourse [1]에 기반한 변경 사항을 테스트 중이며, 이 헤더를 추가하는 작업입니다. 작동하는지 확인되면 알려드리겠습니다.
개인적으로는 누군가가 제안한, FLOC 헤더가 포함된 요청을 단호하게 거부하여 Chrome을 고장 내는 아이디어를 지지합니다. 하지만 그 주장을 옹호했던 기사를 찾을 수가 없네요… 
GNU Terry Pratchett, 그의 이름을 부르자 ↩︎
아니요 - 그 인용문은 Permissions-Policy 헤더에 대한 일반적인 토론에서 나온 것이었습니다. 워드프레스의 세계에는 해당 헤더를 추가하는 플러그인이 있습니다.
고맙습니다 - 제 말이 틀렸네요.
이것으로 충분할 것입니다:
## 빌드 후 실행할 사용자 지정 명령
run:
- exec: echo "Beginning of custom commands"
- replace:
filename: "/etc/nginx/conf.d/discourse.conf"
from: /location \/ {/
to: |
location / {
add_header X-Clacks-Overhead "GNU Terry Pratchett";
add_header Permissions-Policy "interest-cohort=()";
Add a custom HTTP header to requests made to your Discourse 에서 가져옴.
참고: 오늘 날짜에 정말 적절한 주제네요: Terry Pratchett’s debut turns 50: ‘At 17 he showed promise of a brilliant mind’ | Books | The Guardian
결과는 다음과 같습니다:
○ → curl -I https://testmachine/srv/status
HTTP/2 200
server: nginx
date: Tue, 20 Apr 2021 17:48:15 GMT
content-type: text/plain; charset=utf-8
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
x-download-options: noopen
x-permitted-cross-domain-policies: none
referrer-policy: strict-origin-when-cross-origin
x-request-id: ef02ce7c-fabc-49b9-986e-c2c46e50f8e4
x-runtime: 0.004575
x-redis-calls: 1
x-redis-time: 0.000153
x-queue-time: 0.000952
x-clacks-overhead: GNU Terry Pratchett
permissions-policy: interest-cohort=()
lobste.rs 업데이트: 베타 버전이 끝나면 사이트가 계산에 포함되는 것을 거부할 수 있는 옵션이 사라집니다.
인코그니토 모드에서 아닐 때 사용자가 방문하는 공개적으로 라우팅 가능한 IP 주소를 가진 모든 사이트는 POC 코호트 계산에 포함됩니다.
이 “거부” 옵션은 시험 단계가 완료되는 즉시 기능이 중단되며, 현재는 광고를 서빙하는 경우에만 작동합니다.
즉, 이 문제에 대해 시간을 낭비하는 것을 그만두자.
개인이 (아직은) 옵트아웃을 선택할 수 있습니다.
Chrome 90(4월 13일 화요일에 안정 버전으로 출시됨)부터 사용자는 chrome://settings/privacySandbox를 통해 FLoC 및 기타 Privacy Sandbox 제안을 옵트아웃할 수 있습니다. (현재 Canary에서 floc.glitch.me 데모로 직접 체험해 볼 수 있습니다.)
출처: https://discourse.wicg.io/t/proposal-federated-learning-of-cohorts-floc/4473/26
저도 이 내용을 이해하는 데 시간이 좀 걸렸고, 이제야 제대로 이해한 것 같습니다(잘못된 부분이 있다면 지적해 주세요). 혼란의 핵심은 "계산(the calculations)"이라는 표현에 있습니다.
여기에는 두 가지 종류의 계산이 있으며, 사이트가 FLoC에 "참여"하는 방식은 세 가지입니다.
전체(글로벌) 코호트를 결정하는 “글로벌” 알고리즘입니다. 옵트아웃이 불가능합니다. 실제로 비인코그니토(비공개) 모드 이외의 상황에서 사용자가 방문하는 공개 라우터블 IP 주소를 가진 모든 사이트가 POC 코호트 계산에 포함됩니다.
사용자의 브라우징 습관에 기반하여 특정 사용자의 코호트를 결정하는 알고리즘입니다. 헤더를 통한 옵트아웃이 가능합니다. 사이트는 코호트 계산에 사용자의 사이트 목록에 포함되지 않기를 원한다고 선언할 수 있어야 합니다. 이는 새로운 interest-cohort permissions policy를 통해 구현할 수 있습니다. (인용하신 같은 문서에서 발췌)
interest-cohort 권한이 허용되지 않는 모든 프레임은 document.interestCohort()를 호출할 때 기본 값을 반환받습니다..이 부분에 대해 좋은 출처를 찾지 못했습니다.
아, 목록에서 2번과 3번을 혼동하고 있었네요.
그렇다면 헤더에는 가치가 있지만, 다시 한번 말하지만 헤더는 이를 전달하는 데 적합하지 않고 오류가 발생하기 쉬운 방법입니다.