Am I alone in thinking things like online pastebins, base64encoders/decoders, online heap analysers, online json linters, etc are all security issues where the sites can just harvest tons of data?
Uploading a bunch of stack traces to generate a flame map is one thing, but the heap can have secrets and keys and so on in memory.
I agree, uploading a heap dump is completely unacceptable. And their privacy policy seems to grant them a license to use your heap dumps (they call them "log files" which is obviously wrong):
https://heaphero.io/heap-terms.jsp:
>Software applications generate a specialized type of log file. These log files are hard for engineers to interpret and troubleshoot. Using the Site, users can upload log files and we parse, analyze, and generate root cause analysis reports instantly.
>By uploading log files or leaving us feedback, you may provide text, images, software, videos and/or other material, including third party content ("User Content") that you share using the Site.
>Your User Content belongs to you (or to the relevant third parties). However, you grant the Company the following non-exclusive license: a worldwide, transferable and sub-licensable right to use, copy, modify, distribute, publish, and process, information and your User Content that you provide through the Site, without any further consent, notice and/or compensation to you or others. You also grant us the right to use your log files to enhance the performance of our Services.
Not that I would trust even a perfect privacy policy when it comes to uploading heapdumps.
There are however some websites that work completely offline (you download the HTML page and there is no network IO), like CyberChef [1] or the Spotify thread dump analyzer [2].
No, I see it exactly the same way. Especially heap analyzers - you are uploading the entire content of your memory up there, including even the entire application (because classes are in the heap as well, and it's trivial to decompile Java classes, especially since even companies which release only obfuscated class files usually don't obfuscate anything while testing on dev machines, where a majority of heap dumps probably originate from).
In my eyes, anyone using such a service is as careless as someone posting unencrypted lists of his passwords hidden in Lorem Ipsum texts on Facebook so he can look them up if he forgets one. Any sane corporate data protection rulebook should prohibit the use of such services and consider any potential surreptitious use a harsh breach of trust and thus a cause for termination of the employment.
Definitely do not use their cloud service to analyze heap dumps out of production. You will probably be leaking sensitive company secrets, and, if your company's data handling policies are at all reasonable, you'll probably also be violating legal obligations to your clients, as well as their trust.
Doing it for development may be safer, insofar as it it's more likely to merely be dangerous, but not also tortious or unethical.
On these lines, allow me to introduce a valuable new service: MRLTaaS (Most Recent Leak Time as a Service)
Ever wondered when the most recent leak of your most valuable secrets occurred? Simply upload your password file to my web service and within moments the magic of our distributed AI will return the current date/time...
Not at all. I am not alowed to expose customer data to the world as well, regardless how many promises they make on the website regarding how carefully the data is handled.
Obviously bad to upload heap dumps, but they do have an enterprise plan you can pay for to host their software on your own hardware to avoid public upload.
Still, even offering the public upload option is a serious concern. They'd be better suited offering a download with free tier limitations.
Amazon used to (and may still) block access from their corporate network to any pastebin they could find, to try to stop engineers from using them to share code. They'd had too much stuff leak out that way, including API keys.
I once browsed around a local Scribdb equivalent and found tons of internal corporate and government-related documents that I'm pretty sure shouldn't be floating around on the public Internet; I bet they got indexed and included there because of some checkbox or TOC line item on a free PDF conversion tool.
I can recommend the Eclipse MAT tool if you want to do this kind of thing locally. A little awkward when you need to do advanced searches through the heap, but generally pretty good.
The tool will list objects on the heap, their path to the GC roots and allocation stack trace. That is usually sufficient to solve the memory leak. No need to create a large HPROF file or upload data to a server. Everything can be done in the shell.
I have a JavaFX app which is consuming far more memory than the heap allocates... even when I set Xmx. For example, with java -Xmx64m I can see that the app runs just fine, but it still consumes over 200MB according to the OS (checked with htop and with Mac's System Monitor). Does anyone know a tool to help find out why the JVM is holding on to so much memory beyond the heap, or how to make the JVM use less native memory?
I've found out that vmmap (as shown here[1]) is only a little helpful, as it has so much info I can't really make sense of it... and I also found this[2] answer on StackOverflow that was very helpful as it lets me see the native memory allocation by the JVM... but all I know now is that less than half of my JVM memory consumption is the actual heap: the rest is thread stacks (huge for JavaFX - around 50MB for my app), GC-allocated memory and around 25MB of class definitions!
That's the oldest tool in the Java dev toolbox... but it only shows heap usage and metaspace. Also, after Java 9+ they seem to have retired jvisualvm and the tool to use now is https://wiki.openjdk.java.net/display/jmc/Main
Yeah, I saw that... last release was just a few days ago... I thought that since the Java standard distribution stopped shipping it, it would just die off and JMC would become the new standard tool... knowing that it's still alive makes me very happy, especially after Oracle fired the whole team working on JMC[1] immediately after open-sourcing it..
However, in the VisualVM downloads page[2], they say:
"VisualVM has also been distributed in Oracle JDK 6~8 as Java VisualVM. It has been discontinued in Oracle JDK 9. See the Upgrading Java VisualVM page to learn how to upgrade to the latest VisualVM."
That's confusing wording: it sounds like they did "discontinue" something... I think they mean it just stopped being bundled with the JVM, which is not the same thing as discontinuing it.
I've used this a couple of times to profile running servers. Not perfect but it lets you profile memory and cpu usage. Visualvm is a PITA to get working over ssh.
Uploading a bunch of stack traces to generate a flame map is one thing, but the heap can have secrets and keys and so on in memory.