disruptiveink

This is stupid/dangerous advice and I will die on this hill.

The JWT specification is specifically designed only for very short-live tokens (~5 minute or less). Sessions need to have longer lifespans than that.

Your auth token should be 5 or 10 minutes long, yes. Your session should be encoded in a refresh token, which can be another JWT or completely opaque, whichever you prefer.

"stateless" authentication simply is not feasible in a secure way. You must have some state to handle tokens securely, and if you must have a data store, it's better to just store all the data. Most of this article and the followup it links to describes the specific issues:

No. Stateless auth is completely feasible in a secure fashion. You need short lived tokens as stated above, and to perform instant logout you need to be able to identify JWTs that were invalidated at the level of your API gateway. You don't need to store every JWT that is valid, only a way to identify the ones you want to invalidate early. If you make bulk invalidations not go onto this store (and just accept that with bulk logout, users will remain logged in for up to 5 minutes, which if you're doing logouts in bulk, this does not matter to begin with), then this typically fits in memory. "if you must have a data store, it's better to just store all the data" is just wrong.

And of course for refreshing the token, you go to your data store and recompute things. But the point is to do this every 5-10 minutes like the author (correctly) identified, not on every API request.

JWTs which just store a simple session token are inefficient and less flexible than a regular session cookie, and don't gain you any advantage.

But no one does this. People use JWTs as auth tokens which are short lived but contain a bunch of information about the users that you'd get in huge trouble if it could be forged (user ids, resolved geolocation, entitlements, cohorts, etc etc), but that you also don't want to make every service of yours look up against a data store or compute for every single API request. It should be data that normally doesn't change during the duration of the auth token. When it does change, you should have a mechanism to immediately invalidate the previous one (see above) and issue a new one on the API call that made the change. Simple.

The JWT specification itself is not trusted by security experts. This should preclude all usage of them for anything related to security and authentication. The original spec specifically made it possible to create fake tokens, and is likely to contain other mistakes. This article delves deeper into the problems with the JWT (family) specification.

Yes, all standards are horrible if you look at them long enough. XML is terrible, YAML is terrible, ASN.1 is horrific. I'll take a flawed standard that has been studied and criticized publicly so I have libraries and know where the footguns are vs rolling everything myself and having to find out the footguns on my own.

Killed for Skype, which was already declining by that time. Microsoft was keen on unifying their IM platforms, but failed to realise that unless the migration path is incredibly smooth, people just won't do it. And the value of any chat service is that the people you want to talk to are on there. Many people didn't bother migrating from MSN to Skype and that was the end of it.

The Skype team at the time was also run with the mindset of "developer happiness comes first, users come second", a relatively popular mindset in the 2010s, and shipped large app rewrites with missing features and usability regressions.

Of course, they eventually killed Skype too. The MSN users never went to Skype and the Skype users just progressively jumped ship to FaceTime/WhatsApp video/Google Voice to replace video calling and VoIP, respectively. By then you had a former shell of what Skype was and Microsoft figured they should just shove the remainder of their users into Teams.

Similar to the Google Talk > Hangouts > Google Chat tragedy.

Can't we just normalise publishing whatever you put into the LLM instead? I'm sure the author typed things into their favourite AI assistant that regurgitated that long form, LLM-speak style version. I'm sure the original prompt has all the relevant content and was a lot more pleasant to read.

Can't wait for this style of prose to become an incredibly embarrassing faux-pas.

You're thinking of this like a game where the only point is to "win". That's not how this would actually work in practice.

Blue is the only moral and logical choice. If red gets over 50% and you picked it, therefore contributing to the "red" outcome, you are now effectively a murderer. Plus you now get to live in a world where everyone else alive are sociopaths that picked red, where everyone with a conscience is now dead.

You also can't count on everyone picking red, or "if you picked blue, then you voted for suicide".

It's reasonable to assume that, leading to the button press event, the usual low-trust, "every man by himself" types will rally for red, with the usual excuses, where high-trust societies will make it clear that it's your moral duty to pick blue, to get the votes to the 50% threshold and ensure no one dies. Around the world there would be debates nonstop that would permeate every social circle and families. You'd have huge arguments where the typical selfish types would scream at their family members "how dare you say you're going to press blue, do you want to leave your poor mother alone without their only child?", only pushing red-leaning voters more into red and blue-leaning voters more into blue.

Plus, if you look at the possible outcomes:

- Red wins, you picked red: Depending on where you live, a reasonable portion to the large majority of the population is now dead. The ones alive have, by definition, a strong bias towards individualism and noncooperation. It's extremely likely civilisation will collapse. Pick your favourite fictional dystopia and you might have a reasonable chance of it actually coming somewhat real.

- Red wins, you picked blue: You are now dead, but at least you don't have to live in the world above.

- Blue wins, you picked blue: Things carry on as normal and your conscience is safe in knowing that you didn't vote to kill and that over 50% of your fellow humans also didn't vote to kill.

- Blue wins, you picked red: Things carry on as normal, but you now have a guilty conscience, or, if your vote was made public, people around you know you would have killed them to save your skin.

Correct. If you can always either fix it forwards or roll back, which you should be able to unless you're building software that needs to go out in releases with versions tracked separately that need to keep getting fixes, trunk-based development simplifies everyone's lives greatly.

I've never seen an organisation that insists on release branches and complicated git merge flows to release their web-based software gain any actual benefit from it that isn't dwarfed by the amount of tooling you need to put around it to make it workable to the dev team, and even then, people will routinely screw it up and need to reach out to the 5% of the team that actually understands the system so they can go back to doing work.

Baseline requirements are not an imaginary problem. All of them have a legitimate reason for existing. You could argue that some "are not that big of a deal", but that's exactly the point, the overbearing and overly specific requirements serve both their own purpose and double as Van Halen's "no brown M&Ms" clause: if the CA screws them up, either by malice or incompetence and doesn't immediately catch them and self-report, then you know they have no way of telling what other things they are screwing up. And if you're in the business of selling trust, that instantly makes you untrustworthy.

There are countless Bugzilla reports of clearly unprofessional CAs trying to get away with doing whatever they want, get caught, say "it's no big deal", fail to learn the lesson and eventually get kicked out, much to the chagrin and bewilderment of their management, irate that some nerds on the Internet could ruin their business, failing to understand that following the scripture of the Internet nerds is the #1 requirement of the business they chose to run.

If you purposely go into your phone settings and turn off auto-capitalization (which is what the kids do, since they're all typing on their phones), isn't it the very definition of pretentiousness? You're going into extra trouble to signify you're part of a clique, while feigning "laid-backness" and "i dont even care bro".

But you do care. You care so much to project your appearance of being cool and that you don't even care that you go through extra trouble to keep it up, even though paradoxically it would be LESS effort to not do it.

Cat's out of the bag there already. We all have general purpose computing devices in our pockets, locked down on purpose. Android used to allow you to gain admin rights but it's been getting more and more impossible to do so while still keeping most of your programs working. It's not only a cat-and-mouse game against "rooting detection" SDKs companies licence and plug into their apps out of a misguided duty of care, but it's especially bad with anything that uses Google's remote attestation lately.

Android is also about to lock down "sideloading", another "great" dysphemism for "installing software".

Moving the Overton window on this has been so successful, that even people in our industry happily accepted the much maligned dysphemisms of "jailbreaking" and "rooting" for what used to be called "local admin rights" and look upon such access as if it's only something pirates, criminals or malware spreaders would want to do.

I say this as someone who is running an Android phone with a kernel with some backported patches applied and compiled by myself. The fact that I can do it is great. The fact that the entire industry is trying to make it as frustrating as possible for me to do this under the guise of false premises such as "security" is disheartening.

Correct. Age verification and privacy consents belong on the browser. The issue is that on the browser, things work a bit too well (remember https://en.wikipedia.org/wiki/P3P ?), so the big players are incentivized to ignore completely the browser-based mechanisms and say/do nothing whenever they see lawmakers going on a dumb direction (risking fines is a reasonable price to pay in order to kill adoption of an actual browser/OS based control that would cause a dent to their tracking operations) that puts the onus on individual website operators.

The insane question here is, why would the EU mandate hardware attestation controlled by two private American companies in order to access services?

That seems completely contrary to the spirit of EU laws and regulations, which tend to be about protecting the consumer, preventing monopolies, ensuring people can generally live their lives where all things that are mandatory are owned and ran by the state and foster a certain degree of EU independence, with a recent focus on "digital sovereignty".

This one is a five for one against all of those goals? Harms the customer (you could see this as the polar opposite of GDPR), strengthens entrenched monopolies, force citizens to be serfs of one of two private corporations in order to access information, and on top of that, like it wasn't enough, willingly capitulates to the US as the arbitrates of who is a valid person or not.

This is so against the spirit of the EU itself that it would almost be funny if people weren't serious.

Agreed. I refuse to use the terms "rooting" and "jailbreaking" in professional environments, I always use terms like "admin access to the mobile device".

Because that's what it is, despite the extremely successful campaign to paint people who want admin access on their mobile computers to be painted in the same light as pirates.

Starmer is as authoritarian as the Tories at this point. There is no difference here.

We have a near perfect system for finding the location of phone thieves, yet the police will not go and knock on the doors of criminals even when explicitly shown proof of "this is where the thief is currently".

I'm not victim blaming here, but does anyone have this nagging feeling that in this case, we, the "techies" caused this by refusing to engage with lawmakers?

In the case of E2E encryption, it's definitely a hill to die on, there is no way to make a backdoor "only the good guys" can access. But in this case, the long standing refusal for the tech industry to engage in even the lightest of lobbying towards having legal regulation for standards seems to bite us in the ass every now and then. We've seen it time and time even for things that are non controversial and would clearly benefit everyone: why is BCP 38 not mandated by law in any country? Why is IPv6 at the ISP consumer edge not mandated by law?

All of this could have had the same effect if instead of putting the onus of age verification on millions of websites, you instead put it onto the "customer end device", with some definition as to have it only apply to anyone who sells devices used to access online content with more than X% market share (meaning effectively Microsoft, Google on behalf of all Android OEMs and Apple, plus TVs and console makers).

You'd also put into law what content providers need to do to become compliant. It drops from "having a robust system of age verification" into "if you're serving content over HTTP and your content is for over 18, you need to send a specific over 18 header". If you're publishing an app on a walled garden app store, you need to specify the age rating (as one does already). If you state your page is good for under 18s when it's actually over 18, you then incur a fine.

Then it's really just up to OS makers to build support for the above into the parental controls functions that mostly already exist. Implement the header checking on the browser. Then restrict over 18 apps and outside app store that aren't explicitly authorised: this ensures no alternate browsers could be installed or ran by a child, while leaving them freedom to roam the web and install under 18 apps. The issue with existing parental controls is twofold: the web is a wild place and manually vetting every single app your kid wants to install is overbearing so everyone gives up on parental controls.

Then it's a matter of, when you buy a phone for your kid, you click a button "the user is a child, enable parental controls, set the grown up password". If parents fail to even do this, then clearly it's their own fault?

You'd specifically leave out non-HTTP protocols and leave a bunch of technical loopholes that could be exploited by technically minded people. It would both limit the amount of wreckage to things the common people doesn't even know it exists and make sure this wouldn't creep into places it doesn't belong. Sure, teenager who downloads Arch into a USB pen drive and boots off it can then access whatever they want, or someone who finds they can get into IRC and XDCC a bot for hot JPEGs, but at that point they clearly earned it.

I get the feeling that we've fucked it, left very important regulations up to people who have no clue and now we get the most onerous and worst implementation possible of things every single time put into law. We could have done the same with cookies, there's like, three browsers. Remember P3P? https://en.wikipedia.org/wiki/P3P

Usually I would agree with you, but this is an incredibly common initialism, used by not just people in the industry, but also by consumers. Sure, it may not be as widespread as VHS (global) or API (tech-adjacent), but anyone who is in the market for this software already knows what NVR means.

Most people would know the term from either being quoted or looking up CCTV solutions, all of which, unless they're fully "cloud-based", come with a component that is called the NVR. You wouldn't even consider this if you weren't aware of the concept. If NVR means nothing to you, Network Video Recorder doesn't mean anything to you either. This is meant to be a replacement for closed and inflexible hardware boxes that are sold together with security cameras, and the name of those boxes are "NVRs".

I really don't, what is the answer? I assume higher ups at law enforcement, who are detached from the day-to-day operations, make up excuses about "end to end encryption being a challenge" because it's a meme, much like execs in our fields parrot "challenges" to boards and VC investors that are often fully removed from actual execution issues.

And then because it comes up in slides so much at that higher level, politicians actually start thinking that's why we haven't solved all crime, our guys are competent and clearly they're not understaffed, it's that pesky "not being able to break end to end encryption" that is preventing law enforcement from doing their work!

I don't understand why they keep trying this over and over. It can't possibly be a moral crusade as it keeps happening with different players, but I don't understand the purpose.

We now live in a world where the opposite routinely happens: a crime happens, you give the police access to Apple or Google's Find Device / Find My data, they throw it in the trash. Law enforcement has more data to find and procecute criminals than they have time. People get scammed out of money by the thousands every day, over the phone, an insanely easy system to tap and trace. No one gets arrested.

Who is actually repeatedly pushing for things like these within the EU? For what purpose? What crimes went unprocecuted because of the unability to perform mass surveillance like this? It seems that all the time, when law enforcement actually cares about, it's trivial for them to get evidence? So why does this keep popping up every year?

It was Bill fucking Atkinson. Not a disposable random contractor you hire by the dozen when you need to build more CRUD APIs.

At that time at Apple, even as an IC, Bill had lines of communication to Steve and was extremely valued. There's absolutely no doubt he could get "middle manager shenanigans" gone simply by not complying or "maliciously complying". Hell, I've seen ICs far less valuable, or even close to negative value get away with stunts far worse than these, succeed and keep their jobs. Out of all the stories in Folklore.org, this is the one you have an issue with?!

Wait, but didn't TLS 1.0 have significant improvements over SSL 3.0? The article makes it seems that just a couple of things were tweaked just to make it different for the sake of being different.

Ah, yes, The color of infinity, inside an empty glass.

Google ultimately did that for China. The outcome in that case is that the domestic market filled in the gaps, while complying to all relevant authoritarian legislation. I do not believe that the same would happen for every market where these stunts are being pulled off, at least not to the same level of quality.

Why are European countries trying to pull one off from the China playbook, while simultaneously being shocked that companies react to authoritarian moves in the exact same way as they have done in the past, is beyond me. Is the hubris so large that they honestly can't conceive their "requirements" as being "literally the same as China?"

Amusing nomenclature, but it's a legitimate concern. If your SREs use application credentials to connect to the database, your ability to have effective access controls and have accurate access audit trails are severely hampered.

The value proposition of Crowdstrike is exactly that: something that you can deploy to tick the regulatory checkbox of "we have endpoint protection from a reputable company everywhere" without consuming outrageous system resources.

That's why they have so many enterprise customers. They're the only game in town that won't slow down your servers arbitrarily while still convincing an auditor that you do have an antivirus.

Too bad they also crash your whole system every now and then.

What do you mean? They wrote the kernel driver. With great power comes great responsability.

If you're writing a kernel driver that is deployed throughout a great portion of Fortune 500, with the money that that entails, then you should definitely be able to afford to pay people to write defensive code and have proper pipelines in place.

You are correct. Steve definitely believed in doing things properly because you know they're there, regardless of who can see it: https://folklore.org/Signing_Party.html

Steve came up with the awesome idea of having each team member's signature engraved on the hard tool that molded the plastic case, so our signatures would appear inside the case of every Mac that rolled off the production line. Most customers would never see them, since you needed a special tool to look inside, but we would take pride in knowing that our names were in there, even if no one else knew.

Struggled with the context as well: https://sunrise-ev.com/projects.htm

I use a XP VM on a ARM Mac as it's a handy way to run most Win16/32 exes that won't run properly in Wine. Old random utilities, random OEM software required to upgrade old devices' firmware, silly Win16 apps, the works. Anything more recent than XPis too heavy for x86 VM emulation on ARM and Win 10/11 ARM come with their own quirks that are not worth dealing with for my purposes.

It's handy to have a modern browser at hand to not have to shuffle files around between the host and the VM, so you can do Google -> website of the tool in question (plus uBlock, so the main source of infection, ad networks, is taken care of). The likelihood of either Google or whatever very focused and targeted website I happen to visit to be serving XP malware is negligible.

And if it does get infected, congrats, you infected a VM with no connection to the host or shared folders that has no personal files and is powered up maybe 30 minutes per year.

It's not zero, no, but to say there's no use case and it's the same as running around in scissors blindfolded is a huge simplification.

That's an unfortunately common misconception. Your example is not security though obscurity any more than password authentication is, though.

Security through obscurity means substituting security for a flawed algorithm that is usually trivial to exploit if the attacker is made aware of the algorithm. Think things like no authentication and ROT13ing and Base64ing clientside. If the method leaks or is discovered, the whole system is broken.

You just told me your algorithm and I cannot get to your banana because the UUID key space is insanely large. So that's not security to obscurity.

I've never worked with someone who ever stated "How long is a piece of string?" and wasn't a total pain to work with. Doesn't even matter which side I was on, it's painful to hear it even if you're part of the team that made that statement.

It's always a bad faith response. If the requirements are hazy, state that. If the task requires investigation and there's a high degree of exploratory work, state that (and state how long you'd be willing to explore before pivoting). If there's multiple outcomes or options that can lead to wildly different time estimates, disclose that.

Every time I've seen it uttered it meant "you're too dumb to understand what I'm doing and you should just shut up, give me money/time and leave me alone". And it's usually also people who overvalue their own abilities that say it too.

They are reminding you that the reality you are experiencing is not normal and should not be normalised. They are stating that it is not only possible to not be like this, but it's actually a baseline expectation in most of the rest of the developed world.

You can keep burying your head in the sand, make excuses for unacceptable behaviour such as swatting with "but it's extraordinary circumstances with very specific context" and bemoan the "provincials" for expecting the US behaves, or at least trends towards, a society that resembles the rest of the democratic, civilized world.

Or you can say enough, and demand action. One is a lot easier than the other.