[0.9 Proposal] Data Pipelining - good to go?

[Evan Gilbert]

I think all concerns with Data Pipelining have been addressed. Latest proposal is up at http://wiki.opensocial.org/index.php?title=Data_Pipelining.

We had +1s from Kevin, Louis, and me before. Adam was a +1 with concerns which I think have been addressed, but possibly Adam you can verify that you're a +1?

So we're at 3 1/2  +1's ... vote now if you like this or speak up if you still have concerns.

Evan

[Scott Seely]

+1 (the TBD and other items have been addressed)

[Arne Roomann-Kurrik]

+1

--
OpenSocial IRC - irc://irc.freenode.net/opensocial

[Maxwell Newbould]

+1

:max

---

From: opensocial-an...@googlegroups.com
To: opensocial-an...@googlegroups.com
Sent: Tue Dec 02 08:50:26 2008
Subject: [opensocial-and-gadgets-spec] Re: [0.9 Proposal] Data Pipelining - good to go?

[Scott Seely]

We can be closed pending Adam Winer verifying that his concerns are addressed.

[Brian Eaton]

Thanks for addressing the issues I brought up about OAuth parameters
and user prefs. In another thread, you mentioned:

>>>>>>
I think there is a security hole here that needs filling. A malicious
user can manually generate a signed makeRequest from the client, and
set the POST body to be any set of friends. So the friends parameter
in data pipelining is currently untrustworthy, despite the spoof
protection built in to the protocol.

I think that one additional parameter might suffice, saying whether
the request was generated from a makeRequest() or from the server
(data pipelining or proxied content).
<<<<<<<

Have you addressed that hole in the latest proposal?

[Adam Winer]

+1

[Louis Ryan]

Brian,

That hole hasnt been addressed AFAIK.

-Louis

[Scott Seely]

Is this security hole blocking the proposal? I hope it isn’t.

 

We all know that aspects of Data Pipelining are experimental. As we build our implementations, this issue will come up and will be addressed. As we implement the security around this area, we should all be prepared to change the implementation when this issue is specifically addressed by the spec based on experience in v.NEXT. Does that sound reasonable?

 

From: opensocial-an...@googlegroups.com [mailto:opensocial-an...@googlegroups.com] On Behalf Of Louis Ryan
Sent: Tuesday, December 02, 2008 12:26 PM
To: opensocial-an...@googlegroups.com
Subject: [opensocial-and-gadgets-spec] Re: [0.9 Proposal] Data Pipelining - good to go?

 

Brian,

[Brian Eaton]

It seems fairly serious, since it makes all of the data based via
gadgets.io.makeRequest untrustworthy.

[Arne Roomann-Kurrik]

I read the other thread as a separate proposal - (very) nice to have, but not blocking this implementation.

~Arne

On Tue, Dec 2, 2008 at 12:43 PM, Scott Seely <sSe...@myspace.com> wrote:

[Evan Gilbert]

To summarize the security issue: Only viewer ID and owner ID can be trusted. Any data returned for friends has to be assumed to be forgeable, so should only be public data.

I think this shouldn't be a blocker - we can document the limitation. But we should really try to resolve this before we release. Possibly we can flag it as an issue to work out (if possible) during the prototyping phase?

[Scott Seely]

We have the 5 votes—

 

Let’s add the flag. If anyone has issues and feels a need to -1, speak up (today 12-3).

[Brian Eaton]

Agreed it shouldn't block. Data pipelining. Data pipelining
references the JSON-RPC protocol, and we can fix the problems in the
JSON-RPC spec.

On Tue, Dec 2, 2008 at 12:47 PM, Arne Roomann-Kurrik <kur...@google.com> wrote:

[Brian Eaton]

Resurrecting this thread. We should fix this before we declare 0.9 final.

[Adam Winer]

+1. The fix is trivial - add an opensocial_proxied_content=1 query
parameter to proxied content requests. Brian, do you want to write up
a spec patch, or would you like me to?

[Brian Eaton]

I would rather you did it. Thank you.

[Adam Winer]

All, please review:

http://codereview.appspot.com/32091

[Scott Seely]

Can you explain how this stops the malicious user from reading the spec and adding opensocial_proxied_content=1 to their malicious makeRequest? It seems some server behavior is missing.

Even then, I'm pretty sure that this is not the right solution to the problem. It seems that the container and the proxy could/should share an out of band key/secret pair for proxied content that the malicious user couldn't know about. They would have an AppSecret that they use for makeRequest authentication (as it works today) and a ProxySecret that the two use for proxied authentication. The app name would stay the same for both secrets.

> -----Original Message-----
> From: opensocial-an...@googlegroups.com [mailto:opensocial-and-
> gadget...@googlegroups.com] On Behalf Of Adam Winer
> Sent: Tuesday, March 31, 2009 2:26 PM
> To: opensocial-an...@googlegroups.com
> Cc: Adam Winer
> Subject: [opensocial-and-gadgets-spec] Re: [0.9 Proposal] Data Pipelining -
> good to go?
>
>

[Adam Winer]

Gadget servers are already required to strip all opensocial_ query
parameters (along with oauth_ etc.).

The issue of "is this request coming from the container" is addressed
by signed requests.

This is about "what type of signed request is this?"

[Scott Seely]

Line 676: "Servers c an" should be "Servers can"

> -----Original Message-----
> From: opensocial-an...@googlegroups.com [mailto:opensocial-and-
> gadget...@googlegroups.com] On Behalf Of Adam Winer
> Sent: Tuesday, March 31, 2009 2:45 PM
> To: opensocial-an...@googlegroups.com
> Cc: Adam Winer
> Subject: [opensocial-and-gadgets-spec] Re: [0.9 Proposal] Data Pipelining -
> good to go?
>
>

[Adam Winer]

On Tue, Mar 31, 2009 at 2:52 PM, Scott Seely <sSe...@myspace.com> wrote:
>
> Line 676: "Servers c an" should be "Servers can"

It already is - you're seeing a linewrap in codereview, not stray whitespace.