@resist1984
Why so?
@jubes have a look at the #Amazon pull-down here: https://codeberg.org/swiso/website/issues/141
@resist1984 I'm not excusing Amazon's misbehaviours but from a technical perspective I don't think it's foolish, it was either poor design or ignorance. The article posted indicates the leak was from an open S3 buckets which is the end users issue not Amazon's.
@resist1984 Fair point, but insider threat is a risk which affects all businesses. You can also use standard Public Key Infrastructure to secure data so you don't need to trust Amazon if you're going to use them for storage. In addition, from what I understand the Capital One breach wasn't due to untrustworthy insiders, it was due to a misconfigured Web Application Firewall (ModSecurity) which in turn allowed for Server Side Request Forgery.
@resist1984 I don't know and maybe. My point is, it's not unique to Amazon but I understand the need to make the points into beating sticks.
@jubes #Liberapay uses #CloudFlare (a recipe for disaster in itself), so we're blocked from checking the hosting provider, but Liberapay bluntly states that #AMZN is their hosting provider. It's a given that a service must trust their own insiders, but making a tech giant an insider kills trust particularly given a history of breaches.
@jubes Management loves to outsource b/c when shit hits the fan, finger pointing is a form of job security. It's not good for users though.
@resist1984 Apologise, I'm not sure how to interpret this. As a manager, i'd still be held responsible my "choices". There are also plenty of other reasons why oursourcing is a good thing e.g. reducing overheads if you're a small business.
@jubes It's far easier for a manager to justify the choice to outsource than it is to take responsibility for an internal disaster where you had control over all the moving parts. Managers don't get sacked for the mere decision to outsource, so outsourcing is the /safest/ path.. the path of least risk for a manager's job security.
@jubes As someone worked in the trenches of several fortune 500 corps, I've been forced to interact with incompetent services & poorly designed tools to interface w/those svcs many times. The waste is stark yet hard to quantify mathematically (& if it were quantified there's not generally a path to present it to upper management - such trouble makers risk getting cut loose)
@jubes when a small company outsources to CloudFlare, they're often over-estimating the threat of outsider attack while under-estimating the threat of CF compromise (cloudbleed or CF exploiting the data). And if the threat manifests into a DoS attack, admins usually aren't aware that CF is non-gratis for high traffic.
@jubes I think clever web design can mitigate the perceived need for #CloudFlare. E.g. code image dimensions into the html so the important content can quickly render before the images. Use #SBLAM (#CAPTCHA alternative) on pages with form input. Failing that, CF has competitors that are more worthy, who don't attack your own users as a consequence of their sloppy technique.
@resist1984 I agree that it's useful to be able to know which hosting services a service provider uses to be able to have all the facts and make an informed decision about whether you want to use said service. That said cloudflare does offer some useful protective services thus i'd be interested in knowing how you approach this in the light of hackers etc? I'd also be interested in understanding which economic models you prescibe to which would result in something that isn't a tech giant?
@resist1984 Also assuming the service deals with users in the EU you should be able to find the data processors (GDPR speak) within their documentation.
@jubes I think you are implying that #GDPR compliance is somehow the end of the story. It's an abuse of the spirit that drives the GDPR's data minimization clause. It would be too ambitious for the GDPR to restrict who can be a data processor, so it's important as users to refuse unreasonable data sharing, like that of CloudFlare.
@resist1984 Thanks for your insights, I appreciate it, certainly food for thought.
@jubes When someone reported #Cloudflare-proxied child porn to CF, instead of taking corrective action CF doxxed the person who reported it to the admins running the site that hosted the porn, who then publically smeared the whistle blower to solicit attack on that person. This proves that CF cannot be trusted with sensitive information.
@jubes CF has taken over 10% of the web, which makes them a highly desirable target. And when attacked such as when #cloudbleed happened, the impact is unacceptably devestating. All users on the affected sites had to change their passwords.
@jubes #CloudFlare actually directly and deliberately /reduces/ availability by blocking legitimate Tor users. Availability is the most important security factor and they arbitrarily marginalize users who take steps for their own security, forcing unreasonable exposure.
@jubes the business case for #Liberapay (as a non-profit) is not to maximise profits. An ethics-lacking profit-driven business may use CloudFlare if their bottom line justifies it, but that's not the economic model that #Liberapay users are expecting.
@jubes Non-profit or not, if an org opts to use #CloudFlare amid its huge list of ethical issues (https://codeberg.org/swiso/website/issues/141), ethical users have a duty to condemn it. Users don't have a duty to the bottom line.
@jubes Is Capone, Amazon-Swiggy-Juspay, & Liberapay only using AWS for storage? AWS is also a hosting service, so I thought AWS was where these financial services ran their web server. The Capital One attack was executed by a contractor who worked for Amazon. Perhaps their insider access gave awareness of the malconfig.