Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Y Combinator Resources for Developers

yc.dev

Post reply on HN
Print view View original

91–100 of 129 posts

Re: Y Combinator Resources for Developers

#91

Post by CydeWeys »

styfle wrote: post #89
CydeWeys wrote: post #67

Earlier quoted context omitted.

In Chromium, the whole HSTS preload list is expired if it gets too out of date, as domains are both added to and removed from the list. So you're giving up real security by running an out-of-date browser. Not only are HSTS-preloaded TLDs not secured, but even, say, gmail.com or yourbank.com aren't. See: https://chromium.googlesource.com/chromium/src/+/lkgr/compon... I think it'd be better to use an out-of-date list i…

The source code says the data is only valid for 10 weeks. If Google releases a new version of Chrome every 6 weeks, then a user could never skip a single version of Chrome without becoming vulnerable. That doesn't seem like it's enough time. I would expect one year or at least 6 months.

I agree. Unfortunately I'm not on the Chrome team.

Re: Y Combinator Resources for Developers

#92

Post by CydeWeys »

nkozyra wrote: post #78
chiefalchemist wrote: post #18

Earlier quoted context omitted.

Status symbol? Those who know won't likely be impressed. Those who don't can't be impressed. That might be what the buyer is hoping for, but the reality is they're probably mistaken.

"Impressed" might not be the right word. Jealous, maybe. Would I like a .dev domain? Yep. Can I afford it? Nope. Therefore ... status symbol.

You can definitely afford one in a few days.

Re: Y Combinator Resources for Developers

#93

Post by peterwwillis »

CydeWeys wrote: post #67
dooglius wrote: post #62

Earlier quoted context omitted.

A somewhat out-of-date Chromium (69). I should upgrade, but I'm surprised the change is that recent.

In Chromium, the whole HSTS preload list is expired if it gets too out of date, as domains are both added to and removed from the list. So you're giving up real security by running an out-of-date browser. Not only are HSTS-preloaded TLDs not secured, but even, say, gmail.com or yourbank.com aren't. See: https://chromium.googlesource.com/chromium/src/+/lkgr/compon... I think it'd be better to use an out-of-date list i…

HSTS only works if (1) the endpoint properly supports it, (2) the browser supports it, (3) the list is up to date, (4) there is no attacker ever waiting for you to hit the page for the first time or when HSTS expires.

(2) is not really a concern any more, (3) occasionally becomes a concern, (1) is a concern for most of the web, and (4) is a concern for literally every use of HSTS.

The whole point of HSTS is to ward off man-in-the-middle. If all a man in the middle has to do is wait, and is eventually guaranteed a shot at exploiting you, they will. So all HSTS gives you is the small hedge that if an attacker is present, but not persistent, and not targeting you specifically, you're slightly more secure.

Basically, it only protects you if a random hacker is sitting in a coffee shop you don't normally go to, and only if your browser is up to date, and only if every site you want to visit uses HSTS, and only if you've visited them before. It's so incredibly specific that it's almost pointless.

A better solution would be either (A) an extention to the specification to actually support a "secure://" URI prefix, or (B) a proxy or browser mode that only allows valid HTTPS connections. These are user interface fixes, because the entire point of HSTS is to prevent users (and really bad apps, I guess) from accidentally using HTTP.

Re: Y Combinator Resources for Developers

#94

Post by CydeWeys »

gbear605 wrote: post #69
CydeWeys wrote: post #59

Earlier quoted context omitted.

Can you confirm that it's not rewriting the URL to https://yc.dev first before issuing a request to the network? It's possible that Safari has suffered some kind of regression. This definitely used to work at some point. I can confirm here in Chrome and Firefox that the URL is rewritten internally to https://yc.dev (which then redirects to https://ycombinator.dev ), so no unencrypted traffic is ever sent over the net…

Unfortunately I’m not in a situation where I can test that. It’s very possible that that’s the case, but it then leaves the question of why the non-https ycombinator.dev is what we eventually end up on.

Separate from HSTS, they should also be redirecting http to https. Hopefully they'll get around to that soon. The domain is still recent so they're probably not finished with configuration.

Re: Y Combinator Resources for Developers

#95

Post by dragonwriter »

PavlovsCat wrote: post #90
dragonwriter wrote: post #82

Earlier quoted context omitted.

> Sure, but overdoing it and confusing labels and abstractions with the things they represent can also keep a human from being more aware of the world and their deeds in it. Sure, abstractions are not the underlying reality, the map is not the territory, and the Tao that can be told is not the true Tao. That doesn't mean that it is necessary to “reject all labels” as a fundamental requirement for inclusiveness, or ev…

When someone says "reject labels", I basically hear "don't think primarily in terms of them". I didn't take it as "don't ever speak it", but more "don't put it front, middle and last, 24/7". I can imagine it can be annoying/exhausting, part of feeling welcome is the understanding that it's perfectly normal for one to be there, I think.

> When someone says "reject labels", I basically hear "don't think primarily in terms of them".

I've yet to see a reason to believe that complex thought or communication is practical among humans, other than through manipulation of labels for abstractions over the underlying subject matter, so that doesn't change my objection to the argument one bit. You can recognize the limitations of the models underlying labels and be careful in choosing models (and thereby, relevant labels) that you have reason to believe are useful for the specific purpose and recognize that you're still subject to imperfect results in the best case, but labels are, ultimately, universally essential.

And that certainly doesn't mean you can't reject the utility of particular labels and their underlying model, either in general or for particular uses, but that doesn't get you to “reject all labels” much less that you must do so as a prerequisite for inclusiveness.

Re: Y Combinator Resources for Developers

#97

Post by brlewis »

nnq wrote: post #87

Is "Beating the Averages" still relevant in 2019? I see it pretty high up on the site, and I thought the consensus is that nowadays most languages have enough lispy and functional features to give similar productivity. Is there any benefit from hyperflexible languages high enough to outweigh the benefits of readily available libraries?

It's hard to do reproducible experiments measuring productivity, but my personal opinion is it's still relevant. I say that as someone doing mostly JavaScript and TypeScript development day by day. I often miss the clean syntax and macro facilities of Scheme. I used to use Kawa Scheme a lot, which runs on the JVM, so readily available libraries were never a problem.

Libraries, documentation and community are reasons to use non-Lisp languages for certain projects, but if you don't have some kind of Lisp in your toolbox, you're still missing out in 2019, in my opinion.

Re: Y Combinator Resources for Developers

#98

Post by heartbreak »

judge2020 wrote: post #68
chiefalchemist wrote: post #19

I wonder how many of the YC companies use the other YC companies. And which are the most / least used. How much effort do you reckon is put in trying to "align" them and keep them aligned? As in there's a consistency in (e.g.) docs, APIs, etc.

I would bet Stripe is the most used.

Dropbox?

Re: Y Combinator Resources for Developers

#99

Post by dtrailin »

> Beating the Averages

> A classic article on using powerful programming languages as a secret weapon

I'm surprised this is included given that it's been more or less been proven to be false. Almost every valuable company in the past 2 decades was built on a blub language. Facebook even used PHP! Java and C++ are at the core of most Amazon and Google services. There basically haven't been any big companies build on a lisp-like language unless you consider Scala, but even the most companies adopted that later.

edit: blub

Re: Y Combinator Resources for Developers

#100

Post by dctoedt »

dtrailin wrote: post #99

> Beating the Averages > A classic article on using powerful programming languages as a secret weapon I'm surprised this is included given that it's been more or less been proven to be false. Almost every valuable company in the past 2 decades was built on a blub language. Facebook even used PHP! Java and C++ are at the core of most Amazon and Google services. There basically haven't been any big companies build on a…

> bulb language

Had to look that up — do you mean a blub language?

Post reply on HN