[pkulak]

Break the terms of service, get mad and write a blog post. It's not even hidden in some legalese; they tell you not to serve majority image/video content _everywhere_ in the UI.

All my tunnels are still running great, for free. I could not be happier.

[erdaniels]

I feel like as a paying customer a warning and migration deadline would have gone a long way.

[emn13]

Enforcing vague rules is always problematic. The rule itself is intrinsically problematic, because people will see that others get away with it, often for seemingly no reason. While the OPs case looks clear cut, rules like this are always going to catch out people small hard to explain changes will cross the invisible and likely fuzzy line at moments people don't predict correctly.

And that further underlines the need for a grace period, if this really is the best model cloudflare can come up with (presumably it is).

[pkulak]

Yeah, that's a fair point.

[mhuffman]

Google and AWS don't have any issues posting the limits on their free-tier usage, I wonder why CF is so secretive about it?

[internetter]

I'd imagine vague rules allow them to give their customers leeway and handle infractions on a case by case basis. Like a popular open source project could get away with a cheaper plan, while on AWS they couldn't.

I think this particular instance is pretty cut and dry. If I understand correctly, they were just reselling cloudflare's services.

However, I DO think under that vague policy they should issue warnings for cases they seem inappropriate

[lexx]

I am not saying I am right. I did break the TOS. They have the right to do what they did. It's just not nice and I don't like them anymore :)

[sophacles]

It's not nice that they want you to uphold your end of an agreement?

I sure hope your customers read this comment, they should know that you're likely to defraud them, since it's not "nice" of them to want you do what you agree to.

[florbo]

Er, so do you run around and dive in pools when the rule boards posted everywhere explicitly list those as forbidden, then get mad when you get kicked out?

[lexx]

That's exactly what I do in pools. On my case though I haven't read the TOS. And I would really appreciate a warning. Also, as I have already said, it's not clear when and how you are considered an image proxy. There is no way to know or monitor it. Do you consider any website with images breaking the TOS, or because we have a separate subdomain with images makes this a problem.

[furyofantares]

I think it's fair that you would appreciate a warning.

In the blog post your claim that "small businesses cannot depend on huge providers like google or cloudflare" may or may not be right, but it's absolutely not evidenced by you not reading the TOS.

I suppose you're also right that there's no way to monitor whether you would be considered an image proxy. I would appreciate more clarity on that myself.

It's extremely clear in your case though. You said it yourself, "all my subdomains that operate as image proxies are banned."

[lexx]

I agree with your comment

[furyofantares]

Lemme just say I do have sympathy for you, and I think your website looks great.

[lexx]

Thank you very much. I really appreciate it

[infamia]

> Also, as I have already said, it's not clear when and how you are considered an image proxy.

I don't understand your position, you called your own servers image proxies. So how could you not know they were image proxies?

[vlunkr]

> they tell you not to serve majority image/video content _everywhere_ in the UI

Do they? I'm looking at the docs related to proxy and CDN and I don't see anything.

[creatonez]

> they tell you not to serve majority image/video content _everywhere_ in the UI.

Where? I've never seen it outside of the fine-print legalese.

[fahrradflucht]

Isn’t the payload of most marketing websites majority image content size-wise?

[kvdveer]

Majority of the bytes? Yes. Majority of the requests? Usually not. Majority of the caches miss bytes? Probably not.

There are probably exceptions, but even the most graphically heavy sites have a decent amount of HTML, CSS, and JS content. This is probably due to Google bot not appreciating excessive image use. Marketing folk typically listen very closely to whatever Google dictates.

[nimbius]

this assessment is reasonable, but not productive.

- Read your terms of service, contractual responsibility and liability for all services. as a leader, youre authoritative and liable for shareholder and corporate risk.

- What you do after the fact is just as important --if not more-- than what you didnt do before. Channel this outrage into action, identify the problem, and countermeasure it to ensure future success.

- Risk is an isotope, do not concentrate it all into one single provider/platform/service or its criticality will prove a detriment to your business. You can mitigate it, accept it, or delegate it, but it cannot be ignored.

- if the product is for free, its likely the roles are reversed. re-evaluate your needs and understand whether youre a consumer, or a product and if this shift in roles aligns appropriately with risk and compliance in your industry. Do not assume the coffee is free.

[emn13]

It is impossible to read all the the terms of services, especially including all the updates, to all of the services an average person uses. There simply is way, way too much text and vague legalese to read and understand.

This is incidentally true of (by)laws too, and it's part of the why behind the familiar adage that it's better to ask forgiveness than permission.

[drowsspa]

While I agree, I think they should set some more objective limits.

[advisedwang]

Setting a specific limit is going to result in people pushing up as close to the line as possible, instead of holding to the spirit of the policy.

[noncoml]

I don’t know. How would you feel if your ISP would say something like “We will throttle excessive traffic” without specifying what this traffic is.

I think limits should be clearly defined. Especially for paying customers.

[drowsspa]

For free customers, that's okay I guess, but not for paying ones.

[sidcool]

Genuinely curious. Why does Cloudflare prevent that?

[c0balt]

Images and Videos tend, in comaprison to text, consume a lot of data even if compressed. This additional data leads to a stark increase in bandwidth usage when accessing a video compared to, e.g., a (text) blog. Because cloudflare is the one handling most of the bandwidth usage and routing this amounts to a significant cost for them (more servers, bigger pipes, ...).

[salawat]

All of the pipes should have been implemented by ISP's and Telcos if all that damn Federal grant money would have actually gone to infra instead of exec bonuses and lobbying.

[mschuster91]

Because the large carriers make a ton of money by extorting their clients (ISPs and data centers) with absurd data interchange pricing. Some like Deutsche Telekom are even worse, they charge both their residential and mobile customers as well as anyone trying to peer with them.

That's partially also the reason why the extremely large players like Google and Facebook have built their own sub-sea fibre lines. Utter madness.

[cortesoft]

I don't fully know, but I am guessing because Cloudflare doesn't charge for bandwidth, only requests... non-html content is going to be more data per request, which might not fit into their cost model.

[dboreham]

Because money.