elfakyn

I wrote this up since, over the past year, I've encountered more and more weird behavior with s3 bucket policies.

I haven't seen all of this behavior documented in a single place, so here it is.

Some of it has security implications (such as being able to brute force usernames) that is worth knowing about.

A TL;DR of the security stuff:

* Brute-forcing valid principal names is possible, since you can't create a bucket policy with an invalid principal.

* User compromise will break cross-account access, since if AWS becomes aware of a compromise, they will want you to delete the user and recreate it.

* Explicit denies will stop working if the principal is deleted and recreated, since they operate internally on the Principal ID and not the ARN

* Canonical IDs offer no extra security compared to account ARNs, since it's trivial to convert them back and get an account number.

I doubt this would get as much media attention if Tolkien wasn't involved.

Before anyone asks for sources:

https://www.fpri.org/article/2017/03/nationality-ethnicity-e...

https://slate.com/news-and-politics/2017/03/many-ethnic-russ...

https://en.wikipedia.org/wiki/Russians_in_Estonia#Citizenshi...

https://ecpr.eu/filestore/paperproposal/3e77f4ab-9a20-4440-b...

Yes, and that directly causes a device to fail SafetyNet Attestation which can cause some third-party apps to not work even with sideloading/different app store.

Edit: like Netflix, Hulu, and Snapchat

> You can "unbreak" glass. I had a project that started to get a stress fracture as it cooled. I quickly put it back in a cool part of the torch flame to anneal it. The cracks literally healed.

Curious, would that still maintain a weak point in the area?

The problem is that people often conflate dispassionate writing with neutral writing, which makes a biased dispassionate edit much more likely to get through.

Remember that these statistics are specifically from Amazon warehouses, and not from Amazon warehouse workers calling from home. We'd need statistics on calls from workplaces. A quick google scholar search finds suicide rates [1] in the workplace which are significantly lower than what you cite as general suicide rates. I couldn't find any data on 911 calls, so we can't really draw any statistical information from this data.

[1] https://www.sciencedirect.com/science/article/pii/S074937971...

That's dangerous advice. Having access to some (or a combination of) "less-secure" accounts could allow an attacker to get enough personal information to escalate privileges through reset fields, social engineering in customer support, or just plain weird interactions between accounts.

Besides, most people have enough "important" logins (social media, email, amazon, bank(s), computer, cloud accounts) and some have lots that there's no good reason not to use a password manager. Even with 6 passwords to remember (plus a 7th for all the non-sensitive accounts), it's hard to make them unique enough, and if you end up with a system it's pretty easy to infer the rest of the passwords.

Imagine this scenario: you are an average person. You have 90 accounts each requiring a password [1]. 5 of them you deem sensitive enough to have their own password and 85 of them share a password. One of those 85 is compromised. Now you'll spend all day stressing out whether one of those 85 accounts, in hindsight, is actually something you care about at least to some extent. Desperately trying to remember whether there were any other accounts that you should've secured better. (Anecdotally, this has happened to me before a password manager: I had different logins for important stuff and the same for non-important stuff; it's also happened to most of my friends at some point.)

Or you can use a password manager. Once you do have a password manager, you can go ahead and have unique random logins for everything, there's no extra effort needed. 2FA is another important security measure.

In regards to rotation, I agree, and NIST doesn't even recommend forced rotation anymore[2].

[1] https://blog.dashlane.com/infographic-online-overload-its-wo...

[2] https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver

Also, for the love of all the gods, don't prohibit pasting in the password field!!

Google changed the operators; now it's double quotes instead of plus (it was changed for google+ so that the plus searches g+ profiles and pages). You now have to search:

"noir" "film" -"pinot noir"

I wonder whether they'll revert back now that google+ is dead.

That is a very shortsighted blame-the-victim mentality. You're conflating the power of the individual voter with that of the entire voting bloc. Besides, even if new affordable housing was constructed (which is getting harder and harder in nyc as people are being pushed further and further out geographically), it's not easy to just up and move, even in nyc.

This looks like the generic "people" artwork you see in so many places.

> Laying everything on this thick just doesn't increase credibility for me. It makes me suspicious.

Counterpoint: if you've gone through enough hardship, your self-esteem can tank so much that you start thinking in black-and-white -- "I blew every single question" etc.

Every once in a while someone's gonna go through something really bad: "perfect storms of woe-is-me" do come by, and our selection bias of upvoting those specifically means that we're disproportionately more likely to see really horrifying stories.

> * All changes to the main source code repository MUST be reviewed by at least one other engineer.

> Same as above. Just build and RTFO.

Deploying without review is not only a development nightmare (if you keep deploying without review, you'll eventually break something or introduce security vulnerabilities, unstable code etc.), but it can also get you in massive trouble with your compliance audits.

Peer review is very important in production code.

The great thing about hypotheticals is you can just say "wins the lottery, leaves the job, and never comes back" and it's implied in the scenario that you shouldn't read too much into it.

This sounds like a terrible idea. Similarly to implementing your own encryption, having a custom consensus algorithm can create additional vulnerabilities -- a custom consensus algorithm isn't as tested and vetted as an existing, widely-used one.

In security, you generally don't want "unique and innovative", you want tested, verified, robust algorithms that have been gone over with a fine-toothed comb.

That gives rise to a very interesting concept: ML-based bias assessments. If you take some real-life hiring data (or other applications such as sentencing or generally human behavior data) and train the AI on it, then run it through a bunch of tests to see whether there's bias, that can reveal trends in the underlying training data.

I can't imagine this not already being a thing, but I haven't really heard of people using this method.

The Amazon app has an absolutely horrendous FID of around 10 seconds or so. They could use a little bit of optimization.

Downwards arrow towards a disk: https://imgur.com/a/dMrixoi