tankenmate

Again looking back at the history of Unix, it used a 56 bit variant of DES encryption that used the user's password as the key. So only the first 8 characters of the password were used and the rest was silently unused, for example "password" and "password123" would have been the same password on early Unix. And although most BSDs and Linuxes moved in the mid 90s to PAM (and hence md5, etc) most SVR4s didn't move until late in the 90s. And at the other end, DES crypt() made its way into Unix in some v6s (~1977) and became widely available in the release of v7 Unix. So 8 character passwords were a thing for about 20 years.

This decision long predates Linux. It's been a staple back to the earliest days of Unix; and it isn't a weird decision if you take into consideration of multi user systems in office environments that have non trivial security considerations (for example telecoms companies), which is exactly where Unix came from.

Indeed a whole class of issues become moot if you just don't use javascript anywhere. In the browser world this is obviously difficult/impossible; I look forward to the day when WASM can run natively in a browser and doesn't need javascript at all, DOM, network, etc, etc. On the server side? Just steer clear of the javascript ecosystem altogether.

And not just token usage, expensive token usage; when it comes to tokens/joule not all tokens are equal. Efficient use of MoE architectures does have an impact on tokens/joule and tokens/sec.

Isn't it just so much easier to make sure that wealth isn't concentrated in so few hands? Tax wealth, not work.

And before everyone gets upset, tax serves two purposes; 1) control inflation (it in effect burns money that was issued when the govt previously paid for things), 2) disincentivises selected behaviours. and one side effect, when the govt runs a tax deficit it increases inflation, and of course the contrapositive is also true.

There's a litany of such characters over the years; Al Dunlap comes to mind and his tenure at Consolidated Press Holdings.

Unless of course your job is writing an agent that uses an Anthropic model.

i just checked; no version 5 models listed in claude code yet

Some of the conclusions remind of the "ha ha only serious" joke that most people (obviously not the Monks themselves) had about Perl; "write only code". Maybe some of the lessons learnt about how to maintain Perl code might be applicable in this space?

"The EU is more of a threat to itself than Russia is"; it can be easily argued that this is only the case if democracy has little value because in Russia democracy does indeed have little value (let alone life, etc).

"Democracy is the worst form of Government except for all those other forms that have been tried from time to time"

So the EU and the EC are big lumbering organisation that make poor decisions; but then people make poor decisions day in day out. But just because you *feel* disaffected doesn't mean the system is inherently wrong (unless of course you believe that politics' primary, if not only, purpose is to make you "feel good(tm)").

It's probably far more accurate to say that wealth inequality is the EU's biggest threat and that "the elites" (which is more than just senior politicians and bureaucrats) don't feel the pain of inequality and so aren't internally motivated to do much about it (culture eats strategy for breakfast, etc etc).

"But you're basically arguing for not criticizing the status quo.", but that wasn't what was argued ("You should be able to insult and criticise the Prime Minister."), but more your interpretation of what was said. You're making a strawman argument.

Hmm I use Firefox and the rendering I see in Firefox looks nothing like the render the author gets in Firefox; in fact the text rendering I get looks very similar to the "Chrome" rendering. Obviously this must depend on the libraries linked during the build process.

`Not a forcing function unless you’re levered`; but every one is levered, you aren't born with all the housing, food, and water you'll need for the rest of your life. Everyone is born with a net negative of the necessities of life, the difference though is that a very small minority are bequeathed this by well heeled ancestors. But for the overwhelming majority there is a life long struggle to afford to live a suitable life.

"Lai is a victim of this miscalculation."; I don't think Lai miscalculated, he knew what was coming and fought it anyway.

"Authority comes from submission"; sure someone can threaten you with physical coercion, but they can't make you want to submit. I would strongly suspect that Jimmy knew what was coming, but the point isn't "winning" in the "hollywood" sense, but rather that he did the right thing even. I would suspect not even in spite of the cost, but because of the cost.

Are principles that don't cost you anything even principles?

So much of this article has two implicit tenets; 1) information can be "owned", and 2) copying information reduces its inherent value (which as I'll explain follows from the first).

So as a preface, I would argue than in the marketplace for information (ideas, content, works, etc if you will) that value has two components, 1) utility value, and 2) scarcity value (which I would argue has two components, availability value (information horizon[0]) and saliency value (preference as a result of the information horizon[1]). Obviously the rise of copyright over the last few centuries attempts to limit commerce of ideas based somewhat loosely on the concept of (real, physical) property law (itself a glorified codified extension of the animal behaviour of territoriality, aka survival by means of securing resources); ownership is a moral value autogenous to an idea's sui generis expression on, by, or through a recorded medium. In other words the mere act of recording an idea in a "creative" fashion brings with it a "moral" ownership of that idea. Of course the "creative" and "moral" parts from which the law prescribes and proscribes these limits is debatable. The legally mandated "monopoly" of an idea (even though the marginal cost of replication approaches zero) provides this scarcity. So in the end because of this the scarcity, and the resulting "rent seeking" (corporations seeking to charging (typically over time) more than the cost to create and distribute information), are in effect value (read wealth) redistribution.

So, what is more "moral"? Using a constructivist approach, which is more socially acceptable (and hence far more likely to be codified into law)? broad access to information distilled to the point that sui generis is "removed" so that concepts (which in general can't be copyrighted) are freely available for transformative use, or extending the "moral right" of copyright, now that information distillation is so cheap, to include the ability to "copyright" an idea rather than the expression of it. Or are we seeing a "breakdown" of the codification of the law where the granularity of the spectrum is so fine it becomes so costly to enforce such the "value" of the law in reducing the transaction costs of daily social interaction in the information sphere that we revert to pre-copyright behaviours, i.e. information hoarding.

[0] https://www.researchgate.net/publication/261773523_Informati... The concept is quite simple there is a limit to the amount and quality of information that a) a human can get access to (and following what they prefer / value), and b) relatedly the amount that can be synthesised for actual use. [1] https://www.sciencedirect.com/science/article/abs/pii/S07408...

In a lot of ways this seems, from the outside, to be similar to "Planck's principle"; e.g. physics advances one funeral at a time.

For the most part LLMs choose "the most common" tokens; so regardless of whether the content was "AI content" or not, maybe you are getting tired of mediocrity.

And of course also that mediocrity has now become so cheap that it is now the overwhelming majority.

Apologies; if I could edit it I would.

One of my favourite books, I even read it a couple of times, even hacked around with xv6 (the x86 port of the edition 6 kernel[0][1], if you do hack around with it in a VM make sure to add HLT to the idle() function, if nothing else it will save your fans).

One of a small number of books (such as TCP/IP Illustrated[2]) that progressed me from the larval hacker stage.

I also met Lions when I was a kid, but didn't put 2 + 2 together until 20 years later!

[0] https://github.com/bringhurst/xv6 [1] https://pdos.csail.mit.edu/6.828/2011/xv6.html [2] https://www.r-5.org/files/books/computers/internals/net/Rich...

It's a pity that the section on exceptions didn't do a more detailed analysis on the criticism of exceptions; in my personal view I haven't liked exceptions, in a similar vein to how I'm not a huge fan of the implementation of POSIX signals or setjmp / longjmp.

Although I very much see the reason why it was developed, in effect it comes closer to a glorified form of "come from" (and people thought that goto was considered harmful).

Not true, IP addresses are sold on, or even from time to time IP addresses are even leased (they can be transferred from RIRs, temporarily or permanently). Some times IP address ranges are registered with RIR but used in a different geography / region.

Geo-IP databases are mostly accurate, emphasis on mostly.

"but if there's a cost to providing free support to the community like official container images, then it will get cut.", but here's the kicker, supporting creating docker images when you're on github is close to negligible as to be paper thin.

You're misunderstanding my point, the Sec-Fetch-Site is not a replacement for CSRF tokens (be they cookies (classic CSRF tokens, auth tokens, JWTs; all of these can be made to work for the client to prove to the server that they are allow to submit a form (and came from the "right" form), some obviously easier than others), a header (such as X-CSRF-Token - Ruby on Rails, Laravel, Django; X-XSRF-Token - AngularJS; CSRF-Token - Express.js (csurf middleware); X-CSRFToken - Django), a TOTP code, etc), but the Sec-Fetch-Site header is a defence in depth mechanism, not a replacement for CSRF (however that is achieved, classic cookie mechanism or other).

Of course CSRF is a form of authorisation; "should I trust this request? is the client authorised to make this request? i.e. can the client prove that it should be trusted for this request?", it may not be "logging in" in the classic sense of "this user needs to be logged into our user system before i'll accept a form submit request", but it is still a "can i trust this request in order to process it?" model. You can wrap it up in whatever names and/or mechanism you want, it's still a trust issue (web or not, form or not, cookie or not, hidden field or not, header or not).

Servers should not blindly trust clients (and that includes headers passed by a browser claiming they came from such and such a server / page / etc); clients must prove they are trustworthy. And if you're smart your system should be set up such that the costs to attack the system are more expensive than compliance.

And yes, I have worked both red team and blue team.

You might want to read https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...

"Nothing you're saying has any relevance to the topic at hand. And, in fact, is largely wrong."; your confidence in your opinion doesn't make you right.

Prove it.

"MOREOVER, Sec-Fetch-Site obviates the need for csrf tokens.", you're just posting misinformation, you are flat out wrong.

"It is important to note that Fetch Metadata headers should be implemented as an additional layer defense in depth concept. This attribute should not replace a [sic] CSRF tokens (or equivalent framework protections)." -- OWASP; https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...

The Sec-Fetch-Site header can't be read / written by Javascipt (or WASM, etc), cookies (or some other tokens) on the other hand can be. In most circumstances allowing Javascript to access these tokens allows for "user friendly" interfaces where a user can log in using XMLHttpRequest / API rather than using a form on a page. OOB tokens one a one off auth basis or continuous (i.e. OAuth, TOTP with every request) are more secure, but obviously requires more engineering (and comes with its own "usability" / "failure mode" trade offs).

There's server security and there's client security. From what I've seen in these comments people are focused on the client security and are either a) ignoring server security, or b) don't understand server security.

But the server security is the primary security, because it's the one with the resources (in the money analogy it's the bank).

So yes, we do want to secure the client, but if the attacker has enough control of your computer to get your cookies then it's already game over. Like I said you can have time bounded CSRF tokens (be they cookies or whatever else, URL encoded, etc who cares) to prevent replay attacks. But at the end of the day if an attacker can get your cookies in real time you're done for, it's game over already. If they want to do a man in the middle attack (i.e. click on a fake "proxy" URL) then having the "secure" flag should be enough. If the server checks the cookie against the client's IP address, time, HMAC, other auth attributes, will then prevent the attack. If they attacker takes control of your end device, you've already lost.