I have been very pleased with the results so far. I was able to tune the tutorial to exactly what I want to learn, and it did a very good job (at least that i have seen so far). It has made learning fun, since I get to learn exactly what I want, and I can ask the AI questions and have it make changes to the tutorial in real time as i am working through it.
Now, will I keep using this at a rate to fully offset all of the thinking i have stopped doing since i started using AI? I am not sure, I guess time will tell.
i could not get through the hurdles of installing an IDE and js/python modules before.
now i am learning basic scripting and data modeling etc.
it is phenomenal for learning languages.
i built a chicken coop and some furniture. the skills and confidence i gained are real. am i failing to learn certain skills in the process? of course. but I'm getting further then i would on my own, and that is truly meaningful.
you can keep dismissing it; but I'm genuinely using it to break down barriers, give me confidence, and highlight my ignorance in very productive ways.
i find it bizarre how unwilling some people are to recognize that.
You want us to believe you couldn't overcome the puddle-deep challenge of installing an IDE and using Pip or Node in the past, but now you're actually learning how to write functions?
Cool for you if true I guess but I'm pretty seriously skeptical
A lot of the most miserable parts of getting started coding have nothing to do with programming and everything to do with like, trying to apt-install the right compiler version or figure out which build headers you need or some other equally trivial bullshit that gets in the way of writing code.
I started learning Monogame with C# literally yesterday after being a chiefly JavaScript dev for over a decade. I'm having a lot of fun learning it from scratch with no AI
I'll concede that before yesterday it had been a while though
> Especially something older that won't hold your hand
Python and JavaScript are two of the most "will hold your hand" languages these days aren't they?
> A lot of the most miserable parts of getting started coding have nothing to do with programming and everything to do with like, trying to apt-install the right compiler version or figure out which build headers you need or some other equally trivial bullshit that gets in the way of writing code.
I agree but absolutely not for these two languages in particular
You can open the developer tools in any major browser and start typing in JavaScript right there if you want
Python you can install it and write it right in any editor
The upfront burden for both languages is absolutely trivial imo
For example I am following Dirac's book "The Principles of quantum mechanics" to study QM. Pre-AI wouldn't have been able to do so, I am just that dumb. Even with AI its tough. but the thing is I can keep asking questions until I get that concept drilled in. Now I am doing it at a pace that's unfathomable to me.
But now that I am getting to grips with QM, I can get to things that I am really interested to learn like spin resonance and so on. This is something I am so grateful for.
Now it can be questioned that is it making me wise, intelligent or just "giving me answers" that I should strive to discover myself. I dont know the answer to that. But studying what I want, how I want and not getting judged is something i deeply enjoy. Srry the comment might have taken some tangents.
Why exactly wouldn’t you be able to learn pre-AI?
I run Ruff + a type checker.
https://github.com/astral-sh/ruff/issues/970
Though some of them will presumably be covered by Ty
If you passionately care about security and misuse-resistance you CAN write a spec that will lead to fewer implementation issues.
A lot of effort was put into making TLS 1.3 a stronger, less agile and more misuse-resistant standard than its previous iterations. And that effort worked.
If everyone simply designed everything right from the beginning we would live in nirvana.
In engineering we aspire to a slightly stronger standard: "I made it physically impossible to fuck this up."
I'd rather use a refined, battle-tested standard with lots of eyes on it than some new untested contender produced by a handful of upstarts ("look, we just designed it right from the beginning! This time it's perfect!") PASETO reeks of second-system syndrome.
tl;dr: most of the time you should use opaque random strings.
JWT is a serviceable solution for service trust and federation. This use case often just requires a very-short-term token, so lack of revocation support is not an issue. Replay attacks are still an issue, but they can also be prevented with single-use nonces that are included in the token claims.
The OP's take (and my take as well) is that JWT is rarely the BEST solution for this use case. You kinda have to use it if you need to implement a standard that mandates JWT such as OpenID Connect. But OpenID Connect is a great example for a place where JWT was used, but was never really necessary. If you do use the authorization code flow securely (on the server side, with a strong client secret and proper CSRF protection) you don't need the ID token. In fact, you don't need to use any cryptography at all! Just like random session IDs, you've got a stateful solution that works reliably without any cryptography.
If you cannot do a series of authenticated network requests between HTTPS endpoints to verify trust, then a signed payload could be useful, but you've got better standards than JWS/JWT for that. That's all.
This restriction precludes all desktop clients, mobile clients, and webapp clients -- any place where you can't trust the client code to protect a secret.
I don't exactly disagree with you: Security becomes much easier once you rule out handling all the hard edge cases.
I feel like I'm being argued in a circle by a series of strawmen.
But if you want access to user information, you can't just give access to an app that has a shared secret key to a all user data for every single users in the planet. You need to authenticate the user somehow, and sharing the user's password directly with the app is not a good idea for many reasons.
Even if you trust the app to be "written without any bugs", the moment you allow the password grant in OAuth, your service cannot use CAPTCHA, MFA or Passkeys efficiently. The password grant does not allow any of these, so this app that you've let through becomes the weakest link for all cybercrime groups that want to attack your service.
*edit: a recommendation for random strings in most cases isn’t perfect
Edit: also there have been how many attacks have there been on pseudo-random generators?
I think "don't use Mersenne Twister as your RNG" is a much safer bit of load-bearing advice than "use precisely these safe settings for your JWTs".
Edit: an impractical attack can still be used
And if you say those above are outdated, then you admit no technology is perfect *and should be updated
You’re welcome
It's ok if you're totally unfamiliar with this space, but I'd recommend replacing some periods with question marks in your comments.
Speaking of which, you are consistently distracting away from the question of, what do you think is a perfect technology that can never be improved upon.
Edit: separate track, i will agree random strings can be useful if you agree technology should always be updated.
EditEdit:provide me a recipie of Oreo cookie smore pie
[0] https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba...
https://www.acsh.org/news/2020/05/07/dr-norman-borlaug-he-sa...