Gasparila

Thought exercise because I legitimately struggle with this. Is this fundamentally different than Costco using sales data to choose which Kirkland products to launch/sell? If so, how? If not, then why do we not pursue Costco with the same gusto as Amazon? To me this behavior by Amazon seems worse, but I can't figure out why.

Matz (Ruby lead maintainer/original author) has said that Ruby 2.7 (coming out this Christmas) has JIT improments that make JIT neutral for Rails. The goal is to have it be net positive by Ruby 3.0 (Christmas 2020)

The law has you pay taxes of 1% of gross revenue * percentage of global employees working in an SF office. Even if the headquarters moved (and I'd guess it is already a Delaware registered company legally), they'd still have to pay.

There's a .size that works for pretty much everything: if the relation isn't loaded then it will do select count(*), but for arrays and loaded associations it does length of an array

One big reason to me: cookie security

Currently all buckets share a domain and therefore share cookies. I've seen attacks (search for cookie bomb + fallback manifest) that leverage shared cookies to allow an attacker to exfiltrate data from other buckets

I had one experience reporting a security vulnerability to United's bug bounty program and never want to do it again. I reported an issue to that I could reset anybody's MileagePlus number by only guessing a multiple choice security question ("what is your favorite sport", etc), bypassing any email confirmation or anything like that. After 3 months of back and forth with their security team, they released an Android update that patched the issue. I was then told "It turns out this fix was pushed by the QA team and was actually unrelated to your Bug Bounty submission" and that my submission was ineligible. At least they have a program I guess?

Back of the envelope math for birthday paradox is root n. So in this case with ~50% probability you'll get a collision after 2^32 IDs (or after 4 seconds of 1 billion writes a second)

I had one experience reporting a security vulnerability to a bug bounty program and never want to do it again. I reported an issue to United Airlines that I could reset anybody's MileagePlus number by only guessing their Security Questions ("what is your favorite sport", etc), bypassing any email confirmation or anything like that. After 3 months of back and forth with their security team, they released an Android update that patched the issue. I was then told "It turns out this fix was pushed by the QA team and was actually unrelated to your Bug Bounty submission" and that my submission was ineligible.

Your mileage may vary, but the headache for me is not worth the payout

Wow that's a lot of dilution for a late stage round. I feel bad for the employees that suddenly have their equity cut by 60%. If I'm doing my math right, ($865 MM pre-money) then it means even with the higher valuation preferred price goes down

This article (and others I have read disliking HPKP) generally take an all or nothing approach. That is to say, they see HPKP as either "pin the key of my certificate" or "don't use HPKP at all"

In reality, you can have a valid HPKP setup as long as any keys in your certificate chain match the key in the HPKP header. This means that you can pin the intermediate certificate (or even the root CA if you want) key. By doing so, you are no longer vulnerable to losing your SSL keys, but now other CAs cannot issue certificates for your site

They still exist and (as far as I know) there are no plans to do anything about them. We (thankfully) were alerted to this issue by HackerOne before it was an issue, but this remains an absurdly easy attack vector...