CSRF is not as big of an issue as it used to be, and when it is an issue it can be solved more easily and comprehensively than XSS:
1. The default value for SameSite attribute is now "Lax" in most browsers. This means that unless you explicitly set your authentication cookies to SameSite=None (and why would you?), you are generally not vulnerable to cookie-based CSRF (other forms of CSRF are still possible, but not relevant to the issue of storing tokens in local storage or cookies).
2. Most modern SSR and hybrid frameworks have built-in CSRF protection for forms and you have to explicitly disable that protection in order to be vulnerable to CSRF.
3. APIs which support cookie authentication for SPAs can be deployed on another domain and use CORS headers to prevent CSRF, even with SameSite=None cookies.
On the other hand, there are no mechanisms which offer comprehensive protection from XSS. It's enough for a single JavaScript dependency that you use to have a bug and it's game over.
For this reason, OAuth 2.0 for Browser-Based Applications (draft)[1] strongly recommends using a HttpOnly cookie to store the access token:
"This architecture (using a BFF with HttpOnly cookies) is strongly recommended for business applications, sensitive applications, and applications that handle personal data."
With regards to storing access tokens and refresh tokens on local storage without any protection it says:
"To summarize, the architecture of a browser-based OAuth client application is straightforward, but results in a significant increase in the attack surface of the application. The attacker is not only able to hijack the client, but also to extract a full-featured set of tokens from the browser-based application.This architecture is not recommended for business applications, sensitive applications, and applications that handle personal data."
And this is what it has to say about storing the refresh token in a cookie, while keeping the access token accessible to JavaScript:
"When considering a token-mediating backend architecture (= storing only access token in local storage), it is strongly recommended to evaluate if adopting a full BFF (storing all tokens in a cookie) as discussed in Section 6.1 is a viable alternative. Only when the use cases or system requirements would prevent the use of a proxying BFF should the token-mediating backend be considered over a full BFF."
In short, the official OAuth WG stance is very clear:
1. HttpOnly cookies ARE better in terms of security.
2. Storing Refresh Tokens in local storage is only recommended for low-security use cases (no personal data, no enterprise compliance requirements).
3. Storing short-lived Access Tokens in local storage should only be considered if there are technical complexities that prevent you from using only cookies.
Huge access tokens, slow validation AND bad security at the same time, boy we must be lucky.
- Encrypted JWT when saving sensitive information in cookie? Good start...
- ... Using Asymmetric encryption? Oh no...
- RSA-OAEP: At least it's not PKCS#1.5 amirite?
- Same RSA key is used for encryption and signature(?) Not great.
- Stateful Access Tokens: well...
I'm not sure how I feel about using stateful access tokens here at all. Since there is already a KV dependency, there are some advantages to storing stateful access tokens in the KV, most importantly you can easily revoke the tokens directly by deleting them. Revoking stateless tokens, on the other hand, is quite hard and not something that most web applications would care to implement.
The most common trade-off (and indeed, half of the raison d'être for OAuth 2.0 refresh tokens) is to have a very short-lived (e.g. 5 minutes) stateless access token and a long-lived stateful refresh token (which OpenAUTH already does). Revocation would still come with some delay, but you won't be able to use an outdated token for a long time after the user logs out or changes password. This is an acceptable trade-off for many applications, but I'm not sure if it's right to offer it as the only solution in a software package that wants to be generic: many applications will have compliance requirements that could rule out accepting logged out session tokens for such a period.
- JWT in any form or manner
The elephant in the room. Since JWT allows you to choose your own algorithm and offers some some rather bad options, using JWT can be considered as "Rolling your own crypto Lite". You have a lot of choices here and if you are not an expert you're bound to make some wrong choices: such as the ones I've listed above. If OpenAUTH had used PASETO for its tokens, it wouldn't be running into these issues at least since no clearly insecure options are available.
If you do use JWT, for the love of all that is good, never stray away from this path:
1. For symmetric tokens, use the HS* family of algorithms. That's the only available option anyway.
2. When using HS256/384/512, you should use randomly generated secrets from /dev/urandom [1]. The secret size in bits should be the same size as the HS algorithm bits (i.e. 32 bytes for HS256, 48 bytes for HS384 and 64 bytes for HS512). In any case, you should NEVER use passwords as the HS256/384/512 algorithm secret.
3. Do not use asymmetric tokens unless the there are are multiple token verifying parties which are separate from the token issuer. If the token issuer is the same as the verifier, you should use a symmetric token. If you've got one issuer and one verifier, you should probably still use a symmetric token with a shared secret, since there is no issue of trust. Asymmetric cryptography is always an order of magnitude easier to screw up than symmetric cryptography.
4. If you do use asymmetric cryptography, always use Ed25519. If you are forced to use something else for compatibility, use ES256/384/512. It still has some issues (especially if your random number generator is unreliable), but it's still better than RSA. You really want to use Ed25519 though.
5. If you want to encrypt JWT, don't. JWE is too hard to use correctly, and the only reliably secure option that is usually implemented by libraries (A256GCMKW) is slow and it's not very popular so I'm not sure how much analysis the algorithm (AES Key Wrap) has seen.
6. The best and easiest option for encryption if you really must use JWT (and can't use PASETO): Just take your payload, encrypt it with NaCl/Libsodium (secretbox[2]), base64 encode the result and stuff it inside a JWT claim. This will be faster, easier and more secure than anything JWE can offer.
There is already a closed ticket about JWT usage. Unfortunately the ticket author did not point at any specific weaknesses besides revocation to which the app author answered:
"JWTs aren't innately problematic - they come with the tradeoff of not being able to be revoked. The ideal setup is setting a short expiry time on the access_token (eg 5min) and setting a long expiry on the refresh token (which is not a JWT and can be revoked)."
The fact that this tradeoff is acceptable to some apps is correct. But I disagree that JWT tokens aren't innately problematic. Stateless tokens aren't innately problematic. Even stateless access tokens aren't innately problematic if you're willing to live with the tradeoffs (revocation delay or a centralized/propagated revocation list). But JWT is innately problematic, in the most literal sense possibly: the very nature of the JWT specification is to permit the largest amount of cryptographic flexibility including supporting (and even recommending) insecure cryptographic algorithms, that may cause security problems if chosen. In other words: it is innately (= in its very nature) problematic (= has the potential of causing problems). JWT is the poster child of being "innately problematic".
I think the app author confuses "innately problematic" with "impossible to implement securely". JWT is not impossible to implement securely. After all, even SAML with the nefarious XMLdsig is possible to implement securely and we do, in fact, have secure implementations of SAML. The real problem is that JWT is hard to implement securely if you do not have the right expertise. And OpenAUTH is giving us (yet another) clear example where the JWT implementation is less than ideal.
I will be the first to admit that I am not expert enough to know how to hack this kind of cryptography, but I am also not good enough to prove that it is safe to use.
I think Chomsky's theories became popular in anglophone linguistic circles (and later in the rest of the world) because their math-like structure and close applicability to computer science. They've proven to be useful in some cases, but there has been no proof of a universal grammar. The fact that you can create a formal system to represent an idea, is not a proof by any stretch of that definition.
This is why some people would even go as far as classifying Chomsky's theories as pseudo-science (see one of the replies to GP). I wouldn't go as far, but considering the almost toxic disdain Chomsky himself has to every linguist who is not interested in researching his supposed Universal Grammar (he has famously compared structural and functional linguistics to "butterfly collectors"), we should view this theory with more criticism.
Well, the real issue with Chomsky is that he came into vogue during the “linguistic” turn, except he misunderstood the anglo philosophers, thinking their theories had a natural basis, and misunderstood the french, thinking that their studies of writing and discourse made them philosophers of language. But the Kantian project still stands, one must have an architectonic, before one can make a scientific approach. But Kant was always sure to set his critical project within its dialectic, and placed the basis of cognition below language and discourse. That is what the French were able to capture, and its why contemporary philosophy today is so suffuse with discourses on aesthetics (though I’m being a bit broad with what I refer to as “Philosophy,” perhaps it’d be better to say “philosophical work”).
> When talking about someone or something external to you, Tibetan grammar forces you to express whether what you’re talking about is something you’ve experienced or seen with your own eyes, whether it’s an assumption you’re making, or if it’s something that is generally true to everyone else.
The grammatical category the author describes here is called Evidentiality[1], and it's surprisingly rather common[2], but most European languages, especially the popular ones, don't have a system like that as a mandatory part of their grammar.
> In Tibetan, there is an honorific language that goes beyond the French vous or the Spanish usted. Rather than conjugating the verbs differently to indicate politeness, many words are modified, or can even be entirely different, to indicate honor itself. For instance, you can have a regular picture (par) or an honorific picture (kupar) of, say, your lama. There’s even a way to talk about an honorific dog. However, you never use honorific language when talking about yourself. Instead, you can use humble language to help you decrease your sense of ego importance.
Honorifics are also common in many other languages. Japanese also commonly use noun prefixes (especially "o-" and "go-"), while Korean has honorific versions of some particles (e.g. the subject marker "-i/-ga" turns into "-kkeseo". Korean also has many speech formality levels (at least 7 different levels AFAIK), while Japanese has 3 or 4. Both languages have a highly developed system of plain, honorific and humble verbs, where most verbs are modified in a regular manner, but some common verbs are completely replaced by another verb for the honorific or humble version. Tibetan also seems to have a honorific verb system, but I don't know if it's as developed as the ones in Japanese and Korean.
[2] https://wals.info/chapter/77 - WALS is not extremely accurate and in my experience it tends to overestimate features that are not fully grammaticalized, but I think it is safe to assume at least 50 out of the 418 languages languages have an evidential system that is as developed as Tibetan's.
It's also worth mentioning that although English doesn't explicitly require you do do any of this, we generally have ways of conveying respect/familiarity (by tweaking the formality of our register).
Roman Jakobson (probably one of the most important linguists of the 20th century) has famously said: "Languages essentially differ essentially in what they must convey and not in what they can convey".
I think this sums up the weak version of the Sapir-Whorf hypothesis quite well. The strong version of the hypothesis claims that monolingual speakers of a certain language find it hard to think of concepts that cannot be expressed by their language. But as Roman Jakobson hints, with enough effort you can express most concepts in most languages. Quite frankly, I'm not aware of any evidence of this strong form of linguistic determinism, except for Daniel Everett's research of Pirahã[1], which is rather controversial.
The weak version of the Sapir-Whorf hypothesis is more interesting, but most of the research I've seen was on pretty boring (in my opinion) subjects that seem to appeal to a modern European audience. In other words, it's mostly about color and grammatical gender (obviously only when that gender is Masculine, Feminine and Neuter, not something too foreign like Bantu noun classes).
The most interesting research I remember reading was on the Australian Aboriginal language Guugu Yimithirr, which uses a cardinal direction system. Instead of using the relative direction "left" or "right" to describe the location of objects in relation to you, you'd have to use their compass-direction like "The tree that is westwards of me" instead of "the tree on my west". That pretty clearly forces every Guugu Yimithirr speaker to have to be constantly aware of the compass directions so they can clearly point at things, it's quite unsurprising that they are very good in instinctively knowing where the north is without a compass.
>That pretty clearly forces every Guugu Yimithirr speaker to have to be constantly aware of the compass directions so they can clearly point at things, it's quite unsurprising that they are very good in instinctively knowing where the north is without a compass.
Apparently you can't even greet someone unless you know the cardinal directions - an article I read in New Scientist claimed that a greeting is essentially telling which direction you came from and in which you are headed.
Be that as it may, I can easily believe that this feature of the language forces you to keep track of directions, after something I experienced: I was always good at keeping track of directions myself, I could walk around in sunless cities for hours and always know which direction I should go to get back to where I started. I could do this while driving too (I also traveled to other countries and drove around in many unfamiliar cities).
But then GPS navigation systems arrived. Convenient, I thought. Until I realized I had completely stopped tracking cardinal directions unconsciously. I haven't used car navigation since that hit me, and it was actually hard to get back into the habit of keeping track of where I am. I'm not sure I will ever again be as good as I used to be.
The problem is that it doesn't really train it - in a way it's the opposite. I've heard about someone using a belt which vibrated like that. After using it for a while they felt completely lost without it and lost all feeling of direction.
You actually need to let your brain do this for you, external input stops that. Though of course it would be nice with something like that, in general, if you could actually rely 100% on it.. which you can't, with GPS (in cities the direction may suddenly switch, for example, due to buildings playing havoc with the signal)
The strong version is disproven in the original paper: they mention concepts that cannot be expressed in English and then proceed to explain them. In English.
English grammar also has features for expressing uncertainty, unreality, hypothetical, wishes, demands with uncertain outcomes etc. by use of the subjunctive mood.
"If I were a bird, I would be able to fly." (were, not was)
"God bless you." (bless, not blesses)
"The teacher demands that students be on time." (be, not are)
Though many native speakers, even very intelligent ones, fail to properly use subjective mood at a high rate. Or otherwise do not recognize it. As some of the other comments note, there are some interesting differences around what a languages grammar will strictly enforce, where as in English, proper use of the subjunctive mood is less strict. Obviously, this is also far less expressiveness in English around this in grammar than there is in other languages.
This reminds me of a sketch by one of my favorite comedians, which roughly translates to this:
"May i thank you for this nice cup of coffee?"
"Go ahead"
"I want to thank you for this nice cup of coffee."
"Go ahead"
"Thank you for this nice cup of coffee."
"No thanks necessary"
"But i explicitly wanted to give you my thanks!"
"Sorry about that."
"Well thanks for nothing!"
"You're welcome"
"You've shown a complete lack of poor judgment. I have no confidence in your ability to screw things up. You are incompetent as a failure. You are at the very rock bottom of your future potential."
Levels of formality exist in most (if not all) natural languages, but the difference between what you've described above and a proper grammatical system is that the grammatical system is standardized, accurate and absolute. There are clear rules and clear formality levels involved.
Think about tense for instance. In English you have 3 basic grammatical tenses that can be combined with an aspect (perfect aspect, continuous aspect or both).
Mandarin Chinese has various aspect markers (like 了 le, 过 guo, 着 zhe or 在 zai), but does not have a grammatical marker for tense. That doesn't mean you cannot say that something will happen in the past or future: you just indicate the time with an adverb such as "tommorow", "yesterday" or "in the future".
The reason linguists say that Mandarin has no grammatical tense while English has grammatical tense is that the English tense is highly systematic. There are only 3 basic tenses (Past, Present and Future) and they are always marked the same way. On the other hand, Mandarin is flexible. You can mark the tense by using any temporal adverb you want, or even leave it out completely and let the speaker learn about it from the context. In English you don't get that level of flexibility: you HAVE to mark the tense, and you have only three ways of marking it (12 when you combine these ways with all the possible aspect combinations).
The same idea goes for thing like formality levels, honorifics or evidentiality.
English does have language registers, but there are many ways to express formality, and it's rarely clearly which of these ways is more formal. For instance, you can say:
"I would like to express my deepest gratitude for your invaluable assistance in this matter."
"I am sincerely grateful for the valuable time and effort you have so kindly dedicated to helping me."
"I am eternally in your debt for your gracious help in resolving the matter at hand."
Which one of them is more formal? I don't really know, and wouldn't want to spend a single moment debating about that.
However, in Korean it's pretty obvious that 합니다 (hamnida) is quite formal, but 하옵나이다 (haomnaida) is something so formal you'd usually only hear in historical dramas.
Japanese has less distinctions, but everybody can tell the difference between polite "desu", the polite formal "de gozaimasu", the formal (but not polite) "de aru", the informal and familiar "da" and then dated polite "de gozaru" (which you'd mostly hear in Samurai movies or other period dramas).
The situation in which you'd use each levels are also well-defined than in English. In particular, the familiar version is not neutral. You don't just use the Japanese "da" with people you don't know very well. It's not slang at all, but it's still quite rude to use it with strangers or your superiors.
And English has nothing quite like the distinction between "de aru", "de gozaimasu" and "desu". In most cases where you want to be polite (not formal) you would use "desu". "de gozaimasu" is used in certain settings that require extra formality (e.g. when talking to customers or in public announcements). "de aru" is something you would usually not use when addressing to people directly, since it is too plain (i.e. it would be quite rude). Instead, you find it in encyclopedias, reference books and documentaries.
> However, you never use honorific language when talking about yourself. Instead, you can use humble language to help you decrease your sense of ego importance.
Spanish culture encourages humility/modesty through idioms, like "tu humilde servidor" (your humble servant), "aquí, humildemente" (here, humbly), etc., but these are frequently used as humblebrags. I wonder if that happens in Tibetan culture too.
In the older Indo-European languages, like Ancient Greek or Latin, evidentiality was also important and it was expressed using different verbal moods, like the so-called indicative, subjunctive and optative.
Many modern European languages have been simplified from this point of view, but some still have remnants of the older uses of the verbal moods, like the use of some kind of subjunctive for anything that is not known with certainty, e.g. from direct experience.
Typical example in some slavic languages: singular/plural versions of "you". In official speech one almost never says singular "you" even to a single person -- instead using honorific plural "you".
I wonder if it was probably the same in English, just at some point people became all too polite and stopped using "thou".
Yes. And some Quakers were offended by all this unnecessary politeness and continued to use "thou" for a couple of centuries. So English and French used plural "you" for politeness, and so did German at one point, but modern German uses "they" as a polite "you", and so does Italian, I think. So there was an international trend to avoid singular "you" when being polite. But recently in Sweden (1960s/1970s) they've gone back to universal use of singular "you", which seems like a good thing to me, though it's presumably too late for English, despite the holdouts in Yorkshire.
In Norway the switch happened almost overnight, approximately 1980. Good riddance, the plural polite forms didn't exist in my dialect anyway and it always sounded extremely cringy when somebody tried to use those forms in dialects which didn't have them.
I always say that it's not the words you use which matters for politeness, it's how you say them.
> […] In official speech one almost never says singular "you" […]
With a notable exception being addressing the sovereign (king/queen/tsar/etc) where the singular «you», «thou» and similar were used, in all languages. The sovereign was seen as a direct peer, the ultimate protector of the people and the last instance of appeal, and the connection was also perceived as deeply intimate.
The practice fell out of favour in England (I'm not sure when exactly but probably with the transition to the constitutional monarchy), although it lived on elsewhere in mainland Europe until the demise of all major monarchies.
That probably stems from making people believe that sovereign is a semi-god, God's appointee. In religion, God was always addressed intimately, same when God addressed someone.
That would actually be 230V in most countries to be nitpicky. And the split-phase nature of 240V in the US (or 200V here in Japan) does make it somewhat more exotic. I guess building codes may be more expensive when you've got two hot wires?
They might think Shakespeare's story are silly even if they did read it. In fact, there is at least one widely publicized instance where exactly the same thing happened with a culture that wasn't exposed to Shakespeare before:
The same idea is probably true with programmers who have grown used to C-like syntax or even Python-like or Ruby-like syntax. Syntax is at least in great part a cultural thing and your "cultural background" can affect your judgement in many cases:
1. Are braces good? Some programmers find them noisy and distracting and prefer end keywords or significant whitespace, but other programmers like the regularity and simplicity of marking all code blocks with braces.
2. Should the syntax strive for terseness or verbosity? Or perhaps try to keep a middle ground? At one end of the spectrum, Java is extremely verbose, but a lot of Java engineers (who have generally been exposed to at least one less-verbose language) are perfectly OK with it. The trick is that the main way that code gets typed in Java used to be copy-paste or IDE code generation (and nowadays with LLMs typing verbose code is even easier) and reading and navigating the code is done with the help of an IDE, so a lot of the effects of having a verbose language are mitigated. Diffs are harder to review, but in the Enterprise app world, which is Java's bread and butter, code reviews are more of a rubber stamp (if they are done at all).
3. Lisp-like S-expression syntax is also highly controversial. Many people who are introduced with it hate it with passion, mostly because the most important syntax feature (the parentheses) is repeated so often that it can be hard to read, but advocates extol the amazing expressive power, where the same syntax can be use to express code and data and "a DSL" is basically just normal code.
There's "verbosity as descriptive clarity", and there's verbosity as in "I already said this, why do I have to repeat myself?" Ada unfortunately still has some of the latter, otherwise I would agree.
Java is really not that verbose if steer out of the 25+ years old conventions that were defined to justify expensive proprietary tooling. Leave all fields package scope or public final, so you don't need getters and setters. On JDK21+ use records and pattern matching. Go procedural + lambda, don't be afraid to use static methods. When OO is required, prefer composition over inheritance. Adopt a proper annotation processor library such as autovalue to eliminate remaining boilerplate.
Microsoft Access definitely took off. It was certainly more popular than the new crop of no-code/low-code platforms we have today. In the late-90s and early 2000s almost every large company seems to have had Access applications running in several different corners of the business.
The reason Access eventually died off is that it wasn't designed as a multi-user database. You could run Access on a network file share but performance would suffer (especially with concurrent access by multiple users), and you'll be running the risk of database file corruption. Microsoft Access did support a client-only mode, where Access is used for the forms, queries and application code, but the actual data is stored in Microsoft SQL Server — but setting up and maintaining a database server was probably too complicated for the type of contexts in which Access became popular.
The key point is that most of the usage of low-code products in the past was basically an instance of Shadow IT. In order for a Shadow IT product to be successful it generally needs to be easy to use, easy to distribute (or access) and have a capable free (or effectively free) version. Access and Excel had it all. They were easy to use for beginners (although complex applications required skill). Distribution was extremely simple in the corporate intranet age: you just had to place your Excel or Access file on a network share. They were part of Microsoft Office, so everybody had them on their computer "for free". If a product fulfills the conditions above, entrepreneurial employees will start using this product to address viable needs that your IT department lacks the resources to solve with a more robust solution.
Often these Access apps became popular enough that it had to be officially taken by the IT department, where IT programmers invariably cursed the buggy hack of an application they had to maintain. I don't know the statistics, but I assume a great number of these would just be rewritten as a traditional client/server or web application.
> it wasn't designed as a multi-user database. You could run Access on a network file share but performance would suffer [...] Access did support a client-only mode, where Access is used for the forms, queries and application code, but the actual data is stored in Microsoft SQL Server
Both your comment and a sibling's mention features that Access either didn't have or didn't do well. However, there were low-code/scripting workarounds for all of these, which were in fact used in many places. It was scalable if you were just knowledgeable and persistent enough to keep chasing your goals. In addition, the backend didn't have to be SQL Server, it could just be another Access database.
I myself created a 'sharded' Access-only implementation (admittedly a fairly simplistic one) that supported over 300 concurrent users. The trick was to keep record locking to a minimum by training users to click a 'save record' button when they were done filling out a form (which defaulted to an offline state)-- all the data was then uploaded to the central database in a few milliseconds, and the connection was immediately closed. Kind of mimicking old webforms. It worked.
> IT programmers invariably cursed the buggy hack of an application they had to maintain
This was really the biggest problem. Only apps designed by people who were pretty good at what they were doing avoided this.
How is that different from the thousands of different languages that did not have alphabet until recently but then got one created by linguists or missionaries (or often someone who is a little bit of both[1])?
Cyril and Methodius (who created the Glagolithic Alphabet, not the Cyrillic alphabet) weren't even the first Chritian missionaries who created a new alphabet for a language that didn't have on in order to spread Christianity. I believe the first one was Armenian (in the early 5th century).
I admit I didn't have time to read this blog post deeply, but it doesn't sound very convincing. It doesn't bring any EVIDENCE that this is an alphabet it just cites other cases of possible alphabets in Mesopotamia and the near East [1].
Besides that, this blog post mentions some morphological characteristics of the inscriptions that make the author believe the writing is alphabetic, but it fails to mention these characteristics. I don't doubt Rollston has good reasons for this statement, but the claims behind them need to be published and reviewed. I'm not sure if this is the case (and I do not have access to the 2021 article).
[1] This includes the Lachish Dagger I tried to look up, but its dating seems disputed, but even the earliest proposed date (the 17th century) is more recent than the Wadi el-Hol inscriptions, so I'm not entirely sure what it is supposed to prove, except perhaps an earlier spread of the Alphabet from Egypt and the Sinai peninsula to Canaan proper?
That's because it's not a strong conclusion. It's a "better than the alternatives" hypothesis. Repeating my tldr above "they don't know it's alphabetic".
> doesn't bring any EVIDENCE .. some morphological characteristics of the inscriptions
I'd say the "morphological characteristics of the inscriptions" count as evidence and I'll just recap everything linked that I think counts as evidence: the graphemes include several repetitions even with only 12 signs in total; they don't resemble cuneiform at all; they have a weak resemblances to some Egyptian glyphs but weak and Egypt didn't have these clay cigars; they have a weak resemblance to some Indus glyphs and (later) Byblos glyphs but again weak; they don't appear to be numbers, potmarks, etc.; but what they do strikingly resemble is later alphabetic signs, to the point where the author, one of the foremost experts on Semitic epigraphy, really wanted the dating to be wrong.
Now the blog post doesn't go into much detail on these items but Schwartz's 20+ page 2021 paper (I had no trouble getting a free, legal copy) does (not always a lot more detail but also covers more possible alternatives). But, like the blog post says, the case Schwartz 2021 makes is still extremely cautious and he basically concludes that we just have to hope we can find more examples to confirm what kind of system they are from, and to increase the chance of deciphering them.
How is it better than the alternative "we have a set of symbol and we don't know what it means"? I really think there is a merit in saying "with this sample size, every theory we put out has low confidence level".
With 12 signals in total, it's very hard to show patterns that are in line with an alphabet. I don't think that with this sample size you can make a very strong claim that the chance that this is an alphabet is higher than the chance is that these symbol serve any other kind of purpose (including being a non-language). The main claim seems to be that repetition (what kind? I'm a quite disappointed the blog post has no transcritions, considering it's just 12 symbols we're talking about!) makes the chance that this is an alphabet higher. The rest of the claims (it doesn't resemble cuneiform, doesn't seem to be derived from hieroglyphs and doesn't seem related to any other script) are meaningless. The resemblence for later Canaanite alphabetic signs is interesting, and could probably be more convincing if we had a larger sample size.
So in the end, if we are convinced by these claims, we're basically saying something like "We have at most 1% confidence for every other theory, but we've got 2% confidence that this is an independent development of the alphabet that may have inspired the Canaanite alphabet we've seen 500 later". Higher confidence that is still far below the threshold doesn't cut it.
Now, I'm pretty sure the original article did not put the theory in these terms, but the headline is somewhat sensationalist, and the way it was picked up in newspapers is even worse, for instance:
Scientific American: World's Oldest Alphabet Found on an Ancient Clay Gift Tag
Stopping the press from misreporting science is a bit like trying to stop space rockets in midair with your bare hands, but even "Evidence of oldest known alphabetic writing unearthed in ancient Syrian city". The popular understanding of the word evidence is assumed to be "hard" evidence by default, not a weak evidence that bumps up the probability of a certain theory a little bit more.
I'll actually be quite excited if this turns out to be truly an alphabet encoding a Semitic language (it opens a lot of interesting questions and possibilities), but I'm not holding my breath for it.
This does not make GP incorrect though. It just means we really cannot know for sure how the writing system works until we have enough information to decipher the inscriptions.
I don't take beef with the possibility of an earlier alphabet that predates the Proto-Canaanite alphabet — that is entirely plausible. But I think the article is overselling the story. The evidence is not very strong at this point, and I although I can be wrong, I suspect it can never be with if we remain with just four very short inscriptions without external context.
It is important to clarify the vast difference between this and the decipherment of Egyptian Hieroglyphs. I think the myth and magic of the Rosetta stone is overemphasized in popular culture, so just a few points of difference between the Egyptian Hieroglyphs and scripts like the Indus Valley Script or Linear A.
- Of course, to start with we did have the Rosetta Stone, and we have no equivalent for these scripts. But the Rosetta Stone was rediscovered in 1799, while Champollion provided the first phonetic interpretation of Egyptian hieroglyphs only two and half decades later, in 1822. But even after Champollion's famous achievement, we weren't able to read most hieroglyphic texts yet! Champollion didn't realize that many phonetic hieroglyphs represent not just a single consonant, but often two or three different consonants! It took a couple of more decades until we Egyptian was fully deciphered.
- We knew exactly which culture and language the Egyptian Hieroglyphs belonged to. More importantly, we had a vast wealth of external historical sources about this culture that we could read: mostly in Greek, Hebrew, Roman and Aramaic. From these sources we knew the names of Egyptian kings that we could expect to find in Egyptian hieroglyphs, and we knew enough about Egyptian culture, religion and history to often guess what the texts would be talking about. This is not anywhere nearly as true for the Indus Valley Script! Since we don't know who their kings were, we cannot use the names of kings as a highly verifiable way to test the phonetic writing hypothesis.
- We had a vast quantity of Hieroglyphs inscriptions. There are fewer attested Indus Valley Script inscriptions, but the number should be enough if we just had other external clues.
- Egyptian still had a (barely-)living descendant (Coptic) at the time Champollion and other scholars were working on its decipherment. Coptic priests and AFAIK even native speakers have provided a lot of help them in understanding how the Egyptian language they were trying to decipher might sound and work.
1. The default value for SameSite attribute is now "Lax" in most browsers. This means that unless you explicitly set your authentication cookies to SameSite=None (and why would you?), you are generally not vulnerable to cookie-based CSRF (other forms of CSRF are still possible, but not relevant to the issue of storing tokens in local storage or cookies).
2. Most modern SSR and hybrid frameworks have built-in CSRF protection for forms and you have to explicitly disable that protection in order to be vulnerable to CSRF.
3. APIs which support cookie authentication for SPAs can be deployed on another domain and use CORS headers to prevent CSRF, even with SameSite=None cookies.
On the other hand, there are no mechanisms which offer comprehensive protection from XSS. It's enough for a single JavaScript dependency that you use to have a bug and it's game over.
For this reason, OAuth 2.0 for Browser-Based Applications (draft)[1] strongly recommends using a HttpOnly cookie to store the access token:
"This architecture (using a BFF with HttpOnly cookies) is strongly recommended for business applications, sensitive applications, and applications that handle personal data."
With regards to storing access tokens and refresh tokens on local storage without any protection it says:
"To summarize, the architecture of a browser-based OAuth client application is straightforward, but results in a significant increase in the attack surface of the application. The attacker is not only able to hijack the client, but also to extract a full-featured set of tokens from the browser-based application.This architecture is not recommended for business applications, sensitive applications, and applications that handle personal data."
And this is what it has to say about storing the refresh token in a cookie, while keeping the access token accessible to JavaScript:
"When considering a token-mediating backend architecture (= storing only access token in local storage), it is strongly recommended to evaluate if adopting a full BFF (storing all tokens in a cookie) as discussed in Section 6.1 is a viable alternative. Only when the use cases or system requirements would prevent the use of a proxying BFF should the token-mediating backend be considered over a full BFF."
In short, the official OAuth WG stance is very clear:
1. HttpOnly cookies ARE better in terms of security. 2. Storing Refresh Tokens in local storage is only recommended for low-security use cases (no personal data, no enterprise compliance requirements). 3. Storing short-lived Access Tokens in local storage should only be considered if there are technical complexities that prevent you from using only cookies.
[1] https://datatracker.ietf.org/doc/html/draft-ietf-oauth-brows...
reply