Standardizing app id.
Kevin Brown
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
Reinoud Elhorst
Hash: SHA1
+1
I like using the (md5-)hash
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH9Ji9qCQnCrE98GgRArUAAJ96K3jCE6Evamjo5F9fAVFSokS/AQCdE4IK
vyP+BPNjaqEt7ei6DPAhP0s=
=6pVz
-----END PGP SIGNATURE-----
Chris Chabot
-- Chris
Brian Eaton
> 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.
Cheers,
Brian
Kevin Brown
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.
Cheers,
Brian
--
~Kevin
Reinoud Elhorst
For easy storage I always prefer something that's fixed length above
something that potentially is very long. Then again, containers need to
store the url anyway.
For easy referencing in urls, an md5-hash is much easier; it won't
require any url escaping;
http://www.hyves.nl/app/cc4a5adf71139d22781a757e93be0cbf looks better
than http://www.hyves.nl/app/http%3A%2F%2Fwww.example.com%2Fgadget.xml/
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
>>
>
>
Brian Eaton
> 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.
Graham Spencer
--g
John Panzer
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?
Sorry if I'm being dense here.
>
Kevin Brown
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.
--
~Kevin
Lane LiaBraaten
-Lane
Kevin Brown
+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.
This change would primarily benefit developers.
-LaneOn 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.
--gOn Thu, Apr 3, 2008 at 8:19 AM, Brian Eaton <bea...@google.com> wrote:
I'd rather it was the URL than the hash of the URL. The length
On Thu, Apr 3, 2008 at 1:30 AM, Kevin Brown <et...@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.
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.
Cheers,
Brian
--
~Kevin
Lane LiaBraaten
On Thu, Apr 3, 2008 at 2:01 PM, Lane LiaBraaten <llia...@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.
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?
-Lane
Brian Eaton
> 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.
Kevin Brown
On Thu, Apr 3, 2008 at 2:07 PM, Kevin Brown <et...@google.com> wrote:On Thu, Apr 3, 2008 at 2:01 PM, Lane LiaBraaten <llia...@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.
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?
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~Kevin
-LaneOn 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.
--gOn Thu, Apr 3, 2008 at 8:19 AM, Brian Eaton <bea...@google.com> wrote:
I'd rather it was the URL than the hash of the URL. The length
On Thu, Apr 3, 2008 at 1:30 AM, Kevin Brown <et...@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.
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.
Cheers,
Brian
--
--
~Kevin
Cassie
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
fer...@gmail.com
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 fe...@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 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>
>
> >>>> +1 for using the URL. This also helps with phishing because I'll know
Chris Chabot
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
fer...@gmail.com
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?
>
> > 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
Paul Walker
purpose is? That is our current implementation at MySpace.
~Paul
Brian Eaton
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.
Cheers,
Brian
Chris Chabot
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
Brian Eaton
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
Graham Spencer
--g
Zhen Wang
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.
Kevin Brown
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.
I generally agree with this, though we should be explicit in our messaging as well. Users need to trust an opensocial gadget in the same way that they'd trust a website; I'd feel a lot happier about installing gadget X claiming to be from site Y if I could clearly see somewhere (in the directory, for instance), that the gadget was coming from site Y. I'm definitely not going to trust a gadget claiming to be from my bank or whatever if I see it's being hosted on http://evilphishingscam.com/someone-stole-my-data.xml
--
~Kevin
Reinoud Elhorst
At the moment, I don't think any container has support for relocating a gadget. Aside from the whole discussion on whether the app id should be the url (which is, as Cassie noted, only used in the signed makerequest as far as the spec is concerned), I think that containers should keep in mind that gadgets might want to relocate.
*) It should be noted that the gadget is cached, and images etc do not have to come from the same source as the gadget, so bandwidth might not be problem; It might just be that the hosting provider, noting that there is a hugely popular gadget hosted on his url that is unable to relocate, decides to ask a lot more money for hosting. Or the hosting provider decides to take down the "Free Tibet" gadget, because it wants to do business in China. Etc. Basically, there are a lot of reasons why gadgets might have to relocate when they become popular.
Paul Lindner
http://USER.hi5.com/friend/apps/entry/HOST/PATH/FILE.xml
which corresponds to http://HOST/PATH/FILE.xml
so far this is working well, and allows the app dev to have well known
endpoints, and get some SEO terms in the URL. For app requests etal
we use an internal appId.
We have had a couple of requests for renames, which we've done
manually so far.
As far as caching etc, approved apps are only updated at the
developers requests. We cache the app xml contents, which removes
that particular burden from the developer.
> > > 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?
> > > >
> > > >
> > > > On Mon, Apr 14, 2008 at 3:24 PM, Chris Chabot <cha...@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 :))
> > > > >
> > > > >
> > > > >
> > > > > 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.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
> > >
> >
>
> You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
> To post to this group, send email to opensocial-an...@googlegroups.com
> To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
--
Paul Lindner ||||| | | | | | | | | |
lin...@inuus.com
John Panzer
-John
Bruno Bowden
http://go/gadgetalias
301 Permanent Redirect
The problem is that this doesn't scale. The problem is establishing the legitimacy of an incoming request. Therefore I'd prefer to handle as many requests as possible using 304 permanent redirects. It may not be possible for the author to do that but it would reduce the number than need to be faxed in and vetted. Even then, do we want to become a centralized arbiter for vetted requests?
Graham Spencer
--g
John Panzer
If you want to move a gadget:
Step 1: Set up a 301 Permanently Moved response with a Location: header to the new location. Gadget servers would then pick this up lazily and re-map the URL internally. Leave this redirect up for at least 30 days before moving to step 2. (Can have an alternative <link> element in the gadget xml to point to the new location as well, for response-challenged hosting environments.)
Step 2: Set up a 410 Permanently Gone response at the old location for a minimum of 60 days. Gadget servers that see this should erase the gadget from their memory -- it's going bye-bye.
Step 3: Release the URL completely (starts returning 404, or 200 if someone reclaims it somehow).
Any gadget server which hasn't accessed a gadget in over 90 days would need to erase all permissions and app data associated with the gadget. Since this would only affect gadgets with zero usage in 3 months, I don't think this is too onerous a burden.
Bruno Bowden
Step 1: Set up a 301 Permanently Moved response with a Location: header to the new location. Gadget servers would then pick this up lazily and re-map the URL internally. Leave this redirect up for at least 30 days before moving to step 2. (Can have an alternative <link> element in the gadget xml to point to the new location as well, for response-challenged hosting environments.)
Step 2: Set up a 410 Permanently Gone response at the old location for a minimum of 60 days. Gadget servers that see this should erase the gadget from their memory -- it's going bye-bye.
Even though I proposed this and I think it should be the most common resolution, I should ask in what situations can't you set up a redirect? For example, you can't set a redirect on a gadget hosted by the Google Gadgets Editor. Even though we could fix GGE, what other cases arise?
Paul Walker
@MySpace our apps aren’t in this continually pull and render model, but we are committed to supporting app metadata xml.
I agree with the general proposal of http status codes for change of URI, but in this minute sitch can we not expect developers to take action (as they already have to change their URI) and push their updated URI out to OS providers?
Would a simple online registry of OS Providers allow gadget/web part developers to push this change out?
~Paul
From:
opensocial-an...@googlegroups.com
[mailto:opensocial-an...@googlegroups.com] On Behalf Of Bruno
Bowden
Sent: Tuesday, April 15, 2008 4:23 PM
To: opensocial-an...@googlegroups.com
Subject: Re: Standardizing app id.
Step 1: Set up a 301 Permanently Moved response with a Location: header to the new location. Gadget servers would then pick this up lazily and re-map the URL internally. Leave this redirect up for at least 30 days before moving to step 2. (Can have an alternative <link> element in the gadget xml to point to the new location as well, for response-challenged hosting environments.)
fer...@gmail.com
of why it's totally a requirement to support changing definition urls
behind applications.
So when containers check back into the app, the app needs to be able
to tell the container..:
- contents of the gadget def (what we currently do)
- TTL (when to check back for updates)
- possible redirect/redefinition of what defines the app (what we're
currently discussing)
Could that be cleanly done using normal HTTP Cache and Permanent-
Redirect headers?
Or would people prefer some other way of communicating that to the
container?
Do we have to worry about man-in-the-middle allowing someone to fully
hijack apps?
Do we need more secure way to communicate such things to the
containers? (oauth singed, etc)
>
> The dual of this problem would be someone creating a new gadget
> at the old location, and then being able to impersonate the old gadget,
> steal data, etc.
>
> -John
>
> On Apr 15, 2008, at 3:13 AM, "Reinoud Elhorst"
>
>
> For many of the larger gadgets, having the same URL will
> not be much of a problem. However I can easily see how someone develops
> a nice little gadget that he never dreams of becoming huge, hosts it at
> some cheap hostingprovider, and then when his gadget turns out to be
> hugely popular, runs out of bandwidth *). Now the last thing we want to
> do in OpenSocial is kill any gadget that becomes popular.... Just
> telling the creator that it's too bad and he should have thought about
> this on beforehand, doesn't seem like a good plan.
>
> At the moment, I don't think any container has support
> for relocating a gadget. Aside from the whole discussion on whether the
> app id should be the url (which is, as Cassie noted, only used in the
> signed makerequest as far as the spec is concerned), I think that
> containers should keep in mind that gadgets might want to relocate.
>
> *) It should be noted that the gadget is cached, and
> images etc do not have to come from the same source as the gadget, so
> bandwidth might not be problem; It might just be that the hosting
> provider, noting that there is a hugely popular gadget hosted on his url
> that is unable to relocate, decides to ask a lot more money for hosting.
> Or the hosting provider decides to take down the "Free Tibet" gadget,
> because it wants to do business in China. Etc. Basically, there are a
> lot of reasons why gadgets might have to relocate when they become
> popular.
>
> On Tue, Apr 15, 2008 at 2:49 AM, Kevin Brown
>
>
> On Mon, Apr 14, 2008 at 5:42 PM, Graham Spencer
>
> <g...@google.com> wrote:
>
> 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.
>
> I generally agree with this, though we should be
> explicit in our messaging as well. Users need to trust an opensocial
> gadget in the same way that they'd trust a website; I'd feel a lot
> happier about installing gadget X claiming to be from site Y if I could
> clearly see somewhere (in the directory, for instance), that the gadget
> was coming from site Y. I'm definitely not going to trust a gadget
> --g
>
> 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
>
fer...@gmail.com
This is part of the larger question of how does an app developer,
publish and manage apps on many containers..
We have the ultimate goal of a "zero-configuration/management" system,
where one server can serve up an app into multiple containers without
any work from developers... but this goal is very far from grasp,
specially with current implementations.
I could say that ultimately the issues brought up in this thread deal
with distributed management.. how can an app be managed on various
servers by one identity (the valid owner of the app).
We have a dream that anyone can just add a gadgetxml to any container,
and voila the app now works perfectly there.. but that's not the
reality. (most containers have developers declare what apps they own
and can manage, and then apps have to be whitelisted into directories,
and then app developers have to download app keys or container public
keys into their key caches, etc etc ). And really only dead simple
apps have a chance of write-once-run-everywhere, what with varying
sizes, styles, userids, features implemented, server-server code, etc.
Should we just give up on that dream and say that developers have to
explicitly publish apps to each container???
Or should we put more effort and make more progress on having that
centralized directory that people mentioned way back when... so
developers can manage centrally and containers would just inherit
information from that central directory?
Or do we have to create an OpenSocial gadgetxml server/redirection
service; so that I can create a permanent url to my gadgetxml, and
still change where it's actually hosted..
Cassie
There are many things to discuss here so I look forward to us coming to further resolutions for 0.9.
Please let me know if there are any problems with this.
Thanks!
- Cassie
Reinoud Elhorst
Hash: SHA1
Hi Brian,
Working on OpenSocial for Hyves, we ran into a security issue; I would
like to know whether it has been considered and what the best solution
would be.
I believe that many containers have the same businessrules as we, where
the viewer is by default not visible to the gadget on the profile view,
but is visible in the canvas view. The profileview gadgets with us would
be on
http://claude.hyves.nl/
and a canvas view gadget might be at
http://claude.hyves.nl/gap/1234/abcd
What if a gadget in profile view opened a hidden iframe to
http://claude.hyves.nl/gap/1234/abcd. The gadget in the canvas iframe
would then be able to see the viewer (and for instance log who would
visit your profile).
You could even do this from external pages: On my external blog I have
an iframe to the canvas page, and I can log which hyves members visit my
blog (as long as they have automatic login enabled).
Just wondering whether there is some sort of best practices solution for
this.
Thanks,
Reinoud
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkhbxMMACgkQqCQnCrE98GifAACfY2LWQpyfK/GgXt3NLj6x1W9h
cssAoLEEXQgkpm6TCHL8+ZsOOZe+f9Xh
=X81Y
-----END PGP SIGNATURE-----
Ropu
How do you plan to do the communication from one gadget to the other? (iframe to iframe?)
And if that "hack" works? the idea is to have the viewer_id in the profile view? so go "against" the businessrules?
if so, i think it will be much easier to just code the back end to get the viewer_id and pass it in the sec token.
and besides that, u'll have to create one extra iframe for each gadget in the profile, and that DUPLICATING the costs of bandwith, processing, memory, etc etc..
my 2 cents
ropu
.-. --- .--. ..-
R o p u
Reinoud Elhorst
Well, since it's out in the open, I guess there is no sense in starting trying to undo it. So I'll guess I'll put the question out to everyone. We're concerned about the possible attack vector here.
Kevin Brown
Zhen Wang
within both gadgets to enable cross-domain communication between the
two.
Reinoud Elhorst
To me it would seem there are only two ways to avoid this (but perhaps I'm being premature here):
1) Always using the same viewer visibility rules on all views.
2) Protecting views where the viewer is always visible with anti-CSRF techniques. This would disable direct linking to the canvas pages from outside of the container as well.
Kevin Brown
Zhen Wang
info on the profile page but not on the canvas view?
Reinoud Elhorst
In other words, when you go to a gadget canvas page, you know which gadget you're dealing with. If you go to a profile page, you don't know which gadgets it will contain.
I think other containers use similar rules, although I'm not sure.
Ropu
gadgets.util.registerOnLoadHandler(onloadHandled);to execute when the iframe gets the focus()
ropu