As someone who deals with application support, another big reason is SSO is such a support nightmare. No one wanted to touch SSO tickets because of how frustrating they were to deal with. People wouldn't follow the instructions. Microsoft/Google moved something in their portal and we didn't know so instructions were useless. Microsoft/Google would be having issues and we got tickets because they were still working until tokens expired. Their Admins would turn on 2FA and when their support desk got "Cannot login to $OurProduct", they would just flip it over to us without caring. List goes on and on.
I was lead engineer for a startup. By virtue of being the most flexible in my day-to-day, I ran front line for most of the customer support issues.
SSO issues took exponentially longer than nearly every other support issue and accounted for well over 50% of our support efforts.
We didn’t really feel like there was much we could do about it either. Most of it came down to the fact that the user of our application was not the person also able to setup SSO. The result was a massive game of pass the hot potato until we would get fed up and request a call with our customers IT team.
Yeah but does that require any expertise to solve? It’s a bunch of meaningless arcana, for which the other party pays well. Seems like a fair deal. Someday you might get big enough where it’s minions talking to minions, or so big that people simply accept no customer service as the status quo.
The “human cost” of SSO is definitely the hardest part.
At WorkOS we solved this by shipping the whole config workflow in the form of an admin portal. It checks things like SAML certificate, signatures/assertions, attribute mapping, etc. and a zillion other edge cases across dozens of identity systems.
Yes! We don't charge for SSO, but thankfully we've only had our largest customers ask for it -- and every time it required significant back-and-forth to get it set up. Basically every time somebody comes in with a new IdP, I have to go stand up my own instance so I can figure out what weird combination of options will make it work, because I'm convinced nobody actually understands SAML.
That's my conclusion as well. We're a small shop and I used to feel a bit incompetent every time we'd setup SSO with a big client and it wouldn't work as it should, until I noticed that it was due to inconsistencies, misconfiguration, on their side more than half of the time.
Now I've accepted it though and I don't mind doing that part of my job. I know they feel somewhat incompetent on the other side as well.
I have to say, once it's setup it just works without any other intervention required though, I have very few support requests related to already existing SSO setups.
Nobody understands SAML because it doesn’t really exist. It’s not so much a standard as a bag of standard parts from which a protocol can be assembled. It’s possible for two implementations to be fully compliant and yet incompatible.
PS: the single most common developer error is assuming the SAML configuration is static and has a single certificate somewhere. The modern approach is to get all configuration from a metadata XML file including the multiple overlapping certificates that are used to implement seamless rotation on a schedule. If you haven’t accounted for this, you’ve “made it work” just like a child making a flying machine by throwing a rock.
(Guess what I was troubleshooting just this morning in a vendor product juuuust this morning. I’m not bitter this is the fifteenth time I’ve seen this exact issue. I’m not!)
I thought some company had free SSO for Google and 365 only and advanced SSO on the enterprise tier. I don't remember which company though, so maybe I made this up.
Meh. Most of them are using off the shelf stuff like Entra ID or Okta. They support complex configs but it's all on the side of the IDP. For the end service it's just SAML.
That's why you charge extra for the White Glove Service turnkey support tier. Nobody's claiming every SaaS vendor has to spend days of support time handholding every single customer through setting up semi-custom SSO solutions - we're all just asking for the vendors to stop gatekeeping the basic off-the-shelf SSO implementation!
No problem at all with the concept of price discrimination. The economics make sense. In any scenario where unit costs are low, but development costs are high, the ideal situation is where everyone gets the benefit of having the product at a price they are willing to pay. Maximizes total value to all parties.
The problem with the SSO tax is that it wedges itself into the pre-existing cracks in most organizations. Security practitioners are already in conflict with other departments. What happens when a department head has pitched a new SaaS as being 1x price, but then it becomes 2x price after the security team's requirements are added? It is not seen as the [application is expensive], it seen as [security team's requirements have doubled the price]. Conversely a price discrimination strategy which locks specific user facing features behind a specific tiers means that the same person championing the software, would also advocate for the appropriate payment tier.
Price discrimination is a valid strategy. Responding to organizations who are actively making the security practitioners job more difficult is also valid.
This is a good economics lesson but fails to address the actual issue people have with the SSO tax. It isn't about the concept of price discrimination, but price discrimination when it comes to security. You can charge extra for convenience features or other value-add features, sure, but the choice of login provider is something that should be table stakes for every person and every organization regardless of how big they are or how much they can pay. An even worse example – plenty of apps gate two-factor auth behind a paid tier as well.
Sure, but most SaaS support “SSO at home” in lower tiers via either Google idp or GitHub. So yes you’re locked into those vendors which kind of sucks but it’s not necessarily true that you have to give up security without forking over the “SSO tax”
I mean, no. If they supported BYOSSO then they wouldn’t be, by definition, charging an SSO tax. People are using the term when SSO as a concept is gated behind a paywall.
A customer who wants SSO is signaling that they are using this product in their business operations. I.e. they are making money from it. They aren't just learning it, or using it as a hobby. Therefore the product vendor is going to charge the customer at least some approximation of the value the customer is gaining from the product.
While generally true it's not a perfect signal. I would love to roll out SSO for my family off of my domain but can't because of the SSO tax. I realize power users like me are in the extreme minority
The amount of money and budget that a company has can vary wildly. Just because your company uses SSO doesn't mean you're a Fortune 500.
Of course this mostly means that if your required feature set falls into the "Contact us for pricing" tier then you're going to have to talk to a sales rep (probably several, from different vendors so you have a competitive quote) instead of getting any kind transparent pricing.
Exactly my thoughts. IMO it's analogous to SSL/TLS, which for the longest time was something you had to pay extra for at multiple levels. You had to get a dedicated IP for your service instead of being able to use shared hosting, you had to buy the certificate itself, and you had to have someone renew it and install the new certificate every now and then. Even from the user side there were web sites I remember where SSL access as a client was a premium feature as if it had a meaningful cost per use instead of just the cost to have it available at all.
This was long lamented in the security-focused parts of the internet but no significant movement happened until late 2010 when the Firesheep extension made sniffing unencrypted passwords or session keys accessible to the masses. Suddenly it wasn't just security nerds complaining about things that could easily be brushed off by higher-ups, it was a problem that anyone who could install a Firefox extension (which thanks to ad blocking and the general badness of could see with their own eyes
Almost overnight major services decided that they in fact were fully capable of offering encrypted services to everyone. Suddenly client and server applications, SSL/TLS libraries, etc. that had been ignoring SNI all started supporting it over the next year or two so you didn't need a dedicated IP per hostname anymore. The ISRG was formed and developed Let's Encrypt to solve the problem of having to pay for certs, and while they were at it took the opportunity to develop and enforce the use of ACME with short-lived certificates so automation was effectively mandatory.
In six years we went from there being a "SSL/TLS Tax", which every part of the process would defend as absolutely necessary costs, to it being freely available to all and automatically supported by a lot of major application and service platforms.
I look at the SSO Tax situation as being mostly comparable from the user side of things. The internet as a whole would benefit from wide support for SSO, but the demand to solve the problem is minimal because most of the people making the purchasing decisions don't care about the problem enough to make it a requirement.
There are definitely some valid points that have been made about support costs associated with SSO, especially with regards to supporting more than just a couple of big name identity providers, but I don't think most people would complain if a vendor limited their free/cheap tiers to those couple of big systems those clients are likely already using. If someone needs custom integration they get to pay enterprise prices, but if they just want to sign in with Google that should be accessible to all. The support costs should scale well with a good implementation, hypothetically if Google or Microsoft changes something that breaks your integration you only have to fix it once to solve issues for everyone using it, as opposed to private identity services where each tenant might need something slightly different.
> It's a bad system and you should feel bad for using it.
What "system" is bad and why? The poster made several arguments - which one of them are you rebutting?
The core idea that "you should have to pay more money for more features" makes sense from a basic economics standpoint (regardless of other rationalizations).
> I wonder if someone avoided perfectly reasonable SSO protections because of this tax
I don't know how much sense this speculation makes. SSO is complex to set up - without data, you could just as easily argue that misconfigured SSO makes breaches more likely, instead of less.
Plus, from a more practical standpoint, if you're frustrated about the never-ending stream of breaches (as I am), then it'd be better to push for laws that make the end result (personal data leaked) directly illegal with steep fines. There's too many different "upstream" problems (lack of SSO, default database credentials, buffer overflow in web application, misconfigured authorization system in webapp, etc.) for the strategy of "wage war against them one at a time" to be productive.
This car with no seat belts, no airbags, and no ABS is just price discrimination! Strangely, no one seems interested in celebrating the implied discount for not having safety.
This is a solid objection that I hadn't considered before!
Why isn't SAML SSO mandated (either literally or my convention)?
Practically speaking, as someone who spends all day trying to convince developers to implement SAML SSO, I really wish this were the case :)
I think in practice, software vendors correctly assess that relatively few of their prospective customers actually care.
If many small / price sensitive companies really wanted SAML SSO from their vendors -- if there were really meaningful demand -- I imagine we'd see more pricing plans with SAML SSO bundled into entry level tiers.
As for mandates, this is a challenging ethical question. I don't think it's necessarily obvious in all cases that some institution should impose safety regulations upon us.
There's clearly some set of risks we accept, and some set of risks we don't accept. And we all draw the line in different places.
This is pretty obviously true. Not many of us worry about objects randomly falling off buildings. We don't all wear helmets all the time. It's certainly a risk, but do we really care?
I think the revealed preference from many software buyers is basically ... no, they don't care about having the security benefits of SSO.
>This is a solid objection that I hadn't considered before!
To be quite frank: this strongly suggests that while you put a lot of effort into writing a long article in defense of the SSO tax, you didn't perform more than the most cursory research about why it's a topic of discussion.
This argument is literally above the fold on the two top search results for the term.
>In short: SSO is a core security requirement for any company with more than five employees.
And the other explicitly makes the car-safety analogy:
>Imagine buying a car and the manufacturer asks for an extra payment to unlock 100% of the braking power. Not offering security features if they already exist in your product means a vendor doesn’t care about your security. Our aim is to spotlight vendors who overcharge for security features, in hopes of instigating a change in the industry.
And to be franker: the word "security" appears exactly once in your entire piece. That's a near-complete avoidance of the actual issue that people are highlighting.
I perfectly understand the rationale behind the pricing model. The point is that "only large enterprises need or care about SSO" is completely wrong-headed and detrimental to the overall security posture of any business customer. That is and should be unacceptable.
On a lot of issues (passwords, SQL injection, automated deployments), buyers originally didn't care much about security, but the security community slowly but surely managed to shift norms and get doing the right thing to become normalized. I think that could happen on SSO too, if not for the fact that it's so effective as a price discriminator, which in turn I think makes it less likely to happen absent some kind of regulation. (Developers at small companies might not care, or they might want to do the right thing but be unable to justify it to the boss; meanwhile, SSO is usually a non-negotiable requirement for enterprises. I think that's a bigger factor than apathy or "price sensitivity" (enterprises are often extremely price-sensitive) in why it's such a good discriminator.)
I favor regulation on this, even though it's probably not necessary in every case, simply because I don't see any other way to break this equilibrium.
I also don't want to mandate anything but as an industry we have to find some way to do better on security. Free SSO and 2FA with very strong nudges seems like a good path.
We effectively did tell them they can't by not allowing any vendors to ship a lower cost car without those features. This method of operation in the car industry is incredibly common and has probably saved hundreds of thousands of lives.
As far as the older cars without those features allowing them to age out has almost entirely worked.
This car comes with a spike pointing out of the steering wheel. For a premium fee we'll replace the spike with an airbag. Why aren't you cheering for the cost-saving spike-flavored steering wheel?
My job involves working with customers to test out products - has for years, and for several jobs. None of my products have ever charged extra for SSO, and most require it, so I get to deal with it all the time.
For the past 5+ years, the part of configuration that takes the longest - by far - is always SSO. I cannot imagine the amount of added support calls, time, and frustration brought about by it, so I can completely understand why some companies gate it behind more expensive tiers.
I was responsible for IT in a hypergrowth scale-up and I don’t like this article, it misrepresents the problem. The problem is, when you are big enough to set up SSO like Okta, you have to upgrade nearly all of your subscriptions in a short time to make use of it, suddenly resulting in a huge increase in the budget. So, let’s say the business goes from X to 2X in revenue and from X to almost 2X in staff (let’s assume there’s some small increase in productivity over time). In some incredible logical twist every SaaS provider thinks that 2X increase in price is affordable, despite that the company is still burning money and the enterprise features aren’t really needed yet. 2X budget isn’t approved by CFO, cost-cutting exercise starts and price increase is matched by significant reduction in number of licenses. Did it worth it? Not sure. Volume-based pricing complimented by feature add-ons would do a good job too.
Let’s not forget that the whole reason your company needs to upgrade all its subscriptions for SSO is so it can get a soc2 and offer its own high-priced enterprise plan (which is probably gated by SSO).
This argument is basically wrong because it supposes companies don't have market power when they do. "Market power" doesn't mean monopoly. It takes at least four and more often at least a dozen viable competitors before you have enough that there isn't an implicit cartel, and there are altogether too many markets where this is the case.
Nearly all specialty or line of business software, for example. These markets commonly have two or three providers and rarely have hundreds. Literally the intended purpose of copyright in this context is to give the authors market power.
And then the example given is the sympathetic one. The premise here is that there are the same number of customers willing to pay $40 as $10, and so the rational choice for a company not engaged in price discrimination is to charge $40 to everyone and price discrimination allows them to provide a "discount" to half of the customers.
Now suppose that only 10% of the customers would be willing to pay $40. The single-price profit-maximizing strategy is then to charge $10, because 100% x $10 is more than 10% x $40, and no customer benefits because all price discrimination does is allow them to overcharge the remaining 10%.
More to the point, in an actually competitive market, price discrimination isn't possible. If the marginal cost of providing the service is $7 and anyone is charging $40 to anyone, someone else could take those customers by charging $39, and someone else could take their customers by charging $25, until the market price is a thin margin over the underlying cost of providing the service. Because even the customers willing to pay $40 would prefer to pay $8, and the company that has 0.25% market share at $40 would rather have 10% market share at $8.
The better argument in favor of the "SSO tax" is the one from the comments: That SSO actually increases the cost of providing the service by raising support costs.
I can identify basically three criticisms of my argument in your post.
(1) That I assume companies never have market power.
(2) That I suppose "market power" implies monopoly
(3) That my example was cherry-picked.
1. I did no such thing. I explicitly acknowledged market power several times.
2. Again, not correct. I explicitly mentioned oligopoly (assuming that 'imperfect competition' wouldn't land).
3. Of course it was. I acknowledged as much! I quite literally said the example doesn't generalize. The example serves to illustrate a 'there exists' claim. I felt a concrete example would be easier to follow than some kind of generalized model.
Your own comment claims that "actually competitive" markets can't have price discrimination. Sure, we can suppose the law of one price applies to perfectly competitive markets, but there's no sense in which a perfectly competitive markets "actually" exist at all! The obvious observation we can make is that such competitive dynamics imply that no one would make any profit!
My appeal to the airline industry as an example was not an accident. There's a very well-established literature on the relationship between competition and discrimination in the airline business. It's *certainly* not a settled question that discrimination decreases as competition intensifies. I included a classic from Stavins below that finds precisely the opposite of your claim.
My argument here isn't perfect. I can think of many flaws, many reasonable objections. But I don't think you're using any of them here.
> I did no such thing. I explicitly acknowledged market power several times.
Your premise is that if market power exists then market power is the problem rather than price discrimination. The issue is that price discrimination isn't possible without market power. Its presence implies that the company both is capable of and is overcharging the people coerced into the higher price tier.
> That I suppose "market power" implies monopoly
This is not an argument you make explicitly, but it's something readers commonly assume and my point is to highlight that companies successfully engaged in price discrimination can and do have market power even if they don't have a full monopoly.
> Of course it was. I acknowledged as much! I quite literally said the example doesn't generalize. The example serves to illustrate a 'there exists' claim. I felt a concrete example would be easier to follow than some kind of generalized model.
And I'm providing the 'there exists' claim for the alternative, to demonstrate that price discrimination can be (and often is) detrimental to customers without providing any countervailing benefit to any of them.
> The obvious observation we can make is that such competitive dynamics imply that no one would make any profit!
Profit doesn't really work that way. For example, if a company takes investment and uses it to buy a building to operate out of, the money not paid as rent to a landlord is added to the investor's profit, but if the company takes less investment and instead pays rent, the same money is counted as operating costs. Likewise, if you develop software needed before you can start operating and you take investment to pay for it, the net returns are called profit, but if you take a bank loan to pay for it then the interest on the loan is counted as operating costs again. The interest rate you'd pay the bank would even be proportional to the risk you'd fail, unless you post collateral, for which you'd need an investor.
So a company that didn't take any investment and operated entirely by renting everything, taking loans and using off-the-shelf software instead of developing anything in-house wouldn't be expected to make any profits in a perfectly competitive market -- and there would also be no investors to pay any profits to. Profit in companies that take investment would still be present and equal the cost (time value) of the assets bought with the money, but in a perfectly competitive market this would exactly equal the risk-adjusted market rate of return in the overall capital markets.
The distinction in uncompetitive markets is that profit exceeds that amount. (Or at least can; a market can be uncompetitive and then the companies become inefficient from lack of competitive pressure and waste the money they extract from customers instead of returning it to investors.)
It's true that "perfectly" competitive markets don't exist in the same sense that perfect anything doesn't exist, but this is splitting hairs. A gold coin might be .999 gold and you can say that it isn't perfect but you can still distinguish it from a wooden nickel.
Readit News
SSO issues took exponentially longer than nearly every other support issue and accounted for well over 50% of our support efforts.
We didn’t really feel like there was much we could do about it either. Most of it came down to the fact that the user of our application was not the person also able to setup SSO. The result was a massive game of pass the hot potato until we would get fed up and request a call with our customers IT team.
At WorkOS we solved this by shipping the whole config workflow in the form of an admin portal. It checks things like SAML certificate, signatures/assertions, attribute mapping, etc. and a zillion other edge cases across dozens of identity systems.
It’s pretty much “Stripe Checkout" for setting up SAML. Live demo here (click “Configure”) https://explore.workos.com/app/settings
That's my conclusion as well. We're a small shop and I used to feel a bit incompetent every time we'd setup SSO with a big client and it wouldn't work as it should, until I noticed that it was due to inconsistencies, misconfiguration, on their side more than half of the time.
Now I've accepted it though and I don't mind doing that part of my job. I know they feel somewhat incompetent on the other side as well.
I have to say, once it's setup it just works without any other intervention required though, I have very few support requests related to already existing SSO setups.
PS: the single most common developer error is assuming the SAML configuration is static and has a single certificate somewhere. The modern approach is to get all configuration from a metadata XML file including the multiple overlapping certificates that are used to implement seamless rotation on a schedule. If you haven’t accounted for this, you’ve “made it work” just like a child making a flying machine by throwing a rock.
(Guess what I was troubleshooting just this morning in a vendor product juuuust this morning. I’m not bitter this is the fifteenth time I’ve seen this exact issue. I’m not!)
But this will usually show up in pricing structures with SSO as a relatively inexpensive add-on feature -- not as part of an indivisible bundle.
Seemingly we want to talk about both of these things as "the SSO tax" but I think we can agree that they're pretty different scenarios.
The problem with the SSO tax is that it wedges itself into the pre-existing cracks in most organizations. Security practitioners are already in conflict with other departments. What happens when a department head has pitched a new SaaS as being 1x price, but then it becomes 2x price after the security team's requirements are added? It is not seen as the [application is expensive], it seen as [security team's requirements have doubled the price]. Conversely a price discrimination strategy which locks specific user facing features behind a specific tiers means that the same person championing the software, would also advocate for the appropriate payment tier.
Price discrimination is a valid strategy. Responding to organizations who are actively making the security practitioners job more difficult is also valid.
Of course this mostly means that if your required feature set falls into the "Contact us for pricing" tier then you're going to have to talk to a sales rep (probably several, from different vendors so you have a competitive quote) instead of getting any kind transparent pricing.
This was long lamented in the security-focused parts of the internet but no significant movement happened until late 2010 when the Firesheep extension made sniffing unencrypted passwords or session keys accessible to the masses. Suddenly it wasn't just security nerds complaining about things that could easily be brushed off by higher-ups, it was a problem that anyone who could install a Firefox extension (which thanks to ad blocking and the general badness of could see with their own eyes
Almost overnight major services decided that they in fact were fully capable of offering encrypted services to everyone. Suddenly client and server applications, SSL/TLS libraries, etc. that had been ignoring SNI all started supporting it over the next year or two so you didn't need a dedicated IP per hostname anymore. The ISRG was formed and developed Let's Encrypt to solve the problem of having to pay for certs, and while they were at it took the opportunity to develop and enforce the use of ACME with short-lived certificates so automation was effectively mandatory.
In six years we went from there being a "SSL/TLS Tax", which every part of the process would defend as absolutely necessary costs, to it being freely available to all and automatically supported by a lot of major application and service platforms.
I look at the SSO Tax situation as being mostly comparable from the user side of things. The internet as a whole would benefit from wide support for SSO, but the demand to solve the problem is minimal because most of the people making the purchasing decisions don't care about the problem enough to make it a requirement.
There are definitely some valid points that have been made about support costs associated with SSO, especially with regards to supporting more than just a couple of big name identity providers, but I don't think most people would complain if a vendor limited their free/cheap tiers to those couple of big systems those clients are likely already using. If someone needs custom integration they get to pay enterprise prices, but if they just want to sign in with Google that should be accessible to all. The support costs should scale well with a good implementation, hypothetically if Google or Microsoft changes something that breaks your integration you only have to fix it once to solve issues for everyone using it, as opposed to private identity services where each tenant might need something slightly different.
By all means charge enterprises more, but base it on something else, headcount, revenue, non-profit status...whatever.
Every time I hear about a data breach I wonder if someone avoided perfectly reasonable SSO protections because of this tax.
What "system" is bad and why? The poster made several arguments - which one of them are you rebutting?
The core idea that "you should have to pay more money for more features" makes sense from a basic economics standpoint (regardless of other rationalizations).
> I wonder if someone avoided perfectly reasonable SSO protections because of this tax
I don't know how much sense this speculation makes. SSO is complex to set up - without data, you could just as easily argue that misconfigured SSO makes breaches more likely, instead of less.
Plus, from a more practical standpoint, if you're frustrated about the never-ending stream of breaches (as I am), then it'd be better to push for laws that make the end result (personal data leaked) directly illegal with steep fines. There's too many different "upstream" problems (lack of SSO, default database credentials, buffer overflow in web application, misconfigured authorization system in webapp, etc.) for the strategy of "wage war against them one at a time" to be productive.
Deleted Comment
Why isn't SAML SSO mandated (either literally or my convention)?
Practically speaking, as someone who spends all day trying to convince developers to implement SAML SSO, I really wish this were the case :)
I think in practice, software vendors correctly assess that relatively few of their prospective customers actually care.
If many small / price sensitive companies really wanted SAML SSO from their vendors -- if there were really meaningful demand -- I imagine we'd see more pricing plans with SAML SSO bundled into entry level tiers.
As for mandates, this is a challenging ethical question. I don't think it's necessarily obvious in all cases that some institution should impose safety regulations upon us.
There's clearly some set of risks we accept, and some set of risks we don't accept. And we all draw the line in different places.
This is pretty obviously true. Not many of us worry about objects randomly falling off buildings. We don't all wear helmets all the time. It's certainly a risk, but do we really care?
I think the revealed preference from many software buyers is basically ... no, they don't care about having the security benefits of SSO.
To be quite frank: this strongly suggests that while you put a lot of effort into writing a long article in defense of the SSO tax, you didn't perform more than the most cursory research about why it's a topic of discussion.
This argument is literally above the fold on the two top search results for the term.
>In short: SSO is a core security requirement for any company with more than five employees.
https://sso.tax/
And the other explicitly makes the car-safety analogy:
>Imagine buying a car and the manufacturer asks for an extra payment to unlock 100% of the braking power. Not offering security features if they already exist in your product means a vendor doesn’t care about your security. Our aim is to spotlight vendors who overcharge for security features, in hopes of instigating a change in the industry.
https://ssotax.org/
And to be franker: the word "security" appears exactly once in your entire piece. That's a near-complete avoidance of the actual issue that people are highlighting.
I perfectly understand the rationale behind the pricing model. The point is that "only large enterprises need or care about SSO" is completely wrong-headed and detrimental to the overall security posture of any business customer. That is and should be unacceptable.
I favor regulation on this, even though it's probably not necessary in every case, simply because I don't see any other way to break this equilibrium.
I used OIDC for my internal sites to integrate with our corporate SSO provider. Why would I need to use saml instead?
SAML isn't exactly the best choice here. It's very SOAP-y; that's like being in 2005 and mandating everyone use SOAP+RPC for interopability.
I wouldn't celebrate taking those cars away from people.
As far as the older cars without those features allowing them to age out has almost entirely worked.
For the past 5+ years, the part of configuration that takes the longest - by far - is always SSO. I cannot imagine the amount of added support calls, time, and frustration brought about by it, so I can completely understand why some companies gate it behind more expensive tiers.
Nearly all specialty or line of business software, for example. These markets commonly have two or three providers and rarely have hundreds. Literally the intended purpose of copyright in this context is to give the authors market power.
And then the example given is the sympathetic one. The premise here is that there are the same number of customers willing to pay $40 as $10, and so the rational choice for a company not engaged in price discrimination is to charge $40 to everyone and price discrimination allows them to provide a "discount" to half of the customers.
Now suppose that only 10% of the customers would be willing to pay $40. The single-price profit-maximizing strategy is then to charge $10, because 100% x $10 is more than 10% x $40, and no customer benefits because all price discrimination does is allow them to overcharge the remaining 10%.
More to the point, in an actually competitive market, price discrimination isn't possible. If the marginal cost of providing the service is $7 and anyone is charging $40 to anyone, someone else could take those customers by charging $39, and someone else could take their customers by charging $25, until the market price is a thin margin over the underlying cost of providing the service. Because even the customers willing to pay $40 would prefer to pay $8, and the company that has 0.25% market share at $40 would rather have 10% market share at $8.
The better argument in favor of the "SSO tax" is the one from the comments: That SSO actually increases the cost of providing the service by raising support costs.
(1) That I assume companies never have market power.
(2) That I suppose "market power" implies monopoly
(3) That my example was cherry-picked.
1. I did no such thing. I explicitly acknowledged market power several times.
2. Again, not correct. I explicitly mentioned oligopoly (assuming that 'imperfect competition' wouldn't land).
3. Of course it was. I acknowledged as much! I quite literally said the example doesn't generalize. The example serves to illustrate a 'there exists' claim. I felt a concrete example would be easier to follow than some kind of generalized model.
Your own comment claims that "actually competitive" markets can't have price discrimination. Sure, we can suppose the law of one price applies to perfectly competitive markets, but there's no sense in which a perfectly competitive markets "actually" exist at all! The obvious observation we can make is that such competitive dynamics imply that no one would make any profit!
My appeal to the airline industry as an example was not an accident. There's a very well-established literature on the relationship between competition and discrimination in the airline business. It's *certainly* not a settled question that discrimination decreases as competition intensifies. I included a classic from Stavins below that finds precisely the opposite of your claim.
My argument here isn't perfect. I can think of many flaws, many reasonable objections. But I don't think you're using any of them here.
---- Referenced paper from Stavins: https://www.bostonfed.org/publications/research-department-w...
Your premise is that if market power exists then market power is the problem rather than price discrimination. The issue is that price discrimination isn't possible without market power. Its presence implies that the company both is capable of and is overcharging the people coerced into the higher price tier.
> That I suppose "market power" implies monopoly
This is not an argument you make explicitly, but it's something readers commonly assume and my point is to highlight that companies successfully engaged in price discrimination can and do have market power even if they don't have a full monopoly.
> Of course it was. I acknowledged as much! I quite literally said the example doesn't generalize. The example serves to illustrate a 'there exists' claim. I felt a concrete example would be easier to follow than some kind of generalized model.
And I'm providing the 'there exists' claim for the alternative, to demonstrate that price discrimination can be (and often is) detrimental to customers without providing any countervailing benefit to any of them.
> The obvious observation we can make is that such competitive dynamics imply that no one would make any profit!
Profit doesn't really work that way. For example, if a company takes investment and uses it to buy a building to operate out of, the money not paid as rent to a landlord is added to the investor's profit, but if the company takes less investment and instead pays rent, the same money is counted as operating costs. Likewise, if you develop software needed before you can start operating and you take investment to pay for it, the net returns are called profit, but if you take a bank loan to pay for it then the interest on the loan is counted as operating costs again. The interest rate you'd pay the bank would even be proportional to the risk you'd fail, unless you post collateral, for which you'd need an investor.
So a company that didn't take any investment and operated entirely by renting everything, taking loans and using off-the-shelf software instead of developing anything in-house wouldn't be expected to make any profits in a perfectly competitive market -- and there would also be no investors to pay any profits to. Profit in companies that take investment would still be present and equal the cost (time value) of the assets bought with the money, but in a perfectly competitive market this would exactly equal the risk-adjusted market rate of return in the overall capital markets.
The distinction in uncompetitive markets is that profit exceeds that amount. (Or at least can; a market can be uncompetitive and then the companies become inefficient from lack of competitive pressure and waste the money they extract from customers instead of returning it to investors.)
It's true that "perfectly" competitive markets don't exist in the same sense that perfect anything doesn't exist, but this is splitting hairs. A gold coin might be .999 gold and you can say that it isn't perfect but you can still distinguish it from a wooden nickel.