Data security improvements with the new architecture?

[charliecruzan-stripe]

Hi! Really excited about the new architecture. Think it'll be a huge step forward for React Native as a whole! We're looking to add support to Stripe's React Native SDK asap 🚀

Some questions I was hoping to get answered: in the original RN architecture, data was passed from JS to native via the bridge. These messages weren't secure, since the bridge's message queue can be easily read. It looks like with the new architecture, that is no longer the case, thanks to JSI?

Bc of the bridge's message queue being public in the original architecture, we couldn't pass protected data from JS to native via native method calls in a privacy-compliant way (due to the previously mentioned bridge exposure). Instead, native views would be mounted that collect the data directly themselves. I'm hoping that with this new architecture, the native method calls (and the associated parameters) are no longer exposed like they were with the bridge? Was just hoping I could get some confirmation on that :)

[Kudo]

hey @charliecruzan-stripe, to share some of my thought here. there's no true security. even in native apps, there're still some ways to hook api calls, e.g. through objc method swizzling.

in react-native bridge, people may use MessageQueue.spy to intercept message calls. if a third party malicious npm module can use it to intercept the bridge calls. it can also monkey patch, e.g. global.__turboModuleProxy, to intercept some calls. it's just that the new architecture and JSI to increase the difficulty of intercepting calls through a single MessageQueue.spy.
one thing worth to mention and you might already know: you can use JSI nowadays without new architecture.

to harden the stripe library for a reference, e.g., you could try to inherit a custom TextInput to encrypt the credit card numbers from native side and decrypt the messages until delivered to server side.

[charliecruzan-stripe]

encrypt the credit card numbers from native side and decrypt the messages until delivered to server side

Yep, this was our plan! Just thought I'd ask here and see if there was a substantial security difference now. thanks @Kudo
But yeah, there's always some degree of risk for sure