Re: [whatwg] WebSocket support in HTML5
Hi Philipp, After all, more or less the only situation you'd want to use UDP Wrong. But then personally, I'd use UDP for server-generated events, and something other than a context-devoid, connection-less, session-hijackable, bollocks protocol as my middleware backbone; I am clearly 180 degrees in the minority :-) That out of the way, I think the structure in content approach is preferable because in the end it makes the whole feature easier to use and accessible to a much broader range of web authors. Because a WS stream has standardized metadata and delimiters, you can easily build a generic framework that processes those parts for you. Fine, you want structure in content then you stick it on *afterwards*. Please don't impose your particular views on what everyone else's data stream should look like! Some might like chunking, record-type indicators, or data-length sentinels, or something completely different; it's up to them! Anyway, I believe Shannon has come up with a very workable ws.read(bytes) and ws.write(bytes) alternative.Spookily, just like a Socket - amazing. Well done. Note that it was a conscious design decision to make WS incompatible with existing protocols, because the risk for misuse is too great. Excellent, so WebSockets have been deliberately ham-strung by design? Now that explains a lot :-( Even if I was less paranoid I'd still smell a vested interest rat here Yes, you can have all the sockets you want as long as you are forced through our HTTP servers to do it. Cheers Richard Maher - Original Message - From: Philipp Serafin [EMAIL PROTECTED] To: Kristof Zelechovski [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, September 29, 2008 7:18 PM Subject: Re: [whatwg] WebSocket support in HTML5 On Sat, Sep 27, 2008 at 12:58 PM, Kristof Zelechovski [EMAIL PROTECTED] wrote: If you are in control of the server, you can simulate datagram sockets with one-shot controlled sockets I do not agree with Richard at all, but I have to play devil's advocate here because I think such a simulation would be pretty useless. After all, more or less the only situation you'd want to use UDP outside a LAN is when TCP doesn't fit your needs, e.g. because the flow control does more harm than good to your use-case or because your peers have not enough processing power for a full TCP implementation. Simulating UDP via TCP would pretty much combine the disadvantages of both protocols. Also, you already need a full roudtrip to initiate a TCP connection, a second one to perform the WS handshake and a third one to close the connection. Data not taken into account. You can hardly repeat that for every datagram you want to send. That out of the way, I think the structure in content approach is preferable because in the end it makes the whole feature easier to use and accessible to a much broader range of web authors. Because a WS stream has standardized metadata and delimiters, you can easily build a generic framework that processes those parts for you. This is especially important if you DON'T have full control over the server, which I believe is the case for the majority of smaller sites that use a shared hosting solution. Those hosters usually don't give their clients access to the underlying processes at all. All the clients can do is upload static files and script files that get executed in a restricted environment. It's really hard to integrate pure, persistent connections into such a setup. With WS, a hoster could for example have a demon listen to all incoming WS connections and call the client's scripts whenever a data frame has been received. In short, it's much easier for them to manage persistent connections if there is a standardized structure. And if it's easier for them, hopefully the support for this feature will grow. As for the restriction of unicode data, of course we could just use an octet counting mechanism like HTTP does instead of a fixed delimiter. This would allow arbitrary data inside the WS frames. On the other hand, this might make it easier to spoof existing protocols. Would the benefits of this outweigh the risks? Note that it was a conscious design decision to make WS incompatible with existing protocols, because the risk for misuse is too great. If you need your web app to inerac with a specific service, it should be easy to write a generic proxy that does the handshake, strips out the frame marks and transforms the data. Also, it's not like the other technologies would vanish all of a sudden. If you have sufficient control over your server, you can STILL use Java or Flash sockets. Regards, Philipp Serafin
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
Hi Maciej, Does OS X (or the iPhone for that matter) support Java 6 yet? And were all these security bug reports you keep seeing to do with Java in general, or the Apple version in particular? Would Strict Same Origin policy not be useful as an optional (perhaps default) configuration? Cheers Richard Maher - Original Message - From: Maciej Stachowiak [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: whatwg@lists.whatwg.org; Michal Zalewski [EMAIL PROTECTED] Sent: Tuesday, September 30, 2008 12:22 PM Subject: Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web On Sep 26, 2008, at 2:19 PM, Elliotte Rusty Harold wrote: Michal Zalewski wrote: I kinda assumed this suggestion was tongue-in-cheek, but if not - banning cross-domain IFRAMEs to fix one flaw, without providing viable methods for sandboxing untrusted same-origin content, would leave web developers with no tools to deal with quite a few classes of major security issues. It's tongue-in-cheek that I don't expect it to be adopted or seriously considered (this year). It's not tongue-in-cheek in that I very much wish it were adopted. That is, I think it's in the realm of the desirable, not the possible. I am curious what issues you see with same origin content. They certainly exist, but I tend to feel those are orthogonal to the issues at hand, and subject for a separate discussion. I do think we have an existence proof that security in this realm is possible. That's Java. Modulo some outright bugs in VMs (since repaired) the default Java applet security model has worked and worked well since 1.0 beta 1. (1.0 alpha 1 wasn't quite strict enough.) I have seen no security design flaws exposed in Java applets in over ten years. That's why I suspect duplicating Java's security policy in HTML is a safe way forward. I'm skeptical that anything less will suffice. Java's security policy is also looser in some ways. For example, it allows the applet to connect to any port on the origin server. This has at times caused Java applets to be subject to vulnerabilities that did not affect plain HTML+JS+CSS (more recently than in the past 10 years). The general Web same-origin policy considers the port as well as the host to be part of the origin. More generally, I am on Apple's internal incoming security bug list, and I see Java applet security bugs all the time, so I think whatever the strength of the model may be, it does not lead to Java applets being secure in practice. And finally, the key question for whether strict same-origin can work it not one of security but of functionality and usability. The trend in recent years has been for browsers to punch more controlled holes in the same-origin policy to fulfill the frequent desire of Web application developers to communicate with other servers from the client side. This is desirable so that AJAX apps (where most of the logic and functionality is client-side) can make use of third-party Web services APIs, in the same way that native apps can, without having to round-trip through their own server. I do not see this trend reversing any time soon. In conclusion I think limiting the Web to 100% strict same-origin would not be desirable even in an ideal world where compatibility issues are not a concern. I don't expect this to happen, however, because many large players are exploiting existing security design flaws in the web to do things they shouldn't be allowed to do in the first place, especially tracking users. Any scheme that limits the ability of advertisers and others to track users will be strenuously resisted. For the record, neither Apple nor the WebKit project have any strong commercial interest in the ability of advertisers or others to track users. Regards, Maciej
Re: [whatwg] WebSocket websocket-origin
Hear! Hear! - Original Message - From: Shannon [EMAIL PROTECTED] To: Anne van Kesteren [EMAIL PROTECTED] Cc: WHATWG [EMAIL PROTECTED] Sent: Tuesday, September 30, 2008 12:59 PM Subject: Re: [whatwg] WebSocket websocket-origin Anne van Kesteren wrote: What is the reason for doing literal comparison on the websocket-origin and websocket-location HTTP headers? Access Control for Cross-Site Requests is currently following this design for access-control-allow-origin but sicking is complaining about so maybe it should be URL-without-path comparison instead. (E.g., then http://example.org and http://example.org:80 would be equivalent.) I think the temptation to standardise features like access control defeats the point of websockets. Since things like access control and sessions can be readily implemented via CGI interfaces it seems implied that the whole point of websockets is to provide lightweight services. If the service actually needs something like this then the author can perform the check post-handshake using any method they feel like. I don't really feel strongly one way or the other about this particular header but I'm concerned about the slippery-slope of complicating the HTTP handshake to the point where you might as well be using CGI. Maybe the standard should simply recommend sending the header but make no requirement about how it is parsed. That way the service itself can decide whether the check is even necessary and if so whether it should be strict or loose or regex-based without the client automatically hanging up the connection. Shannon
Re: [whatwg] Simplified WebSockets
Hi Shannon, In the absence of Socket Policy Files, this is a good fallback position; the shorter the handshake, the better. Cheers Richard Maher - Original Message - From: Shannon [EMAIL PROTECTED] To: WHAT working group whatwg@lists.whatwg.org Sent: Tuesday, September 30, 2008 4:04 PM Subject: [whatwg] Simplified WebSockets It occurred to me the other day when musing on WebSockets that the handshake is more complicated than required to achieve its purpose and still allows potential exploits. I'm going to assume for now the purpose of the handshake is to: * Prevent unsafe communication with a non-websocket service. * Provide just enough HTTP compatibility to allow proxying and virtual hosting. I think the case has been successfully put that DDOS or command injection are possible using IMG tags or existing javascript methods - however the counter-argument has been made that the presence of legacy issues is not an argument for creating new ones. So with that in mind we should implement WebSockets as robustly as we can. Since we don't at first know what the service is we really need to assume that: * Long strings or certain characters may crash the service. * The service may not be line orientated. * The service may use binary data for communications, rather than text. * Characters outside the ASCII printable range may have special meaning (ie, 'bell' or control characters). * No string is safe, since the service may use string commands and non-whitespace separators. For the sake of argument we'll assume the existence of a service that accepts commands as follows (we'll also assume the service ignores bad commands and continues processing): AUTHENTICATE(user,password);GRANT(user,ALL);DELETE(/some/record);LOGOUT; To feed this command set to the service via WebSockets we use: var ws = new WebSocket(http://server:1024/?;AUTHENTICATE(user,password);GRANT(user,ALL); DELETE(/some/record);LOGOUT;) I have already verified that none of these characters require escaping in URLs. The current proposal is fairly strict about allowed URIs but in my opinion it is not strict enough. We really need to verify we are talking to a WebSocket service before we start sending anything under the control of a malicious author. Now given the huge variety of non-HTTP sub-systems we'll be talking to I don't think a full URL or path is actually a useful part of the handshake. What does path mean to a mail server for instance? Here is my proposal: C = client S = service # First we talk to our proxy, if configured. We know we're talking to a proxy because it's set on the client. C CONNECT server.example.com:1024 HTTP/1.1 C Host: server.example.com:1024 C Proxy-Connection: Keep-Alive C Upgrade: WebSocket/1.0 # Without a proxy we send C HEAD server.example.com:1024 HTTP/1.1 C Host: server.example.com:1024 C Connection: Keep-Alive C Upgrade: WebSocket/1.0 # If all goes well the service will respond with: S HTTP/1.1 200 OK S Upgrade: WebSocket/1.0 or S Some other HTTP response (but no Upgrade header) or S Other non-HTTP response or No response. # If we get a 200 response with Upgrade: WebSocket we *know* we have a WebSocket. Any other response and the client can throw a 'Connection failed' or 'Timeout' exception. The client and server can now exchange any authentication tokens, access conditions, cookies, etc according to service requirements. eg: ws.Send( 'referrer=' + window.location + '\r\n' ); ws.Send( 'channel=' + 'customers' + '\r\n' ); ws.Send( CookiesToServerSyntax() ); The key advantages of this method are: * Simplicity (less handshaking, less parsing, fewer requirements) * Security (No page author control over initial handshake beyond the server name or IP. Removes the risk of command injection via URI.) * Compatibility (HTTP compatible. Proxy and Virtual Hosting compatible. Allows a CGI script to emulate a WebSocket) I'm not saying the current proposal doesn't provide some of these things, just that I believe this proposal does it better. Shannon
Re: [whatwg] WebSocket and proxies
Hi Shannon, Bummer :-( Please don't give up! Sorry if this is a really stupid question (my knowledge of proxy-servers is minimal) but what issues are involved here that have not been solved with a product such as Orbited? http://www.orbited.org/ Look, I've never used it but, if I understand it correctly, it sits behind the proxy-server and traps the Socket traffic and forwards it onto the designated run-o'-the-mill TCP/IP server. Could a similar mechanism(s) not work here? Is it that we're dealing with runtime discovery of public proxy-servers outside any firewalls? Something else? Cheers Richard Maher PS. Much prefer the websocket.read(bytes) and websocket.write(bytes) well done! Please don't forget websocket.peek(bytes). - Original Message - From: Shannon [EMAIL PROTECTED] To: WHAT working group whatwg@lists.whatwg.org Sent: Tuesday, October 14, 2008 7:22 AM Subject: [whatwg] WebSocket and proxies In the process of testing my WebSocket proposal I discovered the CONNECT method has a major restriction. Most proxies disable CONNECT to anything but port 443. The following is from Squid and the Blowfish: -- It is very important that you stop CONNECT type requests to non-SSL ports. The CONNECT method allows data transfer in any direction at any time, regardless of the transport protocol used. As a consequence, a malicious user could telnet(1) to a (very) badly configured proxy, enter something like: ... snip example ... and end up connected to the remote server, as if the connection was originated by the proxy. --- I verified that Squid and all public proxies I tried disable CONNECT by default to non-SSL ports. It's unlikely many internet hosts will have 443 available for WebSockets if they also run a webserver. It could be done with virtual IPs or dedicated hosts but this imposes complex requirements and costs over alternatives like CGI. The availability and capabilities of the OPTIONS and GET protocols also varied from proxy to proxy. The IETF draft related to TLS (http://tools.ietf.org/html/draft-ietf-tls-http-upgrade-05) has this to say: --- 3.2 Mandatory Upgrade If an unsecured response would be unacceptable, a client MUST send an OPTIONS request first to complete the switch to TLS/1.0 (if possible). OPTIONS * HTTP/1.1 Host: example.bank.com Upgrade: TLS/1.0 Connection: Upgrade --- So according to this draft spec OPTIONS is the only way to do a *mandatory* upgrade of our connection. Once again this failed in testing --- = OPTIONS * HTTP/1.1 = Proxy-Connection: keep-alive = Connection: Upgrade = Upgrade: WebSocket/1.0 = Host: warriorhut.org:8000 = = HTTP/1.0 400 Bad Request = Server: squid/3.0.STABLE8 Other proxies gave different errors or simply returned nothing. The problem may be related to the Upgrade and Connection headers rather than OPTIONS, since I had similar issues using Connection: Upgrade with GET. I had the most success using GET without a Connection: Upgrade header. It seems that the proxy thinks the header is directed at it so it does not pass it on to the remote host. In many cases it will abort the connection. Using the Upgrade: header without Connection allows the Upgrade header through to the actual websocket service. It seems to me that whatever we try in many cases the connection will be silently dropped by the proxy and the reasons will be unclear due to the lack of error handling. There seems to be a wide variation in proxy behaviour for uncommon operations. I suppose proxy developers could fix these issues but whether a significant rollout could be achieved before HTML5 is released is questionable. Given that an asynchronous connection cannot be cached the only reasons remaining for going through a proxy are anonymity and firewall traversal. Automatically bypassing the users proxy configuration to solve the issues above has the potential to break both of these. It would be a significant breach of trust for a UA to bypass the users proxy and some networks only allow connections via a proxy (for security and monitoring). It seems that we're stuck between a rock and hard place here. In light of this I reiterate my earlier suggestion that the time could be better spent providing guidelines for communication via an asynchronous CGI interface. This would allow reuse of existing port 80 and 443 web services which would resolve the cross-domain issues (the CGI can relay the actual service via a backend connection) and most of the proxy issues above (since proxy GET and CONNECT are more reliable on these ports). Shannon
Re: [whatwg] WebSocket support in HTML5
Hi David, - Original Message - From: ddailey [EMAIL PROTECTED] To: Richard's Hotmail [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, September 21, 2008 10:33 PM Subject: Re: [whatwg] WebSocket support in HTML5 Hi Richard, My apologies for getting involved in a topic I confess to knowing very little about (though I would like to be able to have direct client-to-client communication for a variety of purposes including gaming and social networking), but it seems like the question here is what does the approach you are advocating enable that the approach on the table doesn't do? The easiest way to do that is to point you towards the BSD Socket documentation or, in the case of browser-based functionality, go to http://java.sun.com/j2se/1.5.0/docs/api/index.html and look up java.net.Socket. Now, you might like to sit there and ask me to justify the need or desirability for each and every attribute and method, but then you'd problably also claim that AJAX long-polling does everything we need already so why bother with sockets anyway? Connection Timeouts? Read Timeouts? KeepAlive? NoDelay? Peeking? Perhaps - Well we do that sort of stuff with HTTP headers, so there!? I understand that you are saying the approach WHATWG and HTML5 WG have undertaken is flawed (and I acknowledge your claim that lots of folks are doing it better), but I really don't see what you are hoping to do that these folks (whose expertise in such matters I would certainly be willing to defer to) will not enable? I am just asking why Sockets are being re-invented for html5, and in such a restricted and watered-down fashion. If you guys/gals really like to build an integer 7 bits at a time or frame UTF-8 then more power to you; just please stop forcing every one else to perfoem the same contortions. Please gives us a normal a Socket (UDP and Multicast too please) Subject it to same-origin policy or whatever else is reqd. There are Intranets and IPsec and all sorts of configurations that lend themselves to just such functionality. But you say It's fine for gaming others say It's just fine for chat what else could there be eh? Are you claiming, for example, that HTTP roundtrips from a server to each client will be intrinsically too slow to support such applications as gaming? It's up to others to define too slow for their own applications. (But the amount of meta-data crud travelling around these days with HTTP and XML et al could certainly be classified as sub-optimal :-) If so, then it would seem that would be a concrete complaint that the advocates of the current proposal could, in theory, respond to. The history of the discussion referred to by the link, indicates that as James says, the current proposal has undergone numerous revisions based on input. I'm sure a lot of (perhaps too narrowly) focused people have put in a heap of work on this, but does no one else question how these people could have come up with a solution that differs so greatly from the approach taken by SUN/Java, Adobe/Flex, and Microsoft Silverlight? Aristotle, Plato, Socrates - Morons! :-) Please make it a broader church, and not just for the Internet denominations of gaming and chat. Perhaps since you obviously care so much about it, you can help the proposal to evolve into something which addresses your concerns. Just the observation of a naive onlooker. cheers David Cheers Richard Maher - Original Message - From: Richard's Hotmail [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, September 21, 2008 9:58 AM Subject: Re: [whatwg] WebSocket support in HTML5 Hi James, Thanks for the reply. [1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-July/015252.html My appologies for only having read the first ten years of that thread :-) Look, I'm not sure exactly what problem you guys are solving with HTML5's WebSockets but I wish you well. What I and *many* others are looking for is native JavaScript support for Sockets a la mode de (SUN Java Applets + Adobe Flex + MIcrosoft Silverlight) that for some strange reason don't seem to be subject to the same imaginary obstacles that are being discussed in that thread. Please explain what security vulnerabilities et al that Adobe, SUN and Microsoft have foisted upon us that the HTML5 people wish to spare us from. If you guys live in a world where nothing but port 80 exists and no one with ever want UDP datagrams (let alone Multicast messages) to their web clients then I have come to the wrong place :-( What goes up and down the network connection is our business not yours. No more bollocks protocols! As I said in the previous post, if you guys want to put a Frame me like ASCII contortion interface/API on top of the JavaScript Sockets (similar to SOAP on HTTP) then go crazy; just don't try to shackle everyone else with the same restrictions. Please see the following
Re: [whatwg] WebSocket support in HTML5
{
stillDying = false;
System.out.println(Joining MessageThread);
try {socketThread.join();}
catch (InterruptedException e){
System.out.println(Interrupted Join);
stillDying = true;
}
} while (stillDying);
socketThread = null;
}
System.out.println(Tier3Pager Applet Rundown complete);
super.destroy();
}
}
Tier3Talk.java
===
/**
* Copyright Tier3 Software. All rights reserved.
*
* Author: Richard Maher
*
**/
import java.awt.*;
import java.awt.event.*;
public class Tier3Talk extends Frame
implements WindowStateListener
{
TextArea chatPanel = new TextArea(Server messages will appear
below: -, 10, 50);
Toolkit toolkit= Toolkit.getDefaultToolkit();
boolean windowDown = true;
public Tier3Talk(String heading)
{
super(heading);
setBackground(Color.gray);
chatPanel.setEditable(false);
Panel panel = new Panel();
panel.setLayout(new FlowLayout(FlowLayout.CENTER));
panel.add(chatPanel);
add(Center, panel);
Dimension screenDim = toolkit.getScreenSize();
pack();
Dimension windowDim = getSize();
setLocation((screenDim.width - windowDim.width),(screenDim.height -
windowDim.height));
setResizable(false);
addWindowStateListener(this);
setExtendedState(Frame.ICONIFIED);
setVisible(true);
}
public void append(String newMsg)
{
chatPanel.append(\n + newMsg);
if (windowDown)
setExtendedState(Frame.NORMAL);
toolkit.beep();
}
public void windowStateChanged(WindowEvent we)
{
switch (we.getNewState())
{
case Frame.ICONIFIED:
windowDown = true;
break;
case Frame.NORMAL:
windowDown = false;
break;
default:
System.out.println(Event of no interest +
we.getNewState());
}
}
}
Cheers Richard Maher
- Original Message -
From: ddailey [EMAIL PROTECTED]
To: Richard's Hotmail [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Sunday, September 21, 2008 10:33 PM
Subject: Re: [whatwg] WebSocket support in HTML5
Hi Richard,
My apologies for getting involved in a topic I confess to knowing very
little about (though I would like to be able to have direct
client-to-client
communication for a variety of purposes including gaming and social
networking), but it seems like the question here is what does the
approach
you are advocating enable that the approach on the table doesn't do? I
understand that you are saying the approach WHATWG and HTML5 WG have
undertaken is flawed (and I acknowledge your claim that lots of folks are
doing it better), but I really don't see what you are hoping to do that
these folks (whose expertise in such matters I would certainly be willing
to
defer to) will not enable? Are you claiming, for example, that HTTP
roundtrips from a server to each client will be intrinsically too slow to
support such applications as gaming? If so, then it would seem that would
be
a concrete complaint that the advocates of the current proposal could, in
theory, respond to. The history of the discussion referred to by the link,
indicates that as James says, the current proposal has undergone numerous
revisions based on input. Perhaps since you obviously care so much about
it,
you can help the proposal to evolve into something which addresses your
concerns.
Just the observation of a naive onlooker.
cheers
David
- Original Message -
From: Richard's Hotmail [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, September 21, 2008 9:58 AM
Subject: Re: [whatwg] WebSocket support in HTML5
Hi James,
Thanks for the reply.
[1]
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-July/015252.html
My appologies for only having read the first ten years of that thread
:-)
Look, I'm not sure exactly what problem you guys are solving with
HTML5's
WebSockets but I wish you well. What I and *many* others are looking for
is
native JavaScript support for Sockets a la mode de (SUN Java Applets +
Adobe Flex + MIcrosoft Silverlight) that for some strange reason don't
seem
to be subject to the same imaginary obstacles that are being discussed
in
that thread. Please explain what security vulnerabilities et al that
Adobe,
SUN and Microsoft have foisted upon us that the HTML5 people wish to
spare
us from.
If you guys live in a world where nothing but port 80 exists and no one
with
ever want UDP datagrams (let alone Multicast messages) to their web
clients
then I have come to the wrong place :-(
What goes up and down the network connection is our business not yours.
No
more bollocks protocols!
As I said in the previous
Re: [whatwg] Dealing with UI redress vulnerabilities inherent tothe current web
Hi Rob, You're saying Java's security model is adequate for what people want to do on the Web. I say that is unproven since people are not using Java on the Web. *Why* they are not using Java on the Web is irrelevant. I certainly don't know what's on every web-page out there, but when it comes to Java Applets and the security model, the following recent developments may be of interest (especially the crossdomain stuff): - https://jdk6.dev.java.net/plugin2/ http://weblogs.java.net/blog/joshy/archive/2008/05/java_doodle_cro.html Cheers Richard Maher - Original Message - From: Robert O'Callahan To: [EMAIL PROTECTED] Cc: whatwg@lists.whatwg.org ; Michal Zalewski Sent: Saturday, September 27, 2008 8:38 AM Subject: Re: [whatwg] Dealing with UI redress vulnerabilities inherent tothe current web On Sat, Sep 27, 2008 at 11:55 AM, Elliotte Rusty Harold [EMAIL PROTECTED] wrote: As I said, it's an existence proof. Sun's inability to provide decent developer tools (unlike Adobe) doesn't reflect on the capability of the model. That has nothing to do with it. You're saying Java's security model is adequate for what people want to do on the Web. I say that is unproven since people are not using Java on the Web. *Why* they are not using Java on the Web is irrelevant. In fact, people are doing a lot of things on the Web, using cross-origin IFRAMEs, that are not possible with the Java model. Or maybe you're not saying that. Maybe you're just saying the Java model is secure and not claiming it meets people's needs. In that case, you may be right, but that's not very interesting --- it's easy to come up with safe, simple security models that don't provide the functionality people want. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
[whatwg] WebSocket support in HTML5
Hi, I've been told that this is the correct forum for lobbying/venting about html5 changes; I hope that this is correct? My particular beef is with the intended WebSocket support, and specifically the restrictive nature of its implementation. I respectfully, yet forcefully, suggest that the intended implementation is complete crap and you'd do better to look at existing Socket support from SUN Java, Adobe Flex, and Microsoft Silverlight before engraving anything into stone! What we need (and is a really great idea) is native HTML/JavaScript support for Sockets - What we don't need is someone re-inventing sockets 'cos they think they can do it better. Anyway I find it difficult to not be inflammatory so I'll stop now, but please look to the substance of my complaint (and the original post in comp.lang.JavaScript attached below) and at least question why it is that you are putting all these protocol restriction on binary socket support. Thanks for listening. (and looking forward to UDP and Multicast support in HTML5 :-) Cheers Richard Maher Richard Maher [EMAIL PROTECTED] wrote in message news:... Hi, Also interesting that Flex, SilverLight, and now Java are all adopting the cossdomain.xml standard. It would be nice if Microsoft introduced Socket support in SilverLight but then it's so far behind Flex that it's probably not an issue? While looking for something else in Silverlight yesterday I stumbled across some version 2 beta documentation that says that Microsoft has in fact introduced native Socket support for Silverlight. Yippee! (Albeit TCP only at this stage.) So I once again beseech you - if you know or can influence anybody involved in the HTML5 WebSocket design team, please tell them that they are getting it horribly, horribly wrong! Java, Flex, and now Silverlight are all giving us full-on unrestricted-content binary socket support and yet these knob-heads are tying us up in knots and doing everything they can to make it look/behave like HTTP. I guess that's all they know, or at least all they're used to :-( Please, please, please give us complete access to the same Sockets that have been around for a million years and stop trying to fashion them in your likeness. If you're confined to talking to http servers then by all means stick an additional interface or abstraction on top for those who'll see fit to use it, but there are many of use that have no interest in being shackled by such nonsense. What goes up and down the network connection is our business; not yours! NO MORE BOLLOCKS PROTOCOLS! Cheers Richard Maher Richard Maher [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi Jorge, But client-side Java... is it that stinky cold dying corpse ? That's my kind of rhetoric :-) In this case however I think you'll find Java alive and well. (If more for infrastructure code rather than straight GUI) These links may also be of some interest: - http://weblogs.java.net/blog/joshy/archive/2008/05/java_doodle_cro.html https://jdk6.dev.java.net/plugin2/ If you don't like Java there's always Flex. I believe Flex's Socket support to be rudimentary at best with: - . No connect Timeout . No OOB support . No UDP but if you're already incorporating Flex into your Web apps (or AIR) then why not? (Actually, in this case, I'd still use Java along side Flex and the Adobe FABridge, but each to his own. See http://manson.vistech.net/t3$examples/demo_client_flex.html for an example of getting data from a Java Socket and populating a Flex DataGrid for presentation in Flex charting. Once again, all source including MXML file can be found at http://manson.vistech.net/t3$examples/ ) I'd rather wait for HTML5 If you are refering to WebSockets with HTML5 then I obviously have to say What a great idea!. But what an absolute bollocks implementation :-( If anyone has any input at all with these guys can you please ask them to go back to the drawing board and work out what a socket actually is. Yes, we *want* WebSockets but not some piece o' shit implementation as the God of HTTP would've intended!) Also interesting that Flex, SilverLight, and now Java are all adopting the cossdomain.xml standard. It would be nice if Microsoft introduced Socket support in SilverLight but then it's so far behind Flex that it's probably not an issue? and in the meantime will keep fudging with http/XHRs. Why not, that's what everyone else does; and fudging things what the web's all about :-) Cheers Richard Maher Jorge [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Sep 1, 2:03 am, Richard Maher [EMAIL PROTECTED] wrote: With a context-devoid, *stateless* , pile-of-pooh like HTTP, the options are clearly limited. (...) Richard, the way I see it http has proved to be quite handsome (much more than enough). And lots of things can be done with it
Re: [whatwg] WebSocket support in HTML5
Hi James, Thanks for the reply. [1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-July/015252.html My appologies for only having read the first ten years of that thread :-) Look, I'm not sure exactly what problem you guys are solving with HTML5's WebSockets but I wish you well. What I and *many* others are looking for is native JavaScript support for Sockets a la mode de (SUN Java Applets + Adobe Flex + MIcrosoft Silverlight) that for some strange reason don't seem to be subject to the same imaginary obstacles that are being discussed in that thread. Please explain what security vulnerabilities et al that Adobe, SUN and Microsoft have foisted upon us that the HTML5 people wish to spare us from. If you guys live in a world where nothing but port 80 exists and no one with ever want UDP datagrams (let alone Multicast messages) to their web clients then I have come to the wrong place :-( What goes up and down the network connection is our business not yours. No more bollocks protocols! As I said in the previous post, if you guys want to put a Frame me like ASCII contortion interface/API on top of the JavaScript Sockets (similar to SOAP on HTTP) then go crazy; just don't try to shackle everyone else with the same restrictions. Please see the following for examples of what I am talking about: - http://manson.vistech.net/t3$examples/demo_client_flex.html http://manson.vistech.net/t3$examples/demo_client_web.html In both cases the Username is TIER3_DEMO and the password is QUEUE. Obviously, you can view source for the HTML and Javascript and the Java Applet and MXML source can be found at http://manson.vistech.net/t3$examples/ Once again, you are not introducing something new, but you *are* attempting to introduce support for a tried and tested architecture and you are getting it hopelessly wrong :-( Cheers Richard Maher - Original Message - From: James Graham [EMAIL PROTECTED] To: Richard's Hotmail [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, September 21, 2008 8:46 PM Subject: Re: [whatwg] WebSocket support in HTML5 Richard's Hotmail wrote: Hi, I've been told that this is the correct forum for lobbying/venting about html5 changes; I hope that this is correct? Er, I think it is the correct forum for discussing the spec. I'm less sure that lobbying/venting are useful forms of discussion. My particular beef is with the intended WebSocket support, and specifically the restrictive nature of its implementation. I respectfully, yet forcefully, suggest that the intended implementation is complete crap and you'd do better to look at existing Socket support from SUN Java, Adobe Flex, and Microsoft Silverlight before engraving anything into stone! Nothing is engraved into stone, at least until browsers ship something and are unable to change it because it would adversely affect their marketshare. As far as I am aware there are currently no browser-based implementations of WebSockets, so it is relatively easy to make changes. What we need (and is a really great idea) is native HTML/JavaScript support for Sockets - What we don't need is someone re-inventing sockets 'cos they think they can do it better. You might find [1] helpful for understanding the rationale behind the current WebSockets spec. If you have use cases that cannot be met with the current design, it would be helpful if you could explain the use case and how you can deal with the security issues identified in that email. [1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-July/015252.html -- Eternity's a terrible thought. I mean, where's it all going to end? -- Tom Stoppard, Rosencrantz and Guildenstern are Dead
