6 ms·
It never ceases to amaze me how otherwise intelligent people think it‘s a good idea to send unencrypted user data to random servers on the internet in the backg
by jakobegger 9y ago
It never ceases to amaze me how otherwise intelligent people think it‘s a good idea to send unencrypted user data to random servers on the internet in the background.
- JadeNB 9y agoIt makes me scared to be an iTerm2 user, frankly. Because I am an idiot, it never occurred to me that I'd have to wonder about the security implications of my choice of terminal emulator. Does it otherwise have a good reputation for security?
- problems 9y agoJust ditch it - clearly the author has no regard for privacy. I cringe just thinking about implementing something like that.
- mw6621 9y agoiTerm2 is great and George is absolutely responsive with any issue I've ever brought up. I am personally going to give him the benefit of the doubt here, I'm sure he'll fix things ASAP.
- deleted 9y ago[deleted]
- derimagia 9y agoYep was already fixed: https://gitlab.com/gnachman/iterm2/wikis/dnslookupissue https://gitlab.com/gnachman/iterm2/wikis/dnslookupissue
- 0culus 9y agoI don't think it's worth throwing the baby out with the bathwater. But this should at a minimum be an opt-in feature, and not opt-out. Better yet, it's probably not needed. I've almost never needed to interact with URLs in a clickable way via a terminal.
- sametmax 9y agoI do but I always know if they are valid before I click on them, so I don't see the appeal of the DNS lookup. Plus that must be freaking slow.
- JosephRedfern 9y agoNot necessarily slow, DNS Lookups are generally pretty fast: ~ dig somerandomurlimadeup.com | grep 'Query time: ' ;; Query time: 23 msec
- greglindahl 9y agoEr, that's just saying "you got lucky and the root nameserver you hit was fast". Looking up any valid .com requires that plus a 2nd level lookup.
- alanh 9y agooh wow, what would that make it, 50ms? that's almost enough time to blink!
- sametmax 9y agoCompare to the rest of the operations your terminal do, it's crazy slow though.
- JosephRedfern 9y agoI tried on several domain names (that I had not, to my knowledge, recently visited), and they were all around the 25ms mark. I'm not saying that this is the case universally, but for many the typical lookup time will be very fast.
- joosters 9y agoClickable URLs are very convenient. I have plenty of code that runs on remote machines and generates data that I'd like to view in my browser. Print the URL out, and I can click on it to open it up. n.b. for me, in iTerm2, I have to press cmd to make the links highlight before I can click on them - so there's little danger of accidentally opening something you didn't want to. Doing any DNS before clicking on the links seems like overkill, though. My browser can tell me if the URL is garbage or not.
- exikyut 9y agoThe author has fixed it, and clearly this has been an educational experience. Considering the professionalness of the rest of the app, I get the impression that the author is likely going to factor security considerations into the picture in a big way in the future.
- bluedino 9y agoI used to use it religiously but recently went back to Terminal on my last two Macs and don’t really miss anything
- burnte 9y agoCome on, it's doing domain lookups, it's not sending social security numbers to Russia. The amount of hyperbole regarding this misfeature is absurd. It was something that maybe should have been better expressed but this is not some kind of massive security failure.
- jakobegger 9y agoIt doesn’t matter what the code intends to do. Sure, looking up strings that look like domains seems harmless. But it means that every string that looks like a domain is transmitted unencrypted over the internet. If your software deals with private user data, you must consider the side effects of every API you are calling. You can’t just transmit data somewhere and hope that everyone will do the right thing. Network traffic is monitored on lots of networks. Unless the data is encrypted and you have reason to trust the receiver, don’t send it. And whatever you do, don’t send private data without user action. Users expect web requests to be made when clicking a link. They do not expect data to be transmitted when hovering the mouse over URLs.
- burnte 9y agoIt absolutely matters what the code intends to do. If it intends to do a DNS lookup, and does that, that's working properly, eepecially if it's doing an DNS lookup on what its regex says looks like a clickable URL. If it means to store an SSN in an encrypted DB and accidentally writes it to plaintext or sends it to twitter, that's a security flaw. If that same app is following the system standard method of doing DNS resolutions, what else should it do? Are you really suggesting that it should somehow encrypt a DNS lookup? Why should this app be held to a higher standard than every single other application that does DNS lookups? This is the absurdity I'm talking about. I completely agree that one must take into account how that feature fits with your product, user expectations, and privacy, but none of that means a feature that works as intended is a security flaw. As others have said, prefetching pages has been done for years. Checking to see if it's a valid domain isn't an unreasonable feature for iTerm's URL highlighting, and for those who would prefer it not, he's changed that behavior, but let's not pretend that it was some absurd use of data that no one could have reasonably predicted. And lastly, let's also stop clutching our pearls about "transmitting data". IT did a DNS lookup, and while technically that means there was a transmission, it wasn't taking what people traditionally call user data and transmitting it to a foreign third party. It's perfectly reasonable to check a domain name against a DNS server. Maybe unwanted, yes, but not even remotely irrational or irresponsible.