LethargicStud

This works around a real problem I'm surprised nobody has solved - the ability to register a bunch of keys at the same time.

The webauthn spec has public/private keys incorporated: https://www.w3.org/TR/webauthn-2/#sctn-sample-registration

There should be no risk to storing all your public keys in e.g. 1password. When signing up for e.g. facebook.com, you should be able to hit a button and have all your keys registered at the same time. You can send $site all your public keys, and sign auth reqs as you log in. Of course, the UX would be handled by webauthn, so you'd really just be tapping your yubikey or scanning your fingerprint on login.

Ideally, password managers would offer key servers that websites could hit in real-time to pull your public keys. That's probably a stretch - maybe websites could sync your 2fa pub keys in the background.

With such a model:

1. Having multiple yubikeys

2. Having multiple team members with access (same as 1, effectively)

3. Revocation of individual 2fa devices

4. Adding 2fa devices after account creation

Would be pretty trivial.

I assume there's something basic in the webauthn protocol that I'm overlooking that prevents such a model. What is it, and why can't we have these properties?

I for one don't want all my accounts to hinge on access to a single physical device, and I certainly don't want to register 10 yubikeys with every service (some I may not even have physical access to on a day-by-day basis).

It is open source - https://github.com/jchorl/sendfiles

GCP supports remotely loading public ssh keys onto a box. They do this using the metadata endpoint - this is (in theory) a trusted API endpoint available to instances @ 169.254.169.254. IAM actually uses this - when you call other services, client libs reach out to the metadata endpoint and get IAM creds to send with each request.

Anyway, they have a local process that polls the metadata endpoint and adds authorized keys on the host. So you can e.g. upload your public key in the web UI, their metadata endpoint will serve it up on your instance, the guest agent will poll the metadata endpoint and add your key to the authorized_keys file.

These folks spoofed a response from the metadata endpoint. They used https://github.com/kpcyrd/rshijack to inject their own hand-crafted public key, which the guest agent happily added to authorized_keys (and created the wouter user).

They then ssh'd using their key:

ssh -i id_rsa -o StrictHostKeyChecking=no wouter@localhost

Once we accomplished that, we had full access to the host VM (Being able to execute commands as root through sudo).

Looks like they had passwordless sudo as well.

My main FUD with alpaca.markets is the ability to transfer assets in/out. It doesn't look like they offer ACATS transfers (although there's not much info on this!).

Using them for anything beyond entertainment budget is very scary - you may incur substantial tax liability if e.g. they ever go out of business or you choose to use a different brokerage.

Any insight here? Am I missing something? Is there any way to transfer holdings out without incurring the cap gains?

Hey!

I built this because I had 10+ bank accounts, and they were annoying to monitor. I'd log in every month and have to chase down why they didn't look as I expected them too.

I've set up Lambda functions to e.g. post bills to Splitwise, email me when my balances go above/below thresholds, and pipe all transactions into Google sheets. I've been running my own personal finances off it for a while and it's greatly improved my quality of banking life.

Would love feedback :)

Coming soon! I appreciate the feedback.

It uses plaid under the hood, so I get read-only access to bank data. You can validate by inspecting network reqs - it just grabs a public token from plaid and sends it to my backend - I never see the bank creds. Whether you trust plaid is up to you.

I'm hacking on https://bankhooks.com

The premise is simple - define arbitrary conditions on transactions or balances, and get webhooks or emails when those conditions fire on any of your bank accounts.

I have >10 bank accounts and was having trouble monitoring them. I use this to alert me of any activity, on any of my accounts, that is unexpected. I no longer need to log into banks. I also use it to alert me if my balance gets too low or too high in any account.

I've also deployed Lambda functions to e.g. post my utilities bill to Splitwise to automatically split with my roommates, or pipe all transactions into a Google sheet so I can analyze my spending over time.

It started out as a simple hobby project but has grown into an immensely useful tool in my day-to-day life.

Mount the docker socket. There's some quirks with storage volume paths. Also, security implications. Was not super hard to get working though.

I'd love to go straight to containerd or even basic linux containers but I'm not willing to run kubernetes on my personal machine and haven't found any ergonomic enough ways to run containers.

This is the exact class of problem that docker itself attempts to avoid. This is why I run docker-compose inside a docker container, so I can control exactly what it has access to and isolate it. There's a guide to do so here[1]. It has the added benefit of not making users install docker-compose itself - the only project requirement remains docker.

1: https://cloud.google.com/community/tutorials/docker-compose-...

1) You can run your own pull-through cache[0]

2) You can use a different registry

3) Run something like kraken[1] so machines can share already-downloaded images with eachother

4) If you need an emergency response, you can docker save[2] an image on a box that has it cached and manually distribute it/load it into other boxes

0: https://docs.docker.com/registry/recipes/mirror/

1: https://github.com/uber/kraken

2: https://docs.docker.com/engine/reference/commandline/save/

Yes! That'll probably be our next feature! Thanks for checking it out

We've actually been working on something similar. Our goal is to make it as dead simple to send a letter as possible in USA. We'd love any feedback people have!

https://papermail.in

Feel free to drop us a note at support@papermail.in if you have thoughts :)

Can someone explain why a government couldn't block the IP of this service? Whether it's a VPN or just dns over https, it seems the servers wouldn't have infinite dynamic ips and could therefore be blocked.

Please don't do this. It gives the user the illusion that their connection is secure, but the connection between Cloudflare and the site is not secure. Arguably it's better to encrypt some of the route rather than none of it, but also giving people a false sense of security comes with its own drawbacks.

Thanks for all the great work on dev-tools. I recently started developing a chrome extension and found that not all of the great standard functionality was present. Here were some of the main pain points:

- debugger; statements do not work for me

- When right clicking the extension and clicking Inspect Popup, the first few network requests are not reported in the network tab (seems that it starts recording after the extension opens)

- It took a very long time for me to figure out that cookies were not being set due to this permission: (https://developer.chrome.com/extensions/declare_permissions)

- Hot-reloading extension code would be extremely nice

Even just extra documentation on dev-tools with extensions or tips/tricks for debugging extensions would be excellent - I haven't been able to find much in the way of docs. Keep doing the excellent work you're doing, just thought I'd give some suggestions :)

Today, the average taxpayer has one chance in 200 of getting audited.

Does this mean 1/200 people get audited, or of the people who meet the conditions to be audited, only 1/200 of them will be audited? The article doesn't differentiate between whether people today should be audited but are not due to the systems in place, or perhaps that simply less people today meet the criteria to be audited and the computers are still doing their job just fine.

Because privacy is good. There could be countries that could physically harm you for accessing certain sites. This is a good step to avoiding that.

The self driving accidents might be the easiest for humans to avoid, but if accident rates are lower for self-driving cars, it's still worth it. Let's look at overall numbers and severity, not how avoidable it would be for a human.

Theoretically the reputation cost would discourage for-profit organizations from releasing unsafe self-driving vehicles for testing on public roads.

This assumes that the reputation costs are comparable in weight to the acts that they commit. Based on the past year and what I hear about Uber's growth[0], I'd argue that their reputation and their valuation are quite uncorrelated, but it's hard to know the truth.

0: https://www.forbes.com/sites/miguelhelft/2017/08/23/despite-...

This is very anecdotal. I really wish we had data on market share, costs, revenues, etc. Obviously we won't have even most of the picture until both companies are public, but at this point it seems like all of these articles are just speculation. When I interned at Uber, media estimates were pretty inaccurate.

Some people will still pick wrong for a multitude of reasons. Hopefully, those people can pivot.

We are lucky as software engineers, but I was also making the point that if your line of work gets automated, hopefully you can pivot. This applies to everyone, and is similar to when you are no longer enjoying your field of work. Changing careers is not always an option, but let's not forget that it usually is when we talk about automating an entire industry and putting them out of work.

Generally, the idea of stifling innovation to "preserve jobs" is harmful to society. Upon choosing a career, you should consider the longevity of that career. Some people will still pick wrong for a multitude of reasons. Hopefully, those people can pivot. It is unreasonable to hold the entire population back to continue employing those in a specific field. If we consistently did that, we'd be in the stone age and our quality of life would be far poorer. This will help future generations drastically even if it hurts us a bit.

I'm unclear as to how this would work in practice. Chrome supports U2F out of the box, so getting a big weird pop-up asking to access your USB device, you'd at least be suspicious.

Upon registration, the server also collects a nonce, which is used for verification[0]. The attackers would need to get that nonce from the site. Hopefully, the site disables CORS so a phishing site cannot request a challenge.

Lastly, on Linux (I know, a minority), you need to make an entry in rules.d[1] to even allow Chromium to access USB devices.

I can see how this potentially maybe could catch someone, but I don't see it as much of a risk.

[0] https://blog.fastmail.com/2016/07/23/how-u2f-security-keys-w... [1]: https://developers.google.com/web/updates/2016/03/access-usb...

Do you mind sharing the math? Isn't impossible to know how much the equity is cut by because we don't know how much dilution there was (vs. liquidation)?

I'm actually in support of this. It's very important to separate content providers from entities that make things more discoverable. Google's job is to help me find what I'm looking for, not to decide what I can or cannot buy. I see this analogous to Cloudflare not supporting a site because they don't agree with the content.

Great article, I learned a lot. I've wondered for a while why some usernames appear green, it would be nice to include that too.

They weren't, they were losing a lot.

But that won't scale because the public won't have time to study every case that occurs. Maybe instead we could have specific people whose job it is to analyze cases and make judgements. And maybe each case could be assigned a few people to study it and help the judge decide...

I _really_ hope they let braintree handle that and don't touch PANs. If they do store PANs, presumably they'd be audited and hopefully would store them more securely. But hey, I guess you never know and less exposure is always better.

Sure, but Google or AWS looking at your specific certs and using them to decrypt your traffic or impersonate you is probably far less likely than someone MITMing Cloudflare's connection to your server or even worse finding a vulnerability in CF (see cloudbleed [1]). I really really dislike how Cloudflare has legitimized MITMing many sites while making it look 'secure'. It's basic security, never trust someone else with your keys.

1: https://en.m.wikipedia.org/wiki/Cloudbleed