Bit color and secondary liability
"I think the TOS concern lies more with the end user who has HTTPS Everywhere installed and the ruleset enabled". Your mention of "bit color", a metaphor for the provenance sensitivity of copyright law, reminded me of the concept of secondary liability, which spread from patents to copyrights through case law. I wonder if there's much case law about to "contributory TOS violation" in the same way as contributory infringement of a copyright or patent. --Tepples (talk) 01:24, 29 December 2013 (UTC)
- Acknowledged; no substantive comments. Convenience link: "torbug:9287" means https://trac.torproject.org/projects/tor/ticket/9287, since we haven't actually set up a "torbug" interwiki prefix yet. I failed to notice until I checked just now that the ticket was wontfix'd, citing a lack of notable case law in this area (it is also probable the developers feel the mailing list would be a better venue than Trac for such a discussion).
- I do intend to look at some actual terms of service of CDNs, but that's a topic for later. --Eighty5cacao (talk) 04:18, 29 December 2013 (UTC)
- Ok, here's the specific example I had in mind, from the "Network and System Security Violations" section of one major CDN's Acceptable Use Policy. The name of the CDN provider has been redacted (and I have since found that another CDN uses a similarly-worded TOS).
Collapsed to save space
|
Network and system security violations are prohibited by [redacted], and we reserve the right to pursue criminal and/or civil charges and/or work in conjunction with legal authorities in relation to any such violation. Examples of such violations are, but not limited to, the following:
- Unauthorized access of networks, data, servers, databases, etc. that customer does not have permission to access.
- Any attempt to test, probe, or scan any [redacted] system or network (or use the our [sic] network or systems for the purposes of such tests) in order to ascertain vulnerability, or any attempt to breach security or authentication measures without authorization.
- Unauthorized monitoring of traffic or data on any network or system without authorization from the owner of such network or system
- Any attempt to interfere or disrupt any service or network by using the following, but not limited to, methods: flooding, mail-bombing, denial of service attacks, or any other deliberate attempts to overload a system
- [redacted as irrelevant to this discussion]
- Any usage or attempted usage of services for which customer is not authorized to use
|
- (numbering for convenience; this was originally an unordered bulleted list)
- The problems I see are as follows:
- To the extent that the use of unencrypted HTTP presents a trivial vulnerability to MITM attacks, the process of testing a site to determine whether a ruleset can be written could be construed to violate #2; possibly #3 as well, though there is almost certainly a shortage of case law on tools such as Live HTTP Headers that aren't full packet sniffers.
- CDNs typically charge a lot more for HTTPS requests / bytes if the customer has not specifically purchased (i.e., "authorized") a volume deal for HTTPS, by which I mean something like Amazon CloudFront Reserved Capacity Pricing. (It is possible, though unlikely, that some CDNs may immediately raise a customer to a higher pricing tier as soon as the bucket receives a single well-formed HTTPS request.) The CDN in question here does not make prices publicly available. It does have a limited capability for shared SSL as a standard feature (some tiers might require the account holder to configure an origin server that supports HTTPS), and it has an existing HTTPS Everywhere ruleset that makes use of that capability. The end-use of the ruleset might be construed to violate #6 and maybe #1.
- To the (admittedly limited) extent that HTTPS requires additional processing power, use of said ruleset could be construed to violate #4; at least it could be an aggravating factor if browser-based (D)DoS tools/malware were run. --Eighty5cacao (talk) 18:12, 4 January 2014 (UTC) (+ 07:53, 25 March 2014 (UTC))