vijayp

Congrats to the team for tracking this down, it was a great write-up!

Twitter has some great networking/kernel engineers. When I was working at Twitter a few years back we isolated and fixed another insidious kernel bug; a large group was critical to making it happen (including Cong, who worked on this bug): https://tech.vijayp.ca/linux-kernel-bug-delivers-corrupt-tcp...

I'm always shocked at how the kernel seems to mostly work, with such meagre test coverage. I guess testing in production does kind of work at scale?

The design is terrible. I never use the touchpad for anything regular keys wouldn't do better. The keyboard on my 2017 MBP13 failed three times in the year I've owned it. The first time, the Apple Store person "cleaned" the keyboard, fixed things for a while. A couple of weeks later, the problem came back. I insisted on a better solution, and they replaced the keyboard.

Five months later, a different key failed, and the Apple Store people sent it to Memphis. This time, it came back with one of the "new and improved" keyboards. They also replaced the screen because of 'delamination' which I hadn't noticed. The total amount they spent to repair this computer is approaching the cost of the machine at this point! So far, the new keyboard hasn't failed yet but I'm not holding my breath…

You can sort HN by date, and few URLs are updated every day. So you can push a new bloom filter every day and a different list of updates every 5m. Then just check your URL against both of them.

How do these execs not have 10b5-1 plans set up?! Many companies require them for all senior managers.

http://www.investopedia.com/terms/r/rule-10b5-1.asp

Mirabel airport [https://en.wikipedia.org/wiki/Montr%C3%A9al%E2%80%93Mirabel_...] probably was a contender. The passenger terminals were eventually torn down recently, but cargo flights continue to use it.

EDIT: "By surface area, it was the largest airport in the world that had ever been envisioned, with a planned area of 39,660 hectares (396.6 km2; 98,000 acres)"

Agreed -- I feel far safer biking around in Manhattan then sf. There are way more separated lanes in NY, traffic moves much more slowly, there are no tram tracks, and the lack of right on red makes it less likely I'm going to get run over by an inattentive driver.

http://www.cnrtl.fr/etymologie/shampooing

If he actually flew out of YVR, he was probably in a us preclearance area -- us customs are located in some Canadian airports so flights can go directly into us domestic terminals.

Since those screenings are on Canadian territory, us agents do not have police powers or the right to detain people. They can deny entry but people can leave at any time unless they have violated Canadian law. (https://en.m.wikipedia.org/wiki/United_States_border_preclea...)

If this was the case, he could have simply left the airport at any time.

Yeah, maybe human review is not the most scalable solution; if data analysis shows that certain patterns of behaviour are highly predictive of an account takeover, there are almost certainly product solutions for them.

I guess the real question is what the data actually show

Yeah, a couple of years back, I went to a t-mobile store (I think it was on Broadway and Park Pl) to get a new SIM card; I'd lost it in Europe when I was on holiday. They gave me a new SIM card and let me pay cash without even checking my ID…

That's a good point. Though I think it would be challenging to have a phone number that no one knows which you also carry around with you.

It's possible if you use something like Google Voice for most of your regular calls, but you still need to make sure that the telco can't tie your name to your number…

Yeah, I'm also scared of LastPass being a SPOF. While LastPass does do a good job, no one is perfect, and the cost of having my account compromised is really high

I'm now leaning towards encrypting backup codes with a passphrase and putting the encrypted blobs in LastPass. I haven't actually done this but as long as I don't forget the second passphrase, that might work…

Yeah, I could believe that it would create too many false positives and in retrospect things do often seem easy.

Google and other service providers do have data to evaluate the benefit and cost of making decisions based on patterns, and they probably do.

oh man, I remember browsing FTP servers over email back in the early 1990s, when I had email access but not FTP access. It was incredibly slow and typos were to be avoided at all costs! https://en.wikipedia.org/wiki/FTPmail

Seems to me like shipping paper bank statements scales quite well -- linearly in fact!

Well, YHOO's total market cap is now about $37.36B, so it's not a complete travesty. (MSFT would have gotten the Alibaba investment with the $45B offer)

The blog seems to be down. Does anyone have a link to a cached copy?

http://blog.cryptographyengineering.com/2012/01/attack-of-we...

This article talks about tls and corruption, including dtls. I found it educational!

Oops I probably should have been clearer.

Hardware verification IS performed. For various reasons, the nic never itself drips packets that are corrupt, packets are instead marked by HW as either verified or unverified. When a packet is marked as unverified, the kernel should verify and potentially reject the packet before delivery to the application. The bug in the veth driver causes the kernel to treat packets marked unverified as "verified"

Just skimmed it; very interesting. I hadn't heard of this bug before, but will read it in detail soon. Thanks!

I think it's in the 3.13 queue already: http://kernel.ubuntu.com/git/ubuntu/linux.git/commit/?h=linu...

yes, the code is as follows in the broken veth:

if (skb->ip_summed == CHECKSUM_NONE && rcv->features & NETIF_F_RXCSUM)

checksum offloading is encapsulated in the rcv-features bitmap, so disabling it will hide this bug.

You can do something like this within your container to disable it (from memory, might be slightly off): $ ethtool --offload VETH_DEVICE_NAME rx off tx off $ ethtool -K VETH_DEVICE_NAME gso off

Yeah, TCP's checksum is indeed weak and TLS is indeed a good answer.

However, I think delusional is a bit of a strong word to use here. "Performance of Checksums and CRCs over Real Data" has a bunch of interesting data about the number oand types of common errors detected by simple checkums and CRC: http://ccr.sigcomm.org/archive/1995/conf/partridge.pdf

The code is open sourced as GPL3, you should be able to run your own server pretty easily. Please let us know if you have issues.

https://github.com/mitro-co/mitro

A password manager really needs to be a high-availability service -- it should work even (especially) when AWS is down. Since our service (intentionally) does not cache secret data on the client, running a proxy is not substantially easier than running our service. Plus we'd have to write this proxy :)

Yeah, our largest costs are: - a primary server running on AWS - a read-only replica running on google compute engine. Other smaller costs include networking, DNS, and various tax/administrative/regulatory fees

You can actually change the server in a hidden preferences page. Go to /html/preferences.html in the extension.

Of course the irony is that much of Apple's dominance has been cemented by their tyrannically analytical optimization of all aspects of their supply chain!

We open sourced (GPL3) Mitro (https://www.mitro.co). You can find the code here: https://github.com/mitro-co/mitro.

We have a similar model for reprompting, but you can alter the code as you see fit. Someone was working on a command line client too, but I'm not sure what became of it.

The design doc describes the architecture: https://github.com/mitro-co/mitro/blob/master/PasswordManage...

We unfortunately don't have a great description of the protocol. The closest you can get is to look at the RPC proto spec: https://github.com/mitro-co/mitro/blob/master/mitro-core/jav...