[nitrogenBlue]

Sorry, to add, NBT connects to IBKR by intercepting your oAuth client secret as TradingView talks to IBKR and then builds valid authorization headers to send its own requests. This information is never sent to the NB server, over the bridge, or saved in your ciphertext.

The data it stores in the ciphertext is order data from the /orders API. Right now the data processing just does things like figuring out which orders relate to one another to see your PNL for individual trades and days/weeks kind of thing.

[jdehorty]

Thanks for addressing this. However, I have concerns regarding NBT's interception of OAuth client secrets. This is a highly sensitive process, and any mishandling could result in unauthorized access and potential financial loss. Could you please explain how NBT ensures the security/integrity of this interception?

[nitrogenBlue]

I am not exactly sure what you mean by 'integrity of the interception' but I will speak on the process. This was actually one of the most difficult aspects to figure out but the solution ended up being fairly simple. At first I tried just going to local storage and finding the client secret, and, to this day, I don't know if it even lives there or not. There is some sort of data when TV is connected to IBKR but it is encoded by an unknown process and it looks like braille in the dev tools. I would love it if someone knows how to decode this, it should be a standard process but even ChatGPT seems to not know or be helpful figuring this out.

The solution I found was that I wrote a pair of very simple wrappers for the javascript engine's atob() and encodeURIComponent() native functions, that run in the webpage environment. These MITM's the functions and when the OAuth/websocket session ID information is passed to the functions by TV for whatever TV is doing, they grab what I need to piggyback the OAuth connection, and establish a websocket connection, and pass it through the DOM, as the dataset of an element, to the extension environmen, where it is held in memory and used to build valid OAuth headers and also the session ID for a valid websocket connection to IBKR for streaming data. This data is only used for talking to IBKR and I believe that even if this data was exfiltrated by a bad actor, IBKR itself does not tolerate changes of IP addresses during a valid session. I discovered that this is why many people have problems with getting disconnected from IBKR - because their IPs are not fully static for one reason or another.

It is absolutely true that my program requires the same level of trust as TV itself. And it has access to the same APIs as TV (which is a subset of the API that IBKR publishes for their Client Portal API). You can see the permissions required by my extension in the Chrome Web Store are just one and that is granted for only the Supercharts page.

Does this answer your question? Feedback is greatly appreciated as security and trust are my top priorities.

[jdehorty]

What I mean by "integrity of the interception" is ensuring the process of capturing OAuth tokens is secure, reliable, and not vulnerable to exploitation.

Your statement, "It is absolutely true that my program requires the same level of trust as TV itself," is misleading for a few reasons:

1. Security Practices: TradingView (TV) undergoes extensive security audits, compliance checks, and has a dedicated security team. Your tool, being new, hasn't been through this level of scrutiny. TV has a proven track record; your tool doesn't yet.

2. Attack Surface: By intercepting OAuth tokens and modifying TV's functionality, you're increasing the attack surface. More code and complexity mean more potential vulnerabilities. This token interception adds risks that don't exist when using TV directly.

3. Third-Party Code Trust: Users have to trust your code is secure and malware-free. TV's code is constantly under scrutiny, but your tool hasn't had this level of review. If your code gets compromised, it could lead to theft of sensitive data, including OAuth tokens.

4. Lack of Verification: TV undergoes regular third-party security audits. Your tool hasn't been independently verified, so users are essentially taking your word on security claims. This makes it hard to assess your tool's true security posture.

5. Potential for Misuse: If your browser extension gets compromised, a bad actor could push malicious updates to steal info or manipulate trades. The broad permissions often required by extensions could be exploited.

6. User Awareness: Most users probably don't grasp the implications of letting a third-party tool intercept their tokens. They might assume it's as secure as TV without understanding the nuances and added risks.

7. In-Memory Handling: You mentioned storing tokens in memory. This is tricky to get right. Proper handling would involve techniques like immediate use and secure erasure, in-memory encryption, and isolation of sensitive operations. Without these, tokens are at risk if the local environment is compromised.

I get that you're trying to enhance trading functionality, but by adding this interception layer, you're introducing new risks that don't exist with TV alone. It's not just about trusting you personally - it's about the inherent risks in this approach.

Have you considered getting third-party security audits? It could really help build trust and validate your security measures.

[nitrogenBlue]

Thank you very much for your response.

When you give my ext permission to operate in at a certain URL you are giving the same level of trust. Maybe this is the wrong word. It is better if I say NBT has authorization, but not authentication. Because NBT has been authorized but NBT is not you. NBT can prove authorization by using the data that it has intercepted, with permission granted by giving access to the URL, to to create a valid Authorization OAuth-ed HTTP header, using the authorization that was given when the extension was installed.

I will address each one individually.

1. Security Practises: The IBKR sign-in TOS explicitly abstains from taking responsibility related to using TV so IBKR does not itself 'trust' TV enough to take responsibility of the security practises of TV. IBKR has a Client Portal API which would allow any user to implement what NBT does, the difference is that NBT works inside TV. The TV TOS explicitly abstains from taking responsibility for a compromised email account. Everyone is passing the buck, which is natural in security along a chain of trusted software and devices. NBT cannot be more trusted than that which comes before in the chain, that is why I isolated everything except that which is necessary from my servers. Any audit, even without source code, would show that NBT does not pass the 'data password' to NB servers, nor any unencrypted data. The data that is sent to NB servers is clear-as-day if anyone wishes to look.

2. Attack Surface: I have considered various threat models up to and including things like me getting robbed at gunpoint. The main attack vector is that someone takes over (or I sell) my google account and pushes a malicious update. This is the reason I charge a subscription. Not only that but this software is published under a psudonym and although I could ask my sister to use her address to publish in the EU that, to me, would be a compromise of security. I have considered setting up a canary in the code as well which would warn in the event of a transfer of ownership.

3. Third-Party Code Trust: This was addressed above. This is why I am here to discuss every single point without reluctance. I am currently considering a completely disconnected version. I trust that the value of my software is beyond dark patterns and lock-in so this is viable for me.

4. Lack Of Verification: Again, this has been addressed above. Anybody is free to see the communicated data between NBT and NB servers and the data password is never transmitted, nor is any personal data transmitted unencrypted except the login password and account details. These are only encrypted with TLS like all HTTPS comms.

5. I have clearly addressed this. There is always a risk of an update containing something malicious, as there has been many high profile cases recently of supply-chain attacks. I would say that of any extension published for TV I have been more clear and willing to explain my security practises than any other. Have I done my due dilligence to understand security and the implications that NBT has? Yes. I have buit NBT to be as trustless as possible. I give you room to store an encrypted chunk of text and other than that I have your email and your login password is only encrypted once (TLS). All this is visible in Chrome Dev Tools and is auditable.

7. In-Memory Handling: It is my understanding that in-memory is best practises. NBT does not use cookies (NB the website does). My software does not handle anything other than JSON and will fail upon presentation of anything else. Not only that, it is required to abide by the CORS restrictions of TV itself. I snapped up the credentials from TV with a little inginuity (which may not even have been needed) so it's not like they are a fortress. Here I need to stress again that IBKR does not allow IP changes so the credentials are not actually useful outside of your HTTPS connection to IBKR.

Summing up, if you want something to place trades then you have to give authorization. Have I been through 3rd party review? Yes through the Chrome Web Store. Do I trust them? No! hahah Would I be willing to move along the lines of being audited? Yes. Is exactly what I say verifiable by the user? Yes.