GDPR 및 귀하의 웹사이트 - 개인정보 보호 및 마음의 평화를 위한 가이드

어느 날, 당신은 평온한 블로거입니다. 그 다음에는 갑자기 GDPR이라는 거대하고 어렴풋한 일을 다루고 있습니다. EU는 개인 정보 보호에 중점을 둔 새로운 규정인 GDPR을 도입했으며 개인 데이터를 처리하는 웹 사이트에 대한 중요한 개인 정보 보호, 보안 및 데이터 투명성 요구 사항을 규정합니다. 이것이 나에게 영향을 미치나요? 그리고 당신은 걱정합니다. 오늘 이 기사는 누가, 무엇을, 언제, 어떻게 이해하는 데 도움이 될 것이며 다시 한 번 근심 없는 블로거가 되어 즐겁게 규정을 준수할 수 있는 지식과 도구를 제공할 것입니다.

이제 스스로에게 물어볼 수 있는 한 가지 추가 질문은 다음과 같습니다. 왜 규정이 발효된 후에만 이것을 게시합니까? 대답은 믿거 나 말거나 대부분의 도구와 서비스가 GDPR 준수 업데이트를 지난주에만 발표했기 때문에 마침내 이 가이드를 구성할 수 있었습니다. 무엇이 주는지 봅시다.

목차

고지 사항

몇 가지 중요한 설명부터 시작하겠습니다.

저는 변호사가 아니므로 이 기사를 어떤 식으로든 법적 조언으로 해석해서는 안 됩니다.

내가 틀렸거나 착각하고 있을 수 있으니 아래 정보를 맹목적으로 신뢰하지 마세요.

이 문서는 주로 회사가 아닌 웹사이트와 블로그를 운영하는 개인을 대상으로 합니다.

60초의 GDPR

GDPR에 대해 아직 듣지 않았거나 읽지 않았다면 여기에 가장 간단한 버전이 있습니다. 일반 데이터 보호 규정(GDPR)은 데이터 보호 및 개인정보 보호에 관한 새로운 EU 규정입니다. 2018년 5월 25일에 발효되었습니다. EU/EEA 시민 및 거주자의 개인 데이터 취급에 대한 추가적인 투명성과 선택권을 제공하도록 설계되었습니다. 이 규정은 기업이 개인 데이터를 처리, 저장 및 사용하는 방법에 대한 추가적인 보호 장치 및 설명을 도입하도록 요구합니다. 개인에 대한 강조. 개인적이지 않음 =문제가 되지 않습니다.

GDPR은 개인 데이터를 취급, ​​저장 또는 사용하는 모든 사람에게 적용됩니다. 따라서 규정이 귀하(요리, 여행 또는 IT 수리에 관한 소규모 블로그를 운영하는 귀하)에게 적용되는지 묻는다면 대답은 다음 질문에 있습니다. EU/EEA 시민 및 거주자?

개인 데이터를 처리하는 경우 어떻게 됩니까?

예 또는 아니오라고 말하기 전에 잠시 예라고 가정해 봅시다.

GDPR은 데이터 처리를 막지 않습니다. 투명성과 추가 보호가 필요합니다. 즉, 개인 데이터를 사용하는 이유를 정당화하고, 그 이유와 방법을 설명하고, 데이터를 보호하기 위한 메커니즘을 마련할 수 있어야 합니다. 이러한 요구 사항은 다음과 같이 광범위하게 정의할 수 있습니다.

1. 알아야 할 사항 - 데이터를 처리하는 경우 이유가 있어야 합니다.
2. 프라이버시 - 데이터를 취급하는 경우 덜 개인적인 것으로 만드십시오.
3. 보안 - 데이터를 처리하는 경우 보안이 유지되어야 합니다.

온라인에서 많은 사람들이 데이터 처리에 대해 화를 내는 것을 보았습니다. 그들은 즉시 데이터 처리가 잘못되었으며 피해야 한다고 가정합니다. 올바른 접근 방식은 과도하고 불필요한 데이터 처리를 피하는 것입니다.

데이터를 처리하는 경우 투명하게 처리해야 합니다(알아야 함). 그런 다음 보호하십시오. 이 기사에서는 익명화(개인 정보를 비개인적으로 만들기) 및 암호화(개인 데이터를 덜 보이게/접근하기 어렵게 만들기)와 같은 개념을 사용할 것입니다.

벌금에 관한 것도 아닙니다

이것은 규제의 또 다른 뜨거운 요소입니다. 무거운 벌금. 숫자가 무섭습니다. 그러나 그들에게 초점을 맞추는 것은 잘못된 접근 방식입니다. 당신은 법과 관련된 처벌을 확인하고 당신이 옳은 일을 해야 하는지 그른 일을 해야 하는지를 결정하지 않습니다. 징역형이 길다는 이유만으로 절도를 자제할 수는 없습니다. 잘못했으니까 하지마. 여기도 마찬가지입니다. 벌금이 부과되므로 GDPR을 준수해서는 안 됩니다. 보다 우수하고 투명한 온라인 인지도를 창출할 수 있는 기회로 여기십시오.

그 과정은 고통스럽고 비용이 많이 들 수 있으므로 모든 것이 우리의 원래 질문인 개인 데이터로 돌아갑니다. 처리하고 있습니까?

데이터 흐름 따르기

위의 질문에 답하려면 몇 가지 수준의 설명이 필요합니다.

1. 개인 데이터로 분류되는 것은 무엇입니까?
2. 웹사이트에 개인 데이터를 수집하는 메커니즘이 있습니까?

첫 번째 하위 질문에 대한 답변도 사소하지 않습니다. 개인 데이터는 개인을 식별할 수 있는 모든 것입니다. 대부분의 법률 용어와 마찬가지로 정의가 모호합니다. 최선의 대답은 확실하지 않거나 의심이 가는 경우 특정 "모호한" 정보가 실제로 개인 데이터로 사용될 수 있다고 가정하는 것이 가장 좋습니다.

좋은 예는 컴퓨터의 IP 주소입니다. 기술적으로 이것은 전화번호와 같습니다. 컴퓨터가 서로 통신할 수 있게 해주는 번호(주소)이며 장치를 고유하게 식별합니다. 그렇습니다. 전화번호를 계약서나 청구서 등에서 추적할 수 있는 것과 같은 방식으로 특정 상황에서 사람을 식별하는 데 사용될 수 있습니다.

또한 분리할 수 없는 인터넷 통신의 일부입니다. 그리고 이것은 기술과 법 사이의 전투가 시작되는 곳입니다. 개인 정보 보호 규정이 모호한(또는 모호해야 하는) 이유이기도 합니다. 이것은 특히 기술에 정통하지 않은 사람들 사이에서 두통과 걱정거리를 만듭니다. 어느 날 누군가가 음식 레시피를 공유하고 싶었습니다. 그 다음에는 IP 주소에 대해 생각해야 합니다.

이것은 두 번째 하위 질문으로 이어집니다. 일부(대부분) 블로거는 자체 ​​인프라를 설정하지 않고 다른 사람이 만든 플랫폼(블로깅 플랫폼, 계약자가 구축한 웹 사이트 등)을 사용합니다. 그들은 백그라운드에서 무슨 일이 일어나고 있는지조차 모를 수 있습니다.

그리고 이것이 우리가 데이터 추적을 따라야 하는 이유입니다.

GDPR이 귀하의 사이트/블로그에 적용되는지 여부와 적용되는 경우 규정을 준수하는지 확인하기 위해 해야 할 일이 궁금하다면 호기심 많은 사용자에서 귀하의 사이트로 이동하는 인터넷 트래픽의 여정을 따라가 봅시다.

웹사이트 연결

기술적인 세부 사항에 들어가지 않고 dedoimedo.com과 같은 웹 사이트에 방문하면 브라우저에서 인터넷 주소록(DNS라고 함)을 사용하여 광범위한 인터넷에서 dedoimedo.com을 찾을 수 있는 위치를 파악하고 그런 다음 이 주소로 연락하십시오. 모든 것이 제대로 구성되면 웹 서버라는 소프트웨어가 이 연락 요청을 수락하고 지금 읽고 있는 것과 같은 웹 페이지 형식으로 정보를 반환합니다.

웹 서버에 대한 연결을 시작하면 브라우저는 IP 주소, 운영 체제, 브라우저 버전 및 일부 추가 데이터를 포함하여 필요한 정보를 보냅니다. 각 브라우저에는 웹 서버가 최상의 콘텐츠를 제공하는 데 도움이 되는 자체 서명(사용자 에이전트)이 있습니다.

웹 서버는 데이터 로그에 연결을 기록합니다. 1) 해킹, 사기에 대한 추적이 필요하기 때문에 2) 기술적인 문제 3) 웹 트래픽 밸런싱 4) 규정 준수 및 감사를 위한 보안상의 이유입니다.

우리는 IP 주소를 언급했습니다. 따라서 우리는 이미 서버에 기록되는 개인 정보가 하나 있다는 것을 알고 있으므로 GDPR이 적용됩니다. 하지만 기다려. 이것이 실제로 적용되는지 완전히 이해해야 합니다. 따라서 다음과 같은 질문이 있습니다.

• 웹 서버 로그에 액세스할 수 있습니까?
• 그렇다면 웹 서버 로그의 생성, 보관 등을 제어할 수 있습니까?

이러한 질문을 하는 이유는 사람들이 사용할 수 있는 웹 서비스에는 크게 두 가지 유형이 있기 때문입니다. 그들은 자신의 서버를 가질 수도 있고 다른 사람의 서버를 사용할 수도 있습니다. 후자는 호스팅으로 알려져 있으며 웹 서버를 설정하고 유지 관리하기 위해 호스팅 공급자에게 비용을 지불할 수 있습니다. 매우 자주 이들은 공유 서비스입니다. GoDaddy, Digital Ocean, Media Temple 등으로 호스팅할 수 있습니다.

자신의 웹 사이트가 있는 경우 상황이 더 복잡해집니다. 그러나 웹 서버를 설정하는 것이 결코 쉬운 일이 아니기 때문에 기술에 정통한 사람이라는 의미이기도 합니다.

자신의 블로그를 설정할 수 있는 인프라를 제공하기 위해 호스팅 회사에 비용을 지불하는 경우 GDPR에 대한 전적인 책임은 귀하에게만 있는 것이 아닙니다. 호스팅 제공업체도 인프라를 제어할 책임이 있습니다.

서버 로그에 대한 액세스 권한이 없는 경우 문제가 되지 않습니다. 액세스 권한이 있는 경우(일부 호스팅 제공업체는 사용자에게 제한된 액세스를 허용함) 제어 권한이 있습니까? 아마도 이러한 로그에서 데이터를 제거하거나 기록되는 내용과 방법을 변경할 수 없을 것입니다. 다시 말하지만 이것은 주로 보안상의 이유이며 괜찮습니다.

그런데 웹 서버 로그를 사용하고 있습니까?

서버 로그를 만들 수 없거나 로그에 들어갈 항목을 결정할 수 없지만 호스팅 공급자가 읽기 액세스 권한을 부여했을 수 있습니다. 일부 블로거는 AWStats와 같은 자동화 도구를 사용하여 웹 서버 통계를 분석합니다. 이 오픈 소스 로그 분석기는 웹 서버 로그에서 데이터를 읽고 구문 분석하여 시간별, 일별, 주별, 월별 트래픽 그래프 및 차트를 생성하고 방문 횟수 및 방문 시간, 도메인, 국가, 최고 트래픽 등을 표시할 수 있습니다. 또한 AWStats는 IP 주소를 읽고 구문 분석합니다.

그렇게 한다면 개인 데이터를 처리하는 것이므로 GDPR을 준수해야 합니다.

AWStats는 널리 사용되는 도구이기 때문에 좋은 예입니다. 그러나 그것은 또한 후속 질문의 전체 범위를 열어줍니다. 개인 데이터를 처리하는 경우 데이터 보호와 관련하여 어떤 보호 장치를 갖추고 있습니까? 사이트 통계를 공개적으로 공유합니까?

AWStats는 간단하고 친숙하지만 예를 들어 데이터를 일반 텍스트로 저장합니다. GDPR은 향상된 개인 정보 보호 및 데이터 보호 메커니즘을 규정하기 때문에 이는 문제가 될 수 있습니다. 우리는 익명화와 암호화를 언급했는데 AWStats는 이 두 가지를 만족하지 않습니다.

따라서 AWStats(또는 이와 유사한 것)와 같은 도구를 사용하는 경우 IP 주소와 같은 특정 유형의 정보를 선택 취소하는 (상대적으로 쉽게) 구성 가능한 옵션이 있는지, 그리고 구문 분석된 데이터가 다음을 수행할 수 있는지 여부를 확인해야 합니다. 암호화된 파일에 보관됩니다. 그렇지 않은 경우 액세스 권한이 있는 경우 웹 서버 로그를 분석해서는 안 됩니다. GDPR 책임의 일부를 전적으로 호스팅 공급자의 손에서 자신의 손으로 이전하는 것이기 때문입니다. 재미는 없지만 나중에 다른 유형의 사이트 통계에 대해 이야기하겠습니다.

페이지 로드 중

서버에 연결되면 페이지가 표시되고 브라우저에 표시됩니다. 이제 다른 방향에서 보세요. 사용자가 사이트에 연결하면 브라우저에 표시됩니다. 사이트가 무엇을 하고 있는지 모른다면 이제 위에서 아래로 작업하여 백그라운드에서 무슨 일이 일어나고 있는지 알아낼 수 있습니다.

표시된 모든 웹 페이지에는 보이는 부분(보이는 것)과 보이지 않는 부분(웹 언어 지시문, 선언 및 다양한 스크립트)이 있습니다. 웹 페이지는 HTML/CSS 언어로 작성되며 종종 Javascript 언어로 작성된 스크립트를 로드합니다.

최신 브라우저의 고급 개발자 도구를 사용하여 브라우저에서 페이지 로딩을 추적할 수 있습니다. 예를 들어 Firefox와 Chrome 모두 이러한 도구를 제공합니다. 마우스 오른쪽 버튼 클릭> 검사. 이렇게 하면 로드된 리소스의 순서를 표시할 수 있는 콘솔을 포함하여 기술 항목으로 가득 찬 별도의 페이지가 열립니다. 이것은 페이지의 백엔드이며 보이는 부분과 완전히 다릅니다.

참고:이 작업을 한 번도 해본 적이 없다면 사이트의 실행 흐름을 해독하는 작업이 쉽지 않을 것입니다. 기술에 정통하지 않으면 어려움을 겪을 것입니다. 그러나 GDPR을 준수하려면 규정이 귀하에게 적용되는지 여부를 결정하기 위해 귀하의 사이트가 무엇을 하는지 알아야 합니다. 이미 알고 있다면 실제 데이터에 집중하고 싶을 것이기 때문에 좋습니다.

제 웹사이트를 예로 들어 설명하겠습니다. dedoimedo.com은 주로 사용자 상호 작용이 없는 정적 사이트이기 때문에 가장 좋거나 대표적인 예는 아닙니다. 등록된 사용자가 없고 댓글을 사용하지 않으며 데이터 교환 부분이 매우 제한적입니다. 그래도 저는 이것이 유용한 연습이라고 생각합니다. 겉보기에 무해해 보이는 사이트라도 고려해야 할 몇 가지 데이터 수집 경로가 있을 수 있기 때문입니다.

내 페이지 로딩을 보면 일반적으로 흐름(보이는 요소와 보이지 않는 요소 모두)은 다음과 같습니다(당분간 특정 세부 사항에 대해 걱정하지 마십시오. 관련 세부 사항에 대해 자세히 이야기하겠습니다).

• 페이지 헤더(제목, 설명 등).
• Google Analytics(웹사이트 트래픽 분석).
• Google 사용자설정 검색 엔진(사람들이 내 사이트의 콘텐츠를 검색할 수 있음).
• 메인 콘텐츠(지금 읽고 있는 것과 같은 기사 텍스트 및 이미지).
• Google 애드센스(인라인으로 배치된 광고 블록).
• 더 많은 메인 콘텐츠(더 많은 텍스트와 멋진 이미지).
• ShareThis 버튼(사람들이 내 콘텐츠를 소셜 네트워크에 공유할 수 있는 공유 버튼).
• 일치하는 콘텐츠(내 사이트 및 일부 Google 광고의 관련 기사를 표시하는 Google 코드 실행).
• 쿠키 제어 스크립트(사용자가 쿠키 설정 여부를 선택할 수 있는 오버레이 애플릿).

구글 애널리틱스

웹 서버 로그를 기억하십니까? 글쎄, 어떤 사람들은 액세스 권한이 있을 수도 있고 없을 수도 있고, 어떤 사람들은 수동 분석 도구를 설정하는 데 필요한 기술 지식이 있을 수도 있고 없을 수도 있습니다. Google 애널리틱스가 들어오는 곳입니다. 이것은 아마도 가장 인기 있는 사이트 트래픽 통계 도구일 것입니다. 구성은 간단합니다. 모든 웹 페이지에 코드를 추가하기만 하면 됩니다! 당신이 이기고 Google도 이깁니다. 그들은 데이터를 좋아하기 때문입니다.

Google 애널리틱스는 여러 유형의 코드를 제공합니다. 과거에 Google Analytics는 Urchin이라는 도구를 기반으로 했으며 페이지에 추가한 코드 스니펫에 이를 반영했습니다. 그런 다음 몇 년 전 Google은 Urchin을 더 이상 사용하지 않지만 여전히 Urchin을 사용하는 웹사이트와의 이전 버전과의 호환성을 위해 기능이 활성화되어 있습니다(현재로서는). Urchin의 후속 제품은 Universal Analytics입니다. 최근에 Google은 추가 기능과 사이트 측정 기능을 제공하는 전체 사이트 태그도 도입했습니다. 그런 다음 다른 방법도 있습니다. 세 가지 주요 코드는 다음과 같습니다.

추가 Google 애널리틱스 읽기

리소스 섹션에 더 많은 내용이 있지만 다음은 고려해야 할 몇 가지 추가 사항입니다. 그리고 고려한다는 것은 귀하의 사이트뿐만 아니라 일반적으로 탐색을 보다 비공개로 만들고 데이터 수집을 거부할 수 있는 선택권이 사용자에게 있음을 알리는 것입니다.

Google Analytics Opt-Out 브라우저 추가 기능

Google 맞춤검색 엔진

Google 사용자설정 검색 엔진(CSE)은 페이지에 추가할 수 있는 코드 조각으로, 사람들이 귀하의 사이트 및/또는 전 세계에서 콘텐츠를 검색할 수 있도록 합니다. 시각적으로 검색 상자를 만들고 사람들은 다른 Google 검색처럼 사용할 수 있습니다. 여기서 우리는 스스로에게 질문해야 합니다. 개인 데이터 수집이 관련되어 있습니까?

이제 까다로운 부분은 Google CSE도 광고를 표시할 수 있다는 것입니다. 이는 Google Adsense와 연결되며 아직 언급하지 않았습니다. 그러나 일반적으로 Google CSE는 실제로 Google Adsense 대시보드를 통해 생성되기 때문에 광고 기능으로 간주될 수 있습니다. 따라서 확실히 개인 데이터 측면과 쿠키가 있습니다. 우리는 쿠키를 다루는 방법을 알고 있습니다. 광고에 대해 이야기해야 합니다.

구글 애드센스

Google Adsense는 아마도 세계에서 가장 인기 있는 광고 네트워크일 것입니다. 다시 말하지만 대부분의 다른 Google 도구와 마찬가지로 사용이 매우 간단합니다. 페이지에 코드 스니펫을 추가하기만 하면 사용자가 방문할 때 광고가 표시될 수 있습니다. 다시 한 번 질문해야 합니다. 우리가 개인 데이터를 처리하고 있습니까?

두 가지 유형의 광고가 있습니다. 비개인적(단지 무작위) 및 개인적(특히 이전 행동 및 수집된 메트릭을 기반으로 사용자를 대상으로 함). 귀하의 사이트에서 Google Adsense를 통해 개인 광고를 허용하면 프록시를 통해 개인 데이터를 처리합니다. 그러나 Google Adsense 스크립트 실행에 동의하는 것은 Google Analytics보다 훨씬 어렵습니다. 첫째, 아무데나 코드를 배치하기만 하면 사용자가 작업을 볼 수 없는 분석과 달리 광고 배치가 중요합니다. 둘째, 사용자가 동의하지 않으면 광고가 실행 및 표시되지 않으며 동의가 사실상 광고 차단기가 되어 게시자의 수익이 감소합니다.

Google은 이를 깨닫고 사용자가 EU 사용자에게 광고가 게재되는 방식을 구성할 수 있는 CENTRAL 도구를 제공해야 한다고 생각했습니다. 실제로 GDPR 시행 기한인 5월 25일 직전에 Google은 Adsense 대시보드에 EU 사용자에게 개인이 아닌 광고만 제공할 수 있는 별도의 섹션을 도입했습니다. 이것은 모든 도구와 서비스가 처리해야 하는 이상적인 방법입니다. 안타깝게도 항상 가능한 것은 아닙니다.

As the EU user consent tab explains, you still need to let users consent to cookies. This also covers the search engine implementation, because some of the cookies are shared, since CSE can display ads. So going back to our question, we use non-personal ads in the EU, and we ask users for consent on cookies, which covers this section.

ShareThis buttons

When I visually revamped my website in early 2018, I added the ShareThis inline buttons script to my pages, as a way of increasing user engagement around content. Essentially, the functionality comes in two pieces, an HTML element that shows the buttons and the script that runs in the background:

Unfortunately - and we will see this throughout the article - ShareThis only released an update for GDPR compliance on May 25, 2018, and it was too late for me. I could not wait till then. I decided to implement the functionality beforehand, and I did this using conditional loading via Cookie Control, similar to my Google Analytics (with cookies) example. So if a user consents, the buttons will be shown and cookies set, and if not, then they won't. I lose some sharing/engagement traffic this way, but the implementation is compliant.

Placing the script as is above into the onAccept function won't work. The syntax you need is slightly different, but it is applicable to any Javascript script really:

onAccept :function(){var file=document.createElement('script');
file.setAttribute("type","text/javascript");
file.setAttribute("src", "//platform-api.sharethis.com/js/sharethis.js#property=
5a3a29849d192f001374331f&product=inline-share-buttons");
document.getElementsByTagName("head")[0].appendChild(file);},

In a more abstract manner:

function(){
var file=document.createElement('script');
file.setAttribute("type","text/javascript");
file.setAttribute("src", "SCRIPT HERE");
document.getElementsByTagName("head")[0].appendChild(file);
}

I also tested the new ShareThis functionality. I found it not to be ideal, because it comes with its own overlay window (which clashes with my cookie applet), and the granularity of control given to the user for consent is not sufficient (in my opinion). I am willing to accept the loss of sharing traffic for the sake of compliance. But this is another good example where the new regulation may interfere with your ongoing activities, like the bounce rate and session duration when you use Google Analytics without cookies.

Matched content

This is very similar to the CSE and Adsense. Again, the code for matched content can be generated in the Google Adsense dashboard, so the same rules apply. You need to use non-personal ads in the EU and ask for their consent for cookies. We're all set here.

Other types of data

My examples above only illustrate a small number of possible types of embedded content and scripts. Indeed, you may also have a shopping cart. And this is the next type of data that I'd like to discuss.

You may be interacting with your users other than just showing them words and images. We've seen invisible scripts (they run in the background), we've seen cookies, we also handled visible third-party content like search and ads and sharing buttons, we didn't really process any deliberate personal information per se.

E-commerce forms and buttons (PayPal)

My example in this section will be PayPal. Indeed, PayPal is one of the most popular online payment services. The integration with web pages is dead simple. You copy and paste code onto your pages, and then users can use the Buy button or Donate button to send you money. They authenticate with their username and password, and a transaction is made. Data and money are exchanged between parties.

In GDPR terms, we have a lot of things to consider:

• Is the loading of the PayPal form compliant?
• Does PayPal set cookies? Hint:Yes. But then are you allowed to tamper with these?
• If users send you payments, they provide personal info, so what happens next?

Compliance wise, the short answer is yes. Moreover, people need to agree to PayPal terms and conditions, which means that if they use the payment form or button on your pages, they have already agreed for PayPal to have access to some of their information. You are not privy to any of this data UNLESS a transaction is made, and then, only a small part of this data is shared with you - which you need for obvious business reasons, including tax declarations. The need is not in dispute (no different than any receipt or invoice), but then we will touch some more on the data handling.

Another thing that needs to be mentioned is that PayPal is a financial institution, so some data collection is mandatory, for security and fraud-prevention reasons. And even if you use their services (or any other e-commerce platform), you do not really have much say in the matter.

Once the form or button is loaded, a script will run - and this script will most likely log some important security-related information. The form will also set a cookie - not for your own domain but for paypal.com. And here, we have a situation where we have a non-optional situation. So far, we could ask the user for consent or use our scripts in a non-personal manner. But here, we cannot control this. There is a necessary cookie that is required for the form to work properly, and for PayPal to do their thing. Your only options are to allow the form to load (without any tampering or changes) or not to have it, but this may also mean losing all business.

This constitutes a situation where necessary data collection is done - for security reasons. Cookie control tools will also not be able to delete the PayPal objects even if you want to. The way browsers work, for security reasons, domains can only delete cookies for themselves and nothing else. So if you open a site page, it cannot tamper with cookies that belong to other sites. Makes sense, because you don't want anyone to be able to steal your session login data.

So what do you do in a situation like this? Well, be transparent about it. You still use a service, but explain to your users how you do that, what data is collected - and best yet, refer them to the relevant privacy policy so they can read and understand what happens.

We answered two of the questions. The last one is - you now have some personal data, directly related to financial transactions performed on your site. This is necessary data (like necessary cookies set by the e-commerce platform), and you will need to use this data when you submit tax reports and such. In other words, you will be transferring this data from PayPal, which has its own security measures in place to safeguard data, to your own machine, probably a desktop, a laptop or a phone of some kind. What now?

Remember we talked about two major aspects related to data collection:anonymization and encryption. The first is around minimizing data collection (to the point of making it non-personal). We did that throughout most of the steps above, but we do end up with some data related to core business. We cannot anonymize this any further (that would probably raise a flag with tax authorities, for instance). 문제 없어요. So we need to protect this data.

Once you download a form or a report from PayPal (or any other e-commerce platform), you become responsible for it. So you must make sure the data is always safe. This means, if you accidentally lose it, or it gets stolen, you must make any retrieval of personal information difficult. This is where encryption comes into play.

Encryption is a mathematical process that renders human-readable data into random bits of text that have no meaning and that cannot be deciphered without a proper encryption key. Good encryption is near impossible to break with conventional computing methods. Moreover, to make things GDPR-compliant, you need be the sole owner of the encryption key so that only you can open the data. In other words, if someone else comes into possession of this data, it will be useless.

Bottom line:if you keep an offline copy of data outside its original source (like PayPal online console), then encrypt that data. Open it only for the purpose of necessary exchange, like with an accountant, tax authorities, etc. The last step will sometimes require that you send personal data via email or physical mail. Again, this is necessary for legal purposes, and it is unavoidable. But that's fine, because the other businesses and entities handling personal data will also have their piece on GDPR compliance, and this includes your email provider, your accountant, your government. The idea is to minimize such actions and maintain high security (this is a vague term, but we will elaborate more on that). See the section on encryption farther below.

User registration

Your site may have a user registration form. Normally, such forms will usually have at least a name and email fields. Data provided into the registration form will then be saved into some form of database. If you have this functionality on your site, you need to ask yourselves the following questions:

• Do you really need registered users? The answer could simply be yes.
• What information do you need from your users? Is your registration form 'slim' enough?
• Do you know where your database is located, how to access it, edit it and secure it?

We go back to what we already discussed - anonymization and encryption. If you can make user data you handle less personal (without hurting your blog/site activity), then do it. If you keep this data somewhere, try to encrypt it. For most people, the answer to how one goes about encrypting a SQL database hosted with a shared provider is very complex. 하지만. You are not alone in this game. Your provider has its own responsibility when it comes to their services:they need to be robust and secure.

Your additional GDPR responsibility comes into play when you handle user data. In other words:

• You need to know where user data is stored.
• You need to know how to access this data (and delete it if necessary).
• If you back this data up (to your computer, cloud, other servers), you need encryption for the backups.

If you struggle with this, you will need to hire a professional to do this for you (money, trust, beware scams). Otherwise, you may not be in the best position regarding GDPR compliance. It sounds tough and cruel, but think about it:if you're clueless around how your user data handling mechanisms work, would you really want people to use your services? Or put yourself in their shoes. Would you trust a site that has no 'idea' what they are doing with user data?

Then, the last piece:data transfer. If you possess personal data, you bear responsibility for its safekeeping. Selling data or giving it to other entities without an explicit permission from your users is a big no-no. The worst thing here is, you could 'accidentally' give away data without being aware. A service on your site might crawl or index your user database, and you wouldn't even know it.

The aspect of active user data collection is definitely more complex than just passive services you have enabled in the background. It requires far more effort. We will talk about this some more when we discuss Content Management Systems (CMS).

Comments

A similar logic applies to comments as to user registration. In essence, the two functionalities are identical. You will have users providing personal information. True, it's their choice to register and write comments, but it is your responsibility to let them know what you intend to do with the data. We will revisit this topic in detail a little later on.

Email (and mailing lists)

This is a very interesting aspect of data privacy, for many, many reasons. First, email is almost unavoidable when it comes to online sites/blogs. You will definitely have some kind of contact information, and people will use it to reach you. And with every email you receive, you will add new data points to your collection.

Emails contain a lot of personal data, too. A typical email will include:

• IP address of the last mail server (in a chain of mail servers from sender to you).
• In some cases, the IP address of the sender.
• System/mail client signature.
• User's email address (obvious).
• Name or alias (real or fictitious).
• The actual contents, which may contain any manner of personal data.

Moreover, emails are normally not encrypted, so the message itself is readable if you possess the actual mail message. 기다리다. Don't panic. This sounds ominous, but it is not. While the messages are written in plain text, so to speak, most mail systems use additional encryption to establish the connection and send data. We will discuss this in a jiffy.

Okay, so what do we do now?

We will need to address two main topics:1) receiving and sending email 2) storing email information.

First, you have no control over some of the data you receive in an email. Mail protocols dictate certain basic fields (for functionality and security). Furthermore, if you have a publicly available/accessible email address, you have no control over who contacts you, or why. That constitutes consent on behalf of the user.

The GDPR compliance comes into place when you initiate contact with other people via email. You need consent from your users to do so. If you have user registration and comments, then you will inevitably end up with a number of registered users, and you will have access to their email addresses.

The possession of this data does NOT give you the right to send your users information (most often marketing, advertising and promotion) unless they approve. 생각해보세요. If someone signs in to write a comment, that does not mean they want you to spam them with your newsletter. They need to agree to the newsletter separately.

To make it simple:you need to use email for the intended purpose only:

• If someone writes to you, you write back; perfectly fine, the exchange of communication.
• If someone registers, then you can use their email for user management purposes - verification of email, notification around their account, notification on comments, password reset, etc.
• If you want to send your users OTHER information, you need to ask them to consent. Like cookies.

And that's the black magic of email exchange. You can use mailing lists. You can use newsletters. You need to build these lists with your explicit user approval. Simple.

The second part is:data handling. Email data is like any other personal data. You need to make sure that you keep it safe. It's very similar to e-commerce data. You will most likely have to keep emails, for legal and accounting reasons. Make sure you do that in a secure and auditable manner:

• Access:You will be accessing email in two primary ways:1) through a web browser 2) using a dedicated mail client like Microsoft Outlook or Mozilla Thunderbird, for instance. In both cases, make sure you connect using a secure layer (https:// in browsers and secure ports in the mail client configuration, e.g. port 465 TLS/SSL). In some cases, you will also have the option to use Two-Factor Authentication (2FA), which makes hacking attempts against your login more difficult.
• Storage:Your inbox should be safe. If you use an online provider (including your hosting provider), they have their due diligence and responsibility to safeguard the data. Add your own security when you can, like 2FA, if possible. Most importantly, if you keep an offline copy of your inbox (any mail client really), you should keep the mailbox in an encrypted location (with yourself as the only owner of the encryption key). More on encryption later.

To sum it up:

• Use email as intended (reply, account support, mailing lists - each with its own consent).
• Protect the emails (secure connection, encrypted local storage, additional online safeguards where possible).

Embedded videos (Youtube)

If you choose to embed videos, then you must understand in what way these videos could potentially be used to profile users viewing these videos, and if there's an element of personal data involved, then you need to ask users for consent. Moreover, largely, there are two types of embedded videos - Flash-based clips (older) and native HTML5 videos (newer). This also makes a big difference.

A Flash-based video might look something like this:

An HTML version will look something like this:

So the question is - how to make videos GDPR-compliant?

First, regarding Flash clips (specifically Adobe Flash Player). In general, Flash as a technology is probably not the best way moving forward, at least when it comes to online videos. For over a decade, this technology was hugely popular as the preferred method for embedding interactive multimedia content into web pages, but it is gently being phased out in the recent years, both because of associated security issues with the Flash player and also because all modern browsers support native HTML5 video.

Flash clips may also set cookies - not just ordinary cookies - Flash cookies. They are similar in nature to regular Web cookies, but they are stored separately and used exclusively by Adobe Flash Player. And you may not have a straightforward way of controlling them using cookie control tools. So what you should do:

• Re-embed all existing clips in the old format and convert it to the new format.

Then, this leaves us with the familiar aspects of data collection and cookies. Luckily, Youtube offers an enhanced privacy feature for sharing. When you click on the share option for any which video online, you have the option to embed the video. Then, you need to tick the box that reads Enable privacy-enhanced mode. This will generate a different embed code, and it will set no cookies.

And this way - given the fact Youtube (Google) no longer uses third-party ad serving and pixel tracking as part of the GDPR compliance, and we use the privacy-enhanced mode with no cookies, we now have user-friendly embedded videos. Otherwise, you need to ask for consent as before.

Lastly, you may also have other non-standard, non-Youtube Flash clips on your pages. 예를 들면:

There is no easy solution for these. I am not aware of any trivial ways to limit Flash clips or disable cookies by design. If they need to be available publicly, the best recommendation is to upload these videos to Youtube and then offer them with the new, privacy-enhanced embed options. It is possible that these videos cannot be used on Youtube or similar sharing platforms for various legal/content reasons. In that case, you may want to have a separate disclaimer, or remove such clips altogether.

Embedded scripts

You may also embed other content onto your pages, other than videos. For instance, polls, maps, etc. These will come in some form of script, most often Javascript (something.js). The best way to handle these, if you want or need them, is to ask users for consent, in a way similar to what we did with ShareThis buttons. Whatever tool you use, the onAccept function will include:

function(){
var file=document.createElement('script');
file.setAttribute("type","text/javascript");
file.setAttribute("src", "SCRIPT HERE");
document.getElementsByTagName("head")[0].appendChild(file);
}

Content Management Systems (CMS):WordPress

This section will probably be of most interest to most of the people reading this article. WordPress is the most popular website and blogging management system in the world. It is very easy to use, relatively easy to configure, and it offers a wealth of flexible, useful plugins. I will indeed demonstrate with WordPress, but do note that other CMS exist, like Drupal, Joomla!, Magento, phpWiki, and many more.

The Lost Words is a fairly simple WordPress site - no user registration. I had comments enabled using the Disqus plugin (instead of organic comments) and collected data analytics using the Google Analytics for WordPress by MonsterInsights plugin (which is also mentioned in the guide above). I have disabled both these plugins prior to the GDPR enforcement data and implemented alternative methods for compliance, and I will explain exactly what and how.

So, the journey is the same as what we did earlier - only we will now be doing this with WordPress. Establish a connection to your site. Try to to understand the data flow. Open the dashboard and examine your installed and activated plugins.

Data collection =plugins

If you're using one or more WordPress plugins, it is quite likely you are collecting data, possibly personal data. The simplest way to verify if your plugins are collecting data is to read their privacy policy, if one exists. Then, you may need a little bit of tech knowledge to understand better what happens. And do remember, the fact core WordPress is GDPR-compliant does not mean your plugins - or your activities - are.

In my case, I have several plugins installed. Some of these do not collect any personal data whatsoever. These are mostly security hardening tools, designed to make the website more robust. Some plugins have a configurable option to collect data (this is similar to Web server logs we discussed and Google Analytics options). Some definitely do collect personal data. So we have three groups:

• Plugins that do not collect personal data (excluded from discussion).
• Plugins that can collect data - we can configure them for non-personal use, or collect personal data but then inform users and give them the option to consent. In some situations, the data may be necessary. We will discover that soon.
• Plugins that collect data - we must ask users for consent.

Google Analytics

The Website traffic statistics collection via Google Analytics falls into the second group. We have already seen how to use Google Analytics in an anonymous, non-personal data collection way. Here, I will show you how to run the script without personal data but with cookies. We will combine the two.

I decided to implement the conditional loading of Google Analytics based on user consent via Cookie Control, as I've shown you earlier. Basically, we ask users to consent, and if they do, the script will run and the cookies will be set. We still use IP address anonymization. Cookie Control, the tool of my choice, actually has a helpful example for exactly this purpose, so this should be easy to set up. See earlier for the actual copy &pastable snippet of code.

Why not MonsterInsights?

A simple matter of practicality and timelines. Originally, I actually had the Google Analytics for WordPress by MonsterInsights plugin configured for non-personal data collection (except cookies), even before they released their GDPR-ready update. Indeed, the plugin now comes with a separate EU Compliance tool that will configure everything in this regard (automatically). This addon costs money - and I've already invested money in a different cookie control solution (which also handles scripts).

Reading on what it does, the plugin handles IP anonymization, disables UserID tracking and disables Author tracking, this is a custom dimension. You can manually handle these, BUT the advantage of doing through this plugin is that these changes will only apply to your EU visitors. If you make the change through your Google Analytics accounts, they will be global. Google Analytics for WordPress by MonsterInsights also integrates with cookie plugins. I do not know if there's any conditional loading of the script, though.

For me, the introduced changes were a little late - like most GDPR tools, they only happened a short week before the enforcement date, which is hardly enough to properly test. Moreover, given that I had to ask users for consent for cookies (although I could use no local storage option), then I could also load Google Analytics conditionally via Cookie Control, and I've already purchased the multi-site license for this.

So it's the matter of practicality really. You can use MonsterInsights (with some extra cost) and integrate with several cookie control plugins. Or you could invest your money in a different tool (like I did), and handle it this way, with the advantage that you can control additional scripts and cookies and not specifically Google Analytics, like say ShareThis buttons, as we've already seen.

Comments (disqus)

I used to run Disqus for comments. Unfortunately, Disqus released an update only on May 25, 2018, and this was too late for me. At this point, I had disabled comments on the blog. I decided I would re-introduce them at a later stage, after I have ascertained that either WordPress comments or Disqus are compliant.

Before the GDPR update for Disqus, I did try to 'intercept' Discus using Cookie Control and its onAccept and onRevoke functions. This was a valuable lesson that we will discuss shortly. Now, Disqus has introduced necessary GDPR measures. If you want to login and post a comment, you first need to agree to their new privacy policy. If you're already logged in, you will not see the comments field until you agree. And you also have the option to opt-out of tracking. As a user (someone using Disqus), the downside of this choice is that you will have only temporary session logins, and you will need to log in anew each time.

Disqus &WordPress database integration

Do note that by default, Disqus will not write user comments to your database. You will need to manually configure that. If you do, the comments will be added to your database, and if you have had a non-personal database until now, it will now include personal data, and so you will need to treat it accordingly. For example, if you used to have non-encrypted database backups, now they will have to be encrypted. We will address this in the backups section below.

General script control

You may have additional plugins or scripts on your WordPress site, which may not have any GDPR accessories. If these plugins or scripts collect personal data, you will need to block their execution until the user has consented. This is similar to what I've outlined earlier with the ShareThis buttons. To that end, we need to talk about two WordPress functions - wp_enqueue_script() and wp_deregister_script().

Wp_enqueue_script

This function allows you to run scripts on demand. The usage is far from trivial, but if you know what script needs to run, you can wrap it in wp_enqueue_script and then place it into the onAccept section of your cookie control tool, like we did earlier.

The difficult part is actually finding the script that you need to run. This goes back to checking the Web console in a browser, and trying to figure out what your site is doing. There's no easy way around this, especially if you have plugins that behave in an odd, undocumented way. Justin Tadlock discussed this on his site way back in 2009, and it's an extremely valuable piece of advice. Your conditional script may look something like:

wp_enqueue_script( 'contact-form-7', wpcf7_plugin_url( 'contact-form-7.js' ), array('jquery', 'jquery-form'), WPCF7_VERSION, $in_footer );

Wp_deregister_script

This function does the opposite of enqueue; it removes/stops a script. Something like:

add_action( 'wp_print_scripts', 'my_deregister_javascript', 100 );

function my_deregister_javascript() {
wp_deregister_script( 'contact-form-7' );
}

Session cookies

WordPress (and your plugins and themes) may set session cookies. Again, we need consent, like before.

WordPress 4.9.6 - GDPR changes

There's no point repeating what's been said a million times before. Very briefly, WordPress now has additional tools that can help you manage user data. If you have registered users, you will be able to delete them, and there's also a template for privacy policy.

Data backups

We talked about backups earlier - around emails and databases. In general, there's a fairly good chance you will be backing up your site data (and your user data along with it). This is a healthy, recommended practice. You should have backups. By all means. What you need to make sure is:anonymization and encryption.

You should have covered the anonymization part already (by design). Encryption is the next step. Any which data backup you make should go to:

• Secure, trusted and DOCUMENTED location.
• Not be accessible to anyone but you.

The best way to achieve this is with encryption - and I'm not talking about the fact some backup providers (mostly cloud) offer encryption. Example:You might be backing up data to Dropbox. The service is secure, it offers 2FA and encryption. So if someone actually hacks into the Dropbox systems, they will not be able to read any data they might steal. But that is not enough. Because you do not control the encryption method.

The solution is to encrypt the backups with your own tool and key (password if you will), and then, for whatever reason, if someone has access to this data, they will not be able to access the actual contents. And we can finally discuss this technology called encryption.

Encryption tools

Well, we talked a lot about encryption above. Let's put it to some good use.

There are many ways to encrypt data. I will now elaborate on a few possible tools. Please note that the quality and security of encryption tools may differ. Also, different data types may require different types of encryption and standards. In some cases, you may have to use specific methods to be compliant. For ordinary bloggers, most tools should suffice. Some level of technical knowledge is required.

The most basic encryption method is to create a password-protected ZIP archive. This isn't foolproof, but a tool like 7-Zip can create encrypted files in its native 7z format (including filename encryption) using the AES-256 method, which is an encryption standard adopted by the US government. In Linux, you can use GPG (GnuPG), a free implementation of the OpenPGP standard, to encrypt files as well as emails. Several frontend tools are available.

You can also create encrypted containers - large files that you can then use as virtual folders to store many different files inside. To a casual observer, an encrypted container looks like a random file, something like Documents.bin, with a size of 603 MB, for instance. When you mount it (open it in a special program capable of reading and decrypting the encrypted format), it will be shown as a folder or a separate drive in your file manager, and you can interact with it like any other location on your disk.

Friendly GUI tools that can create encrypted containers include TrueCrypt and VeraCrypt, the latter being a fork of TrueCrypt, which was discontinued in 2015. This last piece of information may give you a pause, as you may assume there's an inherent security risk in this. However, an independent audit of the program found no significant security risks (for now). Both these programs use several encryption standards, including AES.

Another Linux tool - Vault in Plasma-based distributions like KDE neon or Kubuntu, for instance. This program is integrated into the desktop and lets you create encrypted containers on the fly. The encryption backend is CryFS, which also uses AES-256 plus another cipher.

Documentation

The last piece, once you've made your site compliant, is to wrap things up. Document everything, and that also means also writing a privacy policy. It does not have to be long or fancy. In fact, short and sweet is the best way forward. Be transparent about what you do and why, and explain the changes. If in doubt, always err on the side of caution. Give your user a choice rather than assume that it's ok. In the end, it's about transparency of your actions, anonymization of user data (if possible) and secure handling (encryption).

Finally, audits. Website layout and content can change over time. In fact, they always, inevitably do. You need to make sure you stay complaint. Every now then, it could be once a month or even once a quarter or whatever cadence, take a look at your Web stack. If things have changed, document them, and if they affect your users, reflect them in the privacy policy and/or the relevant tools and services your users interact with.

Conclusion

And here we are, the end. I would like to believe this article has been useful. Simple, clear and practical. I tried to cover as much material as possible, avoid vague language, and provide real-life, relatable examples from my own blogging adventures. GDPR compliance is NOT a trivial thing. It will require mental and technical effort, it will require hours of work, and it may even cost you money, both in direct investment and post-compliance changes to your traffic. But you will have a nice, tidy site that is friendly and fun to your users.

There are no shortcuts. The most important thing in this journey is education. Ignorance breeds fear. But if you take time to understand what you're doing - and your site is doing - you will both enjoy your work and the outcome. This means being careful around quick promises and silver-bullet solutions out there. Don't rush, take your time, try to figure out the best, most elegant way to make your site compliant. Finally, if you have any feedback, suggestions or requests around this topic, feel free to contact me, and I will try to update this guide. Take care, children of the Internet.

Resources

In order of appearance and relevance (most also linked throughout the document):

GDPR topics:

EU GDPR Information Portal

Wikipedia article on GDPR

Website statistics and analytics tools:

AWStats

Google Analytics

Google Analytics Measurement options for Web pages

Policy requirements for Google Analytics Advertising Features

Google Universal Analytics IP Anonymization

Google Analytics Opt-Out Browser Add-on

Cookie control tools:

Google Cookie Choices

Civic Cookie Control

Types of cookies used by Google

Google Analytics Cookie Usage on Website

Google Universal Analytics Cookies and User Identification

Google Adsense, Custom Search Engine &Matched Content:

Google Adsense

Google CSE

Sharing buttons:

ShareThis opt-out page

E-commerce:

PayPal privacy policy

Embedded videos &Flash player:

Wiki page on Local Shared Objects (Flash cookies)

Adobe Flash Player settings manager

Youtube Embed videos &playlists

WordPress:

WordPress home page

WordPress version 4.9.6

The Ultimate guide to WordPress and GDPR compliance

Google Analytics for WordPress by MonsterInsights EU compliance plugin add-on

Disqus opt-out policy

How to disable WordPress scripts and styles

WordPress developers tools reference:wp_enqueue_script

WordPress developers tools reference:wp_deregister_script

Encryption tools:

7-Zip homepage

The GNU Privacy Guard

OpenPGP encryption standard

Wiki page on Advanced Encryption Standard (AES)

TrueCrypt (GRC page)

TrueCrypt audit report

VeraCrypt