You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Brian Eaton <be...@google.com> on 2008/02/26 00:22:15 UTC
Fwd: Passing in the client IP
[-opensocial-and-gadgets-spec@googlegroups.com,
+shindig-dev@incubator.apache.org]
Should the open proxy in Shindig forward an X-User-IP header with the
client's IP to servers the client instructs us to contact?
I'm concerned that the open proxy in Shindig will become a vector for
abuse. Sending the client IP will make it slightly easier for the
admins of targeted servers to blame the perpetrator rather than the
Shindig server.
Cheers,
Brian
---------- Forwarded message ----------
From: Kevin Brown <et...@google.com>
Date: Mon, Feb 25, 2008 at 3:18 PM
Subject: Re: Passing in the client IP
To: opensocial-and-gadgets-spec@googlegroups.com
That's a discussion worth having on the shindig mailing list,
probably, but it's a different issue than what I think Paul is trying
to address.
On Mon, Feb 25, 2008 at 3:13 PM, Brian Eaton <be...@google.com> wrote:
>
> Providing an X-User-IP header for requests sent through the proxy
> service might help reduce abuse of the open proxy in Shindig.
>
>
> On Mon, Feb 25, 2008 at 11:38 AM, Bruno Bowden <br...@google.com> wrote:
>
>
>
> > Geolocation is difficult to do well. For example AOL users across the
> > country getting mapped to the same IP address in Virginia. User preference
> > data can be helpful but what if they travel? There's also serious issues
> > surrounding user privacy, which vary from country to country.
> >
> > Ultimately it should be Shindig's responsibility to draw on as much
> > information sources as possible and make a best guess.
> >
> > Syntax:
> > Use ints for lat / lon, representing data in microdegrees (more accuracy
> > than using a 4 byte float). This gives up to 14m resolution, so the IP
> > geotargeting will be a more limiting factor. For example, 145 degrees =>
> > 145,000,000.
> >
> > Example:
> > var prefs = new gadgets.Prefs();
> > var lat = prefs.getString("lat");
> > var long = prefs.getString("long");
> >
> >
> >
> >
> > On Mon, Feb 25, 2008 at 7:03 AM, Kevin Marks <ke...@google.com> wrote:
> >
> > > Why not use the location information in the viewer/owner person info for
> > this?
> > >
> > >
> > >
> > >
> > >
> > > On Mon, Feb 25, 2008 at 2:21 AM, Paul Lindner <li...@inuus.com> wrote:
> > >
> > > > At a recent hackathon a developer wanted to be able to query the IP
> > > > address of the client invoking the gadget. The developer wanted to
> > > > use this for geolocation.
> > > >
> > > > Considering that it might be useful to include other http headers too,
> > > > cookies, languages, etc.
> > > >
> > > > It seems like it would be fairly easy for the gadget server to inject
> > > > this information.
> > > >
> > > > I am unsure what the API to access this information would be like.
> > > >
> > > > --
> > > > Paul Lindner ||||| | | | | | | | | |
> > > > lindner@inuus.com
> > > >
> > >
> > >
> > >
> > >
> >
> >
> > >
> >
>
>
>
--
~Kevin
If you received this email by mistake, please delete it, cancel your
mail account, destroy your hard drive, silence any witnesses, and burn
down the building that you're in.
--~--~---------~--~----~------------~-------~--~----~
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-and-gadgets-spec@googlegroups.com
To unsubscribe from this group, send email to
opensocial-and-gadgets-spec-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
-~----------~----~----~----~------~----~------~--~---
Re: Passing in the client IP
Posted by Akash Xavier <ak...@gmail.com>.
I think there's another way to get the users' IP. Can be done thru
server-side scripts if the content-type of the gadget is URL
On Tue, Feb 26, 2008 at 10:59 PM, Brian Eaton <be...@google.com> wrote:
> If a gadget wants to leak the user's IP, all it needs to do is create
> an img tag pointing to another server. Not sending the IP address
> with requests forwarded through gadgets.io.makeRequest() provides no
> privacy benefit.
>
> On Tue, Feb 26, 2008 at 8:27 AM, Akash Xavier <ak...@gmail.com>
> wrote:
> > Oh!
> > If its for geo-location purposes, ok, there's another way around.
> > We'll let the container use the IP to tell the gadget where the user is
> > from. So instead of passing the IP, the geo-location can be passed
> directly.
> > Ofcourse, it proves financially expensive for the container site. But
> anyone
> > who wants gadgets to get some geo-location data, might ofcourse try to
> give
> > away geo-location data directly instead on the IP. There's no perfect
> > method. But we need to protect the user's privacy too by not offering
> the IP
> > directly.
> >
> >
> >
> > On Tue, Feb 26, 2008 at 9:31 PM, Brian Eaton <be...@google.com> wrote:
> >
> > > Two comments.
> > >
> > > - what use would a hashed IP address be to anyone? I think the
> > > original request was for the IP address for geolocation purposes, and
> > > then I chimed in saying we should have it to help respond to abuse
> > > complaints. A hash of the IP is not useful for either purpose.
> > >
> > > - don't use straight md5 or sha1 to obfuscate something with low
> > > entropy like an IP address. You need a salt, at least, or probably
> an
> > > HMAC or even a one-time pad depending on your goals. If you use an
> > > unsalted hash then building up a dictionary mapping from the hash to
> > > the original IP is easy.
> > >
> > > On Tue, Feb 26, 2008 at 1:53 AM, Akash Xavier <akashmanohar@gmail.com
> >
> > > wrote:
> > > > Hi everyone!
> > > > Perhaps, we solve this by a different solution. I don't know
> whether I
> > > am
> > > > right but I think this can be done.
> > > > The container can set a cookie which contains the value of the ip
> > > address of
> > > > the viewer in some encrypted form (like something md5 or sha1
> value of
> > > the
> > > > IP), this can be done by the server side script (what ever
> language,
> > > java or
> > > > php).
> > > > This value can then be passed to the app's server by the
> javascript
> > > when
> > > > making the call to the app's server for some data.
> > > >
> > > > IMO an an encrypted value is enough. I think server-side
> encryption is
> > > the
> > > > solution to protect the user's privacy (and also from gadget
> authors
> > > > exploiting their IP data).
> > > >
> > > > On Tue, Feb 26, 2008 at 7:35 AM, Kevin Brown <et...@google.com>
> wrot
> > > >
> > > >
> > > >
> > > > > Actually, you're right -- we won't be forcing images through a
> proxy
> > > most
> > > > > likely, so they could always use that vector if they really
> wanted to
> > > > > steal
> > > > > IPs.
> > > > >
> > > > > On Mon, Feb 25, 2008 at 5:57 PM, Brian Eaton <be...@google.com>
> > > wrote:
> > > > >
> > > > > > On Mon, Feb 25, 2008 at 5:47 PM, Kevin Brown <et...@google.com>
> > > wrote:
> > > > > > > Caja will eliminate this in the long run (as well as my
> other
> > > > > proposed
> > > > > > way
> > > > > > > to steal the IP).
> > > > > >
> > > > > > I'm not sure I believe this. In theory, sure. In practice I
> > > suspect
> > > > > > that a policy that prevented the IP address from leaking in
> any
> > > > > > possible way would also make it very difficult to write cool
> > > gadgets.
> > > > > >
> > > > > > I hope to be proved wrong, though.
> > > > > >
> > > > > > Cheers,
> > > > > > Brian
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > ~Kevin
> > > > >
> > > > > If you received this email by mistake, please delete it, cancel
> your
> > > mail
> > > > > account, destroy your hard drive, silence any witnesses, and
> burn
> > > down the
> > > > > building that you're in.
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Akash Xavier
> > > > akashmanohar@gmail.com
> > > >
> > >
> >
> >
> >
> > --
> >
> >
> > Akash Xavier
> > akashmanohar@gmail.com
> >
>
--
Akash Xavier
akashmanohar@gmail.com
Re: Passing in the client IP
Posted by Brian Eaton <be...@google.com>.
If a gadget wants to leak the user's IP, all it needs to do is create
an img tag pointing to another server. Not sending the IP address
with requests forwarded through gadgets.io.makeRequest() provides no
privacy benefit.
On Tue, Feb 26, 2008 at 8:27 AM, Akash Xavier <ak...@gmail.com> wrote:
> Oh!
> If its for geo-location purposes, ok, there's another way around.
> We'll let the container use the IP to tell the gadget where the user is
> from. So instead of passing the IP, the geo-location can be passed directly.
> Ofcourse, it proves financially expensive for the container site. But anyone
> who wants gadgets to get some geo-location data, might ofcourse try to give
> away geo-location data directly instead on the IP. There's no perfect
> method. But we need to protect the user's privacy too by not offering the IP
> directly.
>
>
>
> On Tue, Feb 26, 2008 at 9:31 PM, Brian Eaton <be...@google.com> wrote:
>
> > Two comments.
> >
> > - what use would a hashed IP address be to anyone? I think the
> > original request was for the IP address for geolocation purposes, and
> > then I chimed in saying we should have it to help respond to abuse
> > complaints. A hash of the IP is not useful for either purpose.
> >
> > - don't use straight md5 or sha1 to obfuscate something with low
> > entropy like an IP address. You need a salt, at least, or probably an
> > HMAC or even a one-time pad depending on your goals. If you use an
> > unsalted hash then building up a dictionary mapping from the hash to
> > the original IP is easy.
> >
> > On Tue, Feb 26, 2008 at 1:53 AM, Akash Xavier <ak...@gmail.com>
> > wrote:
> > > Hi everyone!
> > > Perhaps, we solve this by a different solution. I don't know whether I
> > am
> > > right but I think this can be done.
> > > The container can set a cookie which contains the value of the ip
> > address of
> > > the viewer in some encrypted form (like something md5 or sha1 value of
> > the
> > > IP), this can be done by the server side script (what ever language,
> > java or
> > > php).
> > > This value can then be passed to the app's server by the javascript
> > when
> > > making the call to the app's server for some data.
> > >
> > > IMO an an encrypted value is enough. I think server-side encryption is
> > the
> > > solution to protect the user's privacy (and also from gadget authors
> > > exploiting their IP data).
> > >
> > > On Tue, Feb 26, 2008 at 7:35 AM, Kevin Brown <et...@google.com> wrot
> > >
> > >
> > >
> > > > Actually, you're right -- we won't be forcing images through a proxy
> > most
> > > > likely, so they could always use that vector if they really wanted to
> > > > steal
> > > > IPs.
> > > >
> > > > On Mon, Feb 25, 2008 at 5:57 PM, Brian Eaton <be...@google.com>
> > wrote:
> > > >
> > > > > On Mon, Feb 25, 2008 at 5:47 PM, Kevin Brown <et...@google.com>
> > wrote:
> > > > > > Caja will eliminate this in the long run (as well as my other
> > > > proposed
> > > > > way
> > > > > > to steal the IP).
> > > > >
> > > > > I'm not sure I believe this. In theory, sure. In practice I
> > suspect
> > > > > that a policy that prevented the IP address from leaking in any
> > > > > possible way would also make it very difficult to write cool
> > gadgets.
> > > > >
> > > > > I hope to be proved wrong, though.
> > > > >
> > > > > Cheers,
> > > > > Brian
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > ~Kevin
> > > >
> > > > If you received this email by mistake, please delete it, cancel your
> > mail
> > > > account, destroy your hard drive, silence any witnesses, and burn
> > down the
> > > > building that you're in.
> > > >
> > >
> > >
> > >
> > > --
> > > Akash Xavier
> > > akashmanohar@gmail.com
> > >
> >
>
>
>
> --
>
>
> Akash Xavier
> akashmanohar@gmail.com
>
Re: Passing in the client IP
Posted by Akash Xavier <ak...@gmail.com>.
Oh!
If its for geo-location purposes, ok, there's another way around.
We'll let the container use the IP to tell the gadget where the user is
from. So instead of passing the IP, the geo-location can be passed directly.
Ofcourse, it proves financially expensive for the container site. But anyone
who wants gadgets to get some geo-location data, might ofcourse try to give
away geo-location data directly instead on the IP. There's no perfect
method. But we need to protect the user's privacy too by not offering the IP
directly.
On Tue, Feb 26, 2008 at 9:31 PM, Brian Eaton <be...@google.com> wrote:
> Two comments.
>
> - what use would a hashed IP address be to anyone? I think the
> original request was for the IP address for geolocation purposes, and
> then I chimed in saying we should have it to help respond to abuse
> complaints. A hash of the IP is not useful for either purpose.
>
> - don't use straight md5 or sha1 to obfuscate something with low
> entropy like an IP address. You need a salt, at least, or probably an
> HMAC or even a one-time pad depending on your goals. If you use an
> unsalted hash then building up a dictionary mapping from the hash to
> the original IP is easy.
>
> On Tue, Feb 26, 2008 at 1:53 AM, Akash Xavier <ak...@gmail.com>
> wrote:
> > Hi everyone!
> > Perhaps, we solve this by a different solution. I don't know whether I
> am
> > right but I think this can be done.
> > The container can set a cookie which contains the value of the ip
> address of
> > the viewer in some encrypted form (like something md5 or sha1 value of
> the
> > IP), this can be done by the server side script (what ever language,
> java or
> > php).
> > This value can then be passed to the app's server by the javascript
> when
> > making the call to the app's server for some data.
> >
> > IMO an an encrypted value is enough. I think server-side encryption is
> the
> > solution to protect the user's privacy (and also from gadget authors
> > exploiting their IP data).
> >
> > On Tue, Feb 26, 2008 at 7:35 AM, Kevin Brown <et...@google.com> wrot
> >
> >
> >
> > > Actually, you're right -- we won't be forcing images through a proxy
> most
> > > likely, so they could always use that vector if they really wanted to
> > > steal
> > > IPs.
> > >
> > > On Mon, Feb 25, 2008 at 5:57 PM, Brian Eaton <be...@google.com>
> wrote:
> > >
> > > > On Mon, Feb 25, 2008 at 5:47 PM, Kevin Brown <et...@google.com>
> wrote:
> > > > > Caja will eliminate this in the long run (as well as my other
> > > proposed
> > > > way
> > > > > to steal the IP).
> > > >
> > > > I'm not sure I believe this. In theory, sure. In practice I
> suspect
> > > > that a policy that prevented the IP address from leaking in any
> > > > possible way would also make it very difficult to write cool
> gadgets.
> > > >
> > > > I hope to be proved wrong, though.
> > > >
> > > > Cheers,
> > > > Brian
> > > >
> > >
> > >
> > >
> > > --
> > > ~Kevin
> > >
> > > If you received this email by mistake, please delete it, cancel your
> mail
> > > account, destroy your hard drive, silence any witnesses, and burn
> down the
> > > building that you're in.
> > >
> >
> >
> >
> > --
> > Akash Xavier
> > akashmanohar@gmail.com
> >
>
--
Akash Xavier
akashmanohar@gmail.com
Re: Passing in the client IP
Posted by Brian Eaton <be...@google.com>.
Two comments.
- what use would a hashed IP address be to anyone? I think the
original request was for the IP address for geolocation purposes, and
then I chimed in saying we should have it to help respond to abuse
complaints. A hash of the IP is not useful for either purpose.
- don't use straight md5 or sha1 to obfuscate something with low
entropy like an IP address. You need a salt, at least, or probably an
HMAC or even a one-time pad depending on your goals. If you use an
unsalted hash then building up a dictionary mapping from the hash to
the original IP is easy.
On Tue, Feb 26, 2008 at 1:53 AM, Akash Xavier <ak...@gmail.com> wrote:
> Hi everyone!
> Perhaps, we solve this by a different solution. I don't know whether I am
> right but I think this can be done.
> The container can set a cookie which contains the value of the ip address of
> the viewer in some encrypted form (like something md5 or sha1 value of the
> IP), this can be done by the server side script (what ever language, java or
> php).
> This value can then be passed to the app's server by the javascript when
> making the call to the app's server for some data.
>
> IMO an an encrypted value is enough. I think server-side encryption is the
> solution to protect the user's privacy (and also from gadget authors
> exploiting their IP data).
>
> On Tue, Feb 26, 2008 at 7:35 AM, Kevin Brown <et...@google.com> wrot
>
>
>
> > Actually, you're right -- we won't be forcing images through a proxy most
> > likely, so they could always use that vector if they really wanted to
> > steal
> > IPs.
> >
> > On Mon, Feb 25, 2008 at 5:57 PM, Brian Eaton <be...@google.com> wrote:
> >
> > > On Mon, Feb 25, 2008 at 5:47 PM, Kevin Brown <et...@google.com> wrote:
> > > > Caja will eliminate this in the long run (as well as my other
> > proposed
> > > way
> > > > to steal the IP).
> > >
> > > I'm not sure I believe this. In theory, sure. In practice I suspect
> > > that a policy that prevented the IP address from leaking in any
> > > possible way would also make it very difficult to write cool gadgets.
> > >
> > > I hope to be proved wrong, though.
> > >
> > > Cheers,
> > > Brian
> > >
> >
> >
> >
> > --
> > ~Kevin
> >
> > If you received this email by mistake, please delete it, cancel your mail
> > account, destroy your hard drive, silence any witnesses, and burn down the
> > building that you're in.
> >
>
>
>
> --
> Akash Xavier
> akashmanohar@gmail.com
>
Re: Passing in the client IP
Posted by Akash Xavier <ak...@gmail.com>.
Hi everyone!
Perhaps, we solve this by a different solution. I don't know whether I am
right but I think this can be done.
The container can set a cookie which contains the value of the ip address of
the viewer in some encrypted form (like something md5 or sha1 value of the
IP), this can be done by the server side script (what ever language, java or
php).
This value can then be passed to the app's server by the javascript when
making the call to the app's server for some data.
IMO an an encrypted value is enough. I think server-side encryption is the
solution to protect the user's privacy (and also from gadget authors
exploiting their IP data).
On Tue, Feb 26, 2008 at 7:35 AM, Kevin Brown <et...@google.com> wrot
> Actually, you're right -- we won't be forcing images through a proxy most
> likely, so they could always use that vector if they really wanted to
> steal
> IPs.
>
> On Mon, Feb 25, 2008 at 5:57 PM, Brian Eaton <be...@google.com> wrote:
>
> > On Mon, Feb 25, 2008 at 5:47 PM, Kevin Brown <et...@google.com> wrote:
> > > Caja will eliminate this in the long run (as well as my other
> proposed
> > way
> > > to steal the IP).
> >
> > I'm not sure I believe this. In theory, sure. In practice I suspect
> > that a policy that prevented the IP address from leaking in any
> > possible way would also make it very difficult to write cool gadgets.
> >
> > I hope to be proved wrong, though.
> >
> > Cheers,
> > Brian
> >
>
>
>
> --
> ~Kevin
>
> If you received this email by mistake, please delete it, cancel your mail
> account, destroy your hard drive, silence any witnesses, and burn down the
> building that you're in.
>
--
Akash Xavier
akashmanohar@gmail.com
Re: Passing in the client IP
Posted by Cassie <do...@google.com>.
Nuts - wrong mailing list.. I will resend on the spec one, please disregard
shindig folks.
On Tue, Apr 1, 2008 at 2:12 PM, Cassie <do...@google.com> wrote:
> I can't quite figure out what the resolution of this issue was.
> Did we decide on anything? Are there any proposals on the table?
>
> - Cassie
>
>
>
> On Wed, Feb 27, 2008 at 12:17 PM, Reinoud Elhorst <cl...@claude.nl>
> wrote:
>
> > Back on the original discussion: I think the proxy-ing Shindig server
> > should
> > behave just like a proxy, including using the HTTP/1.1 proxy headers, at
> > least for the simple (non-oAuth) makeRequests. As Kevin stated before,
> > nothing in the spec says that makeRequest should be proxied or sent
> > through
> > any Sindig/proxy server; I may want to implement it on my container
> > through
> > Flash/ActiveX/browser extension. Adding extra mystery headers that
> > gadget
> > developers come to rely on is therefor bad (or, at least, should be part
> > of
> > the spec, not a Shindig implementation).
> >
> > So +1 for Paul's:
> >
> > I do like the idea of using correct proxy cache headers. I suggest
> > mandating HTTP/1.1 Via: headers, and highly recommending
> > X-Forwarded-For:
> >
> > On 2/26/08, ihab.awad@gmail.com <ih...@gmail.com> wrote:
> > >
> > > On Tue, Feb 26, 2008 at 10:21 AM, Kevin Brown <et...@google.com> wrote:
> > > > Yeah, but not allowing images is pretty much out of the question.
> > You
> > > may as
> > > > well not render gadgets :)
> > >
> > >
> > > I just want to point out that there is a possible distinction that may
> > > or may not be useful, based on your point about the rewriting proxy:
> > >
> > > A gadget may ask, at compile time, for the right to load certain
> > > images. The container could then pre-load these all (or not, or load
> > > them randomly, or whatever), in which case loading the image cannot be
> > > used as a wall-banging channel to the outside world.
> > >
> > > A completely different authority is the authority to load any
> > > arbitrary image from a URL composed at run time, in which case this
> > > constitutes a much more serious outbound channel.
> > >
> > > Ihab
> > >
> > >
> > > --
> > > Ihab A.B. Awad, Palo Alto, CA
> > >
> >
>
>
Re: Passing in the client IP
Posted by Cassie <do...@google.com>.
I can't quite figure out what the resolution of this issue was.
Did we decide on anything? Are there any proposals on the table?
- Cassie
On Wed, Feb 27, 2008 at 12:17 PM, Reinoud Elhorst <cl...@claude.nl> wrote:
> Back on the original discussion: I think the proxy-ing Shindig server
> should
> behave just like a proxy, including using the HTTP/1.1 proxy headers, at
> least for the simple (non-oAuth) makeRequests. As Kevin stated before,
> nothing in the spec says that makeRequest should be proxied or sent
> through
> any Sindig/proxy server; I may want to implement it on my container
> through
> Flash/ActiveX/browser extension. Adding extra mystery headers that gadget
> developers come to rely on is therefor bad (or, at least, should be part
> of
> the spec, not a Shindig implementation).
>
> So +1 for Paul's:
>
> I do like the idea of using correct proxy cache headers. I suggest
> mandating HTTP/1.1 Via: headers, and highly recommending
> X-Forwarded-For:
>
> On 2/26/08, ihab.awad@gmail.com <ih...@gmail.com> wrote:
> >
> > On Tue, Feb 26, 2008 at 10:21 AM, Kevin Brown <et...@google.com> wrote:
> > > Yeah, but not allowing images is pretty much out of the question. You
> > may as
> > > well not render gadgets :)
> >
> >
> > I just want to point out that there is a possible distinction that may
> > or may not be useful, based on your point about the rewriting proxy:
> >
> > A gadget may ask, at compile time, for the right to load certain
> > images. The container could then pre-load these all (or not, or load
> > them randomly, or whatever), in which case loading the image cannot be
> > used as a wall-banging channel to the outside world.
> >
> > A completely different authority is the authority to load any
> > arbitrary image from a URL composed at run time, in which case this
> > constitutes a much more serious outbound channel.
> >
> > Ihab
> >
> >
> > --
> > Ihab A.B. Awad, Palo Alto, CA
> >
>
Re: Passing in the client IP
Posted by Reinoud Elhorst <cl...@claude.nl>.
Back on the original discussion: I think the proxy-ing Shindig server should
behave just like a proxy, including using the HTTP/1.1 proxy headers, at
least for the simple (non-oAuth) makeRequests. As Kevin stated before,
nothing in the spec says that makeRequest should be proxied or sent through
any Sindig/proxy server; I may want to implement it on my container through
Flash/ActiveX/browser extension. Adding extra mystery headers that gadget
developers come to rely on is therefor bad (or, at least, should be part of
the spec, not a Shindig implementation).
So +1 for Paul's:
I do like the idea of using correct proxy cache headers. I suggest
mandating HTTP/1.1 Via: headers, and highly recommending
X-Forwarded-For:
On 2/26/08, ihab.awad@gmail.com <ih...@gmail.com> wrote:
>
> On Tue, Feb 26, 2008 at 10:21 AM, Kevin Brown <et...@google.com> wrote:
> > Yeah, but not allowing images is pretty much out of the question. You
> may as
> > well not render gadgets :)
>
>
> I just want to point out that there is a possible distinction that may
> or may not be useful, based on your point about the rewriting proxy:
>
> A gadget may ask, at compile time, for the right to load certain
> images. The container could then pre-load these all (or not, or load
> them randomly, or whatever), in which case loading the image cannot be
> used as a wall-banging channel to the outside world.
>
> A completely different authority is the authority to load any
> arbitrary image from a URL composed at run time, in which case this
> constitutes a much more serious outbound channel.
>
> Ihab
>
>
> --
> Ihab A.B. Awad, Palo Alto, CA
>
Re: Passing in the client IP
Posted by ih...@gmail.com.
On Tue, Feb 26, 2008 at 10:21 AM, Kevin Brown <et...@google.com> wrote:
> Yeah, but not allowing images is pretty much out of the question. You may as
> well not render gadgets :)
I just want to point out that there is a possible distinction that may
or may not be useful, based on your point about the rewriting proxy:
A gadget may ask, at compile time, for the right to load certain
images. The container could then pre-load these all (or not, or load
them randomly, or whatever), in which case loading the image cannot be
used as a wall-banging channel to the outside world.
A completely different authority is the authority to load any
arbitrary image from a URL composed at run time, in which case this
constitutes a much more serious outbound channel.
Ihab
--
Ihab A.B. Awad, Palo Alto, CA
Re: Passing in the client IP
Posted by Kevin Brown <et...@google.com>.
On Tue, Feb 26, 2008 at 9:46 AM, Bruno Bowden <br...@google.com> wrote:
> Caja in it's most secure variation prevents the loading of images as that
> leaks information too. We need to have a balance between security and
> practicalities - this will probably vary depending on the context in which
> gadgets are used.
Yeah, but not allowing images is pretty much out of the question. You may as
well not render gadgets :) If all images are forced through a rewriting
proxy, this might work, but otherwise it's just not feasible.
Anyway, I think the IP leaking isn't that big of a deal here now.
>
>
> On Mon, Feb 25, 2008 at 6:05 PM, Kevin Brown <et...@google.com> wrote:
>
> > Actually, you're right -- we won't be forcing images through a proxy
> most
> > likely, so they could always use that vector if they really wanted to
> > steal
> > IPs.
> >
> > On Mon, Feb 25, 2008 at 5:57 PM, Brian Eaton <be...@google.com> wrote:
> >
> > > On Mon, Feb 25, 2008 at 5:47 PM, Kevin Brown <et...@google.com> wrote:
> > > > Caja will eliminate this in the long run (as well as my other
> > proposed
> > > way
> > > > to steal the IP).
> > >
> > > I'm not sure I believe this. In theory, sure. In practice I suspect
> > > that a policy that prevented the IP address from leaking in any
> > > possible way would also make it very difficult to write cool gadgets.
> > >
> > > I hope to be proved wrong, though.
> > >
> > > Cheers,
> > > Brian
> > >
> >
> >
> >
> > --
> > ~Kevin
> >
> > If you received this email by mistake, please delete it, cancel your
> mail
> > account, destroy your hard drive, silence any witnesses, and burn down
> the
> > building that you're in.
> >
>
--
~Kevin
If you received this email by mistake, please delete it, cancel your mail
account, destroy your hard drive, silence any witnesses, and burn down the
building that you're in.
Re: Passing in the client IP
Posted by Bruno Bowden <br...@google.com>.
Caja in it's most secure variation prevents the loading of images as that
leaks information too. We need to have a balance between security and
practicalities - this will probably vary depending on the context in which
gadgets are used.
On Mon, Feb 25, 2008 at 6:05 PM, Kevin Brown <et...@google.com> wrote:
> Actually, you're right -- we won't be forcing images through a proxy most
> likely, so they could always use that vector if they really wanted to
> steal
> IPs.
>
> On Mon, Feb 25, 2008 at 5:57 PM, Brian Eaton <be...@google.com> wrote:
>
> > On Mon, Feb 25, 2008 at 5:47 PM, Kevin Brown <et...@google.com> wrote:
> > > Caja will eliminate this in the long run (as well as my other
> proposed
> > way
> > > to steal the IP).
> >
> > I'm not sure I believe this. In theory, sure. In practice I suspect
> > that a policy that prevented the IP address from leaking in any
> > possible way would also make it very difficult to write cool gadgets.
> >
> > I hope to be proved wrong, though.
> >
> > Cheers,
> > Brian
> >
>
>
>
> --
> ~Kevin
>
> If you received this email by mistake, please delete it, cancel your mail
> account, destroy your hard drive, silence any witnesses, and burn down the
> building that you're in.
>
Re: Passing in the client IP
Posted by Kevin Brown <et...@google.com>.
Actually, you're right -- we won't be forcing images through a proxy most
likely, so they could always use that vector if they really wanted to steal
IPs.
On Mon, Feb 25, 2008 at 5:57 PM, Brian Eaton <be...@google.com> wrote:
> On Mon, Feb 25, 2008 at 5:47 PM, Kevin Brown <et...@google.com> wrote:
> > Caja will eliminate this in the long run (as well as my other proposed
> way
> > to steal the IP).
>
> I'm not sure I believe this. In theory, sure. In practice I suspect
> that a policy that prevented the IP address from leaking in any
> possible way would also make it very difficult to write cool gadgets.
>
> I hope to be proved wrong, though.
>
> Cheers,
> Brian
>
--
~Kevin
If you received this email by mistake, please delete it, cancel your mail
account, destroy your hard drive, silence any witnesses, and burn down the
building that you're in.
Re: Passing in the client IP
Posted by Brian Eaton <be...@google.com>.
On Mon, Feb 25, 2008 at 5:47 PM, Kevin Brown <et...@google.com> wrote:
> Caja will eliminate this in the long run (as well as my other proposed way
> to steal the IP).
I'm not sure I believe this. In theory, sure. In practice I suspect
that a policy that prevented the IP address from leaking in any
possible way would also make it very difficult to write cool gadgets.
I hope to be proved wrong, though.
Cheers,
Brian
Re: Passing in the client IP
Posted by Kevin Brown <et...@google.com>.
On Mon, Feb 25, 2008 at 5:24 PM, Bruno Bowden <br...@google.com> wrote:
> On Mon, Feb 25, 2008 at 5:08 PM, Kevin Brown <et...@google.com> wrote:
>
> > I'm also a little concerned about privacy here. Do we really want the
> > gadget
> > authors to be able to get the user's IP? For abuse purposes, I'm OK with
> > some sort of obfuscated identifier (a salted hash of the IP, perhaps),
> but
> > this seems potentially dangerous. Of course, they could still get the IP
> > anyway using redirects, so maybe this isn't such a big deal.
>
>
> You could do it even simpler than than. Just src some javascript where the
> server returns code that sets a variable to your IP address.
Caja will eliminate this in the long run (as well as my other proposed way
to steal the IP).
Re: Passing in the client IP
Posted by Bruno Bowden <br...@google.com>.
On Mon, Feb 25, 2008 at 5:08 PM, Kevin Brown <et...@google.com> wrote:
> I'm also a little concerned about privacy here. Do we really want the
> gadget
> authors to be able to get the user's IP? For abuse purposes, I'm OK with
> some sort of obfuscated identifier (a salted hash of the IP, perhaps), but
> this seems potentially dangerous. Of course, they could still get the IP
> anyway using redirects, so maybe this isn't such a big deal.
You could do it even simpler than than. Just src some javascript where the
server returns code that sets a variable to your IP address.
> Anyway, I'm +1 on preventing abuse in proxies, but I don't think this is a
> complete solution.
>
> On Mon, Feb 25, 2008 at 4:56 PM, Brian Eaton <be...@google.com> wrote:
>
> > Admins could correlate X-User-IP (or X-Forwarded-For) headers against
> > the address of the Shindig proxy. This isn't bullet-proof, but it is
> > much better than providing an anonymous open proxy for anyone to
> > abuse.
> >
> > Cheers,
> > Brian
> >
> > On Mon, Feb 25, 2008 at 3:38 PM, Kevin Brown <et...@google.com> wrote:
> > > Do we really want to promote them checking X-User-IP though? Couldn't
> an
> > > abusive user just send this IP anyway?
> > >
> > > It's probably useful to send it for systems that have some sort of
> DOS
> > > prevention mechanism though, but I'm not sure we should encourage
> > anyone to
> > > actually rely on it.
> > >
> > >
> > >
> > > On Mon, Feb 25, 2008 at 3:22 PM, Brian Eaton <be...@google.com>
> wrote:
> > >
> > > > [-opensocial-and-gadgets-spec@googlegroups.com,
> > > > +shindig-dev@incubator.apache.org]
> > > >
> > > > Should the open proxy in Shindig forward an X-User-IP header with
> the
> > > > client's IP to servers the client instructs us to contact?
> > > >
> > > > I'm concerned that the open proxy in Shindig will become a vector
> for
> > > > abuse. Sending the client IP will make it slightly easier for the
> > > > admins of targeted servers to blame the perpetrator rather than the
> > > > Shindig server.
> > > >
> > > > Cheers,
> > > > Brian
> > > >
> > > >
> > > > ---------- Forwarded message ----------
> > > > From: Kevin Brown <et...@google.com>
> > > > Date: Mon, Feb 25, 2008 at 3:18 PM
> > > > Subject: Re: Passing in the client IP
> > > > To: opensocial-and-gadgets-spec@googlegroups.com
> > > >
> > > >
> > > > That's a discussion worth having on the shindig mailing list,
> > > > probably, but it's a different issue than what I think Paul is
> trying
> > > > to address.
> > > >
> > > >
> > > >
> > > > On Mon, Feb 25, 2008 at 3:13 PM, Brian Eaton <be...@google.com>
> > wrote:
> > > >
> > > > >
> > > > > Providing an X-User-IP header for requests sent through the proxy
> > > > > service might help reduce abuse of the open proxy in Shindig.
> > > > >
> > > > >
> > > > > On Mon, Feb 25, 2008 at 11:38 AM, Bruno Bowden <br...@google.com>
> > wrote:
> > > > >
> > > > >
> > > > >
> > > > > > Geolocation is difficult to do well. For example AOL users
> across
> > the
> > > > > > country getting mapped to the same IP address in Virginia. User
> > > > preference
> > > > > > data can be helpful but what if they travel? There's also
> serious
> > > > issues
> > > > > > surrounding user privacy, which vary from country to country.
> > > > > >
> > > > > > Ultimately it should be Shindig's responsibility to draw on as
> > much
> > > > > > information sources as possible and make a best guess.
> > > > > >
> > > > > > Syntax:
> > > > > > Use ints for lat / lon, representing data in microdegrees (more
> > > > accuracy
> > > > > > than using a 4 byte float). This gives up to 14m resolution, so
> > the IP
> > > > > > geotargeting will be a more limiting factor. For example, 145
> > degrees
> > > > =>
> > > > > > 145,000,000.
> > > > > >
> > > > > > Example:
> > > > > > var prefs = new gadgets.Prefs();
> > > > > > var lat = prefs.getString("lat");
> > > > > > var long = prefs.getString("long");
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, Feb 25, 2008 at 7:03 AM, Kevin Marks <
> > kevinmarks@google.com>
> > > > wrote:
> > > > > >
> > > > > > > Why not use the location information in the viewer/owner
> person
> > info
> > > > for
> > > > > > this?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Mon, Feb 25, 2008 at 2:21 AM, Paul Lindner <
> > lindner@inuus.com>
> > > > wrote:
> > > > > > >
> > > > > > > > At a recent hackathon a developer wanted to be able to
> query
> > the
> > > > IP
> > > > > > > > address of the client invoking the gadget. The developer
> > wanted
> > > > to
> > > > > > > > use this for geolocation.
> > > > > > > >
> > > > > > > > Considering that it might be useful to include other http
> > headers
> > > > too,
> > > > > > > > cookies, languages, etc.
> > > > > > > >
> > > > > > > > It seems like it would be fairly easy for the gadget server
> > to
> > > > inject
> > > > > > > > this information.
> > > > > > > >
> > > > > > > > I am unsure what the API to access this information would
> be
> > like.
> > > > > > > >
> > > > > > > > --
> > > > > > > > Paul Lindner ||||| | | | | | | | | |
> > > > > > > > lindner@inuus.com
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > ~Kevin
> > > >
> > > > If you received this email by mistake, please delete it, cancel
> your
> > > > mail account, destroy your hard drive, silence any witnesses, and
> > burn
> > > > down the building that you're in.
> > > >
> > > >
> > > > --~--~---------~--~----~------------~-------~--~----~
> > > > 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-and-gadgets-spec@googlegroups.com
> > > > To unsubscribe from this group, send email to
> > > > opensocial-and-gadgets-spec-unsubscribe@googlegroups.com
> > > > For more options, visit this group at
> > > > http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> > > > -~----------~----~----~----~------~----~------~--~---
> > > >
> > >
> > >
> > >
> > > --
> > > ~Kevin
> > >
> > > If you received this email by mistake, please delete it, cancel your
> > mail
> > > account, destroy your hard drive, silence any witnesses, and burn
> down
> > the
> > > building that you're in.
> > >
> >
>
>
>
> --
> ~Kevin
>
> If you received this email by mistake, please delete it, cancel your mail
> account, destroy your hard drive, silence any witnesses, and burn down the
> building that you're in.
>
Re: Passing in the client IP
Posted by Kevin Brown <et...@google.com>.
Indeed, but they'll still need to be aware of which hosts are rendering
gadgets, which is a tricky issue (and perhaps calls for a recommendation in
the spec, but I'll leave that issue aside for now to focus on the current
problem)
We also don't want to take the burden off of the container to prevent abuse
of their own proxy; we're in the best position to prevent such abuse.
I'm also a little concerned about privacy here. Do we really want the gadget
authors to be able to get the user's IP? For abuse purposes, I'm OK with
some sort of obfuscated identifier (a salted hash of the IP, perhaps), but
this seems potentially dangerous. Of course, they could still get the IP
anyway using redirects, so maybe this isn't such a big deal.
Anyway, I'm +1 on preventing abuse in proxies, but I don't think this is a
complete solution.
On Mon, Feb 25, 2008 at 4:56 PM, Brian Eaton <be...@google.com> wrote:
> Admins could correlate X-User-IP (or X-Forwarded-For) headers against
> the address of the Shindig proxy. This isn't bullet-proof, but it is
> much better than providing an anonymous open proxy for anyone to
> abuse.
>
> Cheers,
> Brian
>
> On Mon, Feb 25, 2008 at 3:38 PM, Kevin Brown <et...@google.com> wrote:
> > Do we really want to promote them checking X-User-IP though? Couldn't an
> > abusive user just send this IP anyway?
> >
> > It's probably useful to send it for systems that have some sort of DOS
> > prevention mechanism though, but I'm not sure we should encourage
> anyone to
> > actually rely on it.
> >
> >
> >
> > On Mon, Feb 25, 2008 at 3:22 PM, Brian Eaton <be...@google.com> wrote:
> >
> > > [-opensocial-and-gadgets-spec@googlegroups.com,
> > > +shindig-dev@incubator.apache.org]
> > >
> > > Should the open proxy in Shindig forward an X-User-IP header with the
> > > client's IP to servers the client instructs us to contact?
> > >
> > > I'm concerned that the open proxy in Shindig will become a vector for
> > > abuse. Sending the client IP will make it slightly easier for the
> > > admins of targeted servers to blame the perpetrator rather than the
> > > Shindig server.
> > >
> > > Cheers,
> > > Brian
> > >
> > >
> > > ---------- Forwarded message ----------
> > > From: Kevin Brown <et...@google.com>
> > > Date: Mon, Feb 25, 2008 at 3:18 PM
> > > Subject: Re: Passing in the client IP
> > > To: opensocial-and-gadgets-spec@googlegroups.com
> > >
> > >
> > > That's a discussion worth having on the shindig mailing list,
> > > probably, but it's a different issue than what I think Paul is trying
> > > to address.
> > >
> > >
> > >
> > > On Mon, Feb 25, 2008 at 3:13 PM, Brian Eaton <be...@google.com>
> wrote:
> > >
> > > >
> > > > Providing an X-User-IP header for requests sent through the proxy
> > > > service might help reduce abuse of the open proxy in Shindig.
> > > >
> > > >
> > > > On Mon, Feb 25, 2008 at 11:38 AM, Bruno Bowden <br...@google.com>
> wrote:
> > > >
> > > >
> > > >
> > > > > Geolocation is difficult to do well. For example AOL users across
> the
> > > > > country getting mapped to the same IP address in Virginia. User
> > > preference
> > > > > data can be helpful but what if they travel? There's also serious
> > > issues
> > > > > surrounding user privacy, which vary from country to country.
> > > > >
> > > > > Ultimately it should be Shindig's responsibility to draw on as
> much
> > > > > information sources as possible and make a best guess.
> > > > >
> > > > > Syntax:
> > > > > Use ints for lat / lon, representing data in microdegrees (more
> > > accuracy
> > > > > than using a 4 byte float). This gives up to 14m resolution, so
> the IP
> > > > > geotargeting will be a more limiting factor. For example, 145
> degrees
> > > =>
> > > > > 145,000,000.
> > > > >
> > > > > Example:
> > > > > var prefs = new gadgets.Prefs();
> > > > > var lat = prefs.getString("lat");
> > > > > var long = prefs.getString("long");
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Feb 25, 2008 at 7:03 AM, Kevin Marks <
> kevinmarks@google.com>
> > > wrote:
> > > > >
> > > > > > Why not use the location information in the viewer/owner person
> info
> > > for
> > > > > this?
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, Feb 25, 2008 at 2:21 AM, Paul Lindner <
> lindner@inuus.com>
> > > wrote:
> > > > > >
> > > > > > > At a recent hackathon a developer wanted to be able to query
> the
> > > IP
> > > > > > > address of the client invoking the gadget. The developer
> wanted
> > > to
> > > > > > > use this for geolocation.
> > > > > > >
> > > > > > > Considering that it might be useful to include other http
> headers
> > > too,
> > > > > > > cookies, languages, etc.
> > > > > > >
> > > > > > > It seems like it would be fairly easy for the gadget server
> to
> > > inject
> > > > > > > this information.
> > > > > > >
> > > > > > > I am unsure what the API to access this information would be
> like.
> > > > > > >
> > > > > > > --
> > > > > > > Paul Lindner ||||| | | | | | | | | |
> > > > > > > lindner@inuus.com
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > ~Kevin
> > >
> > > If you received this email by mistake, please delete it, cancel your
> > > mail account, destroy your hard drive, silence any witnesses, and
> burn
> > > down the building that you're in.
> > >
> > >
> > > --~--~---------~--~----~------------~-------~--~----~
> > > 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-and-gadgets-spec@googlegroups.com
> > > To unsubscribe from this group, send email to
> > > opensocial-and-gadgets-spec-unsubscribe@googlegroups.com
> > > For more options, visit this group at
> > > http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> > > -~----------~----~----~----~------~----~------~--~---
> > >
> >
> >
> >
> > --
> > ~Kevin
> >
> > If you received this email by mistake, please delete it, cancel your
> mail
> > account, destroy your hard drive, silence any witnesses, and burn down
> the
> > building that you're in.
> >
>
--
~Kevin
If you received this email by mistake, please delete it, cancel your mail
account, destroy your hard drive, silence any witnesses, and burn down the
building that you're in.
Re: Passing in the client IP
Posted by Brian Eaton <be...@google.com>.
Admins could correlate X-User-IP (or X-Forwarded-For) headers against
the address of the Shindig proxy. This isn't bullet-proof, but it is
much better than providing an anonymous open proxy for anyone to
abuse.
Cheers,
Brian
On Mon, Feb 25, 2008 at 3:38 PM, Kevin Brown <et...@google.com> wrote:
> Do we really want to promote them checking X-User-IP though? Couldn't an
> abusive user just send this IP anyway?
>
> It's probably useful to send it for systems that have some sort of DOS
> prevention mechanism though, but I'm not sure we should encourage anyone to
> actually rely on it.
>
>
>
> On Mon, Feb 25, 2008 at 3:22 PM, Brian Eaton <be...@google.com> wrote:
>
> > [-opensocial-and-gadgets-spec@googlegroups.com,
> > +shindig-dev@incubator.apache.org]
> >
> > Should the open proxy in Shindig forward an X-User-IP header with the
> > client's IP to servers the client instructs us to contact?
> >
> > I'm concerned that the open proxy in Shindig will become a vector for
> > abuse. Sending the client IP will make it slightly easier for the
> > admins of targeted servers to blame the perpetrator rather than the
> > Shindig server.
> >
> > Cheers,
> > Brian
> >
> >
> > ---------- Forwarded message ----------
> > From: Kevin Brown <et...@google.com>
> > Date: Mon, Feb 25, 2008 at 3:18 PM
> > Subject: Re: Passing in the client IP
> > To: opensocial-and-gadgets-spec@googlegroups.com
> >
> >
> > That's a discussion worth having on the shindig mailing list,
> > probably, but it's a different issue than what I think Paul is trying
> > to address.
> >
> >
> >
> > On Mon, Feb 25, 2008 at 3:13 PM, Brian Eaton <be...@google.com> wrote:
> >
> > >
> > > Providing an X-User-IP header for requests sent through the proxy
> > > service might help reduce abuse of the open proxy in Shindig.
> > >
> > >
> > > On Mon, Feb 25, 2008 at 11:38 AM, Bruno Bowden <br...@google.com> wrote:
> > >
> > >
> > >
> > > > Geolocation is difficult to do well. For example AOL users across the
> > > > country getting mapped to the same IP address in Virginia. User
> > preference
> > > > data can be helpful but what if they travel? There's also serious
> > issues
> > > > surrounding user privacy, which vary from country to country.
> > > >
> > > > Ultimately it should be Shindig's responsibility to draw on as much
> > > > information sources as possible and make a best guess.
> > > >
> > > > Syntax:
> > > > Use ints for lat / lon, representing data in microdegrees (more
> > accuracy
> > > > than using a 4 byte float). This gives up to 14m resolution, so the IP
> > > > geotargeting will be a more limiting factor. For example, 145 degrees
> > =>
> > > > 145,000,000.
> > > >
> > > > Example:
> > > > var prefs = new gadgets.Prefs();
> > > > var lat = prefs.getString("lat");
> > > > var long = prefs.getString("long");
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Feb 25, 2008 at 7:03 AM, Kevin Marks <ke...@google.com>
> > wrote:
> > > >
> > > > > Why not use the location information in the viewer/owner person info
> > for
> > > > this?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Feb 25, 2008 at 2:21 AM, Paul Lindner <li...@inuus.com>
> > wrote:
> > > > >
> > > > > > At a recent hackathon a developer wanted to be able to query the
> > IP
> > > > > > address of the client invoking the gadget. The developer wanted
> > to
> > > > > > use this for geolocation.
> > > > > >
> > > > > > Considering that it might be useful to include other http headers
> > too,
> > > > > > cookies, languages, etc.
> > > > > >
> > > > > > It seems like it would be fairly easy for the gadget server to
> > inject
> > > > > > this information.
> > > > > >
> > > > > > I am unsure what the API to access this information would be like.
> > > > > >
> > > > > > --
> > > > > > Paul Lindner ||||| | | | | | | | | |
> > > > > > lindner@inuus.com
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
> > --
> > ~Kevin
> >
> > If you received this email by mistake, please delete it, cancel your
> > mail account, destroy your hard drive, silence any witnesses, and burn
> > down the building that you're in.
> >
> >
> > --~--~---------~--~----~------------~-------~--~----~
> > 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-and-gadgets-spec@googlegroups.com
> > To unsubscribe from this group, send email to
> > opensocial-and-gadgets-spec-unsubscribe@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> > -~----------~----~----~----~------~----~------~--~---
> >
>
>
>
> --
> ~Kevin
>
> If you received this email by mistake, please delete it, cancel your mail
> account, destroy your hard drive, silence any witnesses, and burn down the
> building that you're in.
>
Re: Passing in the client IP
Posted by Kevin Brown <et...@google.com>.
Do we really want to promote them checking X-User-IP though? Couldn't an
abusive user just send this IP anyway?
It's probably useful to send it for systems that have some sort of DOS
prevention mechanism though, but I'm not sure we should encourage anyone to
actually rely on it.
On Mon, Feb 25, 2008 at 3:22 PM, Brian Eaton <be...@google.com> wrote:
> [-opensocial-and-gadgets-spec@googlegroups.com,
> +shindig-dev@incubator.apache.org]
>
> Should the open proxy in Shindig forward an X-User-IP header with the
> client's IP to servers the client instructs us to contact?
>
> I'm concerned that the open proxy in Shindig will become a vector for
> abuse. Sending the client IP will make it slightly easier for the
> admins of targeted servers to blame the perpetrator rather than the
> Shindig server.
>
> Cheers,
> Brian
>
>
> ---------- Forwarded message ----------
> From: Kevin Brown <et...@google.com>
> Date: Mon, Feb 25, 2008 at 3:18 PM
> Subject: Re: Passing in the client IP
> To: opensocial-and-gadgets-spec@googlegroups.com
>
>
> That's a discussion worth having on the shindig mailing list,
> probably, but it's a different issue than what I think Paul is trying
> to address.
>
>
>
> On Mon, Feb 25, 2008 at 3:13 PM, Brian Eaton <be...@google.com> wrote:
>
> >
> > Providing an X-User-IP header for requests sent through the proxy
> > service might help reduce abuse of the open proxy in Shindig.
> >
> >
> > On Mon, Feb 25, 2008 at 11:38 AM, Bruno Bowden <br...@google.com> wrote:
> >
> >
> >
> > > Geolocation is difficult to do well. For example AOL users across the
> > > country getting mapped to the same IP address in Virginia. User
> preference
> > > data can be helpful but what if they travel? There's also serious
> issues
> > > surrounding user privacy, which vary from country to country.
> > >
> > > Ultimately it should be Shindig's responsibility to draw on as much
> > > information sources as possible and make a best guess.
> > >
> > > Syntax:
> > > Use ints for lat / lon, representing data in microdegrees (more
> accuracy
> > > than using a 4 byte float). This gives up to 14m resolution, so the IP
> > > geotargeting will be a more limiting factor. For example, 145 degrees
> =>
> > > 145,000,000.
> > >
> > > Example:
> > > var prefs = new gadgets.Prefs();
> > > var lat = prefs.getString("lat");
> > > var long = prefs.getString("long");
> > >
> > >
> > >
> > >
> > > On Mon, Feb 25, 2008 at 7:03 AM, Kevin Marks <ke...@google.com>
> wrote:
> > >
> > > > Why not use the location information in the viewer/owner person info
> for
> > > this?
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Feb 25, 2008 at 2:21 AM, Paul Lindner <li...@inuus.com>
> wrote:
> > > >
> > > > > At a recent hackathon a developer wanted to be able to query the
> IP
> > > > > address of the client invoking the gadget. The developer wanted
> to
> > > > > use this for geolocation.
> > > > >
> > > > > Considering that it might be useful to include other http headers
> too,
> > > > > cookies, languages, etc.
> > > > >
> > > > > It seems like it would be fairly easy for the gadget server to
> inject
> > > > > this information.
> > > > >
> > > > > I am unsure what the API to access this information would be like.
> > > > >
> > > > > --
> > > > > Paul Lindner ||||| | | | | | | | | |
> > > > > lindner@inuus.com
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > >
> > >
> >
> >
> >
>
>
>
> --
> ~Kevin
>
> If you received this email by mistake, please delete it, cancel your
> mail account, destroy your hard drive, silence any witnesses, and burn
> down the building that you're in.
>
>
> --~--~---------~--~----~------------~-------~--~----~
> 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-and-gadgets-spec@googlegroups.com
> To unsubscribe from this group, send email to
> opensocial-and-gadgets-spec-unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
--
~Kevin
If you received this email by mistake, please delete it, cancel your mail
account, destroy your hard drive, silence any witnesses, and burn down the
building that you're in.