Isn't the article over emphasising a little bit on leakage of internal urls ?
Internal hostnames leaking is real, but in practice it’s just one tiny slice of a much larger problem: names and metadata leak everywhere - logs, traces, code, monitoring tools etc etc.
DNS naming rules for non-Unicode are letters, numbers, and hyphens only, and the hyphens can't start or stop the domain. Unicode is implemented on top of that through punycode. It's possible a series of bugs would allow you to punycode some sort of injection character through into something but it would require a chain of faulty software. Not an impossibly long chain of faulty software by any means, but a chain rather than just a single vulnerability. Punycode encoders are supposed leave ASCII characters as ASCII characters, which means ASCII characters illegal in DNS can't be made legal by punycoding them legally. I checked the spec and I don't see anything for a decoder rejecting something that jams one in, but I also can't tell if it's even possible to encode a normal ASCII character; it's a very complicated spec. Things that receive that domain ought to reject it, if it is possible to encode it. And then it still has to end up somewhere vulnerable after that.
Rules are just rules. You can put things in a domain name which don't work as hostnames. Really the only place this is enforced by policy is at the public registrar level. Only place I've run into it at the code level is in a SCADA platform blocking a CNAME record (which followed "legal" hostname rules) pointing to something which didn't. The platform uses jython / python2 as its scripting layer; it's java; it's a special real-time java: plenty of places to look for what goes wrong, I didn't bother.
People should know that they should treat the contents of their logs as unsanitized data... right? A decade ago I actually looked at this in the context of a (commercial) passive DNS, and it appeared that most of the stuff which wasn't a "valid" hostname was filtered before it went to the customers.
Reminds me of the year 2038 problem, which will be more scary than this.
So if you are storing epoch time (no of milli seconds after 1970) in integer variables, your code will most probably break, which I feel is going to happen in a lot of scenarios.
Google also used to have a go app which they deprecated later on, while now i think about it what is the use of having a go app, if the websites which are shown in search results are not optimised for slower networks.
I had the same doubt. With CLIs you can make your own custom shortcuts, LLMs can use it to get things done for you as well. With TUIs I think either these are hobby projects or meant for people who are obsessed with speed.
Though speed impacts are also something which I am uncertain about. Comparing Vim with IDEs, for sure there will be few things which are faster in vim but decent no of things which can be done faster in an IDE as well, so can't comment on your overall speed gains.
Amazon used to be really customer centric 5-10 years ago, I remember once I ordered a physical book which was late in delivery and I urgently needed that book, so they gave me a free kindle edition till the book got delivered.
Last week I had a vendor tell me that they did warranty service through Amazon, and I should contact Amazon for a replacement, even though I was outside of their return window. It turned out to be a lie. But Amazon refunded me the full amount anyway, without prompting. The handful of times I've contacted Amazon tech support this has been my experience. The previous one was when they replaced a $250 porch pirated delivery, no questions asked.
This behavior genuinely earns them more of my business.
The "danger" of their policies (and I've benefitted from them, too) is that they obviously can be gamed, and they obviously have to have defenses against that - which means if you cross some invisible line (and now likely AI-monitored) you're doomed; no recourse.
or get requests with query params already handles this in majority of the cases, unless the query size is too big (which ideally should not be the case since in the end it is a get request)
This theory seems to be BS, If let us say a founder is raising a seed round of 2m at 20m valuation, then according to hypothetical accrual tax rate, they would need to pay a tax of ~ 3-4m.
reply