The TCP proxy use case, which has been my primary motivation for WebSocket since day one, points to another limitation of SSE. SSE cannot handle binary data without encoding the data into text. WebSocket can.
I'm surprised the author didn't jump on this sentence:
"With any diagnostic data sent to Apple, customers must actively opt-in to share this information..."
As I understand it, Carrier IQ is about sending data to carriers. Apple only denied that data was silently sent to Apple. That's completely different than saying no data has been transmitted at all.
While that is a good observation, it has been proven that no statistical data is sent to CarrierIQ when the preference is disabled. This has been determined by reverse engineering the daemons used for CarrierIQ reporting on various iOS versions.
From the description of "Diagnostics & Usage" reporting on the device itself, it sounds as though the carriers can only obtain that data via Apple. This would reconcile that wording with the finding that selecting "Don't Send" appears to disable Carrier IQ logging as well.
[..] To help Apple’s partners and third-party developers improve their apps, products and services designed for use with Apple products, Apple may provide such partners or developers with a subset of diagnostic information that is relevant to that partner’s or developer’s app, product or service, as long as the diagnostic information is aggregated or in a form that does not personally identify you.
I'm sorry but upon Chpwn's investigation, didn't iOS version of the Carrier IQ software only record a few items such as your phone number, your country, your active phone calls and location data if activated? Any of which your carrier would already know anyway?
At the risk of driving an accusation of conspiracy theory, I'm reading that sentence exactly the same way. This is a "non-denial denial". They're denying something not alleged in the hopes that it distracts or confuses people about the real issue.
What use cases for TCP do you envision where WebSocket won't be sufficient? It is quite possible to speak standard protocols over WebSocket that are typically spoken over TCP.
Last thing first: TCP requires a listening server. WebSocket requires a listening server. There is not inherently more infrastructure required.
The handshake and HTTP upgrade are there for a reason. Connecting out from web applications with straight TCP breaks the web security model. After the handshake, you can treat WebSocket binary frames as if they were a TCP byte stream. Speak any protocol you want to.
Anything you can do with TCP you can do with WebSocket. The only exception is that you cannot connect to a listening server that does not expect the WebSocket handshake. That is intentional! In fact, that is the reason for the WebSocket handshake.
That's probably because the DOM's window.location.protocol returns "http:" for URLs with http schemes. That is reflected in the diagram included in the article where protocol extends to cover the colon in the DOM row. Overall, it's a pretty unfortunate mish mash of terminology.
Those are searches for the string MSFT. The article uses the share price data that the author uploaded. See how the chart is labeled "User uploaded activity for MSFT and US Web Search activity for google interview questions."
