Linked by David Adams on Wed 9th Nov 2011 06:34 UTC
PDAs, Cellphones, Wireless "Sources close to Adobe that have been briefed on the company's future development plans have revealed this forthcoming announcement to ZDNet: Our future work with Flash on mobile devices will be focused on enabling Flash developers to package native apps with Adobe AIR for all the major app stores. We will no longer adapt Flash Player for mobile devices to new browser, OS version or device configurations.. . ."
Thread beginning with comment 496738
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Comment by mappy
by mappy on Wed 9th Nov 2011 21:54 UTC in reply to "RE: Comment by mappy"
mappy
Member since:
2010-06-02

I know having raw TCP support in HTML isn't a good idea.

I do like the way Flash gets around it: it makes a request to the target on port 587 before initiating the TCP socket, and expects an XML security certificate permitting the connection. That means you have to authorise it on the server-side, but aside from that it doesn't actually interfere with the stream. So if you wanted to make e.g. a web-based IRC client, you could use a standard IRCd and no websocket proxy, just run an authenticating script on that port to demonstrate you consent to the connections.

Anyways, raw TCP is a legitimate feature that Flash has over HTML, and Flash is still worth considering in certain situations.

Reply Parent Score: 1

RE[3]: Comment by mappy
by Lennie on Wed 9th Nov 2011 23:41 in reply to "RE[2]: Comment by mappy"
Lennie Member since:
2007-09-22

Actually Flash and Java are still vulnerable to the security bug the old websocket protocol revealed.

If someone has a 'transparent proxy server' and it contains a header-injection bug (not all that uncommon especially if you don't keep up with security updates).

In that case it is possible to use Flash or Java to make it look to the proxy like a connection is being made to google.com and to insert malware in the page that will be cached by the proxy.

Thus exposing all users behind the proxy visiting google.com to the malware.

This can be done as a drive-by attack from within the browser (flash and java and the old version of the websockets protocol) of a users behind that same proxy.

So let's say one of the users behind the transparant proxy (the user can not see it, he/she might not even be aware of it's existence) visits attacker.com.

Some code executes in the browser of that user and makes a connection to attacker.com (in the case of flash, it will check if attacker.com has an XML file: it obviously does) but injects some extra HTTP-headers to make it look like it is connecting to google.com to the proxy and the page returned from attacker.com is the normal google.com page but with malware included.

That page will than be cached in the transparent proxy and served to any user behind the proxy who wants to visit google.com

That is why the newer websocket protocol has some extra encoding.

I've not read the detailed information about the vulnerability or the specifications, but this is how I understand it.

The developers of Firefox and Opera felt that introducing more ways to attack such parts of the would be a bad idea. So they disabled it by default until the WebSocket protocol was fixed.

Edited 2011-11-09 23:48 UTC

Reply Parent Score: 3