3 ms·
> 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
by 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.