Always made me judge my company's security teams as to why they enable this stupidity. Thankfully they got rid of this gradually, nearly 2 years ago now (90 days to 365 days to never). New passwords were just one key l/r/u/d on the keyboard.

Now I'm thinking maybe this is why the app for a govt savings scheme in my country won't allow password autofill at all. Imagine expecting a new password every 90 days and not allowing auto fill - that just makes passwords worse.

Ah I really wanna trust AI won't "fix" the tests by commenting out the assert statements or changing the comparison inputs willy-nilly. I guess that's something terrible human engineers also do. I review changes to tests even more critically than the actual code.

Using sha256 was a no-brainer, at least for me.

Now, I end up restarting with that mere act, and have to long-press to shut down again because the shut down option won't show up on login screen.

Afterwards, 1) if per month amount is greater than a regulated threshold, manual confirmation is needed. [ This is friction ] , 2) cancelling can be as simple as going to your bank's website and deleting the "mandate".

In all honesty, this is probably a really balanced approach, but the roll out was a real pain, with banks and merchants collaborating on who supports whom, etc. International payments got screwed completely - to this day, I can't subscribe to nytimes, after almost 2.5 years of this.

(A good summary - https://support.stripe.com/questions/rbi-e-mandate-regulatio... )

That doesn't sound unreasonable, on average. But I suspect the distribution is likely pretty uneven.

Hate to generalize, but this has less to do with "Indian style" but rather adding a lot of fluff to make a problem appear more complex than it is, OR maybe someone set a template that you must write such and such sections, despite there not being relevant content. [ Half the sections from this article could be cut without losing anything ]

In this case, the _former_ really shouldn't have been the case. I for one would love to read a whole lot more about rollback planning, traffic shifting, which query patterns saw most improvements, hardware cost optimizations, if any, etc.

I don't know exactly what they hope to gain by jumping on that bandwagon though; neither the physicists nor the computer scientists are going to value this at all. And dare I say, the general populace associated with the two fields isn't going to either - case in point, this hn post.

If there weren't any noble-worthy nominations for physics, maybe skip it? (Although that hasn't happened since 1972 across any field)

I have a slightly different example of this, where a rpc framework used in my company disallows the service owner from modifying certain headers (say request identifier), and will instead create a duplicate header with a suffix. In that scenario at least, I can see this as a fairly reasonable tradeoff, as the goal is to control certain headers from being modified, not because they are platform internal but because there are certain assumptions associated with those headers that are followed company-wide.

I'll go check what mechanism is used for this matching.

I do know that this is done - in fact worked at a pretty major smartphone manufacturer and never logged in to any personal account on work devices. It was pretty obvious by even just looking at the security info on chrome/firefox that the certificate used was a root signed by the company itself. I used to shout at the top of my lungs to my friends, that hey, _this_ is how your information is vulnerable to the corporate overlords, but I guess they weren't as paranoid as I.

The first thing I checked when moving to my next employer was if they were intercepting SSL traffic like this. (They weren't - they used Falcon)