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

On 09/28/2015 09:38 PM, Melvin Carvalho wrote:
>
>
> On 29 September 2015 at 03:19, Dave Longley
> <dlongley@digitalbazaar.com <mailto:dlongley@digitalbazaar.com>> wrote:
>
>     On 09/28/2015 08:21 PM, Harry Halpin wrote:
>     >
>     > There is no disagreement on using URIs to name things (although URIs
>     > clearly are not *actually* decentralized, as they rely on DNS and as
>     > such ICANN).
>
>     Just a quick note that URIs are just identifiers; they are only
>     bound to
>     particular networks via schemes, etc. Your statement is certainly true
>     if we're talking about common HTTP(S) URIs. However, you could use
>     other
>     URIs for decentralized networks that don't have to rely on DNS, though
>     sometimes they do as a bootstrapping mechanism.
>
>
> Yes exactly.  URIs are, to all intents and purposes, decentralized. 
> You can argue that specs themselves are a form of centralization, but
> I dont think it adds anything to this conversation.
>
> Each URI scheme will have it's own set of rules.  People using HTTP
> for example should follow the rules of HTTP for identity, email should
> follow the rules of the mailto: scheme, xmpp that scheme etc.  In this
> sense arguing over how relatively decentralized URIs are, is as much a
> red herring as arguing that the phonetic alphabet is a form of
> centralization.

Of course folks can invent new URI schemes. However, I would add that
the crux of this rather strange argument is that people backing HTTP
URIs for identifiers don't seem to know or really understand how ICANN
or the domain name system works and claim it's some sort of magic
decentralization sauce. Of course, using HTTP URIs is good if someone
wants some identifier to work cross-domain. Nonetheless, I see no reason
URIs can't work with SOP, and they *do* work with SOP in existing widely
used authorization schemes.

The stranger part of this entire anti-SOP argument is the folks claiming
that revealing a single identifier across domains empowers users without
recognizing that a single identifier across multiple domains is useful
for tracking and a security hazard In fact, unless there is very
enforced stringent user-centric controls (and this ignores the history
of users tending to click through pop-ups and failing at key
management), then having a single identifier in the browser that can be
evoked domains is against user privacy by design. Having that have any
interaction with Javascript would then also have serious security
ramifications. Again, I see no reason why any user-centric identifier
can't be made to adapt to SOP, and the burden that it can't should lie
on its advocates.

There's lots of good academic work in this space around how names,
privledge, and separation work and could be improved in WebApps for
user-centric design. I recommend people advocating how breaking SOP is
user-centric please read it [1].

    cheers,
        harry

[1] ftp://trout.cs.washington.edu/tr/2013/11/UW-CSE-13-11-01.PDF

[1]
>
> What is of more practical use is to decide whether your system will
> use primarily email style identifiers (then follow mailto:) or http
> style identifiers (then use http:) or whether you use another system
> (say xmpp:) then document this in your system so that others can work
> together with you.  The URI system is certainly rich enough to cover
> all the systems currently in use to generate a robust and reusable
> social graph, which can form the basis of pretty much any identity
> based use case.
>
> It's curious why we havent solved this in a general sense yet.  I
> would guess that systems with robust social graphs (such as facebook)
> will over time provide compelling demonstrations. 
>  
>
>
>     >
>     > I believe there is a disagreement in terms of accessing the *same*
>     > identifiers from a browser *per user* across the Web. For
>     example, in
>     > using client certificates and other X.509 infrastructure (and
>     > uniquely identifying government eID schemes) without adaptation to
>     > SOP. You could imagine, for example, access different identifiers
>     > (add in an origin to a key derivation function) or even ZKPs
>     > (proofs-of-possession) per user for authentication.
>
>     Here's a link to a previous brief discussion on ZKPs and credentials
>     that may be of interest to readers of this thread:
>
>     https://lists.w3.org/Archives/Public/public-credentials/2015Jun/0015.html
>
>
>     --
>     Dave Longley
>     CTO
>     Digital Bazaar, Inc.
>
>