Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
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.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.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.
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.
100% agreed.
I don't understand. Will you explain what you mean here?
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 tofalse
. Note the especially privacy-concerned (and perhaps less upgradae-concerned?) may wish to disableTRAEFIK_GLOBAL_CHECKNEWVERSION
as well.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).
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/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:
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.