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.
