smoothgrammer

There is a whole talk on how to use it even for interactive sessions.

https://youtu.be/hBcfrQ8y5Qg?is=Osjnhjrx7WgsHqVj

Wait for Into the Radius 2. The first was a masterpiece as well.

Yes they do. If you subscribe to Google One.

https://support.google.com/googleone/

You should reread. It is very obvious why that won't be a problem if you sit back and think about it.

I hope you don't get hit with a malware fiesta.

If an one source project wants contributors they should recognize it. If they don't then they should not accept new contributors.

It's 100% unethical to take credit for someone else's work.

Make sure you sign the information that indicates the requestor.

Try enabling advanced data protection. If they can still log in then you have found a huge vuln.

The article is missing key data. The password iterations that are set low are client side. The server side is different.

The writer of the article needs to retract.

https://support.lastpass.com/help/about-password-iterations-...

Killed 2 months later to examine the brain.

The TOS says they will provide advance warning. Oracle is in breach of their own contract.

One thing to remember is that these fun utils won't exist on production servers. You also don't want them there for obvious reasons. I find it better to use the most commonly available set of unix tools and I end up being far more effective due to that.

I'm shocked so many people forget this

It's good, but a lot of integrations with Google do not work with advanced protection. Which results in me having 2 accounts, 1 primary and 1 secondary for whatever doesn't work with advanced protection. I've particularly found android tv to not play nice with advanced protection.

It was authorized by the operators of the building. The pentesters literally did everything by the book. Even the responding police officers were about the let them go, until the Sheriff arrived. If anything this highlights the criminal justice system reform needed to deal with bad LEO through a system like mandatory self insurance.

Always do a periodic full off-site cold backup of all your GitHub repos. It's very easy to script and should compress down very small.

They claim HIPAA compliance due to e2e encryption. That is far from an oops.

They updated their documents since, but last week they had documentation up that said they were HIPAA compliant due to end to end encryption.

Guess who owns Venmo? You have 1 attempt.

github needs to read this article. I've seen some pretty awful diffs on github and have had to resort to using CLI diffs which tend to be superior. For a company that's bread and butter is code, vcs, committs, PR's, etc you would think their diffs wouldn't be scraping the bottom of the barrel.

I know, right? Who could possibly judge one way or the other?

fencepost error

It is a mixed bag.

In finance technology is seen as a cost center, not a profit center. They want the minimum needed to ship. Early on this results in a lot of tech debt. Later on, fixing the system is too hard and thus they need to hire super smart people to figure out the mess they are in for any code change.

Enforcement actions are INCREDIBLY rare. The penalties are shockingly low. Thus the cost of failure to comply is low, and the businesses are not prioritizing compliance.

Some mistakes, yes. But this was a case of such a basic and clear cut use case that should have been tested.

My understanding is that companies such as this rely purely on manual testing. Thus it is easy for things to slip through the cracks. Usually they never get hit by penalties or get caught so the pressure to do better is not there.

It is confidence. It is the right tool for the job.

What would you propose as an alternative?

Get out while you can.

It is not about confidence. It is about ownership and being a good engineer. A good engineer would have cared about the code base and ensured that a test would fail, a use case would be linked to that failure, and someone would see that they have now violated a regulation.

Then if the regulation changed, someone would grep through the use cases, and see what behavior is occuring/ how to modify the code base to cope with the change in regulations (this occurs a lot). Of course most finance firms don't do this and actually violate regulations all the time. There is literally a gold mine for the SEC/FINRA to go after, but the government is fairly incompetent at mining through the data and holding companies accountable. The reason being that they don't pay enough to hire the talent that would uncover the violations.

Or you just write a test that checks to make sure you don't screw up.

Basically imagine you want to buy apples from 3 different fruit stands in different parts of a city.

Fruit stand 1 is the cheapest, fruit stand 2 is the 2nd cheapest, and fruit stand 3 is the third cheapest.

You want to buy all the apples out there.

The rule is that you have to go to the cheapest fruit stand first, and exhaust their supply before moving onto the next cheapest fruit stand. If you want to go to ALL the fruit stands at the same time you need to tell them you are an 'OK' guy and are really buying fruit everywhere.

Well, someone deleted code and ignored one of the fruit stands. This violated a rule and cost the fruit buyer a lot of money in penalties.

Sadly, this is the norm in finance. You would be shocked at the shittastic state of the companies that dominate in this industry. They are literally a house of cards waiting for a strong gust of wind.

In finance you'll find low accountability for developers. Basically finance is where great developers go to get paid a lot to become horrible developers. Very few companies in finance are pushing the bar on quality code since they culturally cannot accept the cost of that. It doesn't make sense until it is too late and by then their code base is too entrenched.

I've seen this at countless finance companies, and from interviewing people across the entire spectrum of finance. It is a rare corner of the industry where you'll find quality engineering. Usually everyone in a finance company thinks they are amazing engineers, and are just plain wrong.

My advice: work smarter, not harder.