Re: a bug in default .mozconfig

[Mike Hommey]

On Fri, Aug 17, 2007 at 01:21:35AM +0200, Alexander Sack <address@hidden> wrote:
> On Thu, Aug 16, 2007 at 05:24:23PM -0500, Karl Berry wrote:
> >     privacy features are not really reasonable
> > 
> > Well, that's quite a sweeping statement.
> > 
> 
> Can you please keep a bit more context when replying? especially, if
> you declare a statement as "sweeping" it makes sense ...
> 
> 
> > It seems to me the question is not whether it is theoretically possible
> > to work around the privacy features, but whether most web sites actually
> > do.  I don't know how to begin to investigate the answer statistically,
> > but my hunch is that they don't.

Actually, the question is more about if the privacy features address
enough. The fact is the sites *I* know don't use the technique they
address, but another one (to be specific, using window.status to display
the final link, and having a link to a redirector on the site). So sites
are not working around the privacy features but already using techniques
that are not addressed. I'm pretty sure there are other techniques used.
Now the problem with such half-working privacy features is that it gives
a false sense of security to users, and I'm not sure that's a good idea.

BTW, what is so awful about "spying" clicks ? It's not like your clicks
are not already spied on within the same site... and you can't do much
about that, except removing the referers, which might break sites
relying on it for various reasons.

Speaking of referers, if you keep them, the click spying you're avoiding
can be worked around by reverse analysis : the destination site knows
where you come from, they could pretty much inform them. I'm pretty sure
there are patnerships between sites relying on this kind of information.

Note that a privacy feature that I've seen requested a lot is to have
referers not sent when the domain name is different.

Anyways, on the implementation side, the small patch required in the
event handling to be able to observe the event should be cleaned-up and
sent to mozilla.

> >     cleanly to an extension that will help you to merge your changes into
> > 
> > Thank you.  An extension seems to me like the cleanest way to implement
> > them, regardless.  Giuseppe?
> 
> Its not only the cleanest way to implement, but imo probably the only
> way that we will be able to join forces in the long run. Mike?

I do think so, too.

Now, for the others iceweasel changes:

On Wed, Aug 15, 2007 at 11:45:49AM +0200, Giuseppe Scrivano <address@hidden> 
wrote:
> 2) If on a page is present a link to a zero sized image on another
>    site then the hosting image site is blocked to store cookies.  This
>    is for the same reason, to don't allow another site to "spy" user
>    habits and don't get notified on every request to other sites.
>    This mechanism was noticed and if I remember correctly, reported on
>    this ML long time ago.

*I*'ve seen the zero-sized image technique used *nowhere*. I don't doubt
it exists, I just think it's marginal. So marginal that it makes the
feature pretty useless. There are so many techniques used and useable to
do the same thing that it's almost impossible to track. The best thing
that could be done would be to not send cookies when a page on site X
wants to get (not even display) anything from site Y, where X and Y
don't share the same domain name (it might be impractical otherwise)

> 3) We are using an our plugin finder service that shows only Free
>    plugins.  This service can be used by original Mozilla Firefox too
>    changing the pfs.datasource.url attribute in about:config.

This is actually something interesting, though I think there is space
for improvement. I think it would be nice for us (debian) to have our
own web service that could provide links for deb files (or aptitude
install instructions or whatever). If we come to something nice, I think
it'd be worth sending upstream. We'd then only have to change the
datasource url in our builds.

Mike