유럽의 개인정보 보호 규정으로 인해, 본인이 호스팅하는 웹사이트에서 제3자 도메인으로 요청을 시작하는 것을 피하는 것이 좋습니다. Discourse의 경우, Onebox 기능이 브라우저가 원본 웹사이트에서 썸네일을 가져오도록 하여 제3자 요청을 발생시키므로 규정 준수를 달성하기가 어렵습니다. 아래 Onebox 처리된 기사를 참고하세요:
개발자 도구를 보면 이미지가 제3자 웹사이트에서 다운로드되는 것을 확인할 수 있습니다. 해당 기사에서도 지적하듯, 요청에 쿠키가 포함되지 않더라도 이는 GDPR 위반 사항입니다.
현재 저는 Discourse 인스턴스에서 Onebox를 비활성화했지만, 프라이버시를 더 엄격하게 존중하고 과태료 부과 위험을 제거하는 방식으로 이 기능을 다시 도입하고 싶습니다.
이미지는 메인 도메인이나 cdn.mydomain.com과 같은 사용자 지정 도메인에서 제공될 수 있습니다.
저작권 문제로 인해 제3자의 이미지를 자체 서버에 저장할 수 없으며, 이미지와 관련하여 이는 실제로 매우 어렵습니다(이로 인해 Discourse의 특정 기능이 다소 의문스럽지만, 이는 별개의 이야기입니다). 하지만 원보이싱(oneboxing)은 GDPR에 위배되지 않으며, 앞으로도 그럴 것입니다. 안전을 위해, 링크를 통해 제3자가 개입된다는 사실을 알려주고 GDPR 준수는 해당 제3자의 책임임을 명확히 하는 것이 현명한 조치입니다. 하지만 이것도 필수적은 아닙니다.
한편, Discourse는 이미 여기 onebox에 사용된 이미지를 조용히 가져왔습니다:
원박싱 자체는 위배되지 않지만, 제3자 리소스를 제공하는 것은 명확히 위배됩니다. 위 구글 폰트(Google Fonts) 사례를 참고하십시오.
대신 디스코urs(Discourse) 서버를 통해 프록시를 거치도록 하면, 제3자는 사용자의 IP가 아닌 디스코urs 서버의 IP만 확인할 수 있게 되지 않을까요?
오, 흥미롭네요! 제 인스턴스에서 활성화할 수 있는 어떤 플러그인이나 설정인가요?
원박스(Oneboxing)는 제3자 서비스를 제공하지 않습니다. 그리고 GDPR은 Google Fonts의 사용을 허용하며, 사용자에게 이를 알려야 합니다 — 또한 Google도 GDPR을 준수하고 있습니다.
하지만 이것은 애초에 GDPR의 문제가 아닙니다. iframe이 문제입니다.
사용자들에게 단순히 "알리는 것"이라기보다는, 동의(Consent)나 정당한 이익(Legitimate Interest)과 같은 법적 근거가 있는지 여부가 더 중요합니다. 동의를 기반으로 한 경우, 사용자가 동의를 거절할 수 있는 편리한 방법을 제공해야 하며, 그렇게 할 경우 해당 리소스가 로드되지 않습니다. 정당한 이익을 근거로 하는 경우, 정당한 이유 평가(Legitimate Reason Assessment)를 수행해야 하는데, 저(그리고 다른 많은 Discourse 호스트 관리자들도 마찬가지일 것입니다)는 이를 수행하기보다는 원복싱(oneboxing) 기능을 완전히 비활성화하거나, 프록시를 통해 사용자의 IP 주소를 숨기는 방식을 선택하는 편이 낫다고 생각합니다.
이것은 정확히 ‘알리기’에 관한 것입니다. 사용자의 개인 데이터를 수집, 사용 및 저장할 때 동의를 받아야 합니다. 그리고 그렇게 하더라도 반드시 무엇을, 왜, 그리고 얼마나 오랫동안 그렇게 하는지 알려야 합니다.
원박스(oneboxing)는 이에 해당하지 않지만, 제3자가 관여된 경우라면 반드시 이를 알려야 합니다. 그리고 원박스는 단순히 화려한 링크일 뿐입니다.
제가 말하고자 하는 바는 다음과 같습니다. 제3자 요청의 존재를 단순히 공개하는 것만으로는 충분하지 않습니다. GDPR에 따르면 다음 사항들을 제공해야 합니다:
동의(Consent)를 사용할 수 없는 이유는, Discourse가 동의를 제공한 사용자에 대해서만 원박스를 통해 외부 이미지를 표시하도록 설정할 수 없기 때문입니다. 그리고 정당한 이익(Legitimate Interest)을 근거로 하더라도, 적절하게 균형 테스트를 수행하려면 변호사를 고용해야 합니다. 소프트웨어가 브라우저가 제3자에게 요청을 보내지 않도록만 하면 이 모든 과정이 훨씬 쉬워질 텐데 말입니다. (사실상 인터넷상의 아무나일 수 있기 때문에, 제3자를 개인정보처리방침에 나열하거나 해당 제3자의 개인정보처리방침을 참조하도록 안내하는 것조차 불가능합니다.)
GDPR의 관점에서 보면, 원박스는 사용자가 직접 행동하지 않아도 브라우저가 방문하기 때문에 단순히 링크가 아닙니다.
(참고로, 저는 직업적으로 GDPR 준수 업무를 담당하고 있으며, EU에서 불만 접수와 과징금이 어떻게 작동하는지에 대한 실무 경험을 가지고 있습니다. 이 내용은 근거 없이 말한 것이 아닙니다.)
법률적 논의를 떠나서, 제3자에게 자신의 IP 주소와 서핑 습관을 노출하지 않기 위해 의도적으로 제3자 리소스를 차단하는 사용자들도 있습니다. 이러한 사용자에게도 원박스가 작동한다면 좋겠습니다. 
법률적 고려 사항은 제쳐두고, 이 분야에서 무언가를 하는 것이 유용할 것 같다고 생각합니다.
다만, 저는 외부 미디어를 표시하기 위해 사용자에게 명시적인 옵트인(opt-in)을 요청하는 것이 더 나은 해결책이라고 생각합니다. 제가 방문하는 독일 웹사이트 중 상당수가 이 방식을 채택하고 있습니다(아래 예시 참조).
이와 별도로, Discourse 호스트에서 직접 정적 이미지 미리보기를 제공하는 것도 좋겠지만, 실제 옵트인 기능이 더 중요한 단계라고 생각합니다.
예시 (Golem.de, 독일 IT 뉴스 웹사이트):
기사: Minecraft-Version des Minecraft-Filmtrailers erobert Herzen
외부 미디어 옵트인 없이:
외부 미디어 옵트인 사용 시:
이 부분에 대해 궁금합니다. Google 폰트 문제는 각 사용자마다 실제로 Google 서버에서 폰트를 가져와야 하므로 이해할 수 있습니다.
하지만 제 경험상 "Onebox"의 링크 미리보기는 HTML을 다시 빌드하지 않는 한 정적(static)으로 유지됩니다. 즉, 제 경험상 원박스는 소스 페이지의 정보가 변경되어도 동일한 미리보기 정보를 유지합니다.
이는 사이트의 페이지 정보가 크게 변경되었을 때 유용했습니다. 렌치 아이콘으로 게시물을 다시 빌드하지 않아도 제 원박스 정보 미리보기는 변경되지 않았습니다.
원래 링크된 사이트가 더 이상 해당 링크된 콘텐츠를 가지고 있지 않음에도 불구하고, 오래된 원박스들이 그대로 유지되는 경우도 있었습니다.
반면 iframe은 @Jagster가 언급한 대로, Google 폰트를 가져오는 것과 유사하게 사용자가 볼 때마다 실시간 미리보기처럼 업데이트된다고 생각합니다.
적어도 제 이해로는 그렇습니다. 그렇다면 임베드(embeds)도 비활성화해야 하지 않을까요?
아래와 같은 기능을 추가하는 플러그인이 만들어질 수 있을 것 같습니다.
캐나다에 있는 제 독일 친구가 EU를 차단하는 것이 가장 좋다고 말하는 이유를 이해할 수 있습니다.
위에서 @Firepup650이 말했듯이, 이는 전혀 사실이 아닙니다. Discourse는 Onebox된 이미지를 자동으로 다운로드하여 제공하며, 이는 기본 설정이기도 합니다.
block hotlinked media(핫링크된 미디어 차단) 옵션을 켜면 이를 더 엄격하게 관리할 수도 있습니다.
이를 위해 동의가 필요하지 않습니다.
GDPR은 그렇게 보지 않습니다. 그리고 사용자가 해당 사이트를 방문하려면 조치를 취해야 합니다.
이 문제는 GDPR을 준수하지 않은 Google 측의 문제였습니다. 이것이 EU에서 Google이 상당한 금액의 벌금을 부과받은 이유 중 하나였습니다. 하지만 Google 폰트, AdSense 등을 사용한 사이트들의 문제는 결코 아니었습니다. 그래서 소송의 당사자는 Google이었지, 해당 서비스를 제공한 사이트들이 아니었습니다.
그런 좌절감을 이해합니다. EU가 하는 많은 일들은 의도가 좋지만, 반드시 잘 실행되는 것은 아니며, 개발자들에게 종종 복잡성을 더합니다.
이 특정 경우에는 사람들이 구현한 방식을 좋아합니다. 왜냐하면 그것은 사용자에게 단순하지만 의미 있는 선택지를 제공하기 때문입니다.
이것이 플러그인으로 구현될 수 있다면 더 좋겠습니다. 모든 원박스(oneboxes)에 걸쳐 실행되므로 코어에서 구현해야 한다고 생각했습니다.
이유든, 상상된 이유가든, 이제 이 주제는 약간 벗어난 것 같습니다. 하지만 해당 규제들은 미국에서는 고통스러운 문제들이죠. 그리고 이러한 규제는 미국의 거대 기업들이 사용자의 사생활을 전혀 존중하지 않았기 때문에 필요하게 된 것입니다. 미국에는 관련 규제가 없었으니까요. 아니면 이제 이렇게 말해야 하나요… 개발자들의 삶이 그렇게 복잡하지 않다고요 
그러니 EU에 감사를 표하지 마세요. 구글, 아마존, 마이크로소프트, X, 애플 등에 감사 카드를 보내세요. 그리고 동시에, 이 기업들에게 공통적으로 있는 것이 무엇인지도 생각해 보세요.
참고로, 제 포럼에 13세 미만의 사용자가 들어오지 못하게 해야 한다는 메시지를 받았습니다. 캘리포니아에서 온 사람이라도 핀란드어를 읽을 수 있다면, 저는 분명히 그들을 받아들일 것입니다 
이상입니다 (왜 마이크 드롭 이모지가 없지…)
규제의 필요성에 대해 이의를 제기하는 것은 아닙니다. 제가 말하고 싶은 것은, "저희와 저희의 999개 신뢰할 수 있는 파트너사가 당신의 데이터를 탈취합니다"라는 상황에서, "여기를 클릭하여 저희와 저희의 999개 신뢰할 수 있는 파트너사가 당신의 데이터를 탈취하는 것에 동의합니다"라고 쓰인 대형 팝업으로 넘어가는 과정이 때로는 피로적인 승리로 느껴질 수 있다는 것입니다. 많은 사람들이 고개를 갸웃하게 되는 이유를 이해할 수 있습니다. 
다시 본론으로 돌아가서:
@kuba-or 님, 이 방식이 당신에게 적합하다면 기능 요청 사항을 "외부 미디어 표시 전에 사용자 동의 필수 옵션 제공"으로 수정하는 것을 제안합니다. (그렇게 되면 제가 투표에 참여하겠습니다.)
현재 제목이 당신의 요청에 더 잘 맞다고 느낀다면 그것도 괜찮습니다. 그 경우, 제가 별도로 다른 요청을 열겠습니다.
솔직히 말하면, 정말 터무니없는 극단으로 가고 있습니다. 기억이 정확하다면(혹은 왜곡되지 않았다면), 최종 사용자가 하드웨어를 분해하고 수리를 시도하는 과정에서 손상을 입힌 경우에도 회사가 보증 책임을 져야 한다는 내용을 읽은 적이 있습니다.
더 큰 문제는 사람들이 단순한 무지( stupidity)로부터 보호받기 위해 규제가 극단적인 수준까지 치닫고 있다는 점입니다.
제 이해로는 플러그인이 실제로 이를 수행할 수 있을 것 같습니다. 테마 컴포넌트가 클라이언트/브라우저 측에서 요소를 수정하는 반면, 플러그인은 서버 측에서 코어의 요소를 수정하기 때문입니다. Tampermonkey 스크립트는 일종의 브라우저 측에 설치된 테마/컴포넌트와 유사합니다. 저는 예전에 'Fallen Sword’라는 오래된 브라우저 게임에서 시장 내 아이템 정렬 방식을 수정하기 위해 Tampermonkey 스크립트를 사용했던 적이 있습니다.
흥미로운 부연 설명으로, 이 토픽에 대한 알림을 받지 못했습니다.
이미 다음 기능들이 존재하는 상황에서, 이 기능 요청이 무엇을 의미하는지 잘 이해가 되지 않습니다.
block hotlinked media
그리고
download_remote_images_to_local
따라서 해당 동작을 원하신다면 … true와 false로 설정하시면 됩니다.
혹시 이 기능 요청은 Discourse 제품에 일급(first-class) HTTP 프록시를 구축해 달라는 것인가요?
이 두 설정은 몰랐네요! 지금은 이 정도면 충분히 잘 작동하는 것 같습니다. 더 테스트해봐야겠어요. 감사합니다!
이것이 작동하지 않는 것 같습니다. 원박스(Onebox)의 파비콘과 미리보기 이미지가 여전히 원격 서버에서 가져와지므로, 해당 서버가 어떤 사용자가 스레드를 열었는지 추적할 수 있습니다. GDPR에 따르면, 포럼 운영자는 플랫폼에 링크된 각 개별 페이지를 사용자에게 공개해야 합니다.
또한, 원박스를 비활성화하는 설정(한도를 0으로 설정)이 전체 보드에 걸쳐 작동하지 않는 것 같으므로, 이 설정을 사후적으로 적용할 수 있는 방법이 있는지 확실하지 않습니다.
