Ask HN: Why isn't there a backlash around charging for security features? | Hacker News Reader

Ask HN: Why isn't there a backlash around charging for security features?

57 pointseranation65 comments

There is a very common (dark?) pattern I see employed by practically everyone in the industry, instead of charging for differentiating features, we seem to accept that it's ok to charge for security features as premium features in the pretense that these are "Enterprise Features". I am not here to name and shame but you know how it works. Role Based Access Control, SSO integration, API access to audit logs, MFA are presented as "premium enterprise features", why isn't there a bigger backlash? Why is this practice not pushed back by everyone? The startup I'm building, we are committing to provide SSO/SAML/OIDC, audit logs, advanced RBAC etc for free for everyone, we want people to pay for actual differentiating features. Am I missing something here?

View on HN

Because it isn't a dark pattern. It's market segmentation, and, contrary to popular belief, market segmentation has two goals, not just one: yes, it soaks price-insensitive customers, but it also provides relief for price-sensitive customers.

"Needs SSO integration" is one of the cleanest market seg signals available to a SAAS startup. Customers that really want SSO integration are overwhelmingly large enough to stop obsessing about SAAS seat costs. What's better, this extremely desirable cohort of customer prospects is increasingly mandated, as a cohort, to seek SSO integration.

A frequent cynical (and, justified) question asked about new services appearing on Hacker News is "where do they make their money?". You know, "if you're not the customer, you're the product"? Well: this is one very straightforward way companies manage to have generous free or cheap tiers.

We're not going to charge extra for SSO integration; we're SAAS customers ourselves, and the sso.tax is, obviously, super annoying. And you can take this idea way too far --- as you would be if you charged extra for 2FA. But "dark pattern" doesn't mean "everything we find super annoying in business". I absolutely understand why SAAS companies tax SSO.

> I absolutely understand why SAAS companies tax SSO.

You don't mention all advantages to the SAAS company to have their customers using SSO, though: improved customer stickiness, happier end users, and no more liability for stored password hashes. Charging for SSO is false economy.

I think that's potentially the difference between social sign on and enterprise SSO.

Login with Google etc. achieves most of those advantages, while still leaving SSO against an organisation's SAML provider etc for enterprise.

That solves password hashes, yes. But the end users face the scenario "this is one of those apps that's missing from my company's SSO portal, how do I get into it again?", which nobody likes. And does nothing for stickiness.

I have worked for a few small price sensitive companies and we very much still relied on SSO.

Yes, obviously, the sso.tax wouldn't be super annoying if that weren't the case.

I usually very much agree with you. But this is a case where I'll "beg to differ".

At least we agree on the baseline of not charging for 2FA.

The fact is, it's very difficult to fight "shadow IT". SaaS companies penalizing early adopters for access to acceptable security only incentivizes employees, at large and small companies, to bypass IT vendor management and security policies. And once you've had to make an exception for "the CROs favorite SaaS tool", it's going to be fair game and an uphill battle to taken seriously.

As an industry, as a society, we need to make some of these security features easier to implement, easier to adopt, and not a penalty.

As I noted in a sibling comment, I also think that running a protection racket is lazy product management and marketing.

Frankly, if you are telling me that I have to pay extra for protection, that tells me that you don't take security seriously, since you are basically operating an insecure environment as your default practice.

The companies listed on the sso.tax site include many that self-evidently take security extremely seriously, far more so than most of their customers, so I don't know where that leaves your argument.

It sounds like you're just not happy that SSO gets used for market seg. I'm not "happy" about it either. That doesn't make it a dark pattern or an indicator that companies "don't take security seriously".

The status quo is the problem here. So pointing to the status quo doesn't invalidate my argument. Taking security seriously means you take the security of your customers and your users seriously--not just yourself. I'm sure a lot of those companies take their own security seriously. That doesn't mean they shouldn't be doing a better job for their customers, their users, and the rest of society.

It's not just that my feelings are hurt, it's that I personally view this as a societal issue. Our tremendous reliance on this internet thing, and our lax day-to-day security practices and expectations, puts us at serious risk--individually and as a society.

You regularly post about the overcomplexity of security protocols and their poor implementation. I'm sure you're more than just "unhappy" about those things.

SSO shouldn't be hard to implement relative to, say, MFA--especially since so many use SMS. Auditing should be incredibly straightforward to implement, especially if you are using tools like Rails or Django.

Charging money for SAML integration is simply not a "societal issue".

Nor are either JWT or DNSSEC--on their own.

But we aren't having a discussion amongst the general population. We're having a discussion amongst people who plan, design, and build these systems and who, as professionals and practitioners, society looks to for input on policy choices.

The fact that SSO--and let's be honest, it'd be nice if it weren't always SAML, just like it'd be nice if Google/et.al. didn't force us all to use JWT--is so broadly taxed should be viewed the same way we used to view storing passwords in plain text or not supporting 2FA.

DNSSEC and JWT are far more important security issues than the SSO tax; like, it's not even close. None of these are societal issues though; "things that annoy me" are not per se societal issues. "How much a service costs to use properly" simply isn't a societal issue. Just pay what they expect you to pay and move on. Or don't, and don't use the service. I don't see what's complicated about this.

It's an indicator that the company favors profits over security.

Literally every commercial entity, including the ones with the actual best security teams on the planet, favors profits over security in multiple ways.

Yes! Their behavior in public is one of the few signals we have to assess the degree to which they take security seriously behind the scenes. Hence, the SSO tax is an issue to us, we do evaluate companies by their behavior in this regard.

That's silly, since there are powerful business reasons for companies to charge for SSO integration (see above), and companies routinely make far more important compromises in favor of profits without comparable justification. But you do you.

And this is why it is a societal issue.

Individuals and companies will do what makes sense for their bottom line in the short-term, even if it is lazy or even self-defeating in the long-term.

But if it is bad for society, then it's a societal issue and requires society to intervene.

Just pay for the service or don't use it. Society will be fine.

> As an industry, as a society, we need to make some of these security features easier to implement

They're very easy to implement - it just costs money. If you've got enough employees that you need SSO, it's time to move off the free tier.

As an industry, as a society, we need to stop expecting developers to deliver services to huge multinationals for $0

Actually, SSO is usually a requirement for even basic security audits. So SSO is essentially required for companies operating in specific sectors, regardless of their size. Healthcare and military contracts are two obvious ones, but any company dealing with sensitive information, going through SOC compliance, or similar will likely need to enforce SSO to enforce and audit access policies.

Besides, SSO is a major convenience. Assuming that SSO = large company is a flawed perspective, although, I understand the reasoning you're conveying. I believe, however, that only very small companies (less than four people) can easily avoid SSO, because it is complicated to deal with on/off-boarding employees, SSO helps.

And I agree with OP in most regards, for most services, advanced security controls should be available. I think it is far more likely that most companies segregating their security features are not secure by design, so the functionality they're offering is poorly implemented, and by restricting access they limit the amount of support they need to provide to those features.

I don't know which security audits you're referring to. PCI doesn't require SSO for all SAAS apps. There's no standardized HIPAA/HITECH audit at all. SOC2 is probably the primary driver for SSO adoption, and even SOC2 doesn't actually require SSO (SSO is just the easiest way to meet a bunch of SOC2 security scope requirements). SOC2 is also the price-insensitivity threshold product managers are relying on for segmenting: most sane companies don't SOC2 until they're past product-market fit and are reliably closing sales (anybody who tells you to speculatively SOC2 before then is selling you something).

Again: it's obviously an inconvenience, or the sso.tax wouldn't be super annoying. I would of course prefer it if SSO were free everywhere.

This is another comment that makes insinuations about the competence of companies that tax SSO. But you can just look at the sso.tax site and see several companies with world-class security teams, so that argument doesn't work so well.

Do you really believe that these world-class security teams have the authority to influence this detail of the pricing models of their organizations, or the political naivete to fight this fight?

In some of these places, yes. It's a seller's market for this kind of talent, for whatever that's worth to you to know.

Ok this is a _fascinating_ comment. (thanks for the discussion as always by the way!)

Is there a link between the market for security engineering talent and the leverage that the security engineers have within their organizations? Are you seeing anecdotes play out in the industry that inspire hope that the balance of power in business decisions is shifting toward the engineers?

I don't think engineers automatically agree with you that organizations should pay less money for the services they're working on, is the issue here. It feels like a lot of people on this thread are convinced that Very Annoying Things are, per se, moral catastrophes. But they aren't. Services cost what they cost.

A literally equivalent way to look at the SSO tax is "the no SSO rebate". As a security engineer, I'm not prepared to launch a moral crusade over SMBs who don't adopt SSO on all their random SAAS apps; meanwhile, we're SSO on everything, and it costs us extra money, and that's life in the National Foosball League.

I’m the commenter that’s not on a moral crusade, or even annoyed, I just question the business justification for gating SSO in this day and age :)

See above: companies with SSO's are overwhelmingly less price-sensitive than companies without them, which tend to be smaller.

Times are changing though. Smaller companies increasingly have SSO portals. At what tipping point will the industry embrace SSO for everyone?

Since the whole point of the SSO tax is to segment out small companies from larger ones, mass adoption of single signon by small companies is a problem that will solve itself, as SSO stops being a good segmentation signal.

Are we talking past each other? It seems like we just disagree on when segmentation on SSO will no longer be prudent - I believe we’ve crossed that point, and you believe it’s in the future. Seems like we agree in substance though.

I don't think Thomas has an opinion on the "when". He's just saying it's being used that way. If it's being used that way, then it's still a good signal (in the markets where it is being used in that manner).

If it's actually true that we have crossed the point where it is no longer prudent for companies to segment their customers this way, then there are a whole lot of companies making unsound business decisions, and the problem will solve itself.

> There's no standardized HIPAA/HITECH audit at all.

HITRUST is the standardized audit for companies that care about HIPAA/HITECH, but your argument certainly holds there as well (everything you can say about SOC2 is just multiplied by an order of magnitude or two for HITRUST).

Yes, but also a bit of muddled.

Let's take SSO for example. In the early days of Okta/Ping/OneLogin - Lets call it 2015. SAML was a big cost add-on to almost every service. At the time most services (with a few exceptions like Zendesk and Salesforce) charged you a decent proserve fee for setting it up, because it was a manual setup process for them. It was hard/time consuming/etc.

For the time, that makes total sense. But since then SAML libraries and usage have matured. You can write less than 100 line python/flask application that supports SAML. So while SAML was, at one point, actually expensive (by person hours, both engineering and PS) to implement ... it no longer is. Companies are just continuing to charge for it in most cases... because they can get away with it.

The real problem with SSO in general, at least currently, is that it's not viewed as a necessity for all businesses (even though it is). A company a decade ago could sign up for the cheap Slack edition and be happy with that through 100+ employees. Now a company of 5 or 10 may already have SSO and therefor need to goto a Slack edition that is twice as expensive - simply for that one feature.

SAML libraries are still pretty unsafe. But I agree with you: the cost of actually delivering SSO features has nothing to do with why they're taxed.

In the general case I think it's a perverse segmentation, security is the right default and obviously we can't really force people to stop offering inadequate security for a lower price, but we should discourage it.

Remember when bulk hosts segmented on HTTPS? Want to host dog.example, cat.example, and sheep.example? That'll be $10 per year. Oh you want SSL for them? That'll be $50 per month per domain. Sure, you get better performance and whatever else, but there is no option to go without those and just pay $10 per year for the basic service but with HTTPS.

They had very similar excuses to what you've offered, it's a clear market signal, it actually does cost us money to do this (but nowhere near what they were charging usually, these might be "$100 SSL certificates" but if the bulk host wasn't getting a good deal directly they were buying from a "discount" reseller for less than sticker price anyway), we can subsidise our cheap offering knowing serious customers will buy the expensive one and so on.

If there are people out there who have less security because that cost less money when in reality it was just a feature toggle that's a bad thing.

Security is different the same way safety systems are different. You don't really want the investigators of a child's death to conclude that the $500 extra "Premium" version of your product had safety interlocks that would have prevented the death, shame the "Family Economy" version lacked those. And likewise, when investigators conclude the successful attack on Customer X was because they had your "Basic" package lacking the optional security features for "Premium" customers, do you think other customers buy Premium or do they leave for a product which doesn't have your terrible press?

The really nice pies I sometimes buy have a nicer pastry, and a richer gravy, but in common with the cheaper pies I also sometimes buy they don't have shards of metal or glass, expired or diseased ingredients, and so on. The Premium product is nicer but the cheap product is up to a minimum standard for safe food, and I feel like way too many software products aren't reaching a minimum standard for secure software.

Personally, I hear the arguments about "how you do segmentation". My personal opinion is that that is a lazy cop-out that is only successful in an environment where no one is being held accountable for security or privacy violations.

There are other ways to do segmentation, but they require actually understanding your customer and what they need in order to develop a value proposition.

People will complain about how hard it is to implement. And that's a thing. We as an industry are to blame for that. Tools like Rails, Django, etc. should be setup to support SSO/SAML/OIDC/RBAC/Audit Logs/MFA by default--rather than the default always being 'start with a user table and shit password management'-- so that the cost of those implementations goes down, and so that the "best practices", such that they are, are implemented from the very beginning.

Not at least supporting MFA and audit logs, at this point, should be considered an ethical lapse.

Here's a list of things you could charge extra for:

  - White-glove support.
  - Higher quotas and usage. 
  - Dedicated capacity. 
  - Value-added services. 
  - Dedicated/isolated instances. 
  - Multi-instance configurations (Likely only a feature requested by actual enterprises or resellers)
  - On-prem installs. 
  - Access to greater customizability. 
  - Access to escrowed source code. 
  - White-labeling or branding

There are so many other things you can charge an enterprise extra for. Safety, security, and peace-of-mind in using your service shouldn't ever be a question.

The startup I'm building, we are committing to provide SSO/SAML/OIDC, audit logs, advanced RBAC etc for free for everyone, we want people to pay for actual differentiating features. Am I missing something here?

At some point in the future you will be faced with a dilemma. You will have a customer who can't get these free features to work with their existing systems. On one hand you won't want to give away the time of a senior engineer necessary to fix what is their problem. On the other hand, you won't want a potential large customer to walk away and tell people they don't use your product because "it doesn't work."

Charging customers for features is really charging them to support getting those features to work for them. It means you can afford to support customers and make them happy rather than having to say "The feature is there. Good luck!"

These are not real security features, they are implementation features that only the largest customers will demand, so they really are differentiation: SSO (enterprise kind, not log in with Google), Role based access control (i.e. custom roles, not the usual admins, managers and users), Log auditing.

MFA should be the default. Because one day, Bob in sales is gonna click that link and enter his password that 850 other sites use.

Two points: 1. It’s common (and I think ethical and prudent) to charge for enterprise management of security features. Microsoft, for example, has had a long running practice that in the box with Windows you get everything you need to manage that one system. If you want to manage many systems, you buy a product that does that.

2. I HAVE seen a dark pattern, particularly in “Freemium” software, where security primitives like encryption and access controls are upsells. If you expect me to store my data in your SaaS platform then I believe you owe it to me to provide baseline security controls. Put another way, it’s not freemium, it’s “not-fit-for-purpose trialware” if basic security controls aren’t provided.

It's not the job of open source developers to secure your data. Rather, open source developers provide tools that let you do it yourself. Like GPG. If you want a turnkey solution then consider rewarding the people who are already working hard for you, by giving them a rational self-interest to help you comply with your security policies.

There is a backlash around it. https://sso.tax is a perfect example that I'm sure you're aware of. But there are two major ways to look at this:

#1 - From a builders perspective, you've got to figure out what features (security or otherwise) that cost you extra and charge accordingly. In the old days SAML was one of those features was legitimately expensive to implement. Now keep in mind that not everything that costs you extra people will necessarily want to pay for.

#2 - From the sales perspective, what are features that people are willing to pay more for. SSO is something that is more and more frequently a business requirement. You want slack? Require SSO? Well you're paying for Business+ at $12.50/mo/user rather than Pro at $6.67/mo/user... even if you care about nothing else that comes in the Business+ plan.

As a Security/IT person, I absolutely hate that features I consider to be "required" (like SSO and APIs) are extra costs when we're the customers. The best I (and others like us can do) is convince our businesses those items should be part of the default feature set and not charged extra for.

Nope, TIL about sso.tax, I'm one of those 10,000 I guess :)

https://xkcd.com/1053/

Nobody knows what these things are or why they need them. The only thing that makes companies care about security is when it can be used to close more deals, or comply with regulations. That means you're either targeting MM+ customers or are MM+ yourself. Until then, if a company can jettison audit logs to save $20/seat, they will. And providing them that option may be exactly the mental gymnastics you need to close the deal.

I also don't agree it's a dark pattern. Implementing and storing audit logs takes up time and space, so it makes sense to charge more for them. Having your engineers spend time on meta-features like SSO rather than the next product roadmap feature has an opportunity cost so you should get some cash out of it to balance things.

I'm just thinking of a standard B2B SaaS context. If you're in the security field selling to security professionals then maybe these features are table stakes?

SSO also costs many companies a few hundred thousand dollars to implement.

Not everyone is using AWS cognito or auth0, and thus has to add on SSO to an existing authentication method.

Even if you are using Cognito or Auth0, its still annoying to implement in their systems, and THEY charge you additional for it as well.

Add on to that its a clear segment of customers, it really makes sense to charge more for it.

I’ve been working in the infosec industry for some time now. I think that most of my peers are either aware of this practice, and see themselves as powerless or openly criticizing this issue. The criticism happens mostly inside of closed rooms and segregated areas (like Twitter bubbles). The practice itself doesn’t qualify as a dark pattern though.

Respected infosec Podcaster Patrick Gray had a show recently about this topic exactly:

https://risky.biz/soapbox56/

I'm a SaaS owner. SSO/SAML/etc. take time to implement and maintain. They are also a very good indicator of company size, which typically means deeper pockets. So why do services charge more for them? Because they can. But I agree with the sentiment -- things like MFA (!) and API audit logs should be available to everyone (logs being very useful for debugging).

SSO integration is a simple way to delineate between Enterprise and Not Enterprise. I'm unsurprised that it raises the charging band.

There are very few teams in the typical organization that can unilaterally veto a purchase. Security is one of them, and the easiest to get to reject the free version by restricting security features.

In your model, the enterprise version is a marginal cost. Customers get 3/4 of the product for free, and decide whether they want they want to pay for the other quarter. A lot of people won't, or they'll write a batch script to replicate the single feature they want, or etc.

In the "restricted security features" model, customers either get 0 features because security won't let them deploy it, or they get all the features.

It also encourages startups to use the product since it's free... for now. A 3 person startup doesn't really need SSO or RBAC. They eventually will, as they grow, and they'll already be locked in.

I think Enterprise Security Features will eventually trickle down to all plans. Years ago we required Premium subscription to have forced HTTPS and we didn't have a single bush back - but it was shameful act from 2000s, especially after Let's Encrypt came about. Essential (keyword) security features should absolutely be included in all plans in this day and age.

Admittedly, it's easier to segment plans based on such top level features you listed (not required by everyone but required mostly by Enterprise customer) than having matrixes of features that make usability of the software a nightmare just because you're not on a specific plan. Developing and ploying software with feature flags that change the workflow can be a nightmare. Not to mention segmented documentation that's impossible for your customers to follow / use.

That said, I know you're coming from an idealistic point of view, BUT be careful providing some features that require high touch to freeloaders - assuming you'll have a free tier. Question to ask yourself is - can a multimillion or even billion company use our free tier comfortably - if the answer is yes - then you'll struggle making money.

This is one of the big reasons I initially fell in love with FOSS; you get all the enterprise features out of the box, or at least they were not artificially fenced out. It's also the reason why I'm not generally very enthusiastic about open core stuff. I do note that this sort of market segmentation has been going on for very long, notable example would be Windows XP, where "Home" edition can not join to AD domain.

The enterprise level security I've often noticed is around integration with SAML or LDAP. Both of those do take time and effort and I appreciate charging extra for it. As for RBAC, MFA, etc those should be made at a lower level like RBAC could be at a Teams level. MFA of course should be for everyone.

I know we are an outlier, but literally the first day at my startup, we setup Okta for everything we could, best investment ever, onboarding a new user takes 1 minute, and we don't have to worry about leaked / weak passwords. Adding support for SAML / OIDC is relatively easy today with Auth0/Cognito, but agree it's an effort. But I really believe that the time to implement it is irrelevant, I believe people should charge for differentiating features, not common/convenient features.

This could be viewed as shortcoming in open source licenses too.

Many companies take an open core approach but license some features (maybe security related, management, scalability, etc.) with proprietary licenses and charge for them.

Part of this is because traditional open source licenses tend to assume all time and resources are donated freely. It’s hard to sustain one or more people in terms of money, and some run the risk of another company reusing your source in their product.

I think some viable alternate approaches to earn money through open source would go a long way towards avoiding open core approaches. But until that happens companies will do what they need to in order to keep revenue flowing.

Backlash? Can you be more specific? Do you mean some kind of organized boycott? Complainy blog posts? What exactly would you expect? Generally, companies do what makes them a profit and customers either buy it or don’t buy it. We no longer have the institutional means for anything else.

A better example would be that the Home version of Windows doesn’t include BitLocker disk encryption.

It's insane to me that SaaS providers are trying to productize data encryption at rest on their platform. How is that my responsibility as a customer? I'm paying for a seat license.

I am happy to pay for the implementation and ongoing maintenance of what these systems accomplish. Why should corporations give things away for free simply because they relate to security?

Simply, these features have a legal standard to uphold and the software vendor may be liable for these features misbehaving.

For example, your healthcare software incorrectly exposes Patient Health Information (PHI) due to a bug in your RBAC. You don't just ship a patch that fixes this, you are liable for the PHI exposure up to $150k per PHI exposure...

How do you prevent this? You charge more for these features and use that money to purchase liability insurance.

As someone who has spent most of their career working on this stuff: this isn't it at all.

TLDR: Because they can.

SSO is the one feature a SaaS company can use to force people that can afford it up to higher tiers when their usage remains low but the the value to the customer is high enough to justify the tier increase because of a mandated SSO requirement etc.

Who charges for security features?

Salesforce

Because often those security features come with a lot of excess infrastructure and architecture/re-engineering requirements. Would you prefer we lifted the fee for everyone including small businesses who don't need it to keep the margins we've got?

I agree it's silly binding features to tiers, for example having to buy an Enterprise license to get MFA is ridiculous (looking at you _every_ Oracle competitor). You _should_ be able to pay a per-seat, per-resource or flat fee to get each additional feature. Security isn't for Enterprise only.

I'll give you some fair examples:

Audit logs: Every action every user makes on the platform, usually for a fixed period - often between 2 and 7 years. For thousands of users, or in publicly shared websites or end-user-customer-facing websites, this can be hundreds or millions of extra users all generating hundreds and thousands of logs each per year. And if we add any more features to the platform? The problem compounds, and it gets more expensive to support the additional resources. We also have to integrate with every SIEM or partner with a third-party to expose the functionality, none of which use the cheap "bulk data export" option but incrementally export logs continuously using shitty CRUD API's we developed for the front-end. God help us all if I chose AWS and I don't get to meet with someone who reports to Bezos to negotiate a deal. I'm gonna get screwed.

SSO/SAML integration: For a subset of our customers, say 5%, we have to allow and cater for the design of major IdP's. Even billion dollar companies like Slack can't cater for the design of Google Groups and integrate with them properly, how the fuck am I with my mere 100-person engineering team supposed to cater for each and every IdP and weird implementation they require? Great, now I've got to retrofit my architecture to support design choices made by companies who only care about authentication and RBAC of a very generic company structure. They don't need to cater for everyone, but now I do?

MFA/2FA: Now I have to add support for either email or SMS because "hardware tokens are too hard" or "we need a backup option for if I lose my phone", and a whole 24/7 operational process to support it because every now and then that shitty cell tower in Turkey or New Zealand goes down and that one, critical SVP at their holiday home can't login. Great, my support staffing costs have gone up exponentially, and it's only to cater the 2% of dinosaur executives that can't figure out how a fucking Yubikey works without calling me for support like I'm their fucking grandkid.

None of this is easy. It's all hard because tech's expensive, process is expensive and most importantly people are expensive.

Anyone who questions Enterprise SaaS software costs in 2022 doesn't understand the end-to-end cost of running and supporting Enterprise software. There's no such thing as a free meal, just because you're used to paying $2/mo for your shitty personal blog which integrates with all the modern security features you've come to expect at an Enterprise, doesn't mean it'll translate to your custom Enterprise CRM or your wacko-Enterprise integration.

I think the nature of your startup also plays a role with it. Many SaaS propositions do not even target the "enterprise" customer and never have to deal with CIOs and CISOs. What is the nature of your startup that you want to (commendable in my opinion) immediately address these features?

holding hostage security features behind payment is what is wrong

security should be the default, no matter if you are wealthy or not

otherwise you create the recipe of a shitty civilization, wich you already have, too bad

Reply on news.ycombinator.com