RFC 35140: HTTP Do-Not-Stab (2023) 정책

 (5snb.club)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 웹사이트가 사용자를 찌를 수 있다는 풍자적 설정을 통해, Do-Not-Stab는 사용자가 찔리고 싶지 않다는 선호를 HTTP 헤더로 전달하게 함
  • 헤더 문법은 Do-Not-Stab: 1 하나뿐이며, 헤더가 없으면 사용자가 찔리기를 원한다는 선호로 처리됨
  • 사용자 에이전트가 이 값을 기본으로 켜면 안 되며, 기본값으로 설정된 신호는 웹 서비스가 무시하고 사용자를 찔러도 된다는 규칙을 둠
  • Microsoft는 EEA 안에서만 Do-Not-Stab 지원을 약속했고, EEA 밖에서는 헤더를 설정해도 찔릴 수 있음
  • 상업적 이익, 정부 요청, 동의 처리, 주주 요구 같은 예외가 안전 우려보다 우선할 수 있다는 점을 통해 기업의 선택권 존중 방식을 비판함

Do-Not-Stab 헤더의 규칙

  • Do-Not-Stab는 사용자가 웹사이트에 자신이 찔리는 것에 대한 선호를 알릴 수 있게 하는 HTTP 헤더임
  • 풍자적 배경에서는 지난 50년간 주변기기 발전으로 웹사이트가 사용자를 찌를 수 있게 됐고, Stabbings as a Service 산업까지 생겨남
  • 악의적 행위자는 사용자 선호를 무시할 수 있지만, 대부분의 찌르기는 악의적 행위자가 아니라 합법적 기업이 수행한다고 봄
  • 이 표준은 사용자가 모든 찌르기를 쉽게 거부할 방법을 제공하지만, 법이 요구하는 찌르기와 회사가 어쨌든 하고 싶은 찌르기는 예외로 남겨둠
  • 문법은 하나뿐임
    • Do-Not-Stab: 1
    • 헤더가 없으면 사용자가 찔리기를 원한다는 선호로 처리함
  • 사용자 에이전트는 이 헤더를 기본 선호로 채택하면 안 됨
    • 그렇게 설정된 경우 웹 서비스는 선호를 무시하고 사용자를 찌르는 것이 권장됨
    • 사용자가 찔리고 싶은지 여부는 사용자 에이전트가 정할 수 없고, 사용자의 명시적 선택이어야 한다는 이유임

적용 범위와 예외

  • Microsoft는 EEA, 즉 European Economic Area 안에서 Do-Not-Stab 헤더를 지원하겠다고 약속함
  • EEA 밖에서는 지원이 아직 진행 중이어서, 헤더를 설정해도 사용자가 찔릴 수 있음
  • 어떤 국가가 EEA를 떠나면 그 국가의 사용자는 찔릴 수 있음
  • Do-Not-Stab 예외는 상업적 이익이 안전 우려보다 클 때 인정됨
    • 사용자가 찔리는 데 동의한 경우가 포함되며, 사용자가 동의 사실을 몰라도 마찬가지임
    • 정부가 요청한 찌르기는 웹사이트가 합법성을 다투지 않는 것이 권장되며, 사용자가 그럴 만했을 것이라고 적음
    • 사용자가 죽지 않을 가능성이 있는 찌르기
    • 주주가 원한 경우
  • 편집자 코멘트는 기업들이 해서는 안 된다는 것을 알면서도 명시적으로 하지 말라고 해야만 멈추는 상황을 비판함
    • Microsoft가 EEA에서만 사용자 선택을 존중하는 이유를 그곳에서만 의무가 있기 때문이라고 봄
    • IE에서 Do-Not-Track을 기본값으로 설정해 모두가 IE의 신호를 무시하게 만든 일도 함께 비판함
    • Windows의 EEA 내 Digital Markets Act 준수 변경 미리보기 링크를 함께 둠
    • “We and our 756 partners process personal data” 문구를 들어, 756개 파트너와 함께 개인정보를 처리하는 광고 기술 관행을 강하게 비판함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 풍자는 훌륭하지만, 개인 자율성 보호의 부담이 기관과 규제기관에서 개인 사용자에게 넘어간 더 큰 사회적 변화를 그대로 비춘다는 점이 핵심임
    Do-Not-Stab이든 Do-Not-Track이든, 재정 압박 앞에서 어떤 형태의 자발적 준수도 출발점부터 성립하기 어렵다 봄
    이제는 다시 이런 문제에 전투적으로 대응하는 태도를 정상화하고, 자기 컴퓨터를 원하는 방식으로 쓸 자유를 공격적·대립적으로 지켜야 함

    • HN에서 Firefox 얘기만 나오면 보통 완벽한 해결책 오류가 쏟아지는데, 이런 메시지가 크게 추천받는 건 흥미로움
      소프트웨어 업계가 Chrome이 광고 소프트웨어라는 걸 알면서도 자기와 친척 컴퓨터에 깔아주며 레드카펫을 깔아줬고, 대안으로 바꾸는 비용이 극히 낮은데도 안 바꾼 걸 보면 사람들이 여기에 전투적으로 나설지는 회의적임
    • 맞음. 밀레니얼 세대로서 시민 불복종이 있던 시절이 더 나았다고 느낌
      소비자에게 더 나은 인터넷을 얻었을 뿐 아니라, 더 나은 회사들이 보상받고 이기기도 했음. 추억 보정일 수도 있지만, 불복종이 필요한 또 다른 이유는 상대편도 돈 때문에 그렇게 하기 때문임
      구체적으로 쿠키에 대해 Adblock 같은 걸 할 수 있을까? 차단보다 오염된 데이터가 더 효과적일 것 같음. 데이터를 달라고 한다면 데이터를 주면 됨. 동의 없이 요구한다면 오염된 데이터는 그저 악의적 준수일 뿐임
      DNT의 확장으로 “DNT 헤더 이후 동의를 요구하면 사용자 에이전트는 임의의 합성 데이터를 생성할 수 있다”처럼 표준화할 수도 있음
    • 아주 엄밀히 말하면, 그 변화를 비추기 때문에 훌륭한 풍자임. 원조인 A Modest Proposal의 영향을 많이 받았음
    • 컴퓨터를 원하는 방식으로 쓸 자유를 공격적이고 대립적으로 지키려 해도, 슬프게도 늘 소모전이 됨
      기업들은 사용자의 저항 비용을 시간과 짜증 측면에서 올리기만 하면 장기적으로 이길 수 있다는 걸 아는 듯함. 브라우저에서 App Store, 온갖 SaaS로 이어지는 플랫폼의 역사와 방향은 비극적이고, 단계마다 사용자 통제권은 계속 줄어들었음
      이제 큰 질문은 인공지능이 기업 중심이 될지 민주화될지, 또 어느 정도까지 그럴지인데 낙관하기 어렵다 봄
      아니면 60년 더 Do-Not-Stab을 클릭하는 게 싫다면 양치기 같은 게 될 수도 있음. 10년쯤은 잘 먹히겠지만, 결국 자동차·식기세척기·전등 스위치를 쓰려면 Do-Not-Stab을 클릭해야 하는 시점이 오고, 그때 기업이 이김
      결국 “찌르기 전에 물어봐 준 것만으로도 감사해야지, 사실 내가 빚진 셈이지”라고 말하게 되고, 유명 양치기 인플루언서가 된 뒤 쏟아질 사랑과 돈을 기대하게 됨. 좋아요와 구독 부탁, 언제나처럼 기업 만세
    • 그걸 시작하기 가장 좋았던 때는 19일 전이었지만, 이제 여기까지 왔음. 안전벨트 매야 함

  • Do-Not-Stab 헤더는 한 브라우저 엔진이 기본값으로 켰고, 사용자가 찔림에 명시적으로 동의해야 하는 구조가 찌르기 산업의 수익을 해쳤기 때문에 폐기됐다는 점이 중요함
    다행히 누군가 비표준 대안인 General Assault Control을 만들었고, 이 역시 값이 하나뿐이라 Sec-GAC를 1로 설정해 웹사이트에 공격하지 말아 달라고 요청할 수 있음
    설계상 이 헤더는 확장할 수 없어서, 앞으로 잔혹한 칼부림과 얼굴에 파이를 던지는 코미디를 구분하는 데는 쓸 수 없음
    법적 요건 때문에 General Assault Control 헤더는 기본으로 켤 수 없음. Colorado 같은 미국 주에서는 명시적 동의가 아니라 명시적 거부를 요구하기 때문임
    이는 대부분 사용자가 찔리기를 원하지 않을 테니, Colorado의 번성하는 찌르기·총격 산업을 보호해 줌
    이 기능은 기본으로 꺼져야 하지만, 명세를 만든 조직은 고객들에게 이 기능을 구현한 변두리 브라우저를 내려받으라고 강하게 밀고 있음. 다만 켜려면 about:config가 필요할 수도 있음
    사용자 기반이 작기 때문에, 표준을 따르지 않는 웹사이트는 공격하지 말라는 요청 자체를 이용해 찌르기와 총격을 더 정밀하게 만들 수 있음
    최종 사용자는 웹 서버에 GAC 헤더 지원 여부를 담은 JSON 파일을 요청할 수 있지만, 비준수 서버는 이 URL 요청을 이용해 사용자의 이를 걷어찰 수도 있음

    • 이제 유럽 규정을 준수하기 위해, 웹사이트 사용 전에 사용자가 거부할 수 있는 개인 대상 폭력 범죄 목록을 보여주는 것이 관례가 됐음
      이렇게 하면 찌르기에 동의하지 않는 것이 항상 능동적 선택이 되고, 찔리거나 불구가 되기를 원하는 사용자가 그 기회를 실수로 놓치지 않게 됨
    • 왜 이진값이어야 함? 마조히스트나 내기에서 져서 조금만 찔리고 싶은 사람, 혹은 목 졸리고 싶은 사람은 어떻게 함?

  • 이건 너무 노골적인 EU 관료제 편들기임. 찌르기에 비우호적인 사업 환경 때문에 유럽에 대형 SaaS 회사가 없는 것도 당연함

    • 맞음, EU는 왜 stabtech 산업이 평화롭게 찌르게 그냥 두지 못하는 걸까
    • 사실관계는 틀렸다고 봄. Skype, Spotify, Revolut, Zendesk, Transferwise 같은 회사가 있고, SaaS로 운영되는 유럽 유니콘도 꽤 많음
      미국과 중국 회사보다는 적지만, 일부는 인수됐거나 다른 나라로 기반을 옮겼음

  • 클릭 1,000회당 20달러라는 저렴한 가격으로, 곧 나올 EU와 California의 웹 기반 찌르기 규정을 완전히 준수하는 찌르기 동의 배너를 제공하겠음

    • 구매하겠음. “필수”, “타기팅”, “성능”, “기능성” 찌르기의 구분은 정말 지뢰밭임
      게다가 내가 함께 일하는 846개 찌르기 브로커를 어떻게 제대로 공개해야 할지도 막막함. 이렇게 관료주의가 가로막는데, 사람이 찌르기로 어떻게 먹고살라는 건가
    • 참고로 연구에 따르면 경쟁사 배너에서는 사용자가 찌르기에 95%만 동의하지만, 우리 배너는 제대로 거부하는 데 시간이 50% 더 걸려서 98% 동의율을 보임. 그러니 우리 걸 쓰는 게 맞음

  • 이 웹사이트는 MtF 트랜스젠더, 퍼리, 스스로 로봇이라고 밝히는 사람들, 그리고 그 조합으로 이뤄진 웹링의 일부처럼 보임. 일부는 3인칭 대명사만 사용하기도 함
    모두 어떤 형태로든 시스템 관리자나 프로그래머인 듯함
    내 부족은 아니지만, 이 웹링 안에서 옛 인터넷의 아름다운 반영을 보게 되어 무척 반가움

  • Do Not Track 헤더는 2009년 연구자 Christopher Soghoian과 Sid Stamm이 처음 제안했고, Mozilla Firefox가 이 기능을 구현한 첫 브라우저였음
    https://en.wikipedia.org/wiki/Do_Not_Track#:~:text=The%20Do%...

    • 실제로 얼마나 많은 웹 개발자가 Do Not Track을 존중하는지 궁금함
      내가 만든 모든 사이트, 고용주를 위해 만든 사이트에서도 지키고 있음. 다만 고용주가 모르는 덕분에 가능한 것 같음
      Do-Not-Track을 켠 상태로 탐색하면 쿠키 동의 배너도 건너뛰고, 세션·로그인 쿠키처럼 엄격히 필요한 것 외에는 원하지 않는다고 간주하게 만들었음
      Google Analytics도 넣지 않고, 개인식별정보 없이 페이지의 단일 조회수 카운터만 올림
    • 2002년에 W3C가 권고한 P3P라는 훨씬 더 정교한 표준이 있었음. 기업이 개인 데이터를 어떻게 사용할 수 있는지 설명하는 형식을 정의한 것으로 보임
      하지만 너무 복잡하고 “집행력이 부족하다”고 여겨졌던 듯함
      GDPR까지 살아남았다면 집행력을 갖게 됐을지도 모르지만, Mozilla가 그전에 지원을 제거했음

  • “모든 회사가 사용자를 정말 싫어하기 때문”이라는 말은 정확하진 않음
    실제로 사용자를 싫어한다기보다, 사용자의 돈을 사랑하고 사용자 자체에는 타락한 무관심을 보이는 것에 가까움

    • 사용자를 싫어하진 않지만, 잡아먹으려 하고 있음: https://www.lesswrong.com/posts/ENBzEkoyvdakz4w5d/out-to-get...
    • 아니, 그들은 사용자에 대해 벌 수 있는 돈을 사랑함. 내가 아는 사람 중 이들에게 직접 돈을 주는 사람은 없음
      데이터를 수집한 수상한 회사들이, 사용자에 대한 데이터를 다른 수상한 회사들에게 파는 구조임. 그리고 이 모든 것이 사용자에게는 무료로 제공됨
    • 이 스케치의 후반부가 떠오름: https://www.youtube.com/watch?v=uQjUh4nWwaM
    • 자본주의가 사람에게 해롭다는 걸 이제 막 발견한 것처럼 보임. 누가 알았겠나

  • 진정들 하자. 조직들에게는 다른 선택지가 충분함. Do-Not-Shoot, Do-Not-Rape, Do-Not-Stone 지원은 여전히 없을 테니 온 가족이 즐길 수 있음

    • robots.txt도 잊지 말아야 함

  • RFC가 request for comment라면, 항상 궁금했던 게 있음. 댓글은 어떻게 남기고, 누가 남기는 걸까?

    • 대학 네트워킹 수업에서 들은 일화로는, RFC라는 이름은 약간 농담처럼 붙은 것이고 제안이 RFC 단계에 이르면 댓글은 별로 환영받지 않는다는 뜻이었다고 함
      의견은 그 훨씬 전에 내야 한다는 이야기였음
      이 일화가 사실인지는 모르지만, RFC가 보통 해당 표준에 대한 최종 판단처럼 작동하는 건 맞음
      실제로 RFC는 ID를 받으면 수정하거나 철회할 수 없고, 다른 RFC로 대체될 수만 있음
    • 초기 RFC는 실제로 아이디어와 제안에 대한 의견 요청이었고, 목표는 표준이나 모범 관행의 보관 기록을 만드는 게 아니라 대화를 시작하는 것이었음
      시간이 지나며 출판 절차가 더 공식화되고 자료를 소비하는 공동체가 커지면서 목표가 바뀌었음
      오늘날에는 모범 관행 안내, 실험적 프로토콜, 정보성 자료, 그리고 물론 인터넷 표준까지 포함해 8,500개가 넘는 RFC가 출판됐음
      https://www.rfc-editor.org/rfc/rfc8700.html
      요즘은 “인터넷 표준” 단계에 도달하기 전에 의견을 내야 함
    • RFC는 IETF 아래에서 운영됨. RFC는 특정 그룹에서 개발되고, 그 그룹에 참여할 수 있으며 업무는 보통 이메일로 진행됨
      내가 참여하던 시절에는 대면 회의도 있었지만 참석이 필수는 아니었음
    • 다른 해석으로는 “request for compliance”, 즉 준수 요청도 있음
    • 정오표를 제출할 수 있음. 이름을 RFE로 바꿔야 할지도 모름

  • 이 헤더도 결국 어차피 찌를 회사들이 사용하는 엔트로피 조각이 하나 더 되는 것 아닌가?

    • 법적 뒷받침이 없다면 맞음. 그게 있었다면 이야기는 완전히 달랐을 것임
    • 헤더 오용을 불법으로 만들면, 불법인 자들만 사용자를 찌르게 됨
답변달기