I am the author, I wanted to publish it myself, I didn't expect you had already published it. Thank you very much.
Encountered quite a few problems during the deployment, mainly related to HTTPS certificates.
The longest segment of a domain name is 63 characters. The maximum length of an HTTPS certificate commonName is 64 characters.
This caused Cloudflare, Vercel, and Netlify to be unable to use Let's Encrypt to sign HTTPS certificates (because they used the domain name as the commonName), but Zeabur can use Let's Encrypt to sign HTTPS certificates.
Finally, the Cloudflare certificate was switched to Google Trust Services LLC to successfully sign.
Just to expand on this, commonName is not at all required in certificates and is basically deprecated/legacy
Letsencrypt does not require you to set it, just subject alternate names, which can be up to 255 characters, but some providers require it for no reason
To further expand, commonName is only deprecated for SSL/TLS server certificates. It is, for example, mandatory for CA certificates and code signing certificates.
If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead.
Therefore, if and only if the presented identifiers do not include a
DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types
supported by the client, then the client MAY as a last resort check
for a string whose form matches that of a fully qualified DNS domain
name in a Common Name field of the subject field (i.e., a CN-ID). If
the client chooses to compare a reference identifier of type CN-ID
against that string, it MUST follow the comparison rules for the DNS
domain name portion of an identifier of type DNS-ID, SRV-ID, or
URI-ID, as described under Section 6.4.1, Section 6.4.2, and
Section 6.4.3.
9.2.2 Subject Distinguished Name Fields
a. Subject Common Name Field
Certificate Field: subject:commonName (OID 2.5.4.3)
Required/Optional: Deprecated (Discouraged, but not prohibited)
Contents: If present, this field MUST contain a single IP address
or Fully-Qualified Domain Name that is one of the values contained
in the Certificate’s subjectAltName extension (see Section 9.2.1).
> Registrants are required to certify that they meet the following eligibility requirements when registering a .NGO or .ONG domain name:
> 1. Focused on acting in the public interest. [...] work for the good of humankind and/or the preservation of the planet
> 5. Active Organizations. Members of the .NGO and .ONG community are actively pursuing their missions on a regular basis.
> 6. Structured. Members of the .NGO and .ONG community, whether large or small, operate in a structured manner (e.g., under bylaws, codes of conduct, organizational standards, or other governance structures.)
> 1. Focused on acting in the public interest. [...] work for the good of humankind and/or the preservation of the planet
Operating a publicly available lengthening service is in the public interest and is working for the good of all humans. I used to use hugeurl, but it's no longer in service.
> 5. Active Organizations. Members of the .NGO and .ONG community are actively pursuing their missions on a regular basis.
This is an active organization, pursing a mission of longer urls for the good of all. Maybe this sounds frivolous, but there's a lot of frivolous but chartered 501(c)(3)s, and the requirements doesn't specifically require a registrant to be registered as a non-profit or charity or similar (although such a registration is likely to satisfy an audit, tax records showing a lack of profits/retained earnings may be sufficient)
> 6. Structured. Members of the .NGO and .ONG community, whether large or small, operate in a structured manner (e.g., under bylaws, codes of conduct, organizational standards, or other governance structures.)
We don't have evidence of how it's operated. Many organizations operate websites without publishing their bylaws. Although, I'll grant that circumstantial evidence seems to be that it's operated by an individual.
The GitHub repo linked from the page is owned by an individual (not any kind of structured NGO that would be eligible for this), and they set the location field on their GitHub profile to "NanJing,China" (suggesting that they are located in China).
My first impression was: "What in the QA is this? I wonder what this breaks?"
> because they used the domain name as the commonName
Understandable, but that's old-school, right? I'm pretty sure the x.509 extensions for SAN cover this now, and I'm kind of surprised that CA's are sticking to the old way of doing this.
Yeah, I understand _why_ they provide the warning before forwarding you through to any URL, but at the same time this extra click (or "warning") for users puts this service squarely in the category of joke services rather than actually-usable services (even as a joke service).
There should be a label telling people they need the protocol first, as soon as I entered I wrote "google.com" and nothing happened, confused me for a bit and thought there was something broken or maybe it was a victim of a HN hug.
Otherwise the service would have to presume. Which either excludes http:// or https:// probably the first.
I've ran into this when writing an url shortener and decide that without the protocol, I'd just put https:// in there. So that people could still add webcal://, ftp:// ssh:// and http:// in there if they wish.
A company called Halibut Stuff used to sell T-shirts that came with free email forwarding.
I was myself@iwenttodefcon7.andalligotwas.thislousyemailaddress.com
It broke a LOT of signup forms.
I was working in software testing at the time and we talked about setting up a "likely to break things" email service and selling it to other testers, but realized that the people who'd need it would find it hard to explain to the people who write the checks.
I believe the RFC says they can be up to 256 characters, though the domain must only be 64 characters.
>In addition to restrictions on syntax, there is a length limit on email addresses. That limit is a maximum of 64 characters (octets) in the "local part" (before the "@") and a maximum of 255 characters (octets) in the domain part (after the "@") for a total length of 320 characters. However, there is a restriction in RFC 2821 on the length of an address in MAIL and RCPT commands of 256 characters. Since addresses that do not fit in those fields are not normally useful, the upper limit on address lengths should normally be considered to be 256.
Am I having a stroke? I am 100% certain I saw this exact topic with these exact comments yesterday, but here we are with all of them saying they're from 5 hours ago.
This happens when an article is revived from the second-chance pool. From what I understand the only way they currently have to resurrect a thread involves changing timestamps, which is extremely disorienting for people who actually did see the previous thread.
Be wary with making this kind of website. I made something similar long time ago (urllengthener.sadale.net) and got my site reported for "spam campaign". Turns out that the spammer was abusing my site to generate spam link. I handled that promptly by shutting down my site and didn't receive any penalty for that.
The way how it worked is that the spammer used my urllengthener as a redirection service to a website that looks like an incomplete project, which is actually a disguise. There's javascript code on their site that if there's a URL fragment identifier (the hash thingie postfix for URL) detection mechanism and if the URL fragment identifier matches an ad of their own, it'd redirect to the actual spam ad.
(Remarks: example.org isn't the actual spam site. I just use this domain name as an example.)
I don't have the time for now but I think I should make a write up about that some time later.
And I've tested your service and apparently your site is vulnerable for the exact same kind of abuse as mine. I'd strongly recommend you to at least disabling redirection of URL fragment identifier. Example of URL that's prone to abuse: https://looooooooooooooooooooooooooooooooooooooooooooooooooo...
Spamhaus or another IP reputation provider will contact your hosting provide or ISP and warn them that either:
- You need to follow their best practices (which practically for me meant paying for a subscription)
- Or your upstream net block would be marked as untrustworthy (which basically blocks email delivery from that IP range)
You can imagine what your hosting provider or ISP will do with this.
Source: I ran a URL shortening service from 2004-2007 and this happened to me.
How is this different from GET arguments in the URL? I mean is this relates only to URL fragment, because javascript can parse URL parameters as well and any spam site can abuse it even with rewrite in the path part in the URL.
GET arguments are not redirected to the spam site because when the url redirection site has received the GET argument, the GET argument would generally be discarded/disregarded before redirecting the user to the spam site.
But you're not in control of fragment part. Server doesn't receive fragment for request, it's all managed completely by the browser. To handle this you need to do client side redirect with javascript.
So my idea would be getting looo.ong to create a special client-side redirection webpage that would remove the fragment part using Javascript before performing the redirection with Javascript. And no. Using HTTP redirection response on server side won't work.
EDIT: I've actually seen URL redirection websites that removes the fragment part so it should be doable. Perhaps the purpose of that is to avoid spam abuse.
thanks to the need for ES to accommodate SPA (one of the worse thing that has ever happens to the web), that allows ES/JS to change the URL of the page as long as it is within the same domain. What could go wrong. Don't try to make web a QT replacement. Crete your own freaking interface. Stop hijacking web as document based platform to squeeze everything in there.
There is a de-facto limit on the total length of an URL [0] which significantly exceeds 255, and the path portion of an URL can be arbitrarily long within that limit, so using only subdomains would be unnecessarily limiting, and using them in addition would provide no further benefit.
That was one of the coolest sites ever, the other one being where you could make virtual mixtapes and send them to people. We can't have nice stuff anymore....
According to [1], .ong/.ngo domains are eventually audited for NGO status, rather than requiring proof during the purchase. So one can technically buy it but the registrar should eventually take it away from them.
However the requirements don't state that you have to be a registered NGO in any country. Being registered as some NGO-like tax-exempt entity anywhere but China will make the audit a lot easier, but technically you should be able to pass even if you are just two people with some bylaws written on a piece of paper.
Interesting technical details on the challenges of using long domain names and HTTPS certificates. The author seems to have found a workaround, though potential abuse is a valid concern. I wonder if there are any plans to address that.
First of all, short URLs is kinda overdone / common. There are infinite URL shortening services.
Secondly, this is maybe the last service I'd recommend people use. First time I opened it all of the images failed to load and no CSS. Then, I refreshed it with the console open and there were 40+ errors and 500+ warnings in the console, but everything loaded... including 2 pop-up ads stacked on top of each other and a ton of banner ads. Feels like I should wash my laptop with soap and water after opening that URL.
It's funny because we are used to URL shorteners making URLs shorter, not longer. Storing the target URL as a series of O and o inside the generated URL is also a clever technical solution that is aesthetically pleasing.
Do you have any reason to believe that this is more prone to abuse than URL shorteners? If anything I'd expect the reverse to be true—a URL like this would raise far more eyebrows among most people than a short one would—and this one has a pretty thorough warning page before giving you a nondescript button to click to proceed to the target.
Encountered quite a few problems during the deployment, mainly related to HTTPS certificates.
The longest segment of a domain name is 63 characters. The maximum length of an HTTPS certificate commonName is 64 characters.
This caused Cloudflare, Vercel, and Netlify to be unable to use Let's Encrypt to sign HTTPS certificates (because they used the domain name as the commonName), but Zeabur can use Let's Encrypt to sign HTTPS certificates.
Finally, the Cloudflare certificate was switched to Google Trust Services LLC to successfully sign.
Related certificates can be viewed at https://crt.sh/?q=looooooooooooooooooooooooooooooooooooooooo...