Tuân Thủ GDPR Cho Website: Hướng Dẫn Thực Tế Về Quyền Riêng Tư & Niềm Tin

Hôm qua bạn còn là một blogger tự do. Hôm nay, bỗng nhiên phải đối mặt với "cái khổng lồ" tên là GDPR. EU ban hành quy định tập trung vào quyền riêng tư này, quy định yêu cầu quan trọng về bảo mật, minh bạch dữ liệu cho website xử lý dữ liệu cá nhân. Bạn tự hỏi: "Điều này ảnh hưởng đến tôi không?" Và bạn lo lắng. Bài viết hôm nay sẽ giúp bạn hiểu rõ ai, gì, khi nào, như thế nào – hy vọng trang bị kiến thức & công cụ để bạn vừa lại là blogger tự do, vừa tuân thủ GDPR vui vẻ.

Câu hỏi thêm: tại sao xuất bản bài này sau khi quy định có hiệu lực? Thực tế, hầu hết công cụ/dịch vụ chỉ phát hành bản cập nhật tuân thủ GDPR trong tuần vừa qua, mới cho phép tôi hoàn thiện hướng dẫn này. Hãy cùng xem có gì.

Tuân Thủ GDPR Cho Website: Hướng Dẫn Thực Tế Về Quyền Riêng Tư & Niềm Tin

Mục Lục

Miễn Trừ Trách Nhiệm (Disclaimer)
GDPR Trong 60 Giây
1. Nếu bạn đang xử lý dữ liệu cá nhân?
2. Không chỉ về tiền phạt
Theo Dõi Luồng Dữ Liệu
1. Kết nối đến website
2. Tải trang
Google Analytics
1. GA & dữ liệu cá nhân
2. GA & local storage (cookie)
3. Ẩn danh IP
4. Nếu muốn thu thập dữ liệu/dùng cookie?
5. Đọc thêm về GA
Google Custom Search Engine
Google Adsense
Nút ShareThis
Matched Content
Các Loại Dữ Liệu Khác
1. Form/nút thương mại điện tử (PayPal)
2. Đăng ký người dùng
3. Bình luận
4. Email (và mailing list)
5. Video nhúng (YouTube)
6. Script nhúng
CMS: WordPress
1. Thu thập dữ liệu = plugin
2. Google Analytics
3. Bình luận (Disqus)
4. Kiểm soát script chung
5. Session cookie
6. WordPress 4.9.6 – thay đổi GDPR
Sao Lưu Dữ Liệu (Data Backups)
Công Cụ Mã Hóa (Encryption Tools)
Văn Bản Hướng Dẫn (Documentation)
Kết Luận
Tài Nguyên (Resources)

Miễn Trừ Trách Nhiệm

Một số làm rõ quan trọng:

Tôi không phải luật sư, bài viết này không phải tư vấn pháp lý dưới bất kỳ hình thức nào.

Tôi có thể sai hoặc hiểu lầm – đừng tin mù thông tin dưới đây.

Bài viết dành cho cá nhân vận hành website/blog, không phải doanh nghiệp.

GDPR Trong 60 Giây

Nếu chưa nghe về GDPR, đây là tóm tắt siêu ngắn. Quy định Bảo vệ Dữ liệu Chung (GDPR) là quy định mới của EU về bảo vệ dữ liệu & quyền riêng tư. Có hiệu lực từ 25/5/2018. Mục đích: tăng cường minh bạch & quyền lựa chọn về xử lý dữ liệu cá nhân của công dân/cư trú EU/EEA. Yêu cầu doanh nghiệp có biện pháp bảo vệ & làm rõ cách thu thập, lưu trữ, sử dụng dữ liệu cá nhân. Nhấn mạnh: Cá nhân. Không phải cá nhân = không vấn đề.

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

Câu trả lời KHÔNG hề tầm thường.

Nếu Bạn Đang Xử Lý Dữ Liệu Cá Nhân?

Trước khi trả lời có/không, hãy giả định "có" một chút.

GDPR không cấm xử lý dữ liệu – nó yêu cầu minh bạch & bảo vệ thêm. Tức là bạn phải:

Cần biết (Need to know) – nếu xử lý dữ liệu, phải có lý do.
Quyền riêng tư – nếu xử lý, hãy làm cho nó kém "cá nhân" hơn.
Bảo mật – nếu xử lý, phải an toàn.

Đọc mạng thấy nhiều người phẫn nộ về xử lý dữ liệu, cho rằng nó sai và phải tránh. Cách tiếp cận đúng: tránh xử lý dữ liệu dư thừa, không cần thiết.

Nếu bạn cần một số dữ liệu cá nhân cụ thể, bạn cần chúng. Đó là bình thường. Nếu bạn có lợi ích kinh doanh hợp pháp, bạn 행使 chúng. Vấn đề là GDPR ra đời vì nhiều doanh nghiệp lạm dụng dữ liệu cá nhân KHÔNG có nhu cầu cốt lõi thực sự – đó là nguyên nhân các scandal quyền riêng tư. Ví dụ: bạn kinh doanh ống nước. Bạn cần biết tuổi, sở thích khách hàng? Không. Nhưng nếu bán áo, bạn cần giới tính, tuổi, địa chỉ giao hàng? Có, bạn cần.

Nếu xử lý dữ liệu, hãy minh bạch (cần biết). Và bảo vệ nó. Trong bài này tôi dùng khái niệm ẩn danh hóa (anonymization) (làm cho dữ liệu cá nhân thành không cá nhân) và mã hóa (encryption) (làm dữ liệu ít nhìn thấy/tiếp cận được).

Không Chỉ Về Tiền Phạt

Đây là yếu tố "nóng" khác. Tiền phạt nặng. Con số đáng sợ. Nhưng tập trung vào chúng là sai lầm. Bạn không đọc luật và hình phạt rồi quyết định làm đúng/sai. Bạn không tránh trộm cắp chỉ vì tù giam lâu. Bạn không làm vì nó sai. Tương tự đây. Đừng tuân thủ GDPR vì sợ phạt. Hãy coi đó là cơ hội xây dựng sự hiện diện trực tuyến tốt hơn, minh bạch hơn.

Quá trình đó có thể đau đớn, tốn kém – quay lại câu hỏi cốt lõi: dữ liệu cá nhân. Bạn có đang xử lý nó không?

Theo Dõi Luồng Dữ Liệu

Cần làm rõ vài cấp độ để trả lời câu hỏi trên:

Điều gì được coi là dữ liệu cá nhân?
Website bạn có cơ chế thu thập dữ liệu cá nhân không?

Câu 1 cũng không tầm thường. Dữ liệu cá nhân là bất cứ thứ gì có thể xác định một người. Như thuật ngữ pháp lý, định nghĩa mơ hồ. Cách tốt nhất: nếu không chắc, hoặc nghi ngờ, hãy giả định thông tin "mơ hồ" đó CÓ THỂ dùng làm dữ liệu cá nhân.

Ví dụ điển hình: địa chỉ IP. Về mặt kỹ thuật, đây giống số điện thoại – số định danh thiết bị, cho phép máy tính giao tiếp. Vì vậy, dưới một số trường hợp, nó CÓ THỂ dùng để xác định người, giống như số điện thoại truy vết được hợp đồng/hóa đơn.

Địa chỉ IP cũng là một phần không tách rời của giao tiếp Internet. Đây là nơi xung đột giữa công nghệ và pháp luật nảy sinh. Chính vì vậy quy định quyền riêng tư (hoặc cần) phải mơ hồ. Tạo ra đau đầu, lo lắng, nhất là người không rành kỹ thuật. Hôm qua chỉ muốn chia sẻ công thức nấu ăn. Hôm nay phải suy nghĩ về địa chỉ IP.

Điều này dẫn đến câu hỏi 2. Hầu hết blogger không tự thiết lập hạ tầng, dùng nền tảng của người khác – blog platform, web do thầu xây... Có thể không biết gì xảy ra ở hậu trường.

Vì vậy chúng ta phải theo dõi dấu vết dữ liệu.

Nếu muốn biết GDPR có áp dụng cho site/blog bạn – và nếu có, cần làm gì để tuân thủ – hãy theo dõi hành trình traffic Internet: từ người dùng tò mò đến site của bạn.

Kết Nối Đến Website

Khi bạn truy cập website (ví dụ dedoimedo.com), trình duyệt dùng "danh bạ Internet" (DNS) tìm địa chỉ, rồi liên hệ địa chỉ đó. Nếu cấu hình OK, phần mềm Web server chấp nhận yêu cầu và trả về trang web.

Khi khởi tạo kết nối đến Web server, trình duyệt gửi thông tin cần thiết: địa chỉ IP, hệ điều hành, phiên bản trình duyệt, dữ liệu thêm. Mỗi trình duyệt có "chữ ký" riêng (user agent) giúp Web server cung cấp nội dung tốt nhất.

Web server ghi log kết nối vào data logs. Thường bắt buộc vì: 1) an ninh (cần dấu vết nếu hack, gian lận) 2) sự cố kỹ thuật 3) cân bằng traffic 4) tuân thủ & kiểm toán.

Đã nhắc IP. Vậy đã có một thông tin cá nhân được ghi log ⇒ GDPR áp dụng. Nhưng đừng vội. Cần hiểu rõ hơn qua các câu hỏi:

Bạn có quyền truy cập log Web server không?
Nếu có, bạn có kiểm soát cách log được tạo, lưu trữ không?

Lý do: có 2 loại dịch vụ Web rộng rãi. Tự host server, hoặc dùng server của người khác (hosting – trả tiền cho provider như GoDaddy, Digital Ocean, Media Temple...). Thường là shared service.

Nếu tự host, mọi thứ phức tạp hơn, nhưng có nghĩa là bạn rành kỹ thuật (setup server không hề tầm thường).

Nếu thuê hosting, trách nhiệm GDPR không chỉ của bạn. Provider cũng có trách nhiệm vì họ kiểm soát hạ tầng.

Nếu KHÔNG có quyền truy cập log server ⇒ không phải lo ngại của bạn. Nếu CÓ quyền truy cập (một số provider cho phép truy cập hạn chế) – bạn có kiểm soát không? Có thể bạn KHÔNG thể xóa dữ liệu từ log hoặc thay đổi nội dung log. Lại vì lý do an ninh, và điều đó ổn.

Nhưng rồi, bạn có đang SỬ DỤNG log Web server không?

Bạn có thể không tạo log – hoặc quyết định nội dung log – nhưng provider có thể cho bạn quyền đọc. Một số blogger dùng công cụ tự động như AWStats để phân tích thống kê server. Công cụ open-source này đọc & parse dữ liệu từ log để tạo biểu đồ traffic theo giờ/ngày/tuần/tháng, số lượt truy cập, thời gian, domain, quốc gia, top traffic... Trong số đó, AWStats cũng đọc & parse địa chỉ IP.

Nếu bạn làm vậy ⇒ bạn đang xử lý dữ liệu cá nhân ⇒ cần tuân thủ GDPR.

AWStats là ví dụ tốt vì phổ biến. Nhưng nó mở ra hàng loạt câu hỏi tiếp theo. Nếu xử lý dữ liệu cá nhân, bạn có biện pháp bảo vệ dữ liệu nào? Bạn có công khai thống kê site không?

AWStats đơn giản, thân thiện – nhưng lưu dữ liệu dưới dạng plain text. Điều này có thể gây vấn đề, vì GDPR yêu cầu cơ chế bảo vệ & quyền riêng tư nâng cao. Chúng ta đã nói đến ẩn danh hóa & mã hóa – AWStats KHÔNG đáp ứng cả hai.

Vì vậy, nếu dùng AWStats (hoặc tương tự), bạn cần xem có tùy chọn cấu hình dễ dàng để loại bỏ thông tin nhất định (như IP), và dữ liệu parse có thể lưu dưới dạng file mã hóa không. Nếu không ⇒ KHÔNG nên phân tích log Web server, vì bạn đang chuyển một phần trách nhiệm GDPR từ provider sang mình. Không vui, nhưng chúng ta sẽ nói về thống kê site khác sau.

Tải Trang (Loading a Page)

Khi đã kết nối server, bạn nhận trang và hiển thị trên trình duyệt. Nhìn từ phía ngược: user kết nối site bạn, trang hiển thị trên trình duyệt họ. Nếu bạn không biết site mình đang làm gì, hãy làm việc top-down để tìm hiểu background.

Mọi trang web có phần hiển thị (thấy được) và phần vô hình – chỉ thị ngôn ngữ web, khai báo, script. Trang web viết bằng HTML/CSS và thường load script JavaScript.

Bạn có thể theo dõi tải trang bằng dev tools trình duyệt hiện đại (Firefox, Chrome: Right-click > Inspect). Mở ra trang riêng đầy "tech stuff", bao gồm console hiển thị trình tự resource load. Đây là backend của trang, hoàn toàn khác phần hiển thị.

Lưu ý: nếu chưa bao giờ làm điều này, việc giải mã luồng thực thi site không dễ. Nếu không rành kỹ thuật, bạn sẽ gặp khó khăn. Tuy nhiên, nếu muốn tuân thủ GDPR, bạn CẦN biết site đang làm gì để quyết định quy định có áp dụng không. Nếu đã biết, tuyệt vời – tập trung vào dữ liệu thực tế.

Tôi lấy site của mình làm ví dụ. Không phải ví dụ tốt/đại diện nhất, vì dedoimedo.com chủ yếu là site tĩnh, ít tương tác user. Không có user đăng ký, không dùng comment, phần trao đổi dữ liệu rất hạn chế. Tuy nhiên tôi tin đây là bài tập hữu ích, vì ngay site "vô hại" cũng có thể có vài vector thu thập dữ liệu cần lưu ý.

Xem luồng tải trang (cả phần hiển thị & vô hình):

Page header (title, description...)
Google Analytics (phân tích traffic)
Google Custom Search Engine (tìm kiếm nội dung site)
Main content (bài viết, hình ảnh)
Google Adsense (quảng cáo inline)
More main content
ShareThis buttons (chia sẻ mạng xã hội)
Matched content (chạy code Google hiển thị bài liên quan + quảng cáo)
Cookie Control script (applet overlay cho user chọn cookie)

Google Analytics

Nhớ log Web server? Một số người có/không có quyền truy cập, có/không có kiến thức setup công cụ phân tích thủ công. Đó là lúc Google Analytics xuất hiện – công cụ thống kê traffic phổ biến nhất. Cấu hình đơn giản: thêm đoạn code vào mọi trang, xong! Bạn thắng, Google thắng (vì họ thích dữ liệu).

GA có vài loại code. Trước đây dựa trên Urchin (urchin.js). Sau vài năm Google ngừng hỗ trợ Urchin (chỉ giữ tương thích ngược). Kế nhiệm là Universal Analytics (analytics.js). Gần đây có Global Site Tag (gtag.js) với tính năng đo lường thêm. Ba đoạn code chính:

Urchin (urchin.js):
<script src="https://www.google-analytics.com/urchin.js" type="text/javascript"></script>
<script type="text/javascript">
_uacct = "UA-xxxxxx";
urchinTracker();
</script>

Universal Analytics (analytics.js):
<script>
(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.insertBefore(a,m)
})(window,document,'script','https://www.google-analytics.com/analytics.js','ga');

ga('create', 'UA-xxxxxx', 'auto');
ga('send', 'pageview');
</script>

Global Site Tag (gtag.js):
<script async src="https://www.googletagmanager.com/gtag/js?id=UA-xxxxxx"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());

gtag('config', 'UA-xxxxxx');
</script>

Đây là snippet mặc định. Để hoạt động, thay xxxxxx bằng mã GA của bạn. Mặc định GA set cookie & thu thập thông tin. Cần hiểu: a) cookie là gì? b) thông tin thu thập có phải dữ liệu cá nhân không?

Để trả lời, tập trung vào 2 điều: code bạn chạy & việc xảy ra bên trong GA. Câu trả lời đơn giản: mặc định GA không cấu hình phân tích dữ liệu cá nhân trừ địa chỉ IP. Google đã làm nhiều việc để công cụ tuân thủ GDPR, phản ánh trong các tùy chọn trong admin dashboard GA. Hãy bắt đầu từ đó.

Thu thập dữ liệu cá nhân xảy ra qua vài vector – nếu dùng chúng, bạn phải thông báo cho user EU & xin phép (consent) thu thập. Nghĩa là việc chạy script analytics phụ thuộc vào lựa chọn user. Nếu ai không muốn dữ liệu cá nhân được thu thập, script analytics sẽ không chạy, bạn sẽ KHÔNG có thống kê user đó.

Vì vậy bạn có 2 lựa chọn:

Thu thập dữ liệu cá nhân tùy theo consent user; có thể thu thập ít hơn (lý thuyết có thể 0 từ EU).
KHÔNG thu thập dữ liệu cá nhân – khi đó 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 GA như công cụ thống kê traffic KHÔNG cá nhân. Nghĩa là bạn có thông tin: số lượt truy cập/trang, real-time traffic, một số metric khác, nhưng KHÔNG có thông tin về user. Xem cần làm gì trong dashboard GA online. Google có FAQ chi tiết giải thích được/khi nào phải làm gì.

GA cho phép quảng cáo & remarketing = dữ liệu cá nhân. Tắt chúng đi.

Cần thiết lập chính sách lưu giữ (retention policy) – dữ liệu cũ sẽ bị xóa. Bạn không phân tích được dữ liệu lịch sử trước kỳ lưu giữ, nhưng giúp giảm thiểu xử lý dữ liệu (mục tiêu của chúng ta). Vẫn nên thận trọng, ý thức quyền riêng tư.

Bước User-ID. Google đã cấm dùng dữ liệu xác danh người, nhưng nếu bạn dùng tính năng này, cần xin consent ⇒ Tắt nó đi.

Đảm bảo KHÔNG có custom dimensions/metrics có thể xác danh người. Nếu có, bạn đang chuyển từ không cá nhân sang cá nhân. Đó là chủ đề riêng. Ở đây tập trung vào thu thập dữ liệu ẩn danh, không cá nhân qua GA.

Đây là phần online trong dashboard. Nhưng chưa nói đến IP & cookie. IP rõ ràng. Giờ nói cookie...

Cookie là file text lưu cục bộ trên máy tính, dùng bởi website để tạo sự liên tục hoạt động online. Hãy coi cookie như file log nhỏ nói cho web biết lần truy cập cuối, login... Cách để site "nhớ" bạn (ví dụ quay lại vẫn đăng nhập). Web có thể set cookie, có ngày hết hạn, sau đó cookie bị xóa, nội dung bị xoá, xóa lịch sử hoạt động đối với web đó.

Về mặt kỹ thuật, một số thông tin trong cookie có thể tiềm ẩn xác danh người ⇒ cần xin consent user để set cookie. Nếu không đồng ý, cookie KHÔNG được set.

GA set một vài cookie. Vì vậy cần xin phép user. Nhưng phức tạp hơn: ngay cả khi xin consent cho cookie ban đầu khi load trang, nếu GA được phép chạy, nó sẽ set cookie trong phiên duyệt web ⇒ thực tế bạn cần xin consent không chỉ set cookie mà cả chạy GA từ đầu. Quay lại thống kê site: nếu user không consent, lượt truy cập không được đếm (dù phần không cá nhân), bạn sẽ thấy ít traffic EU hơn trong thống kê.

Vì vậy, nếu muốn chạy GA KHÔNG thu thập dữ liệu cá nhân, bạn cần vô hiệu hóa cookie, và xử lý phần IP – ngoài tất cả công việc online trên.

Google Analytics & Local Storage (Cookie)

Phần developer tools của GA chứa nhiều thông tin, bao gồm cài đặt vô hiệu hóa local storage = không set cookie nào. Với Universal Analytics, thay dòng:

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

Thành:

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

Vậy là không cookie được set.

Ẩn Danh Địa Chỉ IP

GA thu thập IP = thông tin cá nhân. Nhưng bạn có thể ẩn danh IP. Làm như vậy, IP dạng aaa.bbb.ccc.ddd thành aaa.bbb.ccc.0. Không đi sâu kỹ thuật, điều này làm cho định danh duy nhất (IP) trùng với 254 địa chỉ có sẵn cho octet cuối, làm cho hiện diện Internet của user qua IP như được GA thấy trở nên ẩn danh. Thực hiện bằng cách thêm dòng trước khi gửi event GA. Thêm dòng sau 'create' và trước 'send' (Universal Analytics):

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

Ví dụ:

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

Bây giờ bạn có thu thập dữ liệu ẩn danh, không cá nhân qua GA.

Nhược điểm: bạn sẽ KHÔNG biết lòng trung thành user. Bounce rate (tỷ lệ thoát sau 1 trang) sẽ lên 100%, average session duration (thời gian trung bình) giảm về 0 giây. Nhưng đó chính xác là điều chúng ta muốn. Chỉ muốn dữ liệu traffic tổng hợp, không cá nhân.

Nếu Muốn Thu Thập Dữ Liệu (Hoặc Dùng Cookie)?

Lúc đó bạn cần làm việc load script GA phụ thuộc vào consent rõ ràng của user. Cần công cụ (script khác) chặn thực thi GA & set cookie cho đến khi (và nếu) user consent.

Tôi chọn Civic Cookie Control – công cụ thiết kế riêng cho tuân thủ cookie GDPR. Công cụ này và nhiều cái khác liệt kê trên Google Cookie Choices. Sau khi test một vài giải pháp, tôi thấy đây phù hợp nhất.

Điều tôi thích (ngoài kỹ thuật) ở Cookie Control: bản PRO cho phép lọc bỏ quốc gia non-EU, nên applet không hiển thị cho user không chịu ảnh hưởng GDPR. Tức là bạn có thể chọn lọc hiển thị applet consent cookie. Bản free tồn tại nhưng giới hạn, bản PRO không rẻ – quay lại điều tôi nói đầu: tuân thủ GDPR tốn tiền, thời gian, chuyên môn mà blogger cá nhân có thể không có.

Tôi triển khai Cookie Control trên mọi trang – bạn chọn wording, styling, tạo category cần thiết. Quan trọng nhất: mỗi category có 2 hàm: onAccept và onRevoke. onAccept chạy code (và set cookie) CHỈ KHI user consent. onRevoke xóa cookie & có thể dừng script nếu không consent. Cấu hình chi tiết công cụ này vượt phạm vi bài viết.

Nếu muốn chạy GA + cookie trên mọi trang, với Cookie Control, ở EU, khai báo sẽ giống như (dùng Universal Analytics):

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.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;
}

Điều này cũng cho thấy ta có tùy chọn chặn script nếu cần, ngoài cookie control. Sẽ thấy ví dụ này sau khi thảo luận CMS như WordPress.

Script Cookie Control khai báo trên mọi trang – nó kiểm soát nội dung third-party khác, không phải GA, vì tôi chọn lộ trình ẩn danh, không cá nhân. Code thêm trên mỗi trang trông như sau (gộp thành 1 dòng để dễ search & replace):

Đọc Thêm Về Google Analytics

Trong phần Resources còn nhiều hơn, nhưng đây là vài điều bạn có thể cân nhắc. Với "cân nhắc", tôi muốn nói: thông báo cho user họ có quyền làm cho duyệt web riêng tư hơn và từ chối thu thập dữ liệu, không chỉ trên site bạn, mà chung.

Google Analytics Opt-Out Browser Add-on

Google Custom Search Engine

Google CSE là đoạn code thêm vào trang, cho phép tìm kiếm nội dung site bạn và/hoặc toàn cầu. Trông như hộp tìm kiếm Google bình thường. Câu hỏi: có thu thập dữ liệu cá nhân không?

Phần rắc rối: Google CSE cũng hiển thị quảng cáo – liên quan đến Google Adsense (chưa nói đến). Nhưng nói chung, CSE có thể coi là tính năng quảng cáo, vì thực tế được tạo qua dashboard Adsense. Vì vậy chắc chắn có khía cạnh dữ liệu cá nhân – và cookie. Chúng ta biết cách xử lý cookie. Cần nói về quảng cáo.

Google Adsense

Google Adsense – mạng quảng cáo phổ biến nhất thế giới. Dễ dùng như các công cụ Google khác: thêm snippet code vào trang, user truy cập có thể thấy quảng cáo. Lại hỏi: chúng ta có xử lý dữ liệu cá nhân không?

Có 2 loại quảng cáo: không cá nhân (vô hướng) và cá nhân (target dựa trên hành vi/thu thập trước). Nếu cho phép quảng cáo cá nhân qua Adsense trên site, bằng đại diện bạn xử lý dữ liệu cá nhân. Nhưng xin consent chạy script Adsense khó hơn GA. Một, vị trí quảng cáo quan trọng (khác GA – code đặt đâu cũng được, hành động vô hình). Hai, nếu user không consent, quảng cáo không chạy/hiện, consent thực tế thành ad blocker ⇒ giảm doanh thu publisher.

Google nhận ra, nên cung cấp công cụ TRUNG TÂM cho phép user cấu hình cách phục vụ quảng cáo cho user EU. Ngay trước deadline 25/5, Google bổ sung mục riêng trong dashboard Adsense: chỉ phục vụ quảng cáo không cá nhân cho user EU. Đây là cách lý tưởng MỌI công cụ/dịch vụ nên xử lý, tiếc là không luôn khả thi.

Như tab EU User Consent giải thích, bạn vẫn cần xin consent user cho cookie. Điều này cũng cover CSE, vì một số cookie shared (CSE có thể hiển thị quảng cáo). Quay lại câu hỏi: chúng ta dùng quảng cáo không cá nhân ở EU, và xin consent cookie – cover xong phần này.

Nút ShareThis

Khi redesign site đầu 2018, tôi thêm script nút ShareThis inline để tăng engagement. Chức năng gồm 2 phần: element HTML hiển thị nút & script chạy background:

Thật đáng tiếc – và sẽ thấy xuyên suốt bài – ShareThis chỉ phát hành bản cập nhật GDPR vào 25/5/2018, quá muộn đối với tôi. Không thể chờ. Tôi triển khai trước bằng conditional loading qua Cookie Control, tương tự ví dụ GA (có cookie). Nếu user consent, nút hiển thị & cookie set; nếu không, không hiển thị. Mất một chút traffic chia sẻ/engagement nhưng tuân thủ.

Đặt script như trên vào onAccept KHÔNG hoạt động. Cú pháp cần khác một chút, nhưng áp dụng cho mọi script JS:

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);},

Dạng trừu tượng hơn:

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

Tôi cũng test tính năng mới ShareThis. Không lý tưởng, vì có overlay window riêng (xung đột với cookie applet của tôi), và độ chi tiết consent cho user không đủ (theo tôi). Tôi chấp nhận mất traffic chia sẻ để tuân thủ. Ví dụ tốt khác cho thấy quy định mới có thể can thiệp hoạt động đang diễn ra (như bounce rate & session duration khi dùng GA không cookie).

Matched Content

Rất giống CSE & Adsense. Code matched content tạo trong dashboard Adsense ⇒ cùng quy tắc áp dụng. Dùng quảng cáo không cá nhân ở EU & xin consent cookie. Xong phần này.

Các Loại Dữ Liệu Khác

Ví dụ trên chỉ minh họa một số ít loại nội dung/script nhúng. Bạn có thể có giỏ hàng. Đó là loại dữ liệu tiếp theo.

Bạn có thể tương tác user không chỉ hiện chữ/ảnh. Đã thấy script vô hình (chạy background), cookie, nội dung third-party hiển thị (tìm kiếm, quảng cáo, nút chia sẻ), chưa xử lý thông tin cá nhân có chủ đích.

Form/Nút Thương Mại Điện Tử (PayPal)

Ví dụ: PayPal – dịch vụ thanh toán online phổ biến. Tích hợp web cực đơn giản: copy-paste code, user dùng nút Mua/Quyên góp gửi tiền. Xác thực bằng user/pass, giao dịch diễn ra. Dữ liệu & tiền trao đổi giữa các bên.

Về mặt GDPR, nhiều điều cần xem xét:

Load form PayPal có tuân thủ không?
PayPal set cookie? Gợi ý: Có. Nhưng bạn có được can thiệp không?
User gửi tiền ⇒ cung cấp thông tin cá nhân ⇒ sau đó thế nào?

Tuân thủ: câu trả lời ngắn gọn là CÓ. Hơn nữa, user phải đồng ý điều khoản PayPal ⇒ nếu dùng form/nút trên trang bạn, họ đã đồng ý PayPal truy cập một số thông tin. Bạn KHÔNG nắm dữ liệu này TRỪ KHI giao dịch xảy ra, và chỉ một phần nhỏ được chia sẻ cho bạn – cần cho lý do kinh doanh rõ ràng (khai thuế). Nhu cầu không tranh cãi (giống hóa đơn/biên lai), nhưng sẽ nói thêm về xử lý dữ liệu.

Điều khác: PayPal là tổ chức tài chính ⇒ một số thu thập dữ liệu bắt buộc (an ninh, chống gian lận). Dù bạn dùng dịch vụ của họ (hoặc platform thương mại điện tử khác), bạn không có nhiều lời.

Khi form/nút load, script chạy – log thông tin an ninh quan trọng. Form cũng set cookie – không cho domain của bạn mà cho paypal.com. Đây là tình huống bắt buộc. Cho đến nay, ta có thể xin consent hoặc dùng script không cá nhân. Nhưng đây, KHÔNG kiểm soát được. Có cookie bắt buộc cho form hoạt động & PayPal làm việc. Lựa chọn duy nhất: cho load form (không can thiệp/thay đổi) hoặc không có form – nhưng có thể mất tất cả doanh thu.

Đây là trường hợp thu thập dữ liệu cần thiết – vì lý do an ninh. Công cụ cookie control cũng KHÔNG thể xóa object PayPal ngay cả khi muốn. Cách trình duyệt hoạt động: vì an ninh, domain chỉ xóa cookie của chính nó. Nếu bạn mở trang site, không thể can thiệp cookie thuộc site khác. Hợp lý, vì không ai muốn người khác đánh cắp session login.

Làm sao trong tình huống này? Minh bạch. Vẫn dùng dịch vụ, nhưng giải thích cho user cách bạn làm, dữ liệu gì được thu thập – tốt nhất tham chiếu privacy policy liên quan để họ đọc hiểu.

Đã trả lời 2/3 câu hỏi. Câu cuối: bạn hiện có dữ liệu cá nhân liên quan trực tiếp đến giao dịch tài chính trên site. Đây là dữ liệu cần thiết (như cookie bắt buộc của platform thương mại điện tử), bạn sẽ cần dùng khi nộp báo cáo thuế. Tức là bạn sẽ chuyển dữ liệu từ PayPal (có biện pháp bảo mật riêng) sang máy của bạn (desktop, laptop, phone...). Lúc này sao?

Nhớ chúng ta nói 2 khía cạnh lớn liên quan thu thập dữ liệu: ẩn danh hóa & mã hóa. Thứ nhất: tối thiểu hóa thu thập (làm thành không cá nhân). Đã làm qua hầu hết bước trên, nhưng cuối cùng vẫn còn dữ liệu liên quan cốt lõi kinh doanh. Không thể ẩn danh thêm (sẽ gây chú ý cơ quan thuế). Không sao. Cần bảo vệ dữ liệu này.

Khi tải form/báo cáo từ PayPal (hoặc platform khác), bạn trở thành người chịu trách nhiệm. Phải đảm bảo dữ liệu LUÔN AN TOÀN. Nghĩa là nếu vô tình mất, hoặc bị đánh cắp, bạn phải làm cho việc truy xuất thông tin cá nhân trở nên khó khăn. Đây là lúc mã hóa xuất hiện.

Mã hóa là quá trình toán học biến dữ liệu đọc được thành bits văn bản ngẫu nhiên vô nghĩa, không giải mã được tanpa khóa mã hóa đúng. Mã hóa tốt gần như không thể phá vỡ bằng máy tính thông thường. Hơn nữa, để tuân thủ GDPR, bạn cần là chủ sở hữu duy nhất của khóa mã hóa để chỉ bạn mở được dữ liệu. Tức là ai khác chiếm được dữ liệu cũng vô dụng.

Tóm lại: nếu giữ bản sao offline dữ liệu ngoài nguồn gốc (như console PayPal online), hãy mã hóa dữ liệu đó. Mở chỉ khi cần trao đổi cần thiết (kế toán, cơ quan thuế...). Bước cuối đôi khi yêu cầu gửi dữ liệu cá nhân qua email hoặc thư vật lý. Lại là cần thiết cho mục đích pháp lý, không tránh được. Nhưng ổn, vì các bên khác xử lý dữ liệu cá nhân (email provider, kế toán, chính phủ) cũng có trách nhiệm GDPR của họ. Ý tưởng: giảm thiểu hành động này & duy trì bảo mật cao (thuật ngữ mơ hồ, sẽ nói rõ hơn). Xem phần mã hóa bên dưới.

Đăng Ký Người Dùng (User Registration)

Site bạn có thể có form đăng ký. Thường có ít nhất trường tên & email. Dữ liệu nhập vào sẽ lưu vào database. Nếu có chức năng này, hãy tự hỏi:

Bạn THẬT SỰ cần user đăng ký? Câu trả lời có thể đơn giản là CÓ.
Bạn cần thông tin gì từ user? Form đăng ký có đủ "mảnh" không?
Bạn biết database ở đâu, cách truy cập, chỉnh sửa, bảo mật nó?

Quay lại ẩn danh hóa & mã hóa. Nếu có thể làm dữ liệu user ít cá nhân hơn (không hại hoạt động site/blog), hãy làm. Nếu lưu dữ liệu đâu đó, hãy thử mã hóa. Đối với hầu hết mọi người, câu trả lời cho việc mã hóa SQL database host shared provider rất phức tạp. Nhưng. Bạn không đơn độc. Provider có trách nhiệm của họ: dịch vụ phải robust & an toàn.

Trách nhiệm GDPR thêm của bạn xuất hiện khi bạn xử lý dữ liệu user. Tức là:

Bạn cần biết dữ liệu user lưu ở đâu.
Bạn cần biết cách truy cập dữ liệu này (và xóa nếu cần).
Nếu bạn backup dữ liệu này (ra máy tính, cloud, server khác), bạn cần mã hóa cho backup.

Nếu gặp khó khăn, bạn cần thuê chuyên gia (tiền, niềm tin, cảnh báo lừa đảo). Nếu không, bạn có thể không ở vị trí tốt về tuân thủ GDPR. Nghe khắc nghiệt, nhưng hãy suy nghĩ: nếu bạn mù mờ về cơ chế xử lý dữ liệu user, bạn có thực sự muốn người khác dùng dịch vụ của bạn? Hay đặt mình vào vị trí họ. Bạn có tin tưởng site không có "ý thức" về việc làm gì với dữ liệu user?

Mảnh cuối: chuyển dữ liệu. Nếu nắm dữ liệu cá nhân, bạn chịu trách nhiệm bảo toàn. Bán dữ liệu hoặc đưa cho bên thứ 3 mà không có sự cho phép rõ ràng từ user là TUYỆT ĐỐI KHÔNG. Điều tệ nhất: bạn có thể "vô tình" rò rỉ dữ liệu mà không hay biết. Một dịch vụ trên site có thể crawl/index database user, bạn không hề hay.

Khía cạnh thu thập dữ liệu user chủ động phức tạp hơn nhiều so với dịch vụ thụ động bật ở background. Yêu cầu nỗ lực lớn hơn. Sẽ nói thêm khi thảo luận CMS.

Bình Luận (Comments)

Logic tương tự đăng ký áp dụng cho bình luận. Bản chất hai chức năng y hệt. User cung cấp thông tin cá nhân. Đúng, đó là lựa chọn của họ đăng ký & bình luận, nhưng trách nhiệm của bạn là cho họ biết bạn định làm gì với dữ liệu. Sẽ quay lại chi tiết sau.

Email (Và Mailing List)

Khía cạnh thú vị của quyền riêng tư dữ liệu, vì nhiều lý do. Thứ nhất, email gần như không thể tránh khi chạy site/blog. Chắc chắn có thông tin liên hệ, người dùng sẽ dùng để liên lạc. Với mỗi email nhận được, bạn thêm data point mới vào bộ sưu tập.

Email chứa nhiều dữ liệu cá nhân. Email điển hình bao gồm:

IP của mail server cuối (trong chuỗi server từ người gửi đến bạn).
Trong một số trường hợp, IP của người gửi.
Chữ ký hệ thống/mail client.
Địa chỉ email người dùng (rõ ràng).
Tên/biệt danh (thật hoặc giả).
Nội dung thực tế – có thể chứa bất kỳ dữ liệu cá nhân nào.

Hơn nữa, email thường KHÔNG được mã hóa, tin nhắn có thể đọc nếu nắm được mail thực tế. Đừng hoang mang. Điều này nghe đáng sợ nhưng không phải. Mặc dù tin nhắn plain text, hầu hết hệ thống mail dùng mã hóa bổ sung để thiết lập kết nối & gửi dữ liệu. Sẽ thảo luận ngay.

Được, bây giờ làm sao?

Cần giải quyết 2 chủ đề chính: 1) nhận & gửi email 2) lưu trữ thông tin email.

Thứ nhất, bạn KHÔNG kiểm soát một số dữ liệu nhận được qua email. Giao thức mail quy định các trường cơ bản (chức năng & an ninh). Hơn nữa, nếu email công khai/sẵn sàng, bạn không kiểm soát ai liên hệ, vì sao. Đó cấu thành consent từ phía user.

Tuân thủ GDPR xuất hiện khi bạn CHỦ ĐỘNG liên hệ người khác qua email. Bạn cần consent từ user để làm vậy. Nếu có đăng ký user & comment, bạn sẽ có số lượng user đăng ký, nắm được email của họ.

Việc nắm dữ liệu này KHÔNG cho phép bạn gửi thông tin cho user (thường marketing, quảng cáo, khuyến mãi) trừ khi họ chấp thuận. Suy nghĩ: ai đó đăng ký để comment, không có nghĩa họ muốn bạn spam newsletter. Họ cần đồng ý newsletter RIÊNG.

Để đơn giản: dùng email cho đúng mục đích:

Ai viết cho bạn, bạn trả lời; hoàn toàn ổn, trao đổi giao tiếp.
Ai đăng ký, dùng email cho quản lý user – xác thực email, thông báo tài khoản, thông báo comment, reset mật khẩu...
Muốn gửi thông tin KHÁC, phải xin consent. Giống cookie.

Đó là "phép màu đen" của trao đổi email. Có thể dùng mailing list, newsletter. Cần xây dựng list với sự chấp thuận rõ ràng của user. Đơn giản.

Phần 2: xử lý dữ liệu. Dữ liệu email giống dữ liệu cá nhân khác. Cần đảm bảo an toàn. Rất giống dữ liệu thương mại điện tử. Sẽ phải giữ email, vì lý do pháp lý & kế toán. Làm theo cách an toàn & có thể kiểm toán:

Truy cập: Truy cập email 2 cách chính: 1) qua trình duyệt web 2) dùng mail client chuyên dụng (Outlook, Thunderbird...). Cả 2, hãy dùng secure layer (https:// trên trình duyệt, secure port trong config mail client, ví dụ port 465 TLS/SSL). Một số trường hợp có option 2FA (Two-Factor Authentication), làm cho hack login khó hơn.
Lưu trữ: Inbox phải an toàn. Nếu dùng provider online (kể cả hosting provider), họ có trách nhiệm bảo vệ dữ liệu. Thêm bảo mật của bạn khi có thể, như 2FA. Quan trọng nhất: nếu giữ bản sao offline inbox (bất kỳ mail client nào), hãy giữ mailbox ở vị trí mã hóa (bạn là chủ sở hữu duy nhất khóa mã hóa). Xem thêm phần mã hóa sau.

Tóm lại:

Dùng email đúng mục đích (trả lời, hỗ trợ tài khoản, mailing list – mỗi cái có consent riêng).
Bảo vệ email (kết nối an toàn, lưu trữ cục bộ mã hóa, bảo vệ online bổ sung khi có thể).

Video Nhúng (YouTube)

Đây là trường hợp thú vị. YouTube cho nhúng video vào trang. Không tồi. Nhưng có hàng loạt vấn đề. Video YouTube kết hợp nhiều yếu tố: có thể có tracking (để recommend video); có thể hiển thị quảng cáo (dựa trên sở thích); có thể có cookie; và hơn nữa. Lớn mạnh có 2 loại video nhúng: Flash-based (cũ) & HTML5 native (mới). Cái này khác biệt lớn.

Làm sao để video nhúng tuân thủ GDPR?

Thứ nhất, về clip Flash (cụ thể Adobe Flash Player). Nói chung, Flash như công nghệ có lẽ không phải đường đi tốt nhất tiến về phía trước, nhất là về video online. Hơn 10 năm, công nghệ này cực phổ biến làm phương pháp ưu tiên nhúng multimedia tương tác vào web, nhưng đang bị loại bỏ dần gần đây, do vấn đề bảo mật Flash player & tất cả trình duyệt hiện đại hỗ trợ video HTML5 native.

Clip Flash cũng có thể set cookie – không chỉ cookie thường – Flash cookie (Local Shared Objects). Tương tự cookie web nhưng lưu riêng & chỉ Flash Player dùng. Bạn có thể không có cách dễ dàng kiểm soát chúng bằng công cụ cookie control. Vì vậy nên làm:

Nhúng lại tất cả clip cũ sang định dạng mới.

Sau đó, còn lại khía cạnh thu thập dữ liệu & cookie quen thuộc. May mắn YouTube cung cấp tính năng privacy-enhanced cho chia sẻ. Khi click Share cho video bất kỳ online, có tùy chọn nhúng video. Cần tick ô Enable privacy-enhanced mode. Sẽ sinh code nhúng khác, KHÔNG set cookie.

Code privacy-enhanced trông như sau:

Cách này – với việc YouTube (Google) không còn dùng third-party ad serving & pixel tracking như một phần tuân thủ GDPR, và chúng ta dùng privacy-enhanced mode không cookie – giờ đây có video nhúng thân thiện user. Ngược lại, cần xin consent như trước.

Cuối cùng, bạn có thể có clip Flash non-standard, non-YouTube trên trang. Ví dụ:

Không có giải pháp dễ dàng cho những cái này. Tôi không biết cách tầm thường để giới hạn clip Flash hoặc vô hiệu hóa cookie by design. Nếu cần công khai, khuyến nghị tốt nhất: upload lên YouTube rồi nhúng với tùy chọn privacy-enhanced mới. Có thể video không dùng được trên YouTube/platform chia sẻ khác vì lý do pháp lý/nội dung. Lúc đó, có thể cần disclaimer riêng, hoặc xóa hoàn toàn clip đó.

Script Nhúng (Embedded Scripts)

Bạn cũng có thể nhúng nội dung khác lên trang, ngoài video. Ví dụ: khảo sát, bản đồ... Dạng script, thường JavaScript (something.js). Cách tốt nhất xử lý, nếu muốn/cần, là xin consent user, cách tương tự nút ShareThis. Bất kỳ công cụ nào dùng, hàm onAccept sẽ bao gồm:

Hệ Thống Quản Trị Nội Dung (CMS): WordPress

Phần này có lẽ hấp dẫn nhất cho hầu hết người đọc. WordPress – CMS website & blog phổ biến nhất thế giới. Dễ dùng, cấu hình tương đối dễ, plugin linh hoạt, hữu ích. Tôi demo với WordPress, nhưng lưu ý CMS khác tồn tại: Drupal, Joomla!, Magento, phpWiki...

WordPress phát hành bản GDPR-ready đầu tiên, 4.9.6, ngày 17/5/2018. Wpbeginner.com xuất bản hướng dẫn GDPR hữu ích ngày 23/5/2018, chỉ 2 ngày trước ngày hiệu lực. Test & triển khai thay đổi cần thiết của tôi cho thấy một số khác biệt so với hướng dẫn đó, nên tôi muốn chia sẻ chi tiết thay đổi & cài đặt tôi thực hiện để site viết sách của tôi, The Lost Words, tuân thủ quy định.

The Lost Words là site WordPress đơn giản – không đăng ký user. Tôi bật comment dùng plugin Disqus (thay vì comment gốc) & thu thập analytics bằng plugin Google Analytics for WordPress by MonsterInsights (cũng nhắc trong hướng dẫn trên). Tôi đã vô hiệu hóa cả 2 plugin trước ngày GDPR có hiệu lực & triển khai phương pháp thay thế tuân thủ, sẽ giải thích chính xác cái gì & như thế nào.

Hành trình giống như trước – chỉ làm với WordPress. Thiết lập kết nối site. Cố gắng hiểu luồng dữ liệu. Mở dashboard & kiểm tra plugin đã cài & kích hoạt.

Thu Thập Dữ Liệu = Plugin

Nếu dùng một hoặc nhiều plugin WordPress, rất có thể bạn đang thu thập dữ liệu, có thể là dữ liệu cá nhân. Cách đơn giản kiểm tra plugin có thu thập dữ liệu không: đọc privacy policy của chúng (nếu có). Sau đó cần chút kiến thức tech để hiểu rõ hơn. Và nhớ: WordPress core tuân thủ GDPR KHÔNG có nghĩa plugin – hoặc hoạt động của bạn – tuân thủ.

Trường hợp tôi: có vài plugin cài đặt. Một số không thu thập dữ liệu cá nhân nào. Chủ yếu là công cụ hardening bảo mật, làm site robust hơn. Một số plugin có tùy chọn cấu hình thu thập dữ liệu (tương tự log server & tùy chọn GA). Một số CHẮC CHẮN thu thập dữ liệu cá nhân. Vậy có 3 nhóm:

Plugin KHÔNG thu thập dữ liệu cá nhân (loại khỏi thảo luận).
Plugin CÓ THỂ thu thập dữ liệu – cấu hình dùng không cá nhân, hoặc thu thập cá nhân nhưng thông báo user & cho consent. Một số tình huống dữ liệu có thể cần thiết. Sẽ khám phá sớm.
Plugin THU THẬP dữ liệu – BẮT BUỘC xin consent user.

Google Analytics

Thu thập thống kê traffic qua GA rơi vào nhóm 2. Đã thấy cách dùng GA ẩn danh, không cá nhân. Ở đây tôi chỉ cách chạy script không dữ liệu cá nhân nhưng CÓ cookie. Kết hợp cả hai.

Tôi quyết định triển khai conditional loading GA dựa trên consent user qua Cookie Control, như đã chỉ trước. Cơ bản: xin consent user, nếu đồng ý, script chạy & cookie set. Vẫn dùng ẩn danh IP. Cookie Control (công cụ tôi chọn) có ví dụ hữu ích chính cho mục đích này, nên setup dễ dàng. Xem trước cho snippet code copy-paste.

Tại Sao Không Dùng MonsterInsights?

Vấn đề thực tế & timeline. Ban đầu tôi thực sự cấu hình plugin Google Analytics for WordPress by MonsterInsights cho thu thập không cá nhân (trừ cookie), ngay cả TRƯỚC KHI họ phát hành bản cập nhật GDPR-ready. Thực tế, plugin hiện có công cụ EU Compliance riêng cấu hình mọi thứ tự động (addon). Addon này tốn tiền – và tôi đã đầu tư tiền cho giải pháp cookie control khác (cũng xử lý script).

Đọc về tính năng: plugin xử lý ẩn danh IP, tắt UserID tracking, tắt Author tracking (custom dimension). Bạn có thể xử lý thủ công, NHƯNG ưu điểm làm qua plugin: thay đổi chỉ áp dụng cho visitor EU. Nếu thay đổi qua tài khoản GA, chúng sẽ là global. MonsterInsights cũng tích hợp với plugin cookie. Tôi không biết có conditional loading script không.

Đối với tôi, thay đổi đến hơi muộn – như hầu hết công cụ GDPR, chỉ xảy ra 1 tuần ngắn trước ngày enforcement, khó test kỹ. Hơn nữa, vì đã phải xin consent cookie (dù có thể dùng no local storage), tôi cũng có thể load GA conditional qua Cookie Control, và đã mua license multi-site cho công cụ này.

Vậy là vấn đề thực tế. Bạn có thể dùng MonsterInsights (chi phí thêm) & tích hợp với vài plugin cookie. HOẶC đầu tư tiền vào công cụ khác (như tôi), xử lý theo cách này, với ưu điểm kiểm soát thêm script & cookie khác, không chỉ GA, ví dụ nút ShareThis, như đã thấy.

Bình Luận (Disqus)

Tôi dùng Disqus cho comment. Thật tiếc, Disqus phát hành bản cập nhật chỉ vào 25/5/2018, quá muộn. Lúc đó tôi đã tắt comment trên blog. Quyết định tái giới thiệu sau khi xác minh WordPress comment hoặc Disqus tuân thủ.

Trước bản cập nhật GDPR cho Disqus, tôi thử "chặn" Disqus bằng Cookie Control & hàm onAccept/onRevoke. Bài học quý giá sẽ thảo luận ngay. Giờ Disqus đã có biện pháp GDPR cần thiết. Nếu muốn login & comment, trước tiên phải đồng ý privacy policy mới. Nếu đã login, không thấy ô comment cho đến khi đồng ý. Cũng có tùy chọn opt-out tracking. Nhược điểm cho user (người dùng Disqus): chỉ có login session tạm thời, phải login lại mỗi lần.

Disqus & Tích Hợp Database WordPress

Lưu ý: mặc định Disqus KHÔNG ghi comment user vào database của bạn. Cần cấu hình thủ công. Nếu làm, comment sẽ thêm vào database, và nếu bạn có database không cá nhân cho đến nay, giờ sẽ có dữ liệu cá nhân ⇒ phải xử lý tương ứng. Ví dụ: nếu backup database không mã hóa trước, giờ bắt buộc phải mã hóa. Sẽ giải quyết ở phần backup dưới.

Kiểm Soát Script Chung

Bạn có thể có plugin/script thêm trên site WordPress, không có phụ kiện GDPR. Nếu plugin/script này thu thập dữ liệu cá nhân, bạn cần chặn thực thi cho đến khi user consent. Tương tự ShareThis. Cần nói về 2 hàm WordPress: wp_enqueue_script() và wp_deregister_script().

Wp_enqueue_script

Hàm này cho phép chạy script theo yêu cầu. Cách dùng không tầm thường, nhưng nếu biết script nào cần chạy, bạn có thể wrap nó trong wp_enqueue_script & đặt vào phần onAccept của cookie control tool, như đã làm trước.

Phần khó: thực sự tìm script cần chạy. Quay lại kiểm tra Web console trình duyệt, tìm hiểu site đang làm gì. Không có lối tắt, nhất là plugin hành xử lạ, không documented. Justin Tadlock thảo luận trên site của ông năm 2009, lời khuyên cực giá trị. Conditional script có thể trông như:

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

Wp_deregister_script

Hàm này làm ngược enqueue; dừng/loại bỏ script. Ví dụ:

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

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

Session Cookie

WordPress (và plugin, theme) có thể set session cookie. Lại cần consent, như trước.

WordPress 4.9.6 – Thay Đổi GDPR

Không cần lặp lại điều đã nói hàng triệu lần. Rất ngắn gọn: WordPress giờ có công cụ thêm giúp quản lý dữ liệu user. Nếu có user đăng ký, bạn có thể xóa họ, cũng có template privacy policy.

Sao Lưu Dữ Liệu (Data Backups)

Đã nói về backup trước – quanh email & database. Nói chung, khá khả thi bạn sẽ backup dữ liệu site (và dữ liệu user cùng lúc). Thực hành khuyến khích, hãy backup. Bằng mọi cách. Điều cần đảm bảo: ẩn danh hóa & mã hóa.

Bạn nên đã cover phần ẩn danh hóa (by design). Mã hóa là bước tiếp. BẤT KỲ backup dữ liệu nào bạn làm nên:

Đến vị trí an toàn, đáng tin cậy & CÓ VĂN BẢN GHI CHÉP.
KHÔNG thể truy cập bởi bất kỳ ai trừ bạn.

Cách tốt nhất: mã hóa backup bằng công cụ & khóa của chính bạn (mật khẩu), rồi nếu ai đó có quyền truy cập dữ liệu, họ không thể đọc nội dung thực. Cuối cùng ta nói đến công nghệ mã hóa.

Công Cụ Mã Hóa (Encryption Tools)

Đã nói nhiều về mã hóa. Hãy dùng nó thực tế.

Nhiều cách mã hóa dữ liệu. Tôi trình bày một vài công cụ có thể. Lưu ý chất lượng & bảo mật công cụ mã hóa có thể khác nhau. Cũng vậy, loại dữ liệu khác nhau có thể yêu cầu loại mã hóa & tiêu chuẩn khác. Một số trường hợp phải dùng phương pháp cụ thể để tuân thủ. Với blogger thông thường, hầu hết công cụ đủ dùng. Cần một mức độ kiến thức kỹ thuật.

Phương pháp mã hóa cơ bản nhất: tạo archive ZIP bảo vệ bằng mật khẩu. Không tuyệt đối, nhưng công cụ như 7-Zip tạo file mã hóa định dạng 7z native (kể cả mã hóa tên file) dùng phương thức AES-256 – tiêu chuẩn mã hóa được chính phủ Mỹ áp dụng. Trên Linux, dùng GPG (GnuPG), triển khai miễn phí chuẩn OpenPGP, mã hóa file & email. Có vài frontend tool.

Cũng có thể tạo encrypted container – file lớn dùng như folder ảo chứa nhiều file khác nhau. Với người ngoài, container trông như file ngẫu nhiên, ví dụ Documents.bin, 603 MB. Khi mount (mở bằng chương trình đặc biệt đọc/giải mã), nó hiện như folder hoặc ổ đĩa riêng trong file manager, bạn tương tác như vị trí khác trên ổ cứng.

Công cụ GUI thân thiện tạo encrypted container: TrueCrypt và VeraCrypt (fork của TrueCrypt, ngừng phát triển 2015). Thông tin này có thể làm bạn ngần ngại, vì có thể cho là rủi ro bảo mật. Tuy nhiên, audit độc lập không tìm thấy rủi ro đáng kể (hiện tại). Cả hai dùng nhiều tiêu chuẩn mã hóa, kể cả AES.

Công cụ Linux khác: Vault trong distro Plasma-based như KDE neon, Kubuntu. Chương trình tích hợp desktop, tạo encrypted container on-the-fly. Backend mã hóa là CryFS, cũng dùng AES-256 + cipher khác.

Văn Bản Hướng Dẫn (Documentation)

Mảnh ghép cuối, sau khi site tuân thủ, là gói gọn mọi thứ. Văn bản hóa mọi thứ, bao gồm viết privacy policy. Không cần dài hay xa hoa. Thực tế, ngắn gọn & súc tích là tốt nhất. Minh bạch về cái bạn làm & tại sao, giải thích thay đổi. Nếu nghi ngờ, luôn nghiêng về phía thận trọng. Cho user quyền lựa chọn thay vì mặc định OK. Cuối cùng, يتعلق đến minh bạch hành động, ẩn danh hóa dữ liệu user (nếu có thể) & xử lý an toàn (mã hóa).

Cuối cùng, kiểm toán (audits). Layout & nội dung site thay đổi theo thời gian. Thực tế, luôn luôn thay đổi. Bạn cần đảm bảo luôn tuân thủ. Mỗi lúc (có thể 1 tháng, 1 quý, tần suất bất kỳ), xem lại Web stack. Nếu có thay đổi, văn bản hóa, và nếu ảnh hưởng user, phản ánh trong privacy policy và/hoặc công cụ/dịch vụ user tương tác.

Kết Luận

Tôi hy vọng bài viết hữu ích. Đơn giản, rõ ràng, thực tế. Tôi cố gắng cover nhiều material nhất có thể, tránh ngôn ngữ mơ hồ, cung cấp ví dụ thực tế, relatable từ phiêu lưu blogging của mình. Tuân thủ GDPR KHÔNG hề tầm thường. Sẽ tốn công sức tư duy & kỹ thuật, hàng giờ làm việc, thậm chí tốn tiền – cả đầu tư trực tiếp & thay đổi traffic sau tuân thủ. Nhưng bạn sẽ có site gọn gàng, thân thiện, vui vẻ cho user.

Không có lối tắt. Điều quan trọng nhất trong hành trình này là giáo dục. Sự vô tri sinh ra nỗi sợ. Nhưng nếu bạn dành thời gian hiểu mình đang làm gì – và site đang làm gì – bạn sẽ vừa tận hưởng công việc vừa kết quả. Nghĩa là cẩn trọng với lời hứa nhanh & giải pháp "bạc đạn" (silver-bullet) ngoài kia. Đừng vội, dành thời gian, tìm cách tốt nhất, thanh lịch nhất để site tuân thủ. Cuối cùng, nếu có feedback, gợi ý, yêu cầu về chủ đề này, liên hệ tôi, tôi sẽ cố gắng cập nhật hướng dẫn. Chào các con của Internet.

Tài Nguyên (Resources)

Theo thứ tự xuất hiện & liên quan (nhiều đã link xuyên suốt):

Chủ đề GDPR:

EU GDPR Information Portal

Wikipedia article on GDPR

Công cụ thống kê & phân tích website:

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

Công cụ kiểm soát Cookie:

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

Nút chia sẻ:

ShareThis opt-out page

Thương mại điện tử:

PayPal privacy policy

Video nhúng & 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

Công cụ mã hóa:

7-Zip homepage

The GNU Privacy Guard

OpenPGP encryption standard

Wiki page on Advanced Encryption Standard (AES)

TrueCrypt (GRC page)

TrueCrypt audit report

VeraCrypt