Show HN: Nitrogen Blue Launching from the Forest
nitrogenblue.com
nitrogenblue.com
More directly, I have no idea about the domain you've created this software for but I'm in admiration of your resourcefulness.
...from the forest. Haha, very cool.
One main feature of NBT: There is an ETF with the ticker SOXX, indexing semiconductor companies. There are two ETNs SOXL(3x leveraged) and SOXS(3x leveraged inverse). People day-trade these because they regularly move 1%-6%+ within a day. If you think SOXX is going to go up, you buy SOXL and if down then you buy SOXS(rather than short selling). To make a trade with TV it takes about 5-10 clicks and involves making calculations and opening windows and entering numbers in. With NBT you press Go Up or Go Down - that's it. To exit your position, you press Close Up or Close Down. It's waaay faster and when you are trading like this it needs to be fast(fast to take action, not buy and then quickly sell type of fast).
There is other functionality but this is a good example because most of my interface real estate is dedicated to trading these ETNs.
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?
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.
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.
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.
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.
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.
Funny founder (or cautionary) story: for the past ~100 days I have been living in a tent in the forest outside a small town near a major European city. I've been working in libraries, cafes, hotel lobbies, park benches, the airport, cafes, etc. Anything to stretch out my bootstrap resources.
4 years ago I decided I was going to open a software company and try and break free from a life working in the service industry. I bring a lifetime of tinkering with tech and 20 years of experience in the service industry to the table, which I believe has given me a unique perspective on system design - systems run restaurants, people run systems.
When I set out traveling 2 years ago I had a set amount of resources saved up to bootstrap the company. 16 months ago I had decided on a market, a problem and a product. I thought it was going to take 3 months to get to first launch, so here I am!
There is a small hill that I hike up everyday where I can judge my physical energy level, which remains high. I have lost weight but I am just a little leaner now, so no problem. I spend a lot of time and energy on things like gathering food and water, finding electricity, setting up and taking down/hiding my camp every day, etc. The balance between surviving and working is a welcome one.
The problem that I am solving is that TV's and International Brokers(IBKR)'s trading interfaces are extremely frustrating to use.
The great thing is that NBT doesn't inhibit TV's own trading functionality, if that's what you're familiar with, it simply adds a new pane that can be opened and closed as if it was part of TV itself. It piggybacks on the existing authenticated connection between TV-IBKR and adds functionality including the following: - single-click buying and selling of charted securities - single-click leveraged/inverse pair ETN trading - simplified position sizing - in-program conditional trading (stop loss, take profit, etc) - advanced order creation - trade execution on TV alert webhooks - trade history storage and analysis - in-program paper trading - overnight trading - a functional picture-in-picture interface - a mobile/remote control interface (not being released today)
I would like for everyone to be able to play with the actual software, but it only works with CHROME+TV+IBKR. It is also not available in the EU because they require an address to do business there, and, well, I live hidden in a forest.
I am very happy with the way it has turned out! It began as just a program so one could single-click trade leveraged/inverse ETN pairs but during the early months I began to realize how much I could do and that I could provide functionality that spreads across multiple types of traders/investors. The feature set being released today is just a subset/base of some much larger concepts that have already taken root including a unique AI integration (no, it has nothing to do with the markets or prediction or anything like that).
My stack is JS, CSS, HTML, Node, NGINX, ArangoDB, Debian, Linode, Stripe. I have avoided using anything, like libraries, that I don't absolutely have to use.
I only have about 2 weeks of resources left which has really pushed me through all my fears about launching the company. The next few weeks are going to be the challenge of finding ~200 users to keep the company alive.
I see Nitrogen Blue becoming a trusted software company with a suite of both open and paid software that strives to bring-value-to rather than extract-value-from. I am open to finding a co-founder that is able to bring capital and business alpha - I just want to write great software.
My el3kr0nik mail, no nomburs: p1s2o3i4@5p6m7.8m9e0 if you're interested.
Thanks for your attention! I hope you enjoyed my story (if not at least found it cautionary:)).
BTW: IBKR stands for Interactive Brokers, I haven't seen them use International in their name.