GDPR とウェブサイト - プライバシーと安心のガイド

ある日、あなたはのんきなブロガーです。次に、GDPR と呼ばれる迫りくる大きな問題に突然対処することになります。 EU は、プライバシーに焦点を当てた新しい規制 GDPR を導入しました。GDPR は、個人データを扱う Web サイトの重要なプライバシー、セキュリティ、およびデータ透明性の要件を定めています。あなたは自問しています、これは私に影響を与えますか?そして、あなたは心配しています。今日、この記事は、誰が、何を、いつ、どのように理解するのに役立つかを理解するのに役立ちます。うまくいけば、知識とツールの両方を提供して、気楽なブロガーになり、楽しく従うことができます.

さて、あなたが自問するかもしれないもう1つの質問は、規制が発効した後、なぜこれを今になって公開するのですか?答えは、信じられないかもしれませんが、世の中のほとんどのツールやサービスが GDPR 準拠の更新プログラムをリリースしたのはこの 1 週間程度であり、最終的にこのガイドをまとめることができました。何が得られるか見てみましょう。

目次

1. 免責事項
2. 60 秒でわかる GDPR <オール>
3. 個人データを処理している場合はどうなりますか?
4. 罰金の問題でもありません

データ フローに従う <オール>

ウェブサイトへの接続

ページの読み込み

Google アナリティクス <オール>

Google アナリティクスと個人データ

Google アナリティクスとローカル ストレージ (Cookie)

IP アドレスの匿名化

データを収集する (または Cookie を使用する) 場合はどうすればよいですか?

Google アナリティクスの追加情報

Google カスタム検索エンジン

Google アドセンス

ShareThis ボタン

一致するコンテンツ

その他の種類のデータ <オール>

電子商取引のフォームとボタン (PayPal)

ユーザー登録

コメント

メール (およびメーリング リスト)

埋め込み動画 (Youtube)

埋め込みスクリプト

コンテンツ管理システム (CMS):WordPress <オール>

データ収集 =プラグイン

Google アナリティクス

コメント (disqus) <オール>

Disqus と WordPress データベースの統合

一般的なスクリプト制御 <オール>

Wp_enqueue_script

Wp_deregister_script

セッション Cookie

WordPress 4.9.6 - GDPR の変更

データのバックアップ

暗号化ツール

ドキュメント

結論

リソース

免責事項

いくつかの重要な説明から始めましょう:

私は弁護士ではありません。この記事を法的助言として解釈しないでください。

私は間違っているか、思い違いをしている可能性があります。以下の情報を盲目的に信用しないでください。

この記事は主に、企業ではなく、ウェブサイトやブログを運営している個人を対象としています。

60 秒でわかる GDPR

GDPR についてまだ聞いたことがない、または読んだことがない場合は、ここに最も簡単なバージョンがあります。一般データ保護規則 (GDPR) は、データ保護とプライバシーに関する新しい EU 規則です。これは 2018 年 5 月 25 日に発効しました。これは、EU/EEA の市民および居住者の個人データの取り扱いに関するさらなる透明性と選択肢を提供することを目的としています。この規制では、企業が個人データをどのように処理、保存、使用するかについて、追加の保護と明確化を導入する必要があります。個人重視。個人的ではない =問題ありません。

GDPR は、個人データを処理、保存、または使用するすべての人に適用されます。したがって、規制があなた (料理、旅行、または IT 修理に関する小さなブログを持っている個人) に適用されるかどうかを尋ねようとしている場合、答えは次の質問にあります。 EU/EEA の市民と居住者は?

その質問への答えは簡単ではありません。

個人データを処理している場合はどうなりますか?

イエスかノーかを言う前に、ちょっとイエスと仮定してみましょう.

GDPR はデータ処理を妨げるものではありません。透明性と追加の保護が必要です。つまり、個人データを使用する理由を正当化し、それを行う理由と方法を説明し、データを保護するためのメカニズムを整備できる必要があります。これらの要件は、次のように大まかに定義できます。

<オール>

知っておく必要があります - データを扱っている場合は、理由があるはずです。

プライバシー - データを扱う場合は、個人情報を減らしてください。

セキュリティ - データを扱う場合、安全である必要があります。

オンラインで読んでいると、多くの人がデータ処理について本当に腹を立てていることに気づきました。彼らはすぐに、データの取り扱いが間違っていて、避けるべきだと思い込みます。正しいアプローチは、過剰で不必要なデータ処理を避けることです。

特定の個人データが必要な場合は、それらが必要です。それはいいです。正当なビジネス上の利益がある場合は、それを行使します。問題は、GDPR が誕生したのは、多くの企業が真の真のコア ビジネス ニーズを持たずに個人データをいじっていたためです。配管事業を営んでいるとします。顧客の年齢や社会的関心を知る必要がありますか?いいえ。しかし、T シャツを販売する場合、商品を発送するために、性別、場合によっては年齢、住所を知る必要がありますか?そうです。

データを処理する場合は、それについて透明性を確保してください (知る必要があります)。そして、それを保護します。この記事では、匿名化 (個人的なものを非個人的にする) や暗号化 (個人データを見えにくくしたり、アクセスしにくくしたりする) などの概念を使用します。

罰金の問題でもありません

これは、規制のもう 1 つの重要な要素です。多額の罰金。数字が怖い。しかし、それらに焦点を当てるのは間違ったアプローチです。法律と関連する処罰を確認してから、正しいことを行うべきか間違ったことを行うべきかを判断しません。懲役刑が長くなるかもしれないという理由だけで、窃盗を棄権することはありません。それは間違っているので、あなたはそれをしません。こっちも一緒。 GDPR には罰金が伴うため、従うべきではありません。これを、より優れた透明性の高いオンライン プレゼンスを作成する機会と見なしてください。

そのプロセスは苦痛で費用がかかる可能性があるため、元の質問である個人データに戻ります。処理していますか?

データの流れに従う

上記の質問に答えるには、いくつかのレベルの説明が必要です:

<オール>

個人データとして分類されるものは?

あなたのウェブサイトには、個人データを収集する仕組みがありますか?

最初のサブ質問への答えも簡単ではありません。個人データとは、個人を特定できるあらゆるものです。ほとんどの法律用語と同様に、定義はあいまいです。よくわからない場合、または疑問がある場合は、特定の「あいまいな」情報が実際に個人データとして使用される可能性があると想定するのが最善の答えです。

良い例は、コンピュータの IP アドレスです。技術的に言えば、これは電話番号のようなものです。これは、コンピューターが相互に通信できるようにする番号 (アドレス) であり、デバイスを一意に識別します。そうです、特定の状況下では、電話番号から契約書や請求書などを突き止めるのと同じように、個人を特定するために使用される可能性があります。

また、インターネット通信と切り離すことのできないものでもあります。そして、ここでテクノロジーと法の戦いが繰り広げられます。これが、プライバシー規制があいまいな (またはそうする必要がある) 理由でもあります。これは、特に技術に精通していない人々の間で、頭痛と心配を引き起こします.ある日、誰かが料理のレシピを共有したいと思っていました。次に、IP アドレスについて考える必要があります。

これにより、2 番目のサブ質問が表示されます。一部の (おそらくほとんどの) ブロガーは、独自のインフラストラクチャをセットアップせず、他の誰かによって作成されたプラットフォーム (ブログ プラットフォーム、請負業者によって構築された Web サイトなど) を使用します。彼らは、バックグラウンドで何が起こっているかさえ知らない場合があります。

これが、データ トレイルをたどらなければならない理由です。

サイトやブログに GDPR が適用されるかどうか、また、適用される場合は、GDPR に準拠するために何をする必要があるかを知りたい場合は、好奇心旺盛なユーザーからサイトに至るまでのインターネット トラフィックの旅をたどってみましょう。

ウェブサイトへの接続

技術的な詳細には触れませんが、たとえば dedoimedo.com という Web サイトにアクセスすると、ブラウザーはインターネット アドレス帳 (DNS と呼ばれます) を使用して、より広範なインターネット上で dedoimedo.com を見つけることができる場所を見つけ出し、その後、このアドレスに連絡してください。すべてが正常に構成されている場合、Web サーバーと呼ばれるソフトウェアがこの連絡要求を受け入れ、今読んでいるような Web ページの形式で情報を返します。

Web サーバーへの接続を開始すると、IP アドレス、オペレーティング システム、ブラウザのバージョン、その他のデータなど、必要な情報がブラウザから送信されます。各ブラウザーには、Web サーバーが最高のコンテンツを提供するのに役立つ、独自のいわゆる署名 (ユーザー エージェント) があります。

Web サーバーは、接続をデータ ログに記録します。多くの場合、これは次の理由で必須です:1) セキュリティ上の理由。ハッキングや詐欺の場合に証跡が必要なため 2) 技術的な問題 3) Web トラフィックのバランシング 4) コンプライアンスと監査。

IPアドレスについて言及しました。つまり、サーバーに記録されている個人情報が既に 1 つあることがわかっているため、GDPR が機能します。ちょっと待って。これが本当に当てはまるかどうかを完全に理解する必要があります。したがって、次の質問:

• ウェブ サーバーのログにアクセスできますか?
• 管理している場合、ウェブ サーバー ログの作成、アーカイブなどを管理できますか?

これらの質問の理由は、人々が利用できる Web サービスには大きく分けて 2 つのタイプがあるためです。彼らは独自のサーバーを持っているか、他の誰かのサーバーを使用している可能性があります.後者はホスティングとして知られており、ホスティング プロバイダーにお金を払って、Web サーバーをセットアップして維持してもらうことができます。多くの場合、これらは共有サービスです。 GoDaddy、Digital Ocean、Media Temple などでホスティングできます。

独自の Web サイトを持っている場合、事態はさらに複雑になります。しかし、それはおそらく、あなたが技術に精通していることも意味します。なぜなら、Web サーバーのセットアップは簡単なことではないからです.

ホスティング会社にお金を払って、独自のブログをセットアップするためのインフラストラクチャを提供している場合、GDPR に対する全責任はあなただけのものではありません。インフラストラクチャを管理しているため、ホスティング プロバイダーにも責任があります。

サーバー ログにアクセスできない場合、これは問題ではありません。アクセス権がある場合 (一部のホスティング プロバイダーは、ユーザーに制限付きのアクセスを許可しています)、制御できますか?おそらく、これらのログからデータを削除したり、何をどのようにログに記録するかを変更したりすることはできません。繰り返しますが、これは主にセキュリティ上の理由によるものであり、問​​題ありません。

では、Web サーバーのログを使用していますか?

サーバー ログを作成できない場合や、ログに記録する内容を決定できない場合がありますが、ホスティング プロバイダーが読み取りアクセスを許可している可能性があります。一部のブロガーは、AWStats などの自動化ツールを使用して、Web サーバーの統計を分析しています。このオープンソースのログ アナライザーは、Web サーバー ログからデータを読み取って解析し、時間別、日別、週別、月別のトラフィック グラフとグラフを作成し、訪問数と訪問期間、ドメイン、国、トップ ヒット トラフィックなどを表示できます。その他、AWStats は IP アドレスの読み取りと解析も行います。

そうする場合は、個人データを処理していることになるため、GDPR に準拠する必要があります。

AWStats は人気のあるツールであるため、その良い例です。しかし、それはまた、フォローアップの質問の全範囲を開きます.個人データを処理している場合、データ保護に関してどのような安全対策を講じていますか?サイトの統計情報を公開していますか?

AWStats はシンプルで使いやすいですが、たとえば、データをプレーン テキストとして保存します。 GDPR は強化されたプライバシーとデータ保護メカニズムを規定しているため、これは問題になる可能性があります。匿名化と暗号化について言及しましたが、AWStats はこれら 2 つを満たしていません。

そのため、AWStats (または同様のツール) などのツールを使用している場合は、IP アドレスなどの特定の種類の情報を選択解除するための (比較的簡単に) 構成可能なオプションがあるかどうか、および解析されたデータを使用できるかどうかを確認する必要があります。暗号化されたファイルに保管されます。そうでない場合、アクセスできる場合でも、Web サーバーのログを分析しないでください。GDPR の責任の一部をホスティング プロバイダーの手から自分自身に移すことになるからです。面白くありませんが、他のタイプのサイト統計については後で説明します。

ページの読み込み

サーバーに接続すると、ページが取得され、ブラウザーに表示されます。今度は別の方向から見てください。ユーザーがサイトに接続すると、ブラウザに表示されます。サイトが何をしているのかわからない場合は、トップダウンで作業して、バックグラウンドで何が起こっているかを理解しようとすることができます.

表示されるすべての Web ページには、目に見える部分 (目に見えるもの) と見えない部分 (Web 言語のディレクティブと宣言、およびさまざまなスクリプト) があります。ウェブページは HTML/CSS 言語で書かれており、Javascript 言語で書かれたスクリプトをロードすることがよくあります。

最新のブラウザーの高度な開発者ツールを使用して、ブラウザーでのどのページの読み込みも追跡できます。たとえば、Firefox と Chrome の両方がこれらのツールを提供しています。右クリック> [検査] を選択します。これにより、ロードされたリソースのシーケンスを表示できるコンソールを含む、技術的なものでいっぱいの別のページが開きます。これはページのバックエンドであり、目に見える部分とはまったく異なります。

注意:これを行ったことがない場合、サイトの実行フローを解読する作業は簡単ではありません。技術に精通していない場合は、苦労するでしょう。ただし、GDPRに準拠したい場合は、規制が適用されるかどうかを判断するために、サイトが何をしているかを知る必要があります.すでにわかっている場合は、実際のデータに注目したいので、それは素晴らしいことです。

例として、私のウェブサイトを紹介します。 dedoimedo.com は大部分が静的なサイトであり、ユーザーとのやり取りがないため、これは最良の例でも最も代表的な例でもありません。登録ユーザーはおらず、コメントも使用せず、データ交換部分は非常に限られています。それでも、これは有益な演習だと思います。なぜなら、一見無害に見えるサイトでさえ、考慮に入れる必要のあるいくつかのデータ収集ベクトルを持っている可能性があるからです.

私のページの読み込みを見ると、通常、フロー (目に見える要素と見えない要素の両方) は次のようになります (現時点では特定の詳細について心配する必要はありません。関連するものについて詳しく説明します):

• ページ ヘッダー (タイトル、説明など)
• Google アナリティクス (ウェブサイトのトラフィック分析)
• Google カスタム検索エンジン (ユーザーが自分のサイトのコンテンツを検索できるようにする)
• メイン コンテンツ (記事のテキストと画像、今読んでいるものなど)
• Google Adsense (インラインに配置された広告ブロック)
• より多くのメイン コンテンツ (より多くのテキストと魅力的な画像)。
• ShareThis ボタン (人々が私のコンテンツをソーシャル ネットワークに共有できる共有ボタン)。
• 関連コンテンツ (私のサイトの関連記事と一部の Google 広告を表示する Google コードを実行します)
• Cookie 制御スクリプト (ユーザーが Cookie を設定するかどうかを選択できるオーバーレイ アプレット)

Google アナリティクス

Web サーバーのログを覚えていますか?アクセスできる人もいない人もいれば、手動分析ツールをセットアップするために必要な技術的知識を持っている人もいない人もいます。そこで、Google アナリティクスの出番です。これは、おそらく最も人気のあるサイト トラフィック統計ツールです。構成は簡単です。すべての Web ページにコードを追加するだけで完了です。あなたが勝ち、Google が勝ちます。彼らはデータが好きだからです。

Google アナリティクスでは、いくつかのタイプのコードを提供しています。これまで、Google Analytics は Urchin と呼ばれるツールに基づいており、ページに追加したコード スニペットにはこれが反映されていました。その後、数年前に Google は Urchin を非推奨にしましたが、Urchin を使用している Web サイトとの下位互換性のために機能は (今のところ) 有効なままです。 Urchin の後継は Universal Analytics です。最近では、Google は、追加機能とサイト測定機能を提供するグローバル サイト タグも導入しました。それから、他の方法もあります。コードの 3 つの主要部分は次のようになります。

Urchin (urchin.js):

ユニバーサル アナリティクス (analytics.js):

グローバル サイト タグ (gtag.js):

これらはデフォルトのコード スニペットです。機能させるには、Google アナリティクス コードで xxxxxx 文字を変更する必要があります。デフォルトでは、Google アナリティクスは Cookie を設定し、いくつかの情報を収集します。そのため、以下を理解する必要があります:a) Cookie とは何ですか? b) 収集された情報は個人的なものですか?

この質問に答えるには、実行するコードと Google アナリティクス内で発生することの 2 つに注目する必要があります。簡単な答えは次のとおりです。デフォルトでは、Google アナリティクスは IP アドレス以外の個人データを分析するように設定されていません。実際、Google はツールを GDPR に準拠させるために多くの作業を行っており、これは Google アナリティクスの管理ダッシュボード内で利用可能なオプションに反映されています。それから始めましょう。

個人データの収集にはいくつかの方法があります。これらを使用する場合は、EU ユーザーに通知し、データを収集する許可 (同意) を求める必要があります。これは、分析スクリプトの実行がユーザーの選択に依存することを意味します。つまり、誰かが個人データの収集を望まない場合、分析スクリプトは実行されず、その特定のユーザーに関する統計はまったく収集されません。

選択肢があります:

<オール>

ユーザーの同意待ちの個人データを収集します。収集量が少ない可能性があります (理論的には、EU からはまったく収集されません)。

個人データを収集しない - この場合、GDPR 条項は適用されません。

Google アナリティクスと個人データ

Google Analytics は、非個人サイトのトラフィック統計ツールとして実行できます。つまり、訪問数とページ数、リアルタイムのトラフィック、その他の指標に関する情報は得られますが、ユーザーに関する情報は得られません。まず、Google アナリティクス ダッシュボードでオンラインで何をする必要があるかを見てみましょう。 Google には、できることとできないこと、およびしなければならないことを説明した非常に詳細な FAQ があります。

Google アナリティクスでは、広告やリマーケティング＝個人データを利用することができます。これらをオフにすることができます。

保持ポリシーを設定する必要があります (古いデータは削除されます)。これは、(設定された保持期間の前に) 古い履歴データに基づいて分析を行うことができないことを意味しますが、繰り返しますが、これはデータ処理の量を最小限に抑えるのに役立ちます。以下のステップ）。それでも、慎重に過ちを犯し、プライバシーを意識することが常に最善です。

次に、ユーザー ID の手順もあります。 Google はすでに個人を特定できるデータの使用を禁止していますが、この機能を使用する場合は、同意を求める必要があります。したがって、この機能はオフに設定する必要があります。

また、個人を特定する可能性のあるカスタム ディメンションやカスタム指標が含まれていないことも確認する必要があります。もしあなたがそれらを持っているなら、あなたは非個人的な空間から個人的な空間に移動しているからです.繰り返しますが、それらがあれば問題ありませんが、それは別のトピックです。現時点では、Google アナリティクスを使用した匿名の非個人データ収集に重点を置いています。

これは、ダッシュボードのオンライン部分をカバーしています。しかし、IP アドレスと Cookie についてはまだ話していません。したがって、前者は明らかです。さて、クッキー...

Cookie は、コンピューターにローカルに保存されるテキスト ファイルであり、ウェブサイトがオンライン アクティビティを継続させるために使用します。 Cookie は、ウェブサイトにあなたの最後のアクセスやログインなどを知らせる小さなログ ファイルだと考えてください。これは、たとえば、あなたが戻ってきたときにまだログインしているときなど、サイトがあなたを記憶できるようにするための方法です。 Web サイトは Cookie を設定できます。有効期限が過ぎると、Cookie は削除されて内容が消去され、Web サイトに対するアクティビティ履歴が効果的に消去されます。

技術的には、Cookie に保存された一部の情報は個人を特定する可能性があります。つまり、Cookie を設定するには、ユーザーに同意を求める必要があります。同意しない場合、Cookie を設定しないでください。

Google アナリティクスはいくつかの Cookie を設定します。そのため、ユーザーに許可を求める必要があります。ただし、それよりも少し複雑です。初期設定の Cookie について同意を求めても、ウェブサイトのページが読み込まれたときに、Google アナリティクスの実行が許可されていれば、閲覧セッション中に Cookie が設定されるため、設定するだけでなく、実際にはユーザーに同意を求める必要があります。 Cookie だけでなく、そもそも Google アナリティクスも実行します。これはサイト統計に戻ります。ユーザーが同意しない場合、その訪問は (非個人的な部分であっても) カウントされず、統計にカウントされる (EU) トラフィックが少なくなります。

したがって、個人データを収集せずに Google アナリティクスを実行できるようにするには、Cookie を無効にする必要があります。また、すべてのオンライン作業に加えて、IP アドレスの部分も処理する必要があります。

Google アナリティクスとローカル ストレージ (Cookie)

Google アナリティクスの開発者ツール セクションには、ローカル ストレージを無効にする設定など、豊富な情報が含まれています。これは、Cookie がまったく設定されないことを意味します。実際、ユニバーサル アナリティクスの場合、次の行を変更する必要があります:

ga('create', 'UA-xxxxxx', 'auto');

これに:

ga('create', 'UA-xxxxxx', { 'storage':'none' });

その後、Cookie は設定されません。

IP アドレスの匿名化

Google アナリティクスはIPアドレス＝個人情報を取得します。ただし、IP アドレスを匿名化することはできます。これにより、aaa.bbb.ccc.ddd のような IP アドレスが aaa.bbb.ccc.0 になります。技術的な詳細に立ち入ることなく、これにより、一意の識別子 (IP アドレス) が、アドレスの最後のセグメント (オクテット) で使用可能な 254 個のアドレスと同一になり、Google アナリティクスから見た IP アドレスを介したユーザーのインターネット プレゼンスが匿名になります。これは、Google アナリティクス イベントがサーバーに送信される前に行を追加することによって行われます。 「作成」行と「送信」行の後に次の行を追加します (ユニバーサル アナリティクス):

ga('set', 'anonymizeIp', true);

このようなもの:

ga('create', 'UA-xxxxxx', { 'storage':'none' });
ga('set', 'anonymizeIp', true);
ga('send', 'pageview');

これで、Google アナリティクスを介して匿名の非個人データを収集できるようになりました。

この方法の欠点は、ユーザーの忠誠度がわからないことです。直帰率 (サイトに 1 ページだけアクセスして離脱する人の数) は 100% になり、平均セッション時間 (サイトでの滞在時間) は 0 秒に減少します。しかし、それは問題ありません。それがまさに私たちが望んでいることだからです。集約された非個人的なトラフィック データのみが必要です。

データを収集したい場合 (または Cookie を使用したい場合)

その場合、明示的なユーザーの同意に基づいて Google アナリティクス スクリプトの読み込みを行う必要があります。そのためには、ユーザーが同意するまで (および同意する場合)、Google アナリティクスの実行と Cookie の設定をブロックする何らかのツール (実際には別のスクリプト) が必要です。

私は、GDPR 要件を満たす Cookie コンプライアンスを提供するために特別に設計されたツールである Civic Cookie Control を実装することにしました。このツールと他のいくつかのツールは、Google Cookie Choices にリストされています。利用可能なソリューションのいくつかをテストした結果、これが私のニーズに最も適したツールであると判断しました。

Cookie Control について (明らかな技術的な部分は別として) 私が気に入ったのは、PRO バージョンでは EU 以外の国を除外できるため、GDPR の影響を受けていないユーザーにはアプレットが表示されないことです。つまり、Cookie 同意アプレットをユーザーに選択的に表示できます。無料版は存在しますが、より機能が制限されており、PRO バージョンは安くはありません。最初に述べたことに戻ります。GDPR への準拠には、費用と時間がかかり、ほとんどの個人のブロガーやサイト所有者が持っていない可能性のある専門知識が必要になる可能性があります。 .

サイトのすべてのページに Cookie コントロールを実装しました。文言、スタイルを選択し、必要なカテゴリを作成できます。最も重要なのは、カテゴリごとに onAccept と onRevoke の 2 つの関数があることです。前者は、ユーザーが同意した場合にのみ、いくつかのコードを実行 (および Cookie を設定) します。後者は Cookie を削除し、同意がない場合はスクリプトを停止する可能性があります。この特定のツールの正確な構成は、この記事の範囲を超えています。

したがって、すべてのページで Google アナリティクス + Cookie を実行したい場合、EU で Cookie Control などのツールを使用すると、宣言は次のようになります (例としてユニバーサル アナリティクスを使用):

onAccept :function(){
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function( ){
(i[r].q=i[r].q||[]).push(引数)},i[r].l=1*new Date();a=s. createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})( window,document,'script','https://www.google-analytics.com/analytics.js','ga');

ga('create', 'UA-xxxxxx', 'auto');
ga('send', 'pageview');
},
onRevoke:function(){
window['ga-disable-UA-xxxxxx'] =true;
}

これは、Cookie コントロールに加えて、必要に応じてスクリプトをブロックするオプションがあることも示しています [sic]。この例は、WordPress のようなコンテンツ管理システム (CMS) について説明するときに後で説明します。

Cookie コントロール スクリプトは、私のサイトのすべてのページで宣言されています。匿名化された非個人的なルートを選択したため、Google アナリティクスではなく、他のサードパーティのコンテンツを制御します。各ページに追加されたコードは次のようになります (必要に応じて検索と置換が容易になるため、コードを 1 行にまとめました):

Google アナリティクスの追加情報

リソース セクションにはさらに多くの情報がありますが、考慮すべき追加事項がいくつかあります。検討とは、サイトだけでなく一般的に、ブラウジングをより非公開にし、データ収集をオプトアウトする選択肢があることをユーザーに知らせることです.

Google アナリティクス オプトアウト ブラウザ アドオン

Google カスタム検索エンジン

Google カスタム検索エンジン (CSE) は、ページに追加できるコードの一部であり、ユーザーがサイトやグローバルでコンテンツを検索できるようにします。視覚的には検索ボックスを作成し、他の Google 検索と同じように使用できます。ここで自問自答する必要があります:個人データの収集は含まれていますか?

ここで注意が必要なのは、Google CSE は広告を表示することもできるということです。これは、まだ説明していない Google Adsense と結びついています。ただし、一般に、Google CSE は実際には Google Adsense ダッシュボードを通じて生成されるため、広告機能と見なすことができます。したがって、間違いなく個人データの側面と Cookie があります。私たちはクッキーの扱い方を知っています。広告について話し合う必要があります。

Google アドセンス

Google Adsense は、おそらく世界で最も人気のある広告ネットワークです。繰り返しになりますが、他のほとんどの Google ツールと同様に、使い方は非常に簡単です。コードのスニペットをページに追加するだけで、ユーザーがアクセスしたときに広告が表示される場合があります。繰り返しになりますが、私たちは個人データを扱っていますか?

広告には、非個人的 (ランダムなもの) と個人的 (以前の行動と収集された指標に基づいて特定のユーザーを対象とする) の 2 種類があります。サイトで Google Adsense 経由の個人広告をプロキシによって許可する場合、個人データを処理することになります。しかし、Google Adsense スクリプトの実行に同意することは、Google Analytics よりもはるかに困難です。 1 つ目は、コードを任意の場所に配置するだけでアクションがユーザーに表示されないアナリティクスとは異なり、広告の配置が重要であることです。 2 つ目は、ユーザーが同意しない場合、広告は実行も表示もされず、同意は実質的に広告ブロッカーになり、パブリッシャーの収益が減少することを意味します。

Google はこれを認識したため、ユーザーが EU ユーザーに広告を配信する方法を設定できる CENTRAL ツールを提供する必要があると判断しました。実際、5 月 25 日の GDPR 施行期限の直前に、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. Think about it. 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)

This is an interesting one. Youtube allows you to embed videos into your pages.悪くない。 But there's a whole range of things that come into play here. Youtube videos combine various elements:there might be an element of tracking, which allows Youtube to offer video recommendations; there might be ads shown to users, again based on various preferences; there might be cookies;もっと。

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.

Privacy-enhanced code then looks like this:

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. For instance:

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.

WordPress released its first GDPR-ready version, 4.9.6, on May 17, 2018. Wpbeginner.com has released a very useful guide on GDPR on May 23, 2018, only two days before the regulation came into effect. My own testing and implementation of necessary changes shows certain differences to this guide, and so I'd like to share in detail the changes and settings that I've undertaken to make my book-writing site, The Lost Words, in line with the regulation.

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.しかし、それだけでは十分ではありません。 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