Talk:Pirate decryption

message: The changes to the article by @Notwillywanka were reverted because the number of clients on a card sharing network is limited  by a number of practical considerations. The most obvious limitation is that the card clients have to have a receiver capable of using the key stream. There is a limit to the number of possible receivers or clients on a card sharing network due to the latency of the network (the time taken for the data from the server to travel to the receiver) and the period between the updated keys. If the latency is greater than the period between the updated keys, the receiver/decoder (IRD) will miss a key and the signal may become encoded again. The decrypted key has to arrive within a specific timeframe and if the latency causes it to miss that window, the IRD will lose lock and stop decoding the signal. With large ISP networks, it may work well but on high-latency or poor connections, it will not be as effective and the signal on the IRD will stop being decoded if it misses too many keys. A related factor is that as the size of the card sharing network grows, the probability of detection increases. If the number of card clients on the card sharing network is high enough, then the Pay TV providers or law enforcement agencies may identify the network and neutralise it (either by identifying the cards being shared, or by identifying the operator and customers and taking legal action). Thus it is often in the best interests of the card sharing network operator to limit the number of clients on one card sharing network. In theory, one card can run a country's decoders however the real work practicalities make that difficult. Jmccormac (talk) 01:14, 15 February 2014 (UTC)
replies: text: the limitations listed above do not affect the number of potential "subscribers". Just like a. Radio station can transmit to an unlimited number of radios, a card sharing system can broadcast to an unlimited number of authorized receivers. It is not like viewing a web page, where each viewer has to open a connection and then wait for a response, where timing is an issue, but it is a constant stream that the authorized receiver listens. Into for the key. No limit as to how many can listen in, therefore unlimited. Bandwidth, latency, are factors in setup, and costs, but are all able to be easily overcome, limits are chosen by operators, not imposed by any ability.  — Preceding unsigned comment added by Notwillywanka (talk • contribs) 23:06, 15 February 2014 (UTC)
replies: text: There is no finite number of radios that can be used, or made, no limit exists, the fact that there is a finite number of radios in existence does not limit the potential number of radios that can receive a signal. There is no upper limit to how many receivers are capable of receiving the key stream, every new receiver that is built can receive the stream, just like every new radio built is able to receive the radio signal, regardless of how many already are receiving the same signal.  — Preceding unsigned comment added by Notwillywanka (talk • contribs) 16:38, 17 February 2014 (UTC)

text: Real, easy, there is no actual limit as to how many CAN use. The number in existence is not a limit. Do some simple research, take time to think about it, just because there are a finite number of things at the moment, it does not limit the possible number that can exist. You seem to be confusing unicast with multicast. Unicast sends a seprate copy to each device, multicast sends one copy that ANY subscribed device CAN listen in to, NO UPPER LIMIT as each device just listens in, regardless of how many devices exist or not, more devices CAN be added, created, removed, but there is NO LIMIT. — Preceding unsigned comment added by Notwillywanka (talk • contribs) 18:20, 17 February 2014 (UTC)

text: I'm sorry, I don't understand? You are the one spouting on and on about how there is a limit, yet your own explanations give the exact opposite point. I am not pointing out any "opinion", like yourself, but making factual points about the system. What research I have or have not done, what my experience is or is not is not up for debate. The facts are, there is no upper limit to as how many receivers CAN receive the decryption key. The fact that there is a finite number of receivers in existence, does not mean that more receivers can not be made and added to a card sharing system, the two facts are independent of each other.  We are not talking about a "10 gallon bucket" that can only have "10 gallons" of liquid in it, we are talking about a system that has "X" number of receivers on it, one additional receiver added will also work, therefore the new "limit" is X+1. Instead of using bad reason logic, and pushing your view, take a moment and look at the problem you are creating. I've tried to use a simple comparison for you to understand, yet you take a complete different fact, irrelevant to the subject, and apply it's logical fallacy to support your incorrect statement.
You obviously don't seem to understand the part simple mathematics plays in this hack and  you just don't understand the concept of how the number of devices capable of utilising the key stream dictates the maximum number of clients in a card sharing network at any given time. You seem to be approaching this from a non-technical Arts point of view rather than a technological one. It is not simply a question of semantics. The maximum number of devices capable of using the key stream is finite and this finite value at any given time determines the maximum number of clients in a card sharing network. The number changes as old devices fail or are switched off and new devices become available. However it is not an unlimited number of devices at any given and neither is there an infinite number of viewers.  You are merely trying to impose your opinion as fact and your opinion is wrong. Jmccormac (talk) 21:34, 17 February 2014 (UTC)
thread_title: Limitations of Internet Card Sharing

message: This is the problem section with the section on limits modified:
::: The limiting factors in the number of possible remotely located satellite receivers are the network latency, the period between the updated keys and the ability of the card client's receiver to use the decrypted key stream. The theoretical maximum number of clients, at any given time, in a card sharing network is limited to the number of client devices, typically Integrated Receiver-Decoders, capable of using that key stream to decode the encrypted satellite TV signal.
'''
:::Each receiver is configured in an identical manner, a clone receiving the same television signal from a satellite and, from the internet server, the same decryption keys to unlock that signal. As the server must have individually subscribed smart cards for each channel to be viewed, its continued operation tends to be costly and may require multiple subscriptions under different names and addresses. There is also a risk that as the number of card clients on the card sharing network grows, it will attract the attention of the satellite TV service provider and law enforcement agencies and the monitoring of IP addresses associated with this card sharing network may identify individual users and server operators who then become targets for legal action by the satellite TV service provider or by legal authorities.
The first section now reflects the reality of a card sharing network. As there is a card sharing article, it might be unnecessary duplication of information and the brief pointer might be sufficient for this article. Jmccormac (talk) 19:03, 17 February 2014 (UTC)
replies: text: Wouldn't that still run into the problem where the only detailed sources of technical background info for much of this were online message forums, which would normally not meet WP:RS and which tend to appear and disappear rather frequently? The article is rubbish, but there are no good sources to repair it. K7L (talk) 01:46, 3 January 2015 (UTC)
replies: text:  There are some patents (NDS/News Datacom) and academic papers that actually cover countermeasures and state the concept of card sharing. Jmccormac (talk) 08:54, 3 January 2015 (UTC)
thread_title:  Moving problem section to talk for editing discussion 

message: There's a lot of overlap between this article and Smart card piracy. 
Lunchboxhero 19:57, 4 September 2007 (UTC)
thread_title: Merger Proposal

message: I'm disputing the neutrality of this section due weasel words, and the following passages:
"In theory the system was an ideal solution" Ideal how, and in in whose opinion?
"In some cases, fraudulent cloning has been used..." This references a non-existing article and gives no explanation of what makes the cloning fraudulent.
Also:
"A scheme ... has been widely promoted by some unscrupulous individuals as a means of disabling communication of billing information for pay-per-view programming but this device is effectively worthless..."
I see no reason why the unnamed individuals should be described as unscrupulous, or why the described device should be labeled as effectively worthless, except for the author to express value judgements. I recommend identifying the individuals referred to, refrain from describing them as unscrupulous, and factually describing the technical shortcomings of the device.Bigpinksocks (talk) 16:52, 2 December 2012 (UTC)
thread_title: NPOV dispute - Technical issues