Hacker News new | past | comments | ask | show | jobs | submit login

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!




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: