Re: WebRTC Service: On temporary call URLs

[Adam Roach]

On 2/19/14 22:32, Martin Thomson wrote:

I think that you need to consider confidentiality here as well.  It might be 
desirable to have the addressing information concealed.  That implies a 
mechanism like: http://tools.ietf.org/html/draft-rescorla-stateless-tokens


You'll note that I employ pretty much that technique exactly, modulo the 
encryption (which I call out in the final paragraph as "not in this 
version, but probably desirable for the next", and which the draft 
concedes is optional) and the use of bitmasks and bloom filters for 
invalidation (since revocation is expected to be exceedingly rare).



That leads to the next concern, which is that committing to a URI format is not 
wise in general because that can dictate server architecture.  If you do as you 
describe (s/http/https), then loop.services.mozilla.com is it.  You can't hand 
out tokens that reference a specific deployment or server, you can't move stuff 
without paying redirect or proxying costs.


Apparently, I was not sufficiently clear. I was not describing client 
behavior in any way whatsoever. I was describing server behavior. The 
intention here is exactly that the client asks for a full URL, and the 
server provides one. The client is in no way involved in synthesis of 
the URL.


--
Adam Roach
Principal Platform Engineer
a...@mozilla.com
+1 650 903 0800 x863
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: WebRTC Service: On temporary call URLs

[Byron Campen]

   Ultimately, we're going to need to hand out a URL that causes a call 
to happen. To make sure you are understood, are you proposing making it 
more "nouny" by doing something like passing out /contact/... URLs that 
lead to a page with enough smarts to create a call (using the same 
token) with a REST API? I can see some advantages of this approach; one 
of these /contact/... urls could lead to a tiny bit of html that is 
basically like an entry in a contact list, containing presence info, an 
icon, and some buttons for placing calls (it might even have a chat 
window). But, this is a bit more involved, and requires more server 
resources. I do hasten to point out that there is nothing that prevents 
us from adding this later on, if we think it would be useful.


   As for the rest of the URL, I don't think anyone is actually 
suggesting we treat these as anything other than opaque URLs; the 
examples are merely that. Basically, we should write the client to 
handle http:// ?.net/{anything well-formed} coming back from the server 
that mints call (or more RESTy) URLs.


Byron

On 2/19/14 8:32 PM, Martin Thomson wrote:

As it stands, I believe that we have two "things" here: a registry of contact 
URIs, and a registry of calls.  So the nouns might be /contact/{token} and /calls/{token}.

That leads to the next concern, which is that committing to a URI format is not 
wise in general because that can dictate server architecture.  If you do as you 
describe (s/http/https), then loop.services.mozilla.com is it.  You can't hand 
out tokens that reference a specific deployment or server, you can't move stuff 
without paying redirect or proxying costs.



___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: WebRTC Service: On temporary call URLs

[Martin Thomson]

I think that you need to consider confidentiality here as well.  It might be 
desirable to have the addressing information concealed.  That implies a 
mechanism like: http://tools.ietf.org/html/draft-rescorla-stateless-tokens

Now for a variation on a well-worn screed that I had to repeat many times while 
I was at Skype...

I think that the general guidance for designing APIs on HTTP is that URLs 
should not represent actions, they should represent things.  So /call/ might be 
OK in the noun sense, but if the intent is to load this with other actions, I 
think that I might have to question the wisdom of that.  Not knowing what these 
implied other actions are makes it hard to assess this properly though.

As it stands, I believe that we have two "things" here: a registry of contact 
URIs, and a registry of calls.  So the nouns might be /contact/{token} and 
/calls/{token}.

That leads to the next concern, which is that committing to a URI format is not 
wise in general because that can dictate server architecture.  If you do as you 
describe (s/http/https), then loop.services.mozilla.com is it.  You can't hand 
out tokens that reference a specific deployment or server, you can't move stuff 
without paying redirect or proxying costs.

Since you are minting tokens anyway, why not provide clients with all the URIs 
they will need, in full, when the token is minted.  Then you can hand clients 
off to https://idontcareabout.loop.services.mozilla.com.itspants.for.me/ and 
change URI layouts and all sorts of magical stuff.  The only fixed part is the 
starting point.

I'll also note that /call/1/... and /call/... are identical in very many 
respects.  The first is revised by increasing 1 to 2, the second by picking 
another name.

(I have a design for a RESTful registrar API if you are at all interested.  I 
built two of those in the past year, it's a fairly straightforward pattern.)

- Original Message -
From: "Adam Roach" 
To: dev-media@lists.mozilla.org
Sent: Wednesday, February 19, 2014 7:52:53 PM
Subject: WebRTC Service: On temporary call URLs

[For the tl;dr, skip down the the line starting "Putting this all 
together."]

I realize that, while I've had a few discussions with people about the 
nature of the temporary calling URLs, I haven't really communicated some 
of the requirements we have around them, and how we can meet those 
requirements.

Users need the ability to revoke a URL that they have passed out -- if 
it, for example, falls into the hands of marketers or people from whom 
they do not wish to receive communications, users need a means to tell 
the server that the URL can no longer be used to reach them. This means 
the calling URLs must be unique each time they are generated; and, 
ideally, will identify the party to whom they were given. This also 
means that the URLs need to be tamper-proof, which implies some form of 
integrity protection.

Second, for this kind of system where users can and will create 
boundless state at a potentially rapid pace, we need to ensure that the 
server is not required to store all that state -- it just doesn't scale. 
This means the calling URLs need to encode all the information necessary 
to identify the called party and the calling party.

Now, revocation is inherently state that we need to store; but 
revocation events should be infrequent. Nonetheless, we don't want to 
store such state in perpetuity, which means all calling URLs need to be 
time bounded: once a URL expires, we can discard any associated 
revocation state. We can also optimize the size of the data we need to 
store for revocation: by including a short, unique serial number in each 
URL, a revocation record can consist simply of that serial number along 
with a date after which the URL is no longer valid (and, consequently, 
after which the revocation can be discarded). Both pieces of information 
are readily available from a URL each time it is used. If we use, say, 
64-bit serials and 32-bit expirations, this requires nominally 96 bits 
of state per revocation, which is pretty cheap.

Ideally, we also want the ability to identify multiple versions of URL 
encodings, should we decide to migrate to include an enhanced scheme in 
the future.

Putting this together, what we want is something that semantically 
evaluates to:

http://authority/action/url-format-version/{serial 
#,caller,callee,expiration,hmac}

Where "hmac" is an HMAC that includes the serial #, the caller, the 
callee, and the expiration. We may find that we want to add more fields 
to the part I have inside brackets here; using an explicit URL format 
versioning allows us to do this very easily.



For example (and this is meant to be illustrative, not normative), a URL 
that is minted to call from "a...@mozilla.com" to "a...@nostrum.com", 
with an expiration of March 1st, 2014 at 21:19:13 CST might crafted 
first by concatenating these three f

Re: WebRTC Service: On temporary call URLs

[Adam Roach]

On 2/19/14 22:03, Timothy B. Terriberry wrote:

Adam Roach  wrote:

Now, revocation is inherently state that we need to store; but
revocation events should be infrequent. Nonetheless, we don't want to


I assume you've thought about just using time-based expiration instead?


The issue is that nuisance calls tend to be repetitive, and if someone 
is getting them on a URL that has, say, one month of validity on it, we 
want them to be able to stop them now, not wait for them to stop a month 
from now.


--
Adam Roach
Principal Platform Engineer
a...@mozilla.com
+1 650 903 0800 x863
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: WebRTC Service: On temporary call URLs

[Timothy B. Terriberry]

Adam Roach  wrote:

Now, revocation is inherently state that we need to store; but
revocation events should be infrequent. Nonetheless, we don't want to


I assume you've thought about just using time-based expiration instead?
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

WebRTC Service: On temporary call URLs

[Adam Roach]

[For the tl;dr, skip down the the line starting "Putting this all 
together."]


I realize that, while I've had a few discussions with people about the 
nature of the temporary calling URLs, I haven't really communicated some 
of the requirements we have around them, and how we can meet those 
requirements.


Users need the ability to revoke a URL that they have passed out -- if 
it, for example, falls into the hands of marketers or people from whom 
they do not wish to receive communications, users need a means to tell 
the server that the URL can no longer be used to reach them. This means 
the calling URLs must be unique each time they are generated; and, 
ideally, will identify the party to whom they were given. This also 
means that the URLs need to be tamper-proof, which implies some form of 
integrity protection.


Second, for this kind of system where users can and will create 
boundless state at a potentially rapid pace, we need to ensure that the 
server is not required to store all that state -- it just doesn't scale. 
This means the calling URLs need to encode all the information necessary 
to identify the called party and the calling party.


Now, revocation is inherently state that we need to store; but 
revocation events should be infrequent. Nonetheless, we don't want to 
store such state in perpetuity, which means all calling URLs need to be 
time bounded: once a URL expires, we can discard any associated 
revocation state. We can also optimize the size of the data we need to 
store for revocation: by including a short, unique serial number in each 
URL, a revocation record can consist simply of that serial number along 
with a date after which the URL is no longer valid (and, consequently, 
after which the revocation can be discarded). Both pieces of information 
are readily available from a URL each time it is used. If we use, say, 
64-bit serials and 32-bit expirations, this requires nominally 96 bits 
of state per revocation, which is pretty cheap.


Ideally, we also want the ability to identify multiple versions of URL 
encodings, should we decide to migrate to include an enhanced scheme in 
the future.


Putting this together, what we want is something that semantically 
evaluates to:


http://authority/action/url-format-version/{serial 
#,caller,callee,expiration,hmac}


Where "hmac" is an HMAC that includes the serial #, the caller, the 
callee, and the expiration. We may find that we want to add more fields 
to the part I have inside brackets here; using an explicit URL format 
versioning allows us to do this very easily.




For example (and this is meant to be illustrative, not normative), a URL 
that is minted to call from "a...@mozilla.com" to "a...@nostrum.com", 
with an expiration of March 1st, 2014 at 21:19:13 CST might crafted 
first by concatenating these three fields together, prepended with a 
serial number (1 in this example):


secret = "Bjqcy:FCwn^1P.s,v9,+;9AN(call_string = base64(concat(state, hmac)) = 
"MTphYnIuY29tOmFkYW0uY29tOjEzOTM3MzAzNTN6Sne6"


This would then be combined with the authority 
("loop.services.mozilla.com"), the action ("call") and the version ("1") 
to create the following url:


http://loop.services.mozilla.com/call/1/MTphYnIuY29tOmFkYW0uY29tOjEzOTM3MzAzNTN6Sne6

(n.b., we probably want to strongly obscure the fields inside the blob 
so as to avoid the ability to back out a called-party's contact 
information -- a...@nostrum.com in this example -- but for MLP, this 
should be sufficient)


--
Adam Roach
Principal Platform Engineer
a...@mozilla.com
+1 650 903 0800 x863
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: Architecture Decisions and Action Items for User-Facing WebRTC Project

[Dan Mosedale]

On 2/19/14 3:31 PM, Adam Roach wrote:

 * Unit testing of client code will be performed with the mochi test
   framework.


The decision I thought I heard was that we were going to go find out 
more about
cross-browser mochitest-ing before a call was made here.  Did I 
misunderstand?



Action Items

 * L: *Nicolas* to examine use of client libraries (jQuery, Backbone)
   to determine how much effort we're likely to save versus the effort
   of ensuring we can run the libraries safely in the context of
   elevated privileges.


After talking with Kaze about MVC stuff, it sounds like there's no 
particular convention in B2G apps for this, and each app does, to some 
extent its own thing.  He suggests talking to James Lal (who wrote the 
B2G calendar, which apparently includes its own hand-rolled framework), 
and who has lots of regular web experience (maybe including general 
mobile) with this stuff as well.



 * V: *Adam* to research possibilities for running part of the code
   with chrome privileges and others with content privileges, so as to
   minimize the exposure to security issues.


Looking at the pdf.js code as possible prior art may be interesting 
here, though it may not be analogous enough to be worthwhile.  See below.



 * V: *Dan* to evaluate the use of s for the use of l10n
   (will all WebRTC browsers have template support?).


I probably didn't communicate this clearly; apologies.  I was actually 
referring to  stuff, which I'm not even sure is a suitable 
for what we want.  I had a bunch of discussions on with folks today, and 
have found something that appears suitable at first blush, as it's used 
in pdf.js (both on desktop and in b2g), as well as for all of b2g. 
 has details.


Dan


___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: Architecture Decisions and Action Items for User-Facing WebRTC Project

[Fabrice Desré]

On 02/19/2014 03:48 PM, Eric Rescorla wrote:
> On Wed, Feb 19, 2014 at 3:31 PM, Adam Roach  wrote:
>>  * We will use github pull requests to ensure that patches are reviewed
>>prior to landing.
>>
> 
> I missed this decision, but it's not really matching what I would have
> expected.
> 
> Rather, I would have expected that every patch would correspond to
> a bugzilla bug, that we would do reviews in bugzilla, and github pushes
> would come with r= as we do now...

fwiw, that's similar to what we do on gaia: bugzilla for all bugs,
reviews either direcly in bugzilla or on github PRs, and pushes with r=...

Fabrice
-- 
Fabrice Desré
b2g team
Mozilla Corporation
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: Architecture Decisions and Action Items for User-Facing WebRTC Project

[Eric Rescorla]

On Wed, Feb 19, 2014 at 3:31 PM, Adam Roach  wrote:

> (Sorry for the long subject -- I think we have a project name picked out,
> but since it hasn't been officially communicated yet, I'm using the
> descriptive term "User-Facing WebRTC Project.")
>
> Based on conversations this morning, we have a number of decisions and
> pending action items for the user-facing product architecture. These are
> summarized below. I've marked action items with a single letter to indicate
> the associated timeframe: "L" for "MLP", and "V" for "MVP" [1].
>
> I have action items recorded for Mark Banner, Nicolas Perriault, Dan
> Mosedale, Eric Rescorla, Alexis Metaireau, and myself.
>
>
>  Client Architecture
>
>
> Decisions
>
>  * The panel JavaScript will ship with the browser and ride the trains,
>at least through MVP.
>  * Local data storage will make use of the IndexedDB API. We may choose
>to wrap it to make it less painful to use.
>  * Unit testing of client code will be performed with the mochi test
>framework.
>
>
> Action Items
>
>  * L: *Adam* to contact Gavin, Dolske, and Shane to determine future
>availability and support for Social API
>  * L: *Mark* to experiment with loading chrome: URLs in the Social API
>to determine whether doing so gives us sufficient elevated privileges.
>  * L: *Nicolas* to examine use of client libraries (jQuery, Backbone)
>to determine how much effort we're likely to save versus the effort
>of ensuring we can run the libraries safely in the context of
>elevated privileges.
>  * V: *Adam* to research possibilities for running part of the code
>with chrome privileges and others with content privileges, so as to
>minimize the exposure to security issues.
>  * V: *Dan* to evaluate the use of s for the use of l10n
>(will all WebRTC browsers have template support?).
>  * L: *EKR* to touch base with Doug to determine tools used to test
>Sync, evaluate applicability to our use cases.
>  * L: *Adam* to contact David Burns and Ted to determine the level of
>effort it would take to make Marionette and Steeplechase work
>together, to facilitate system testing.
>  * L: *Adam* to ask Ted who to contact regarding the prospect of
>running a subset of Mochi tests on Chrome/Chromium.
>  * L: *Adam* to talk to Andreas and Denelle about partner library code
>landing and versioning.
>
>
>  Server Architecture
>
>
> Decisions
>
>  * Development will be performed in node.js
>  * No external libraries are identified for use at this time. Any
>external libraries will be discussed and agreed upon before importing.
>  * Current assumption is that we will use AWS for deployment. This can
>be revisited if circumstances arise that makes that deployment
>environment suboptimal.
>  o As an aside, the ability to run the server code locally is a
>hard requirement.
>  * We will use github pull requests to ensure that patches are reviewed
>prior to landing.
>

I missed this decision, but it's not really matching what I would have
expected.

Rather, I would have expected that every patch would correspond to
a bugzilla bug, that we would do reviews in bugzilla, and github pushes
would come with r= as we do now...

-Ekr

Action Items
>
>  * L: *Adam* to task appropriate party with evaluation of available
>databases.
>  * L: *Alexis* to create repo in under mozilla github; *Adam* to send
>him list of team members so they can be added to the committers.
>  * L: *Mark* to investigate state of github/bugzilla integration.
>
>
>
> 
> [1] That's "Minimum Landable Product" (aka demo) and "Minimum Viable
> Product" for anyone not used to these acronyms.
>
> --
> Adam Roach
> Principal Platform Engineer
> a...@mozilla.com
> +1 650 903 0800 x863
> ___
> dev-media mailing list
> dev-media@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-media
>
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Architecture Decisions and Action Items for User-Facing WebRTC Project

[Adam Roach]

(Sorry for the long subject -- I think we have a project name picked 
out, but since it hasn't been officially communicated yet, I'm using the 
descriptive term "User-Facing WebRTC Project.")


Based on conversations this morning, we have a number of decisions and 
pending action items for the user-facing product architecture. These are 
summarized below. I've marked action items with a single letter to 
indicate the associated timeframe: "L" for "MLP", and "V" for "MVP" [1].


I have action items recorded for Mark Banner, Nicolas Perriault, Dan 
Mosedale, Eric Rescorla, Alexis Metaireau, and myself.



 Client Architecture


Decisions

 * The panel JavaScript will ship with the browser and ride the trains,
   at least through MVP.
 * Local data storage will make use of the IndexedDB API. We may choose
   to wrap it to make it less painful to use.
 * Unit testing of client code will be performed with the mochi test
   framework.


Action Items

 * L: *Adam* to contact Gavin, Dolske, and Shane to determine future
   availability and support for Social API
 * L: *Mark* to experiment with loading chrome: URLs in the Social API
   to determine whether doing so gives us sufficient elevated privileges.
 * L: *Nicolas* to examine use of client libraries (jQuery, Backbone)
   to determine how much effort we're likely to save versus the effort
   of ensuring we can run the libraries safely in the context of
   elevated privileges.
 * V: *Adam* to research possibilities for running part of the code
   with chrome privileges and others with content privileges, so as to
   minimize the exposure to security issues.
 * V: *Dan* to evaluate the use of s for the use of l10n
   (will all WebRTC browsers have template support?).
 * L: *EKR* to touch base with Doug to determine tools used to test
   Sync, evaluate applicability to our use cases.
 * L: *Adam* to contact David Burns and Ted to determine the level of
   effort it would take to make Marionette and Steeplechase work
   together, to facilitate system testing.
 * L: *Adam* to ask Ted who to contact regarding the prospect of
   running a subset of Mochi tests on Chrome/Chromium.
 * L: *Adam* to talk to Andreas and Denelle about partner library code
   landing and versioning.


 Server Architecture


Decisions

 * Development will be performed in node.js
 * No external libraries are identified for use at this time. Any
   external libraries will be discussed and agreed upon before importing.
 * Current assumption is that we will use AWS for deployment. This can
   be revisited if circumstances arise that makes that deployment
   environment suboptimal.
 o As an aside, the ability to run the server code locally is a
   hard requirement.
 * We will use github pull requests to ensure that patches are reviewed
   prior to landing.


Action Items

 * L: *Adam* to task appropriate party with evaluation of available
   databases.
 * L: *Alexis* to create repo in under mozilla github; *Adam* to send
   him list of team members so they can be added to the committers.
 * L: *Mark* to investigate state of github/bugzilla integration.




[1] That's "Minimum Landable Product" (aka demo) and "Minimum Viable 
Product" for anyone not used to these acronyms.


--
Adam Roach
Principal Platform Engineer
a...@mozilla.com
+1 650 903 0800 x863
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media