4 ms·
Regulations on data exports doesn't solve this problem at all, it just means an endless goose chase of exporting and importing. Additionally, we open people up
by gochi 3y ago
Regulations on data exports doesn't solve this problem at all, it just means an endless goose chase of exporting and importing. Additionally, we open people up to even larger data leaks if the entire export and import path isn't regulated. We already have a problem with this in regards to switching password managers.
Regulations on what data can even be collected will solve this problem, and negate the entire reason for using these front ends.
- mindslight 3y agoAgreed that we desperately need privacy legislation that makes surveillance-based software much less prevalent. In addition, stopping this bundling of proprietary javascript clients with service hosting seems like straightforward antitrust action that doesn't even need any new legislation. Any action that a user can do through a web browser should be required to be made available as an API for programmatic access.
- flagrant_taco 3y agoI'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.
- coldacid 3y agoRegulations? Legislation? None of that means anything in this age of "it's only wrong/illegal if you get caught". What's needed is to kick these shitty anti-user services to the curb, and switch wholesale to ones that actually care about user agency, security, and privacy.
- mindslight 3y agoI agree with where you're coming from with the approach of users needing to kick shitty anti-user services to the curb. But I'd say why not both? It doesn't need to be an either-or. Legislation sets normative behavior, even if it is not enforced fully or companies find loopholes. It is simply not right for a free society to have surveillance databases that would make the most staunch Stasi agent blush, and we should work towards the goal of ending them by every avenue possible. Also how do you propose to kick say Equifax to the curb through individual action? There are many services that don't exist via user consent or interaction, but rather just by purported assent through contracts of adhesion from some de facto mandatory industry.
- klardotsh 3y agoI alluded to this on Mastodon recently [1], and I strongly agree. Here's a copy of the toots: --- Thought that just crossed my mind: what if - a law that mandated any service accessed over the web must not interfere with any attempts to develop or use third party clients? Not a software license. A law, with actual teeth and massive fines for companies (it's always companies) violating it. Discord banning folks for using Ripcord? Yeah that'll be $(insert massive fine here) per user banned. Your credit union? Sure, write your own mobile app for it. Like GDPR, but a hundred steps further. To give it proper teeth, the fines for willful infringement should be basically company-ending events, because fuck abusing users. No $1000 slap on the wrist. Nah, "up to 5% of company net profit for the year of occurrence, or $X minimum amount, whichever is higher" (to handle unprofitable VC-backed entities) or something truly fear-inducing. And no, I can't currently think of anything that should be excepted from this. If you think you can write a better GUI for the SaaS version of TurboTax and not land yourself with tax fines, go for it, dude. The law should allow you to do that, too. [1]: https://merveilles.town/@klardotsh/110749363058611919 https://merveilles.town/@klardotsh/110749363058611919
- SgtBastard 3y ago>And no, I can’t currently think of anything that should be excerpted by this You’d make it illegal to take active action against Phishing? That’s uh… bold…
- klardotsh 3y agoI'm open to hearing examples of effective phishing prevention that cannot be replicated with open APIs like this proposal - or even the counterexample, phishing attempts that rely on freedom of client choice to do. I said "currently" - this means I'm open to hearing worthwhile exceptions, but I do want to have a chance to think about those exceptions and think of how companies would abuse them to in turn abuse their users, too.