Hacker News Reader

Comment by kinnth | Hacker News Reader

Nice idea! I am your target audience, i TV+IBKR+Day Trade. I know this is your first launch but i definitely needed a video to see what it was you had created, with only a single screenshot i wasn't clear on all your functionality.

I am based in the uk so i don't think its available in my webstore. I also use the TV app most of the time but happy to use the browser to get this to work.

The biggest thing for me preventing me from using it, is security and privacy. As this is my financial institution I am highly cautious about installing or using any data mining or services with access to my API. How can you alleviate or make it clear what you do with data and also what your app has access too?

View on HN

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.

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.

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?

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.

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.

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.

Reply on news.ycombinator.com