davidfiala

Attestation of any type: A double edged sword, where you are guaranteed to lose freedom. Attestation entrenches, empowers, and enriches other entities that aren't you.

Ironic how this post got upvoted in parallel to polar opposite in the #1 slot: "John Deere owners will get the right to repair equipment under FTC settlement" https://news.ycombinator.com/item?id=48838876

Engineers may debate about what-about-isms of vulnerabilities and counterexamples of TPM failures, but that misses the point: We should be debating about where society will be when devices you paid for serve other masters.

Probably we should just write/vibe/demand better software. Otherwise we're going to end up with a law demanding TPMs that watch more than just your firmware...

Missing Option 3) hardware and software continue to evolve and AI becomes cost efficient at the same price and eventually even lower

Very nice. Thanks for making it clean and simple to use. I'm curious, only if you're willing to share, how you check so many domains availability automatically? Is there any potential rate limit problems behind the scenes?

One challenge I've always seen with similar tools is that the AI always wants to generate MultiWordsTogether domains, even when selecting that you want only creative short ones like "uber". Maybe this is something that a prompt change could help solve. But I'm pretty certain that LLMs today are just bad at type of single word creativity in their default state.

Bug report: when I click on the hamburger menu and switch to another item on your site, I get into an infinite loop of being prompted to sign into Google.

SPAs are not about view transitions. TFA implies that fancy transition is important between pages (wrong!) and blames a "CMO" or "brand manager" rather than challenging their own preconceptions and exploring the value an SPA does add:

- excellent frameworks for client side logic (interactivity) - separation of concerns (presentation logic vs. backend) - improved DevEx => inc. speed of development => happiness for all

The sad thing is that an article like this will get plenty of eyeballs due to comments like my own adding to the algo, but it should have never made it above the fold.

I'd love to see more examples in a portfolio or catalogue page. I think it would help me more clearly see what is possible than just the links above. Or at the very least, having them all together on one page without having to open the design chat URL for each to see the examples would be nice.

I'm glad to see you working on this. It's an incredibly difficult and important space!

Assuming you have a desktop or VM that is always on, then using vs code or cursor with the remote SSH and dev containers extensions installed is great. The extensions operate on top of each other transparently.

A lost or interrupted internet connection is not a big deal. Both IDEs come back right where you left off by just hitting a reload button when you come back.

They also have some black magic (which I recommend against trusting) that will bring your terminal back to a similar state to where it was when you left off. I do not recommend the built-in terminal in either IDE though, but it is there in a pinch. For long-running tasks, if you like SSH, then tmux solves your problem.

I mean, the site is just incredibly beautiful. Good job. I want to go on vacation wherever the made-up end-frame is with the lake on the bottom.

I had to show it to a friend who said they must have hired a frontend engineer yelling, "I've wanted to do this my entire career, and you cannot stop me."

It is important for readers to be aware that the specs compared are not useful today.

Only the latest greated 50x NVIDIA gpus will do DP 2.1 (everything else is DP 1.4). And likewise, even your best monitors are unlikely to support DP 2.1 today.

HDMI 2.x is supported by a wider(est) array of available GPUs and monitors, and thus not only wins out, but is literally the only way to unlock the resolutions and refresh rates in today's situations.

Absolutely excellent!

Very nice!

Regarding the localness, are you optimizing or targeting users that prefer only local inference? The part about API keys at the end makes me wonder if there's any practical difference outside of lower local resource requirements and access to private models on the clound.

Do you recommend or force that people use any specific languages or frameworks that dyad is optimized to render or iterate on locally?

This is great news.

I love thinking about exploit scenarios that remain.

Very niche, but attackers on a LAN or in the path to cloudflare's edge servers probably have a small window to still exploit this.

In my case, I have about 25 millis before the RST packet arrives from CF:

ip=$(getent ahosts api.cloudflare.com | awk '$1 ~ /^[0-9.]+$/ { print $1; exit }') && time bash -c "exec 3<>/dev/tcp/$ip/80"

(Long command because I wanted to separate the DNS resolution time from the time it takes to send a SYN and then get the RST)

An attacker observing network traffic for a SYN could spoof a single ACK and then quickly capture the Request HTTP headers including the auth payload. Often that fits in the first packet.

Another niche idea/risk: TCP Fast Open might also provide an avenue for the HTTP data to get sent before the CF's RST packet is sent, too. I imagine TFO would apply because any connection (even an https one) would have established TFO with api.cloudflare.com, and then one single accidental hit to http instead of https may include payload regardless of the RST? Hmm.

I replied to cold outreach from designers. To vet, I took calls to see their actual portfolio (actual prior work in Figma, for instance), asked about their processes, areas of strength/weakness, types of work (illustrations only? css help? slides? products or only landing pages? which types of target audiences they've had?), etc.

Might be useful to comment on what your budget is. Having an external design team that knows you and can work fast when there's a crunch is very useful as it removes the latency inherent with one-off task based platforms. Plus, you get a consistent level of quality.

If you don't have enough work to keep designers busy on a day to day basis, then it may not be worth it to get a long contract. On the other hand, things often take longer than you expect to iterate and refine.

Might be worth explicitly stating popular/known datapoints you were unable to include or evaluate yet.

For example, the fastest inference provider by multiples as of this writing, Cerebras, is missing. It's popular, so I'm surprised it was missed: https://news.ycombinator.com/item?id=42178761 and makes me wonder if other evaluations are missing.

See also a similar (commercial AFAIK) project: https://artificialanalysis.ai/

Imagine increasing the quality and FPS of those AI-generated minecraft clones and experiencing even more high-quality, realtime AI-generated gameplay

(yeah, I know they are doing textual tokens. but just sayin..)

edit: context is https://oasisaiminecraft.com/

  > Your manager doesn’t promote you?
  > No, managers at Google can’t promote their direct reports. 
  They don’t even get a vote.
  > Instead, promotion decisions come from small committees of upper-level software engineers and managers who have never heard of you until the day they decide on your promotion.

Exercise extreme caution.

Having your security strategy rely on quirky behaviors of an implementation detail which might change is incredibly dangerous.

- 1,800tps on llama 3.1 8B

- 450tps on llama 3.1 70B

free chat interface is at: https://inference.cerebras.ai (requires login)

Didn't see it :) you nailed it!

Ideally TFA would have also explained why some requests do go through without a preflight. What's called a 'simple' request is the explanation behind TFA's whole premise.

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simpl...

These days, pretty much everything requires a non-simple request in order to invoke an action, regardless of whether the client can read the result.

Agree'd in spirit though that CORS is annoying to use, and it's always worth consulting the manual.

It depends on including things like headers and other non-approved changes to the request. Content-Type is one of them, but even it has some whitelisted options.

Read about 'simple' requests to see what you can and cannot do before a preflight is required: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simpl...

Couldn't agree more on this one:

especially when the product itself claims security as a core principle

My thought is that both volunteers and corporations contribute. In different ways, too.

One example is how a YC company made an open source version of Zanzibar. Zanzibar was an open paper to the world from Google that describes a flexible, resilient, fast access control system. It powers 99% of ACLs at Google. It's /damn/ good for the whole world and /damn good/ for developers' sanity and company security.

Corporate endeavors may fail, but they are often intense in direction and can raise the bar in terms of UX and security. Even if it's just a whitepaper, it still cannot be discounted. Besides, the larger places focusing on security aren't getting a big blast radius hack all that often, yeah?

I'm curious though, you've intrigued me. What kind of evidence or just lightweight ideas are you thinking of wrt volunteer led being more secure? No need to dig up sources if it's hard to find, but the general direction of what makes you feel that would be useful.

tldr; purpose built tools

SSH is kind of a swiss army knife. But 1000x sharper ;) The delta I'm speaking of would be to have bespoke tooling for different needs. And the tooling for each purpose could have appropriate, structured logging and access controls.

With SSH you can do almost anything. But you can imagine a better tool might exist for specific high-value activities.

Case study:

Today: engineering team monitors production errors that might contain sensitive user data with SSH access and running `tail -f /var/log/apache...`.

Better: Think of how your favorite cloud provider has a dedicated log viewing tool with filtering, paging, access control, and even logs of what you looked at all built in. No SSH. Better UX. And even better security, since you know who looked at what.

---

There are times when terminal access is needed though. SSH kinda fits that use case, but lacks a lot. Including: true audit logging, permissioned access to servers, maybe even restricting some users to a rigid set of pre-ordained commands they are allowed to run. In that cases, a better built tool can allow you to still run commands, but have a great audit log, not require direct network access (mediated access) to servers or internal networks directly, flexible ACLs, and so on.

It's off topic, but in my consulting and networking, security/firewall appliances are an easy first line approach I see companies buy in to. The security sales pitch sounds good and makes you feel good. Cannot name names.

tldr; your statement overlooks the reality of businesses with high ethical and financial obligations, like Google, Amazon, and Azure.

- These companies underpin much of the internet's infrastructure.

- Their security practices are far more advanced than typical businesses, with SSH being a heavily restricted last resort. That's not to imply that everyone else shouldn't strive to do meet that (modern) bar too.

- Dedicated teams focus on minimizing access through time-based, role-based, and purpose-based controls.

- They actively develop new security methodologies, often closed-source, but with public evidence of their impact (e.g., https://cloud.google.com/docs/security/production-services-p... ).

- They rarely experience conventional hacks due to reduced blast radius from attacks and insider threats.

- Leading security experts in both major tech companies and niche organizations are driving new strategies and ways to think about security... their focus includes access reduction, resilience, and reliability, regardless of whether the solutions are closed or commercial for them. The ideas spread. (looking at you, Snapchat, for some odd reason)

- This is key: This evolution may not be obvious unless you actively engage with those at the forefront. I think it's what makes people think like the comment above. We cannot see everything.

- It's crucial to recognize that security is a dynamic field... with both open-source and closed-source solutions contributing.

So, the notion that volunteer-led projects are inherently more secure overlooks the significant investments in security made by major corporations that host the internet, and their relative success in doing so. Their advacements are coming to the rest of the world (eventually).

There's a ton of great truth here. It's hard to bite the bullet and believe that insiders already exist (everywhere), but I can share that from my experience working in big tech:

- There 100% will be bad actors. Many of them.

- But not always nationstate. Instead, they do it for (dumb) personal reasons, too. Also, don't forget lulzsec as a great example of just doing it for fun. So we cannot presume to know anything about the 'why'. The bad guys I caught did it for the most asinine reasons...

But the good news is that we have options:

- Strategic: Develop processes and systems that account for the perpetual existence of unknown bad actors and allow for successful business operation even when humans are compromised.

- Reactive: Structural logging that makes sense in the context of the action. Alerts and detection systems too.

- Reduction: Reduce access to only what is needed, when it is needed.

- Proactive (not always necessary): Multi party approvals (a la code review and production flag changes or ACL changes, too)

- Social: Build a culture of security practices and awareness of bad actors. Don't make people feel guilty or accusatory, just empower them to make good design and process decisions. It's a team sport.

Bonus: By guarding against evil actors, you've also got some freebie good coverage for when an innocent employee gets compromised too!

---

Companies like Google and Amazon do the techniques above. And they don't generally rely on antiquated technology that cannot and will not change to meet the modern standards.

I know because I was the person that built and Google's first time-based access system and rational-based access systems. And multi party approval systems for access. (Fun fact: The organizational challenge is harder than the technical).

And, those strategies work. And they increase SRE resilience too!

---

But even with the best UX, the best security tooling, the best everything, etc there's no guarantees that it matters if we just reject anything except the old system we're used to.

It's like a motorcycle helmet: Only works if you use it.

We don't know. We won't know the negative case, but we may someday in some circumstance find out the positive (bugged) case.

But we do know some sane things:

- The stakes couldn't be higher.

- Good: Don't allow inbound SSH connections, even through a fancy $100k firewall.

- Best: Don't let people login with SSH (treat SSH like we treat the serial port: a debugging option of last resort)

@dns_snek, it's right there in my real name username, comment history, and profile. :)

My entire youth and professional life I've seen nothing but footguns with actual practical use of SSH. The HN community loves to hate, but the reality is that almost no one uses SSH safely. It's near impossible. Especially when it comes to configuration, keys, passwords, and network factors.

I observed the common SSH failure patterns, and I made the most obvious footguns less than lethal. Looking a step further, I made remote terminal access a pleasure to use safely even for absolute novices.

So to your point about being in YC: In doing so, I thought it would be beneficial to join a community that supports one another (YC) so that an option (Teclada) can scale to make a real impact in the world WRT the warts and footguns of SSH.

Even with the best intentions, can a volunteer-driven project like OpenSSH truly guarantee the same level of security as a commercial solution with dedicated resources and a financial stake in preventing backdoors?

Great presentation.

As the founder of teclada.com, I'll also share that one of the biggest risks is not even technical but human:

  - not managing your SSH keys properly
  - not even knowing where they are
  - reuse, copying, etc
  - forgotten placement of keys in authorized_keys

  - "no way I'm going to even consider changing any of it"
  - "our audit logs are .bash_history"

I've wished for a complete version like this for so long. Great work. Thank you!