It's up to the advocates to demonstrate that it'll be cheap, not to the skeptics to demonstrate that it'll be expensive. That's the way the world works.
Of course, one solution to this problem is to make security breaches or other software failures that cause serious harm to third parties extremely expensive if they could reasonably have been avoided.
There is an old saying that if you think education is expensive, you should try ignorance. It was never truer than here. The software industry has been getting away with shipping substandard products for years, and has pulled off one of the greatest PR coups of modern times by convincing the general public and their political and business leaders that this is somehow inevitable.
Evidently it doesn't have to be this way. The inherent dangers of using languages like C and C++ to write software with a high cost of failure are widely documented in industry and routinely taught to students studying software-related fields. There is no doubt that modern languages have facilities that make writing the equivalent code objectively safer by eliminating the possibility of various classes of programmer error.
Moreover, there is no doubt that using alternative tools and methods to the mainstream programming world can result in dramatically lower failure rates, and consequently better safety, security, etc. If the software running air traffic control centres or medical devices failed as often as a typical web startup or cheap mobile app, many of us would be dead right now. We can examine the more successful software projects and make reasonable assumptions about the costs of achieving the best quality we know how to achieve in the most important situations, and again evidently this is a price that the market will bear in such cases.
At this point, the principle is established, and it is simply a matter of degree: how much damage could a failure in any given system cause, and so how much effort is justified to use better tools and methods to mitigate that risk? As long as software development businesses aren't significantly penalised regardless of the damage caused by their negligence, of course the answer to that will be "very little effort", but that is exactly why we should be starting to hold software developers working on products and services with significant risks to higher standards.
Which brings us back to the original point that plopez made...
Sorry, but I think you're either missing the point here or misunderstanding the situation.
The collection agencies provide a pragmatic way to license music legally and collect revenues, but in general they have no special status in law. In particular, this is not a compulsory licensing arrangement; rightsholders actively enter into agreements with these intermediaries to administer the licences on their behalf.
The terms those collections agencies offer for granting those licences on behalf of the rightsholders are renegotiated from time to time, and it is their job to negotiate the best deal they can on behalf of the rightsholders. There is nothing unusual about this in general business terms, nor is there any sort of extortion or other inflammatory rhetoric going on just because someone with some exclusive legal right tries to maximise its value commercially. Google's a big business. It can fight for its own corner to get a fair deal, regardless of what anyone else is doing.
My objection is when hosting services are given extra legal ammunition to fight for more than a fair deal, which is clearly the case where you've got any major hosting service well known for having infringing content uploaded by its users on a large scale but the hosting service is essentially immune to the normal legal protections for rightsholders against redistributing their content on such a large scale because of safe harbor. This distorts the bargaining positions, because the alternative for the rightsholders (or their agents) to negotiating in good faith to reach a fair deal for licensing is not to have nothing happen at all but to have their work widely pirated with the direct assistance of their negotiating partners anyway, just with little meaningful accountability.
I'm not going to get drawn into any other cases that you seem to want to introduce here. We're talking about one specific case here. Let's stick to the details of that one.
There's truth in that, certainly, but I think a lot of people make bad assumptions about how expensive and slow formal methods will or could be. The up-front cost may be higher, perhaps quite significantly so depending on your exact tools and methods. On the other hand, the cost of fixing bugs that you don't catch until much later in the development process can also be high, as can the costs of making good any resulting damage or paying compensation or fines for bugs that make it into production. In each case, "cost" can mean both time and money, and by investing in better safeguards up-front you're likely to reduce the costs of problems later. Whether the cost/benefit is favourable probably depends on the specifics of each case.
Most people have literally no idea what it would actually cost to prevent security issues and other bugs using formal methods. The average developer probably hasn't even heard of them, and I'd guess less than 5% of professionals have any substantial knowledge of the relevant tools and techniques or have ever actually used anything much beyond a type system for this purpose.
It may well be that organisations assume that the cost of prevention will be higher, but their ignorance is not an argument. (Neither is calling me names, by the way.)
Finally, your hypothetical $100K low risk vulnerability is irrelevant, given that within the past few weeks alone we have seen major security outbreaks with consequences like bringing down large parts of the NHS infrastructure in the UK, which probably cost lives and certainly caused a great deal of unnecessary suffering. Even the lower bound on the cost of security screw-ups in modern software includes people dying unnecessarily.
If there was actually a "need" for secure and expensive software the marketplace would already be providing it.
Apparently not.
It turns out that ignorance and apathy are often more powerful influences than the invisible hand. That doesn't make the costs of security breaches any less for the victims.
A much better argument against formal regulation of the software development profession is that we don't know the best way to do it yet.
We have centuries of experience building bridges, and have a pretty good idea of how to build bridges that don't fall down by accident, even under unlikely but plausible conditions like freak weather events or excessive loading because the public ignore some limit or other.
We have decades of experience building software at all, and little consensus on the best way to do it. Indeed, we don't even have a clear definition for what "best" means in this context, and it's possible that depending on the purpose of and risks associated with software, a reasonable set of good practices might look entirely different in one case from another.
Worse, the people who are most qualified to judge when we do reach that level of maturity within the industry, and to formally recognise good practices, are probably among the least likely to actually do that. They're probably too busy building good software where quality matters.
Instead, there must be an all too realistic possibility that any formal regulatory system would be dominated by the famous consultblogauthspeakers who spend a career burnishing their profile within the industry, but who in many cases have remarkably little experience actually building working software of their own, never mind working software to a very high quality standard. The very last thing we need is these fools being given any real authority over developers who are trying to do better, or $DEITY forbid, being required to give their blessing to those developers before anyone can ship anything.
That seems to be a very defeatist attitude. Formal verification doesn't need to be a huge burden. After all, we enforce many useful properties of our programs automatically all the time just by using strongly typed languages. (Obviously less so with needlessly dangerous languages like C and C++, which seems to be the fundamental point in this particular discussion.)
It's true that it might be prohibitively expensive to formally prove every conceivably useful property of every line of code using the best known methods. Indeed, just figuring out how to specify exactly what you do want to prove isn't always straightforward.
However, this isn't a black and white issue. We could do much better than we actually do in everyday software development, and the savings could be substantial. The fact that we don't use more powerful tools and more powerful methods routinely is more down to some mix of developer ignorance and hubris than anything else. Most working developers probably don't even realise what is possible or know roughly how the tools and processes work, because unfortunately this remains a relatively low profile field for now. Too many working developers would rather just play with the latest libraries that came out this week in their painting-by-numbers languages anyway, or listen to consultants who've never written a piece of critical software in their entire careers offering the false promise of good code without having to spend much time on things like proper design or documentation.
We could do so much better with even a modest investment in developer education and a willingness of management to look beyond the current quarter's accounts. Ironically, given the savings from better quality code both due to lower maintenance costs generally and particularly in areas like security or regulatory compliance where failures might also have $$$ fines attached, it might even work out cheaper in the long term to develop in a more careful, considered way. Just some robust analysis of the different possible cases and data flows and so on would probably turn up all kinds of lurking bugs in everyday software, and this is hardly beyond the abilities of an average developer if they have some awareness of what is possible.
Now, if our priority is to build throwaway web/mobile startups that can TDD an MVP in ten seconds and don't care much about long term maintenance or quality because they're going to either flip or fold the business within a year or two anyway, or if we're interested in in-house business admin systems that need to be as cheap as possible right now because it will come from someone else's budget if we have to fix any screw-ups later, none of this matters. But if we actually want to build good software, then at some point we have to start playing the long game and looking at options that aren't the quick, easy path all the time.
In that case, YouTube would still have a formal agreement to distribute the works, even if it's via the rightsholders' representative rather than directly with the rightsholder themselves. Legally this may be a slightly different relationship, but the practical implications are much the same.
What would be very different in practice is YouTube hosting the same works but uploaded by its users rather than from "official" sources, without any sort of formal agreement authorising the redistribution of those works. This is the real alternative that rightsholders are facing if they don't make a deal (directly or indirectly) with YouTube for legitimate hosting, as long as YouTube can hide behind safe harbor and just dump all the costs of YouTube-facilitated infringement on the rightsholders while obviously still benefiting from having that content available on its service. And so in reality, those rightsholders are still negotiating with a gun to their head here, and I still don't see why YouTube should get a special legal loophole that grants them that sort of commercial advantage.
The DMCA is extremely generous to hosting sites. It basically puts them above the law as far as normal responsibilities for respecting copyrights are concerned, as long as they comply with some simple conditions about takedowns. And as I mentioned before, IME they sometimes don't even comply with those very well, but still seem to benefit from the immunity anyway.
As long as YouTube is shielded by the DMCA, that can't be a winning strategy for the RIAA, even if in theory they thought it would be in their favour. In practice, they know lots of people will just put up illegal rips instead, and with YouTube effectively immune to any sort of consequences because of the safe harbor provisions, pulling the "authorised" versions would just mean losing what controls and revenue they do have. (This was one of the points mentioned in TFA.)
Surely it would be copyright infringement to redistribute those works without a licence from the rightsholders of some form, though, even if YouTube itself could avoid responsibility for the infringing acts of its users because of the safe harbor provisions in laws like the DMCA.
Given that YouTube's origins are of questionable legitimacy in terms of respecting copyrights, yet today the site is one of the biggest names in online video hosting and features revenue-generating ads, I'm still voting "live by the sword, die by the sword" on this one.
Of course, I'll vote the same way if the demands of Big Media groups like the RIAA prove to be excessive, YouTube walk away from the deal and take down the associated videos, and then it turns out that the previous deal was actually a fair market rate and instead the RIAA wind up with less in royalties than before.
On the other hand, why should YouTube benefit from widespread copyright infringement? I can understand arguments about compensation for the artists and others directly involved in the creative process vs. benefits to the general public, but YouTube is just an intermediary, even if it's a very big one.
Also, from my own professional experience, YouTube is appallingly bad at living up to even its basic obligations under the extremely generous (to hosting sites) provisions of the DMCA and its equivalents around the world. I'll have no sympathy whatsoever if they take a big hit on this one.
Disputes against fraudulent or unsatisfactory charges (advertised isn't what you got) are extremely easy here. It takes 5-10 min to login and write the email.
Unfortunately, the downside of that is that abusing the chargeback process at the expense of honest merchants is also very easy. The terms imposed on merchants for accepting credit cards (or other payment methods such as PayPal) are almost invariably heavily loaded in favour of making almost everything that goes wrong their problem. Someone's going to pay for the overheads of those fraudulent chargebacks, and it's not the fraudsters exploiting the system, and it's certainly not going to be the giants running the payment schemes. That leaves some combination of the merchants and their honest customers to pick up the tab.
The same basic argument applies, though perhaps on a different scale, to honest mistakes. For example, we had a customer a while back who challenged a charge they didn't immediately recognise. They quickly acknowledged that the original charge was legitimate when we queried the chargeback with them, but then they couldn't understand that we as the merchant weren't able to do anything about the chargeback and they had to contact their bank to cancel it themselves. They also didn't seem to understand that merchants are heavily penalised for even quite a small proportion of charges being disputed, so we were definitely going to challenge it. And they had no idea at all that it cost us probably 10x what their business was worth just to fight that one chargeback, even though we were ultimately successful in getting the charge reinstated. Some people simply have no idea of the implications of using that oh-so-easy facility.
In Slashdot's home country, there are already criminal penalties for commercial infringement of copyright on a substantial scale.
As there are in quite a few other places these days. Unfortunately, that does nothing to help someone whose creative work goes viral, as we apparently call it these days, with the result that it is widely yet still illegally shared among a network of friends, via social media or otherwise. It doesn't need to be commercial infringement to pull the bottom out from under the commercial market, and the original creator has just as little compensation themselves regardless of whether someone else was making money from supplying all those copies or not.
Unless and until we have a culture that regards exploiting someone's creative work without fair compensation as socially unacceptable, or we have real enforcement of the legal rights theoretically granted to creators in return for sharing their creations, I'm not generally in favour of compelling anyone to do anything as far as sharing or distributing their work is concerned.
Well, actually I didn't say that, or anything like it. It happens to be true anyway; none of our business models rely on selling any sort of customer data to anyone.
However, as I've pointed out, it's not even possible to do what some in this discussion seem to think happens routinely. The information typically isn't provided to payment services in that much detail, and there isn't even a mechanism to provide it with any payment service I've ever used. Even if it were possible technically, there would be immediate legal and regulatory obstacles in much of the developed world to sharing potentially sensitive information about customers without their consent. (This is part of the argument for "loyalty" schemes in big stores; read the small print in any agreement to join those schemes and notice what it says about data processing and privacy.)
This discussion would be a lot more interesting and a lot more constructive if instead of just posting crude ad hominem attacks with no substance, you could provide some concrete examples of this type of data sharing that are actually happening so we could talk about the specifics.
Interesting. Maybe the fee structure with the banks over there really is that different to everything I've come across so far. I've never run a US-based business, but what you're describing seems to be quite different to how finance is normally handled over here. I think we do have a business chequebook somewhere, but I can't remember the last time we used it for anything. And over here, I think if we deposit cash then the bank takes a cut as a percentage for their fee too these days.
If you're holding out for "all", you'll be holding out for a very long time. There is no such thing as a perfect payment system with no risk for anyone involved. There never can be, if only because someone always has control of the real money at any given point, and any other party will ultimately require some form of legal action to override that if a dispute is serious enough.
Yes, of course the finance businesses are trying to make money, but that doesn't mean they're doing it through selling potentially sensitive personal data, which was the subject being discussed here.
Which is why I wrote, in my very first comment on this thread:
That means there is some genuine risk if you're talking about people buying something from a vendor known for supplying potentially sensitive or controversial products or service.
It remains the case that no-one really has a database of everything you purchased, not even the card networks. When advocating improvements in privacy, I find it's helpful to concentrate on the demonstrable, real dangers instead of getting distracted by exaggerated or made-up ones.
What do you consider "an incredible amount of detail"?
I've just replied to probably 10 different comments in this discussion, many of them implying to varying degrees that shady things are happening and I'm [various unpleasant things] if I don't believe it, and yet not a single person anywhere that I've seen has cited any specific and verifiable example that we can discuss sensibly.
There was a lot of concern about the security of the system in the early days, some of it justified. In practice, though, the risk to the cardholder turns out to be very low. The practical issues with things like having multiple cards close together and not knowing which one has activated the sensor have mostly been overcome with design improvements. The issues of someone getting close enough to scan the card covertly are mostly non-issues, because one way or another the card issuer is likely to be on the hook for such a transaction, and then they'll go after whoever had the machine/accounts used to commit the act itself.
but what's to stop visa from saying to businesses "hey, share the details of your transactions with us, and we'll cut our fee by X?
Well, in my part of the world, the horrible data protection requirements that such an arrangement would immediately impose on both the business and the card network would surely be a significant disincentive.
Google and FB have shown how profitable consumer data actually is (whether or not that's an incredibly inflated figure is another discussion.)
But Google and FB primarily deal with data that was voluntarily provided by the data subjects (and the areas where they don't are controversial and have been subject to various legal actions). That's an entirely different situation to the sort of covert data collection and sale people are implying here about paying with the various electronic methods.
Also, FWIW, some grocery stores have done away with the loyalty programs, opting instead to track you by your card purchases (albertson's for example does this)
Again, that seems to be treading on very thin ice legally speaking in some parts of the world. In any case, if it becomes widespread, it seems likely that the card companies will start clamping down on it, since it's an incentive for people to pay some other way.
The only metadata the card companies would necessarily receive is knowing the sender and receiver of the money, and the amount and date of the transaction, which obviously they have to know in order to effect that transaction in the first place.
Selling that sort of information on without the shoppers' explicit consent would be dangerously close to huge lawsuit territory in much of the first world (and probably even more so as privacy laws finally start to catch up with modern technology, as with the new EU data protection rules that will be coming into effect in the next year or so).
Slashdot Mirror
It's up to the advocates to demonstrate that it'll be cheap, not to the skeptics to demonstrate that it'll be expensive. That's the way the world works.
Of course, one solution to this problem is to make security breaches or other software failures that cause serious harm to third parties extremely expensive if they could reasonably have been avoided.
There is an old saying that if you think education is expensive, you should try ignorance. It was never truer than here. The software industry has been getting away with shipping substandard products for years, and has pulled off one of the greatest PR coups of modern times by convincing the general public and their political and business leaders that this is somehow inevitable.
Evidently it doesn't have to be this way. The inherent dangers of using languages like C and C++ to write software with a high cost of failure are widely documented in industry and routinely taught to students studying software-related fields. There is no doubt that modern languages have facilities that make writing the equivalent code objectively safer by eliminating the possibility of various classes of programmer error.
Moreover, there is no doubt that using alternative tools and methods to the mainstream programming world can result in dramatically lower failure rates, and consequently better safety, security, etc. If the software running air traffic control centres or medical devices failed as often as a typical web startup or cheap mobile app, many of us would be dead right now. We can examine the more successful software projects and make reasonable assumptions about the costs of achieving the best quality we know how to achieve in the most important situations, and again evidently this is a price that the market will bear in such cases.
At this point, the principle is established, and it is simply a matter of degree: how much damage could a failure in any given system cause, and so how much effort is justified to use better tools and methods to mitigate that risk? As long as software development businesses aren't significantly penalised regardless of the damage caused by their negligence, of course the answer to that will be "very little effort", but that is exactly why we should be starting to hold software developers working on products and services with significant risks to higher standards.
Which brings us back to the original point that plopez made...
Sorry, but I think you're either missing the point here or misunderstanding the situation.
The collection agencies provide a pragmatic way to license music legally and collect revenues, but in general they have no special status in law. In particular, this is not a compulsory licensing arrangement; rightsholders actively enter into agreements with these intermediaries to administer the licences on their behalf.
The terms those collections agencies offer for granting those licences on behalf of the rightsholders are renegotiated from time to time, and it is their job to negotiate the best deal they can on behalf of the rightsholders. There is nothing unusual about this in general business terms, nor is there any sort of extortion or other inflammatory rhetoric going on just because someone with some exclusive legal right tries to maximise its value commercially. Google's a big business. It can fight for its own corner to get a fair deal, regardless of what anyone else is doing.
My objection is when hosting services are given extra legal ammunition to fight for more than a fair deal, which is clearly the case where you've got any major hosting service well known for having infringing content uploaded by its users on a large scale but the hosting service is essentially immune to the normal legal protections for rightsholders against redistributing their content on such a large scale because of safe harbor. This distorts the bargaining positions, because the alternative for the rightsholders (or their agents) to negotiating in good faith to reach a fair deal for licensing is not to have nothing happen at all but to have their work widely pirated with the direct assistance of their negotiating partners anyway, just with little meaningful accountability.
I'm not going to get drawn into any other cases that you seem to want to introduce here. We're talking about one specific case here. Let's stick to the details of that one.
There's truth in that, certainly, but I think a lot of people make bad assumptions about how expensive and slow formal methods will or could be. The up-front cost may be higher, perhaps quite significantly so depending on your exact tools and methods. On the other hand, the cost of fixing bugs that you don't catch until much later in the development process can also be high, as can the costs of making good any resulting damage or paying compensation or fines for bugs that make it into production. In each case, "cost" can mean both time and money, and by investing in better safeguards up-front you're likely to reduce the costs of problems later. Whether the cost/benefit is favourable probably depends on the specifics of each case.
Most people have literally no idea what it would actually cost to prevent security issues and other bugs using formal methods. The average developer probably hasn't even heard of them, and I'd guess less than 5% of professionals have any substantial knowledge of the relevant tools and techniques or have ever actually used anything much beyond a type system for this purpose.
It may well be that organisations assume that the cost of prevention will be higher, but their ignorance is not an argument. (Neither is calling me names, by the way.)
Finally, your hypothetical $100K low risk vulnerability is irrelevant, given that within the past few weeks alone we have seen major security outbreaks with consequences like bringing down large parts of the NHS infrastructure in the UK, which probably cost lives and certainly caused a great deal of unnecessary suffering. Even the lower bound on the cost of security screw-ups in modern software includes people dying unnecessarily.
If there was actually a "need" for secure and expensive software the marketplace would already be providing it.
Apparently not.
It turns out that ignorance and apathy are often more powerful influences than the invisible hand. That doesn't make the costs of security breaches any less for the victims.
A much better argument against formal regulation of the software development profession is that we don't know the best way to do it yet.
We have centuries of experience building bridges, and have a pretty good idea of how to build bridges that don't fall down by accident, even under unlikely but plausible conditions like freak weather events or excessive loading because the public ignore some limit or other.
We have decades of experience building software at all, and little consensus on the best way to do it. Indeed, we don't even have a clear definition for what "best" means in this context, and it's possible that depending on the purpose of and risks associated with software, a reasonable set of good practices might look entirely different in one case from another.
Worse, the people who are most qualified to judge when we do reach that level of maturity within the industry, and to formally recognise good practices, are probably among the least likely to actually do that. They're probably too busy building good software where quality matters.
Instead, there must be an all too realistic possibility that any formal regulatory system would be dominated by the famous consultblogauthspeakers who spend a career burnishing their profile within the industry, but who in many cases have remarkably little experience actually building working software of their own, never mind working software to a very high quality standard. The very last thing we need is these fools being given any real authority over developers who are trying to do better, or $DEITY forbid, being required to give their blessing to those developers before anyone can ship anything.
That seems to be a very defeatist attitude. Formal verification doesn't need to be a huge burden. After all, we enforce many useful properties of our programs automatically all the time just by using strongly typed languages. (Obviously less so with needlessly dangerous languages like C and C++, which seems to be the fundamental point in this particular discussion.)
It's true that it might be prohibitively expensive to formally prove every conceivably useful property of every line of code using the best known methods. Indeed, just figuring out how to specify exactly what you do want to prove isn't always straightforward.
However, this isn't a black and white issue. We could do much better than we actually do in everyday software development, and the savings could be substantial. The fact that we don't use more powerful tools and more powerful methods routinely is more down to some mix of developer ignorance and hubris than anything else. Most working developers probably don't even realise what is possible or know roughly how the tools and processes work, because unfortunately this remains a relatively low profile field for now. Too many working developers would rather just play with the latest libraries that came out this week in their painting-by-numbers languages anyway, or listen to consultants who've never written a piece of critical software in their entire careers offering the false promise of good code without having to spend much time on things like proper design or documentation.
We could do so much better with even a modest investment in developer education and a willingness of management to look beyond the current quarter's accounts. Ironically, given the savings from better quality code both due to lower maintenance costs generally and particularly in areas like security or regulatory compliance where failures might also have $$$ fines attached, it might even work out cheaper in the long term to develop in a more careful, considered way. Just some robust analysis of the different possible cases and data flows and so on would probably turn up all kinds of lurking bugs in everyday software, and this is hardly beyond the abilities of an average developer if they have some awareness of what is possible.
Now, if our priority is to build throwaway web/mobile startups that can TDD an MVP in ten seconds and don't care much about long term maintenance or quality because they're going to either flip or fold the business within a year or two anyway, or if we're interested in in-house business admin systems that need to be as cheap as possible right now because it will come from someone else's budget if we have to fix any screw-ups later, none of this matters. But if we actually want to build good software, then at some point we have to start playing the long game and looking at options that aren't the quick, easy path all the time.
In that case, YouTube would still have a formal agreement to distribute the works, even if it's via the rightsholders' representative rather than directly with the rightsholder themselves. Legally this may be a slightly different relationship, but the practical implications are much the same.
What would be very different in practice is YouTube hosting the same works but uploaded by its users rather than from "official" sources, without any sort of formal agreement authorising the redistribution of those works. This is the real alternative that rightsholders are facing if they don't make a deal (directly or indirectly) with YouTube for legitimate hosting, as long as YouTube can hide behind safe harbor and just dump all the costs of YouTube-facilitated infringement on the rightsholders while obviously still benefiting from having that content available on its service. And so in reality, those rightsholders are still negotiating with a gun to their head here, and I still don't see why YouTube should get a special legal loophole that grants them that sort of commercial advantage.
The DMCA is extremely generous to hosting sites. It basically puts them above the law as far as normal responsibilities for respecting copyrights are concerned, as long as they comply with some simple conditions about takedowns. And as I mentioned before, IME they sometimes don't even comply with those very well, but still seem to benefit from the immunity anyway.
As long as YouTube is shielded by the DMCA, that can't be a winning strategy for the RIAA, even if in theory they thought it would be in their favour. In practice, they know lots of people will just put up illegal rips instead, and with YouTube effectively immune to any sort of consequences because of the safe harbor provisions, pulling the "authorised" versions would just mean losing what controls and revenue they do have. (This was one of the points mentioned in TFA.)
Surely it would be copyright infringement to redistribute those works without a licence from the rightsholders of some form, though, even if YouTube itself could avoid responsibility for the infringing acts of its users because of the safe harbor provisions in laws like the DMCA.
Given that YouTube's origins are of questionable legitimacy in terms of respecting copyrights, yet today the site is one of the biggest names in online video hosting and features revenue-generating ads, I'm still voting "live by the sword, die by the sword" on this one.
Of course, I'll vote the same way if the demands of Big Media groups like the RIAA prove to be excessive, YouTube walk away from the deal and take down the associated videos, and then it turns out that the previous deal was actually a fair market rate and instead the RIAA wind up with less in royalties than before.
On the other hand, why should YouTube benefit from widespread copyright infringement? I can understand arguments about compensation for the artists and others directly involved in the creative process vs. benefits to the general public, but YouTube is just an intermediary, even if it's a very big one.
Also, from my own professional experience, YouTube is appallingly bad at living up to even its basic obligations under the extremely generous (to hosting sites) provisions of the DMCA and its equivalents around the world. I'll have no sympathy whatsoever if they take a big hit on this one.
Disputes against fraudulent or unsatisfactory charges (advertised isn't what you got) are extremely easy here. It takes 5-10 min to login and write the email.
Unfortunately, the downside of that is that abusing the chargeback process at the expense of honest merchants is also very easy. The terms imposed on merchants for accepting credit cards (or other payment methods such as PayPal) are almost invariably heavily loaded in favour of making almost everything that goes wrong their problem. Someone's going to pay for the overheads of those fraudulent chargebacks, and it's not the fraudsters exploiting the system, and it's certainly not going to be the giants running the payment schemes. That leaves some combination of the merchants and their honest customers to pick up the tab.
The same basic argument applies, though perhaps on a different scale, to honest mistakes. For example, we had a customer a while back who challenged a charge they didn't immediately recognise. They quickly acknowledged that the original charge was legitimate when we queried the chargeback with them, but then they couldn't understand that we as the merchant weren't able to do anything about the chargeback and they had to contact their bank to cancel it themselves. They also didn't seem to understand that merchants are heavily penalised for even quite a small proportion of charges being disputed, so we were definitely going to challenge it. And they had no idea at all that it cost us probably 10x what their business was worth just to fight that one chargeback, even though we were ultimately successful in getting the charge reinstated. Some people simply have no idea of the implications of using that oh-so-easy facility.
In Slashdot's home country, there are already criminal penalties for commercial infringement of copyright on a substantial scale.
As there are in quite a few other places these days. Unfortunately, that does nothing to help someone whose creative work goes viral, as we apparently call it these days, with the result that it is widely yet still illegally shared among a network of friends, via social media or otherwise. It doesn't need to be commercial infringement to pull the bottom out from under the commercial market, and the original creator has just as little compensation themselves regardless of whether someone else was making money from supplying all those copies or not.
Unless and until we have a culture that regards exploiting someone's creative work without fair compensation as socially unacceptable, or we have real enforcement of the legal rights theoretically granted to creators in return for sharing their creations, I'm not generally in favour of compelling anyone to do anything as far as sharing or distributing their work is concerned.
Well, actually I didn't say that, or anything like it. It happens to be true anyway; none of our business models rely on selling any sort of customer data to anyone.
However, as I've pointed out, it's not even possible to do what some in this discussion seem to think happens routinely. The information typically isn't provided to payment services in that much detail, and there isn't even a mechanism to provide it with any payment service I've ever used. Even if it were possible technically, there would be immediate legal and regulatory obstacles in much of the developed world to sharing potentially sensitive information about customers without their consent. (This is part of the argument for "loyalty" schemes in big stores; read the small print in any agreement to join those schemes and notice what it says about data processing and privacy.)
This discussion would be a lot more interesting and a lot more constructive if instead of just posting crude ad hominem attacks with no substance, you could provide some concrete examples of this type of data sharing that are actually happening so we could talk about the specifics.
Interesting. Maybe the fee structure with the banks over there really is that different to everything I've come across so far. I've never run a US-based business, but what you're describing seems to be quite different to how finance is normally handled over here. I think we do have a business chequebook somewhere, but I can't remember the last time we used it for anything. And over here, I think if we deposit cash then the bank takes a cut as a percentage for their fee too these days.
If you're holding out for "all", you'll be holding out for a very long time. There is no such thing as a perfect payment system with no risk for anyone involved. There never can be, if only because someone always has control of the real money at any given point, and any other party will ultimately require some form of legal action to override that if a dispute is serious enough.
Yes, of course the finance businesses are trying to make money, but that doesn't mean they're doing it through selling potentially sensitive personal data, which was the subject being discussed here.
Which is why I wrote, in my very first comment on this thread:
That means there is some genuine risk if you're talking about people buying something from a vendor known for supplying potentially sensitive or controversial products or service.
It remains the case that no-one really has a database of everything you purchased, not even the card networks. When advocating improvements in privacy, I find it's helpful to concentrate on the demonstrable, real dangers instead of getting distracted by exaggerated or made-up ones.
What do you consider "an incredible amount of detail"?
I've just replied to probably 10 different comments in this discussion, many of them implying to varying degrees that shady things are happening and I'm [various unpleasant things] if I don't believe it, and yet not a single person anywhere that I've seen has cited any specific and verifiable example that we can discuss sensibly.
There was a lot of concern about the security of the system in the early days, some of it justified. In practice, though, the risk to the cardholder turns out to be very low. The practical issues with things like having multiple cards close together and not knowing which one has activated the sensor have mostly been overcome with design improvements. The issues of someone getting close enough to scan the card covertly are mostly non-issues, because one way or another the card issuer is likely to be on the hook for such a transaction, and then they'll go after whoever had the machine/accounts used to commit the act itself.
but what's to stop visa from saying to businesses "hey, share the details of your transactions with us, and we'll cut our fee by X?
Well, in my part of the world, the horrible data protection requirements that such an arrangement would immediately impose on both the business and the card network would surely be a significant disincentive.
Google and FB have shown how profitable consumer data actually is (whether or not that's an incredibly inflated figure is another discussion.)
But Google and FB primarily deal with data that was voluntarily provided by the data subjects (and the areas where they don't are controversial and have been subject to various legal actions). That's an entirely different situation to the sort of covert data collection and sale people are implying here about paying with the various electronic methods.
Also, FWIW, some grocery stores have done away with the loyalty programs, opting instead to track you by your card purchases (albertson's for example does this)
Again, that seems to be treading on very thin ice legally speaking in some parts of the world. In any case, if it becomes widespread, it seems likely that the card companies will start clamping down on it, since it's an incentive for people to pay some other way.
People keep making these vague assertions about some data being sold by someone to someone.
Identify a specific case where this is happening and we can verify the relevant details, and we can talk intelligently about the issue.
The only metadata the card companies would necessarily receive is knowing the sender and receiver of the money, and the amount and date of the transaction, which obviously they have to know in order to effect that transaction in the first place.
Selling that sort of information on without the shoppers' explicit consent would be dangerously close to huge lawsuit territory in much of the first world (and probably even more so as privacy laws finally start to catch up with modern technology, as with the new EU data protection rules that will be coming into effect in the next year or so).
What financial service makes its money by knowing exactly what was purchased by those using it and selling on that data?