Well apple themselves are pushing swiftUI and I suspect it will be the main (and only) approach as time goes on, even though its just a wrapper around "older" approach...
no, not really, PQC is already being discussed in pretty much every relevant crypto thing for couple years alearady and there are multiple PQC algos ready to protect important data in banking etc as well
I don’t really understand the threat to banking. Let’s say you crack the encryption key used in my bank between a java payment processing system and a database server. You can’t just inject transactions or something. Is the threat that internal network traffic could be read? Transactions all go to clearing houses anyway. Is it to protect browser->webapp style banking? those all use ec by now anyway, and even if they don’t how do you mitm this traffic?
As far as i am aware, eliptic curve is also vulnerable to quantum attacks.
The threat is generally both passive eavesdropping to decrypt later and also active MITM attacks. Both of course require the attacker to be in a position to eavesdrop.
> Let’s say you crack the encryption key used in my bank between a java payment processing system and a database server.
Well if you are sitting in the right place on the network then you can.
> how do you mitm this traffic?
Depends on the scenario. If you are government or ISP then its easy. Otherwise it might be difficult. Typical real life scenarios are when the victim is using wifi and the attacker is in the physical vicinity.
Like all things crypto, it always depends on context. What information are you trying to protect and who are you trying to protect.
All that said, people are already experimenting with PQC so it might mostly be moot by the time a quantum computer comes around. On the other hand people are still using md5 so legacy will bite.
> Well if you are sitting in the right place on the network then you can.
Not really. This would be if not instantly then when a batch goes for clearing or reconciliation, be caught -- and an investigation would be immediately started.
There are safeguards against this kind of thing that can't be really defeated by breaking some crypto. We have to protect against malicious employees etc also.
One can not simply insert bank transactions like this. They are really extremely complicated flows here.
I meant on a technical level you could insert the data into the network. Obviously if the system as a whole does not depend on TLS for security, then no amount of breaking TLS will impact it
Sure, if a bank gets compromised you could in theory DOS a clearing house, but I'd be completely amazed if it succeeded. Those kind of anomalous spikes would be detected quickly. Not even imagining that each bank probably has dedicated instances inside each clearing house.
These are fairly robust systems. You'd likely have a much better impact dossing the banks.
Okay, but breaking that TLS (device->bank) would allow you to intercept the session keys and then decrypt the conversation. Alright, so now you can read I logged in and booked a transaction to my landlord or whatever. What else can you do? OTP/2FA code prevents you from re-using my credentials. Has it been demonstrated at all that someone who intercepts a session key is able to somehow inject into a conversation? It seems highly unlikely to me with TCP over the internet.
So we are all in a collective flap that someone can see my bank transactions? These are pretty much public knowledge to governments/central banks/clearing houses anyway -- doesn't seem like all that big a deal to me.
(I work on payment processing systems for a large bank)
> Has it been demonstrated at all that someone who intercepts a session key is able to somehow inject into a conversation? It seems highly unlikely to me with TCP over the internet.
if you can read the TLS session in general, you can capture the TLS session ticket and then use that to make a subsequent connection. This is easier as you dont have to be injecting packets live or make inconvinent packets disappear.
It seems like detecting a re-use like this should be reasonably easy, it would not look like normal traffic and we could flag this to our surveillance systems for additional checks on these transactions. In a post quantum world, this seems like something that would be everywhere anyway (and presumably, we would be using some other algo by then too).
Somehow, I'm not all that scared. Perhaps I'm naive.. :}
> It seems like detecting a re-use like this should be reasonably easy, it would not look like normal traffic
I don't see why it wouldn't look like normal traffic.
> Somehow, I'm not all that scared. Perhaps I'm naive.. :}
We're talking about an attack that probably won't be practical for another 20 years , which already has counter measures that are in testing right now. Almost nobody should be worried about it.
while jquery had a gajillion of exotic apis to do pretty much everything, react is, frankly, pure js with handful of apis: jsx (html with pure js), useState/useEffect/useMemo (rarely you need more), and initial hydration function. Rest is utility libraries, bundler, and all the wondeful things that brings you endless headache and depression because without them fulfilling yet another business req would take 10x more time
they are not intrusive but their entire focus changed on that instead of other features. Entire Git view feels abandoned in half done state yet they spent entire month working on AI chats, AI agents, their own AI edit (that's priced 20 per month yet they boast how light and performant it is -- why isn't it free local model then and why its priced worse than copilot?)
They're moving from "making awesome code editor" into yet another "buy our ai" product
debugger is very far from being feature-complete, I would call it MVP at the moment; lets see if they will iterate on that or will quickly go back to new shiny thing...
The fact that they have released both features within 3 months of each other is mind boggling. Their development velocity is insane. These are not trivial features.
AFAIK they added conflict resolution just recently, so it's not like non-AI features such as Git get no attention at all. And of course the debugger now.
I'm much prefer the VS Code style when you have 2 clear sections: staged and not staged. Zed's chose the IntelliJ style which is just a bunch of checkboxes, I can see it being easier to understand for the novice, but not very intuitive from a git point of view.
Never used Git in Jetbrain IDEs or Zed (yet), but recently VS Code improved a lot the Git by making easier to stage changes in a file in a granular manner (I tried briefly edamagit extension a while ago and now use a lot gitu in the terminal, in combination with VS Code version control).
I suspect their previous “collab editing” marketing angle was probably not a big enough draw. AI features seem to be desired by more people, or at least the hype cycle currently says so.
I hate the direction they're going to be honest with this giga focus on AI bullshit. Only good part added was zeta (their own predictive editing model that jumps across the file where it predicts you want to edit your typo etc AND have a "subtle" mode), but they price it at 20/month, which is absurd.
> I don't want to learn a complex framework. I don't want to learn magic that I don't understand without reading the documentation (useState, createSignal et al)
I'm always suprised reading statements like that. No offence, but maybe you're in wrong career if you don't want to learn how most popular and important tools of today work... Not to mention that its so simple you can learn everything required to be efficient during lunch break
> I'm always suprised reading statements like that. No offence, but maybe you're in wrong career if you don't want to learn how most popular and important tools of today work... Not to mention that its so simple you can learn everything required to be efficient during lunch break
This is such a common comment that I am never surprised to see it pop up whenever the "front-end mess" discussion arises.
No, you cannot learn React over a lunch break. You cannot learn Angular and Vue over a lunch break.
I am skeptical that even you, personally, can learn just the footguns alone present in the hundreds of thousands of lines of code in a specific $FRAMEWORK over one lunch break, two lunch breaks or even a dozen lunch breaks.
All those thousands of lines of code implement something, and I will wager a month of my income against a month of your income that you will not learn more than 3 or 4 concepts over a single lunch break, because they all have multiple concepts, multiple use-cases, multiple exceptions-to-the-general-rule and multiple footguns without even including the edge-cases they solve.
You will spend several years of lunch breaks, unless you consider reading the wikipedia overview for each $FRAMEWORK to be "learning the $FRAMEWORK".
Web components, OTOH, have less functionality than full-blow $FRAMEWORKS, but each can be individually learned over a lunch break, reused by non-JS-developers and is a knowledge base that is more or less future-proof.
React is particularly easy to learn tho, much easier then angular.
What you definitely can not learn over lunch breakis whatever local developers created as a local ad-hoc framework. Those area always more time consuming to work with, because you have no internet, stack overflow or documentation to help you.
Never understood this posts. React as a whole and state management became many times easier over the years (been working with it, vue and a bit of angular for 6+ years now).
Function components removed stuff like getDerivedStateFromProps and many other things, introduced clear and simple way of component updating (as in "prop reference changed, I'm gonna render now").
For state we got redux toolkit, which simplified reducers, zustand and recoil/jotai and mobx which allow you to pick based on your needs instead of writing million reducers or passing state to children when you don't really need it.
Its not "react got hard", its people unable to adapt to changing world. Every mainstream framework in reality got streamlined, simpler and more effecient to create apps.
> React as a whole and state management became many times easier over the years
This to me is exactly the problem actually. React was an object oriented framework; it leaned into that for managing state for components. Then they introduced stateful functional components in 16.8, and React became an entirely new paradigm. 16.8 should have been an entirely new framework, and yet it was merely a minor version bump. I can't find myself blaming users for finding it difficult to keep up with the whims of Facebook.
I rather like React, but its names for things (like "getDerivedStateFromProps") are always just godawful. They're wordy, and even all of those words really don't make the purpose clear.
I was always particularly aggrieved by "mapStateToProps", which obfuscates that it's referring to the Redux state rather than the thing that's actually called "state" in the component. And why the heck are we mapping it into the props? (Not that "useSelector" is any great model of clarity, but at least it's a compact verb-noun pair.)
