4 ms·

Super cool... but these tools always seem to be in the non-existent middle of a Venn diagram of "big enough a dev can't hold all context" and "small enough no o

Super cool... but these tools always seem to be in the non-existent middle of a Venn diagram of "big enough a dev can't hold all context" and "small enough no one is going to care if we hand over everything". What are your thoughts on this issue and the future of these kinds of tools where teams have to hand over the key to the city on a ongoing basis and running on dev computers? Most dev tools are isolated to a certain extent and aren't getting blank checks to the entire engineering department from top to bottom with access to external tools that detail business concerns. These tools seem like extremely ripe pickings for targeting for corporate espionage / hackers to 'pwn' companies.

baristaGeek 4y ago
This is a very good and common question we get, thanks for bringing it to the discussion. We have a very strong conviction that these kinds of tools have to be open-source to solve this trust issue. In fact, we wrote this blog post where we talk about how we're building this without storing your code or passing it through our server at all: https://www.watermelontools.com/post/building-a-code-archeology-toolbox-without-storing-your-code https://www.watermelontools.com/post/building-a-code-archeol... You still have to give us read access to your GitHub, Slack, Jira, etc. Which is still asking for access to corporate info, but you know... people are very used to giving access to these tools via oAuth flows. Regarding running on dev computers, we have one answer to that: Providing value as a GitHub Action. We still haven't launched it (it's gonna happen very soon), but our hypothesis is that by packaging the product in such format, we'll be able to address that very valid concern. Thanks!
estebandalelr 4y ago
Our attack surface is big, yes, but think about slack or Apple notes, where people keep the actual api keys. We could be a risk, but I, as CTO have ensured to the best of my knowledge it's hard to do. If you want to talk more about it, I'd love to do so, learning would be great!
quickthrower2 4y ago
Same issue with CI systems surely? And indeed Github itself! But people use them. I wonder why they are so successful.

baristaGeek 4y ago

This is a very good and common question we get, thanks for bringing it to the discussion. We have a very strong conviction that these kinds of tools have to be open-source to solve this trust issue. In fact, we wrote this blog post where we talk about how we're building this without storing your code or passing it through our server at all: https://www.watermelontools.com/post/building-a-code-archeology-toolbox-without-storing-your-code https://www.watermelontools.com/post/building-a-code-archeol... You still have to give us read access to your GitHub, Slack, Jira, etc. Which is still asking for access to corporate info, but you know... people are very used to giving access to these tools via oAuth flows. Regarding running on dev computers, we have one answer to that: Providing value as a GitHub Action. We still haven't launched it (it's gonna happen very soon), but our hypothesis is that by packaging the product in such format, we'll be able to address that very valid concern. Thanks!

estebandalelr 4y ago

Our attack surface is big, yes, but think about slack or Apple notes, where people keep the actual api keys. We could be a risk, but I, as CTO have ensured to the best of my knowledge it's hard to do. If you want to talk more about it, I'd love to do so, learning would be great!

quickthrower2 4y ago

Same issue with CI systems surely? And indeed Github itself! But people use them. I wonder why they are so successful.