Re: A Somewhat Critical View of SOP (Same Origin Policy)

On Wed, Sep 30, 2015 at 8:28 PM, Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

> On 2015-09-28 23:29, Alex Russell wrote:
>
>> On Mon, Sep 28, 2015 at 12:48 PM, Anders Rundgren <
>> anders.rundgren.net@gmail.com wrote:
>>
> <snip>
>
>>
>>     I don't see why a proper implementation of Native Messaging couldn't
>>> together
>>>
>> >>     with an equally properly written native extension indeed support
> SOP.
>
>>
>>
>> If by "proper implementation" you mean bi-directional attestation that the
>>
> > native service trusts the origin and that the origin expects a
> conversation
> > with said service (cryptographically), plus mediation by the browser,
> plus
> > exposure to sites directly, then yes that could work -- but not if hosted
> > inside the Extensions platforms as currently understood.
>
> No, that's not my definition of proper implementation.  It is rather based
> on using OS-level assurances that the two end-points (calling web-page,
> and native application) are authentic.
>
> That is, it up to the browser/OS to only permit browser-hosted web-pages
> calling native extensions which also must be vetted for this kind of
> use as well as featuring a manifest that is enforced by the browser/OS.
> This should be pretty close to what Android intents do.
>

Android is more cautionary tale than template for success. But your
description of it also leads me to believe that you don't grok how even
Android creates mutual consent and UI for user control.


> Attesting something to the origin service would [maybe] be cool but this
> applies to any kind of client application (including browsers) which
> is something I gladly leave to the TrustedComputingGroup to cater for :-)


I have spent several minutes trying to unpack that sentence. I give up.


> Which is the long way of saying that citing Native Messaging in this page
>>
> > is either misdirection regarding the current feature or re-definition of
> > terms to mean a hoped-for (but not proposed or implemented) separate
> feature.
>
> It was probably a mistake mentioning it in the Wiki.
>

We agree. Might be best to remove it?


> Regarding proposals I have done considerable efforts getting an open
> discussion
> but it didn't go anywhere.  Mozilla and Microsoft apparently intend to
> implement
> Native Messaging "as is" in Chrome without further ado.   IMO, the current
> system
> does not meet reasonable security-, deployment- and
> functionality-requirements.
>
> Anders
>
>
>
>> Neither are useful in the context of this discussion.
>>
>>     I never said this is what the world wants, I only pointed out this as
>> a possibility.  U2F could for example have been supported this way.
>>
>>     https://github.com/cyberphone/web2native-bridge#api
>>
>>
>>
>>         In an area where there is not only rough consensus and running
>> code, but precise definitions, specifications, and a common nomenclature,
>> this document does a lot of redefining of terms (most notably SOP itself),
>> that is when it's not making slippery slope arguments around the security
>> guarantees SOP can provide and suggesting we give up because SOP is not the
>> universal panacea for all problems.
>>
>>         I can cite some specific examples for the curious, but I'm not
>> going to run the gish gallop.
>>
>>         My only real request for this Wiki page is it be given a more
>> appropriate name, like "Criticisms of the Same-Origin Policy" (which this
>> document confusingly and repeatedly calls "Single-Origin Policy", itself a
>> testiment to the overall degree of misunderstanding happening here)
>>
>>         [1]: http://rationalwiki.org/wiki/Gish_Gallop
>>
>>
>>         --
>>         Tony Arcieri
>>
>>
>>
>>
>