Had the Daily Stormer folks kept their mouths shut, they probably would've been fine.
And then Cloudflare continues on to describe why they don't think companies should censor content, whereas Google has numerous blogs and entire technologies revolving around how to censor content even more than they do now.
> Section 18 - Because Cloudflare has no control over such sites and resources, you acknowledge and agree that Cloudflare is not responsible for the availability of such external sites or resources, and does not endorse and is not responsible or liable for any content, advertising, products, or other materials on or available from such sites or resources.
It's a clear ToS breach, a bit of thought would have avoided the whole thing. You got lawyers on hand? Talk to lawyers!
I may support my friend's right to free speech in general, but if they are at my house and start bad-mouthing myself and my family, I'll ask them to leave. They can still say what they want (if not libel/slander), but they don't need to do it in my house. They can go say it elsewhere.
> I wonder if this signals a more general change in attitude
CloudFlare CEO says his Daily Stormer takedown was “arbitrary” and “dangerous” https://news.ycombinator.com/item?id=15034304
> If this is true [Daily Stormer made the claim that CloudFlare were secretly supporters], then I agree with the takedown [...] But in this interview, the CEO says something totally different
The Terrifying Power of Internet Censors https://news.ycombinator.com/item?id=15238415 (September 2017)
> If you think that [...] government has a tendency to suppress dissent, then censoring [...] is just opening the door and setting a precedent
‘Daily Stormer’ Termination Haunts Cloudflare in Online Piracy Case https://news.ycombinator.com/item?id=15377292
> Cloudflare set up a limit to what they allow or not so now they will have to fight where that limit is
if someone tells me they have a 100% SLA I write them off as a liar, but tell me you have a 99.995% SLA and have only ever had this one exception and here's why, that builds much more trust with me.
It's plainly wrong.
https://en.wikipedia.org/wiki/Exception_that_proves_the_rule
If you expect that the SLA has very likely been violated at some point, hearing that it has at some point means that the statement confirms to what you already believe to be true given your existing knowledge. That doesn't mean the statement is true, but since it's not obviously conflicting with what you already believe to be true, it at least allows you to believe it is not immediately false.
Instead of thinking about it increasing the likelihood of being entirely true, think about it as decreasing the likelihood it's entirely false. Depending on your point of view that may not be much, but it's something.
>No, it's a matter of reality matching expectations.
What an agent tells me is what they choose to tell me. You're describing some sort of luck-based updating via that third party's choice.
I don't live in a tinseltown universe full of model trains and animatronic NPCs. None of us do. All reasoning about real-world agents is subject to incomplete information and uncertainty.
That much is trivial. More, it's mutually understood to be the case.
Also mutually understood: basic world knowledge stemming from the same. These are principles simple enough to be patronizing in written description, yet persistently ignored or misused at implementation-level. Like:
1. Actors are variably susceptible to errors in reasoning under uncertainty
2. Actors are variably skilled at exploiting 1 to modulate 3rd party behavior
3. Actors are variably motivated to make use of 1-2
It follows from the above that allowing an actor to subtly shift your expectations as if you ever held a platonic model of their behavior is simply a cognitive error. There's no way around it.
Take the "99.995% SLA" example.
In the absence of that figure, would you have assumed a God-Mode level of performance? Clearly not. You can cross all the factors like whether you care about the figure, whether it's above or below average, whether disclosure is standard in this context, … to just enumerate all the cases and see clearly that there's no time when this information is surprising.
I mean, just look at a top google hit for SLA⁽¹⁾. You really think a CIO reader is in any way surprised to hear that some metric they negotiated into a contract indeed holds? Or that it doesn't?
Continuing: A figure like 99.995% is well within reasonable bounds for any number of business processes, so it's not necessarily false precision here. What it almost definitely is, however, is precision in pursuit of persuasion.
There are plenty of industries for which exacting figures at the high end of some performance criterion — manufacturing quality, service availability, measurement accuracy, etc — are essential to informed consumer behavior. Those industries almost universally have norms or regulations setting out certain expectations about what will be found on a specsheet, how units will be tested, how this information will be reported. If not, the spiel is just spiel.
Facts and figures as token gestures of fallibility, however, are confidence tricks.
I already know you're fallible. You cannot sway this comprehension by reframing around some very likely sort of figure: charm pricing⁽²⁾ and related uses of odd figures are marketing weaselry targeting plebs. To point these things in the direction of clientele is to tell them how much you think of their ability to resist bullshit-fatigue.
My feels about whether I'd wanna have a beer with <The Guy>, modulated by his current demeanor toward me or whatever audience he imagines me to be a member of, do not determine his fitness for any high-stakes job.
The same is true here.
Cloudflare is in the MITM business. Absolutely trusted at no point in time, independent of whatever cost/benefit has gone into the decision to use a MITM. This isn't even defeated by being too big a client to lose: if you were big enough to be a lifeline for cloudflare, you'd have no need for cloudflare.
____________________
¹ https://www.cio.com/article/2438284/outsourcing/outsourcing-...