> 3.) Fictitious Domain Considerations: As you may know, domains that has ".web" have faced issues related to fictitious domain name usage. While ".one" is not ".web" the combination of the subdomain and TLD triggers similar security protocols.

This is an LLM response. It's the classic pattern where the LLM says something completely unrelated to the topic at hand, realizes that it doesn't have a backspace key, and tries to hedge it in.

My business Workspace account got suspended recently, no reason given, can’t even login to contact support. I’m a solo user so I only had one admin account and that was the one locked out. There was just one text field to submit an appeal, so I did. I never got any email confirmation or tracking number for my appeal, it’s been a week now with no contact from Google. This happened about a week after they charged my credit card for the subscription.

I’m now in the process of switching to Fastmail. Google doesn’t give a shit about anything besides for their golden goose, I would encourage everyone to move away from their services before they just screw you with no warning or recourse just because they can.

I get this sort of thing constantly because my domain, 3e.org, which I have had for 30 years, is apparently impossible. It's either too short to be real, or starts with a number (obviously impossible).

And like the author, 90% of the time I can just disable their front-end validation and go on my merry way.

Smells like „product engineering“. So a product or an engineering lead gets a task to reduce risks of specific abuse by preventing someone from sending email from yahoo or web.de clone. As a quick solution they add this filter without „overthinking“ it. The impact is low, a few customers in a million, so its stupidity gets unnoticed and, once first complaint reaches them, quietly deprioritized to death. Removing it is cheap: the justification for taking that work is likely the show stopper. Google is an old large corp that hires and fires at a scale. Owning removal of abuse filter to increase revenue by Planck-sized amount is an impossible thing.

Google has a computer making decisions that affect humans, and then they then have humans defending the decisions a computer did. We live in a dystopia. I hope "Karen" sees the irony in the day job she is doing.

A COMPUTER CAN NEVER BE HELD ACCOUNTABLE. THEREFORE A COMPUTER MUST NEVER MAKE A MANAGEMENT DECISION.

—IBM, 1979

> Just for context, this is a premium domain with a very high premium renewal fee, no history of abuse obviously.

The registry premium domains on the new TLDs have several issues. The biggest IMO is a lack of price protection. Non-premium domains at least get the cohort based protection from section 2.10c of the registry agreement.

So, in addition to being treated as a 2nd rate domain, there’s nothing stopping the registry from cranking up the price if a domain gets popular. I don’t think it’s ever happened, but have never found contractual terms that forbid it.

I made a website about it a while ago after a registry reclassified one of my domains from standard to premium.

https://tldrisk.com/beyond-basics/premium-domains/

The end is really hilarious. Google had a stupid frontend-only validation, it seems.

I use a .one for a project where it makes perfect sense. Brevo, who are a huge email delivery platform, told me they don't support signing up with a .one domain. Fortunately, after a couple of weeks going back-and-forth one of their developers eventually saw sense and fixed it.

Sadly, with Google, I don't think you'll ever get the issue that far up the chain.

Since the author asked about Alice: it was an Internet provider in France in the early 2000's.

Some domains in that list are truly ancient. That was a trip down memory lane.

I can only presume this regex is there because Google had to block various scammers trying to use email hosting donain names when novel TLDs came onto the market. You can try to manage gmail.zip or outlook.mov but Google will probably flag you as a scammer if you try to email from them. Just because web.de isn't well-known outside of German circles doesn't mean the risk doesn't exist. These email providers, especially the ones hosted by Microsoft, have a history of buying multiple TLDs to offer users a localised email domain.

Blocking a second level domain like the Ukranians tried to use is surprising, though. I guess it's to prevent domains like outlook.co.uk or something like that?

These regexes were put there for a reason so I doubt they'll get removed, but if they fix their frontend-only detection script you're going to be locked out of your domain some day if you force your way through their checks. Seems awfully risky.

Just wait for someone at Google to read this post and then block the domain retrospectively.

>write an entire blog post ranting about how the company that runs the product doesn't give a shit and has terrible support

>signs up for it anyway

Why?

If you could just change your company's domain name that'd be swell!

Surprising Google is happy to lose a paying company over this.

Although the author is taking quite the risk bypassing Google's validation like that. Not sure I'd be risking my company's workspace to do it in case Google wakes up ban hammer happy one morning.

Better then my email invalidate most email checks because it 5 characters wide

One time in college I bypassed client-side validation to order a burrito in a slightly earlier pickup window. More recently, I unhid html elements for features that were "disabled" on an ISP provided router.

You can query an LLM for "a bookmarklet to show hidden elements and enable disabled inputs".

As usual, this is more than just an honest mistake from Google. Not only is the given justification complete gibberish, it has AI written all over it. They have zero respect for users and it shows.

I'd recommend not coming up with inventive fixes like this. There's a non-zero chance that check is in some server-side validation that you can't work around, and one day something you rely on becomes unrecoverable. Take it as a sign that it won't always work

I was about to say that the response was pretty clear, e.g, “your domain sounds like spam”, and you can’t give a more clear reasoning for “exactly why” than any other spam filter can give you an “exactly why reason”.

But then I saw the work around at it turned out it was just incompetence compounding.

I think ditching google would've been a better choice.

> I was about to ditch Google completely and head over to Microsoft

That is the obvious thing to do. Don't understand why you even waste time there. You are digging a deeper hole for yourself.

If they cannot even provide proper support for sign up, what will happen when your account gets disabled for no obvious reason, and you potentially lose years of emails?

the last paragraph was probably most important one here, and the lesson is If you truly want to enforce a validation then it has to be in the backend, the client side validation is just additional luxury if you can afford it.

On a different note, the validations were added for genuine reasons and most likely there would be some discussions/debate on the scope/cost/benefits. I would imagine if some one were to do it a a business seriously then they would have some way to override it on use case basis.

This was a fun read. Absolutely baffling behaviour from Google.

alice.it is indeed an email provider's domain; based on the code snippet it seems like they are active in other countries.

alice.app however isn't registered anywhere.

I would hope that somewhere at Google there is a policy that says you can't do anti-fraud and security checks in frontend only...

Crazy that .one gets locked, but .arpa is fully okay.

Google Workspace has one of the most perplexing interfaces I've ever had the displeasure of getting to know and use.

Namely, it seems impossible to archive users despite the fact that we have a business account and have already archived numerous former employees.

ooof that's bad, all levels of support missed the frontend validation and blamed you and an opaque non-existent process instead

The engineer that implemented this probably used it to justify promotion.

"Reduced fraudulent signups by <made up metric>. Reduce business risk exposure."

Google engineering has certainly taken a nosedive.

I wonder how this list ended up being created anyway. Was it a long standing issue, or just some ai slop? web.com, web.org, web.net don't look like an email provider.

If you use a whacky domain name suffix I dunno what else you expect.

Act unconventional and you’ll encounter various inconveniences for doing so, which applies to the real world, too.

that's a trip. nice catch!