freedomPusher

joined 4 years ago
MODERATOR OF
[–] freedomPusher@sopuli.xyz 1 points 2 years ago* (last edited 2 years ago) (12 children)

Every lemmy traffic is public.

Certainly not. Your unhashed password is not public. Your DMs are only normally visible to intended parties + their admins. Your IP address is only public when you interact in a generative way. Your login times and the links you visit are also non-public unless you generate content in response. Lemmy votes are also not public (unlike kbin).

NSA can just create their own instance and save everything.

No they can’t. Anyone can create an instance but that instance cannot inherently encroach on non-public data of other instances. But if the NSA is in your threat model for some reason, the NSA /can/ easily get what they want from Cloudflare and it need not even be a tailored ops scenario.

There are other services for private communication, lemmy was never advertised as one.

Disclosure is only the tip of the iceberg. Cloudflare is also a gatekeeper. When a lemm.ee user writes a post, there are several groups of people who are excluded from viewing it. Cloudflare controls which browsers people can use. CF users feed a business model that a privacy abuser profits from. There are countless problems with Cloudflare beyond the reckless disclosure problem.

[–] freedomPusher@sopuli.xyz 1 points 2 years ago* (last edited 2 years ago) (17 children)

The security pitfalls are far more vast on WiFi, in fact by your own suggestion: anyone in range of the library can setup their own spoofed AP. You can even be several blocks away and point a directional yagi antenna at a library or cafe to do this. It would be foolish to try this from inside the library because not only would you be in plain visible sight but the malicious traffic would be visible to the library’s admins (which in the case at hand is outsourced to Cisco). It would also be trivial for admins to detect when a new device is connected for longer than the library’s open hours.

You would have to evade the surveillance cams, ensure no trace of your identity on the router (which you would have to buy using cash), plant it using gloves so no fingerprints, and do something creative to hide it because the ports are in plain sight at waist level. If you opt to store the snooped data on the router which you then must return to fetch, that’s an insane risk that just would not justify the gains. And what do you think would be a gain that’s not possible over wifi? Even if the ethernet LAN differs from the wifi LAN, they would be configured with the same security anyway.

If someone wants to plant a malicious device in the library, wifi still makes more sense. E.g. an attacker can carve out a smartphone sized hole out of the center of a book and plant a device in a book that reaches wifi. Or if they want to power the device, there are still more options to hide it anywhere there is power, vs. trying to hide a device that must plug into an exposed ethernet port in an open room. Thus:

  1. the attack surface of wifi is bigger than the attack surface of ethernet
  2. the attack surface of ethernet is a subset of the wifi attack surface

A Venn diagram of this would be a circle wholly inside another circle. If someone thinks otherwise, please give a viable attack scenario.

As a library user, how do I know I’m not connecting to a spoofed AP? Users are trivially safer plugging into the wall.

(BTW, if you appreciate security, you might be interested to know that your instance [lemm.ee] is a Cloudflare site; thus a US gatekeeping tech giant sees all your traffic on that instance in-the-clear. You might want to change instances. You’re welcome!)

UPDATE

They really are (excessively) on their security game -- it turns out the ethernet ports are just a decoy to distract hackers from resources that actually function. Though in seriousness, we can only say they are on their security game if we scrap availability as a security objective (as non-wifi users are stuffed in this situation).

[–] freedomPusher@sopuli.xyz 2 points 2 years ago* (last edited 2 years ago)

The website of a Belgian law office specializing in GDPR is (ironically) on Cloudflare itself. So they apparently determined that it’s legal under the GDPR. From there, I suppose the question is whether medical information somehow changes the equation. But that’s beyond the GDPR and essentially my question. I don’t know if Czech has privacy safeguards specific to medical data that covers this.

[–] freedomPusher@sopuli.xyz 2 points 2 years ago* (last edited 2 years ago)

Has avoiding Cloudflare become Impossible?

Mostly, yes. But let’s break this down. Cloudflare only breaks web services and so far Cloudflare’s privacy abuses and gate-keeping is mostly confined to the web. Avoiding Cloudflare is impossible in some circumstances.

CFd government sites are unavoidable (voting rights lost in the US)

The only Cloudflare sites that are strictly unavoidable AFAICT are government sites. You can always boycott the private sector, but the public sector is shoved down our throats. There are 6 or so states in the US where voter registration goes through Cloudflare. Even if you register on paper there is still no escape because the data entry worker likely uses the Cloudflare site. I am a non-voter for this reason. Although it’s still possible to move to one of the 44 other states and register there.

CFd medical websites

See How lack of digital rights, Cloudflare, and Google worsened a medical emergency situation and undermined human rights. When you need medical info in a hurry, boycotting is tough.

search is liberated -- but only by 1 single search service to date

There is only one general purpose search service that helps avoid Cloudflare: Ombrelo, which tags and down-ranks Cloudflare websites in the results.

[–] freedomPusher@sopuli.xyz 1 points 2 years ago* (last edited 2 years ago)

If you’re so concerned about being tracked at those levels

What do you mean by “at those levels”? You seem to imply Cloudflare’s abuse is not vastly harmful.

CF ruins Tor, VPNs, discriminates against poor people behind CGNAT, and people who look like bots because they don’t load images. You don’t even get basic protection from IP disclosure. CF sees all traffic on most of their sites, including usernames and unhashed passwords. The OP’s demand is reasonable. The demand that everyone partake in such reckless disclosure to a single gatekeeper running a private walled-garden is not reasonable. Cloudflare has removed the minimum baseline of security that everyone used to have and failed to achieve even a low level of privacy.

[–] freedomPusher@sopuli.xyz 1 points 2 years ago

Cf only acts as a mitm for encrypted traffic if you choose it in the options. If you provide your own cert then they can’t decrypt anything.

That’s really misleading. Most admins use Cloudflare’s gratis service and they use CF to handle the traffic load. This is only possible if CF has the private key and sees the traffic. If CF cannot see the traffic, it must pass it all through to the source webserver which defeats the purpose of using CF.

Most importantly, users have no way of knowing whether a web service opts to use their own key or CFs key. It’s impossible. So wise users have no choice but to assume the worst case (which is also the strong majority of cases): that CF sees the traffic.

[–] freedomPusher@sopuli.xyz 2 points 2 years ago

Admins tend to have an exaggerated degree of self-importance. They think their own service is somehow so important that downtime is just not an option, even at the cost of pawning all their own users/supporters traffic to a tech giant in a country without privacy safeguards. And they do that even when offering a non-profit service like a fedi instance. It’s a total disregard for privacy even when no money is on the line. Part of the problem is not only are they not hiring experts but they can’t be bothered to develop the competency themselves. They don’t factor in or realize the fact that web security is part of the task they are signing up for. Like someone saying they want to sell fries but they don’t want to be bothered with finding a potato supplier. If they want to reject a fundamental component of the activity, perhaps that activity is not for them.

[–] freedomPusher@sopuli.xyz 2 points 2 years ago (1 children)

The pattern is that big businesses can afford their own infosec experts and have no use for CF (who poses a disclosure risk to their business). It’s the small mom & pop shops that cling to CF. They hire someone cheap who doesn’t have a high infosec proficiency, who just takes the cheap lazy path of deploying the site on CF. They usually don’t even bother to tweak CF’s extra privacy-hostile default settings.

[–] freedomPusher@sopuli.xyz 2 points 2 years ago (1 children)

You say “fundamental” when I think (from context) you mean to say “essential”. But to be clear, Cloudflare is not essential to business or the internet. Consider banking in the US. Big banks are competent enough to not need CF. But credit unions are small and on shoestring budgets. So CUs are increasingly exposing all their customers to Cloudflare to save money. If you are a client of a CU that starts using Cloudflare, I suggest switching to paper statements and quit using the website. Switch to a CU that does not expose you to Cloudflare. So far that’s not difficult but that could change.

[–] freedomPusher@sopuli.xyz 2 points 2 years ago* (last edited 2 years ago)

Cloudflare can be avoided so far but this may not hold up for long. There are browser extensions that put a strikethrough on all links to CF sites. There is also a search service (Ombrelo) which tags and down-ranks Cloudflare sites in the results. There is a bot you can follow on Mastodon that will DM you whenever you share a link to a CF website, so you can remove it (documented here).

[–] freedomPusher@sopuli.xyz 1 points 2 years ago

I just recall your post was long with some useful info that I had not copied.

[–] freedomPusher@sopuli.xyz 2 points 2 years ago

Or that this isn’t talked more about.

Indeed. It’s disturbing how not even EFF (the org most reputable for educating people about privacy among other digital rights) keeps Cloudflare’s attack on the privacy of 20%+ web traffic out of the spotlight that it should have.

 

(this is a reply to a mailing list that's too restrictive to accept in-band replies)

Dr. Stallman said:

I've read that GitLab now requires nonfree software both to make an account (recaptcha) and to do various operations once you have an account. I'm told that gitlab.torproject.org makes it impossible to communicate with the developers from the free world.

Different Gitlab instances use different CAPTCHAs, and some have no CAPTCHA at all. Apparently the Gitlab CE code is written to use Google reCAPTCHA (the site admin apparently has control). However,the flagship instance (gitlab.com) is a CloudFlare site, and thus uses hCAPTCHA.

gnu.org is painfully ambiguous here, as it states that the eval is simply for "Gitlab". Is that the Gitlab software, or the service?

I think it's implied that the /service/ was evaluated, because Github was evaluated next to it and Github is only available as a service. So the next question is: which service? gitlab.com, or gitlab.torproject.org? The following page refers to "https://about.gitlab.com/":

https://www.gnu.org/software/repo-criteria-evaluation.html#GitLab

So it seems the "C" rating was given to gitlab.com-- which I find revolting. Ethically they're both quite controversial but gitlab.com is far more exclusive and odious than github.com. (I'll give more details about that on my next post.)

Thos needs to be tested, but assuming it is true, we need to downgrade our evaluation of GitLab ASAP. For our evaluation to be incorrect in such an important way is an embarrassment as well as steering people wrong.

I first complained about the GitLab "C" rating over a year ago (back when it was still reCAPTCHA as opposed to hCAPTCHA). I think it's fair to say the big component of the embarrassment is the length of time to address this over rating.


This post is here because gnu.org has started using "OpenSPF" to restrict inbound email. The email above was rejected by the mail server automatically because the domain of the envelope FROM header does not match the reverse lookup of the sending server's IP address. In short, they are blocking contributors from using a forwarding email service to protect themselves. It's a pre-emptive strike with collateral damage to legitimate participants. Anyone with access to repo-criteria-discuss@gnu.org: please forward this to that list (or people thereon).

view more: ‹ prev next ›