Problem/Justification
Sending a shared link with 23567gdfeuiaghfdijsrfg7238tf783.truenas.com can be alarming to some folks
Impact
A custom / friendly domain will allow for easier user acceptance.
User Story
Auntie, I set up an account for you to access my webshare so you can get the latest graduation pictures. Click HERE: 23567gdfeuiaghfdijsrfg7238tf783.truenas.com
Yaaaaaahhhh, dont click that link Auntie.
I would revise your request. You’re the one sending the link(s) to the end user and you should tell them you are sending it. You don’t show how or why any custom name is safer. These two links go to the same place but one is masked to look ‘friendly’.
Why not add a url shortener to you servers and use that for your friendly links
Why would that be alarming; the TLD is legitimate. Unless the TLD is compromised, the subdomains are fine.
Regular non technical employees would balk too at least the ones who have security training. It may be fine but it doesnt appear that way. Take it as a UI/UX concern for adoption.
You still haven’t explained why you believe a ‘Friendly name / Custom domain’ would even do for security nor what that is even considered. How are you sharing pictures with ‘Auntie’ and what is the domain? What are you considering trusted?
That makes it even worse, as it obscures the true destination of the link.
OK, is the concern for “Auntie,” or for “regular non technical employees”?
And in either case, the standard security advice would be to not click on links you don’t expect–but in the example you gave, Auntie would presumably be expecting that link. And if you’re digging a bit further, you’d see that the link is to a truenas.com domain, which you’d presumably recognize as legitimate. But that’s only if you have the sense to look at the URL in the first place, which I wouldn’t expect either Auntie or “regular non technical employees” to do.
But I suspect there are a couple of reasons it is the way it is, and is unlikely to change:
iX are having enough trouble managing their own certificates (e.g., TrueNAS Connect: TLS certificate for account-service.tys1.truenasconnect.net expired 2026-07-24 — all handle_update_ips calls failing server-side) that I don’t see them taking on the task of handling any others.
ANYTHING obscures the true destination. If he’s asking to make his urls more friendly to Auntie then that’s the way without a real domain. But of course no one should link on links they haven’t any trust it, that’s basic security.
Really depends on what he wants to do, in the basics if its a real Auntie go and edit her host file to direct all his links from her PC http://mynethew.com/\*
Non-technical employees who have had training is taught to not click anything unless absolutely sure and they have a good incentive to do so, at least in my company. Anyone who fails a company phishing email test (they send out these phishing emails at random once in a while) will be forced to retake their training.
So they also should be able to identify a phishing link vs legitimate link because this is one of the top focuses of the phishing training.
I can see the arguments coming from both sides here but there clearly isn’t agreement on what would be a better solution yet.
One thing that might be useful to add to this conversation is to think about why
http://23567gdfeuiaghfdijsrfg7238tf783.truenas.com/ or MyHappyHappyFunTimeGraduationPictures might be alarming while https://drive.google.com/file/d/Qw5rP_hZ2dvJqBmL1oGpH-QsPfj4DVrhu/view?usp=drive_link
is a common way to share files that most wouldn’t look twice at if they trust the sender (that’s a fake file ID btw).
I’m not sure what the answer is there, but I’d be curious to see what people think.
It seems to me that http://23567gdfeuiaghfdijsrfg7238tf783.truenas.com/ is a good starting point but the supported ability to setup a cname: http://truenas.mygreatdomain.com would be a good way for someone to customize things if they want / are able to do so.
