Closed Bug 1033587 Opened 6 years ago Closed 3 years ago

get more functional and cleaner origins for Loop URLs

Categories

(Hello (Loop) :: Client, defect, P5)

defect

Tracking

(Not tracked)

RESOLVED INCOMPLETE
Blocking Flags:
backlog tech-debt

People

(Reporter: dmose, Unassigned)

References

Details

(Whiteboard: [investigation] [tech-debt])

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.
Whiteboard: [investigation needed][browser]
See Also: → 1028187
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
backlog: --- → Fx38?
if we start moving to web loading of pages will adjust priority up.
Priority: -- → P5
Whiteboard: [investigation needed][browser] → [investigation needed][browser] [tech-debt]
backlog: Fx38? → tech-debt
OS: Mac OS X → All
Hardware: x86 → All
Rank: 55
Whiteboard: [investigation needed][browser] [tech-debt] → [investigation] [tech-debt]
Support for Hello/Loop has been discontinued.

https://support.mozilla.org/kb/hello-status

Hence closing the old bugs. Thank you for your support.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.