I had a junior dev show me a neat site where you can paste in a Java thread dump and it performs an analysis. After explaining why it's a bad practice to send diagnostic details to an un-trusted third party I think he understood, but it seems like every week I'm finding people using ngrok, unauthorized password managers, grammarly, JWT parsers, Base64 encoders, and all manner of questionable tools.

I too wonder if I'm out of touch, if I'm tilting at windmills.

> I'm finding people using ngrok... and all manner of questionable tools.

At least ngrok supports end-to-end TLS tunnels[0], where you use your own TLS key/certs and the ngrok server never sees plaintext (the ngrok client is also open source, so for the truly paranoid you can examine it to ensure it isn't doing anything nefarious).

But I agree... I've seen people at a company where I used to work pasting sensitive data into a public pastebin. It still hurts my brain to think about it.

[0] https://ngrok.com/docs#tls

You're not out of touch. People like to trade security for convenience and while it doesn't always present an issue, it's a bad habit to get into. It's also one thing to take personal risks, it's another to put risks onto the company.

How are any of those questionable tools?

Sure, don't put arbitrary shit on the internet and know where your data is going. But every example you gave is incredibly useful to many people on a daily basis.

Leaking a bit of code will unlikely cause a problem, but the guns that can backfire are some of the cert checkers and SAML validators.

It can also happen you don’t care about the data you are sharing. Why not using an online then?

Still too dangerous, and I don't trust new developers to make that determination. Once you get into the habit of pasting development details into random website textboxes hosted who-knows-where with who-knows-what ad networks, you're one keystroke away from leaking sensitive details that are correlated to your employer's IP range.

Or maybe I'm a crank and need to lighten up. That's why I'm asking.

It's a reasonable thing to worry about. Bad actors exist. IP is valuable. Computers are insecure. People are lazy. You have to be careful out there.

> I don't trust new developers to make that determination.

Ignoring this issue is a sign of professional immaturity. Recommend you view it as an opportunity to educate the younger members of your team. Show them the power of a solid CLI toolbox that respects your privacy while delivering solid performance.

Still, you shouldn't be dogmatic about it. Webapp tools can be useful for understanding a new programming language or API. Just be judicious.

I agree 100%, perhaps I could have phrased that better. I try to use it as a teachable moment: "Hey, instead of using base64decode.org did you know you could use atob and btoa in a web inspector?"

Security-related scanners are a tough one though. Free XSS scanners, free TLS cert checkers: The best intentions can result in unintended disclosure. Developers have it constantly beaten into their head "Security! Security! Security!" and are often given nothing more than an OWASP cheat-sheet, so I can totally understand and empathize with the thought process that leads someone to plug a company URL into a free web-hosted XSS scanner.

Hum. I can see both cases. I would also think even if they copy/paste sensitive information. Like SSNs or password. It will be so diluted in the noise of other people data that it won't matter. Most of these websites - I made one myself - are run by people like us and we won't care about what it sent to the server.

Google offers a digital leak prevention service as part of GCP. You could use it for offensive security to find likely PII without much concern about the noise.

Google runs this (or an internal version) of this service to make sure people serving third party ads aren't sending sensitive data. At one of my past companies our customers would send out email marketing campaigns that contained URLs with tracking parameters with PII. We wound up having to just strip off any query parameters we didn't explicitly need because Google kept flagging us for PII leaks caused by our customers.

So yeah, there's a lot of noise. But, people are listening out there!

You can do the same in the browser console. I don't really get why people need an online tool for this:

   copy(JSON.stringify(obj, null, 2))

obj can be parsed with JSON.parse if it is in text.

Even better, just open the JSON file in Firefox.

Not bad. I usually copy json data from the browser console, but for files this can be useful.

> I don't really get why people need an online tool for this:

That’s rather condescending, and probably not true. Surely you must be able to think of reasons why someone would use a website instead of writing a one-line program.

The only reason I can think of is if this is something which one very rarely needs. Otherwise, I'd think those who regularly handle JSON files are able to write a one line program.

And the JS console was only an example. Other languages can also pretty print JSON trivially. E.g. python.

On chrome at least copy(Paste json here) is enough

It drives me crazy when I see people do it. For the most part tools like VSCode have plugins for it as well, so no need to send this stuff to random third party.

The biggest struggle for me is diffing random bits of text. Pulling two JSON docs from the DB and wanting to compare them. Recently found a VSCode plugin that makes it a bit better, but still a pain in the ass.

Does a diffing tool maybe satisfy your requirements? I personally use Meld but there's lots of them out there.

I've caught coworkers doing this with base64 for at least a decade before JSON was a thing. And keep in mind we base64 things like credentials, RSA keys...

There are some things you just shouldn't paste into the internet.

This is what keeps our security industry employed. Anything like a pastebin is blocked at my workplace.

It should be noted that this particular site works without sending any data back to the server.

Aside from that, this is one area where web-based applications excel: You can inspect and limit what data an application is sending away about you via your browsers built-in dev tools and extensions like uMatrix (or your own request-filtering extensions).

I always quickly check my Chrome Inspector to make sure it's not sending anything to a server.

Don't count on this. There are ways to guess if the dev tools are likely to be open and then alter nefarious behavior based on that.

For example you can detect changes in window sizes or look for plugins that are in the global namespace (e.g. Redux Dev Tools). Better play it safe and don't copy and paste private data to random sites.

Another attack vector would be to avoid sending down any data unless it contains something that looks like a hash or a token, or has a keyword like "password."

There are also ways to wait until you close or navigate away from the page, using window.onbeforeunload / window.onunload / navigator.sendBeacon: https://stackoverflow.com/questions/4945932/window-onbeforeu...