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).
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.
> 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).
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
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).
To further expand, commonName is only deprecated for SSL/TLS server certificates. It is, for example, mandatory for CA certificates and code signing certificates.
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.
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....
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...
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.
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.
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.
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.
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.
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.
131 comments
[ 3.5 ms ] story [ 197 ms ] threadHere: (literally) https://looooooooooooooooooooooooooooooooooooooooooooooooooo...
Love it as a piece of art/commentary, though.
2) what the fuck lmao
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...
[1] According to https://www.godaddy.com/help/about-ong-domains-41384
The .ong domain has a policy that has criteria. https://thenew.org/org-people/about-pir/policies/ngo-and-ong...
These are not hard to meet, nor should they be.
But hard for a random url-elongator site to meet.
> 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.)
Clearly this site doesn't qualify.
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.
Running the website (in this case, an url elongator) is not required to be an objective in the articles of incorporation.
Nevertheless, an URL elongator strikes me as funny, and providing fun for free is surely for the good of humankind.
[1]: https://x.com/ccbikai
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
It's only more recently that browsers and other common software stopped validating it though
Also from 2015:
* https://cabforum.org/wp-content/uploads/BRv1.2.5.pdf#page=17* https://stackoverflow.com/questions/5935369/how-do-common-na...
https://community.letsencrypt.org/t/simplifying-issuance-for...
The previous workaround available was to include a second, shorter domain on the certificate but that wasn’t always easy or possible.
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.
Also, it seems to only look for `http:` + one character, which is a bit disorienting. (E.g. `https:/a` would be a "valid" domain)
https://httpscolonforwardslashforwardslashwwwdotzoltanbalazs...
https://aaaaaaaaaa.org/
http://thebestpageintheuniverse.net/
http://bettermotherfuckingwebsite.com/
Slightly disappointed that doesn't have a 10hr version of https://www.youtube.com/watch?v=dys8KUnwGGg
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.
Let's say the spammer owns example.org. The spammer would generate link with my service such that https://urllengthener.sadale.net/foobarbaz would redirect to https://example.org. Then it'd send spam with a link of https://urllengthener.sadale.net/foobarbaz#identifierXYZ to the victim. Then the victim would click on the link, which redirects him to https://example.org/#identifierXYZ, which would show victim the ad. https://example.org/ looks legit on its own and there is no log shown on the HTTP server because the URL fragment identifier is a client-side thing. I'm kind of thankful of that spam abuse report. Otherwise I might have never found out.
(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...
I haven't tested that but I think it's possible to modify the fragment with Javascript: https://stackoverflow.com/a/4282075
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.
Yes, this is how single-page apps allowed linking to subpages before history.pushState existed.
What kind of penalty do you think you could've gotten and by whom?
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.
No one would shut down the post (DHL) for allowing a drug enterprise to send illegal substances using DHL.
So yeah, these links will be abused. What isn't abused?
From my understanding the domain could be 255 characters long.
https://a.lot.looooooooo(...)nger.than.looooooooo(...).ng
[0] https://stackoverflow.com/questions/417142/what-is-the-maxim...
https://web.archive.org/web/20140208032349/http://hugeurl.co...
utils.js, which contains the (de)serialization code: https://github.com/ccbikai/loooooooooooooooooooooooooooooooo...
tool.js, which does the serialization: https://github.com/ccbikai/loooooooooooooooooooooooooooooooo...
display.js, which does the deserialization and redirect: https://github.com/ccbikai/loooooooooooooooooooooooooooooooo...
https://xdpirate.github.io/ghost-translator/ghost-translator...
See dang's explanation to the same question here (and his link to an algolia search of other previous explanations): https://news.ycombinator.com/item?id=36472976
Somehow I have even more questions now. Is this a registered ONG then!?
[1]: https://thenew.org/org-people/about-pir/policies/ngo-and-ong...
https://looooooooooooooooooooooooooooooooooooooooooooooooooo...
https://looooooooooooooooooooooooooooooooooooooooooooooooooo...
I absolutely love it.
You need to put the protocol like I said.
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.
will probably break any auto linking stuff but should work if copy&pasted or properly linked
https://root:ssh@mail.com.sketchylinkasdf.com…
URL filters may have a hard time though.