[Greasemonkey] GM_xmlhttpRequest and localhost

[Godmar Back]

If you disallowed everything to which the user didn't explicitly agree
you wouldn't have to find out what resolves to localhost.

Going back to the business case for some GM scripts.  Suppose a
company would distribute a universal GM script that phones home and
collects a user's browsing pattern under the disguise of providing
some useful service.  Do you think it is your responsibility as GM
developer to warn users when they install this company's deceptive
user script that this script might leak such information to the
company offering this disguised service?

 - Godmar

On 7/19/05, Aaron Boodman <zboogs at gmail.com> wrote:
> I can see doing something with configuration, but it is also seems
> non-trivial to figure out what resolves to localhost and/or other
> internal servers. And accessing internal servers is a very real use
> case.
> 
> I think that the best solution is configuration (about:config) which
> specifies what servers can be contacted. But I think this can wait
> until a later release. People who don't want GM scripts contacting
> internal sites can just not use GM *and* are not in control of what
> scripts they install can just not use GM.
> 
> Put another way, I dont think it's Greasemonkey's responsibility to
> disallow access to the internal network. It seems like a cool feature,
> I agree, but not a requirement.
> 
> On the other hand, if somebody wants to implement this I'll be happy
> to include it. You can patch against the current tree.
> 
> --
> Aaron
> 
> On 7/19/05, Jason Diamond <jason at injektilo.org> wrote:
> > Mark Pilgrim wrote:
> >
> > >  On 7/19/05, Jun Yang <jyang825 at gmail.com> wrote:
> > >
> > > > I think the access to http://localhost is important for many
> > > > wonderful possibilities. However, security concerns are also real.
> > > > Can we plese do this? Some configuration is provided for user to
> > > > allow only GM scripts from certainly sites to access
> > > > http://localhost?
> > >
> > >  Please disable all access by default, then provide options to allow
> > >  access to localhost (and 127.0.0.1!). Such access is only useful for
> > >  script developers, who can enable it if they need it.
> > >
> > >  Even better, don't provide a GUI option for it, just put it in
> > >  about:config (no access by default) and publish documentation on how
> > >  script developers can change it. I can't see any legitimate need to
> > >  bother end users with this.
> >
> > I like disabling everything by default. But why not make it a per-script
> > option like the @include and @exclude headers?
> >
> > // ==UserScript==
> > // ...
> > // @allow-requests-to localhost
> > // ==/UserScript==
> >
> > This makes it explicit what a user script might be contacting on a
> > script-by-script basis. You won't have to look through the source for
> > the script to see if it's contacting anybody you don't want it to.
> >
> > A "@forbid-requests-to" header probably wouldn't be necessary since
> > everything would be (should be) forbidden by default. Unless, of course,
> > you wanted to do something like this:
> >
> > // ==UserScript==
> > // ...
> > // @forbid-request-to *.goatse.cx
> > // @allow-requests-to *
> > // ==/UserScript==
> >
> > Assuming GM is fixed so that websites can't access the GM_* functions,
> > why not allow scripts the use of the file scheme (as long as it's
> > explicitly allowed)?
> >
> > // ==UserScript==
> > // ...
> > // @allow-requests-to file:///home/jason/stuff/*
> > // ==/UserScript==
> >
> > I can imagine this being very useful for scripts that want access to
> > some configuration or metadata but don't want to "hard code" that
> > information in the script itself.
> >
> > --
> > Jason
> > _______________________________________________
> > Greasemonkey mailing list
> > Greasemonkey at mozdev.org
> > http://mozdev.org/mailman/listinfo/greasemonkey
> >
> _______________________________________________
> Greasemonkey mailing list
> Greasemonkey at mozdev.org
> http://mozdev.org/mailman/listinfo/greasemonkey
>