In https://bugzilla.mozilla.org/show_bug.cgi?id=1028187#c8 , bz requested a longer-term solution for origins for loop pages. He and I chatted last week, and came up with the following as a starting point: Our goal here is to enable building as much of Loop as is practical using existing web tech in semi- or minimally-priviliged execution contexts (e.g. Loop/Social panels, FrameWorkers(?), ServiceWorkers(?)). The longer-term plan wants at least these two things in support of that: * shared origin across separate execution contexts running in panels (as a replacement for the implementation about to land in bug 1028187) * working web URLs (e.g. nsStandardURLs) in rather than nsSimpleURLs for window.location and friends Here are the notes for a proposal from our call: write a new protocol handler, using nsAboutProtocolHandler as a model, but... * use nsStandardURL instead of nsSimpleURI * make URLs mutable * don't bother nesting URIs * no need for unnecessary multiple about module lookup mechanism * maybe write in JS? considerations * URI structure * just look at nsIURL.filePath * don't include port (handler returns -1 for detault port; nsStandardURL handles the rest) * scheme: "moz-loop" * host: "moz-loop-host", or some other such arbitrary thing * make sure protocol flags are secure, given non-nested URIs Feel free to comment on any of the above; I wanted to get it in a bug where the folks likely to care could track it...

> * scheme: "moz-loop" Does this not have more general applicability than just Loop? > * host: "moz-loop-host", or some other such arbitrary thing As a matter of hygiene, I recommend we make this intentionally unresolvable; something like "moz-loop-host.localhost" or "moz-loop-host.invalid".

> Does this not have more general applicability than just Loop? It can, but then we have to design the scheme/host setup, which might need much wider input. > I recommend we make this intentionally unresolvable Good idea.

One of the issues that a recent discussion with TokBox highlighted is that they use localStorage to save and retrieve a unique identifier used for anonymous telemetry purposes. Without this information, they may need to fall back to IP addresses for correlation, which has significantly worse privacy properties.

(In reply to Adam Roach [:abr] from comment #3) > One of the issues that a recent discussion with TokBox highlighted is that > they use localStorage to save and retrieve a unique identifier used for > anonymous telemetry purposes. Without this information, they may need to > fall back to IP addresses for correlation, which has significantly worse > privacy properties. Although it would be ideal to move this over to something like local storage eventually (once we have this origin mess sorted), we're going to put in place an alternate mechanism so that we can address this need immediately; see Bug 1066816.

There is an update on this with OpenTok 2.2.9. See https://bugzilla.mozilla.org/show_bug.cgi?id=1066816

if we start moving to web loading of pages will adjust priority up.

Support for Hello/Loop has been discontinued. https://support.mozilla.org/kb/hello-status Hence closing the old bugs. Thank you for your support.