On Wed, Jul 18, 2012 at 3:41 AM, Gervase Markham <[email protected]> wrote: > On 12/07/12 04:09, Jonas Sicking wrote: >> I'm told that requiring SSL has been deemed as not ok still. > > I think that's a debate we need to have more widely (or has it > happened)? Facebook's submission to the HTTP 2.0 group, which I happen > to have just read, says: > > "We feel strongly that HTTP/2.0 should require transport encryption, > and we acknowledge that this position is potentially controversial. > > ... > > Regarding our deployment experience, we have deployed TLS at a large > scale using both hardware and software load balancers. We have found > that modern software-based TLS implementations running on commodity > CPUs are fast enough to handle heavy HTTPS traffic load without > needing to resort to dedicated cryptographic hardware. We serve all of > our HTTPS traffic using software running on commodity hardware." > > http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0251.html
Sorry to have dropped this thread. Requiring SSL wouldn't really help us anyway. The problem we are trying to protect against with signing is if the web server gets hacked. Web servers are generally fairly complex and are hard to protect. We should create an application update mechanism where the ability to hack a webserver is all that stands between the attacker, and the ability to automatically get millions of people to automatically get updated to applications that are running malicious code. >>> The "feed://" debacle, which led to a load of non-working URLs on the >>> public web, makes me nervous about this... >> >> Can you point to more information about the "feed:// debacle"? > > http://en.wikipedia.org/wiki/Feed_URI_scheme > > "Critics hold that the purpose of the feed URI scheme is better served > by MIME types, or that it is not a user-friendly solution for the > problem of feed subscription, since a user who has not installed the > appropriate software will receive an unhelpful browser error message on > clicking a link to a feed URI." > > I certainly hit this problem a lot. The first part of a URL is for the > protocol to be used. feed:// broke that by saying "this shows it's a > feed; but you should use HTTP". > > I guess whether it will be a problem or not with app:// depends on > whether you think we will ever see these apps deployed to non-WebRT > browsers. The difference there is that feed:// was just a synonym for http://. Loading from feed:// was exactly the same as loading from http://. The same is not true for app://. Loading from app:// means doing something entirely different from loading from http://. This was the conclusion the webapps WG and even the TAG came to when they created the widget protocol. app:// is much more like file://. But even file:// isn't a synonym for app:// since the latter doesn't have URLs that are relative to the local filesystem. / Jonas _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
