Net Neutrality

gourimoko said:

Again, that is false. There have been more than 4 violations of the net neutrality standard. I already gave you several.

You are asking me how can I reasonably present "other instances" if there is no proof that they actually occurred?

I'm putting to you the following:

1) Are you suggesting Verizon didn't block Apple Pay on it's network in 2011 (this instance, well known, is not among the 4 in the paper)?
2) If they did, will you admit you are wrong about there only being 4 proven violations of the standard?

Click to expand...

KI4MVP said:

Verizon admitted they blocked google wallet, what more proof do you need beyond their own admission of what they did?

Click to expand...

Even if the phone is easily unlocked and rooted, Verizon doesn't allow it to ship with those actions already taken. Verizon is especially strict on the issue of device security, and forces many of its OEM partners not only to lock device bootloaders, but encrypt them as well. It's part of Verizon's network security policy.

And guess what - those Block C rules have an exception (several exceptions, actually). Basically, these rules about open applications apply unless a particular app "would not be compliant with published technical standards reasonably necessary for the management or protection of the licensee's network." That's basically why Verizon is allowed to lock your bootloader and prevent you from rooting your device. No other carrier in the US is subject to these restrictions, by the way, so there's no issue for them.


If you're not familiar with how Wallet functions, it's a bit odd as an application goes. The Wallet app isn't the only "piece" necessary to get the Wallet service functioning, there are two other parts of the equation. One you're already familiar with: NFC (near-field communication). It's a simple, open wireless standard that transmits data over very short distances. In Wallet's case, it transmits payment data. But there's a third wheel in play that many people aren't aware of, and it's called a "secure element." Without getting too technical (eg, into things I don't at all understand), the secure element's job is to store encrypted credentials (your payment info) and tell the Wallet app "hey, these are the credentials you need to transmit to the payment terminal."

Only one card's credentials are stored on the element at a given time (obvious security reasons), which is why you need an internet connection if you want to switch your active card in Wallet. When you sign in to Wallet or change cards, the Wallet app calls up to the Google server, pulls down your credentials for a particular card, and then writes them to the secure element.

But one does not simply write to the secure element (... or walk into Mordor), it requires special permissions. Google Wallet is doing something few apps do - asking for direct, exclusive access to a secure piece of hardware in the phone. Not only that, once Google takes over the secure element, it wants total control. Because of the security concerns (and related technical difficulties) involved in sharing a secure element, Wallet and only Wallet is able to utilize the internal secure element on a Wallet-enabled device. That means Google is directly managing every layer of the process.

And guess what: Verizon wasn't OK with this. It really has nothing at all to do with Block C rules or apps - this is a fight over who gets to control the internal secure element. This isn't about letting consumers run the software they want, it's about letting Google run the software and control the hardware it wants.




http://www.androidpolice.com/2013/0...why-the-carrier-is-still-allowed-to-block-it/

Triplethreat said:

Even if the phone is easily unlocked and rooted, Verizon doesn't allow it to ship with those actions already taken. Verizon is especially strict on the issue of device security, and forces many of its OEM partners not only to lock device bootloaders, but encrypt them as well. It's part of Verizon's network security policy.

And guess what - those Block C rules have an exception (several exceptions, actually). Basically, these rules about open applications apply unless a particular app "would not be compliant with published technical standards reasonably necessary for the management or protection of the licensee's network." That's basically why Verizon is allowed to lock your bootloader and prevent you from rooting your device. No other carrier in the US is subject to these restrictions, by the way, so there's no issue for them.


If you're not familiar with how Wallet functions, it's a bit odd as an application goes. The Wallet app isn't the only "piece" necessary to get the Wallet service functioning, there are two other parts of the equation. One you're already familiar with: NFC (near-field communication). It's a simple, open wireless standard that transmits data over very short distances. In Wallet's case, it transmits payment data. But there's a third wheel in play that many people aren't aware of, and it's called a "secure element." Without getting too technical (eg, into things I don't at all understand), the secure element's job is to store encrypted credentials (your payment info) and tell the Wallet app "hey, these are the credentials you need to transmit to the payment terminal."

Only one card's credentials are stored on the element at a given time (obvious security reasons), which is why you need an internet connection if you want to switch your active card in Wallet. When you sign in to Wallet or change cards, the Wallet app calls up to the Google server, pulls down your credentials for a particular card, and then writes them to the secure element.

But one does not simply write to the secure element (... or walk into Mordor), it requires special permissions. Google Wallet is doing something few apps do - asking for direct, exclusive access to a secure piece of hardware in the phone. Not only that, once Google takes over the secure element, it wants total control. Because of the security concerns (and related technical difficulties) involved in sharing a secure element, Wallet and only Wallet is able to utilize the internal secure element on a Wallet-enabled device. That means Google is directly managing every layer of the process.

And guess what: Verizon wasn't OK with this. It really has nothing at all to do with Block C rules or apps - this is a fight over who gets to control the internal secure element. This isn't about letting consumers run the software they want, it's about letting Google run the software and control the hardware it wants.




http://www.androidpolice.com/2013/0...why-the-carrier-is-still-allowed-to-block-it/

Click to expand...

Did you really just say you didn't want to get too technical for me and @gourimoko? seriously? Since I'm packing, I'll let @gourimoko respond to the rest.

I will add, though, that the phones absolutely are not Verizon's. And it's 100% certain that the only way they can block Google Wallet from running on android phones is to violate net neutrality.

KI4MVP said:

Did you really just say you didn't want to get too technical for me and @gourimoko? seriously? Since I'm packing, I'll let @gourimoko respond to the rest.

Click to expand...

I mean it's clear you don't even understand how the FCC works.

Seeing that you think ISP's can now do literally whatever they want. So if you don't understand the fact that there is still FCC violations that they take care of, how can you even suggest you're informed on the topic in the slightest, and push your agenda on the rest?

It's like reading the first 1/4 of a book and then giving a full report on it from start to finish.

Triplethreat said:

I mean it's clear you don't even understand how the FCC works.

Seeing that you think ISP's can now do literally whatever they want. So if you don't understand the fact that there is still FCC violations that they take care of, how can you even suggest you're informed on the topic in the slightest, and push your agenda on the rest?

It's like reading the first 1/4 of a book and then giving a full report on it from start to finish.

Click to expand...

What @KI4MVP is saying is that, so long as the ISP advises its consumers in a disclosure (which, many of them already did prior to net neutrality); then, they can arbitrarily decide which traffic to block, which to throttle, and which to "accelerate."

In the context of "net neutrality," that means they are free to do whatever they want with the traffic, even if it means it doesn't get delivered; so long as they tell you in a disclosure, ahead of time, that they might do this.

Triplethreat said:

Even if the phone is easily unlocked and rooted, Verizon doesn't allow it to ship with those actions already taken. Verizon is especially strict on the issue of device security, and forces many of its OEM partners not only to lock device bootloaders, but encrypt them as well. It's part of Verizon's network security policy.

And guess what - those Block C rules have an exception (several exceptions, actually). Basically, these rules about open applications apply unless a particular app "would not be compliant with published technical standards reasonably necessary for the management or protection of the licensee's network." That's basically why Verizon is allowed to lock your bootloader and prevent you from rooting your device. No other carrier in the US is subject to these restrictions, by the way, so there's no issue for them.


If you're not familiar with how Wallet functions, it's a bit odd as an application goes. The Wallet app isn't the only "piece" necessary to get the Wallet service functioning, there are two other parts of the equation. One you're already familiar with: NFC (near-field communication). It's a simple, open wireless standard that transmits data over very short distances. In Wallet's case, it transmits payment data. But there's a third wheel in play that many people aren't aware of, and it's called a "secure element." Without getting too technical (eg, into things I don't at all understand), the secure element's job is to store encrypted credentials (your payment info) and tell the Wallet app "hey, these are the credentials you need to transmit to the payment terminal."

Only one card's credentials are stored on the element at a given time (obvious security reasons), which is why you need an internet connection if you want to switch your active card in Wallet. When you sign in to Wallet or change cards, the Wallet app calls up to the Google server, pulls down your credentials for a particular card, and then writes them to the secure element.

But one does not simply write to the secure element (... or walk into Mordor), it requires special permissions. Google Wallet is doing something few apps do - asking for direct, exclusive access to a secure piece of hardware in the phone. Not only that, once Google takes over the secure element, it wants total control. Because of the security concerns (and related technical difficulties) involved in sharing a secure element, Wallet and only Wallet is able to utilize the internal secure element on a Wallet-enabled device. That means Google is directly managing every layer of the process.

And guess what: Verizon wasn't OK with this. It really has nothing at all to do with Block C rules or apps - this is a fight over who gets to control the internal secure element. This isn't about letting consumers run the software they want, it's about letting Google run the software and control the hardware it wants.




http://www.androidpolice.com/2013/0...why-the-carrier-is-still-allowed-to-block-it/

Click to expand...

Triplethreat, this article is obviously wrong. Verizon doesn't control the hardware, Samsung and Google do; Verizon simply licenses the devices. They don't make them. Secondly the NFC chip is standard in most Android devices, on or off Verizon's network. Third, the device can accessed without root since Google includes Google Wallet's service API as part of Android, which has privileged access regardless.

The author of the article says himself he doesn't know how these devices work. I'm a software developer, that includes mobile platforms. I know how these devices work. And I don't want you to take my word for it, since anyone who wants to spend a modicum of time to find out can learn how these devices work.

The article makes some very clear and obvious flawed assumptions about how Android devices work and who owns what. These aren't "Verizon devices."

gourimoko said:

What @KI4MVP is saying is that, so long as the ISP advises its consumers in a disclosure (which, many of them already did prior to net neutrality); then, they can arbitrarily decide which traffic to block, which to throttle, and which to "accelerate."

In the context of "net neutrality," that means they are free to do whatever they want with the traffic, even if it means it doesn't get delivered; so long as they tell you in a disclosure, ahead of time, that they might do this.

Click to expand...

There's still rules in place.

We haven't stripped down to the point where ISP's have unlimited power over us. Which seems to be the argument BOTH of you are making.

gourimoko said:

Triplethreat, this article is obviously wrong. Verizon doesn't control the hardware, Samsung and Google do; Verizon simply licenses the devices. They don't make them. Secondly the NFC chip is standard in most Android devices, on or off Verizon's network. Third, the device can accessed without root since Google includes Google Wallet's service API as part of Android, which has privileged access regardless.

The author of the article says himself he doesn't know how these devices work. I'm a software developer, that includes mobile platforms. I know how these devices work. And I don't want you to take my word for it, since anyone who wants to spend a modicum of time to find out can learn how these devices work.

The article makes some very clear and obvious flawed assumptions about how Android devices work and who owns what. These aren't "Verizon devices."

Click to expand...

those Block C rules have an exception (several exceptions, actually). Basically, these rules about open applications apply unless a particular app "would not be compliant with published technical standards reasonably necessary for the management or protection of the licensee's network."

Triplethreat said:

There's still rules in place.

We haven't stripped down to the point where ISP's have unlimited power over us. Which seems to be the argument BOTH of you are making.

Click to expand...

No. I'm not arguing that ISPs can enslave our children. I'm arguing they are violating a decades old standard of net neutrality; which means, treating internet traffic neutrally, without preference or bias, without blocking services, without violating my privacy or penalizing me for protecting my privacy via encryption.

This network standard predates the World Wide Web as well as the Internet itself.

Why does that need to get turned into something that it's not? My argument is concise and clear and to the point.

Triplethreat said:

those Block C rules have an exception (several exceptions, actually). Basically, these rules about open applications apply unless a particular app "would not be compliant with published technical standards reasonably necessary for the management or protection of the licensee's network."

Click to expand...

Um, okay... Now explain why Google Wallet in any way infringes on the management or protection of Verizon's network?

gourimoko said:

Um, okay... Now explain why Google Wallet in any way infringes on the management or protection of Verizon's network?

Click to expand...

Only one card's credentials are stored on the element at a given time (obvious security reasons), which is why you need an internet connection if you want to switch your active card in Wallet. When you sign in to Wallet or change cards, the Wallet app calls up to the Google server, pulls down your credentials for a particular card, and then writes them to the secure element.


But one does not simply write to the secure element (... or walk into Mordor), it requires special permissions. Google Wallet is doing something few apps do - asking for direct, exclusive access to a secure piece of hardware in the phone. Not only that, once Google takes over the secure element, it wants total control. Because of the security concerns (and related technical difficulties) involved in sharing a secure element, Wallet and only Wallet is able to utilize the internal secure element on a Wallet-enabled device. That means Google is directly managing every layer of the process.

And guess what: Verizon wasn't OK with this.

If Wallet didn't require access to the secure element, there'd be no issue in getting it onto Verizon phones. And hopefully something like that is coming.

Triple, this is the problem when citing articles from Google without understanding them.. What you're saying is wrong, outdated, and inaccurate; as is the article you're using to present an argument. I will go through this now, from a technical level, to demonstrate this to you. I'm saying this because I want you to understand...

Let's go through these point for point:

Triplethreat said:

Only one card's credentials are stored on the element at a given time (obvious security reasons), which is why you need an internet connection if you want to switch your active card in Wallet.

Click to expand...

This is false. You need an active internet connection for user authentication, as well as for Host-based Card Emulation, which is an Android feature that validates and stores card information in Google's cloud not on the physical device. This actually bypasses the Secure Element SoC functionality entirely.

Triplethreat said:

Only one card's credentials are stored on the element at a given time (obvious security reasons),

Click to expand...

This is false.

ISO 14443 standard-compliant devices (see: phones made since 2012) are capable of storing multiple cards and transmitting multiple card data simultaneously within a single polling loop from a non-mono card reading terminal. This allows for multiple cards to be stored on a given device, either SE-based or not.

Triplethreat said:

When you sign in to Wallet or change cards, the Wallet app calls up to the Google server, pulls down your credentials for a particular card, and then writes them to the secure element.

Click to expand...

That's false.

When the Android API uses HCE for card credentials, it bypasses the SE in the phone entirely. Here's a flowchart of how it works without HCE:



And here's how it works with HCE:

Triplethreat said:

But one does not simply write to the secure element (... or walk into Mordor), it requires special permissions. Google Wallet is doing something few apps do - asking for direct, exclusive access to a secure piece of hardware in the phone.

Click to expand...

Sigh... That's false.

The usermode Google Wallet app relies on the underlying Google Android Wallet API which is part of the operating system. Any application can make the exact same request to the operating system API and the Wallet app is in no way privileged.

Triplethreat said:

Not only that, once Google takes over the secure element, it wants total control. Because of the security concerns (and related technical difficulties) involved in sharing a secure element, Wallet and only Wallet is able to utilize the internal secure element on a Wallet-enabled device. That means Google is directly managing every layer of the process.

Click to expand...

That's false too..

ONLY Google can "control" the Secure Element on any device. All access happens through Android. There is no direct hardware access in Android whatsoever. Any developer could tell you this, the author obviously has no idea what he's talking about. It's a completely closed space; hell, most of these apps run in the fucking Java (Dalvik) Virtual Machine for crying out loud.

Triplethreat said:

And guess what: Verizon wasn't OK with this.

Click to expand...

The author undermines this point at the end of the article you're citing.

Triplethreat said:

If Wallet didn't require access to the secure element, there'd be no issue in getting it onto Verizon phones. And hopefully something like that is coming.

Click to expand...

Wallet does not require the Secure Element, it can use Host-based Card Emulation. It simply needs to operate the NFC radio. Google and it's device partners (read: not Verizon) control the NFC radio.

Again, Triplethreat, the author is quite obviously clueless and you're doing yourself a disservice by citing him simply because you think he agrees with your position.

^^ TripleThreat thinks he can get too technical for me or @gourimoko

gourimoko said:

Triple, this is the problem when citing articles from Google without understanding them.. What you're saying is wrong, outdated, and inaccurate; as is the article you're using to present an argument. I will go through this now, from a technical level, to demonstrate this to you. I'm saying this because I want you to understand...

Let's go through these point for point:



This is false. You need an active internet connection for user authentication, as well as for Host-based Card Emulation, which is an Android feature that validates and stores card information in Google's cloud not on the physical device. This actually bypasses the Secure Element SoC functionality entirely.



This is false.

ISO 14443 standard-compliant devices (see: phones made since 2012) are capable of storing multiple cards and transmitting multiple card data simultaneously within a single polling loop from a non-mono card reading terminal. This allows for multiple cards to be stored on a given device, either SE-based or not.



That's false.

When the Android API uses HCE for card credentials, it bypasses the SE in the phone entirely. Here's a flowchart of how it works without HCE:

And here's how it works with HCE:

Sigh... That's false.

The usermode Google Wallet app relies on the underlying Google Android Wallet API which is part of the operating system. Any application can make the exact same request to the operating system API and the Wallet app is in no way privileged.



That's false too..

ONLY Google can "control" the Secure Element on any device. All access happens through Android. There is no direct hardware access in Android whatsoever. Any developer could tell you this, the author obviously has no idea what he's talking about. It's a completely closed space; hell, most of these apps run in the fucking Java (Dalvik) Virtual Machine for crying out loud.



The author undermines this point at the end of the article you're citing.



Wallet does not require the Secure Element, it can use Host-based Card Emulation. It simply needs to operate the NFC radio. Google and it's device partners (read: not Verizon) control the NFC radio.

Again, Triplethreat, the author is quite obviously clueless and you're doing yourself a disservice by citing him simply because you think he agrees with your position.

Click to expand...

This is such a divergence from the topic it's almost baffling.

What's the point being made here?

If the worst thing that has happened before net neutrality was that some people couldn't use Google Wallet?

Sure, I'll give you this then. (And note that there was absolutely no violation of Block C rules)

Comcast, I absolutely will not because there's zero proof of any malpractice whatsoever.

So we have the 4 that we're resolved + Verizon.

And we haven't even gotten into the main basis of the paper which is the economics.

Triplethreat said:

This is such a divergence from the topic it's almost baffling.

Click to expand...

Triple, I'm just responding to the article you're presenting as evidence.

Triplethreat said:

What's the point being made here?

Click to expand...

That the article is incorrect.

Triplethreat said:

If the worst thing that has happened before net neutrality was that some people couldn't use Google Wallet?

Click to expand...

No, that ISPs were fundamentally trying to change how the Internet operates.

Think about it, right now you think the ISPs control the internet, and they never did before.. when did that happen? Ask yourself, when did Verizon or Comcast get the right to do this? They never had it before.. did they?

Sure there was no law in place, but there was always the agreement, the assumption, that traffic flowed from end to end across the internet, in a way that was neutral and agnostic to the underlying fabric. That's what net neutrality is and always was, before there ever was a law or a regulation put in place.

Thus, it never mattered who owned the router your packets hopped through -- it was irrelevant, since everyone agreed, the internet was a thing that existed atop this network of routers, switches, and hubs.

So the paper you cited suggesting the FCC was acting preemptively is mistaken. The FCC was codifying a decades old tradition and understanding that suggests the Internet is a thing, a place, and a space, that exists unto itself, regardless of the topology or the underlying network hardware. "The Internet" is a thing, not simply a product that Verizon or Comcast can sell you in piecemeal.

Triplethreat said:

Sure, I'll give you this then. (And note that there was absolutely no violation of Block C rules)

Click to expand...

Fair enough, Triple.

Triplethreat said:

Comcast, I absolutely will not because there's zero proof of any malpractice whatsoever.

So we have the 4 that we're resolved + Verizon.

Click to expand...

We can go over Comcast... in fact let's do that next.

Triplethreat said:

And we haven't even gotten into the main basis of the paper which is the economics.

Click to expand...

No, I get that.. but, I just want to be clear; this portion of the argument (about 4 citations of violations) is wrong, and it's been used before. To the effect of "this was never a problem;" oh but yes it was, and we can go through over many such problems in the past, from 1996 to 2015.

KI4MVP said:

^^ TripleThreat thinks he can get too technical for me or @gourimoko

Click to expand...

I'm a fucking DBA and @gourimoko regularly makes me feel like I'm not a nerd when he gets technical.