On 27 July 2013 02:18, Daniel Veditz <dved...@mozilla.com> wrote: > Uniformity is indeed important. Are you implying that some other browser > is NOT blocking mixed-content WebSockets? Why is it only Firefox where > you have to do long polling? > > If so we can take that information back to the standards body and > discuss changing the spec (which is probably where this conversation > should happen).
Thanks, Dan. Chrome certainly doesn't block mixed-content WebSockets (just checked their latest nightly). They had a patch, but chose not to commit it. I'm raising this issue with Firefox because I don't know how to talk to IE developers, Chrome works for me, and as I understand the discussion, Firefox was one of the reasons this was added to the spec. It would be great if we could tweak the spec, but I think you're the first people I need to convince to do that! For completeness, we're just checking the whole range of browsers at the moment. >> The second request is a bigger discussion: I think we need a fuller, >> proper way to allow mixed-content XHR/WebSocket. Not all mixed-content >> requests, just some. I recognise the value that browsers provide to >> website developers flagging up when their site is misconfigured, and >> we want these warnings to be on by default. > > I do want to recognize this as a separate point and don't want it to get > buried. Leaving WebSockets aside is it appropriate to treat data > connections as "active" content rather than "passive" content. What do > IE and Chrome (who both block mixed active content) do with XHR? I haven't tested with IE yet. Current Chrome is happy with mixed-content XHR, nightly build displays a warning on load but allows it. This is different to Firefox, where nightly blocks by default and provides a UI to reload the page with mixed XHR enabled (at which point it shows an identical warning to Chrome's). XHR is probably too dangerous to be passive. It's true you can be virtuous with it, but it makes sense to be heavy-handed and treat it as active. It's just too tempting for people to put HTML with script fragments in there. It's clearly very different from an image or stylesheet, which could never be interpreted, whereas (X)HTML can certainly contain executable scripts. It would be possible to treat XHR as active or passive depending on the content-type, so that only the (X)HTML, JavaScript, and SVG types were classed as active, but that might be too much work for a minor bit of behaviour. As I understand from Chromium bugzilla, there are perhaps one or two other types of resource types where you differ on whether it counts as active or passive (some font types?). >> I tentatively suggest a new header: "Access-Control-Security: >> externally-verifiable" (or anything similar). > > That's worth considering. I can clean up my patch and post it in a bugzilla as "X-Access-Control-Security", but perhaps more people need to buy-in before it's worth doing that. Best, Nicholas ----- Nicholas Wilson: nicho...@nicholaswilson.me.uk _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
