I still think client side JS apps are the biggest mistake this industry ever made.
You can query an LLM for "a bookmarklet to show hidden elements and enable disabled inputs".
Namely, it seems impossible to archive users despite the fact that we have a business account and have already archived numerous former employees.
This is so stupid.
But then I saw the work around at it turned out it was just incompetence compounding.
Bro is asking for other issues that could potentially take down the entire company.
I would NEVER EVER move company critical services to Google or any other provider if they legitimately don't care or don't have the qualification to fix an issue at the sign up stage.
web.de is an oldschool German provider, as is gmx.de (and .at, .fr, .com, ...)
the regex smells like an inexperienced developer trying to be clever
Act unconventional and you’ll encounter various inconveniences for doing so, which applies to the real world, too.
And as the article explains, it was the prefix (web.*) and not the suffix (one.*) which turned out to be tripping their validation rules.
I think the same goes for Alice (big ISP, offering mail addresses, in multiple countries)
It looks like some of these wildcards are for mail providers who use multiple TLDs.
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.
All models do it now.
People using LLMs to "spam" slop already caught up on this sentiment and are purposefully introducing grammar and spelling mistakes in the outputs now. I'm not saying yay/nay in this particular case, just sharing what I've seen in the wild. If a company get complaints that customer support is too robotic after starting to use LLMs for it, making it more concise and introducing subtle mistakes are two surefire approaches they'd get recommended.
hallucinated command
actual command
In this case, the combination of "web" and ".one" triggers these security measures.
It also flagged the whole email as 100% AI.
But yeah I kinda understand why would they want to block stuff with 'web'
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.
And like the author, 90% of the time I can just disable their front-end validation and go on my merry way.
One of them was to submit a photo of my drivers license. After I did that it OCRed out some details and prepopulated a form with my information. Hitting submit gave me an error saying to use my full middle name, not an initial. My full middle name is a single letter though.
The person on the phone with my bank had no idea what to do and just kept asking me try again.
I busted out my elite hacker skills though and added a space to the end of the middle name field and was able to steal my own identity.
<quote>
2.1 Host Names and Numbers
The syntax of a legal Internet host name was specified in RFC-952 [DNS:4]. One aspect of host name syntax is hereby changed: the restriction on the first character is relaxed to allow either a letter or a digit. Host software MUST support this more liberal syntax.It's from 1989. ICANN was founded in 1998.
Later, I learnt that this is actually very common problem, if you see the "Me too" count on the Google Community Help, it's about 20K (https://support.google.com/accounts/thread/52598991/my-gmail...) users, that's a huge amount of false positives that Google refuses to care enough about to make a change in their automated account process, which they keep bringing up when users complain, they say the process is automated and nothing could be done about it (well, you are a tech company, can't you like change the code or something?). Unironically I had to wait uncertainly for a week then try, which did not work (same too many attempts), then after two weeks, then after couple of months, until I just gave up and created a new account. After 4 months I was able to finally login again.
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.
The author of that article missed their chance making Google eat their words.
A client-side check's not so unreasonable for that kind of thing.
Of course then you still want the list to be accurate and/or actually have some working support flow that results in an overzealous filter getting fixed. The code suggests that they do or did have a process at some point: the list of specific domains is an override that allows domains that would otherwise match one of the regexes and get blocked.
Sadly, with Google, I don't think you'll ever get the issue that far up the chain.
To their credit, my building society actually took it all on board and fixed their system within a few months. To my incredible surprise, so did a major insurer.
A COMPUTER CAN NEVER BE HELD ACCOUNTABLE. THEREFORE A COMPUTER MUST NEVER MAKE A MANAGEMENT DECISION.
—IBM, 1979
1) it is not automated
2) the user consented
3) subjecting oneself to automated processing is a hard requirement
while in reality
1) a human rubberstamping the decision does not make it non-automated
2) coerced or forced consent via ToS and a checkbox is not consent
3) automated processing is not a requirement, just a business decision.
Some domains in that list are truly ancient. That was a trip down memory lane.
>signs up for it anyway
Why?
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.
Plus, any entity large enough probably has some kind of account manager or contact in Google that could hopefully escalate to the right person.
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.
> "gmail.zip or outlook.mov" will probably flag you as a spammer
> "web.de isn't well-known outside of German circles"
I'm not sure how "web.de" or "web.one" would be perceived as especially trustworthy though.
"It must be genuine, it's from the official Web"?
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?
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.
Obviously if you typed Outlook.com this would be a challenge for you.
Unfortunately that may mean a support ticket and explanation and whatnot, and wasted time. Charitably, it might even mean the customer experiencing friction and going to another provider.
So in this case, front ending it seems to make a bit of sense, it’s just really clumsily done.
Well, apart from search and advertisement, maybe.
Maybe there are politics involved, but fixing a broken regex seems well worth the time to convince a foreign government to rely on your tech.
Of course, the support request never reached anyone who knows what a regex is, so bugs get confused for policy and nobody cares to fix it.
"Reduced fraudulent signups by <made up metric>. Reduce business risk exposure."
Google engineering has certainly taken a nosedive.
alice.app however isn't registered anywhere.
Dark patterns? AI doesn't care about dark patterns. It will instantly navigate around them.
10% annual price increases for absolutely no reason? No problem! Just build a replacement. 98% of SaaS applications out there no longer have a moat. My friend just contracted out a CRM replacement for Salesforce for a small company for $65k. He built it in a few days for a few hundred dollars. Obviously it's much less feature rich, but this company never used 99% of the features in Salesforce anyway. If anything, a light weight and bespoke CRM was what they always needed and wanted anyway. SaaS just wasn't viable for bespoke.
Ads killing the experience? AI will hunt down every explicit and hidden ad and eradicate it. The entire ad model is about to die.
I also use it with my own domain registered outside Zoho, so Zoho cannot actually lock me out of my email ever, only the data they host, though this is true for external domains in Google Workspace also.
[1]: https://support.google.com/accounts/thread/117103497/i-m-loc...
It's your sign to move on, there are hundreds of other cloud providers who will actually provide meaningful human support because they need your business unlike Google.
A cheap 2.5Gb how from racknerd, $20-22/year, + domain.
It's been as smooth sailing as any other email provider.
Very satisfied.
Try it
I guess you could follow the Simpsons joke and spell the letter's name. I'm adding this one to my personal list of falsehoods programmers believe about names.
I believe they have made display answer a tool call so that it can keep updating its answer as it thinks, instead of doing all the reasoning up front, essentially inverting the usual flow. You can use this pattern with any model that supports tool calling.
I use the Maildir format so each message is its own file making it atomic.
(You could have a token that hides previous tokens, but that'd be rather closer to CoT.)
The way everyone gets so up-in-arms about the political views of a person three levels detached from the company is insane.
"Oh no, an individual with different views than me offhandedly mentioned Proton, the horror! I can't possibly differentiate between the views of a company and a separate individual!
Let's go grandstand about canceling our service and discouraging others from signing up because a random person thinks differently than me, and talked about the company."
It also can purely be choosing to not support an organization that doesn’t align with your world view. The money in our pockets is the power to change things.
- use checkpoints to save KV cache before trigger CoT
- trigger CoT, save result as a summary
- go back to previous checkpoint
- instead of generating tokens, add result of CoT summary as input tokens
- continue normally
For the price of twice the KV cache memory, the context stays perpetually small, allowing smarter sessions. You can even apply that continually by summarizing tool calls, etc.
This idea is free.
I'm not sure it's that advantageous though: it consumes more memory, and the sessions are already quite long at 1M+ tokens. One would need to run the economics down, and just test if the shorter sessions are actually smarter with the continuous summarization.