|
List Info
Thread: License in software
|
|
| License in software |
 
Germany |
2008-03-29 14:00:43 |
Hi guys,
I wanna write an GLPed application that searches flickr and
shows images.
Is it ok if I hardcode my Flickr api key into the source
code or must
every use get his own api key (this would be very unhandy)?
Cheers,
Manuel
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://grou
ps.yahoo.com/group/yws-flickr/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://
groups.yahoo.com/group/yws-flickr/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:yws-flickr-digest@yahoogroups.com
mailto:yws-flickr-fullfeatured@yahoogroups.com
<*> To unsubscribe from this group, send an email to:
yws-flickr-unsubscribe@yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.c
om/info/terms/
|
|
| Re: License in software |
 
United States |
2008-03-29 16:54:10 |
On Mar 29, 2008 (13), at 12:00, Manuel Schölling wrote:
> Hi guys,
>
> I wanna write an GLPed application that searches flickr
and shows
> images.
> Is it ok if I hardcode my Flickr api key into the
source code or must
> every use get his own api key (this would be very
unhandy)?
>
> Cheers,
> Manuel
In general, you can code your key into the application if
you want.
Whether or not you should want to do this depends greatly on
the
nature of your application.
Here's the scenario: someone's using your code to search
flickr and
show images, but is doing a broad search, and using
copyright images
without permission to advertise their services (or similar).
This
sort of situation comes up at least once or twice a week in
the Help
Forum under "Site X stealing photos," so it's not
just a hypothetical
point.
Flickr's one and only option to address this is to revoke
the API
key. This puts all your other users out in the cold as
well.
They've said they don't have the time to warn then
double-check
compliance later, or track down the one bad user out of a
thousand
good ones. If they find a key being used improperly, that
key gets
invalidated, with no warnings.
Another concern is the secret: I don't think anyone should
ever
publish a default secret. That's a situation where a
malicious
application could masquerade as a trusted one, since a lot
of aspects
of authorisation (like the name and the callback URL) are
tied to the
key.
E.g., if you app is called "Harmless Flickr
Application", the user
sees "Harmless Flickr Application wants these
permissions:"
regardless of who is actually making the request. If they
grant it,
they're even directed to Harmless Flickr Application's
callback URL,
even less reason to suspect they've just given me permission
to
delete their entire photostream. And when I do delete it –
whose
account is the key tied to? Yours. And you'd have
absolutely no way
to show that anyone else did it.
Basically there's an inherent conflict with openly
publishing a key
(as you would be if it were hard-coded into GPL'd code):
you're
responsible for how it's used, but you can't be responsible
for what
your users do with it.
Anyway, the solution that seems to balance the concerns
would be to
include a clearly-named default key (not the secret, to
prevent
people authenticating with your key) with the application,
but with a
*very* strong recommendation to get your own key, including
the
warning that the default key could expire at any time.
Getting a key
is not difficult, it's basically ticking a box. Copy and
paste it to
a configuration file, and it's done.
cheers,
matt.
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://grou
ps.yahoo.com/group/yws-flickr/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://
groups.yahoo.com/group/yws-flickr/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:yws-flickr-digest@yahoogroups.com
mailto:yws-flickr-fullfeatured@yahoogroups.com
<*> To unsubscribe from this group, send an email to:
yws-flickr-unsubscribe@yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.c
om/info/terms/
|
|
| Re: License in software |
United States |
2008-03-29 17:18:48 |
|
Many apps (including open source) distribute their key within the
app because it's unreasonable to expect end users to get their own. Any Flickr application needs to have a key and Bad Guys can get the key from your app whether the source code is available or not. Distributing apps in binary format only doesn't provide any extra security, only a slight hindrance.
On Sat, Mar 29, 2008 at 2:54 PM, matt smillie < matt.smill ie gmail.com">matt.smilliegmail.com> wrote:
On Mar 29, 2008 (13), at 12:00, Manuel Schölling wrote:
> Hi guys,
>
> I wanna write an GLPed application that searches flickr and shows
> images.
> Is it ok if I hardcode my Flickr api key into the source code or must
>; every use get his own api key (this would be very unhandy)?
>
> Cheers,
> Manuel
In general, you can code your key into the application if you want.
Whether or not you should want to do this depends greatly on the
nature of your application.
Here's the scenario: someone9;s using your code to search flickr and
show images, but is doing a broad search, and using copyright images
without permission to advertise their services (or similar). This
sort of situation comes up at least once or twice a week in the Help
Forum under "Site X stealing photos," so it's not just a hypothetical
point.
Flickr's one and only option to address this is to revoke the API
key. This puts all your other users out in the cold as well.
They've said they don't have the time to warn then double-check
compliance later, or track down the one bad user out of a thousand
good ones. If they find a key being used improperly, that key gets
invalidated, with no warnings.
Another concern is the secret: I don't think anyone should ever
publish a default secret. That's a situation where a malicious
application could masquerade as a trusted one, since a lot of aspects
of authorisation (like the name and the callback URL) are tied to the
key.
E.g., if you app is called "Harmless Flickr Application", the user
sees "Harmless Flickr Application wants these permissions:"
regardless of who is actually making the request. If they grant it,
they're even directed to Harmless Flickr Application's callback URL,
even less reason to suspect they've just given me permission to
delete their entire photostream. And when I do delete it – whose
account is the key tied to? Yours. And you'd have absolutely no way
to show that anyone else did it.
Basically there's an inherent conflict with openly publishing a key
(as you would be if it were hard-coded into GPL'd code): you're
responsible for how it's used, but you can't be responsible for what
your users do with it.
Anyway, the solution that seems to balance the concerns would be to
include a clearly-named default key (not the secret, to prevent
people authenticating with your key) with the application, but with a
*very* strong recommendation to get your own key, including the
warning that the default key could expire at any time. Getting a key
is not difficult, it's basically ticking a box. Copy and paste it to
a configuration file, and it's done.
cheers,
matt.
__._,_.___
.
__,_._,___
|
[1-3]
|
|