Hacker News new | ask | show | jobs
by ghnws 752 days ago
Having two almost identical terms that mean completely different things is not a very good idea. Also here you are explaining what the words mean, when "login" and "permission" are immediately obvious. Most people don't speak english natively either.
18 comments

If you think two different words having different meanings is difficult, wait 'til you hear about contranyms! English is full of words like these, where context is needed to understand the meaning.

If something is fast, it moves quickly or not at all. Cocktails can be garnished, but so can wages. Sales or trade of a product could be sanctioned by one country, but sanctioned by another.

I generally think it is a good thing to communicate clearly. Sometimes that means using words differently to explain something. Other times, that means using words the same way as others. I think this is a case of the latter.

Also, I think the idea of "native speaker" is a bit of a red flag. There are plenty of people that speak English from birth but are utterly unintelligible, and there are plenty of people that speak English as a second language who speak more clearly than those.

>wait 'til you hear about contranyms! English is full of words like these, where context is needed to understand the meaning.

It is, unfortunately, possible for more than one thing to be bad at a time.

When I'm at a restaurant and I don't see anything I like, I just order something "off the menu".

When I'm at a restaurant and I like everyone I see, I order something "off the menu".

The first is "off-menu", and the second (for which I don't think you meant "everyone") is "from the menu". So, no...
People really do say they “ordered something off the menu” when they found the item on the menu. I believe I could usually distinguish the two meanings if I heard a recording. If the item is not on the menu, the word “off” would be stressed.
In Australian english, "off the menu" is perfectly normal vernacular in non formal settings.
So essentially you order off the menu based on your surroundings?
Something can be held fast, but I don't think it is usual English to say that something fixed is fast.

Garnishment of wages is garnisheeing, though here I'll agree "garnishing" seems to be acceptable too.

Something "made fast" is perfectly reasonable usage for tying it in place.
Yep. And something "made fast" is also perfectly reasonable usage for vastly upgrading its speed. "Fast" can absolutely be a contronym.
I think two-word contranyms are more concrete, like "fight together".

Oversight is a less ambiguous example of a single-word contranym.

I've heard "fast" as a contranym to "moving quickly," referenced as "to fast" or "fasting." ie: not eating at all.

Edited to add: Sticking with the context of food, "fasting from food" contradicts someone being a "fast eater."

"Fasten your seatbelt" doesn't usually mean "twirl it wildly above your head".
Sanction and nonplus are the most insane examples, because sometimes it's literally not possible to figure out from the context which of the two opposite meanings is intended.
> Also, I think the idea of "native speaker" is a bit of a red flag

I assume you mean “red herring”. Red flag just means a sign that something is wrong.

I sanction this comment.
I don’t really consider making an API call as “logging in”. The term sounds really out of place other than in a few specific contexts.
The term “Identify” is a lot better in this regard.

It’s already universally used in IAM, where the other half of the puzzle is also clear and free from ambiguity: “Access”.

Identification and authentication are different, though. You identify yourself to a website as a specific user (e.g. using a username) and the website in turn authenticates your claim, i.e. verifies that you are in fact the user you claim to be (e.g. using that user's password).
If you go that route .. your OIDC provider authenticates your claim. The website just trusts some specific OIDC authorities which you must use to create your identity.
If the website in question is using OIDC, sure.
And the third half, “management” verbalizes the action therein.

Also, IAM has a cryptic assertion of ultimate authority: In Hebrew, . . . hayah carries the added weight of representing God himself: Yahweh, “I am.” [0]

https://hebraicthought.org/meaning-of-gods-name-i-am-exodus/

Identity/identify may or may not have anything to do with Login, or Authentication...

KYC (know your customer) are about removing the ambiguity between you user and their identity....

What could be a difference between identification and authentication? In my understanding they are completely synonymous. I frequently use an IdP (identity provider) to authenticate for web applications.
Know your customer is something that started in banking and is leaking everywhere.

Identity is who you really are. Be that you as an individual or as a corporation.... In the case of your bank they have a copy of your ID, your SSN, for them identity is what established the account and auth lets you work with it.... AWS might know some members of your company (either by corporate or individual card) but might not know your identity (as an individual) and yet you can still authenticate, because you have been authorized by an identified customer. I can transact with crypto as an authenticated user and NOT be identified.

In some circles "identity" is a term of art. For instance an identity provider maps credentials to user accounts. Those may or may not map to a government-numbered human.
I think authentication is about proof of identity. Identity can mean a lot of things imo. Applications identify me all the time without me giving them any proof of who I am. This happens in meatspace all the time too. People project identity and we make assumptions about what we observe. We don’t necessarily ask them to verify this identify through mutually agreed upon terms.
KYC is not so much about removinh ambiguity. It's about risk mitigation and proof. Not only about a specific user, but also the connections of a company or a person. There is also a lot of rules and laws behind against AML and PEP checks.
Access doesn’t cover everything though. But identify seems good
I think they mean use both - identity in place of login/authenticate and access in place of auth
Yeah, but access to me feels like access to records. Not necessarily permissions to do certain actions (in general or to certain records)

Iirc, Java or J2EE used “Principal”, which I found super confusing

Principal is Identity not access.
Indeed. "Logging in" implies some kind of long lasting session. And logging in conceptually only requires "identification" (e.g. via a username) but not necessarily "authentication" (e.g. via a password)
Identification is not necessarily via a username, people can identify you via just knowing how you look or your voice, the method doesn't matter.
IMO…

To “log in” is to convert the username/password pair (or API key, or whatever) into a smaller token with an expiration. Doesn’t matter of it’s put in a cookie in my browser, held in memory by some other API client, etc.

Aside: Why bother even doing that? Because every time you transmit the credential, there’s the possibility of leaking. We would rather leak the token that has an expiration.

The wild thing is that they’re apparently from different etymologies. “Authorization” comes from “auctor” in Latin, meaning “leader” or “author”, whereas “authentication” originally comes from the Greek “auto” meaning “self”. There probably was some cross influence that brought them into line though.
I'm going to call IAM "Classics", with "Latin" for identity and "Greek" for access.
I don’t think they are almost identical, they just have the same prefix. “Login” and “permission” each have the same problem: “login” is very similar to “logging”, and “permission” shares a prefix with “persistence” (or permanent). Ultimately software engineering is a broad enough field that we will necessarily have to use similar words to describe the many, many concepts
The issue is that they have the same prefix AND that unfortunately this prefix is used to abbreviate both words.

What does the "auth" module ?

We shouldn't use that abbreviation, then.
Given that _AuthN_ and _AuthZ_ are in common technical use, I would expect something handling _Auth_ to work on both _AuthN_ and _AuthZ_.
me, reading thread on hacker news, where a different team that used to build the auth service just transferred ownership of the service to my team, which builds the authz service....
Not a good analogy.

“Permission” and “persistence” have the same prefix but entirely different semantics. They also occur more commonly in everyday life.

AuthN and AuthZ are similar in in spelling, appear in similar contexts, and are less colloquial, making the distinction a lot less clear.

There’s a reason many junior devs use them interchangeably without knowing better.

Okay fair enough about it not being a perfect analogy.

I think the reason junior devs get them confused is that many junior devs are never taught anything about either in school. But then you just tell the junior dev that they mean different things and in my experience they only need to be told that once.

Ultimately I think it’s fine to use vocabulary.

But authentication and authorization are often used in the same context where confusion is lethal.
Why would it be "lethal"?

As a dev you're either building or hooking up to either or both of them. And you know what each requires you to build / hook up to.

As a user, you just care "I put my login/password/api key here, and I get the capability to do several things in that webpage/service/etc". Both auth and the other auth are handed for you.

Ever heard of a hyperbole?

And if the other dev made an error and confused authorization and authentication you have a problem.

Stupider mistakes have been made and it is a sign of overconfidence if you think you are immune to them.

>Ever heard of a hyperbole?

Yes, primarily I've heard that it is to be avoided in technical discussions...

The real problem is people don't have clear differentiation between authN and authZ. You being you doesn't mean you or they consent to something, those are separate, though very close.

Hence the confusion and ambiguous shorthand "auth". You auth and gets everything. You fail to auth and you don't have access. That covers ~80% of any authentication-authorization-accounting systems use cases, and that allows people to be care-free about differences.

"login" refers to the record of access¹, not the access itself, so it is more properly associated with audit. This dates from the early days² of time-sharing systems when you didn't need a password, you were just saying hi to the computer.

__________

[1] Derived from the signing of a ship's logbook³ when coming aboard.

[2] A few decades ago.

[3] The logbook originally⁴ recorded navigational data and is named for instruments measuring speed through water⁵, of which the simplest is literally throwing roped wooden logs off the stern and counting the knots on the line paying out per interval⁶.

[4] Doubtless some bright-eyed young hornblower with a glittering future career as an admiralty archivist realised that log-structured records could be generalised usefully to all timestamped event and measurement capture, which is why your syslog is full of crap.

[5] Consequently any vessel, maritime or otherwise, measures its speed through the medium in knots. The Enterprise NCC-1701-D, for example, tops out ca.146 megaknots under impulse engine.

[6] It follows by transitive etymology that you may use the term "knots" to edify and delight your colleagues when referring to the rate of creation of user sessions.

offtopic, but: I think when your footnotes themselves need footnotes, there's probably a clearer way to write what you wanted to write. Jumping through multiple levels of nested footnotes is fairly hard to read, at least for me.
Indeed; they are log-structured.
It's most likely not that they needed footnoted footnotes, rather that they wanted them and structured their post on purpose to create them.
That's because they share the same root auto-, i.e. "self". Because they're related concepts...
Apparently not.

> “Authorization” comes from “auctor” in Latin, meaning “leader” or “author”

https://news.ycombinator.com/item?id=40493073

> Most people don't speak english natively either.

This is a problem with only one solution: continue to improve one's skill with the language. You can't solve this by choosing different terms, because then something else will be the "this is confusing to non-native speakers" hangup. You can whack those moles until the day you die and you'll never get them all.

I disagree. To authenticate something is to challenge it to prove its identity. Authentication is much broader in scope than "login," even within the narrow domain of computer science. JWT signing, domain certs and so forth fall under the "authN" header and use the same cryptographic tools and techniques... even many forms of user authN don't have a "login" flow.

Why would we choose "login" - which is more of a special case than the norm to describe something we already have a precise term for?

If words being similar is truly an issue we would have vastly different languages.

Related words for related concepts is very normal, and if you are a professional in this space it's the least we can do to recognize the difference. We aren't astronauts, we have the time to figure it out.

Language learners already learned a second language, they have the skills to figure this out. At least it's not a homonym.

Most people literally do speak English

https://www.google.com/search?q=most+popular+language+in+the...

but the rest of your point is dead on.

Sorry I don’t understand - the link you posted shows that “most people” actually speak mandarin and Spanish?
Parent provided a poor link by just using a Google search results.

https://www.visualcapitalist.com/top-languages-spoken-in-the...

English is not the most popular 1st spoken language, but it is the most spoken language overall.

1.5B speakers is still not "most people", even if it is the most spoken language. To be clear none of this matters, but there is nothing more irritating than seeing a nitpick of a nitpick that is still wrong.
That makes more sense. Thanks.
'permission' might be ok, but 'login' is very imprecise and much more ill defined than authenticate.
> Having two almost identical terms that mean completely different things is not a very good idea.

What's the problem of telling apart the task of authenticating users from authorizing their access?

There's already identification and authorization (IAM) which is mostly a backronym.

Identification & Authorisation are a better pairing here than Authentication and Authorisation.

This way, if someone says "Oh yeah we have an auth module on this site" you don't need to immediately disambiguate the statement.

But then "auth" itself is ambiguous. So it might make sense to get rid of the lot. "Identification" is a good word for the first. Perhaps "Permissions" for the second?

authn -> ident

authz -> perm

So much clearer.

In the case of “auth”, it stands for two related but often separately managed operational processes.

From an end user perspective, auth is the problem. Users can’t determine what is login vs permission. If non native speakers can’t handle the distinction, it’s a valuable lesson to learn.

Login is not obvious. A login is usual a process step before the main part of the process. That does not fit to an API call which is authenticated using a token.
Well, in that case, we are all going to have to talk about the difference between a "product manager" and a "project manager" ;)
what's the difference between login and logon?
I believe “login” is the process of actually logging in, or the set of credentials used to log in. “Logon” refers to the act of connecting to something. They’re often used interchangeably, though.
Except then I won't be able to flip the bozo bit on people who confuse authentication for authorization in conversation...
You're saying that they are almost identical because they share the first 4 letters.... That's a pretty low bar.