3 ms·

Yes, I need to make a video definitely. Problem is IBKR has a minimum captial requirement for subscribing to real-time market data! And my program requires real

Yes, I need to make a video definitely. Problem is IBKR has a minimum captial requirement for subscribing to real-time market data! And my program requires real-time data because it only uses limit orders right now so it would look wonky - placing orders that don't go through and executing trades that have results that don't correspond with the display. There is other functionality that I can show maybe. It should be in the UK Chrome Web Store - it's only not in the EU. Can't have homeless people writing software! I really have put myself in a quite a pickle. I am going to have to return to Canada where I can get a job and keep working on this at the same time. Can someone recommend something on Mac to make such a video? To address the security and privacy issues - very very important given the nature of the software. When you have created an account on my website, the first time you open NBT inside TV you will be asked for your login password. You will then be asked for a data password. This data password is never transmitted to the NB server. The data password is used to encrypt your saved data (like order history, and settings). This encrypted data is saved to my server with a salt and an initiation vector, both of which are rotated every time you enter your data password at login. NBT desktop interface connects to my servers for three reasons. First, at login to get a jwt token, to download a json object with operating data and default settings, check subscription status, and to download the encrypted ciphertext which the user has saved there. Second, during usage to upload said ciphertext when saving. Thirdly, there is the 'bridge'. When activated, this opens a websocket connection to the NB server. This is used for the mobile interface and for trade-on-TradingView-alert. When you set an alert in TV you put a key (that is generated when you create a trade under the GenTrad button) in the message and set it to webhook. This key consists of one part which has meaning to me, the hookKey, and one part, the tradeKey which has meaning to you but not to me. The hookKey tells me to which websocket connection to route the alert to, and the tradeKey tells your desktop interface which saved trade to execute. The fact that I don't know what the trade key means to you conceals what trades you are making from my knowledge. The mobile interface is connected over the bridge as encrypted data packets within an encrypted websocket connection. The encryption is done using the data password. So you enter the same data password at both ends, your phone, and the desktop interface and authentication and authorization is established between the two by showing one another that you can encrypt data properly. All data processing is done client-side. Just hearing myself talk about this makes me feel like I might be confusing people haha not to mention that for some reason I'm telling stories about a forest. Although this is the best place to discuss things like how I have isolated myself and my server from knowing people's secrets.

nitrogenBlue 2y ago
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 2y ago
  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 2y ago
    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.

nitrogenBlue 2y ago

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 2y ago
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 2y ago
  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.