Kinda proud of this, so forgive me while I brag. I found a likely “phone home” tracking image in DocuSeal. I searched around: there was an extant issue about the image. I asked the devs: would they accept a PR to remove the image? A maintainer responded quickly that they were not interested in a PR to remove it, so I forked it in minutes with my tiny hack, built a new Docker image and re-deployed to my server after making a one-line change in a Docker Compose file.

Here’s the hack: https://github.com/meonkeys/docuseal/commit/e710678d

Happy to share my compose config as well if folks are interested.

I do want to put in a plug for DocuSeal: they made an excellent thing. It’s a fast and beautiful app for adding signatures to PDFs, similar to DocuSign or HelloSign, but awesomely AGPL licensed and easy to self-host. I got it running in minutes and it worked very well. I support what they’re doing and I want to see them succeed. OpenSign looks cool too but I haven’t tried that one yet.

So yeah. Self-hosting and FOSS FTW!

cross-posted to: reddit r/selfhosted (there’s no additional content in the post at that link. Sorry, I should have posted on Lemmy first! Anyway, above is the copy/pasted post so you can get it without having to use reddit)

  • Adam Monsen@lemmy.worldOPEnglish
    117·
    4 months ago

    this isn’t a “phone home”

    are you sure? I’m not. In truth, only they know. Here’s the code I worked around in my fork. Why does it fetch an external image? They could just include it in the repo. Why is it fetched from docuseal.co? I would guess GitHub renders badges like this too.

    Blocking the DNS of the GitHub host

    Sure, but why not default to privacy in the upstream source? Why make users and self-hosters do extra work? Feels more like a penalty for non-Enterprise users than a benefit for paying up: you’ll either pay with money or your data.

    Also note: it is actually docuseal.co that would be blocked (I incorrectly guessed it pulled the image directly from GitHub), so that’s probably not as big of a deal than blocking, say, GitHub for a LAN with multiple tech-savvy users.

    they were very clear about it

    I disagree. I’ll grant you they made a clear decision (and quickly), but didn’t explain further. Frankly I found their replies a bit confusing; they implied the issue as entirely about OEM/white-labeling and avoided the tracking/phone home question. They should just clarify why the badge actually exists when the question came up the second time.

    Maintaining a fork is an insane amount of work

    Agreed that maintaining a fork is work. But, I mean, check mine out, please. It’s 3 lines, and could probably be reduced to a few characters. I’d still love to avoid the fork because your other reasons are quite valid, especially about trust. That’s what this is really about, to be honest. I don’t trust this isn’t a phone home, and I don’t want to have to trust them on this.

    I’m not going to worry about doing that every time a release is missed by you

    100% agreed.

    they have a pro version, so aren’t removing the customizations that exist

    I don’t understand. Will you explain what you mean here?

    It’s part of a lot of open source projects.

    If you mean badges on GitHub repo home pages then yes, I agree.

    If you mean mandatory phoning home or, really, reaching out for any images/static assets from a self-hosted service, I disagree.

    Here’s the right way to do it (again, assuming this is a phone home): be 100% transparent that/if it is a phone home, have a privacy policy around data collected, and make it disabled by default. Traefik does this, for example. They have a phone home toggle called TRAEFIK_GLOBAL_SENDANONYMOUSUSAGE that defaults to false. Note the especially privacy-concerned (and perhaps less upgradae-concerned?) may wish to disable TRAEFIK_GLOBAL_CHECKNEWVERSION as well.

    it’s of no security concern, freal

    I never claimed it was. Maybe my fork will have security improvements as well someday, but right now it just has this one tiny patch. And again, I agree with your other points about forks: best case is this fork becomes unnecessary (as transparency around the badge increases).

      • coffee_chum@lemmy.mlEnglish
        19·
        4 months ago

        Just to play devils advocate for a minute- Loading from their own domain means they can actually garner quite a bit of information from just the serving of the svg:

        • date and time of access
        • IP (country, state, region, etc)
        • Potential for SVG xss attack if hoster doesn’t clamp down their CSP settings

        Date/time/IP are good enough for getting pretty good estimates of who all uses their software. Doesn’t matter if they are or aren’t using that data- it is being sent to them on their own accord and terms. The public has no way of knowing.

        And this is all perfectly acceptable, as long as you do one of the following:

        • Prominent notice to user that tracking is enabled by default, and it can be disabled by doing X, Y, or Z. State the kind of tracking information collected and maybe even say logs are kept in memory or dumped after X days.
        • Allow for opt-in tracking. This one’s pretty straightforward.

        All of this doesn’t really matter if the dev isn’t willing to change anything about the remote image.

        But a fork?? Yeah, totally unnecessary. You can take easily care of this at the reverse proxy layer by preventing the svg (or anything else for that matter) from being served. Just serve a 404 or something instead or do a regex replace and remove it altogether from the page prior to serving.

      • neko@sh.itjust.worksEnglish
        101·
        4 months ago

        Loading external images will reveal to the site where it’s loaded from at least these things:

        • User’s IP
        • Useragent string
        • Referrer

        Also it can set third-party cookies which can be used to track specific user.

        I don’t know if this project processes any of that data, but outside images can be used for tracking purposes.

        At least it would be a good idea to limit some of this things for that img tag by setting some attributes that prevent referrer and cookies from being sent.