thanksforfish

I found "Don't Make Me Think" by Steve Krug to be a helpful guide. As an engineer who was shy to approach product design, I felt the language really helped demystify things.

One way to make DNS surveillance more difficult is to use a public open DNS server, such as Google's 8.8.8.8

I assumed Google ran 8.8.8.8 to collect data for targeted advertising, as one of the major players in surveillance capitalism. Am I mistaken?

Snowflake IDs may compress well.

https://en.m.wikipedia.org/wiki/Snowflake_ID

Agreed, very enjoyable.

https://what-if.xkcd.com/

Right.

Content creator: Can you distribute my content? Only in $list-of-countries though.

Distributor: Sure.

If the distributor permits VPNs, how are they sure they are authorized to distribute?

Legal and moral definition of piracy vary.

https://en.m.wikipedia.org/wiki/Online_piracy

Unfortunately, if you don't have permission to download then you may be committing piracy. In this case, entire countries apparently don't have permission.

If the system is guessing location based on IP address, then granting permission based on that guess, then I expect their permission grant should be valid. How would a user know that they have bugs in their permission system?

If you connect directly first, are told "no", then bypass the system with a VPN: You probably understand that you aren't supposed to have access.

What will happen if you commit this type of piracy? I don't think there's a loss of revenue, or damages so pursuing pirates likely isn't worth it.

Obligatory, I am not a lawyer.

One of the unexpected benefits for me has been that I can lock any OAuth enabled app to a container for the OAuth provider I use. To login, I check which container I'm in and click the associated button.

Before this I'd always forget which OAuth provider I previously used. Did I Login with Google to DigitalOcean or did I use GitHub? Worse, I'd often click the wrong button and get logged into a new/empty account. I never came up with a good rule for which OAuth provider I should use, so it's a guessing game.

Locking the app to the container means I don't really need to think.

https://cve.mitre.org/cve/

Same MacBook, same SSD upgrade. I haven't replaced the battery, I tend to stay near an outlet anyway. Debian and Ubuntu work great on it, so I moved off OSX.

Surely there are people getting banned from Google who are not HN users. Social media outcry is not a good solution as its not accessible to everyone.

Agreed about wanting to see more transparency.

To be fair, if the rest of your pipeline runs in the megabytes per second, then memory allocation might as well be free from a speed point of view.

This is important, but I think sometime people struggle with this sort of thinking. I struggled to explain a similar concept to a junior engineer recently. He was very keen to try to optimize part of a process that wasn't the bottleneck. I tried a couple approaches, like benchmarking various parts under different conditions, modeling it to calculate how speeding up different components would take.

I wasn't convincing, unfortunately, so he implemented some changes that sussessfully sped up one part but didn't improve end to end performance. I think sometimes you need to see it with your own eyes.

Presumably, if the customer doesn't have the right to repair then the manufacturer would be able to make parts that are exceptionally difficult to repair without specialized knowledge and tools. Or worse, enforce cryptographic locks on any software/firmware to prevent unauthorized changes.

I think right to repair is about ensuring that the customer can make reasonable repairs to the product, and the manufacturer not infringing on their rights when designing the product.

How are folks using light weight cloud resources approaching password hashing? The `10s of gigabytes of RAM` feels like an expensive requirement. Even lower memory, high iteration count sha256 seems expensive for something like AWS Lambda where you're paying by the millisecond.

From the UX perspective there's also the issue that adding a second of latency during login or registration could increase user drop off.

How many sites really incur the higher costs and higher latency?

Relevant Senate links appear to be:

• https://www.senate.gov/legislative/LIS/roll_call_lists/roll_...

• https://www.finance.senate.gov/imo/media/doc/Wyden%20Lummis%...

Turning off the hashing toggle, I ended up trying to draw some shapes.

    zzzzmmmmaaaa2222

Agreement from me, although I'd avoid double booking. Double booking means that other people are expecting you to attend, they may wait to see if more people join, or need to reschedule if the right audience isn't able to make it. I think it's best to pro-actively reject meetings versus only showing up for one.

I'll add my (32/M/USA) perspective as someone who subscribed to duolingo plus last month. I'm learning Arabic ahead of a _potential_ move with my spouse to an Arabic speaking country.

First Duolingo is fun to use. I didn't enjoy classroom based learning in high school. Duo gamifies the process really well, it's on my schedule, and I have a concrete reason to want to learn. Duo has been reducing my time on social media as well, always a bonus when picking up a good habit.

The $7/month premium subscription was worth it. I'm investing 30 minutes a day in the app, and ad-free means I can get through more lessons. I have unlimited lives so my learning isn't interrupted if I struggle on a hard lesson.

I'm not expecting to become fluent on Duo alone. But I think I'll get a great handle on some basics. My wife is already fluent, so that's helped me speak and figure out some things I struggled with.

I also tried the Rosetta Stone app. I didn't think that one was fun, it throws you into hard content quickly, so I haven't been using it. If our move happens, I'll enroll in a more traditional environment, and I may take a second look at the Rosetta Stone app. For now I'm happy that I have something that's making me increasingly comfortable with the idea of speaking Arabic.

Great answer, thanks for the detail!

Any thoughts on how customers should think about securing their skills? ChatOps exposes skills that may provide deep access to deploy code or modify system configuration. Slack doesn't have the same security as an SSH session (password protected private key). I'm seeing concerns around phone theft, evil maid, spouses, or former employees who haven't had Slack access pulled.

From my end, I think these are solvable but may require thinking about the problem differently. How are you thinking about security?

I think it's best to migrate to a preferred formatting slowly, versus touching everything at once. I've had open pull requests that I've started over due to aggressive reformatting like that. Between that and breaking tools like 'git blame', it can be painful.

I recently changed my opinion on todo list type projects. I previously thought it was a crowded place and a solved problem, not worth building yet another. But a todo list is such a powerful tool and has so many different use cases that each new variation can focus on a different niche and brings new value.

Great work!

Ref: https://en.m.wikipedia.org/wiki/Billion

I saw a thread recently that suggested reviewers should be running the code, not just reading it. Does anyone here run code as well? If so, I'd be interested in hearing about the experience.

I've almost always just read the code and "ran it in my head".

I wonder if that would cause legitimate copyright holders who don't have $1000 to tie up to be blocked. YT blocking legitimate claims could cause them to lose legal protections, which opens them up to liability directly.

I think a challenge is that the law provides much needed protections to YT if they protect copyright holders. Distinguishing between real and fraudulent claimants would need to be done very carefully; could accidentally denying a legitimate claim cause them to lose liability protections?

If so, they'd need lawyers in the loop for any decision about denying a fraudulent copyright claim. The cost of that is likely enough to make them prefer the current setup.

Or atleast as a security measure. Denial of service is a security concern... embarrassing.

Signal sold out? How so?

Unfortunately "install a piece of software" also includes allowing javascript to run in your browser. So the risk may be closer to "clicking a link".

https://www.zdnet.com/article/google-this-spectre-proof-of-c...

Additionally, the passwords and keys on your local dev box are very valuable for further attacks, like supply chain attacks.

See: https://news.ycombinator.com/user?id=pc

Even the length of a second is unstable in some implementations: https://developers.google.com/time/smear