Currently, each container has been generating their own app ids, which means that developers are forced to store the list of what app id matches their app on each container it's deployed on. This means that no matter how careful the developer is to make their app work on multiple containers, they're still stuck with having to insert container specific logic just to validate signed request signatures. Not all containers make getting this app id terribly easy, either.
One solution that's been kicked around a few times is just making the app id equal to the spec xml url. I think this would be the most logical choice for the id:
- Guaranteed to be unique - Can't be forged (unless the container really screwed up!) - Always known to the developer - Easy to correlate in shared abuse / directory systems
url size could be a concern (especially if the original id is being passed in a security token through the renderer), so we could also consider a hash of the url (md5 or sha1 in base16, perhaps) as the id. This has the same basic properties as above, at the slight cost of readability.
Kevin Brown wrote: > Currently, each container has been generating their own app ids, which means > that developers are forced to store the list of what app id matches their > app on each container it's deployed on. This means that no matter how > careful the developer is to make their app work on multiple containers, > they're still stuck with having to insert container specific logic just to > validate signed request signatures. Not all containers make getting this app > id terribly easy, either.
> One solution that's been kicked around a few times is just making the app id > equal to the spec xml url. I think this would be the most logical choice for > the id:
> - Guaranteed to be unique > - Can't be forged (unless the container really screwed up!) > - Always known to the developer > - Easy to correlate in shared abuse / directory systems
> url size could be a concern (especially if the original id is being passed > in a security token through the renderer), so we could also consider a hash > of the url (md5 or sha1 in base16, perhaps) as the id. This has the same > basic properties as above, at the slight cost of readability.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> > One solution that's been kicked around a few times is just making > the app id > > equal to the spec xml url. I think this would be the most logical > choice for > > the id:
> > - Guaranteed to be unique > > - Can't be forged (unless the container really screwed up!) > > - Always known to the developer > > - Easy to correlate in shared abuse / directory systems
On Thu, Apr 3, 2008 at 1:30 AM, Kevin Brown <e...@google.com> wrote: > url size could be a concern (especially if the original id is being passed > in a security token through the renderer), so we could also consider a hash > of the url (md5 or sha1 in base16, perhaps) as the id. This has the same > basic properties as above, at the slight cost of readability.
I'd rather it was the URL than the hash of the URL. The length savings of a hash are relatively minor, and the readability problems are going to increase as opensocial gets more complex and we deal with things like gadgets changing domains and sharing privileges across gadgets.
If we do decide to use a hash function, md5 would be a poor choice. It's not broken for this particular use case, yet, but it could be soon. I think cryptographers are recommending sha256 for most new applications.
On Thu, Apr 3, 2008 at 8:19 AM, Brian Eaton <bea...@google.com> wrote:
> On Thu, Apr 3, 2008 at 1:30 AM, Kevin Brown <e...@google.com> wrote: > > url size could be a concern (especially if the original id is being > passed > > in a security token through the renderer), so we could also consider a > hash > > of the url (md5 or sha1 in base16, perhaps) as the id. This has the same > > basic properties as above, at the slight cost of readability.
> I'd rather it was the URL than the hash of the URL. The length > savings of a hash are relatively minor, and the readability problems > are going to increase as opensocial gets more complex and we deal with > things like gadgets changing domains and sharing privileges across > gadgets.
> If we do decide to use a hash function, md5 would be a poor choice. > It's not broken for this particular use case, yet, but it could be > soon. I think cryptographers are recommending sha256 for most new > applications.
We're not actually concerned about being cryptographically secure for the hash though -- it's just something to make it easier to identify a specific app. The main reason for hashing the url is pure space savings. I don't know what the typical length of a gadget url is though -- if it's around 30 / 40 bytes anyway, the md5 wouldn't be a win anyway (base16 md5 is 32 bytes), but if it's significantly longer it could make a difference.
Kevin Brown wrote: > On Thu, Apr 3, 2008 at 8:19 AM, Brian Eaton <bea...@google.com> wrote:
>> On Thu, Apr 3, 2008 at 1:30 AM, Kevin Brown <e...@google.com> wrote: >>> url size could be a concern (especially if the original id is being >> passed >>> in a security token through the renderer), so we could also consider a >> hash >>> of the url (md5 or sha1 in base16, perhaps) as the id. This has the same >>> basic properties as above, at the slight cost of readability. >> I'd rather it was the URL than the hash of the URL. The length >> savings of a hash are relatively minor, and the readability problems >> are going to increase as opensocial gets more complex and we deal with >> things like gadgets changing domains and sharing privileges across >> gadgets.
>> If we do decide to use a hash function, md5 would be a poor choice. >> It's not broken for this particular use case, yet, but it could be >> soon. I think cryptographers are recommending sha256 for most new >> applications.
> We're not actually concerned about being cryptographically secure for the > hash though -- it's just something to make it easier to identify a specific > app. The main reason for hashing the url is pure space savings. I don't know > what the typical length of a gadget url is though -- if it's around 30 / 40 > bytes anyway, the md5 wouldn't be a win anyway (base16 md5 is 32 bytes), but > if it's significantly longer it could make a difference.
On Thu, Apr 3, 2008 at 11:55 AM, Kevin Brown <e...@google.com> wrote: > We're not actually concerned about being cryptographically secure for the > hash though -- it's just something to make it easier to identify a specific > app.
One of the main reasons to identify the application is security; you only want a particular gadget to pull in user information, not any gadget that user has added.
Exaggerated example: let's say that I have a banking app and a music app on my page. The banking app should have permission to view my account balance, but not the music app. The only way the bank's servers can tell the difference is the application ID.
I agree with Brian, my vote is for using the URL and not a hash. Developers are free to hash the value they get from the container if they want something with a fixed size.
On Thu, Apr 3, 2008 at 8:19 AM, Brian Eaton <bea...@google.com> wrote:
> On Thu, Apr 3, 2008 at 1:30 AM, Kevin Brown <e...@google.com> wrote: > > url size could be a concern (especially if the original id is being > passed > > in a security token through the renderer), so we could also consider a > hash > > of the url (md5 or sha1 in base16, perhaps) as the id. This has the same > > basic properties as above, at the slight cost of readability.
> I'd rather it was the URL than the hash of the URL. The length > savings of a hash are relatively minor, and the readability problems > are going to increase as opensocial gets more complex and we deal with > things like gadgets changing domains and sharing privileges across > gadgets.
> If we do decide to use a hash function, md5 would be a poor choice. > It's not broken for this particular use case, yet, but it could be > soon. I think cryptographers are recommending sha256 for most new > applications.
On Thu, Apr 3, 2008 at 12:42 PM, Reinoud Elhorst <rein...@hyves.nl> wrote:
> Kevin Brown wrote: > > On Thu, Apr 3, 2008 at 8:19 AM, Brian Eaton <bea...@google.com> wrote:
> >> On Thu, Apr 3, 2008 at 1:30 AM, Kevin Brown <e...@google.com> wrote: > >>> url size could be a concern (especially if the original id is being > >> passed > >>> in a security token through the renderer), so we could also consider a > >> hash > >>> of the url (md5 or sha1 in base16, perhaps) as the id. This has the > same > >>> basic properties as above, at the slight cost of readability. > >> I'd rather it was the URL than the hash of the URL. The length > >> savings of a hash are relatively minor, and the readability problems > >> are going to increase as opensocial gets more complex and we deal with > >> things like gadgets changing domains and sharing privileges across > >> gadgets.
> >> If we do decide to use a hash function, md5 would be a poor choice. > >> It's not broken for this particular use case, yet, but it could be > >> soon. I think cryptographers are recommending sha256 for most new > >> applications.
> > We're not actually concerned about being cryptographically secure for > the > > hash though -- it's just something to make it easier to identify a > specific > > app. The main reason for hashing the url is pure space savings. I don't > know > > what the typical length of a gadget url is though -- if it's around 30 / > 40 > > bytes anyway, the md5 wouldn't be a win anyway (base16 md5 is 32 bytes), > but > > if it's significantly longer it could make a difference.
> Can we think of any usecase where one has the id, and needs the url, or > where someone is willing to give out the id, but not the url?
> >> Cheers, > >> Brian
I'm a little confused about what space savings we're talking about -- on the container, or on the gadget's home server? On the container side, it needs to store the full URL anyway (to be able to fetch the gadget XML). This presents obvious opportunities for space savings if a container is worried about the issue -- you don't need to store the URL for each user/app pair, you can normalize it to use an internal 32 bit ID if you want.
On the gadget home server... wouldn't it need to store exactly one string in the most common case?
On Thu, Apr 3, 2008 at 1:36 PM, John Panzer <jpan...@google.com> wrote:
> On Thu, Apr 3, 2008 at 12:42 PM, Reinoud Elhorst <rein...@hyves.nl> wrote:
> > Kevin Brown wrote: > > > On Thu, Apr 3, 2008 at 8:19 AM, Brian Eaton <bea...@google.com> wrote:
> > >> On Thu, Apr 3, 2008 at 1:30 AM, Kevin Brown <e...@google.com> wrote: > > >>> url size could be a concern (especially if the original id is being > > >> passed > > >>> in a security token through the renderer), so we could also consider > > a > > >> hash > > >>> of the url (md5 or sha1 in base16, perhaps) as the id. This has the > > same > > >>> basic properties as above, at the slight cost of readability. > > >> I'd rather it was the URL than the hash of the URL. The length > > >> savings of a hash are relatively minor, and the readability problems > > >> are going to increase as opensocial gets more complex and we deal > > with > > >> things like gadgets changing domains and sharing privileges across > > >> gadgets.
> > >> If we do decide to use a hash function, md5 would be a poor choice. > > >> It's not broken for this particular use case, yet, but it could be > > >> soon. I think cryptographers are recommending sha256 for most new > > >> applications.
> > > We're not actually concerned about being cryptographically secure for > > the > > > hash though -- it's just something to make it easier to identify a > > specific > > > app. The main reason for hashing the url is pure space savings. I > > don't know > > > what the typical length of a gadget url is though -- if it's around 30 > > / 40 > > > bytes anyway, the md5 wouldn't be a win anyway (base16 md5 is 32 > > bytes), but > > > if it's significantly longer it could make a difference.
> > Can we think of any usecase where one has the id, and needs the url, or > > where someone is willing to give out the id, but not the url?
> > >> Cheers, > > >> Brian
> I'm a little confused about what space savings we're talking about -- on > the container, or on the gadget's home server? On the container side, it > needs to store the full URL anyway (to be able to fetch the gadget XML). > This presents obvious opportunities for space savings if a container is > worried about the issue -- you don't need to store the URL for each user/app > pair, you can normalize it to use an internal 32 bit ID if you want.
> On the gadget home server... wouldn't it need to store exactly one string > in the most common case?
The case I was thinking about is for the common token passing mechanism (used by Shindig deployments as well as MySpace) where the url is included in the token. Very long urls would make very long tokens.
Again, though -- if the urls are relatively short on average anyway, this probably don't matter. Standardizing on using urls at all is far more important to me than whether or not we hash them.
+1 for using the URL. This also helps with phishing because I'll know the MyBank app is written by www.mybank.com and not www.evilphisher.com. If the URL is hashed, this info is hidden.
On Thu, Apr 3, 2008 at 1:28 PM, Graham Spencer <g...@google.com> wrote: > I agree with Brian, my vote is for using the URL and not a hash. > Developers are free to hash the value they get from the container if they > want something with a fixed size.
> --g
> On Thu, Apr 3, 2008 at 8:19 AM, Brian Eaton <bea...@google.com> wrote:
> > On Thu, Apr 3, 2008 at 1:30 AM, Kevin Brown <e...@google.com> wrote: > > > url size could be a concern (especially if the original id is being > > passed > > > in a security token through the renderer), so we could also consider a > > hash > > > of the url (md5 or sha1 in base16, perhaps) as the id. This has the > > same > > > basic properties as above, at the slight cost of readability.
> > I'd rather it was the URL than the hash of the URL. The length > > savings of a hash are relatively minor, and the readability problems > > are going to increase as opensocial gets more complex and we deal with > > things like gadgets changing domains and sharing privileges across > > gadgets.
> > If we do decide to use a hash function, md5 would be a poor choice. > > It's not broken for this particular use case, yet, but it could be > > soon. I think cryptographers are recommending sha256 for most new > > applications.
On Thu, Apr 3, 2008 at 2:01 PM, Lane LiaBraaten <lliab...@google.com> wrote: > +1 for using the URL. This also helps with phishing because I'll know the > MyBank app is written by www.mybank.com and not www.evilphisher.com. If > the URL is hashed, this info is hidden.
I'm not sure this makes a huge amount of difference unless we're talking about a container that makes the urls explicitly visible to end users (which is definitely not what i'm proposing). The only people who would be able to take advantage of this are the tech savvy enough who are more likely to avoid the phish in the first place.
> On Thu, Apr 3, 2008 at 1:28 PM, Graham Spencer <g...@google.com> wrote:
> > I agree with Brian, my vote is for using the URL and not a hash. > > Developers are free to hash the value they get from the container if they > > want something with a fixed size.
> > --g
> > On Thu, Apr 3, 2008 at 8:19 AM, Brian Eaton <bea...@google.com> wrote:
> > > On Thu, Apr 3, 2008 at 1:30 AM, Kevin Brown <e...@google.com> wrote: > > > > url size could be a concern (especially if the original id is being > > > passed > > > > in a security token through the renderer), so we could also consider > > > a hash > > > > of the url (md5 or sha1 in base16, perhaps) as the id. This has the > > > same > > > > basic properties as above, at the slight cost of readability.
> > > I'd rather it was the URL than the hash of the URL. The length > > > savings of a hash are relatively minor, and the readability problems > > > are going to increase as opensocial gets more complex and we deal with > > > things like gadgets changing domains and sharing privileges across > > > gadgets.
> > > If we do decide to use a hash function, md5 would be a poor choice. > > > It's not broken for this particular use case, yet, but it could be > > > soon. I think cryptographers are recommending sha256 for most new > > > applications.
On Thu, Apr 3, 2008 at 2:07 PM, Kevin Brown <e...@google.com> wrote: > On Thu, Apr 3, 2008 at 2:01 PM, Lane LiaBraaten <lliab...@google.com> > wrote:
> > +1 for using the URL. This also helps with phishing because I'll know > > the MyBank app is written by www.mybank.com and not www.evilphisher.com. > > If the URL is hashed, this info is hidden.
> I'm not sure this makes a huge amount of difference unless we're talking > about a container that makes the urls explicitly visible to end users (which > is definitely not what i'm proposing). The only people who would be able to > take advantage of this are the tech savvy enough who are more likely to > avoid the phish in the first place.
> > On Thu, Apr 3, 2008 at 1:28 PM, Graham Spencer <g...@google.com> wrote:
> > > I agree with Brian, my vote is for using the URL and not a hash. > > > Developers are free to hash the value they get from the container if they > > > want something with a fixed size.
> > > --g
> > > On Thu, Apr 3, 2008 at 8:19 AM, Brian Eaton <bea...@google.com> wrote:
> > > > On Thu, Apr 3, 2008 at 1:30 AM, Kevin Brown <e...@google.com> wrote: > > > > > url size could be a concern (especially if the original id is > > > > being passed > > > > > in a security token through the renderer), so we could also > > > > consider a hash > > > > > of the url (md5 or sha1 in base16, perhaps) as the id. This has > > > > the same > > > > > basic properties as above, at the slight cost of readability.
> > > > I'd rather it was the URL than the hash of the URL. The length > > > > savings of a hash are relatively minor, and the readability problems > > > > are going to increase as opensocial gets more complex and we deal > > > > with > > > > things like gadgets changing domains and sharing privileges across > > > > gadgets.
> > > > If we do decide to use a hash function, md5 would be a poor choice. > > > > It's not broken for this particular use case, yet, but it could be > > > > soon. I think cryptographers are recommending sha256 for most new > > > > applications.
On Thu, Apr 3, 2008 at 2:21 PM, Lane LiaBraaten <lliab...@google.com> wrote: > Developers often want to create URLs to their app, which includes the appid > (for example, on orkut this is > http://sandbox.orkut.com/Application.aspx?uid=YYYYYY&appId=XXXXXXXXX) so the > app is visible to users, right?
In theory, sure. In practice people are going to notice the bouncing frogs on their screen before they read the URL bar.
On Thu, Apr 3, 2008 at 2:21 PM, Lane LiaBraaten <lliab...@google.com> wrote:
> On Thu, Apr 3, 2008 at 2:07 PM, Kevin Brown <e...@google.com> wrote:
> > On Thu, Apr 3, 2008 at 2:01 PM, Lane LiaBraaten <lliab...@google.com> > > wrote:
> > > +1 for using the URL. This also helps with phishing because I'll know > > > the MyBank app is written by www.mybank.com and not > > > www.evilphisher.com. If the URL is hashed, this info is hidden.
> > I'm not sure this makes a huge amount of difference unless we're talking > > about a container that makes the urls explicitly visible to end users (which > > is definitely not what i'm proposing). The only people who would be able to > > take advantage of this are the tech savvy enough who are more likely to > > avoid the phish in the first place.
> Fair enough.
> > This change would primarily benefit developers.
Sorry, I wasn't actually advocating that we necessarily require it in the main site's url. We can do that if so desired, but I was actually only concerned with the way that appid is referenced in opensocial js / restful calls, signing, etc.
Standardizing the parameter on websites might be nice, but you have to do per-container wiring there anyway. There's another thread going on related to this very issue though (brought up by Nat from ilike).
> > > On Thu, Apr 3, 2008 at 1:28 PM, Graham Spencer <g...@google.com> wrote:
> > > > I agree with Brian, my vote is for using the URL and not a hash. > > > > Developers are free to hash the value they get from the container if they > > > > want something with a fixed size.
> > > > --g
> > > > On Thu, Apr 3, 2008 at 8:19 AM, Brian Eaton <bea...@google.com> > > > > wrote:
> > > > > On Thu, Apr 3, 2008 at 1:30 AM, Kevin Brown <e...@google.com> > > > > > wrote: > > > > > > url size could be a concern (especially if the original id is > > > > > being passed > > > > > > in a security token through the renderer), so we could also > > > > > consider a hash > > > > > > of the url (md5 or sha1 in base16, perhaps) as the id. This has > > > > > the same > > > > > > basic properties as above, at the slight cost of readability.
> > > > > I'd rather it was the URL than the hash of the URL. The length > > > > > savings of a hash are relatively minor, and the readability > > > > > problems > > > > > are going to increase as opensocial gets more complex and we deal > > > > > with > > > > > things like gadgets changing domains and sharing privileges across > > > > > gadgets.
> > > > > If we do decide to use a hash function, md5 would be a poor > > > > > choice. > > > > > It's not broken for this particular use case, yet, but it could be > > > > > soon. I think cryptographers are recommending sha256 for most new > > > > > applications.
Okay, so overall it looks like we have a lot of happy agreement on the fact that containers should be using the gadget xml url as the app id.
So, do we want the spec to actually enforce this? The only place I can actually find it being used is in the makeRequest function. We pass an app id to developers, and we would change the spec to say this:
* - opensocial_app_id The url of the xml file for the current app
Is there anything else we need to do here or is it just the makeRequest function? Thanks.
On Fri, Apr 4, 2008 at 12:42 AM, Kevin Brown <e...@google.com> wrote: > On Thu, Apr 3, 2008 at 2:21 PM, Lane LiaBraaten <lliab...@google.com> wrote:
>> On Thu, Apr 3, 2008 at 2:07 PM, Kevin Brown <e...@google.com> wrote:
>>> On Thu, Apr 3, 2008 at 2:01 PM, Lane LiaBraaten <lliab...@google.com> >>> wrote:
>>>> +1 for using the URL. This also helps with phishing because I'll know >>>> the MyBank app is written by www.mybank.com and not www.evilphisher.com. If >>>> the URL is hashed, this info is hidden.
>>> I'm not sure this makes a huge amount of difference unless we're talking >>> about a container that makes the urls explicitly visible to end users (which >>> is definitely not what i'm proposing). The only people who would be able to >>> take advantage of this are the tech savvy enough who are more likely to >>> avoid the phish in the first place.
>> Fair enough.
>>> This change would primarily benefit developers.
> Sorry, I wasn't actually advocating that we necessarily require it in the > main site's url. We can do that if so desired, but I was actually only > concerned with the way that appid is referenced in opensocial js / restful > calls, signing, etc.
> Standardizing the parameter on websites might be nice, but you have to do > per-container wiring there anyway. There's another thread going on related > to this very issue though (brought up by Nat from ilike).
>> -Lane
>>>> -Lane
>>>> On Thu, Apr 3, 2008 at 1:28 PM, Graham Spencer <g...@google.com> wrote:
>>>>> I agree with Brian, my vote is for using the URL and not a hash. >>>>> Developers are free to hash the value they get from the container if they >>>>> want something with a fixed size.
>>>>> --g
>>>>> On Thu, Apr 3, 2008 at 8:19 AM, Brian Eaton <bea...@google.com> wrote:
>>>>>> On Thu, Apr 3, 2008 at 1:30 AM, Kevin Brown <e...@google.com> wrote: >>>>>> > url size could be a concern (especially if the original id is being >>>>>> > passed >>>>>> > in a security token through the renderer), so we could also consider >>>>>> > a hash >>>>>> > of the url (md5 or sha1 in base16, perhaps) as the id. This has the >>>>>> > same >>>>>> > basic properties as above, at the slight cost of readability.
>>>>>> I'd rather it was the URL than the hash of the URL. The length >>>>>> savings of a hash are relatively minor, and the readability problems >>>>>> are going to increase as opensocial gets more complex and we deal with >>>>>> things like gadgets changing domains and sharing privileges across >>>>>> gadgets.
>>>>>> If we do decide to use a hash function, md5 would be a poor choice. >>>>>> It's not broken for this particular use case, yet, but it could be >>>>>> soon. I think cryptographers are recommending sha256 for most new >>>>>> applications.
wait. I just joined this group and stumbled onto this thread, can
someone answer my concern:
What if we have to change url schemes (technical reasons) or top level
domains ( changing company name ), what would be the procedure to move
all users from old app xml to new app xml without losing all users?
other scenarios:
What if some/all containers begin to to hard caching of the gadget
xml, but we have to push out a change. So after deploy we go and
update gadget xmls on containers to make sure they pull in the latest
version.. did we create a brand new app that can't access old users?
etc etc
This sounds scary and I would ask people to think about issues where
"app != gadget xml" before codifying something like this. So what
defines and "app" and what defines a particular "implementation of an
app". Much like I can define f...@domain.com, but totally change the
MX record, the mail server implementation, hosting, etc etc..
thank you.
On Apr 14, 6:10 am, Cassie <d...@google.com> wrote:
> Okay, so overall it looks like we have a lot of happy agreement on the
> fact that containers should be using the gadget xml url as the app id.
> So, do we want the spec to actually enforce this? The only place I can
> actually find it being used is in the makeRequest function. We pass an
> app id to developers, and we would change the spec to say this:
> * - opensocial_app_id The url of the xml file for the current app
> Is there anything else we need to do here or is it just the
> makeRequest function?
> Thanks.
> - Cassie
> On Fri, Apr 4, 2008 at 12:42 AM, Kevin Brown <e...@google.com> wrote:
> > On Thu, Apr 3, 2008 at 2:21 PM, Lane LiaBraaten <lliab...@google.com> wrote:
> >> On Thu, Apr 3, 2008 at 2:07 PM, Kevin Brown <e...@google.com> wrote:
> >>> On Thu, Apr 3, 2008 at 2:01 PM, Lane LiaBraaten <lliab...@google.com>
> >>> wrote:
> >>>> +1 for using the URL. This also helps with phishing because I'll know
> >>>> the MyBank app is written bywww.mybank.comand notwww.evilphisher.com. If
> >>>> the URL is hashed, this info is hidden.
> >>> I'm not sure this makes a huge amount of difference unless we're talking
> >>> about a container that makes the urls explicitly visible to end users (which
> >>> is definitely not what i'm proposing). The only people who would be able to
> >>> take advantage of this are the tech savvy enough who are more likely to
> >>> avoid the phish in the first place.
> >> Fair enough.
> >>> This change would primarily benefit developers.
> > Sorry, I wasn't actually advocating that we necessarily require it in the
> > main site's url. We can do that if so desired, but I was actually only
> > concerned with the way that appid is referenced in opensocial js / restful
> > calls, signing, etc.
> > Standardizing the parameter on websites might be nice, but you have to do
> > per-container wiring there anyway. There's another thread going on related
> > to this very issue though (brought up by Nat from ilike).
> >> -Lane
> >>>> -Lane
> >>>> On Thu, Apr 3, 2008 at 1:28 PM, Graham Spencer <g...@google.com> wrote:
> >>>>> I agree with Brian, my vote is for using the URL and not a hash.
> >>>>> Developers are free to hash the value they get from the container if they
> >>>>> want something with a fixed size.
> >>>>> --g
> >>>>> On Thu, Apr 3, 2008 at 8:19 AM, Brian Eaton <bea...@google.com> wrote:
> >>>>>> On Thu, Apr 3, 2008 at 1:30 AM, Kevin Brown <e...@google.com> wrote:
> >>>>>> > url size could be a concern (especially if the original id is being
> >>>>>> > passed
> >>>>>> > in a security token through the renderer), so we could also consider
> >>>>>> > a hash
> >>>>>> > of the url (md5 or sha1 in base16, perhaps) as the id. This has the
> >>>>>> > same
> >>>>>> > basic properties as above, at the slight cost of readability.
> >>>>>> I'd rather it was the URL than the hash of the URL. The length
> >>>>>> savings of a hash are relatively minor, and the readability problems
> >>>>>> are going to increase as opensocial gets more complex and we deal with
> >>>>>> things like gadgets changing domains and sharing privileges across
> >>>>>> gadgets.
> >>>>>> If we do decide to use a hash function, md5 would be a poor choice.
> >>>>>> It's not broken for this particular use case, yet, but it could be
> >>>>>> soon. I think cryptographers are recommending sha256 for most new
> >>>>>> applications.
As i understand the open social API at the moment, there is nothing in it that deals with these types of scenarios.
As it stands now, a simplest Open Social compliant site could just have a text field where people past a url to the gadget.xml, the site stores this url and renders it on the person's page. Now in that scenario, were you to change the URL in any way shape or form, the renderer would simply give you a 'Failed to retrieve gadget content' error.
A few musings on the possibilities:
So say you wanted to solve that situation by having an meaningful app id, you would need to have a central registry (which is not at all a part of open social at the moment) to track this app id and what URL belongs to it, which means someone would have to build and maintain the infrastructure for it, and take responsibility for it ... and others (from other geographical and thus political regions) would have to depend on that registry to be able to function ... plus all current and future social sites would have to connect to this service to be able to become an open social container.
To me that sounds like a lot of work and with a few possible thorns attached too
Alternate scenario's i could think if would be to have the app id be only meaningful inside of one social site, but that would mean gadget creators would have to contact each social container, and that could be thousands at some point for all you know, to get their url's updated.. Not a workable situation either.
The alternative of letting a gadget set it's own ID in its meta data (xml) is even more scary, because it would mean any gadget could spoof the app id, and get to information it has no business getting too.. So that has to be the worst possible solution :)
The only semi workable solution i could think of is to mimic HTTP a bit (301: Moved Permanently) and allow for a 'Moved to this new URL' field in the gadget spec, and specify that on receiving this code, the social container should update its database and use the new URL. (And the gadget renderer would need some form of communication / write access to the social container ... which are probably 2 very separate systems), so that would complicate things a bit, especially for the write access to the container bit, but somewhat viable i guess..
Now it's well possible i missed something obvious here, or other possible solutions, however none of the things i was able to think of would be a 'minor change' as far as the impact on the specification, and current implementation goes.
-- Chris
On Apr 14, 2008, at 7:05 PM, fern...@gmail.com wrote:
> wait. I just joined this group and stumbled onto this thread, can > someone answer my concern:
> What if we have to change url schemes (technical reasons) or top level > domains ( changing company name ), what would be the procedure to move > all users from old app xml to new app xml without losing all users?
> other scenarios:
> What if some/all containers begin to to hard caching of the gadget > xml, but we have to push out a change. So after deploy we go and > update gadget xmls on containers to make sure they pull in the latest > version.. did we create a brand new app that can't access old users? > etc etc
> This sounds scary and I would ask people to think about issues where > "app != gadget xml" before codifying something like this. So what > defines and "app" and what defines a particular "implementation of an > app". Much like I can define f...@domain.com, but totally change the > MX record, the mail server implementation, hosting, etc etc..
> thank you.
> On Apr 14, 6:10 am, Cassie <d...@google.com> wrote: >> Okay, so overall it looks like we have a lot of happy agreement on >> the >> fact that containers should be using the gadget xml url as the app >> id.
>> So, do we want the spec to actually enforce this? The only place I >> can >> actually find it being used is in the makeRequest function. We pass >> an >> app id to developers, and we would change the spec to say this:
>> * - opensocial_app_id The url of the xml file for the current >> app
>> Is there anything else we need to do here or is it just the >> makeRequest function? >> Thanks.
>> - Cassie
>> On Fri, Apr 4, 2008 at 12:42 AM, Kevin Brown <e...@google.com> wrote: >>> On Thu, Apr 3, 2008 at 2:21 PM, Lane LiaBraaten >>> <lliab...@google.com> wrote:
>>>> On Thu, Apr 3, 2008 at 2:07 PM, Kevin Brown <e...@google.com> >>>> wrote:
>>>>> On Thu, Apr 3, 2008 at 2:01 PM, Lane LiaBraaten >>>>> <lliab...@google.com> >>>>> wrote:
>>>>>> +1 for using the URL. This also helps with phishing because >>>>>> I'll know >>>>>> the MyBank app is written bywww.mybank.comand >>>>>> notwww.evilphisher.com. If >>>>>> the URL is hashed, this info is hidden.
>>>>> I'm not sure this makes a huge amount of difference unless we're >>>>> talking >>>>> about a container that makes the urls explicitly visible to end >>>>> users (which >>>>> is definitely not what i'm proposing). The only people who would >>>>> be able to >>>>> take advantage of this are the tech savvy enough who are more >>>>> likely to >>>>> avoid the phish in the first place.
>>>> Fair enough.
>>>>> This change would primarily benefit developers.
>>> Sorry, I wasn't actually advocating that we necessarily require it >>> in the >>> main site's url. We can do that if so desired, but I was actually >>> only >>> concerned with the way that appid is referenced in opensocial js / >>> restful >>> calls, signing, etc.
>>> Standardizing the parameter on websites might be nice, but you >>> have to do >>> per-container wiring there anyway. There's another thread going on >>> related >>> to this very issue though (brought up by Nat from ilike).
>>>> -Lane
>>>>>> -Lane
>>>>>> On Thu, Apr 3, 2008 at 1:28 PM, Graham Spencer >>>>>> <g...@google.com> wrote:
>>>>>>> I agree with Brian, my vote is for using the URL and not a hash. >>>>>>> Developers are free to hash the value they get from the >>>>>>> container if they >>>>>>> want something with a fixed size.
>>>>>>> --g
>>>>>>> On Thu, Apr 3, 2008 at 8:19 AM, Brian Eaton >>>>>>> <bea...@google.com> wrote:
>>>>>>>> On Thu, Apr 3, 2008 at 1:30 AM, Kevin Brown <e...@google.com> >>>>>>>> wrote: >>>>>>>>> url size could be a concern (especially if the original id >>>>>>>>> is being >>>>>>>>> passed >>>>>>>>> in a security token through the renderer), so we could also >>>>>>>>> consider >>>>>>>>> a hash >>>>>>>>> of the url (md5 or sha1 in base16, perhaps) as the id. This >>>>>>>>> has the >>>>>>>>> same >>>>>>>>> basic properties as above, at the slight cost of readability.
>>>>>>>> I'd rather it was the URL than the hash of the URL. The length >>>>>>>> savings of a hash are relatively minor, and the readability >>>>>>>> problems >>>>>>>> are going to increase as opensocial gets more complex and we >>>>>>>> deal with >>>>>>>> things like gadgets changing domains and sharing privileges >>>>>>>> across >>>>>>>> gadgets.
>>>>>>>> If we do decide to use a hash function, md5 would be a poor >>>>>>>> choice. >>>>>>>> It's not broken for this particular use case, yet, but it >>>>>>>> could be >>>>>>>> soon. I think cryptographers are recommending sha256 for >>>>>>>> most new >>>>>>>> applications.
I guess the question on the table, is do others feels these scenarios
I proposed are important or not. I just feel scared that once I
publish a url, I'll never be able to change it, a little scary.
Does anyone else have any ideas on how to communicate to containers to
tell them that the old APP should point to a new gadgetxml url?
On Apr 14, 10:27 am, Chris Chabot <chab...@xs4all.nl> wrote:
> As i understand the open social API at the moment, there is nothing in
> it that deals with these types of scenarios.
> As it stands now, a simplest Open Social compliant site could just
> have a text field where people past a url to the gadget.xml, the site
> stores this url and renders it on the person's page. Now in that
> scenario, were you to change the URL in any way shape or form, the
> renderer would simply give you a 'Failed to retrieve gadget content'
> error.
> A few musings on the possibilities:
> So say you wanted to solve that situation by having an meaningful app
> id, you would need to have a central registry (which is not at all a
> part of open social at the moment) to track this app id and what URL
> belongs to it, which means someone would have to build and maintain
> the infrastructure for it, and take responsibility for it ... and
> others (from other geographical and thus political regions) would have
> to depend on that registry to be able to function ... plus all current
> and future social sites would have to connect to this service to be
> able to become an open social container.
> To me that sounds like a lot of work and with a few possible thorns
> attached too
> Alternate scenario's i could think if would be to have the app id be
> only meaningful inside of one social site, but that would mean gadget
> creators would have to contact each social container, and that could
> be thousands at some point for all you know, to get their url's
> updated.. Not a workable situation either.
> The alternative of letting a gadget set it's own ID in its meta data
> (xml) is even more scary, because it would mean any gadget could spoof
> the app id, and get to information it has no business getting too.. So
> that has to be the worst possible solution :)
> The only semi workable solution i could think of is to mimic HTTP a
> bit (301: Moved Permanently) and allow for a 'Moved to this new URL'
> field in the gadget spec, and specify that on receiving this code, the
> social container should update its database and use the new URL. (And
> the gadget renderer would need some form of communication / write
> access to the social container ... which are probably 2 very separate
> systems), so that would complicate things a bit, especially for the
> write access to the container bit, but somewhat viable i guess..
> Now it's well possible i missed something obvious here, or other
> possible solutions, however none of the things i was able to think of
> would be a 'minor change' as far as the impact on the specification,
> and current implementation goes.
> -- Chris
> On Apr 14, 2008, at 7:05 PM, fern...@gmail.com wrote:
> > wait. I just joined this group and stumbled onto this thread, can
> > someone answer my concern:
> > What if we have to change url schemes (technical reasons) or top level
> > domains ( changing company name ), what would be the procedure to move
> > all users from old app xml to new app xml without losing all users?
> > other scenarios:
> > What if some/all containers begin to to hard caching of the gadget
> > xml, but we have to push out a change. So after deploy we go and
> > update gadget xmls on containers to make sure they pull in the latest
> > version.. did we create a brand new app that can't access old users?
> > etc etc
> > This sounds scary and I would ask people to think about issues where
> > "app != gadget xml" before codifying something like this. So what
> > defines and "app" and what defines a particular "implementation of an
> > app". Much like I can define f...@domain.com, but totally change the
> > MX record, the mail server implementation, hosting, etc etc..
> > thank you.
> > On Apr 14, 6:10 am, Cassie <d...@google.com> wrote:
> >> Okay, so overall it looks like we have a lot of happy agreement on
> >> the
> >> fact that containers should be using the gadget xml url as the app
> >> id.
> >> So, do we want the spec to actually enforce this? The only place I
> >> can
> >> actually find it being used is in the makeRequest function. We pass
> >> an
> >> app id to developers, and we would change the spec to say this:
> >> * - opensocial_app_id The url of the xml file for the current
> >> app
> >> Is there anything else we need to do here or is it just the
> >> makeRequest function?
> >> Thanks.
> >> - Cassie
> >> On Fri, Apr 4, 2008 at 12:42 AM, Kevin Brown <e...@google.com> wrote:
> >>> On Thu, Apr 3, 2008 at 2:21 PM, Lane LiaBraaten
> >>> <lliab...@google.com> wrote:
> >>>> On Thu, Apr 3, 2008 at 2:07 PM, Kevin Brown <e...@google.com>
> >>>> wrote:
> >>>>> On Thu, Apr 3, 2008 at 2:01 PM, Lane LiaBraaten
> >>>>> <lliab...@google.com>
> >>>>> wrote:
> >>>>>> +1 for using the URL. This also helps with phishing because
> >>>>>> I'll know
> >>>>>> the MyBank app is written bywww.mybank.comand > >>>>>> notwww.evilphisher.com. If
> >>>>>> the URL is hashed, this info is hidden.
> >>>>> I'm not sure this makes a huge amount of difference unless we're
> >>>>> talking
> >>>>> about a container that makes the urls explicitly visible to end
> >>>>> users (which
> >>>>> is definitely not what i'm proposing). The only people who would
> >>>>> be able to
> >>>>> take advantage of this are the tech savvy enough who are more
> >>>>> likely to
> >>>>> avoid the phish in the first place.
> >>>> Fair enough.
> >>>>> This change would primarily benefit developers.
> >>> Sorry, I wasn't actually advocating that we necessarily require it
> >>> in the
> >>> main site's url. We can do that if so desired, but I was actually
> >>> only
> >>> concerned with the way that appid is referenced in opensocial js /
> >>> restful
> >>> calls, signing, etc.
> >>> Standardizing the parameter on websites might be nice, but you
> >>> have to do
> >>> per-container wiring there anyway. There's another thread going on
> >>> related
> >>> to this very issue though (brought up by Nat from ilike).
> >>>> -Lane
> >>>>>> -Lane
> >>>>>> On Thu, Apr 3, 2008 at 1:28 PM, Graham Spencer
> >>>>>> <g...@google.com> wrote:
> >>>>>>> I agree with Brian, my vote is for using the URL and not a hash.
> >>>>>>> Developers are free to hash the value they get from the
> >>>>>>> container if they
> >>>>>>> want something with a fixed size.
> >>>>>>> --g
> >>>>>>> On Thu, Apr 3, 2008 at 8:19 AM, Brian Eaton
> >>>>>>> <bea...@google.com> wrote:
> >>>>>>>> On Thu, Apr 3, 2008 at 1:30 AM, Kevin Brown <e...@google.com>
> >>>>>>>> wrote:
> >>>>>>>>> url size could be a concern (especially if the original id
> >>>>>>>>> is being
> >>>>>>>>> passed
> >>>>>>>>> in a security token through the renderer), so we could also
> >>>>>>>>> consider
> >>>>>>>>> a hash
> >>>>>>>>> of the url (md5 or sha1 in base16, perhaps) as the id. This
> >>>>>>>>> has the
> >>>>>>>>> same
> >>>>>>>>> basic properties as above, at the slight cost of readability.
> >>>>>>>> I'd rather it was the URL than the hash of the URL. The length
> >>>>>>>> savings of a hash are relatively minor, and the readability
> >>>>>>>> problems
> >>>>>>>> are going to increase as opensocial gets more complex and we
> >>>>>>>> deal with
> >>>>>>>> things like gadgets changing domains and sharing privileges
> >>>>>>>> across
> >>>>>>>> gadgets.
> >>>>>>>> If we do decide to use a hash function, md5 would be a poor
> >>>>>>>> choice.
> >>>>>>>> It's not broken for this particular use case, yet, but it
> >>>>>>>> could be
> >>>>>>>> soon. I think cryptographers are recommending sha256 for
> >>>>>>>> most new
> >>>>>>>> applications.
[mailto:opensocial-and-gadgets-spec@googlegroups.com] On Behalf Of Cassie Sent: Monday, April 14, 2008 6:11 AM To: opensocial-and-gadgets-spec@googlegroups.com Subject: Re: Standardizing app id.
Okay, so overall it looks like we have a lot of happy agreement on the fact that containers should be using the gadget xml url as the app id.
So, do we want the spec to actually enforce this? The only place I can actually find it being used is in the makeRequest function. We pass an app id to developers, and we would change the spec to say this:
* - opensocial_app_id The url of the xml file for the current app
Is there anything else we need to do here or is it just the makeRequest function? Thanks.
- Cassie
On Fri, Apr 4, 2008 at 12:42 AM, Kevin Brown <e...@google.com> wrote: > On Thu, Apr 3, 2008 at 2:21 PM, Lane LiaBraaten <lliab...@google.com> wrote:
>> On Thu, Apr 3, 2008 at 2:07 PM, Kevin Brown <e...@google.com> wrote:
>>> On Thu, Apr 3, 2008 at 2:01 PM, Lane LiaBraaten <lliab...@google.com> >>> wrote:
>>>> +1 for using the URL. This also helps with phishing because I'll know >>>> the MyBank app is written by www.mybank.com and not www.evilphisher.com. If >>>> the URL is hashed, this info is hidden.
>>> I'm not sure this makes a huge amount of difference unless we're talking >>> about a container that makes the urls explicitly visible to end users (which >>> is definitely not what i'm proposing). The only people who would be able to >>> take advantage of this are the tech savvy enough who are more likely to >>> avoid the phish in the first place.
>> Fair enough.
>>> This change would primarily benefit developers.
> Sorry, I wasn't actually advocating that we necessarily require it in the > main site's url. We can do that if so desired, but I was actually only > concerned with the way that appid is referenced in opensocial js / restful > calls, signing, etc.
> Standardizing the parameter on websites might be nice, but you have to do > per-container wiring there anyway. There's another thread going on related > to this very issue though (brought up by Nat from ilike).
>> -Lane
>>>> -Lane
>>>> On Thu, Apr 3, 2008 at 1:28 PM, Graham Spencer <g...@google.com> wrote:
>>>>> I agree with Brian, my vote is for using the URL and not a hash. >>>>> Developers are free to hash the value they get from the container if they >>>>> want something with a fixed size.
>>>>> --g
>>>>> On Thu, Apr 3, 2008 at 8:19 AM, Brian Eaton <bea...@google.com> wrote:
>>>>>> On Thu, Apr 3, 2008 at 1:30 AM, Kevin Brown <e...@google.com> wrote: >>>>>> > url size could be a concern (especially if the original id is being >>>>>> > passed >>>>>> > in a security token through the renderer), so we could also consider >>>>>> > a hash >>>>>> > of the url (md5 or sha1 in base16, perhaps) as the id. This has the >>>>>> > same >>>>>> > basic properties as above, at the slight cost of readability.
>>>>>> I'd rather it was the URL than the hash of the URL. The length >>>>>> savings of a hash are relatively minor, and the readability problems >>>>>> are going to increase as opensocial gets more complex and we deal with >>>>>> things like gadgets changing domains and sharing privileges across >>>>>> gadgets.
>>>>>> If we do decide to use a hash function, md5 would be a poor choice. >>>>>> It's not broken for this particular use case, yet, but it could be >>>>>> soon. I think cryptographers are recommending sha256 for most new >>>>>> applications.
That would imply that the oauth_consumer_key is unique for every application. There's no automated way to set that up, it's a big hassle. We simplify key distribution if each container has a public key, and pass the app id as the opensocial_app_id parameter on signed fetch requests.
Maybe containers should provide some mechanism to alias one gadget URL to another? For example, the app owner could ask the container to direct users of their old gadget to their new gadget. That works even if the app owner loses control of their domain name.
On Mon, Apr 14, 2008 at 1:39 PM, Paul Walker <pwal...@myspace.com> wrote:
> Can we just use the oauth_consumer_key parameter as this is what it's > purpose is? That is our current implementation at MySpace.
> ~Paul
> -----Original Message----- > From: opensocial-and-gadgets-spec@googlegroups.com > [mailto:opensocial-and-gadgets-spec@googlegroups.com] On Behalf Of > Cassie > Sent: Monday, April 14, 2008 6:11 AM > To: opensocial-and-gadgets-spec@googlegroups.com > Subject: Re: Standardizing app id.
> Okay, so overall it looks like we have a lot of happy agreement on the > fact that containers should be using the gadget xml url as the app id.
> So, do we want the spec to actually enforce this? The only place I can > actually find it being used is in the makeRequest function. We pass an > app id to developers, and we would change the spec to say this:
> * - opensocial_app_id The url of the xml file for the current app
> Is there anything else we need to do here or is it just the > makeRequest function? > Thanks.
> - Cassie
> On Fri, Apr 4, 2008 at 12:42 AM, Kevin Brown <e...@google.com> wrote: > > On Thu, Apr 3, 2008 at 2:21 PM, Lane LiaBraaten <lliab...@google.com> > wrote:
> >> On Thu, Apr 3, 2008 at 2:07 PM, Kevin Brown <e...@google.com> wrote:
> >>> On Thu, Apr 3, 2008 at 2:01 PM, Lane LiaBraaten > <lliab...@google.com> > >>> wrote:
> >>>> +1 for using the URL. This also helps with phishing because I'll > know > >>>> the MyBank app is written by www.mybank.com and not > www.evilphisher.com. If > >>>> the URL is hashed, this info is hidden.
> >>> I'm not sure this makes a huge amount of difference unless we're > talking > >>> about a container that makes the urls explicitly visible to end > users (which > >>> is definitely not what i'm proposing). The only people who would be > able to > >>> take advantage of this are the tech savvy enough who are more likely > to > >>> avoid the phish in the first place.
> >> Fair enough.
> >>> This change would primarily benefit developers.
> > Sorry, I wasn't actually advocating that we necessarily require it in > the > > main site's url. We can do that if so desired, but I was actually only > > concerned with the way that appid is referenced in opensocial js / > restful > > calls, signing, etc.
> > Standardizing the parameter on websites might be nice, but you have to > do > > per-container wiring there anyway. There's another thread going on > related > > to this very issue though (brought up by Nat from ilike).
> >> -Lane
> >>>> -Lane
> >>>> On Thu, Apr 3, 2008 at 1:28 PM, Graham Spencer <g...@google.com> > wrote:
> >>>>> I agree with Brian, my vote is for using the URL and not a hash. > >>>>> Developers are free to hash the value they get from the container > if they > >>>>> want something with a fixed size.
> >>>>> --g
> >>>>> On Thu, Apr 3, 2008 at 8:19 AM, Brian Eaton <bea...@google.com> > wrote:
> >>>>>> On Thu, Apr 3, 2008 at 1:30 AM, Kevin Brown <e...@google.com> > wrote: > >>>>>> > url size could be a concern (especially if the original id is > being > >>>>>> > passed > >>>>>> > in a security token through the renderer), so we could also > consider > >>>>>> > a hash > >>>>>> > of the url (md5 or sha1 in base16, perhaps) as the id. This has > the > >>>>>> > same > >>>>>> > basic properties as above, at the slight cost of readability.
> >>>>>> I'd rather it was the URL than the hash of the URL. The length > >>>>>> savings of a hash are relatively minor, and the readability > problems > >>>>>> are going to increase as opensocial gets more complex and we deal > with > >>>>>> things like gadgets changing domains and sharing privileges > across > >>>>>> gadgets.
> >>>>>> If we do decide to use a hash function, md5 would be a poor > choice. > >>>>>> It's not broken for this particular use case, yet, but it could > be > >>>>>> soon. I think cryptographers are recommending sha256 for most > new > >>>>>> applications.
Well that's where i saw a potential problem (see my other somewhat muzing email), right now it's setup in a way that the gadget rendering is a separate system from the container site, for good reasons since they really do different things.
Now the only 'automatic' way i can think of (and non automatic could just not be dependent on with thousands of potential open social containers), is by including this in the meta data of the gadget ... which means the gadget renderer is the only system that actually sees this field, and somehow have to prod the social container site to update it's db .. possible, but quite a change in the spirit of the spec (so far open social reads and provides services, and doesn't actually go and write things to the social container, that would open up a whole new game :))
> Maybe containers should provide some mechanism to alias one gadget URL > to another? For example, the app owner could ask the container to > direct users of their old gadget to their new gadget. That works even > if the app owner loses control of their domain name.
Problem #1: what should the app_id be? how should the gadget server tell the gadget home server what gadget is making a request? Problem #2: how should applications rendering on the gadget server be managed?
On Mon, Apr 14, 2008 at 3:24 PM, Chris Chabot <chab...@xs4all.nl> wrote:
> Well that's where i saw a potential problem (see my other somewhat > muzing email), right now it's setup in a way that the gadget rendering > is a separate system from the container site, for good reasons since > they really do different things.
> Now the only 'automatic' way i can think of (and non automatic could > just not be dependent on with thousands of potential open social > containers), is by including this in the meta data of the gadget ... > which means the gadget renderer is the only system that actually sees > this field, and somehow have to prod the social container site to > update it's db .. possible, but quite a change in the spirit of the > spec (so far open social reads and provides services, and doesn't > actually go and write things to the social container, that would open > up a whole new game :))
> -- Chris
> On Apr 14, 2008, at 10:44 PM, Brian Eaton wrote:
> > Maybe containers should provide some mechanism to alias one gadget URL > > to another? For example, the app owner could ask the container to > > direct users of their old gadget to their new gadget. That works even > > if the app owner loses control of their domain name.
I don't think it's too much of a burden to require developers to keep the same URL. Particularly if gadget developers think about permanent URLs ahead of time, how often will the gadget URL really need to be changed in practice? You can always keep old domain names, use rewriting rules, use HTTP redirects, etc.
On Mon, Apr 14, 2008 at 3:29 PM, Brian Eaton <bea...@google.com> wrote:
> Hrm. We may be looking at two distinct problems.
> Problem #1: what should the app_id be? how should the gadget server > tell the gadget home server what gadget is making a request? > Problem #2: how should applications rendering on the gadget server be > managed?
> Cheers, > Brian
> On Mon, Apr 14, 2008 at 3:24 PM, Chris Chabot <chab...@xs4all.nl> wrote:
> > Well that's where i saw a potential problem (see my other somewhat > > muzing email), right now it's setup in a way that the gadget rendering > > is a separate system from the container site, for good reasons since > > they really do different things.
> > Now the only 'automatic' way i can think of (and non automatic could > > just not be dependent on with thousands of potential open social > > containers), is by including this in the meta data of the gadget ... > > which means the gadget renderer is the only system that actually sees > > this field, and somehow have to prod the social container site to > > update it's db .. possible, but quite a change in the spirit of the > > spec (so far open social reads and provides services, and doesn't > > actually go and write things to the social container, that would open > > up a whole new game :))
> > -- Chris
> > On Apr 14, 2008, at 10:44 PM, Brian Eaton wrote:
> > > Maybe containers should provide some mechanism to alias one gadget URL > > > to another? For example, the app owner could ask the container to > > > direct users of their old gadget to their new gadget. That works even > > > if the app owner loses control of their domain name.
Isn't it the same problem we face when we change our email address?
We are all familiar with the solutions: - Forward mails to our new address if the old one is still under our control. - Otherwise, inform everyone of the new address and learn to not give out school/corporate/other temporary email again.
The app id updating problem can be solved analogically -- use a redirection URL.
On Mon, Apr 14, 2008 at 1:29 PM, fern...@gmail.com <fern...@gmail.com> wrote:
> I guess the question on the table, is do others feels these scenarios > I proposed are important or not. I just feel scared that once I > publish a url, I'll never be able to change it, a little scary.
> Does anyone else have any ideas on how to communicate to containers to > tell them that the old APP should point to a new gadgetxml url?
> On Apr 14, 10:27 am, Chris Chabot <chab...@xs4all.nl> wrote: > > Hmm that is a bit tricky.
> > As i understand the open social API at the moment, there is nothing in > > it that deals with these types of scenarios.
> > As it stands now, a simplest Open Social compliant site could just > > have a text field where people past a url to the gadget.xml, the site > > stores this url and renders it on the person's page. Now in that > > scenario, were you to change the URL in any way shape or form, the > > renderer would simply give you a 'Failed to retrieve gadget content' > > error.
> > A few musings on the possibilities:
> > So say you wanted to solve that situation by having an meaningful app > > id, you would need to have a central registry (which is not at all a > > part of open social at the moment) to track this app id and what URL > > belongs to it, which means someone would have to build and maintain > > the infrastructure for it, and take responsibility for it ... and > > others (from other geographical and thus political regions) would have > > to depend on that registry to be able to function ... plus all current > > and future social sites would have to connect to this service to be > > able to become an open social container.
> > To me that sounds like a lot of work and with a few possible thorns > > attached too
> > Alternate scenario's i could think if would be to have the app id be > > only meaningful inside of one social site, but that would mean gadget > > creators would have to contact each social container, and that could > > be thousands at some point for all you know, to get their url's > > updated.. Not a workable situation either.
> > The alternative of letting a gadget set it's own ID in its meta data > > (xml) is even more scary, because it would mean any gadget could spoof > > the app id, and get to information it has no business getting too.. So > > that has to be the worst possible solution :)
> > The only semi workable solution i could think of is to mimic HTTP a > > bit (301: Moved Permanently) and allow for a 'Moved to this new URL' > > field in the gadget spec, and specify that on receiving this code, the > > social container should update its database and use the new URL. (And > > the gadget renderer would need some form of communication / write > > access to the social container ... which are probably 2 very separate > > systems), so that would complicate things a bit, especially for the > > write access to the container bit, but somewhat viable i guess..
> > Now it's well possible i missed something obvious here, or other > > possible solutions, however none of the things i was able to think of > > would be a 'minor change' as far as the impact on the specification, > > and current implementation goes.
> > -- Chris
> > On Apr 14, 2008, at 7:05 PM, fern...@gmail.com wrote:
> > > wait. I just joined this group and stumbled onto this thread, can > > > someone answer my concern:
> > > What if we have to change url schemes (technical reasons) or top level > > > domains ( changing company name ), what would be the procedure to move > > > all users from old app xml to new app xml without losing all users?
> > > other scenarios:
> > > What if some/all containers begin to to hard caching of the gadget > > > xml, but we have to push out a change. So after deploy we go and > > > update gadget xmls on containers to make sure they pull in the latest > > > version.. did we create a brand new app that can't access old users? > > > etc etc
> > > This sounds scary and I would ask people to think about issues where > > > "app != gadget xml" before codifying something like this. So what > > > defines and "app" and what defines a particular "implementation of an > > > app". Much like I can define f...@domain.com, but totally change the
> > > MX record, the mail server implementation, hosting, etc etc..
> > > thank you.
> > > On Apr 14, 6:10 am, Cassie <d...@google.com> wrote: > > >> Okay, so overall it looks like we have a lot of happy agreement on > > >> the > > >> fact that containers should be using the gadget xml url as the app > > >> id.
> > >> So, do we want the spec to actually enforce this? The only place I > > >> can > > >> actually find it being used is in the makeRequest function. We pass > > >> an > > >> app id to developers, and we would change the spec to say this:
> > >> * - opensocial_app_id The url of the xml file for the current > > >> app
> > >> Is there anything else we need to do here or is it just the > > >> makeRequest function? > > >> Thanks.
> > >> - Cassie
> > >> On Fri, Apr 4, 2008 at 12:42 AM, Kevin Brown <e...@google.com> wrote: > > >>> On Thu, Apr 3, 2008 at 2:21 PM, Lane LiaBraaten > > >>> <lliab...@google.com> wrote:
> > >>>> On Thu, Apr 3, 2008 at 2:07 PM, Kevin Brown <e...@google.com> > > >>>> wrote:
> > >>>>> On Thu, Apr 3, 2008 at 2:01 PM, Lane LiaBraaten > > >>>>> <lliab...@google.com> > > >>>>> wrote:
> > >>>>>> +1 for using the URL. This also helps with phishing because > > >>>>>> I'll know > > >>>>>> the MyBank app is written bywww.mybank.comand > > >>>>>> notwww.evilphisher.com. If > > >>>>>> the URL is hashed, this info is hidden.
> > >>>>> I'm not sure this makes a huge amount of difference unless we're > > >>>>> talking > > >>>>> about a container that makes the urls explicitly visible to end > > >>>>> users (which > > >>>>> is definitely not what i'm proposing). The only people who would > > >>>>> be able to > > >>>>> take advantage of this are the tech savvy enough who are more > > >>>>> likely to > > >>>>> avoid the phish in the first place.
> > >>>> Fair enough.
> > >>>>> This change would primarily benefit developers.
> > >>> Sorry, I wasn't actually advocating that we necessarily require it > > >>> in the > > >>> main site's url. We can do that if so desired, but I was actually > > >>> only > > >>> concerned with the way that appid is referenced in opensocial js / > > >>> restful > > >>> calls, signing, etc.
> > >>> Standardizing the parameter on websites might be nice, but you > > >>> have to do > > >>> per-container wiring there anyway. There's another thread going on > > >>> related > > >>> to this very issue though (brought up by Nat from ilike).
> > >>>> -Lane
> > >>>>>> -Lane
> > >>>>>> On Thu, Apr 3, 2008 at 1:28 PM, Graham Spencer > > >>>>>> <g...@google.com> wrote:
> > >>>>>>> I agree with Brian, my vote is for using the URL and not a hash. > > >>>>>>> Developers are free to hash the value they get from the > > >>>>>>> container if they > > >>>>>>> want something with a fixed size.
> > >>>>>>> --g
> > >>>>>>> On Thu, Apr 3, 2008 at 8:19 AM, Brian Eaton > > >>>>>>> <bea...@google.com> wrote:
> > >>>>>>>> On Thu, Apr 3, 2008 at 1:30 AM, Kevin Brown <e...@google.com> > > >>>>>>>> wrote: > > >>>>>>>>> url size could be a concern (especially if the original id > > >>>>>>>>> is being > > >>>>>>>>> passed > > >>>>>>>>> in a security token through the renderer), so we could also > > >>>>>>>>> consider > > >>>>>>>>> a hash > > >>>>>>>>> of the url (md5 or sha1 in base16, perhaps) as the id. This > > >>>>>>>>> has the > > >>>>>>>>> same > > >>>>>>>>> basic properties as above, at the slight cost of readability.
> > >>>>>>>> I'd rather it was the URL than the hash of the URL. The length > > >>>>>>>> savings of a hash are relatively minor, and the readability > > >>>>>>>> problems > > >>>>>>>> are going to increase as opensocial gets more complex and we > > >>>>>>>> deal with > > >>>>>>>> things like gadgets changing domains and sharing privileges > > >>>>>>>> across > > >>>>>>>> gadgets.
> > >>>>>>>> If we do decide to use a hash function, md5 would be a poor > > >>>>>>>> choice. > > >>>>>>>> It's not broken for this particular use case, yet, but it > > >>>>>>>> could be > > >>>>>>>> soon. I think cryptographers are recommending sha256 for > > >>>>>>>> most new > > >>>>>>>> applications.
|
