Comment by stackghost
4 days ago
It's not 100% clear to me, from reading TFA, what the actual vuln is.
Suppose DankStartup folds and I, being a morally-dubious sort of fellow, purchase dankstartup.net which I then use to sign into DankStartup's O365, or DankStartup's ChatGPT as a DankStartup employee.
Isn't that a failure on DankStartup's part, to not shut down their business accounts? And isn't it also a failure on e.g. Microsoft or OpenAI's parts, since they're providing service to a defunct business entity who can't pay its bills?
To describe this as a vuln in oauth doesn't really make sense to me.
Well, think about it this way:
1. I create DankStartup and my company uses Google workspaces and Google auth for a bunch of stuff, like payroll.
2. DankStartup goes under and we close our Google accounts/let our domain lapse.
3. Someone else buys DankStartup.com, sets up a Google workspace, and attempts Google auth to log into stuff, and it works.
The problem is that the original DankStartup has a Google account that they create in #1, and Google goes around telling other sites (via Auth) "this is user X from company Y".
Then, the impostors in step #3 create a different google account with the same domain, and Google says "yeah, these are definitely the same guys as before", even though Google is fully capable of discerning that that is not the case; these are different people with a different workspace account, different names, different payment information, and so on, but Google is saying that if you're holding the domain you are therefore the same people as far as they're concerned and is asserting that to other companies. They are (or were) refusing to provide any indication to those other companies that these are not, in fact, the same people, so those other companies aren't even capable of doing their due diligence of extra validation if they want to.
It's similar to looking at a driver's license and just matching the name rather than the actual ID number; it's possible for someone else to have the same name as you, and identity documents have unique identifiers for specifically that reason.
>Then, the impostors in step #3 create a different google account with the same domain, and Google says "yeah, these are definitely the same guys as before", even though Google is fully capable of discerning that that is not the case; these are different people with a different workspace account, different names, different payment information, and so on, but Google is saying that if you're holding the domain you are therefore the same people as far as they're concerned and is asserting that to other companies.
Yep I understand the mechanism by which this gets abused; I think we just disagree on the implications. I don't work for Google but it seems from the outside that they're treating the OIDC subject claim as referencing the domain attached to the workspace account, or something similar. I've seen implementations where the `sub` claim is more granular, so to me that indicates the field is underspecified.
Given all that, I suppose TFAuthor's proposed solution is a good way forward.
I still think classifying this as an OAuth vulnerability isn't correct.
Traditionally, SAML / OIDC trust is established using public/private keypairs. Each IdP/SP pair gets a unique combination. In this case, a domain changing hands would not allow the new owner to gain access to the old owner's accounts.
In the case of Google OAuth, it's possible to forego this in order to allow any Google user from any Google workspace to login to your application. See the distinction between "public and internal applications" here: https://support.google.com/cloud/answer/6158849?hl=en#zippy=...
Some applications (e.g. Tailscale) take advantage of the public Google OAuth API to provide private internal corporate accounts. A common misconfiguration here is to use the domain portion of the "email" attribute - this can be spoofed by Google Workspace admins. That's not what's happening here.
Instead, Google instructs you to look at the "hd" parameter, specific to Google, to determine the Google Workspace a given user belongs to for security purposes. This field cannot be overridden by Google Workspace admins. The trust breaks down when the domain changes hands, a new Google Workspace account is opened, but the old "hd" value is reused.
You can read more about "hd" here: https://developers.google.com/identity/openid-connect/openid... (find the table and read the descriptions for both "email" and "hd".)
You can avoid this issue by using a custom Google OIDC IdP configured for internal access only in your applications, rather than using a pre-configured public Google OIDC IdP (be very careful you mark it internal!) A new domain owner would not be able to retrieve the secret key you previously generated.
8 replies →
It seems there are two possible problems.
The first is whether taking over a lapsed domain allows you to takeover an existing Google Workspace (or Cloud Identity) organization. This it what houses the corporate email accounts and OAuth client registrations. If Google allows this scenario then the linked account takeover is simply one symptom / side effect among many. TFA is not clear on whether this step actually happened... I assume not, since if it were the case we'd be talking about direct access to the Google account data rather than only linked SP accounts.
The second is when an SP doesn't properly use the `sub` claim as a unique identifier. It sounds like some products don't understand this requirement and why it "seems to change 0.04%" of the time. I do agree that a unique identifier for the org itself would be a good addition to the token.
That said, I'm still not clear how the second problem manifests if the old OAuth client creds (housed in the old Workspace org id) are invalid. Presumably attacker can login to the SP admin account using just email based password recovery, then reconfigure the OAuth integration with new secrets. In that case the SP is failing to do MFA on the email login.
Would love to hear if I'm missing something.
> That said, I'm still not clear how the second problem manifests if the old OAuth client creds (housed in the old Workspace org id) are invalid.
As far as I understand, this is not a necessary step. The SP is configured to trust Google's public OAuth IdP, not a specific Google Workspace account. So there are no special secrets shared between the old Google Workspace account and, say, Slack. The Slack org trusts any user that Google's public OAuth IdP says is a valid user in the example.com domain. Slack doesn't have to do any MFA for these accounts, they trust Google did that already.
Now, you may not be able to access the Slack org admin account in this way, say to add/remove users or delete the org. But you can access all of the other information that any random employee in the org could access back when it was setup, including a list of all other users in the org.
1 reply →
>>>The problem is that the original DankStartup has a Google account that they create in #1, and Google goes around telling other sites (via Auth) "this is user X from company Y".
Google is telling other sites that it's bob@DankStartup.com - isn't that true? Isn't this on DankStartup to close down operations cleanly?
It's a different bob@DankStartup.com, and in fact a completely different DankStartup.com. Google shouldn't conflate the two.
There are exactly 0 situations where the current behavior is useful. There is no reason whatsoever to have the exact same auth info for two Google accounts that happen to have the same domain.
7 replies →
Part of my company dissolution process is to renew the domain name for 10 years to prevent exactly this
5 replies →
Sure, but DankStartup failed and doesn’t exist anymore. If I am just a lowly employee, I can’t force the failed startup owners to properly shutdown, and now my payroll information is available to hackers.
What is my remedy?
5 replies →
Login credentials are more than just the email used, and should not be conflated with identity. To be honest I'm surprised google isn't using a uuid tied to the account for the identity given to others, especially since internally google knows and treats it as a separate account that just happens to have the same e-mail. The e-mail should only be used as metadata for contact info.
1 reply →
> They are (or were) refusing to provide any indication to those other companies that these are not, in fact, the same people
That is not quite true, the sub field will be different.
But authors does imply that sub will also change in place for users in step #1, without the workspace beeing recreated. And as such the sub is not usable as a general identifier for the user resource differentiation.
2 replies →
This is not necessarily useful. The sub field only indicates that this is a different user, which maybe protects the private info of the old user. However, a big part of OIDC integration is to automatically allow any valid user registered with the IdP to automatically have access to the corporate account, and to any company-wide resources, which can still include very sensitive information.
If by "same people" you mean recognizing a specific user, yes the sub field changes.
If by "same people" you mean being able to tell whether a new user is part of the same organization, the sub field is useless and no other field has this information either.
Yes but he's saying the data on 3rd-party websites should be deleted by the failed startup when they shutdown not just left to sit there.
He's right, but having failed a number of times, after you've put all your savings into the business, fired all your team, notified and disappointed all of your investors and customers, helped your team find new gigs, filed all the dissolution paperwork, handled all the taxes, disposed responsibly of all of the assets and you now find yourself out of work and often out of cash, occasionally you'll forget to jump through all the hoops to close down all of the SaaS accounts before you stop paying the bill personally to host the email accounts.
Of course perfect world you shut down earlier and in a more orderly fashion, but there are so many cases of companies almost failing and then not, it's hard to shutter a company when there is a chance you may go out of business - especially when you feel you're getting close to another raise or becoming default alive :(
1 reply →
There’s an interesting question on service providers responsiblity who use Oauth for primary auth.
Should they reset all access to a company account if a domain transfers or becomes publicly available?
There are some 3rd party accounts that can be accessed via your SSO or via your personal credentials once you leave. The main ones I can think of is your brokerage account containing your 401K and vested RSUs and your payroll provider like ADP and Paylocity. You still need to have access to past paystubs and end of year tax documents.
3 replies →
I don't see the problem here.
We've already settled on DNS being the auhoritative authentication key for everything. If you bought the domain then you've bought the corporate identity. It's working as designed.
The flaw is the fact that companies go bankrupt and their data should die with them. In case of bankruptcy it might be impossible to hold on to your DNS and therefore risking old company data leaking.
1 reply →
Any domain takeover allows email takeover which allows you to send password reset emails for former employees. Does not matter if it is with oauth or not
And many vendors will send "restart your service today for $x" for months afterwards so data not deleted
Some SaaS ecommerce platforms and email marketing services will likely give a restarted domain entire customer databases ...
2 replies →
Those password resets should have some sort of MFA step.
4 replies →
I agree, I don't think this is a problem with Google's Oauth implementation, it's a problem with the service providers who authenticate users via the mere existence of an email address ending in @company.com without checking if the email address actually belongs to an active employee.
If, when you logged into Slack via Google Oauth with the email address user@company.com, Slack checked with company.com whether user@company.com was a valid user that should be allowed to login, then this problem would be avoided entirely because the defunct company would no longer report any valid users.
This would also avoid further problems with attackers being able to login with unattended email addresses like support@company.com, as was discussed here: https://news.ycombinator.com/item?id=41818459 (There's a lot of discussion below about whether the "sub" claim is stable or not but it's a red herring because of this IMO, also the proposed fix in the article wouldn't address it either.)
How would they check that?
By looking the account up with Google's People API - https://developers.google.com/people
They would have to verify the account is active, AND the id hasn't changed
3 replies →
Either slack or some other third party provider could have a whitelist maintained by IT?
Just spitballing.
1 reply →
This is a misunderstanding of the problem. See my comment downthread: https://news.ycombinator.com/item?id=42701912
"hd" is Google's solution to this problem, and "hd" is also the source of this vulnerability.
I don't think so, but please go ahead and clarify if that is the case.
4 replies →
First of all, the whole point of SSO is that the only and final source on who are the valid active users is the IdP, in this case Google's public OAuth instance. If the IdP says that the current request is coming from the real user1@example.com, you give them access. And Google's public OAuth instance will confirm this even if the current Google Workspace associated with example.com is a different one than a few months ago (though the "sub" field of the attestation will be different than before, which the service provider is supposed to check).
Second of all, even if it was recognized that this is a different user1@example.com, they'd still have access to all sorts of company internal resources, that may still contain sensitive data, especially for small companies which inherently trust all employees.
Google's public OAuth is intended for situations where you want to allow anyone with a Google account to login to your application, regardless of workspace. Given that, it is not a Google OAuth vulnerability that a user can login to your application using a Google account from a different workspace.
If you want to integrate Google SSO into your application and restrict logins to a specific workspace, there are other options you can use that will actually check if the user belongs to that workspace (SAML or internal OAuth).
To the extent that service providers are using Google's public OAuth and then trying to read the domain name out of the returned ID token in order to restrict logins a specific Google workspace, they are using Google's public OAuth instance for a situation it was not intended for because domain names do not map 1:1 to workspaces. However that is a vulnerability on the service provider's side, not Google's.
To the extent that a service provider offers Google SSO integration via Google's public OAuth but also via workspace restricted options, if a company selects the former instead of the latter then the responsibility for the vulnerability is on the company's side. (Slack, for example, offers both because there are some Slack groups where allowing access from any Google account makes sense, and other groups where you would want to restrict access to Google accounts from a specific workspace.)
If the attacker is in control of company.com, checking against this domain would not help.
I'm not talking about checking against the domain, but checking against a directory of active users.
15 replies →
Yes, why the Slack or HR or interview etc. data would still exist while being inaccessible to the original owner is very strange. The article seems to take it as a foregone conclusion that those accounts should all be expected to still exist with all the business data, and I don't know if this is based on the author's experience, or it's just a way to make the vuln sound far more serious than it really is.
On the other hand, I don't think people normally expect that OAuth depends strictly on domain ownership like this. I think most would expect that it depends on some kind of secret being stored on the IdP account side, uniquely identifying the IdP account holder beyond the email addresses presented. With regular password-based authentication, with MFA, you would at least get an MFA prompt if someone had gotten access to your email address and was being sent a password reset code. But with this type of SSO, any MFA verification is done on the IdP side, so if the IdP recognizes anyone who controls example.com as the rightful owner of any claims, then there is nothing you can do as the former owner of example.com.
>why the Slack or HR or interview etc. data would still exist while being inaccessible to the original owner is very strange
Ever been in a company that's collapsed before? Nobody hangs around to shut down the WorkDay account when they've been told they're not getting paid for the last 29 days work.
I get that part, but I'm not sure why they would expire even later than the domain registration and the Google Workspace account. I would expect WorkDay or whoever to close/archive a non-paying account much earlier than that.
Yes, it's a failure on DankStartup's part.
Not really much different than a user buying dankstartup.net, setting up a catch-all email, observing what comes in, and performing password resets for those accounts, allowing for account takeovers.
Calling it a vuln in oauth may be a bit hyperbolic, but Google could help prevent it.
I have catchall email accounts in every domain name I own (mostly so I can do differentiated emails for every service to track/combat leakage), and you would not believe the amount of emails I get that are intended for previous domain owners (and typos too). I haven’t actually done any reset password flows, but there are a bunch of social media and SaaS accounts I could easily take over if I wanted. I used to try to track down whoever the emails were intended to go to and forward it to them and let them know to change it, but that got to be too tedious so nowadays I just ignore them.
Still, I wouldn’t call this a vulnerability on the service provider’s part, it’s just user negligence.
> Suppose DankStartup folds … Isn't that a failure on DankStartup's part, to not shut down their business accounts?
Expecting an entity that has already failed* to not fail again isn’t an effective security control, unfortunately.
* - not every startup that folds has “failed”, but the point still stands
>Expecting an entity that has already failed* to not fail again isn’t an effective security control, unfortunately.
Sure, I'm sympathetic to that, but again I don't see how that's within the scope of oauth.
I register a Google Workspace and add CorpDomain.com to it. I then use that to OAuth to other companies (e.g. Slack, payroll companies, etc.). Then my company goes under or closes up and the domain lapses.
Someone else comes along, registers a completely different Google Workspace but attaches that same domain to it. The e-mail address is the same, but it's obviously a new Google Workspace with new people, new payment info, new users, etc.
Google knows that these are two different workspaces and that there is effectively no connection between the two other than the domain, but they are not presenting that information through OAuth (which is possible) so other companies are not able to do any sort of diligence in ensuring that the correct people are accessing that data.
OAuth provides the capability to make this distinction, but Google is (or was?) refusing to provide data to other companies to allow them to make that distinction.
This sounds hyperbolic, but Google is effectively lying to these other services that that someone else is in fact the original person that service expects, even though Google knows full well (or is capable of knowing) that that is almost definitely not the case.
6 replies →
If a security mechanism doesn’t account for failure cases, it’s a failure of the security mechanism.
It’s a hard problem to solve and I don’t have a solution, but it’s a core goal of every security tool to account for edge cases and failure cases like this. If you tell me that OAuth is completely insecure due to a security issue, it’s not going to make me feel any better if you say “but it’s totally not OAuths fault” - I don’t care who’s fault or scope it is, the end result of a security issue is the same, and to avoid it I’m just not going to use OAuth.
2 replies →
The contention isn't that you can impersonate DankStartup, that's obviously not a vulnerability since you are indeed the domain owner. It's that former entities with DankStartup accounts might have used OAuth to create relationships of their own. And when the startup folds, they don't magically disappear.
Basically if Sally, the CTO of DankStartup, signed up for Taskrabbit or whatnot, it's possible for you as the owner of the domain to impersonate Sally in the context of that relationship.
Obviously the root cause here is that someone misused an account to do something not related to the business. And the actual impact is probably low since high value services tend strongly not to take tiny email domains as identity roots (i.e. sally@dankstartup.com clearly doesn't have a Vanguard account to steal).
So... like most security announcements it's oversold and spun. But it's real enough as I read it.
Why do you assume sally@dankstartup.com doesn’t have a vanguard account? I’ve absolutely had similar retirement account logins that became difficult to access once I left that employer. Had to contact HR and get them to help me log into my account. If the company had folded during that timeframe I would’ve been screwed. Of course for financial institutions you can probably recover your account through some identity proving process, and generally money transfers require a second factor sms auth, but a domain takeover would probably have been sufficient to at least get someone logged in and able to see my account balance.
> I’ve absolutely had similar retirement account logins that became difficult to access once I left that employer.
Yes, but your employer's email domain wasn't repurposed. It's still an operating business, and the account is still there, and still yours. And for accounting reasons they still remember who you are and can recover your important information for creditors, etc... The fact that it's difficult for you to access that account is a feature and not a bug, because it means it's difficult for others too. But you can, and people do all the time.
The case here is failed businesses who have abandoned their domains and employee account history. Almost by definition that's a violation of financial regulation already. And this, btw, is the reason why DankStartup employees couldn't use their work emails to open Vanguard accounts.
> Basically if Sally, the CTO of DankStartup, signed up for Taskrabbit or whatnot, it's possible for you as the owner of the domain to impersonate Sally in the context of that relationship.
I don't think this is the issue, unless someone went to some pretty extreme lengths. Configuring OAuth such that the company Google Workspaces account is recognized by Taskrabbit as a valid SSO option is not as simple as signing up to Taskrabbit with your company email instead of personal email.
Even then (in my experience) it's pretty common to setup an email based account and it will auto link to an oauth one that already exists. Even if Google revoked oauth, many platforms let you use the email directly to login
1 reply →
That sounds like a TaskRabbit vulnerability (in your example), not a Google vuln? It is also a vulnerability in any email based sign in, which relies on email alone without a password to demonstrate account ownership. (Including password resets that rely on email).
Besides the github account with a legitimate name, but impostor ownership, I can imagine another case which is problematic. HR SaaS companies might be required by law to maintain the account for a period of time - let's say until the end of the next fiscal year. The account still existing is not a failure on either Google, the SaaS company or DankStartup. The problem, as other posters mentioned is the fact the new account has the same ID in OIDC as the previous one, which is what the author of TFA proposes.
And not only that, almost every form of auth has the same vulnerability not just log in with Google. If you own the domain, you own the email IDs as well and you can very likely reset password.
Yeah, this is the part I'm struggling with. This is absolutely not unique to google oauth, it genuinely seems like a misunderstanding of how the web manages trust.
If you own the domain, you own all the property associated with the domain, including all the old email addresses. Magic links and password resets are all going to give the new owner access.
Your best bet as a solution is to be using strict 2fa (ex - a yubikey might help here) but even that is likely just "a conversation with support" away from being circumvented.
This is why winding down a company is supposed to have specific stages and policies associated with the dissolution. You don't just abandon the offices and leave all the filing cabinets behind either, for similar reasons...
I don't think the claim is that Google has introduced a totally novel vuln, just that they are a stable, trusted middleman who is failing to mitigate a common vuln where they can.
You don't abandon filing cabinets, but given that some percentage of startup failures are sudden and surprising and the people who could do something are unmotivated / unable to, it's not a best practice for a commercial landlord to put abandoned files on the street with a sign "free", files and all. Maybe they have a legal right to, but it's not how I would operate in that situation.
It seems to be at the registry level. But registries do show changes in owner [implicitly at least].
Maybe there needs to be a way to do some signalling/lookup when domains changes hands.
Sounds like a job for a blockchain, lol.
> Magic links and password resets are all going to give the new owner access.
Which is why you should never exclusively rely on either for sensitive services.
1 reply →
The scenario I was envisioning was a simple as a developer that worked at that startup added DankStartup email to their Github account, committed a bunch of code. Company shut down, but dev doesn't think to disassociate that domain/email. Malicious actor uses this technique to then sign into the Github account, gaining access to that developer's account, not just the DankStartup repos which were probably disabled after non-payment.
Now, obviously some fault in that scenario lay with the person who 1) used the same account, and 2) didn't remove the old email once the startup failed. But I'm just using that as a kind of example - there may be other accounts as others have said that need to be accessible years down the line, like financial records and the like, regardless of whether the company is still around.
> DankStartup's O365,
If you wanted to try to re-take over a pre-registered domain in Azure/M365, you would need to involve Microsoft Support who would require you to prove via government documentation that you were the same entity for the now-abandoned Azure/M365 account.
Creating a new tenant using the same public domain won't get you access to the Azure/M365 tenant of a previous customer, you would have a different internal domain name (dankstartup2.onmicrosoft.com).
At best you could register your domain post-expiration of the previous tenant and impersonate them >90 days out.
It's similar to Gmail or Hotmail or Yahoo Mail hypothetically allowing a new user to adopt an abandoned email address. Most email services don't allow this for this very reason.
Third parties is google as single sign on. If such an org/domain is abandoned, a malicious person could 'resurrect' the accounts on those third party sites. It's kind of like a similar situation where a user deletes an email account and then someone else creates an new one in its place, and now they have access to all the third party password reset links. Except in the case linked above, the user never had the ability to delete their accounts before off boarding, and the abstraction isn't just an email, but the account itself.
In emails case all the larger providers I'm aware of retire addresses to prevent this sort of abuse, probably learned the hard way. Could Google OAuth do something similar here?
It now occurs to me that large businesses might have the same issue with emails and former employees (easy to imagine John Smith departing and at a later date John Smith being hired) so I wonder how they typically handle this.
Companies generally don’t reuse emails. If you come back, you can sometimes get your old email and access to your old enabled services.
I know when interns were at Amazon and left, their accounts were disabled. But when they came back, they got their old accounts back and the related Slack users
My father changed careers and dissolved his business over a decade ago, at which point he let his old domain lapse.
A couple years ago, I began to wonder if anyone was still trying to reach him, so I bought the domain (domain squatters weren't even interested in it anymore) and setup an inbox for his old email address. In less than a week, the unread count was in the triple digits. It was basically all marketing and spam so I closed the inbox within the month, but multiple years with a 100% bounce rate is apparently not enough to deter LexisNexis & friends from trying to win him back.
This is a corporate planning/governance problem, not a vulnerability in Oauth, and I bet the problem is even bigger than TFA describes since any previous domains of a company that were almost-but-not-completely migrated away from could easily be taken advantage of, possibly to even greater effect since the company likely has a bunch of systems still up which have the domains whitelisted. (Which makes me wonder if there are hacking groups who use domain squatting as a front or side-gig while they take advantage of lapsed corporate domains.)
This is very much a critical flaw in systems which rely entirely on email or domain names as the sole security factor. OAuth itself is flawed in that it allows this terrible practice, though to be fair it does discourage it. Google's specific OAuth solution encourages this compromised practice even more, because the only identifier it provides for a user group is the domain name associated with the account (in the "hd" field). For individual users they at least provide a "sub" field with a unique user ID (though per the article, it seems this is possibly flaky, or at least misunderstood) - this could be used to make sure that a new user@example.com doesn't get access to the old user@example.com account. But to check if a new user should have access to the organization account, there is nothing that Google provides that can be used securely: all they tell the service provider is that this is a new valid user for the example.com org, not that this is a completely different example.com org.
That's a really good point. Perhaps the protocol should be expanded with an explicit identifier unique to an extant legal entity (or string of identifiers, to account for ownership changes like acquisitions), so it would be easy for SSO-enabled applications to keep previous tenants' data safe from someone who just buys the domain later on.
Of course, this would still rely on the provider: it might be a great solution for large providers like Google which can implement ironclad formal verification procedures, but if you and the previous company self-hosted SSO, you control the response and can impersonate them completely.
1 reply →
Is this basically equivalent to registering a domain, setting up email, and getting services to send you password reset emails to recycled addresses?
What if DankStartup doesn't fold and just forgot to renew their domain, or lost control of their domain for some reason. OAuth shouldn't let you Auth someone else's account just because you can hijack their domain.
I don't think it would be 100% on the failed startup considering most of, if not all, of the applications mentioned likely do not actually delete accounts even when you say to delete them. There probably could be some allowance made for the situation but also you're repurposing the domain of a failed startup.
I don't think the problem was necessarily with Google though as I believe they create a unique ID for the domain. The problem with be with the other services like ChatGPT, Slack, etc that associate with the domain and create accounts for each user in the domain.
it's vital to have extremely skilled and nuanced people managing bug and security report triage because it seems many can overlook the complexities being given.
It is an "ACL vulnerability ".
ACL as in access control list.
Bell-LaPalda and multi-level access control systems both required a trusted controller and, And, AND a trusted arbiter of a state machine.
It is the state machine that magically got expanded into a couple more states, with the introduction of an imposter admin actor.
So yeah, the trusted arbiter and owner of that state machine (Google) did an oops.
This is something that Keberos (KRB5) was designed to protect against.
> a failure on DankStartup's part, to not shut down their business accounts
They seized operations, why should they be responsible for any other assets?
I mean ethically yes of course. But there's no law/obligations to make sure domains are closed.
whats is TFA ?
"The F-ing article" (derived from old internet slang "RTFM", for "Read the F-ing manual", a thing that new users were prone not to do before getting online and asking questions easily answered by RTFM.)
thanks
"The f___ing article"
In polite terms it can also mean “the featured article”. And IMO it makes more sense to read it that way in a top-level comment.
Whereas reading it as the f’ing article makes more sense when the word “TFA” is used in a response to another comment like “well, you say that but TFA said such and such”.
2 replies →
thanks