• 2 Posts
  • 30 Comments
Joined 4 years ago
cake
Cake day: March 6th, 2021

help-circle




  • Also worth noting that #Ubuntu and #Mint both moved substantial amounts of documentation into Cloudflare (the antithisis of the values swiso claims to support). I have been moving people off those platforms.

    BTW, prism-break is a disasterous project too. You know they don’t have a clue when they moved their repo from Github.com to Gitlab.com, an access-restricted Cloudflare site. There are tens if not hundreds of decent forges to choose from and PRISM Break moved from the 2nd worst to the one that most defeats the purpose of their constitution.

    It might be useful to find dirt on various tech at prism-break, but none of these sites can be trusted for endorsements.

    The prism-break website is timing out for me right now. I would not be surprised if they were dropping Tor packets since they have a history of hypocrisy.







  • Every node has a different set of relationships to other nodes. If you create only one account and you choose a small low-activity node, you’re isolated by which nodes are federated and defederated to that node. The front page timeline is also limited by the subscriptions of others on that node which narrows what’s exposed to you. And worse, because most of the population has disregard for decentralization, those subscriptions are mostly to communities on the biggest nodes which exacerbates the imbalance.

    It’s good for the decentralization principle to avoid the large nodes¹, but doing that bring isolation and limited exposure. So to counter those problems you need accounts on multiple small nodes.

    ¹ This means not only avoiding having an account on the large nodes but also avoiding communities hosted on those giant nodes.


  • I don’t think those figures are trustworthy. I recall a page that tracks user counts which named some server I never heard of with a count an order of magnitude higher than lemmy.world. Might have been lemmyverse.net, not sure.

    Counting active accounts is a bit tricky I can imagine. So I judge by looking at the activity. Lemmy has ghost towns and 1 person communities which appear from the timeline like an announcement community but in fact they are open discussions where hardly anyone participates except the moderator. These are not niche topics either. It’s because users only want to manage one account. The stock web client dominates, which is inherently a one-account client. So the single most popular app fails to resist the gravity of the giant nodes. There is a paltry selection of 3rd party apps. Nothing in the Debian official repos.

    I went to phtn.app and just got a 500 error. So whatever that is, it’s probably not a significant factor here either way.

    In Mastodon threads I see more diversity of nodes people are coming from. Whereas when reading a quite active Lemmy thread you see something like 90% of comments coming from the top 5.


  • I might have to try that app.

    As a Debian user I tend to work close to the ideology of using apps from official Debian repos. Debian is quite popular but also disciplined with a quality standard. So an app’s inclusion in the Debian repo somewhat reflects a level of maturity that puts a project on the radar to be taken seriously. There are currently no threadiverse apps in the Debian repos.

    Some would say generally that no non-Debian app is worth looking at. But I do make some exceptions and might have to take a look at Eternity despite the opening sentence: “Eternity is currently in the early stages of development. Expect many unfinished features and bugs!”



  • StreetComplete shows me no map, just quests on a blank canvas. OSMand shows my offline maps just fine, but apparently StreetComplete has no way to reach the offline maps. I suppose that’s down to Android security – each app has it’s own storage space secure from other apps.

    In principle, we should be able to put the maps on shared SD card space and both apps should access it. But StreetComplete gives no way in the settings of specifying the map location. And apparently it fails to fetch an extra copy of the maps as well in my case.




  • I’m on the edge of quitting protonmail. The issues:

    • #CAPTCHA hell. At least for Tor users.
    • no app in f-droid
    • API shenanigans and/or CAPTCHA breaks hydroxide (the foss bridge)
    • protonvpn: you can no longer fetch all the configs in one download. You have to click “download” >120 times now to get all the configs
    • account locks if you do not login frequently enough (i think every 6 months)
    • if you supply your login creds but get a CAPTCHA and say fuck this, and walk, it does not count as a full login needed to reset the expiration clock
    • the CAPTCHAs are graphical which forces you to enable images in your browser; but when you do that you get images that junk up your screen and waste bandwidth
    • no public keyring. Hushmail was better in this regard. An advanced user could upload their PGP public key to Hushtools and then encryption just worked for hushmail users contacting that person. After Hushmail started charging, I would tell the normies who need comms w/me to get a gratis Protonmail account. But then I have to send them my public key and they have to figure out how to attach it to my profile in their phonebook. It’s a show-stopper in many situations.

  • How many websites can handle the amount of traffic that CF can handle? It’s not just about configuring your firewall, it’s about having the bandwidth. Otherwise it’s not much of a DDoS protection.

    That’s what I’ve been saying throughout this thread. The only significant DDoS protection offered by Cloudflare requires CF seeing the traffic (and holding the keys) so it can treat the high-volume traffic. If CF cannot see the payloads, it cannot process it other than to pass it all through to the original host (thus defeating the DDoS protection purpose).

    As I don’t have an account there I can’t see which requests containing credentials use which cert.

    Why would you need an account? Why wouldn’t bogus creds take the same path?

    If it’s true that this is unverifiable, that’s good cause to avoid Cloudflared banks. It’s a bad idea for customers to rely on blind trust. Customers need to know who the creds are shared with /before/ they make use of them – ideally even before they make the effort of opening an account.

    And also, just because the cert is verified by cloudflare does not mean they have the private key.

    This uncertainty is indeed good cause to avoid using a Cloudflared bank.

    UPDATE: I’ve spoken to some others on this who assert that it is impossible for a bank customer to know for certain if a bank uses their own key to prevent disclosure to CF.


  • It seems like a lot of your points hinges on this being true, but it simply isn’t.

    “AFAICT” expands to “as far as I know”, which means the text that follows not an assertion. It’s an intuitive expectation that is open to be proved or disproved. The pins are all set up for you to simply knock down.

    There is a massive benefit to preventing DDoS attacks, and that does not require keys.

    This is unexplained. I’ve explained how CF uses its own keys to offer DDoS protection (they directly treat the traffic because they can see the request). I’ve also explained why CFs other (payload-blind) techniques are not useful. You’ve simply asserted the contrary with no explanation. HOW does CF prevent DDoS in the absence of treatment of the traffic? Obviously it’s not merely CFs crude IP reputation config because any website can trivially configure their own firewall in the same way without CF. So I’m just waiting for you to support your own point.

    There is no indication that banks are handing over client ctedentials to CF.

    This is trivially verifiable. E.g. if you get the SSL cert for eagleone.ns3web.org, what do you see? I see CF keys. That means they’re not using the premium option to use their own keys. Thus CF sees the payloads. I’m open to being disproven so feel free to elaborate on your claim.


  • I’m not looking to be proven right. The purpose of the tangent discussion was to substantiate whether or not bank creds are exposed to CF. If banks are actually protecting consumer creds from CF, then it requires a bit of analysis because banks don’t even disclose the fact that they use Cloudflare. They make the switch to CF quietly and conceal it from customers (which is actually illegal - banks are supposed to disclose it but it’s not enforced in the US). AFAICT, CF’s role is mostly useless if the SSL keys are held by the site owner.

    In the US, the financial system is quite sloppy with user creds and user data. There are even a couple 3rd-party services (Yodlee / Mint) that ask customers for their banking creds at all the places they bank. This service then signs on to all the banks on behalf of the customer to fetch their statements, so customers can get all their bank statements in one place. IIRC some banks even participate so that you login to a participating bank to reach Yodlee and get all your other bank statements. Yodlee and Mint are gratis services, so you have to wonder how they are profiting. The banks are not even wise enough to issue a separate set of read-only creds to their customers who use that Yodlee service. In any case, with that degree of cavalier recklessness, I don’t envision that a US bank would hesitate to use CF in a manner that gives the bank the performance advantage of CF handling the traffic directly. But I’m open to convincing arguments.