2 ms·

You're assuming quite a lot about me and not actually responding very directy to what I'm saying. However, reading this and some of your other responses makes i

by grncdr 5y ago

You're assuming quite a lot about me and not actually responding very directy to what I'm saying. However, reading this and some of your other responses makes it a bit more clear what the concern you're raising is. > Listen, you know and I know that you can serve a personal website perfectly well with /var/www and a stock Apache config. But the proposal we're discussing here is precisely to take that judgment call away from people like you and me and give it to people like Donald Trump. Let's revisit that proposal: > 1. defining legal liability for bad code in a commercial product > 2. making [website operators] legally liable for any and all leaks of our personal records that a jury can be persuaded were unnecessarily collected I believe we both agree that neither of these technically apply to the personal website scenario (static hosting not collecting any PII). So your argument as I understand it is: in order to make the above liabilities legally enforcable for scenarios where they do make sense, we will end up with regulations similar to those for handling "sensitive" data (such as financial/medical information) being imposed on _all_ software / online services (such as basic static websites). This will happen because laws will be written in an environment of near-total regulatory capture. This argument is plausible, but it relies on a bit of a non-sequitur: expanding the scope of data collection/handling regulations will inevitably extend to regulating the publishing of software. It might be in the interest of the current software behemoths to push for such a system, but I don't really see it. They derive too much economic value from the current "free as in lunch" open-source to shoot themselves in the feet like that. It seems more likely they would: 1. try and narrow the scope of their own liability (by heavily constraining which categories of software carry that burden) 2. try to minimize the costs to themselves (by demanding compensation from governments for the work required to meet those regulations) 3. try to offload liability to vendors (who can then demand compensation for taking on that liability). Points 2 and 3 could be a large cash cow for free and open source software, though I doubt many will be able to successfully capitalize on it.

kragen 5y ago
I wasn't responding directly to what you said because it's irrelevant. You were pointing out that in fact hosting a personal website doesn't in fact expose its visitors to a lot of risk, especially if it's a static site instead of a blog or something. But that doesn't imply that people hosting their own personal websites will find it easy to comply with a regulatory regime tailored to raising the barriers to entry for "the next Facebook". More likely they will find it infeasible. It's true that imposing liability for publishing defective software is logically independent from imposing liability for collecting unnecessary PII that leaks. But pjmlp's quote from the article we were commenting on explicitly proposed doing both of these: > For example, if you want to see Microsoft have a heart attack, talk about the idea of defining legal liability for bad code in a commercial product. If you want to give Facebook nightmares, talk about the idea of making it legally liable for any and all leaks of our personal records that a jury can be persuaded were unnecessarily collected. So my argument does not, as you say, "rely on a bit of a non-sequitur: [that] expanding the scope of data collection/handling regulations will inevitably extend to regulating the publishing of software." The proposal in question is to both regulate software publishing and also regulate data handling, so it's irrelevant whether or not the scope would thus "inevitably extend" from one to the other. Probably it is true that the most favorable situation for the current incumbents would be to have no liability, as at present, or as minimal liability as they can get away with. But the second-most-favorable situation, and one that is definitely politically viable even if the current situation is not, would be to have a regulatory regime that raises the barriers to entry for new entrants as much as possible and prevents disruption to their markets, by enshrining in law the particular way they're doing business today: AI melody recognition for prior restraint of free speech, combined with armies of outsourced moderators to watch for terrorism and pornography, centrally-controlled app-store platforms, locked-down end-user hardware (with a grandfathered carve-out for desktops and laptops), real-name policies, fax-us-your-passport ID verification, "two-factor" authentication that turns out to be one-factor, and so on. Anything that encourages you to post stuff on your own blog or website would be a big drawback for GitHub, YouTube, and Fecebutt.

by grncdr 5y ago

kragen 5y ago

I wasn't responding directly to what you said because it's irrelevant. You were pointing out that in fact hosting a personal website doesn't in fact expose its visitors to a lot of risk, especially if it's a static site instead of a blog or something. But that doesn't imply that people hosting their own personal websites will find it easy to comply with a regulatory regime tailored to raising the barriers to entry for "the next Facebook". More likely they will find it infeasible. It's true that imposing liability for publishing defective software is logically independent from imposing liability for collecting unnecessary PII that leaks. But pjmlp's quote from the article we were commenting on explicitly proposed doing both of these: > For example, if you want to see Microsoft have a heart attack, talk about the idea of defining legal liability for bad code in a commercial product. If you want to give Facebook nightmares, talk about the idea of making it legally liable for any and all leaks of our personal records that a jury can be persuaded were unnecessarily collected. So my argument does not, as you say, "rely on a bit of a non-sequitur: [that] expanding the scope of data collection/handling regulations will inevitably extend to regulating the publishing of software." The proposal in question is to both regulate software publishing and also regulate data handling, so it's irrelevant whether or not the scope would thus "inevitably extend" from one to the other. Probably it is true that the most favorable situation for the current incumbents would be to have no liability, as at present, or as minimal liability as they can get away with. But the second-most-favorable situation, and one that is definitely politically viable even if the current situation is not, would be to have a regulatory regime that raises the barriers to entry for new entrants as much as possible and prevents disruption to their markets, by enshrining in law the particular way they're doing business today: AI melody recognition for prior restraint of free speech, combined with armies of outsourced moderators to watch for terrorism and pornography, centrally-controlled app-store platforms, locked-down end-user hardware (with a grandfathered carve-out for desktops and laptops), real-name policies, fax-us-your-passport ID verification, "two-factor" authentication that turns out to be one-factor, and so on. Anything that encourages you to post stuff on your own blog or website would be a big drawback for GitHub, YouTube, and Fecebutt.