GDPR &Trang web của bạn - Hướng dẫn về quyền riêng tư và sự an tâm

Một ngày nọ, bạn là một blogger vô tư. Tiếp theo, bạn đột nhiên phải đối mặt với một thứ to lớn đang lờ mờ được gọi là GDPR. EU đã đưa ra một quy định mới tập trung vào quyền riêng tư, GDPR và quy định này đưa ra các yêu cầu quan trọng về quyền riêng tư, bảo mật và minh bạch dữ liệu đối với các trang web xử lý dữ liệu cá nhân. Bạn đang tự hỏi mình, điều này có ảnh hưởng đến tôi không? Và bạn đang lo lắng. Hôm nay, bài viết này sẽ giúp bạn hiểu rõ hơn về ai, cái gì, khi nào và như thế nào, đồng thời hy vọng cung cấp cho bạn cả kiến ​​thức và công cụ để một lần nữa trở thành một blogger vô tư VÀ tuân thủ vui vẻ.

Bây giờ, một câu hỏi nữa mà bạn có thể tự hỏi là:tại sao bây giờ mới xuất bản nội dung này, SAU KHI quy định có hiệu lực? Vâng, câu trả lời là, tin hay không, hầu hết các công cụ và dịch vụ hiện có đã phát hành các bản cập nhật tuân thủ GDPR chỉ trong khoảng một tuần qua và điều đó cuối cùng đã cho phép tôi tập hợp hướng dẫn này. Hãy xem những gì mang lại.

Mục lục

1. Tuyên bố miễn trừ trách nhiệm
2. GDPR sau 60 giây
   1. Nếu bạn đang xử lý dữ liệu cá nhân thì sao?
   2. Cũng không phải là tiền phạt
3. Theo luồng dữ liệu
   1. Kết nối với một trang web
   2. Đang tải trang
4. Google Analytics
   1. Google Analytics &dữ liệu cá nhân
   2. Google Analytics &bộ nhớ cục bộ (cookie)
   3. Ẩn danh địa chỉ IP
   4. Nếu bạn muốn thu thập một số dữ liệu (hoặc sử dụng cookie) thì sao?
   5. Đọc Google Analytics bổ sung
5. Công cụ Tìm kiếm Tuỳ chỉnh của Google
6. Google AdSense
7. Các nút Chia sẻ Này
8. Nội dung phù hợp
9. Các loại dữ liệu khác
   1. Các biểu mẫu và nút thương mại điện tử (PayPal)
   2. Đăng ký người dùng
   3. Nhận xét
   4. Email (và danh sách gửi thư)
   5. Video nhúng (Youtube)
   6. Tập lệnh nhúng
10. Hệ thống quản lý nội dung (CMS):WordPress
    1. Thu thập dữ liệu =phần bổ sung
    2. Google Analytics
    3. Nhận xét (disqus)
       1. Tích hợp cơ sở dữ liệu Disqus &WordPress
    4. Kiểm soát tập lệnh chung
       1. Wp_enqueue_script
       2. Wp_deregister_script
    5. Cookie phiên
    6. WordPress 4.9.6 - Thay đổi GDPR
11. Sao lưu dữ liệu
12. Công cụ mã hóa
13. Tài liệu
14. Kết luận
15. Tài nguyên

Tuyên bố miễn trừ trách nhiệm

Hãy bắt đầu với một số giải thích quan trọng:

Tôi không phải là luật sư và bạn không nên hiểu bài viết này là lời khuyên pháp lý theo bất kỳ cách nào.

Tôi có thể sai hoặc ảo tưởng, vì vậy đừng tin tưởng một cách mù quáng vào thông tin bên dưới.

Bài viết này chủ yếu dành cho các cá nhân điều hành trang web và blog, không phải công ty.

GDPR trong 60 giây

Nếu bạn chưa từng nghe hoặc đọc về GDPR, thì đây là phiên bản ngắn gọn nhất. Quy định chung về bảo vệ dữ liệu (GDPR) là quy định mới của EU về bảo vệ dữ liệu và quyền riêng tư. Nó có hiệu lực vào ngày 25 tháng 5 năm 2018. Nó được thiết kế để cung cấp thêm sự minh bạch và lựa chọn xung quanh việc xử lý dữ liệu cá nhân của công dân và cư dân EU/EEA. Quy định yêu cầu các doanh nghiệp đưa ra các biện pháp bảo vệ bổ sung và làm rõ cách họ xử lý, lưu trữ và sử dụng dữ liệu cá nhân. Sự nhấn mạnh vào cá nhân. Không cá nhân =không thành vấn đề.

GDPR áp dụng cho bất kỳ ai xử lý, lưu trữ hoặc sử dụng dữ liệu cá nhân. Vì vậy, nếu bạn sắp hỏi liệu quy định có áp dụng cho bạn không (bạn, cá nhân có một blog nhỏ về nấu ăn, du lịch hoặc sửa chữa CNTT), thì câu trả lời nằm ở câu hỏi sau:bạn có xử lý, lưu trữ hoặc sử dụng dữ liệu cá nhân của Công dân và cư dân EU/EEA?

Nếu bạn đang xử lý dữ liệu cá nhân thì sao?

Trước khi chúng ta có thể nói có hay không, chúng ta hãy nhanh chóng giả sử có trong giây lát.

GDPR không ngăn chặn việc xử lý dữ liệu - nó yêu cầu tính minh bạch và bảo vệ bổ sung. Nói cách khác, bạn cần có khả năng biện minh cho lý do sử dụng dữ liệu cá nhân của mình, giải thích lý do và cách thức bạn làm điều đó, đồng thời có sẵn các cơ chế để bảo vệ dữ liệu. Những yêu cầu này có thể được định nghĩa chung là:

1. Bạn cần biết - nếu bạn đang xử lý dữ liệu thì phải có lý do.
2. Quyền riêng tư - nếu bạn đang xử lý dữ liệu, hãy cố gắng làm cho dữ liệu ít mang tính cá nhân hơn.
3. Bảo mật - nếu bạn đang xử lý dữ liệu thì dữ liệu đó cần được bảo mật.

Đọc trực tuyến, tôi nhận thấy rất nhiều người thực sự khó chịu về việc xử lý dữ liệu. Họ ngay lập tức cho rằng việc xử lý dữ liệu là sai và nên tránh. Cách tiếp cận phù hợp là - nên tránh xử lý dữ liệu quá mức và không cần thiết.

Nếu bạn xử lý dữ liệu, thì hãy đảm bảo rằng bạn minh bạch về dữ liệu đó (cần phải biết). Và sau đó, hãy bảo vệ nó. Trong bài viết này, tôi sẽ sử dụng các khái niệm như ẩn danh (làm cho nội dung cá nhân không mang tính cá nhân) và mã hóa (làm cho dữ liệu cá nhân ít hiển thị/có thể truy cập hơn).

Cũng không phải là tiền phạt

Đây là một yếu tố hấp dẫn khác của quy định. Phạt nặng. Những con số thật đáng sợ. Nhưng tập trung vào chúng là cách tiếp cận sai lầm. Bạn không kiểm tra luật pháp và hình phạt liên quan rồi quyết định xem bạn nên làm điều gì đó đúng hay sai. Bạn không kiêng trộm cắp chỉ vì án tù có thể dài. Bạn không làm điều đó, bởi vì nó sai. Ở đây cũng vậy. Bạn không nên tuân theo GDPR vì nó đi kèm với tiền phạt. Hãy coi đây là cơ hội để tạo ra sự hiện diện trực tuyến minh bạch và tốt hơn.

Quá trình đó có thể gây đau đớn và tốn kém, vì vậy tất cả quay trở lại câu hỏi ban đầu của chúng tôi - dữ liệu cá nhân. Bạn có xử lý nó không?

Theo luồng dữ liệu

Có một số mức độ làm rõ cần thiết để trả lời câu hỏi trên:

1. Những gì được phân loại là dữ liệu cá nhân?
2. Trang web của bạn có cơ chế thu thập dữ liệu cá nhân không?

Câu trả lời cho câu hỏi phụ đầu tiên cũng không tầm thường. Dữ liệu cá nhân là bất cứ thứ gì có thể nhận dạng một người. Giống như hầu hết các thuật ngữ pháp lý, định nghĩa là mơ hồ. Câu trả lời tốt nhất là, nếu bạn không chắc chắn hoặc nếu bạn nghi ngờ, thì tốt nhất bạn nên cho rằng một phần thông tin "mơ hồ" nhất định thực sự có thể được sử dụng làm dữ liệu cá nhân.

Một ví dụ điển hình là địa chỉ IP của máy tính. Về mặt kỹ thuật, đây giống như số điện thoại của bạn. Đó là một số (địa chỉ) cho phép các máy tính giao tiếp với nhau và nó nhận dạng duy nhất thiết bị của bạn. Vì vậy, có, trong một số trường hợp nhất định, nó có thể được sử dụng để nhận dạng một người, giống như cách số điện thoại của bạn có thể được truy tìm từ hợp đồng hoặc hóa đơn của bạn hoặc tương tự.

Nó cũng là một phần không thể tách rời của truyền thông Internet. Và đây là lúc cuộc chiến giữa công nghệ và luật pháp diễn ra. Đó cũng là lý do tại sao các quy định về quyền riêng tư là (hoặc cần) mơ hồ. Điều này gây đau đầu và lo lắng, đặc biệt là đối với những người ít hiểu biết về công nghệ. Một ngày nọ, ai đó chỉ muốn chia sẻ công thức nấu ăn của họ. Tiếp theo, họ cần suy nghĩ về địa chỉ IP.

Điều này đưa chúng ta đến câu hỏi phụ thứ hai. Một số (có thể là hầu hết) người viết blog sẽ không thiết lập cơ sở hạ tầng của riêng họ và sẽ sử dụng nền tảng do người khác tạo - nền tảng viết blog, trang web do nhà thầu xây dựng, v.v. Họ thậm chí có thể không biết điều gì đang xảy ra trong nền.

Và đây là lý do tại sao chúng ta phải lần theo dấu vết dữ liệu.

Nếu bạn muốn biết liệu GDPR có áp dụng cho trang web/blog của mình hay không - và nếu có, thì bạn cần làm gì để đảm bảo mình tuân thủ - thì hãy theo dõi hành trình lưu lượng truy cập Internet - từ một người dùng tò mò đến trang web của bạn.

Kết nối với một trang web

Không đi sâu vào chi tiết kỹ thuật, khi bạn truy cập một trang web, chẳng hạn như dedoimedo.com, điều xảy ra là, trình duyệt của bạn sử dụng sổ địa chỉ Internet (được gọi là DNS), để tìm ra nơi có thể tìm thấy dedoimedo.com trên Internet rộng lớn hơn và sau đó liên hệ với địa chỉ này. Nếu mọi thứ được định cấu hình đều ổn, một phần mềm có tên Máy chủ web sẽ chấp nhận yêu cầu liên hệ này và trả lại thông tin dưới dạng các trang web, giống như trang bạn đang đọc ngay bây giờ.

Khi bạn bắt đầu kết nối với máy chủ Web, trình duyệt của bạn sẽ gửi một số thông tin cần thiết, bao gồm địa chỉ IP, hệ điều hành, phiên bản trình duyệt của bạn và một số dữ liệu bổ sung. Mỗi trình duyệt có cái gọi là chữ ký (tác nhân người dùng) riêng, giúp máy chủ Web cung cấp nội dung tốt nhất.

Các máy chủ web đăng nhập các kết nối vào nhật ký dữ liệu của họ. Thông thường, đây là điều bắt buộc vì:1) lý do bảo mật, vì bạn cần theo dõi trong trường hợp bị hack, lừa đảo 2) sự cố kỹ thuật 3) cân bằng lưu lượng truy cập web 4) tuân thủ và kiểm tra.

Chúng tôi đã đề cập đến địa chỉ IP. Vì vậy, chúng tôi biết rằng đã có một phần thông tin cá nhân đang được ghi lại với máy chủ, vì vậy GDPR sẽ phát huy tác dụng. Nhưng đợi đã. Chúng ta cần hiểu đầy đủ nếu điều này thực sự áp dụng. Do đó, các câu hỏi sau:

• Bạn có quyền truy cập nhật ký máy chủ Web không?
• Nếu bạn làm như vậy, bạn có bất kỳ quyền kiểm soát nào đối với cách các nhật ký máy chủ Web được tạo, lưu trữ, v.v. không?

Lý do cho những câu hỏi này là vì nhìn chung có HAI loại dịch vụ Web sẵn có cho mọi người. Họ có thể có máy chủ của riêng mình hoặc họ có thể đang sử dụng máy chủ của người khác. Loại thứ hai được gọi là lưu trữ và bạn có thể trả tiền cho nhà cung cấp dịch vụ lưu trữ để thiết lập và duy trì máy chủ Web cho bạn. Rất thường xuyên, đây là những dịch vụ được chia sẻ. Bạn có thể lưu trữ với GoDaddy, Digital Ocean, Media Temple, v.v.

Nếu bạn có trang web của riêng mình, mọi thứ phức tạp hơn. Nhưng điều đó cũng có thể có nghĩa là bạn là một người am hiểu về công nghệ, bởi vì việc thiết lập một máy chủ Web hoàn toàn không phải là chuyện nhỏ.

Nếu bạn đang trả tiền cho một công ty lưu trữ để cung cấp cho bạn cơ sở hạ tầng nhằm thiết lập blog của riêng bạn, thì toàn bộ trách nhiệm đối với GDPR không chỉ thuộc về bạn. Nhà cung cấp dịch vụ lưu trữ của bạn cũng có trách nhiệm vì họ có quyền kiểm soát cơ sở hạ tầng.

Nếu bạn không có quyền truy cập vào nhật ký máy chủ, đây không phải là vấn đề của bạn. Nếu bạn có quyền truy cập - một số nhà cung cấp dịch vụ lưu trữ cho phép người dùng của họ truy cập hạn chế - bạn có quyền kiểm soát nào không? Rất có thể, bạn sẽ không thể xóa bất kỳ dữ liệu nào khỏi các nhật ký này hoặc thay đổi nội dung và cách thức được ghi. Xin nhắc lại, điều này chủ yếu là vì lý do bảo mật và điều đó không sao cả.

Nhưng sau đó, bạn có đang sử dụng nhật ký máy chủ Web không?

Bạn có thể không tạo được nhật ký máy chủ - hoặc quyết định những gì sẽ xảy ra với chúng - nhưng nhà cung cấp dịch vụ lưu trữ của bạn có thể đã cấp cho bạn quyền truy cập đọc. Một số blogger sử dụng các công cụ tự động như AWStats để phân tích số liệu thống kê của máy chủ Web. Trình phân tích nhật ký nguồn mở này có thể đọc và phân tích dữ liệu từ nhật ký máy chủ Web để tạo biểu đồ và biểu đồ lưu lượng truy cập hàng giờ, hàng ngày, hàng tuần, hàng tháng, hiển thị số lượt truy cập và thời lượng truy cập, tên miền, quốc gia, lưu lượng truy cập hàng đầu, v.v. những thứ khác, AWStats cũng sẽ đọc và phân tích địa chỉ IP.

Nếu bạn đang làm như vậy, thì bạn đang xử lý dữ liệu cá nhân - và do đó, bạn cần phải tuân thủ GDPR.

AWStats là một ví dụ điển hình, bởi vì nó là một công cụ phổ biến. Nhưng nó cũng mở ra một loạt các câu hỏi tiếp theo. Nếu bạn đang xử lý dữ liệu cá nhân, bạn có những biện pháp bảo vệ nào xung quanh việc bảo vệ dữ liệu? Bạn có chia sẻ số liệu thống kê trang web của mình một cách công khai không?

AWStats đơn giản và thân thiện - nhưng chẳng hạn, nó lưu trữ dữ liệu dưới dạng văn bản thuần túy. Đây có thể là một vấn đề, vì GDPR quy định các cơ chế bảo vệ dữ liệu và quyền riêng tư nâng cao. Chúng tôi đã đề cập đến tính năng ẩn danh và mã hóa, còn AWStats không đáp ứng được hai điều này.

Vì vậy, nếu bạn đang sử dụng một công cụ như AWStats (hoặc tương tự), bạn sẽ cần xem liệu chúng có tùy chọn có thể định cấu hình (tương đối dễ dàng) để bỏ chọn một số loại thông tin nhất định, chẳng hạn như địa chỉ IP và liệu dữ liệu được phân tích cú pháp có thể được giữ trong các tập tin được mã hóa. Nếu không, bạn KHÔNG nên phân tích nhật ký máy chủ Web, nếu bạn có quyền truy cập vào chúng, bởi vì khi đó bạn đang chuyển một phần trách nhiệm GDPR chỉ từ tay nhà cung cấp dịch vụ lưu trữ sang của riêng bạn. Không vui chút nào, nhưng lát nữa chúng ta sẽ nói về các loại thống kê trang web khác.

Đang tải trang

Khi bạn đã kết nối với máy chủ, bạn sẽ nhận được trang và nó sẽ hiển thị trong trình duyệt của bạn. Bây giờ hãy nhìn nó từ một hướng khác. Người dùng sẽ kết nối với trang web của bạn và nó sẽ hiển thị trong trình duyệt của họ. Nếu bạn không biết trang web của mình đang làm gì, giờ đây bạn có thể làm việc từ trên xuống để cố gắng tìm hiểu điều gì đang xảy ra trong nền.

Mỗi trang Web được hiển thị đều có phần hiển thị (những gì bạn nhìn thấy) và phần không nhìn thấy - Các chỉ thị và khai báo ngôn ngữ web cũng như các tập lệnh khác nhau. Các trang web được viết bằng ngôn ngữ HTML/CSS và chúng thường tải các tập lệnh được viết bằng ngôn ngữ Javascript.

Bạn có thể theo dõi việc tải bất kỳ trang nào trong trình duyệt của mình bằng các công cụ dành cho nhà phát triển nâng cao trong các trình duyệt hiện đại. Chẳng hạn, cả Firefox và Chrome đều cung cấp những công cụ này. Nhấp chuột phải> Kiểm tra. Thao tác này sẽ mở ra một trang riêng chứa đầy nội dung công nghệ, bao gồm bảng điều khiển có thể hiển thị chuỗi tài nguyên được tải. Đây là phần phụ trợ của các trang của bạn và nó hoàn toàn khác với phần hiển thị.

Xin lưu ý:nếu bạn chưa bao giờ làm điều này, nhiệm vụ giải mã luồng thực thi trang web của bạn sẽ không dễ dàng. Nếu bạn không am hiểu về công nghệ, bạn sẽ gặp khó khăn. Tuy nhiên, nếu bạn muốn tuân thủ GDPR, bạn cần biết trang web của mình đang làm gì để quyết định xem quy định có áp dụng cho bạn hay không. Nếu bạn đã biết thì thật tuyệt vì khi đó bạn muốn tập trung vào dữ liệu thực tế.

Tôi sẽ cung cấp cho bạn trang web của riêng tôi làm ví dụ. Đây không phải là ví dụ tốt nhất hoặc tiêu biểu nhất, bởi vì dedoimedo.com phần lớn là một trang web tĩnh không có tương tác với người dùng. Tôi không có bất kỳ người dùng đã đăng ký nào, tôi không sử dụng bình luận và phần trao đổi dữ liệu rất hạn chế. Tuy nhiên, tôi tin rằng đây là một bài tập hữu ích, bởi vì ngay cả một trang web có vẻ vô tội cũng có thể có một số vectơ thu thập dữ liệu cần được tính đến.

Nhìn vào quá trình tải trang của tôi, thông thường, luồng (cả yếu tố hiển thị và không hiển thị) sẽ giống như thế này (đừng lo lắng về các chi tiết cụ thể vào lúc này, chúng ta sẽ nói chi tiết về những yếu tố có liên quan):

• Đầu trang (tiêu đề, mô tả, v.v.).
• Google Analytics (phân tích lưu lượng truy cập trang web).
• Công cụ Tìm kiếm Tùy chỉnh của Google (cho phép mọi người tìm kiếm nội dung trên trang web của tôi).
• Nội dung chính (văn bản và hình ảnh của bài viết, giống như những gì bạn đang đọc bây giờ).
• Google Adsense (các khối quảng cáo được đặt trong dòng).
• Thêm nội dung chính (nhiều văn bản và hình ảnh ngọt ngào hơn).
• Nút Share This (nút chia sẻ cho phép mọi người chia sẻ nội dung của tôi lên mạng xã hội).
• Nội dung phù hợp (chạy mã Google hiển thị các bài viết có liên quan từ trang web của tôi và một số quảng cáo của Google).
• Tập lệnh Kiểm soát cookie (tiểu dụng lớp phủ cho phép người dùng chọn có đặt cookie hay không).

Google Analytics

Ghi nhật ký máy chủ Web? Chà, một số người có thể có hoặc không có quyền truy cập, một số có thể có hoặc không có kiến ​​thức kỹ thuật cần thiết để thiết lập các công cụ phân tích thủ công. Đó là nơi Google Analytics xuất hiện. Đây có lẽ là công cụ thống kê lưu lượng truy cập trang web phổ biến nhất hiện có. Việc cấu hình rất đơn giản - bạn chỉ cần thêm một đoạn mã vào mỗi trang web là xong! Bạn thắng và Google thắng vì họ thích dữ liệu.

Google Analytics cung cấp một số loại mã. Trước đây, Google Analytics dựa trên một công cụ có tên là Urchin và đoạn mã bạn đã thêm vào các trang của mình phản ánh điều này. Sau đó, vài năm trước, Google đã ngừng sử dụng Urchin, mặc dù chức năng này vẫn hoạt động (hiện tại) để tương thích ngược với các trang web vẫn đang sử dụng nó. Người kế nhiệm Urchin là Universal Analytics. Gần đây hơn, Google cũng đã giới thiệu Thẻ trang web toàn cầu, cung cấp các tính năng bổ sung và khả năng đo lường trang web. Sau đó, có một số phương pháp khác nữa. Ba đoạn mã chính trông như sau.

Universal Analytics (analytics.js):

Thẻ trang web toàn cầu (gtag.js):

Đây là những đoạn mã mặc định và để chúng hoạt động, bạn cần thay đổi các chữ cái xxxxxx bằng mã Google Analytics của mình. Theo mặc định, Google Analytics đặt cookie và thu thập một số thông tin. Vì vậy, chúng ta cần hiểu:a) cookie là gì? b) thông tin được thu thập có mang tính cá nhân không?

Để trả lời câu hỏi đó, chúng ta cần tập trung vào hai điều:mã bạn chạy và nội dung xảy ra bên trong Google Analytics. Câu trả lời đơn giản là:theo mặc định, Google Analytics không được định cấu hình cho bất kỳ phân tích dữ liệu cá nhân nào ngoài địa chỉ IP. Thật vậy, Google đã nỗ lực rất nhiều để làm cho các công cụ của họ tuân thủ GDPR và điều này được phản ánh trong các tùy chọn có sẵn bên trong bảng điều khiển quản trị viên Google Analytics. Hãy bắt đầu với điều đó.

Việc thu thập dữ liệu cá nhân bao gồm một số vectơ - và nếu bạn sử dụng các vectơ này, bạn cần thông báo cho người dùng EU của mình và xin phép họ (sự đồng ý) để thu thập dữ liệu. Điều này có nghĩa là việc thực thi tập lệnh phân tích phụ thuộc vào lựa chọn của người dùng. Nói cách khác, nếu ai đó không muốn thu thập dữ liệu cá nhân của họ, tập lệnh phân tích sẽ không chạy và bạn sẽ không thu thập được BẤT KỲ thống kê nào về người dùng cụ thể đó.

Vì vậy, bạn có một sự lựa chọn:

1. Thu thập dữ liệu cá nhân đang chờ sự đồng ý của người dùng; có thể thu ít hơn (về mặt lý thuyết là không thu được gì từ EU).
2. Không thu thập dữ liệu cá nhân - trong trường hợp đó, các điều khoản GDPR không áp dụng.

Google Analytics &dữ liệu cá nhân

Bạn có thể chạy Google Analytics như một công cụ thống kê lưu lượng truy cập trang web phi cá nhân. Điều này có nghĩa là bạn sẽ có thông tin về số lượt truy cập và trang, lưu lượng truy cập thời gian thực và một số số liệu khác, nhưng bạn sẽ không có bất kỳ thông tin gì về người dùng của mình. Trước tiên, hãy xem bạn cần làm gì trực tuyến trong bảng điều khiển Google Analytics. Google có Câu hỏi thường gặp rất chi tiết giải thích những gì bạn có thể và không thể làm - và phải làm.

Google Analytics cho phép bạn sử dụng quảng cáo và tiếp thị lại =dữ liệu cá nhân. Bạn có thể tắt chúng.

Bạn cần đặt chính sách lưu giữ (dữ liệu cũ sẽ bị xóa). Điều này có nghĩa là bạn sẽ không thể thực hiện phân tích dựa trên dữ liệu lịch sử cũ (trước khoảng thời gian lưu giữ đã đặt), nhưng một lần nữa, điều này giúp giảm thiểu khối lượng xử lý dữ liệu, đó là điều chúng tôi muốn (dù sao cũng không liên quan nếu bạn làm theo phần tiếp theo bước bên dưới). Tuy nhiên, tốt nhất bạn nên thận trọng và có ý thức về quyền riêng tư.

Sau đó, cũng có bước User-ID. Google đã cấm sử dụng bất kỳ dữ liệu nào có thể nhận dạng mọi người, nhưng nếu bạn sử dụng tính năng này, bạn sẽ cần phải xin phép. Do đó, tính năng này cần được tắt.

Bạn cũng nên đảm bảo không có bất kỳ thứ nguyên và chỉ số tùy chỉnh nào có khả năng nhận dạng mọi người. Bởi vì nếu bạn có những thứ đó, thì bạn đang chuyển từ không gian phi cá nhân sang không gian cá nhân. Một lần nữa, bạn có những thứ đó cũng không sao, nhưng đó là một chủ đề riêng biệt. Hiện tại, chúng tôi đang tập trung vào việc thu thập dữ liệu phi cá nhân, ẩn danh bằng cách sử dụng Google Analytics.

Điều này bao gồm phần trực tuyến trong bảng điều khiển. Nhưng chúng ta vẫn chưa nói về địa chỉ IP và cookie. Vì vậy, trước đây là rõ ràng. Bây giờ, bánh quy ...

Cookie là các tệp văn bản được lưu trữ cục bộ trên máy tính của bạn và được các trang web sử dụng để tạo tính liên tục cho hoạt động trực tuyến của bạn. Hãy coi cookie là các tệp nhật ký nhỏ cho các trang web biết về lần truy cập cuối cùng của bạn, thông tin đăng nhập của bạn, v.v. Đó là cách để các trang web có thể nhớ đến bạn, chẳng hạn như khi bạn quay lại và bạn vẫn đăng nhập. Trang web có thể đặt cookie và chúng sẽ có ngày hết hạn, sau đó cookie sẽ bị xóa và nội dung của chúng sẽ bị xóa, tức là lịch sử hoạt động của bạn đối với trang web sẽ bị xóa.

Về mặt kỹ thuật, một số thông tin được lưu trữ trong cookie có thể có khả năng nhận dạng mọi người, điều đó có nghĩa là bạn cần yêu cầu người dùng đồng ý để đặt cookie. Nếu họ không đồng ý thì không được đặt cookie.

Vì vậy, nếu bạn muốn có thể chạy Google Analytics mà không cần bất kỳ hoạt động thu thập dữ liệu cá nhân nào, bạn cần tắt cookie và chúng tôi cũng cần xử lý phần địa chỉ IP - ngoài tất cả công việc trực tuyến.

Google Analytics &bộ nhớ cục bộ (cookie)

Phần công cụ dành cho nhà phát triển dành cho Google Analytics chứa rất nhiều thông tin, bao gồm các cài đặt để tắt lưu trữ cục bộ, nghĩa là sẽ không có cookie nào được đặt. Thật vậy, đối với Universal Analytics, bạn cần thay đổi dòng sau:

ga('tạo', 'UA-xxxxxx', 'tự động');

Về điều này:

ga('tạo', 'UA-xxxxxx', { 'lưu trữ':'không' });

Và sau đó, không có cookie nào được đặt.

Ẩn danh địa chỉ IP

Google Analytics nắm bắt địa chỉ IP =thông tin cá nhân. Nhưng bạn có thể ẩn danh địa chỉ IP. Bằng cách này, địa chỉ IP trông giống như aaa.bbb.ccc.ddd sẽ trở thành aaa.bbb.ccc.0. Không đi sâu vào chi tiết kỹ thuật, điều này sẽ làm cho mã định danh duy nhất (địa chỉ IP) giống với 254 địa chỉ khả dụng cho phân đoạn cuối cùng (octet) của địa chỉ, khiến cho sự hiện diện trên Internet của người dùng thông qua địa chỉ IP mà Google Analytics nhìn thấy là ẩn danh. Điều này được thực hiện bằng cách thêm một dòng trước khi sự kiện Google Analytics được gửi đến máy chủ. Thêm dòng sau vào sau dòng "tạo" và dòng "gửi" (Universal Analytics):

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

Đại loại như thế này:

ga('tạo', 'UA-xxxxxx', { 'lưu trữ':'không' });
ga('set', 'anonymizeIp', true);
ga('send', 'pageview');

Và bây giờ bạn có bộ sưu tập dữ liệu ẩn danh, phi cá nhân thông qua Google Analytics.

Nhược điểm của phương pháp này là bạn sẽ không biết gì về lòng trung thành của người dùng. Tỷ lệ thoát của bạn (có bao nhiêu người đến trang web của bạn chỉ để xem một trang rồi rời đi) sẽ tăng lên 100% và thời lượng phiên trung bình (thời gian dành cho trang web) sẽ giảm xuống 0 giây. Nhưng không sao cả, vì đó CHÍNH XÁC là điều chúng ta muốn. Chúng tôi chỉ muốn dữ liệu lưu lượng truy cập tổng hợp, phi cá nhân.

Nếu bạn muốn thu thập một số dữ liệu (hoặc sử dụng cookie) thì sao?

Trong trường hợp đó, bạn cần làm cho việc tải tập lệnh Google Analytics phụ thuộc vào sự đồng ý rõ ràng của người dùng. Và với mục đích đó, bạn cần một số loại công cụ (thực sự là một tập lệnh khác) sẽ chặn việc thực thi Google Analytics và cài đặt cookie cho đến khi (và nếu) người dùng đồng ý.

Tôi đã quyết định triển khai Kiểm soát cookie công dân, một công cụ được thiết kế đặc biệt để cung cấp việc tuân thủ cookie đáp ứng các yêu cầu GDPR. Công cụ này, cũng như một số công cụ khác được liệt kê trên Google Cookie Choices. Sau khi thử nghiệm một số giải pháp có sẵn, tôi quyết định đây là công cụ thích hợp nhất cho nhu cầu của mình.

Điều tôi thích (ngoài các bit kỹ thuật rõ ràng) về Kiểm soát cookie là phiên bản PRO cho phép bạn lọc ra các quốc gia không thuộc EU, do đó, applet không được hiển thị cho những người dùng không bị ảnh hưởng bởi GDPR. Nói cách khác, bạn có thể hiển thị có chọn lọc cho người dùng của mình tiểu dụng chấp thuận cookie. Mặc dù có một phiên bản miễn phí, nhưng nó bị hạn chế hơn và phiên bản PRO không hề rẻ, điều này quay trở lại với những gì tôi đã đề cập lúc đầu:Việc tuân thủ GDPR có thể tốn tiền, thời gian và yêu cầu chuyên môn mà hầu hết các blogger hoặc chủ sở hữu trang web cá nhân có thể không có .

Tôi đã triển khai Kiểm soát cookie trên mọi trang trên trang web của mình - bạn có thể chọn từ ngữ, kiểu dáng và tạo các danh mục cần thiết. Quan trọng nhất, đối với mỗi danh mục, bạn có hai chức năng:onAccept và onRevoke. Cái trước sẽ chạy một số mã (và đặt cookie) CHỈ nếu người dùng có sự đồng ý. Và cái sau sẽ xóa cookie và có thể dừng tập lệnh nếu không có sự đồng ý. Cấu hình chính xác của công cụ cụ thể này nằm ngoài phạm vi của bài viết này.

Vì vậy, nếu bạn muốn chạy Google Analytics + cookie trên mọi trang, thì với một công cụ như Kiểm soát cookie, ở Liên minh Châu Âu, phần khai báo sẽ giống như (sử dụng Universal Analytics làm ví dụ của chúng tôi):

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(arguments)},i[r].l=1*new Date();a=s. createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertB Before(a,m)
})( cửa sổ,tài liệu,'script','https://www.google-analytics.com/analytics.js','ga');

ga('tạo', 'UA-xxxxxx', 'tự động');
ga('send', 'pageview');
},
onRevoke:function(){
window['ga-disable-UA-xxxxxx'] =true;
}

Tập lệnh Kiểm soát cookie được khai báo trên mọi trang trên trang web của tôi - tập lệnh này kiểm soát nội dung của bên thứ ba khác, không phải Google Analytics, vì tôi đã chọn lộ trình ẩn danh, phi cá nhân. Mã được thêm vào trên mỗi trang trông giống như thế này (Tôi đặt mã thành một dòng vì nó giúp tìm kiếm và thay thế dễ dàng hơn nếu cần):

Đọc Google Analytics bổ sung

Có nhiều hơn nữa trong phần tài nguyên, nhưng đây là một số điều bổ sung mà bạn có thể muốn xem xét. Và bằng cách cân nhắc, ý tôi là thông báo cho người dùng của bạn rằng họ có lựa chọn làm cho trình duyệt của họ trở nên riêng tư hơn và từ chối thu thập dữ liệu, không chỉ trên trang web của bạn mà nói chung.

Tiện ích bổ sung chọn không tham gia trình duyệt Google Analytics

Công cụ Tìm kiếm Tuỳ chỉnh của Google

Công cụ Tìm kiếm Tùy chỉnh của Google (CSE) là một đoạn mã mà bạn có thể thêm vào các trang của mình, cho phép mọi người tìm kiếm nội dung trên trang web của bạn và/hoặc trên toàn cầu. Về mặt trực quan, nó sẽ tạo ra một hộp tìm kiếm và mọi người có thể sử dụng nó giống như bất kỳ tìm kiếm nào khác của Google. Ở đây, chúng ta cần tự hỏi:có liên quan đến việc thu thập dữ liệu cá nhân không?

Bây giờ, phần phức tạp, Google CSE cũng có thể hiển thị quảng cáo - và điều này liên quan đến Google Adsense, điều mà chúng ta vẫn chưa nói đến. Nhưng nói chung, Google CSE có thể được coi là một tính năng quảng cáo, bởi vì nó thực sự được tạo thông qua bảng điều khiển Google Adsense. Vì vậy, chắc chắn có khía cạnh dữ liệu cá nhân - và cookie. Chúng tôi biết cách xử lý cookie. Chúng ta cần nói về quảng cáo.

Google Adsense

Google Adsense có lẽ là mạng quảng cáo phổ biến nhất trên thế giới. Một lần nữa, giống như hầu hết các công cụ khác của Google, nó rất đơn giản để sử dụng. Bạn chỉ cần thêm các đoạn mã vào các trang của mình và khi người dùng đến và truy cập, họ có thể thấy quảng cáo được hiển thị. Một lần nữa, chúng tôi cần hỏi, chúng tôi có đang xử lý dữ liệu cá nhân không?

Có hai loại quảng cáo - phi cá nhân (chỉ là nội dung ngẫu nhiên) và cá nhân (được nhắm mục tiêu cụ thể đến người dùng dựa trên hành vi trước đây của họ và số liệu đã thu thập). Nếu bạn cho phép quảng cáo cá nhân qua Google Adsense trên trang web của mình, bằng proxy, bạn sẽ xử lý dữ liệu cá nhân. Nhưng việc đồng ý chạy các tập lệnh Google Adsense khó hơn nhiều so với Google Analytics. Thứ nhất, vị trí đặt quảng cáo rất quan trọng, không giống như phân tích, nơi bạn chỉ cần đặt mã ở bất kỳ đâu và người dùng không nhìn thấy hành động đó. Hai là, nếu người dùng không đồng ý, thì quảng cáo sẽ không chạy và hiển thị, đồng thời, sự đồng ý sẽ trở thành một công cụ chặn quảng cáo, đồng nghĩa với việc nhà xuất bản sẽ có ít doanh thu hơn.

Google đã nhận ra điều này, vì vậy họ nhận thấy rằng họ cần cung cấp một công cụ TRUNG TÂM cho phép người dùng của họ định cấu hình cách phân phát quảng cáo cho người dùng ở Liên minh Châu Âu. Thật vậy, ngay trước thời hạn thực thi GDPR vào ngày 25 tháng 5, Google đã giới thiệu một phần riêng trong bảng điều khiển Adsense, cho phép chỉ phân phát quảng cáo phi cá nhân cho người dùng EU. Đây là cách lý tưởng để MỌI công cụ và dịch vụ xử lý vấn đề này, tiếc là không phải lúc nào cũng có thể thực hiện được.

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). Không vấn đề gì. 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. Nhưng mà. 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. Wait. Không hoảng loạn. 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. Hãy suy nghĩ về nó. 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. Ví dụ:

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