• 0 Posts
  • 20 Comments
Joined 1 year ago
cake
Cake day: June 14th, 2023

help-circle

  • kinda different there though… it’s trivial to add whatever data you like to images etc (and that’s without even resorting to steganography), but that data is only accessible with an application. i believe the question was intended as whether you could get a virus from downloading/playing media files… the content of that “hidden data” isn’t executable, so whilst it’s reasonable to say it’s possible to transport a virus via hidden data in media, it’s not reasonable to say that you can “get” a virus using that same method alone






  • totally understand the frustration, and i’m not going to try and invalidate it!

    … however, it’s definitely not a problem with a simple solution

    since anyone can start an instance, when you search “all”, where should it search? i don’t mean generally like “all the instances”, i mean where specifically? things like lemmy.world, lemmy.ml, kbin.social, etc are obvious… but what about lemmy.mydomainforfriends.social (not real but let’s pretend someone created their own little instance for friends there!)?

    let’s say you say yes that should be searched, okay… how does your instance know it’s there? does it tell all other instances that it exists at some point? where does IT get that list from? (the current solution to this is that your instance starts to “know about” an instance after someone interacts with it, but this has the problem you’ve described)

    let’s say that instance shouldn’t be searched… now, what are the rules (automatic id assume; not with human intervention) that would allow an instance to be added to some big list somewhere? also where is that list? now we’re back at problem 1: how do you store a federated list of servers?

    the problem gets even harder when you consider mastodon, pixelfed, peertube, etc… all these services interact: should all include them? only certain things in them?



  • the protocol that allows instances to communicate is, but AFAIK there’s an API that apps use… the protocol is kinda just for how to push raw bulk data around, whilst the instance itself does things like filter based on “top”, “hot”, etc

    also, in activitypub things like the actor (user), each comment, post, etc are individual objects which must be requested individually (or in a list via a search i think?), so any app that communicates via activitypub would need to make hundreds of requests to the instance to display a single post, comments, and user information!






  • so what you ideally want is people to ONLY be able to access your backend service through caddy, so caddy should be the only one with ports publicly accessible, yes

    caddy running in the same docker network as your services can talk to those services on their original ports; they don’t need to even be mapped to the host! in this case, you have 3 containers: caddy, service 1, service 2… caddy is the only one that needs to have ports forwarded and you can just forward caddy:443 and no need to worry! then caddy can talk directly to services:80 or services:443 (docker containers show up to other docker containers by their container name! so if you run eg: docker run … —name lemmy, then caddy in the same docker network would be able to connect to http://lemmy:80!)

    … but if you forward say service 1 and 2 on :8443 and :9443 (without firewall, and even with it makes me uncomfortable - that’s 1 step away from a subtle security problem), someone could be able to access <yourserver>:8443, right? so they don’t have to go through caddy to get to the backend service… for some services, that can be a big deal in ways that it’s difficult to understand, so it’s best to just not allow it if possible

    an alternative is to make sure your services are firewalled so that nobody from the internet can hit them, but caddy still can… but i like this less, because it’s less explicit what’s happening so it’s easier to forget about


  • if you’re only going to be using those services through the proxy, it can also be a useful security upgrade to not forward their ports at all, and run caddy inside docker to connect to them directly!

    if you forward the ports (without firewalling them), people can connect to them directly which can be a security risk (for example, many services require a proxy to add the x-forwarded-for header to show which IP address originally made the request… if users can access the service directly, they can add this header themselves and make it appear as though they came from anywhere! even 127.0.0.1, which can sometimes bypass things like admin authentication)



  • you rely on centralised entities every day to use the internet… ICANN, IANA, and a few more right at the top, government agencies to manage IP ranges etc, whoever owns your IP block, whoever provides your network… TBH you rely on cloudflare even if you never pay them because they CDN half the damn internet. you reply on google and amazon simply because again they host services you use

    don’t kid yourself, the internet works because of centralised bodies; not despite them! DNS is the least of your concern; at least those names are commoditised and have enough scrutiny (unless you choose a TLD that doesn’t have favourable TOS) BY those centralised authorities that they’re pretty untouchable short of legal challenges


  • useful thing to remember about these systems: you fuck up and it’s a high likelihood literally nobody at the company can do any work because all their files are inaccessible

    that’s like… $10000/hr in lost man hours alone, let alone reputation from not being able to respond to customers accurately, possibly missed SLAs or other contract obligations

    unless your company is all about tech, it’s highly unlikely your IT team has the skills necessary to take on that level of responsibility