Live data from Hacker News

Show HN: FlowTracker – Track data flowing through Java programs

github.com

11–20 of 34 posts

Re: Show HN: FlowTracker – Track data flowing through Java programs

#11
post #10

Earlier quoted context omitted.

Not sure I follow, can expand on that? I gave a presentation on it recently https://www.youtube.com/watch?v=BuSpMvVU7j4 which goes over demos and implementation details if you are interested in those topics.

I meant this [0], and so tracking a data via tagging it with a metadata and seeing where it ends up. Thanks for the video, I'm gonna go watch it. [0[: https://clojure.org/reference/metadata

So recording in FlowStorm doesn't use Clojure metadata capabilities in any way, it is basically about storing function calls, function returns and the pointers to all expressions intermediate immutable values together with their code coordinates.

Re: Show HN: FlowTracker – Track data flowing through Java programs

#12
post #6

Blown away by the demo tracking an HTML element back to the SQL statement that added that value to the database . I can totally see a future where tools like this are the first line of defense when troubleshooting bugs.

Thanks.

As I was developing FlowTracker, a lot of the work was driven by making tracking of specific example programs work. I knew what result I was aiming for, but it was hard to predict what lower level mechanisms needed to be supported to make a specific example work. That often depended on internal implementation details of the JDK or libraries being used where the data was passing through.

But the HTML element linking back to the SQL script that added that data into the database wasn't like that. I didn't expect or work towards it, that just happened, so it blew me away a little too and got me excited about what else this approach could accomplish.

Re: Show HN: FlowTracker – Track data flowing through Java programs

#14
post #6

Blown away by the demo tracking an HTML element back to the SQL statement that added that value to the database . I can totally see a future where tools like this are the first line of defense when troubleshooting bugs.

When you think about it, so many problems could have been prevented and so many business rules could have been easier to express if there was some standard way to track the origins and veracity of data.

Maybe also some way to track if the data is meant to be transient or meant to be written back.

The more such constraints which could be described up front, the better.

Re: Show HN: FlowTracker – Track data flowing through Java programs

#16
post #12
post #6

Blown away by the demo tracking an HTML element back to the SQL statement that added that value to the database . I can totally see a future where tools like this are the first line of defense when troubleshooting bugs.

Thanks. As I was developing FlowTracker, a lot of the work was driven by making tracking of specific example programs work. I knew what result I was aiming for, but it was hard to predict what lower level mechanisms needed to be supported to make a specific example work. That often depended on internal implementation details of the JDK or libraries being used where the data was passing through. But the HTML element l…

A great example of how design of good products should be guided by the end goal instead of by the technical mechanism, when possible. You went out of your way to make sure the functionality was not limited by a certain single mechanism.

Re: Show HN: FlowTracker – Track data flowing through Java programs

#18

If I recall there was a paper on a similar tool that was used for finding SQL-injections dynamically in java programs. Is this the same tool?

No, that must have been something different.

It would be possible to extend what FlowTracker does to also find SQL (or other) injection vulnerabilities. So it's possible the tool you're thinking of used a similar approach.

Re: Show HN: FlowTracker – Track data flowing through Java programs

#19
post #8

Hmm would love to connect this to our gralde builds :)

I know you may be tongue-in-cheek but if you're on the .gradle.kts flavor there's a reasonable chance it would work. The Groovy ones are, I suspect, just entirely too dynamic dispatch for it to make any sense (e.g. all flows are from org.groovy.SomeRandoThing and good luck)
Post reply on HN