4 ms·

I'd expect this kind of regulation to kill off many of the popular web apps once and for all. The would also be open questions like whether the API must be free

I'd expect this kind of regulation to kill off many of the popular web apps once and for all. The would also be open questions like whether the API must be free to use, could have some legal freemium model, and how a "fair" price would be determined. Companies aren't going to want to be forced to provide a fully functional API. Not only would that mean a large amount of extra cost to build, test, and maintain but they are also more open to issues from hacks and bots. It's be much easier to kill their web app and tell everyone to use a mobile app instead.

mindslight 3y ago
> I'd expect this kind of regulation to kill off many of the popular web apps once and for all I wouldn't be so sure. This whole industry works on having defaults that most people just accept. It's quite easy to set up an ad blocker, and yet most people just don't. > The would also be open questions like whether the API must be free to use, could have some legal freemium model, and how a "fair" price would be determined. I phrased my proposal the way I did on purpose. There's no restrictions on what a company can charge for an account, just that "API access" is always included with it. If a company wants a freemium model, that's fine. If a company charges a subscription for all accounts, that's also fine. If a company bans an account for whatever reason, API access for that account goes away (the arbitrarity and capriciousness of bans is a separate topic though) > large amount of extra cost to build, test, and maintain but they are also more open to issues from hacks and bots This is the standard FUD about anything that's "different" or creates a modicum of requirements on companies. They're already publishing APIs for the proprietary apps to use. Nothing changes for "hacks" unless they're relying on the thinnest of obfuscation. And the whole point is that a user using a "bot" should be given the same consideration as a user using a proprietary front end - services should police user behavior rather than being lazy with method of access. > It's be much easier to kill their web app and tell everyone to use a mobile app instead. Except most "apps" are also just proprietary front ends to services hosted elsewhere, and thus run afoul of the same bundling.
- flagrant_taco 3y ago
  > I wouldn't be so sure. This whole industry works on having defaults that most people just accept. It's quite easy to set up an ad blocker, and yet most people just don't. That's totally possible, I just expect the regulation would kill many services unless the regulation is either full of loop holes or uninforced (or both) > This is the standard FUD about anything that's "different" or creates a modicum of requirements on companies. They're already publishing APIs for the proprietary apps to use. That isn't FUD, requiring API access absolutely adds to business costs and overhead. You need to document the API, test it, security audit it, etc. Sure these should be done already but they rarely are. I've seen plenty of companies that largely ignore these tasks when it's an internal API onyl, believing that shipping fast is more important and the obscurity of an undocumented API is itself a layer of security. I'd be extremely impressed to find literally any company with an internal-only API that is proepryl tested, documented, and audited. I'd be even more impressed if they worried too much about versioning and backwards compatibility beyond the scope of what it takes to update their own consuming code. There are still huge gray areas to define in anything similar to your proposal, writing laws with loose definitions and purposely building in unanswered questions is worse than having no laws at all. Is the legal requirement only related to the API surface available? Can I rate limit all unique users, even to say one request per hour, day, or year? Can I code my API in any way I deem fit, like a Soap API or one with an obfuscated API surface that runs through a random RPC protocol? Do I have to follow semantic versioning or similar? Regulations can't just be thrown together on a whim. That's how we end up with confusing laws and overpaid lawyers trying to game the system in favor of the person with more money. Laws should always be clear on what is being deemed illegal, why, and what the punishment is.
  - mindslight 3y ago
    > Is the legal requirement only related to the API surface available? Can I rate limit all unique users, even to say one request per hour, day, or year? Can I code my API in any way I deem fit, like a Soap API or one with an obfuscated API surface that runs through a random RPC protocol? Do I have to follow semantic versioning or similar? Sorry, but these "questions" are still just FUD. First, an HN comment is not expected to be a fleshed out legislative proposal, nor is HN a place for fleshing out legislative proposals. So demanding that I readily come up with some perfect implementation details right here isn't good faith discussion, but rather derailing by implying that any law would have to specify a technical implementation (which would indeed be ridiculous). In reality, these details are determined through judgements by the courts, which rubs us software people the wrong way, but does make the problem tractable. But really the crux of my original comment, which you brushed right past, is that this bundling seems straightforward afoul of the basic concepts of anti-trust. If existing laws do not suffice, a new law still doesn't actually need to specify how exactly something must be made available to the wider market, only that it is. So all of the technical details fall away - whatever technical arrangements a company uses to make its publishing service available to its own in-house app, need to be made available to the wider market. Likely whatever modern web technology they're already using. If that's SOAP then it's SOAP. If that's a bespoke protocol running on bare IP, then so be it. And if companies attempt to implement this in bad faith and continue colluding between what should be two separate business units, then they should be split up into independent entities.

mindslight 3y ago

> I'd expect this kind of regulation to kill off many of the popular web apps once and for all I wouldn't be so sure. This whole industry works on having defaults that most people just accept. It's quite easy to set up an ad blocker, and yet most people just don't. > The would also be open questions like whether the API must be free to use, could have some legal freemium model, and how a "fair" price would be determined. I phrased my proposal the way I did on purpose. There's no restrictions on what a company can charge for an account, just that "API access" is always included with it. If a company wants a freemium model, that's fine. If a company charges a subscription for all accounts, that's also fine. If a company bans an account for whatever reason, API access for that account goes away (the arbitrarity and capriciousness of bans is a separate topic though) > large amount of extra cost to build, test, and maintain but they are also more open to issues from hacks and bots This is the standard FUD about anything that's "different" or creates a modicum of requirements on companies. They're already publishing APIs for the proprietary apps to use. Nothing changes for "hacks" unless they're relying on the thinnest of obfuscation. And the whole point is that a user using a "bot" should be given the same consideration as a user using a proprietary front end - services should police user behavior rather than being lazy with method of access. > It's be much easier to kill their web app and tell everyone to use a mobile app instead. Except most "apps" are also just proprietary front ends to services hosted elsewhere, and thus run afoul of the same bundling.

flagrant_taco 3y ago
> I wouldn't be so sure. This whole industry works on having defaults that most people just accept. It's quite easy to set up an ad blocker, and yet most people just don't. That's totally possible, I just expect the regulation would kill many services unless the regulation is either full of loop holes or uninforced (or both) > This is the standard FUD about anything that's "different" or creates a modicum of requirements on companies. They're already publishing APIs for the proprietary apps to use. That isn't FUD, requiring API access absolutely adds to business costs and overhead. You need to document the API, test it, security audit it, etc. Sure these should be done already but they rarely are. I've seen plenty of companies that largely ignore these tasks when it's an internal API onyl, believing that shipping fast is more important and the obscurity of an undocumented API is itself a layer of security. I'd be extremely impressed to find literally any company with an internal-only API that is proepryl tested, documented, and audited. I'd be even more impressed if they worried too much about versioning and backwards compatibility beyond the scope of what it takes to update their own consuming code. There are still huge gray areas to define in anything similar to your proposal, writing laws with loose definitions and purposely building in unanswered questions is worse than having no laws at all. Is the legal requirement only related to the API surface available? Can I rate limit all unique users, even to say one request per hour, day, or year? Can I code my API in any way I deem fit, like a Soap API or one with an obfuscated API surface that runs through a random RPC protocol? Do I have to follow semantic versioning or similar? Regulations can't just be thrown together on a whim. That's how we end up with confusing laws and overpaid lawyers trying to game the system in favor of the person with more money. Laws should always be clear on what is being deemed illegal, why, and what the punishment is.
- mindslight 3y ago
  > Is the legal requirement only related to the API surface available? Can I rate limit all unique users, even to say one request per hour, day, or year? Can I code my API in any way I deem fit, like a Soap API or one with an obfuscated API surface that runs through a random RPC protocol? Do I have to follow semantic versioning or similar? Sorry, but these "questions" are still just FUD. First, an HN comment is not expected to be a fleshed out legislative proposal, nor is HN a place for fleshing out legislative proposals. So demanding that I readily come up with some perfect implementation details right here isn't good faith discussion, but rather derailing by implying that any law would have to specify a technical implementation (which would indeed be ridiculous). In reality, these details are determined through judgements by the courts, which rubs us software people the wrong way, but does make the problem tractable. But really the crux of my original comment, which you brushed right past, is that this bundling seems straightforward afoul of the basic concepts of anti-trust. If existing laws do not suffice, a new law still doesn't actually need to specify how exactly something must be made available to the wider market, only that it is. So all of the technical details fall away - whatever technical arrangements a company uses to make its publishing service available to its own in-house app, need to be made available to the wider market. Likely whatever modern web technology they're already using. If that's SOAP then it's SOAP. If that's a bespoke protocol running on bare IP, then so be it. And if companies attempt to implement this in bad faith and continue colluding between what should be two separate business units, then they should be split up into independent entities.