The word "Origin"

[Adam Rice]

Reading the comments on https://codereview.chromium.org/1092113006 has made me think we we have overloaded the word "Origin" to mean several different things. This overloading leads to confusion, and confusion is likely to end in security bugs.

The kind of origin that //net usually concerns itself with is a (scheme, host, port) tuple.

There are also origins as defined by RFC6454, which //net should not produce but sometimes needs to consume.

Then there's Origin as defined by https://html.spec.whatwg.org/multipage/browsers.html#origin and  https://url.spec.whatwg.org/#concept-url-origin which //net cannot produce and is not quite the same as RFC6454.

From the point of view of //net, the differences between "whatwg origin" and "RFC6454 origin" are not important, so I suggest we can continue to call them "Origin".

But I think we need a new name for a (scheme, host, port) tuple. I tend to use "endpoint" for a (host, port) tuple, so "protocol endpoint" comes to mind.

Other ideas:

server tuple

truncated URL

{scheme, host, port}

your idea here

Thanks,

Adam

[Ryan Hamilton]

I'm not sure I follow. Clicking on https://url.spec.whatwg.org/#concept-url-origin, I see that for http or https scheme URLs, origin as:

Return a tuple consisting of URL’s scheme, its host, and its default port if its port is the empty string, and its port otherwise.

So in the context of http/https, it sure seems like scheme, host, port really is an origin? Is that not a correct interpretation?

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAHixhFo05rnWXGVevgELbb6kMJBigWotF2BZLtFCVB4BxozFcA%40mail.gmail.com.

[Ryan Sleevi]

On Jun 2, 2015 9:39 AM, "Ryan Hamilton" <r...@chromium.org> wrote:
>
> I'm not sure I follow. Clicking on https://url.spec.whatwg.org/#concept-url-origin, I see that for http or https scheme URLs, origin as:
>
>> Return a tuple consisting of URL’s scheme, its host, and its default port if its port is the empty string, and its port otherwise.
>
>
> So in the context of http/https, it sure seems like scheme, host, port really is an origin? Is that not a correct interpretation?
>

In one definition, but not another.

For example, if an iframe sandbox was loaded, the URL will be https with a scheme and host and port, but the origin will be an opaque identifier.

I absolutely agree that there is overloaded terminology - when it comes to making security decisions and presentation, it is often unclear what the author intended, as some is handled by blink, some is provided by blink, and some is handled by //net and //URL

(Prime example: //URL knows about the origins for filesystem, which is neither a tuple nor 6454, but doesn't know about blob, which follows the same rules and is in the URL living standard)

> On Tue, Jun 2, 2015 at 8:53 AM, 'Adam Rice' via net-dev <net...@chromium.org> wrote:
>>
>> Reading the comments on https://codereview.chromium.org/1092113006 has made me think we we have overloaded the word "Origin" to mean several different things. This overloading leads to confusion, and confusion is likely to end in security bugs.
>>
>> The kind of origin that //net usually concerns itself with is a (scheme, host, port) tuple.
>>
>> There are also origins as defined by RFC6454, which //net should not produce but sometimes needs to consume.
>>
>> Then there's Origin as defined by https://html.spec.whatwg.org/multipage/browsers.html#origin and  https://url.spec.whatwg.org/#concept-url-origin which //net cannot produce and is not quite the same as RFC6454.
>>
>> From the point of view of //net, the differences between "whatwg origin" and "RFC6454 origin" are not important, so I suggest we can continue to call them "Origin".
>>
>> But I think we need a new name for a (scheme, host, port) tuple. I tend to use "endpoint" for a (host, port) tuple, so "protocol endpoint" comes to mind.
>>
>> Other ideas:
>>
>> server tuple
>> truncated URL
>> {scheme, host, port}
>> your idea here
>>
>> Thanks,
>> Adam
>>
>> --
>> You received this message because you are subscribed to the Google Groups "net-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
>> To post to this group, send email to net...@chromium.org.
>> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAHixhFo05rnWXGVevgELbb6kMJBigWotF2BZLtFCVB4BxozFcA%40mail.gmail.com.
>
>
> --
> You received this message because you are subscribed to the Google Groups "net-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
> To post to this group, send email to net...@chromium.org.

> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAJ_4DfSreqnua-J_pNPw8%3DvhpJOJtH72V4w_85aB2um%2BSoaB6Q%40mail.gmail.com.

[Ryan Sleevi]

Oh, and adding Mike too.

Adam, these issues you raised are ones I've also been recently raising (e.g. https://codereview.chromium.org/1147363005/#msg25 and https://codereview.chromium.org/1153763002/ ), so to be clear, I agree with you that it is a very loaded term, even if it seems simple.

[Ryan Hamilton]

On Tue, Jun 2, 2015 at 9:47 AM, Ryan Sleevi <rsl...@chromium.org> wrote:

On Jun 2, 2015 9:39 AM, "Ryan Hamilton" <r...@chromium.org> wrote:
> So in the context of http/https, it sure seems like scheme, host, port really is an origin? Is that not a correct interpretation?

In one definition, but not another.

​I don't think I want to live on this planet any longer!​

 

For example, if an iframe sandbox was loaded, the URL will be https with a scheme and host and port, but the origin will be an opaque identifier.

​Wow. That's just ... wow.​

I absolutely agree that there is overloaded terminology - when it comes to making security decisions and presentation, it is often unclear what the author intended, as some is handled by blink, some is provided by blink, and some is handled by //net and //URL

(Prime example: //URL knows about the origins for filesystem, which is neither a tuple nor 6454, but doesn't know about blob, which follows the same rules and is in the URL living standard)

My head is spinning. 

Do you have any suggestions for what to call {scheme,host,port} in net? I kinda feel like Origin is still a fine name, but I can imagine there are contexts (like those you allude to) where using such a data type name would be misleading. 

I wish I'd taken the blue pill...

[Ryan Sleevi]

On Jun 2, 2015 3:15 PM, "Ryan Hamilton" <r...@chromium.org> wrote:
>
> Do you have any suggestions for what to call {scheme,host,port} in net? I kinda feel like Origin is still a fine name, but I can imagine there are contexts (like those you allude to) where using such a data type name would be misleading. 

Let the bad naming commence!

OriginTuple - always a scheme/host/port. Only viable for Standard URLs (generic URL syntax with a scheme host port). Maybe allowed to be  converted to SerializedOrigin (see below), but not vice versa. Can be created from a GURL, but may fail (e.g. non standard scheme)

SerializedOrigin - bytes on the wire representation. Cannot be converted to other types, because it's a lossy operation. Should probably only be created from SecurityOrigins, since it is inherently the result of a security check.

SecurityOrigin - Blink's full handling of all the web platform features. Can be converted to serializedorigin, but not vice versa. MAY be convertible to OriginTuple, but that may fail, and can't be converted back.

DisplayOrigin - the logical security boundary for things like permissions (see Raymes' thread on security-dev) and has enough context to present to the user. Depends on how that thread settles go figure out what it can be created from.

That's at least four usages with different layering, needs, and interpretations.... Maybe more.

[Ryan Hamilton]

Thanks! That sounds​ reasonable[1]. Out of curiousity, why does the fourth origin have "Display" in the name?

1. Completely insane, but that appears to be the fault of the specs.

[Ryan Sleevi]

On Jun 2, 2015 3:53 PM, "Ryan Hamilton" <r...@chromium.org> wrote:
>
> Thanks! That sounds​ reasonable[1]. Out of curiousity, why does the fourth origin have "Display" in the name?
>
> 1. Completely insane, but that appears to be the fault of the specs.
>

I don't think it's any more insane than overloaded terms like "account" or "principal" in OS security terms. It has a meaning, and a shared concept, but the details are nuanced to the context (e.g. on Linux, there is uid/gid... But also euid and such, on Windows there is the security identifier/SID, but a thread might be impersonating, etc)

Display exists for purposes such as permissions and the like. For example, the sandboxed iframe might have a URL of filesystem:https://foo.example/blah, an opaque origin due to an iframe sandbox, serialized as "null" during a WebSockets exchange because of it, but might have inherited the permissions from (https, foo.example, 443). The last is the thing we'd want to communicate to the user, for example.

Anyways, I wasn't so much looking for agreement as throwing out awful strawmen to be torn apart, since I easily could have misstated things. But even if I'm wrong in a degree of magnitude, it hopefully echoes my agreement with Adam that things are complicated and depend on what layer you're looking at.

[Adam Rice]

On 3 June 2015 at 07:35, Ryan Sleevi <rsl...@chromium.org> wrote:

OriginTuple - always a scheme/host/port. Only viable for Standard URLs (generic URL syntax with a scheme host port). Maybe allowed to be  converted to SerializedOrigin (see below), but not vice versa. Can be created from a GURL, but may fail (e.g. non standard scheme)

My concern with this is that 5 minutes into a meeting someone will stop saying the "Tuple" part to save time, and by the end of the meeting everyone in the room will think they've agreed on something slightly different.

However, as you pointed out, the language of security is full of ambiguous terms, and somehow the world hasn't ended yet.

"Location tuple" is another idea that comes to mind.

Converting an OriginTuple to a SerializedOrigin is fine if you have all the contextual information available to know that this is correct (ie. you are Blink, or the equivalent code in //content in a post-site-isolation world). But I don't think it would ever be correct within //net code. So I would prefer if it was difficult, so people ask "I just want a SerializedOrigin, why is this so hard?" and hopefully find their way to enlightenment.

 

DisplayOrigin - the logical security boundary for things like permissions (see Raymes' thread on security-dev) and has enough context to present to the user. Depends on how that thread settles go figure out what it can be created from.

I had forgotten about this one. What's uncomfortably exciting is that in cases like HTTP Authentication, //net may create a DisplayOrigin.

[Mike West]

+alexmos, +nasko

I've talked with Ryan a bit about this problem, and I think we have something that's approximating a plan. I've outlined an approach in https://docs.google.com/document/d/19NACt9PXOUTJi60klT2ZGcFlgHM5wM1Owtcw2GQOKPI/edit, and started putting some CLs together to explore the space.

Copy/pasting from the doc, the goals are to:

- Provide a clear mechanism for extracting Origin data from GURL.

- Provide a clear mechanism for extracting (scheme, host, port) tuples for GURL for those occasions when an Origin comparison is undesirable (e.g. many callsites in //net which don't want to treat blob:https://example.com/[guid goes here] as equivalent to https://example.com/resource/).

- Update `url::Origin` and `GURL::GetOrigin` callsites to use one of the two mechanisms above, in order to make it clear when an Origin comparison is desirable, and when only schemes, hosts, and ports matter.

- Encapsulate the weirdnesses of Chromium and Blink’s access checks (e.g. `SecurityOrigin::canRequest`, and the various command-line flags  for universal access and the nature of file origins) in `[new component]::OriginAccessPolicy`.

- Update `blink::WebSerializedOrigin` (by killing it in favor of converting `blink::WebSecurityOrigin` to something which can be procesed by `[new component]::OriginAccessPolicy`).

brettw@: Since I hope much of this will live in //url, your input would be especially appreciated. :)

-Mike

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAHixhFqCL_NKFExG43R_0R3FbPozfj2QaqyKoTM5i0NKBUCfxA%40mail.gmail.com.

[Brett Wilson]

This approach seems like a nice improvement.

Brett