church-branded URL shortening

My ward was previously using the URL shortening service tr.im (in part because the church firewalls blocked bit.ly at the time we started sharing a shortened link), but tr.im recently went out of business, and invalidated all shortened URLs that had gone through their site, including the link that ward members were using to access the weekly bulletin. It would be really nice if the Church could add an official URL shortening service for use by members, where the act of registering the shortened URL first checks that the redirection target will also make it through the church's firewall. It would reduce risk of links breaking when a third party company goes out of business, and might look better by making the short URL obvious that it was created by a church member. In the meantime, does anyone have suggestions for which URL shorteners actually work when logged in to the Church network?

Church headquarters is careful to apply its branding only to official Church materials, to prevent misleading information or incorrect doctrine distributed by members from being misinterpreted as official, and also as a legal protection against people who try to harm the Church by pretending to be an official source. Even local wards and stakes aren't allowed to use church branding (like the logo, for example – see Handbook 2, 21.1.10). Because of the Church's continual efforts to distinguish between official and unofficial, I doubt they would provide a URL shortener that any church member could use – a lot of members would be easily swayed into thinking that something with an "official" short URL is an official church website.

You have a fair point about a branded shortener being abused if it can point to arbitrary locations by an arbitrary person. But it is possible to create a branded shortener that will refuse to create a short link unless the person attempting to create a link has proper authentication rights (such as an lds.org content creator that can already produce official content) and/or if the link points within the lds.org site (where an unauthenticated user can create short links but only to what is already an official site), so that the branded links should never escape the walled garden of official content.

And even if an official branded shortener is unlikely to happen, it could still be helpful if the church could recommend the use of a particular non-branded URL shortener that will be permitted by the firewall when generating memorable names or shorter links into resources that will be helpful while teaching a lesson, sharing a google document between ward council members, etc, while still making it clear that such a recommendation does not make the short URL official. The fact that some shorteners are blacklisted at the firewall makes it harder to know which service to try, especially when a service works at home but fails at church. And if a particular service is recommended, it should also have a preview mode where it is easy enough to learn which website the short URL would redirect to without actually having to follow the short URL.

Don't mind me... just passing by to see if this is a thing so I don't have to use a third party shortener.

Not sure if anyone is still looking at this issue, but I too am looking for a solution to this, as I am trying to help promote the use of my branch's official webpage over Facebook. A simpler URL is needed to communicate the address verbally or in print. If there is no church sponsored solution, is the use of third party URL shortening/redirect services acceptable?

An official URL-shortening service from an organization like the Church of Jesus Christ of Latter-day Saints could create liability issues. The problem is that it could make third-party websites appear to be official, even though they’re not. For example, even if a ward Facebook page is considered “official,” Facebook itself isn’t owned or controlled by the Church, so using a shortened URL to make it look official could cause confusion.

Instead of the Church managing a shortening service, one possible solution is to create a new URL-shortening service designed with more transparency and accountability. Here’s how it could work:

- Links are shortened as usual, but before redirecting, users are taken to a transition page that shows the full URL. This way, people can see where the link is leading before they click.
- The page could also display the username of the person who created the link, with a link to their profile where they can be contacted privately.
- The creator could add context to the link (e.g., explaining what it’s for, including a timestamp, or setting an expiration date for the link).
- Liability disclaimers and legal information could be included to protect against legal issues.

To make links with this service, people would need to create an account, meaning each link would be traceable back to the original creator. This adds accountability and transparency, allowing others to share links while still knowing who made them.

This approach would offer more control over the links, allowing for clearer communication and reducing confusion about what’s official and what’s not.

[Note: I had ChatGPT rephrase my post above to make it more straightforward and comprehensible, and I modified it a little. For your information, ChatGPT thought the account-based transitionary page was a good idea, too, when I asked. But I'm not saying ChatGPT is liable for it if it goes haywire; it can make mistakes.]

Another idea for use in this same system is to have Church-leaders have public/private encryption keys, and sign the link page (timestamp and all), so people can verify that they came from the right person (assuming members have their public key from somewhere else). If everyone in the Church were educated on asymmetric encryption, it would solve a lot of problems. The problem with not doing digital signatures is that someone could spoof someone else's account by using a username that closely resembles or exactly looks like someone else's. So, since encryption is kind of complex to deal with, one thing you could do instead is ensure usernames have to be ASCII-only, and have a known official third party verify specific links/users (saying they officially are who they say they are).

munaish wrote: Mon Feb 03, 2025 10:14 amensure usernames have to be ASCII-only

This would significantly limit use outside of English-speaking countries.

What's the going rate for domain names these days? I don't think it's too hard to set up a re-direct (I know my brother had one) and there's ways to get one server to service multiple domains.

So, perhaps a url like springfield1stward.com. There's also a top-level domain of .church. I couldn't find out what they wanted to charge. But if you used that, it could be springfield1st.church. The big thing is to make sure the ward keeps up with the domain registry with the change in leadership so someone doesn't take over that name.

A quick check of GoDaddy indicates the example domain would be $22/year. But that doesn't include the server.

If someone did take over that domain, it would be a reflection on that ward, not the whole church.

sbradshaw wrote: Mon Feb 03, 2025 12:28 pm

munaish wrote: Mon Feb 03, 2025 10:14 amensure usernames have to be ASCII-only

This would significantly limit use outside of English-speaking countries.

I don't know any stock international keyboards that cannot type A-Z, a-z, and 0-9, which are all represented in the ASCII character set. Even Japanese and Chinese keyboards can type them, as far as I understand. So, even though they couldn't type hanzi, kanji, accents, Cyrillic, and stuff, they could still type a username (just like they can type American website URLs).

You don't actually have to be dealing with ASCII itself anyway. You can limit it to whatever Unicode characters you want (without changing character sets).

It's not really about ASCII. It's about avoiding spoofing (and one way to avoid spoofing is by avoiding visually redundant characters). Avoiding non-ASCII characters is simply one way to avoid the most problematic kinds of spoofing. There are other ways to approach it. Yes, you can still spoof with ASCII, but it's easy to identify if you pay attention (and if you know it's ASCII, you know which characters are problematic). But ASCII can still be tricky with mixed casing; so, you might want to limit it to lowercase usernames for that reason (since with mixed casing you have Il1 and O0 can look pretty much the same, depending on the font, but in lowercase you have il1 and o0, which are easier to tell apart). I and l are the worst offenders in ASCII. So, you could enforce a serif font in usernames, if you wanted to keep mixed casing.

The problem with allowing the full range of Unicode in usernames (and I am only talking about in usernames, and only in the context at hand) is Unicode encompasses all of these, which look pretty similar to each other:

Standard alphabet characters (found in ASCII):
• abcdefghijklmnopqrstuvwxyz
• ABCDEFGHIJKLMNOPQRSTUVWXYZ

Unicode characters (not found in ASCII):

Serif
• 𝐴𝐵𝐶𝐷𝐸𝐹𝐺𝐻𝐼𝐽𝐾𝐿𝑀𝑁𝑂𝑃𝑄𝑅𝑆𝑇𝑈𝑉𝑊𝑋𝑌𝑍 (mathematical italic capital)
• 𝑎𝑏𝑐𝑑𝑒𝑓𝑔ℎ𝑖𝑗𝑘𝑙𝑚𝑛𝑜𝑝𝑞𝑟𝑠𝑡𝑢𝑣𝑤𝑥𝑦𝑧 (mathematical italic small; the h isn't serif with one of the fonts I use)
• 𝑨𝑩𝑪𝑫𝑬𝑭𝑮𝑯𝑰𝑱𝑲𝑳𝑴𝑵𝑶𝑷𝑸𝑹𝑺𝑻𝑼𝑽𝑾𝑿𝒀𝒁 (mathematical bold italic capital)
• 𝒂𝒃𝒄𝒅𝒆𝒇𝒈𝒉𝒊𝒋𝒌𝒍𝒎𝒏𝒐𝒑𝒒𝒓𝒔𝒕𝒖𝒗𝒘𝒙𝒚𝒛 (mathematical bold italic small)

Sans serif
• 𝐀𝐁𝐂𝐃𝐄𝐅𝐆𝐇𝐈𝐉𝐊𝐋𝐌𝐍𝐎𝐏𝐐𝐑𝐒𝐓𝐔𝐕𝐖𝐗𝐘𝐙 (mathematical bold capital)
• 𝐚𝐛𝐜𝐝𝐞𝐟𝐠𝐡𝐢𝐣𝐤𝐥𝐦𝐧𝐨𝐩𝐪𝐫𝐬𝐭𝐮𝐯𝐰𝐱𝐲𝐳 (mathematical bold small)
• 𝘈𝘉𝘊𝘋𝘌𝘍𝘎𝘏𝘐𝘑𝘒𝘓𝘔𝘕𝘖𝘗𝘘𝘙𝘚𝘛𝘜𝘝𝘞𝘟𝘠𝘡 (mathematical sans-serif italic capital)
• 𝘢𝘣𝘤𝘥𝘦𝘧𝘨𝘩𝘪𝘫𝘬𝘭𝘮𝘯𝘰𝘱𝘲𝘳𝘴𝘵𝘶𝘷𝘸𝘹𝘺𝘻 (mathematical sans-serif italic small)
• 𝘼𝘽𝘾𝘿𝙀𝙁𝙂𝙃𝙄𝙅𝙆𝙇𝙈𝙉𝙊𝙋𝙌𝙍𝙎𝙏𝙐𝙑𝙒𝙓𝙔𝙕 (mathematical sans-serif bold italic capital)
• 𝙖𝙗𝙘𝙙𝙚𝙛𝙜𝙝𝙞𝙟𝙠𝙡𝙢𝙣𝙤𝙥𝙦𝙧𝙨𝙩𝙪𝙫𝙬𝙭𝙮𝙯 (mathematical sans-serif bold italic small)

There are a bunch more.

On top of that, there are many other redundant characters, even if they don't constitute whole alphabets like the ones I mentioned above do.

Another way to avoid spoofing would be to have AI analyze the usernames for anomalies, if you have that kind of technology at your disposal. For a backyard web specialist, though, I think ASCII-only is a pretty good solution until you get more resources to do something better.

Alternatively, you could generate a unique random picture or word to be associated with every username, so people would know it's not spoofed (people wouldn't choose these pictures/words, and they wouldn't need to know them to log in; everyone would see them by, under, or above their username, though). That would actually be easier and probably more effective, as long as the people the URL was intended for were familiar with this random word.