VPN hay proxy có thể sao chép nội dung có bản quyền không? Ba hành vi
Chuyển tiếp gói tin, lưu đệm phản hồi và tái xuất bản đặt ra những câu hỏi bản quyền khác nhau. Ghép hành vi mà dịch vụ của bạn thực hiện với quy tắc điều chỉnh nó.
Chuyển tiếp gói tin, lưu đệm và tái xuất bản trông giống nhau trên bảng điều khiển nhưng hành xử hoàn toàn khác khi có câu hỏi về quyền. Một dịch vụ di chuyển byte giữa người dùng và máy chủ thực hiện một hành vi, trong khi dịch vụ giữ lại phản hồi và trao nó cho khách truy cập tiếp theo thực hiện hành vi khác. Xuất bản tài liệu của người khác dưới tên mình là hành vi thứ ba, và chỉ hành vi thứ ba đó mới là phân phối theo nghĩa thông thường.
Xác định xem hệ thống của bạn thực sự làm hành vi nào trong ba hành vi đó, rồi gắn quy tắc tương ứng. Nhãn sản phẩm không quyết định gì ở đây, và giao thức được dùng cũng không phải tiêu chí.
Ba hành vi mà proxy hoặc VPN có thể thực hiện
Cổng nhận một luồng TCP, viết lại địa chỉ và chuyển tiếp các phân đoạn theo cả hai chiều. Không có gì tồn tại trên đĩa sau khi kết nối, và tải trọng vẫn không trong suốt với cổng trừ khi máy khách thương lượng TLS với cổng thay vì với nguồn.
Trung gian lưu đệm làm việc khác: nó phân tích yêu cầu, lưu phản hồi trong khoảng thời gian sống mà nó tự tính hoặc đọc từ tiêu đề, rồi phát lại đối tượng đã lưu đó cho các máy khách sau. Giờ đây có thứ gì đó tồn tại ngoài đường truyền, được khóa theo URL và bộ xác thực, và việc lưu giữ nó là lựa chọn cấu hình chứ không phải tác dụng phụ.
Tái xuất bản đi thêm một bước. Tài liệu nằm trên hạ tầng bạn kiểm soát, hướng tới đối tượng bạn chọn, thường sau khi biên tập. Hai hành vi đầu mô tả vận chuyển, hành vi thứ ba mô tả phân phối.
| Hành vi | Điều gì tồn tại sau đó | Câu hỏi quyết định kết quả |
|---|---|---|
| Mang một luồng | Trạng thái dịch và bộ đệm kéo dài vài giây | Điều khoản trung gian nào bao trùm việc truyền tạm thời? |
| Lưu một phản hồi | Một đối tượng cùng siêu dữ liệu độ mới và bộ xác thực | Việc lưu giữ và phát lại có được phép không, và đến khi nào? |
| Cung cấp tác phẩm dưới URL của bạn | Bản sao đã xuất bản hướng tới đối tượng mới | Sự cho phép nào bao trùm việc phân phối tới đối tượng đó? |
Nơi proxy giải mã biến vận chuyển thành sao chép
Khác biệt quyết định phần lớn tranh luận là liệu chiếc hộp có bao giờ giữ văn bản rõ. Một đường hầm thuần, dù là WireGuard, thiết bị OpenVPN tun hay chuyển tiếp SSH -L, đều di chuyển văn bản mã hóa giữa các đầu và không để lại gì đọc được. Proxy kết thúc TLS làm ngược lại: nó hoàn tất bắt tay, đệm phản hồi trong bộ nhớ, rồi mã hóa lại luồng về phía máy khách. Giữa các thao tác đó, tác phẩm tồn tại ở dạng mà người vận hành có thể xem xét và giữ lại.
17 USC 106 liệt kê sao chép và phân phối trong các quyền độc quyền, mỗi quyền chịu các giới hạn nêu trong cùng bộ luật. Một bộ đệm mili giây có thể nằm gọn trong một giới hạn mà không cần tranh cãi; một đối tượng được lưu giữ và có thể phát lại thì khó đặt vào đó hơn nhiều. Thời hạn và mục đích nặng ký hơn việc bộ nhớ có bị chạm tới hay không.
Không điều nào trong số đó biến VPN thành giấy phép, và không điều nào khiến mọi proxy thành kẻ xâm phạm. Vận chuyển chỉ là một sự kiện trong nhiều sự kiện, và câu hỏi có thể đánh giá vẫn nguyên: hành vi nào, trên tài liệu của ai, theo sự cho phép nào.
Tiêu đề bộ đệm mô tả sự cho phép của giao thức, không phải sự cho phép pháp lý
Bộ đệm HTTP quyết định những gì nó được lưu từ siêu dữ liệu phản hồi, và RFC 9111 đặt ra các quy tắc nó tuân theo. Cache-Control: no-store bảo mọi bộ đệm tuân thủ hãy bỏ phản hồi, trong khi private giới hạn việc tái sử dụng cho một người dùng và một max-age dài mời gọi lưu trữ chia sẻ. Một yêu cầu cho bạn biết nguồn đã chọn chính sách nào. Hãy chạy nó trước khi tranh luận về bất cứ điều gì khác.
curl -sI https://origin.example/media/report.pdf | grep -i -E 'cache-control|etag|age'
Một phản hồi quảng bá thời gian sống dài đang nói với bộ đệm rằng việc phát lại là chấp nhận được ở mức giao thức. Câu đó không nói gì về việc bạn có thể lấy cùng đối tượng đó, lưu trữ lại và đưa vào dịch vụ của mình hay không. Hai sự cho phép khác nhau đến từ hai cơ chế khác nhau, và việc thỏa mãn cái này để cái kia y nguyên chỗ cũ.
Trường hợp gương cũng thất bại như vậy. HTTPS đầu-cuối ngăn bộ đệm trong suốt lưu bất cứ thứ gì, nhưng kết quả đó không tạo ra quyền phân phối tài liệu và cũng không lấy đi quyền bạn đã có. Hành vi giao thức giải thích chiếc hộp có thể làm gì; nó không bao giờ cấp quyền.
Những gì cần ghi lại trước khi dịch vụ đi vào hoạt động
Mô tả cách sắp đặt bằng những từ mà người ngoài có thể kiểm tra. Nêu tên tài liệu và nguồn của nó, liệt kê các hành vi hệ thống thực hiện, và cho biết mỗi đối tượng được lưu sống bao lâu.
Giữ bản mô tả đó cùng với việc triển khai chứ không phải trong trí nhớ của ai đó. Khi khiếu nại đến, khoảng cách giữa một lập trường có thể bảo vệ và một phỏng đoán thường là một đoạn viết từ nhiều tháng trước nêu rõ thời hạn lưu giữ và giấy phép.
Một danh sách rà soát ngắn bao quát những lỗ hổng lặp lại:
- Nguồn của tài liệu và các điều khoản gắn với nó.
- Mỗi hành vi được thực hiện: chuyển tiếp, lưu, sửa, cung cấp.
- Lưu giữ theo từng lớp đối tượng, tính bằng giờ hoặc ngày.
- Sự cho phép hoặc giới hạn mà bước cung cấp dựa vào.
- Liên hệ và đường gỡ bỏ cho chủ sở hữu quyền.
Chạy danh sách đó với cấu hình đang chạy, không phải với sơ đồ kiến trúc. Chỗ nào thiếu câu trả lời, khoảng trống đó là nhiệm vụ tiếp theo: hoặc xin phép cho hành vi đó, hoặc ngừng thực hiện nó. Với dịch vụ thương mại, hãy để luật sư đọc bản mô tả bằng văn bản đối chiếu với thẩm quyền tài phán nơi bạn phục vụ, vì chính bản mô tả mới khiến việc rà soát đó khả thi. Bất cứ điều gì bạn không thể mô tả bằng văn bản là lập trường bạn không thể bảo vệ.