Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Ross Vandegrift]

On Sat, Sep 28, 2019 at 01:17:14AM -0400, Nicholas D Steeves wrote:
> Florian Weimer  writes:
> > Cloudflare only promises to “never sell your data”.  That doesn't
> > exclude sharing it for free with interested parties.
> >
> 
> So a metadata leak (by design) to an unbounded number of entities,
> affecting all Firefox users, at a time when this data is gold?

No, that is incorrect.  The full text says "CloudFlare will not sell, license,
sublicense, or grant any rights to your data that we collect from DNS queries
to any other person or entity without your consent."  This doesn't cover
APNIC's research, that's described separately.  You may dislike CloudFlare and
APNIC having the data at all - but the entities seem clearly bounded.

In case this isn't well-known: in the US residential ISP market, this privacy
policy is *far* better than anything else on offer.  They commonly give ISPs
much more latitute for abuse.  SiteFinder-style DNS hijacking is widespread,
and often cannot be disabled.  "Contracts" with ISPs are one-sided: they
absolve providers of any liability and force customers to preemptively waive
their rights to legal action.  This is probably the backdrop that Mozilla has
in mind.

But of course US residential internet access isn't the whole world.  The
commercial ISP market in the US is more reasonable.  And maybe residential
broadband is better off elsewhere in the world?

Ross


signature.asc
Description: PGP signature

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Bastian Blank]

On Sat, Sep 28, 2019 at 11:02:30AM +0200, Philipp Kern wrote:
> > 
> https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/firefox/

Those two have one critical difference in what they actually log:

"Cloudflare Resolver IP address + Destination Port"
vs.
"Resolver IP address + Port the Query Originated From"

So the first form only logs the AS the query originated from, the later
logs the IP it comes from.

Bastian

-- 
You're dead, Jim.
-- McCoy, "Amok Time", stardate 3372.7

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Florian Weimer]

* Philipp Kern:

> It is probably worth pointing out that Firefox's use of Cloudflare's DoH
> endpoint is governed by a different policy outlined here:
>
> https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/firefox/

Thanks.

> Per that policy, other third parties can only get the data with
> Mozilla's written permissions. And APNIC (or any other third party) is
> not mentioned.

But isn't that policy less restrictive that the other, once Mozilla
has given permission?

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Philipp Kern]

On 9/27/2019 12:23 PM, Florian Weimer wrote:
[...]>> So currently DoH is strictly worse.
> 
> Furthermore, you don't have a paid contract with Cloudflare, but you
> usually have one with the ISP that runs the recursive DNS resolver.
> 
> If you look at 
> 
>   
> 
> you will see that the data is shared with APNIC for “research”:
> 
> | Under the terms of a cooperative agreement, APNIC will have limited
> | access to query the transaction data for the purpose of conducting
> | research related to the operation of the DNS system.
> 
> And:
> 
> | Specifically, APNIC will be permitted to access query names, query
> | types, resolver location
> 
> 
> 
> Typically, APNIC will only see a subset of the queries if you use your
> ISP's DNS resolver (or run your own recursive resolver).
> 
> Cloudflare only promises to “never sell your data”.  That doesn't
> exclude sharing it for free with interested parties.
It is probably worth pointing out that Firefox's use of Cloudflare's DoH
endpoint is governed by a different policy outlined here:

https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/firefox/

Per that policy, other third parties can only get the data with
Mozilla's written permissions. And APNIC (or any other third party) is
not mentioned.

Kind regards
Philipp Kern

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Nicholas D Steeves]

Wouter Verhelst  writes:

> On Sun, Sep 08, 2019 at 11:17:13PM +0200, Marco d'Itri wrote:
>> On Sep 08, Ondřej Surý  wrote:
>> 
>> > I would rather see an explicit statement. I would be very surprised 
>> > with Debian’s usual stance regarding the users’ privacy that we would 
>> > not consider this as a privacy violation, but again I am not Firefox 
>> > maintainer in Debian and I would rather hear from them than speculate 
>> > on my own.
>> I think that this is a privacy enhancement, since it prevents some major 
>> ISPs from spying on users DNS queries.
>
[snip]
>> It would be a terrible signal if Debian decided to disable an 
>> anti-censoship feature provided by an upstream vendor.
>
> Except DoH is *not* an anti-censorship feature. It is a feature that
> provides a net reduction in privacy.
>
> CloudFlare says that it won't read your DNS requests -- scout's honour!
> -- but even if that's true and we can believe it, there's no reason to
> assume it will continue to do so forever, past any potential future
> acquisitions or CEO changes.
>
> Mozilla really missed the ball on this one. OpenBSD already made the
> necessary changes to Firefox. I think we should, too.
>

+1 !

Especially because

Florian Weimer  writes:

> If you look at 
>
>   
>
> you will see that the data is shared with APNIC for “research”:
>
> | Under the terms of a cooperative agreement, APNIC will have limited
> | access to query the transaction data for the purpose of conducting
> | research related to the operation of the DNS system.
>
> And:
>
> | Specifically, APNIC will be permitted to access query names, query
> | types, resolver location
>
> 
>
> Typically, APNIC will only see a subset of the queries if you use your
> ISP's DNS resolver (or run your own recursive resolver).
>
> Cloudflare only promises to “never sell your data”.  That doesn't
> exclude sharing it for free with interested parties.
>

So a metadata leak (by design) to an unbounded number of entities,
affecting all Firefox users, at a time when this data is gold?

How is this not as bad or worse than GAFA?


Regards,
Nicholas


signature.asc
Description: PGP signature

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Bjørn Mork]

Robert Edmonds  writes:

> The entire DNS root zone is only 1 MB compressed and is updated about
> once a day. It would be even better for privacy if the whole root zone
> were distributed via HTTPS, as the initiator would not reveal to the
> server any information about what TLD is being looked up.

Running a local root instance is possible and easy.  See
https://tools.ietf.org/html/rfc7706


Bjørn

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Florian Weimer]

* Robert Edmonds:

> The entire DNS root zone is only 1 MB compressed and is updated about
> once a day. It would be even better for privacy if the whole root zone
> were distributed via HTTPS, as the initiator would not reveal to the
> server any information about what TLD is being looked up.
>
> There are currently ~1500 TLDs in the root zone. Dividing 1 MB by the
> number of TLDs, this is ~700 bytes per TLD, which is roughly the amount
> of bandwidth required by a query/response pair of UDP DNS packets to
> obtain the delegation for a TLD.

Or you can turn on query minimization and NSEC-based NXDOMAIN
synthesis, at which point there is hardly any privacy leak left.

The challenge with the root zone is that anyone can become a de-facto
root server operator for their own part of the Internet (at least with
physical control over machines), by inviting some of the established
operators to host an anycast node on their network.  It's very
difficult to guarantee privacy in such a widely distributed system.

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Florian Weimer]

* Adam Borowski:

> Let's compare; by "ISP" I mean every hop on the network path.
>
> With local DNS:
> * the target server knows about you (duh!)
> * the ISP can read the destination of every connection
>   [reading the DNS packets, reading the IP header, reading SNI header]
> * the ISP can block such connections
>   [blocking DNS packets, blocking actual connection]
> * DNSSEC forbids falsifying DNS
>
> With DoH:
> * the target server knows about you (duh!)
> * the ISP can read the destination of every connection
>   [reading the IP header, reading SNI header]
> * the ISP can block such connections
>   [blocking actual connection]
> * Cloudflare can read the destination of every connection
>   [they serve the DNS...]
> * Cloudflare can falsify DNS¹
> * Cloudflare can block connections
>   [blocking or falsifying DNS response]
>
> So currently DoH is strictly worse.

Furthermore, you don't have a paid contract with Cloudflare, but you
usually have one with the ISP that runs the recursive DNS resolver.

If you look at 

  

you will see that the data is shared with APNIC for “research”:

| Under the terms of a cooperative agreement, APNIC will have limited
| access to query the transaction data for the purpose of conducting
| research related to the operation of the DNS system.

And:

| Specifically, APNIC will be permitted to access query names, query
| types, resolver location



Typically, APNIC will only see a subset of the queries if you use your
ISP's DNS resolver (or run your own recursive resolver).

Cloudflare only promises to “never sell your data”.  That doesn't
exclude sharing it for free with interested parties.

(Some people may find it amusing that I'm concerned by this because I
opened that particular can of worms fifteen years ago.)

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Amir H. Firouzian]

Debian doesn't add ESNI Record into it's Name Server.

Check here (ONLINE dig):
https://toolbox.googleapps.com/apps/dig/#TXT/

Check these two domains:
_esni.debian.org
_esni.cloudflare.com

On Sun, Sep 15, 2019 at 5:31 AM Paul Wise  wrote:
>
> On Sun, Sep 15, 2019 at 5:48 AM Anthony DeRobertis wrote:
> > On 9/13/19 7:05 AM, Simon Richter wrote:
> > >
> > > Mandatory Encrypted SNI with no fallback option -- everything else can be
> > > circumvented easily.
> > >
> > > This is a game that we should not play, really. It raises the cost of
> > > running a service on the Internet so only big players can afford to do so.
> >
> > Does it? I haven't personally deployed it yet anywhere, but when I
> > briefly looked into it, it appears to require adding a DNS record & some
> > web server config. If anything, it appears to be harder to do if you're
> > a big player (e.g., making sure your DNS servers always return matching
> > ESNI and A/ records, even when you have geo-targeted DNS — so much
> > easier when you only have one server.)
>
> Does anyone know if any software in Debian supports ESNI records?
>
> Looking at the RFC draft, it sounds like adding ESNI records to
> debian.org would basically duplicate the DANE records debian.org
> already has. sigh
>
> https://datatracker.ietf.org/doc/draft-ietf-tls-esni/?include_text=1
> https://serverfault.com/questions/976377/how-can-i-set-up-encrypted-sni-on-my-own-servers
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Paul Wise]

On Sun, Sep 15, 2019 at 5:48 AM Anthony DeRobertis wrote:
> On 9/13/19 7:05 AM, Simon Richter wrote:
> >
> > Mandatory Encrypted SNI with no fallback option -- everything else can be
> > circumvented easily.
> >
> > This is a game that we should not play, really. It raises the cost of
> > running a service on the Internet so only big players can afford to do so.
>
> Does it? I haven't personally deployed it yet anywhere, but when I
> briefly looked into it, it appears to require adding a DNS record & some
> web server config. If anything, it appears to be harder to do if you're
> a big player (e.g., making sure your DNS servers always return matching
> ESNI and A/ records, even when you have geo-targeted DNS — so much
> easier when you only have one server.)

Does anyone know if any software in Debian supports ESNI records?

Looking at the RFC draft, it sounds like adding ESNI records to
debian.org would basically duplicate the DANE records debian.org
already has. sigh

https://datatracker.ietf.org/doc/draft-ietf-tls-esni/?include_text=1
https://serverfault.com/questions/976377/how-can-i-set-up-encrypted-sni-on-my-own-servers

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Anthony DeRobertis]

On 9/13/19 7:05 AM, Simon Richter wrote:


Mandatory Encrypted SNI with no fallback option -- everything else can be
circumvented easily.

This is a game that we should not play, really. It raises the cost of
running a service on the Internet so only big players can afford to do so.


Does it? I haven't personally deployed it yet anywhere, but when I 
briefly looked into it, it appears to require adding a DNS record & some 
web server config. If anything, it appears to be harder to do if you're 
a big player (e.g., making sure your DNS servers always return matching 
ESNI and A/ records, even when you have geo-targeted DNS — so much 
easier when you only have one server.)

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Amir H. Firouzian]

Becuase the best privacy solution would be to embed DNS resolver into
mozilla and they query root servers (which manage by ICANN) to find
IPs of TLDs server!
I mean the "users’ privacy" is a opaque general definition, rather
there are the spectrum of techniques which protect us against mass
surveillance. So in some sense there is violation and in other
condition it could be protector (ISP don't realize the packet DNS
QUERY ONLY). There is a trade of as always :)

On Thu, Sep 12, 2019 at 10:28 PM Ondřej Surý  wrote:
>
> What? How did you manage to go from me suggesting disabling DoH by default to 
> CloudFlare in Firefox without explicit user consent to an attack on ICANN?
>
> But I guess that this alternative DNS root nonsense will just never die, so I 
> should not be really surprised.
>
> --
> Ondřej Surý 
>
> > On 12 Sep 2019, at 19:45, Amir H. Firouzian  wrote:
> >
> > Then you should ask why we have ICANN in the first place!
> >
> > PS: https://en.wikipedia.org/wiki/OpenNIC
> >
> >> On Sun, Sep 8, 2019 at 11:01 PM Ondřej Surý  wrote:
> >>
> >> Hi,
> >>
> >> I haven’t found any discussion on the topic (although I haven’t searched 
> >> very hard and only looked for DoH and DNS keywords in the BTS), but since 
> >> Mozilla plans to enable DoH to CloudFlare by default to US based users: 
> >> https://blog.mozilla.org/futurereleases/2019/09/06/whats-next-in-making-dns-over-https-the-default/
> >>  I would rather see an explicit statement. I would be very surprised with 
> >> Debian’s usual stance regarding the users’ privacy that we would not 
> >> consider this as a privacy violation, but again I am not Firefox 
> >> maintainer in Debian and I would rather hear from them than speculate on 
> >> my own.
> >>
> >> Thanks,
> >> Ondřej
> >> --
> >> Ondřej Surý 

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Shengjing Zhu]

On Sat, Sep 14, 2019 at 12:25 PM Shengjing Zhu  wrote:
> It's too native have such thoughts. It's never "too big to block".

s/native/naive/

-- 
Shengjing Zhu

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Shengjing Zhu]

On Fri, Sep 13, 2019 at 7:05 PM Simon Richter  wrote:
>
> Hi,
>
> On Fri, Sep 13, 2019 at 12:28:23PM +0200, Marco d'Itri wrote:
>
> > > Note that by way of counterargument, Google and its services have
> > > been blocked in mainland China by the Great Firewall for nearly a
> > > decade now, so I question whether there is really such a thing as
> > > "too big to block."
>
> > This is a false dichotomy: not all nation states are willing to go to
> > the extreme lengths as China.
>
> Also, China cannot block Github, because they have no equivalent, and even
> if they did, it wouldn't have the same content. Google is too easily
> replicated, because they have no immediate contributors.
>
> I expect that China will set up a proxy service with clones of all relevant
> Github repositories soon to keep read-only access to free software around
> but inhibit organizing through shared documents.
>
> CloudFlare has too many services behind them that are important for the
> economy and not replicable, so they are in a better position than Github
> here.
>

Really?

It's too native have such thoughts. It's never "too big to block".
It's "not worth to block" if it's not too big. If you are in the
"real" censorship environment, you would know how meaningless it is to
rely on some "big" third-partys.

Please don't in name of censorship-resistant.

-- 
Shengjing Zhu

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Roger Lynn]

On 09/09/19 14:40, Bjørn Mork wrote:

Ondřej Surý  writes:

Otherwise it doesn’t make any sense to remove external links to logos
and JavaScript from the documentation and then send everything to one
single US-based provider.


Exactly. I'd be worried if anything in Debian came preconfigured with
DNS servers of any kind.


It apparently already does, although they appear to be used only under 
certain circumstances. See https://bugs.debian.org/761658


Roger

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Sam Hartman]

> "Holger" == Holger Levsen  writes:

>> Mozilla really missed the ball on this one. OpenBSD already made
>> the necessary changes to Firefox. I think we should, too.

Holger> agreed.

OK, so, it seems like the way we do things, that's going to be the
firefox maintainer's decision.

I think right now this discussion is drifting away from being
productive.  There's not a clear consensus and people are starting to
repeat each other.
It could be useful if any of a number of things are happen:

* The firefox maintainers pop up and say it is useful to them.  For
  example if they are trying to get additional input to make a
  decision.  (My assumption is that the firefox maintainers have not
  been particularly active in this discussion.  If so, my entire basis
  for this message may be wrong.  In a different worldh I would go check
  and see who all the active firefox maintainers were and see if they
  have been active)

* Someone volunteers to write up the arguments made here as part of a
  bug requesting either no change or some change.  Obviously such a bug
  could point to this discussion and better yet summarize the arguments
  made.

--Sam

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Evilham]

On dv., set. 13 2019, Simon Richter wrote:


Hi,

On Fri, Sep 13, 2019 at 12:28:23PM +0200, Marco d'Itri wrote:

> Note that by way of counterargument, Google and its services 
> have
> been blocked in mainland China by the Great Firewall for 
> nearly a
> decade now, so I question whether there is really such a 
> thing as

> "too big to block."


This is a false dichotomy: not all nation states are willing to 
go to

the extreme lengths as China.


Also, China cannot block Github, because they have no 
equivalent, and even
if they did, it wouldn't have the same content. Google is too 
easily

replicated, because they have no immediate contributors.

I expect that China will set up a proxy service with clones of 
all relevant
Github repositories soon to keep read-only access to free 
software around

but inhibit organizing through shared documents.

CloudFlare has too many services behind them that are important 
for the
economy and not replicable, so they are in a better position 
than Github

here.

Also, this is a cat and mouse game and DoH is probably just the 
next

step :encrypted SNI will probably be needed as well later.


Mandatory Encrypted SNI with no fallback option -- everything 
else can be

circumvented easily.

This is a game that we should not play, really. It raises the 
cost of
running a service on the Internet so only big players can afford 
to do so.


We are throwing some ice cubes into the boiling pot so there are 
local
zones that are warming up slow enough that the frogs there do 
not notice.

This is a losing strategy.

   Simon



There's also this:
 https://use-application-dns.net/
 https://tools.ietf.org/html/draft-grover-add-policy-detection-00

The way I read it, it means that "soon" DoH would be enabled by 
default for "everyone" unless it can be trivially disabled by the 
network operator.


Quite confusing, at least for me it'd look as having all the 
issues of centralising DNS (a couple kill-switches for de-facto 
global censorship) and then undoing all the benefits of using 
encrypted DNS in the first place.

--
Evilham

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Holger Levsen]

On Thu, Sep 12, 2019 at 11:02:22PM +0200, Wouter Verhelst wrote:
> Except DoH is *not* an anti-censorship feature. It is a feature that
> provides a net reduction in privacy.

agreed.

> CloudFlare says that it won't read your DNS requests -- scout's honour!
> -- but even if that's true and we can believe it, there's no reason to
> assume it will continue to do so forever, past any potential future
> acquisitions or CEO changes.

exactly.

> Mozilla really missed the ball on this one. OpenBSD already made the
> necessary changes to Firefox. I think we should, too.

agreed.

so, iceweasel again? :)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Marco d'Itri]

On Sep 13, Ondřej Surý  wrote:

> > We are talking about preventing large scale censorship (I do not think 
> > that this is really about privacy) for *general users*: obviously *we* 
> > already know about countless workarounds.
> That’s a false statement. Right now, we are talking about sending _all_ your 
> queries from
> just **one** application - Mozilla Firefox.  And what’s worse - if we are 
> talking about protecting
> the users, it could lead to a false sense of protection - any other 
> application in the system
> will send the DNS queries through stub resolver (e.g. most probably to 
> whatever the system
> gets from the DHCP).
I have never argued for or against "protecting users": the problem 
I care about is DNS-based censorship of web sites and DoH from the 
browser to a third party resolver solves this, at least for the time 
being.

> BTW there’s a new initiative - Encrypted DNS and if you look closely, ISC is 
> on the list of
I have seen it: it is an interesting list of companies selling 
DNS-related products or services, USA ISPs who are highly suspect in 
their sudden interest in their customers' privacy and of UK ISPs that 
I assume are subject to regulatory pressure.

> participants from the very beginning.  There’s no doubt that we need to 
> encrypt DNS, but
> in a way that won’t lead to every app sending it’s DNS queries to a different 
> resolver.
This would be nice: maybe a few of these large companies would like to 
fund adding DoH support to systemd-resolved?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Simon Richter]

Hi,

On Fri, Sep 13, 2019 at 12:28:23PM +0200, Marco d'Itri wrote:

> > Note that by way of counterargument, Google and its services have
> > been blocked in mainland China by the Great Firewall for nearly a
> > decade now, so I question whether there is really such a thing as
> > "too big to block."

> This is a false dichotomy: not all nation states are willing to go to 
> the extreme lengths as China.

Also, China cannot block Github, because they have no equivalent, and even
if they did, it wouldn't have the same content. Google is too easily
replicated, because they have no immediate contributors.

I expect that China will set up a proxy service with clones of all relevant
Github repositories soon to keep read-only access to free software around
but inhibit organizing through shared documents.

CloudFlare has too many services behind them that are important for the
economy and not replicable, so they are in a better position than Github
here.

> Also, this is a cat and mouse game and DoH is probably just the next 
> step :encrypted SNI will probably be needed as well later.

Mandatory Encrypted SNI with no fallback option -- everything else can be
circumvented easily.

This is a game that we should not play, really. It raises the cost of
running a service on the Internet so only big players can afford to do so.

We are throwing some ice cubes into the boiling pot so there are local
zones that are warming up slow enough that the frogs there do not notice.
This is a losing strategy.

   Simon

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Ondřej Surý]

> On 13 Sep 2019, at 12:25, Marco d'Itri  wrote:
> 
> We are talking about preventing large scale censorship (I do not think 
> that this is really about privacy) for *general users*: obviously *we* 
> already know about countless workarounds.

That’s a false statement. Right now, we are talking about sending _all_ your 
queries from
just **one** application - Mozilla Firefox.  And what’s worse - if we are 
talking about protecting
the users, it could lead to a false sense of protection - any other application 
in the system
will send the DNS queries through stub resolver (e.g. most probably to whatever 
the system
gets from the DHCP).

Again, please note, I am not advocating against DoH or DoT, I just think we 
need to do
a better job to protect our users than blindly following Mozilla’s lead by 
enabling it by default
without explicit user consent.

BTW there’s a new initiative - Encrypted DNS and if you look closely, ISC is on 
the list of
participants from the very beginning.  There’s no doubt that we need to encrypt 
DNS, but
in a way that won’t lead to every app sending it’s DNS queries to a different 
resolver.

Ondrej
--
Ondřej Surý
ond...@sury.org

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Marco d'Itri]

On Sep 13, Jeremy Stanley  wrote:

> Note that by way of counterargument, Google and its services have
> been blocked in mainland China by the Great Firewall for nearly a
> decade now, so I question whether there is really such a thing as
> "too big to block."
This is a false dichotomy: not all nation states are willing to go to 
the extreme lengths as China.
Also, this is a cat and mouse game and DoH is probably just the next 
step :encrypted SNI will probably be needed as well later.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Marco d'Itri]

On Sep 13, Thomas Goirand  wrote:

> You shouldn't insist on always writing "their ISP", as if it was the
> only choice. It isn't. One can setup his own recursive DNS locally, for
> example. I've done this for years, as I didn't trust my ISP (first, in
Sure, me too: but it does not matter, because if somebody knows how to 
setup a local resolver then they surely can change a browser setting as 
well.
We are talking about preventing large scale censorship (I do not think 
that this is really about privacy) for *general users*: obviously *we* 
already know about countless workarounds.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Thomas Goirand]

On 9/10/19 7:46 PM, Marco d'Itri wrote:
> You obviously consider Mozilla's choices of trusted resolvers (currently 
> Cloudflare, hopefully others too in the future) a bigger privacy risk 
> for generic users (the one who use the browser defaults) than their ISP, 
> I disagree.

You shouldn't insist on always writing "their ISP", as if it was the
only choice. It isn't. One can setup his own recursive DNS locally, for
example. I've done this for years, as I didn't trust my ISP (first, in
China, now I don't trust here in Europe either).

Thomas

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Shengjing Zhu]

// send from my mobile device

Jeremy Stanley  于 2019年9月13日周五 06:51写道：

> On 2019-09-12 22:27:39 +0200 (+0200), Simon Richter wrote:
> [...]
> > The idea for resilience is "too big to block".
> >
> > When Domain Fronting still worked with Google, people used this to
> > circumvent censorship because blocking it would have required
> > blocking Google, so cooperation from Google was necessary to
> > implement effective censorship.
> [...]
> > I'd be in favour of installing it by default (keep in mind: we are
> > also "too big to block", so we're in the position to give software
> > that is useful for activists an install base that makes it hard to
> > identify activists by having the software installed).
>
> Note that by way of counterargument, Google and its services have
> been blocked in mainland China by the Great Firewall for nearly a
> decade now, so I question whether there is really such a thing as
> "too big to block."
> --
> Jeremy Stanley
>

I share the same concern. And please note that cloudflare doesn't have pop
in China mainland, and in some ISP from China, the latency can be more than
200ms(http://mping.chinaz.com/?host=1.0.0.1).

>

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Jeremy Stanley]

On 2019-09-12 22:27:39 +0200 (+0200), Simon Richter wrote:
[...]
> The idea for resilience is "too big to block".
> 
> When Domain Fronting still worked with Google, people used this to
> circumvent censorship because blocking it would have required
> blocking Google, so cooperation from Google was necessary to
> implement effective censorship.
[...]
> I'd be in favour of installing it by default (keep in mind: we are
> also "too big to block", so we're in the position to give software
> that is useful for activists an install base that makes it hard to
> identify activists by having the software installed).

Note that by way of counterargument, Google and its services have
been blocked in mainland China by the Great Firewall for nearly a
decade now, so I question whether there is really such a thing as
"too big to block."
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Wouter Verhelst]

On Thu, Sep 12, 2019 at 11:43:33PM +0200, Marco d'Itri wrote:
> On Sep 12, Wouter Verhelst  wrote:
> 
> > Except all they need to do is return NXDOMAIN on the
> > "use-application-dns.net" domain, and Presto! they can spy on their
> > users again.
> They need to have a government to compel then to do it, which is not 
> obvious.

That's not in the announcement. In fact, it also allows for "opt-in
parental controls", which has nothing to do with governments.

> And then Mozilla will disable that (you can read this clearly 
> in their announcement) and figure out a different strategy.

The announcement does indeed mention that, yes. I sincerely doubt
they'll actually do that, though, unless more than, say, 50% of the
networks they measure end up disabling things.

Of course that's just a matter of personal opinion.

> > Meanwhile, Firefox' default sends everything to the other side of the
> > Internet without the user's consent. How does that improve privacy?
> Not really "to the other side": Cloudflare's resolvers are highly 
> anycasted.

I admit to using some hyperbole here, but the point was that your data
is being sent to a partner of the software you happen to be using,
without you having a contractual relationship with them.

If your bank did that, you'd yell that it's improper. So why is a
browser allowed to do so?

Don't get me wrong; I applaud Mozilla for trying to make encrypted DNS
the default. I just don't think they're going about it the right way.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Marco d'Itri]

On Sep 12, Wouter Verhelst  wrote:

> Except all they need to do is return NXDOMAIN on the
> "use-application-dns.net" domain, and Presto! they can spy on their
> users again.
They need to have a government to compel then to do it, which is not 
obvious. And then Mozilla will disable that (you can read this clearly 
in their announcement) and figure out a different strategy.

> Meanwhile, Firefox' default sends everything to the other side of the
> Internet without the user's consent. How does that improve privacy?
Not really "to the other side": Cloudflare's resolvers are highly 
anycasted.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Wouter Verhelst]

On Tue, Sep 10, 2019 at 07:56:48PM +0200, Julien Cristau wrote:
> On Tue, Sep 10, 2019 at 08:24:03 +0200, Ondřej Surý wrote:
> 
> > > On 9 Sep 2019, at 15:31, Bjørn Mork  wrote:
> > > 
> > > I for one, do trust my ISPs a lot more than I trust Cloudflare or
> > > Google, simply based on the jurisdiction.
> > 
> > While I still strongly agree with you on this one (even though I think all
> > major ISPs here are scumbags, especially the incumbent), I still strongly
> > think we should not have this debate here, and we should turn this around
> > the usual Debian policy - to not send data to 3rd party without explicit 
> > user
> > content and defaulting to not doing so.
> > 
> How is this worse than what we're already doing by default, namely
> sending the same data to whoever happens to be on the network, in
> addition to whoever happened to be listed in an unauthenticated dhcp
> response?  (Which, if you're lucky, is your ISP, aka a 3rd party.)

The major difference is that third party is someone you've got a
contractual relation with.

If you're talking to CloudFlare, you don't. Good luck calling CloudFlare
support when something goes wrong.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Wouter Verhelst]

On Sun, Sep 08, 2019 at 11:17:13PM +0200, Marco d'Itri wrote:
> On Sep 08, Ondřej Surý  wrote:
> 
> > I would rather see an explicit statement. I would be very surprised 
> > with Debian’s usual stance regarding the users’ privacy that we would 
> > not consider this as a privacy violation, but again I am not Firefox 
> > maintainer in Debian and I would rather hear from them than speculate 
> > on my own.
> I think that this is a privacy enhancement, since it prevents some major 
> ISPs from spying on users DNS queries.

Except all they need to do is return NXDOMAIN on the
"use-application-dns.net" domain, and Presto! they can spy on their
users again.

https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https

So no, DoH defeats people who run wireshark, but it does not "prevent
some major ISPs from spying". If a "major ISP" wants to spy, it just
needs to tell Firefox "hey, that DoH feature? Please just disable it,"
and it's back in business.

Meanwhile, Firefox' default sends everything to the other side of the
Internet without the user's consent. How does that improve privacy?

> When it will be enabled in other countries it will prevent
> government-mandated (or "encouraged") censorship.

Nope. See above.

> It would be a terrible signal if Debian decided to disable an 
> anti-censoship feature provided by an upstream vendor.

Except DoH is *not* an anti-censorship feature. It is a feature that
provides a net reduction in privacy.

CloudFlare says that it won't read your DNS requests -- scout's honour!
-- but even if that's true and we can believe it, there's no reason to
assume it will continue to do so forever, past any potential future
acquisitions or CEO changes.

Mozilla really missed the ball on this one. OpenBSD already made the
necessary changes to Firefox. I think we should, too.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard


signature.asc
Description: PGP signature

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Simon Richter]

Hi,

On Thu, Sep 12, 2019 at 06:52:47PM +0200, Adam Borowski wrote:

> > I still believe that generic users are better served by deploying more 
> > censorship-resistant protocols than by worrying that Cloudflare (or 
> > whoever else) would violate the privacy requirements mandated by 
> > Mozilla.

> Sure, but DoH is less censorship-resistant not more.

The idea for resilience is "too big to block".

When Domain Fronting still worked with Google, people used this to
circumvent censorship because blocking it would have required blocking
Google, so cooperation from Google was necessary to implement effective
censorship.

For the same reason, a lot of political activism is taking place on Github,
who have a smaller target market than Google and have fewer staff exposed
in hostile political environments, so they can manage threats by
restricting employees' travel.

The same will apply to services also hosted on a big CDN, and I believe
that is the business model behind providing this service in the first
place -- pull international activists onto CloudFlare.

I expect this to bring a marked improvement for a short time, followed by
the realization at CF that they exist by the kind permission of
nation-state actors that are very interested in strategic Internet choke
points.

To put it bluntly: CloudFlare has, as a consequence of their business
model, too many employees and assets bound in various jurisdictions. Their
censorship resilience is going to be limited to countries where they do not
have a local presence.

They already need to be able to return different results depending on the
client's IP address, otherwise they break anycast or split horizon based
load balancing for everyone whose DNS they do not control themselves. This
mechanism will be used to limit the scope of governmental censorship
requests to the appropriate geographic area.

To be honest, my feeling is that CloudFlare management are not believing
this to be political at all -- it's a technical solution that improves
service for their own customers and degrades service for non-customers
(because it breaks traditional geo-based load balancing), so of course they
are going to do this.

They have a history of ignoring context, and the fallout will be
interesting to watch. In the meantime, we have a responsibility towards our
users to not expose them to unnecessary risks.

I'm fairly sure that a plugin to control the DoH setting from the
navigation bar will pop up shortly. I'd be in favour of installing it by
default (keep in mind: we are also "too big to block", so we're in the
position to give software that is useful for activists an install base that
makes it hard to identify activists by having the software installed).

   Simon

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Clément Hermann]

Le September 12, 2019 4:52:47 PM UTC, Adam Borowski  a 
écrit :
>On Tue, Sep 10, 2019 at 07:46:57PM +0200, Marco d'Itri wrote:
>> On Sep 09, Adam Borowski  wrote:
>> 
>> > With DoH:
>> > * the target server knows about you (duh!)
>> > * the ISP can read the destination of every connection
>> >   [reading the IP header, reading SNI header]
>> > * the ISP can block such connections
>> >   [blocking actual connection]
>> Well, no. They cannot without significantly more expensive hardware
>to 
>> do DPI and a *totally different* legislative framework.
>> (Source: I have been dealing with government-mandated censorship in 
>> Italy for ~15 years, both at technical and policy levels.)
>
>I don't understand how blocking by IP would be any more expensive than
>blocking by DNS.  It's _cheaper_: you read a field in the IP header
>instead
>of doing it in a higher level DNS server.

I don't think it is, actually. Disregarding the legal framework part, only 
looking at the technical aspect of things, when you do it with DNS, you just 
have to create a local version of the zone that has be censored and distribute 
it normally on your resolvers, for instance. 

Anyway you do a high level modification in a high level service. Request will 
go through your DNS infrastructure the way it's intended to.

However, reading IP headers on routers to block a particular destination is not 
how network are designed to operate. It's not as cheap a function you'd think, 
because it means either being able on the customer router, or close to it, and 
those aren't usually designed to filter that way, or you make sure all traffic 
pass by a filtering router at some point - which means dedicated hardware with 
the traffic load involved. This is usually complicated in a large ISP context: 
networks are huge and evolved over time ; and they weren't designed for 
censorship to begin with, there was this thing called Net Neutrality... ;)

Cheers,

-- 
nodens

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Ondřej Surý]

What? How did you manage to go from me suggesting disabling DoH by default to 
CloudFlare in Firefox without explicit user consent to an attack on ICANN?

But I guess that this alternative DNS root nonsense will just never die, so I 
should not be really surprised.

--
Ondřej Surý 

> On 12 Sep 2019, at 19:45, Amir H. Firouzian  wrote:
> 
> Then you should ask why we have ICANN in the first place!
> 
> PS: https://en.wikipedia.org/wiki/OpenNIC
> 
>> On Sun, Sep 8, 2019 at 11:01 PM Ondřej Surý  wrote:
>> 
>> Hi,
>> 
>> I haven’t found any discussion on the topic (although I haven’t searched 
>> very hard and only looked for DoH and DNS keywords in the BTS), but since 
>> Mozilla plans to enable DoH to CloudFlare by default to US based users: 
>> https://blog.mozilla.org/futurereleases/2019/09/06/whats-next-in-making-dns-over-https-the-default/
>>  I would rather see an explicit statement. I would be very surprised with 
>> Debian’s usual stance regarding the users’ privacy that we would not 
>> consider this as a privacy violation, but again I am not Firefox maintainer 
>> in Debian and I would rather hear from them than speculate on my own.
>> 
>> Thanks,
>> Ondřej
>> --
>> Ondřej Surý 

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Amir H. Firouzian]

Then you should ask why we have ICANN in the first place!

PS: https://en.wikipedia.org/wiki/OpenNIC

On Sun, Sep 8, 2019 at 11:01 PM Ondřej Surý  wrote:
>
> Hi,
>
> I haven’t found any discussion on the topic (although I haven’t searched very 
> hard and only looked for DoH and DNS keywords in the BTS), but since Mozilla 
> plans to enable DoH to CloudFlare by default to US based users: 
> https://blog.mozilla.org/futurereleases/2019/09/06/whats-next-in-making-dns-over-https-the-default/
>  I would rather see an explicit statement. I would be very surprised with 
> Debian’s usual stance regarding the users’ privacy that we would not consider 
> this as a privacy violation, but again I am not Firefox maintainer in Debian 
> and I would rather hear from them than speculate on my own.
>
> Thanks,
> Ondřej
> --
> Ondřej Surý 

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Bastian Blank]

On Thu, Sep 12, 2019 at 06:26:34PM +0200, Marc Haber wrote:
> Will DOH break corporate web apps that are accessed over a VPN (and
> thus only resolvable via the local resolver)? Or has Mozilla catered
> for that?

Please see https://wiki.mozilla.org/Trusted_Recursive_Resolver.
network.trr.mode=2 seems to configure what you want.  DoH needs to be
able to bootstrap anyway.

Bastian

-- 
Youth doesn't excuse everything.
-- Dr. Janice Lester (in Kirk's body), "Turnabout Intruder",
   stardate 5928.5.

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Ansgar]

Adam Borowski writes:
> On Tue, Sep 10, 2019 at 07:46:57PM +0200, Marco d'Itri wrote:
>> Well, no. They cannot without significantly more expensive hardware to 
>> do DPI and a *totally different* legislative framework.
>> (Source: I have been dealing with government-mandated censorship in 
>> Italy for ~15 years, both at technical and policy levels.)
>
> I don't understand how blocking by IP would be any more expensive than
> blocking by DNS.  It's _cheaper_: you read a field in the IP header instead
> of doing it in a higher level DNS server.

>From the top of my head I can think of several reasons:

 - For IP-level blocking you need to implement blocking in more places
   instead of a central place (DNS); also more data needs to be
   processed in total.  Block lists are generally not public and access
   to them might need different restrictions (for legal reasons).

 - IP-level blocking leads to more overblocking (anything sharing the
   same IP); this causes legal problems.

So Marco's arguments seem reasonable.

>> > * Cloudflare can falsify DNS¹
>> You can use DNSSEC over DoH.
>
> If implemented.

It's probably easier to use DNSSEC with DoH as you avoid broken
resolvers at ISP or customer routers that don't speak DNSSEC or not even
proper DNS.  I've encountered customer routers that knew only about `A`
RRs and lied about `PTR` which breaks stuff in interesting ways...

Ansgar

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Adam Borowski]

On Tue, Sep 10, 2019 at 07:46:57PM +0200, Marco d'Itri wrote:
> On Sep 09, Adam Borowski  wrote:
> 
> > With DoH:
> > * the target server knows about you (duh!)
> > * the ISP can read the destination of every connection
> >   [reading the IP header, reading SNI header]
> > * the ISP can block such connections
> >   [blocking actual connection]
> Well, no. They cannot without significantly more expensive hardware to 
> do DPI and a *totally different* legislative framework.
> (Source: I have been dealing with government-mandated censorship in 
> Italy for ~15 years, both at technical and policy levels.)

I don't understand how blocking by IP would be any more expensive than
blocking by DNS.  It's _cheaper_: you read a field in the IP header instead
of doing it in a higher level DNS server.

> > * Cloudflare can falsify DNS¹
> You can use DNSSEC over DoH.

If implemented.

> You obviously consider Mozilla's choices of trusted resolvers (currently 
> Cloudflare, hopefully others too in the future) a bigger privacy risk 
> for generic users (the one who use the browser defaults) than their ISP, 
> I disagree.

Currently you need to trust the ISP; with DoH you need to trust both the ISP
and Cloudflare.  Unless you tunnel all the data over DNS (iodine), you need
to contact your actual destination over open network.

> I still believe that generic users are better served by deploying more 
> censorship-resistant protocols than by worrying that Cloudflare (or 
> whoever else) would violate the privacy requirements mandated by 
> Mozilla.

Sure, but DoH is less censorship-resistant not more.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Your snowflakes have nothing on my socks drawer.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Marc Haber]

On Mon, 9 Sep 2019 00:38:03 +0200, Adam Borowski 
wrote:
>With local DNS:
>* the target server knows about you (duh!)
>* the ISP can read the destination of every connection
>  [reading the DNS packets, reading the IP header, reading SNI header]
>* the ISP can block such connections
>  [blocking DNS packets, blocking actual connection]
>* DNSSEC forbids falsifying DNS
>
>With DoH:
>* the target server knows about you (duh!)
>* the ISP can read the destination of every connection
>  [reading the IP header, reading SNI header]
>* the ISP can block such connections
>  [blocking actual connection]
>* Cloudflare can read the destination of every connection
>  [they serve the DNS...]
>* Cloudflare can falsify DNS¹
>* Cloudflare can block connections
>  [blocking or falsifying DNS response]
>
>So currently DoH is strictly worse.

Will DOH break corporate web apps that are accessed over a VPN (and
thus only resolvable via the local resolver)? Or has Mozilla catered
for that?

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Ulrike Uhlig]

Hi!

Thank you for raising this topic!

On 09.09.19 07:56, Ondřej Surý wrote:

> We can discuss (and it has been discussed) ad nauseam, but the point is that 
> nobody (certainly I am not) is asking for crippling DoH, but I just strongly 
> believe it’s in the line with other Debian work that we should not send data 
> to 3rd party DNS service without explicit user consent.

I have a question besides the DOH discussion: How is this technically
done to target "only" US users?

Note: I have not looked up any documentation provided by Mozilla, I was
just wondering.

Cheers!
Ulrike

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Andy Simpkins]

On 11/09/2019 06:16, Ingo Jürgensmann wrote:

Am 10.09.2019 um 07:50 schrieb Florian Lohoff :


On Mon, Sep 09, 2019 at 03:31:37PM +0200, Bjørn Mork wrote:

I for one, do trust my ISPs a lot more than I trust Cloudflare or
Google, simply based on the jurisdiction.

There are tons of setups which are fine tuned for latency because they
are behind sat links etc or low bandwidth landlines. They have dns
caches with prefetching to reduce typical resolve latency down to sub
milliseconds although your RTT to google/cloudflare is >1000ms.

Switching from your systems resolver fed by DHCP to DoH in Firefox will
make the resolve latency go from sub ms to multiple seconds as the
HTTP/TLS handshake will take multiple RTT. This will effectively break
ANY setup behind Sat links e.g. for example all cruise ships at
sea.


I can confirm (based on experiences on my day job) that this can be a real 
problem and affecting thousands and hundredthousands of users.

Having the *option* to use DoH is maybe a good idea, but making it the default 
is not.




I appreciate that Mozilla are trying to enhance privacy by introducing 
DoH as an option (but clearly not for children! [0][1]), but are we not 
missing the major point here?  DNS does not belong in the browser


If we wish to deploy DoH (I think it would get my vote) then it should 
be system wide and transparent to applications, using the same methods 
already available.  If every application were to deploy its own resolver 
service then total chaos will ensue.


Yes I know browsers offer alternative resolve / and proxy methods 
already, unfortunately that ship has already sailed. Providing that they 
are turned OFF by default then that is acceptable.  With in-browser DoH 
again, as long as it is OFF by default I don't see an issue.


/Andy

[0] "Respect user choice for opt-in parental controls and disable DoH if 
we detect them" 
https://blog.mozilla.org/futurereleases/2019/09/06/whats-next-in-making-dns-over-https-the-default/


[1] In browser DoH will break a lot of 'parental control / supervisor' 
applications that block traffic based on black & white lists.  IMO this 
is another reason why DoH shouldn't be inside the browser - already 
Mozilla are deploying work arounds for certain use cases...

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Ingo Jürgensmann]

Am 10.09.2019 um 07:50 schrieb Florian Lohoff :

> On Mon, Sep 09, 2019 at 03:31:37PM +0200, Bjørn Mork wrote:
>> I for one, do trust my ISPs a lot more than I trust Cloudflare or
>> Google, simply based on the jurisdiction.
> There are tons of setups which are fine tuned for latency because they
> are behind sat links etc or low bandwidth landlines. They have dns
> caches with prefetching to reduce typical resolve latency down to sub
> milliseconds although your RTT to google/cloudflare is >1000ms.
> 
> Switching from your systems resolver fed by DHCP to DoH in Firefox will
> make the resolve latency go from sub ms to multiple seconds as the
> HTTP/TLS handshake will take multiple RTT. This will effectively break
> ANY setup behind Sat links e.g. for example all cruise ships at
> sea.

I can confirm (based on experiences on my day job) that this can be a real 
problem and affecting thousands and hundredthousands of users.

Having the *option* to use DoH is maybe a good idea, but making it the default 
is not. 

-- 
Ciao...  //http://blog.windfluechter.net
  Ingo \X/ XMPP: i...@jabber.windfluechter.net

gpg pubkey:  http://www.juergensmann.de/ij_public_key.asc

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Anthony DeRobertis]

On September 8, 2019 10:38:03 PM UTC, Adam Borowski  wrote:

>DoH doesn't stop ISP-based spying nor censorship. 

Firefox, I believe, already supports encrypted SNI (in nightly at least). 
Cloudflare does too. 

So fully deployed, your ISP can only tell that you're connecting to Cloudflare, 
Cloudfront, Akamai, Fastly, etc. At least when you're browsing sites using 
those CDNs. 

Trusting those parties is a huge can of worms, of course, but Mozilla has at 
least contractually limited what Cloudflare can collect and keep[1]. And the 
alternative for a lot of us is Verizon or Comcast. 

That said, ideally it'd be something that each user would be prompted about on 
first run, being given a clear description and asked if he/she wants it or not. 
But since upstream hasn't AFAIK coded that, it's not going to happen. 


[1] 
https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/firefox/

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Jeremy Stanley]

On 2019-09-10 19:56:48 +0200 (+0200), Julien Cristau wrote:
[...]
> How is this worse than what we're already doing by default, namely
> sending the same data to whoever happens to be on the network, in
> addition to whoever happened to be listed in an unauthenticated
> dhcp response? (Which, if you're lucky, is your ISP, aka a 3rd
> party.)

It still significantly distributes the work of recording your DNS
queries/Web browsing activity. Cloudflare and their competitors are
already well-placed to see a significant proportion of general Web
traffic due to their CDN businesses, which makes them a much more
attractive target for mass surveillance (either mandated by some
governments, for sale to the highest bidders, or simply as the
victims of a stealthy criminal incursion). That status increases if
they're also the de facto DNS resolver for a majority of Firefox
users. I think it comes down to whether you consider the biggest
privacy risk to come from focused/local attacks (in which case the
new default is a benefit) or from global dragnet trawling by "big
brother" (in which case nearly everyone in the World trusting the
same small number of companies is a problem).
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Julien Cristau]

On Tue, Sep 10, 2019 at 08:24:03 +0200, Ondřej Surý wrote:

> > On 9 Sep 2019, at 15:31, Bjørn Mork  wrote:
> > 
> > I for one, do trust my ISPs a lot more than I trust Cloudflare or
> > Google, simply based on the jurisdiction.
> 
> While I still strongly agree with you on this one (even though I think all
> major ISPs here are scumbags, especially the incumbent), I still strongly
> think we should not have this debate here, and we should turn this around
> the usual Debian policy - to not send data to 3rd party without explicit user
> content and defaulting to not doing so.
> 
How is this worse than what we're already doing by default, namely
sending the same data to whoever happens to be on the network, in
addition to whoever happened to be listed in an unauthenticated dhcp
response?  (Which, if you're lucky, is your ISP, aka a 3rd party.)

Cheers,
Julien

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Marco d'Itri]

On Sep 09, Adam Borowski  wrote:

> With DoH:
> * the target server knows about you (duh!)
> * the ISP can read the destination of every connection
>   [reading the IP header, reading SNI header]
> * the ISP can block such connections
>   [blocking actual connection]
Well, no. They cannot without significantly more expensive hardware to 
do DPI and a *totally different* legislative framework.
(Source: I have been dealing with government-mandated censorship in 
Italy for ~15 years, both at technical and policy levels.)

> * Cloudflare can falsify DNS¹
You can use DNSSEC over DoH.

You obviously consider Mozilla's choices of trusted resolvers (currently 
Cloudflare, hopefully others too in the future) a bigger privacy risk 
for generic users (the one who use the browser defaults) than their ISP, 
I disagree.

I still believe that generic users are better served by deploying more 
censorship-resistant protocols than by worrying that Cloudflare (or 
whoever else) would violate the privacy requirements mandated by 
Mozilla.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Ondřej Surý]

> On 10 Sep 2019, at 09:38, Yao Wei  wrote:
> 
> On Tue, Sep 10, 2019 at 08:24:03AM +0200, Ondřej Surý wrote:
>> While I still strongly agree with you on this one (even though I think all
>> major ISPs here are scumbags, especially the incumbent), I still strongly
>> think we should not have this debate here, and we should turn this around
>> the usual Debian policy - to not send data to 3rd party without explicit user
>> content and defaulting to not doing so.
> 
> Should we propagate our concerns to Mozilla?

These concerns has been voiced to them multiple times by multiple people
and they won’t budge as they already made their minds.

Ondrej
--
Ondřej Surý
ond...@sury.org

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Yao Wei]

On Tue, Sep 10, 2019 at 08:24:03AM +0200, Ondřej Surý wrote:
> While I still strongly agree with you on this one (even though I think all
> major ISPs here are scumbags, especially the incumbent), I still strongly
> think we should not have this debate here, and we should turn this around
> the usual Debian policy - to not send data to 3rd party without explicit user
> content and defaulting to not doing so.

Should we propagate our concerns to Mozilla?

Yao Wei


signature.asc
Description: PGP signature

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Ondřej Surý]

> On 9 Sep 2019, at 15:31, Bjørn Mork  wrote:
> 
> I for one, do trust my ISPs a lot more than I trust Cloudflare or
> Google, simply based on the jurisdiction.

While I still strongly agree with you on this one (even though I think all
major ISPs here are scumbags, especially the incumbent), I still strongly
think we should not have this debate here, and we should turn this around
the usual Debian policy - to not send data to 3rd party without explicit user
content and defaulting to not doing so.

Ondrej
--
Ondřej Surý
ond...@sury.org

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Florian Lohoff]

On Mon, Sep 09, 2019 at 03:31:37PM +0200, Bjørn Mork wrote:
> I for one, do trust my ISPs a lot more than I trust Cloudflare or
> Google, simply based on the jurisdiction.

There are tons of setups which are fine tuned for latency because they
are behind sat links etc or low bandwidth landlines. They have dns
caches with prefetching to reduce typical resolve latency down to sub
milliseconds although your RTT to google/cloudflare is >1000ms.

Switching from your systems resolver fed by DHCP to DoH in Firefox will
make the resolve latency go from sub ms to multiple seconds as the
HTTP/TLS handshake will take multiple RTT. This will effectively break
ANY setup behind Sat links e.g. for example all cruise ships at
sea.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


signature.asc
Description: PGP signature

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Bjørn Mork]

Ondřej Surý  writes:

> On the privacy topic...
>
> Slides: https://irtf.org/anrw/2019/slides-anrw19-final44.pdf
> Paper: https://dl.acm.org/authorize.cfm?key=N687437

And also section 8 of
https://tools.ietf.org/html/draft-reid-doh-operator-00


> And you can get to the video recording from the ANRW 2019 pages: 
> https://irtf.org/anrw/2019/program.html
>
> We can discuss (and it has been discussed) ad nauseam, but the point
> is that nobody (certainly I am not) is asking for crippling DoH, but I
> just strongly believe it’s in the line with other Debian work that we
> should not send data to 3rd party DNS service without explicit user
> consent.

I agree, FWIW. User consent is required.

I for one, do trust my ISPs a lot more than I trust Cloudflare or
Google, simply based on the jurisdiction.

> Otherwise it doesn’t make any sense to remove external links to logos
>and JavaScript from the documentation and then send everything to one
>single US-based provider.

Exactly. I'd be worried if anything in Debian came preconfigured with
DNS servers of any kind.


Bjørn

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Robert Edmonds]

The entire DNS root zone is only 1 MB compressed and is updated about
once a day. It would be even better for privacy if the whole root zone
were distributed via HTTPS, as the initiator would not reveal to the
server any information about what TLD is being looked up.

There are currently ~1500 TLDs in the root zone. Dividing 1 MB by the
number of TLDs, this is ~700 bytes per TLD, which is roughly the amount
of bandwidth required by a query/response pair of UDP DNS packets to
obtain the delegation for a TLD.

The size of the DNS root zone could also be reduced if it were signed by
an ECC algorithm rather than RSA.

If the ZONEMD resource record (draft-ietf-dnsop-dns-zone-digest) were
standardized and deployed in the root zone, it would allow for
cryptographic verification of the entire contents of the root zone
regardless of the source. So it would not even be necessary to obtain
the root zone from the "official" root name server infrastructure.

That moves the problem down a level to the TLDs, where it is
impracticable to distribute copies of all TLD zone files. So a better
question to ask would be whether any of the DNS TLD servers plan to
implement any of the DNS transport privacy options. That moves the
problem down another level, etc.

The benefit of encrypting the resolver to authoritative side of the DNS
protocol is that it makes it possible to deploy "non stub" caching DNS
resolvers to individual hosts without exposing the plaintext lookup
traffic to either network observers or a centralized resolver operator
such as an ISP or cloud provider.

Ondřej Surý wrote:
> DNSCurve - probably never
> 
> DoT - the current profiles are stub to resolver, when they are profiles for 
> resolver to authoritative and a solid support in the software, the RSSAC will 
> surely talk about this. The deployment will have impact (switching all 
> traffics to TCP? Yay?)
> 
> DoH - I am not sure what would be the benefit for resolver to authoritative, 
> but same as with DoT.
> 
> DNSoQUIC - not yet there, but it might be better option for resolver to 
> authoritative...
> 
> Ondřej
> --
> Ondřej Surý 
> 
> > On 9 Sep 2019, at 03:17, Paul Wise  wrote:
> > 
> > On Mon, Sep 9, 2019 at 2:31 AM Ondřej Surý wrote:
> > 
> >> Mozilla plans to enable DoH to CloudFlare by default to US based users
> > 
> > Does anyone know if there is any plan for the DNS root servers to
> > enable any of the DNS privacy options? AFAIK the available options are
> > DNSCurve, DoT or DoH.
> > 
> > -- 
> > bye,
> > pabs
> > 
> > https://wiki.debian.org/PaulWise
> > 
> 

-- 
Robert Edmonds
edmo...@debian.org

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Ondřej Surý]

On the privacy topic...

Slides: https://irtf.org/anrw/2019/slides-anrw19-final44.pdf
Paper: https://dl.acm.org/authorize.cfm?key=N687437

And you can get to the video recording from the ANRW 2019 pages: 
https://irtf.org/anrw/2019/program.html

We can discuss (and it has been discussed) ad nauseam, but the point is that 
nobody (certainly I am not) is asking for crippling DoH, but I just strongly 
believe it’s in the line with other Debian work that we should not send data to 
3rd party DNS service without explicit user consent.

Otherwise it doesn’t make any sense to remove external links to logos and 
JavaScript from the documentation and then send everything to one single 
US-based provider.

Ondrej
--
Ondřej Surý 

> On 8 Sep 2019, at 23:29, Marco d'Itri  wrote:
> 
> On Sep 08, Ondřej Surý  wrote:
> 
>> I would rather see an explicit statement. I would be very surprised 
>> with Debian’s usual stance regarding the users’ privacy that we would 
>> not consider this as a privacy violation, but again I am not Firefox 
>> maintainer in Debian and I would rather hear from them than speculate 
>> on my own.
> I think that this is a privacy enhancement, since it prevents some major 
> ISPs from spying on users DNS queries. When it will be enabled in other 
> countries it will prevent government-mandated (or "encouraged")
> censorship.
> It would be a terrible signal if Debian decided to disable an 
> anti-censoship feature provided by an upstream vendor.
> 
> -- 
> ciao,
> Marco

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Ondřej Surý]

DNSCurve - probably never

DoT - the current profiles are stub to resolver, when they are profiles for 
resolver to authoritative and a solid support in the software, the RSSAC will 
surely talk about this. The deployment will have impact (switching all traffics 
to TCP? Yay?)

DoH - I am not sure what would be the benefit for resolver to authoritative, 
but same as with DoT.

DNSoQUIC - not yet there, but it might be better option for resolver to 
authoritative...

Ondřej
--
Ondřej Surý 

> On 9 Sep 2019, at 03:17, Paul Wise  wrote:
> 
> On Mon, Sep 9, 2019 at 2:31 AM Ondřej Surý wrote:
> 
>> Mozilla plans to enable DoH to CloudFlare by default to US based users
> 
> Does anyone know if there is any plan for the DNS root servers to
> enable any of the DNS privacy options? AFAIK the available options are
> DNSCurve, DoT or DoH.
> 
> -- 
> bye,
> pabs
> 
> https://wiki.debian.org/PaulWise
> 

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Paul Wise]

On Mon, Sep 9, 2019 at 2:31 AM Ondřej Surý wrote:

> Mozilla plans to enable DoH to CloudFlare by default to US based users

Does anyone know if there is any plan for the DNS root servers to
enable any of the DNS privacy options? AFAIK the available options are
DNSCurve, DoT or DoH.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Adam Borowski]

On Sun, Sep 08, 2019 at 11:17:13PM +0200, Marco d'Itri wrote:
> On Sep 08, Ondřej Surý  wrote:
> 
> > I would rather see an explicit statement. I would be very surprised 
> > with Debian’s usual stance regarding the users’ privacy that we would 
> > not consider this as a privacy violation, but again I am not Firefox 
> > maintainer in Debian and I would rather hear from them than speculate 
> > on my own.
> I think that this is a privacy enhancement, since it prevents some major 
> ISPs from spying on users DNS queries. When it will be enabled in other 
> countries it will prevent government-mandated (or "encouraged")
> censorship.

DoH doesn't stop ISP-based spying nor censorship.  On the other hand, it
allows a new third party (Cloudflare in Mozilla's default) to do both such
spying and censorship -- something it couldn't do before.

Let's compare; by "ISP" I mean every hop on the network path.

With local DNS:
* the target server knows about you (duh!)
* the ISP can read the destination of every connection
  [reading the DNS packets, reading the IP header, reading SNI header]
* the ISP can block such connections
  [blocking DNS packets, blocking actual connection]
* DNSSEC forbids falsifying DNS

With DoH:
* the target server knows about you (duh!)
* the ISP can read the destination of every connection
  [reading the IP header, reading SNI header]
* the ISP can block such connections
  [blocking actual connection]
* Cloudflare can read the destination of every connection
  [they serve the DNS...]
* Cloudflare can falsify DNS¹
* Cloudflare can block connections
  [blocking or falsifying DNS response]

So currently DoH is strictly worse.

In the future, once ESNI is implemented and deployed, the ISP will lose the
possibility of distinguishing sites served from the same IP, but that helps
with some random blogs while most sensitive sites can't trust a shared
hoster.  Thus, ESNI hardly helps.

> It would be a terrible signal if Debian decided to disable an 
> anti-censoship feature provided by an upstream vendor.

If that feature worked, that'd would indeed be terrible.  But in the current
proposal, it's a privacy violation with no clear upside.  I'd thus recommend
to _not_ enable DoH in our packages.


Meow!

[1]. It would be possible to, instead of sending just the answer, to pass
the entire chain of DNSSEC signatures over the DoH link.  This has been
suggested in RFC8484, but doesn't seem to be implemented by Firefox.
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Snowflakes?  Socks drawer!
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Jeremy Stanley]

On 2019-09-08 23:17:13 +0200 (+0200), Marco d'Itri wrote:
[...]
> I think that this is a privacy enhancement, since it prevents some
> major ISPs from spying on users DNS queries.
[...]

While at the same time legitimizing Cloudflare spying on users' DNS
queries, right? How is one necessarily better than the other? My ISP
can spy on far fewer users than Cloudflare can, so on balance this
seems like a net loss for privacy.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Marco d'Itri]

On Sep 08, Ondřej Surý  wrote:

> I would rather see an explicit statement. I would be very surprised 
> with Debian’s usual stance regarding the users’ privacy that we would 
> not consider this as a privacy violation, but again I am not Firefox 
> maintainer in Debian and I would rather hear from them than speculate 
> on my own.
I think that this is a privacy enhancement, since it prevents some major 
ISPs from spying on users DNS queries. When it will be enabled in other 
countries it will prevent government-mandated (or "encouraged")
censorship.
It would be a terrible signal if Debian decided to disable an 
anti-censoship feature provided by an upstream vendor.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Mozilla renames: is Debian the only one?

[Chris Lamb]

Pierre THIERRY wrote:

 If not, which ones?

+ http://www.gnewsense.org/  ?

-- 
 Chris Lamb, Cambridgeshire, UK  GPG: 0x634F9A20


signature.asc
Description: PGP signature

Re: Mozilla renames: is Debian the only one?

[Lawrence Williams]

On April 12, 2007 11:34:00 am Chris Lamb wrote:
 Pierre THIERRY wrote:
  If not, which ones?

 + http://www.gnewsense.org/  ?

Gentoo has done renames of Mozilla products such as Firefox too.

- Lawrence


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Mozilla renames: is Debian the only one?

[Sune Vuorela]

On 2007-04-12, Lawrence Williams [EMAIL PROTECTED] wrote:
 On April 12, 2007 11:34:00 am Chris Lamb wrote:
 Pierre THIERRY wrote:
  If not, which ones?

 + http://www.gnewsense.org/  ?

 Gentoo has done renames of Mozilla products such as Firefox too.

I asked one of my local gentoo devs - and he says no - it is not
rebranded/renamed

/Sune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Mozilla renames: is Debian the only one?

[Lawrence Williams]

On April 12, 2007 01:10:53 pm Sune Vuorela wrote:
 On 2007-04-12, Lawrence Williams [EMAIL PROTECTED] wrote:
  On April 12, 2007 11:34:00 am Chris Lamb wrote:
  Pierre THIERRY wrote:
   If not, which ones?
 
  + http://www.gnewsense.org/  ?
 
  Gentoo has done renames of Mozilla products such as Firefox too.

 I asked one of my local gentoo devs - and he says no - it is not
 rebranded/renamed

 /Sune


My mistake. I was thinking of Bon Echo, the FF2 beta name :)

- Lawrence


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Mozilla renames: is Debian the only one?

[Margarita Manterola]

On 4/12/07, Sune Vuorela [EMAIL PROTECTED] wrote:

On 2007-04-12, Lawrence Williams [EMAIL PROTECTED] wrote:
 Gentoo has done renames of Mozilla products such as Firefox too.
I asked one of my local gentoo devs - and he says no - it is not
rebranded/renamed


It's a USE flag called mozbranding.  It lets the user choose wether
they want to rebrand it (to Bon Echo) or not.

--
Besos,
Marga


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Mozilla renames: is Debian the only one?

[Noah Meyerhans]

On Thu, Apr 12, 2007 at 02:27:51PM -0300, Margarita Manterola wrote:
  Gentoo has done renames of Mozilla products such as Firefox too.
 I asked one of my local gentoo devs - and he says no - it is not
 rebranded/renamed
 
 It's a USE flag called mozbranding.  It lets the user choose wether
 they want to rebrand it (to Bon Echo) or not.

NetBSD does something similar in their pkgsrc collection.  The default
uses Bon Echo, but it can be overridden to use the Mozilla branded
names.

noah



signature.asc
Description: Digital signature

Re: Mozilla plugins to depend upon virtual mozilla-plugin-browser?

[Roberto C . Sánchez]

On Fri, Mar 23, 2007 at 11:34:17PM +0100, Harald Dunkel wrote:
 Hi folks,
 
 Would it be possible that the Mozilla plugins depend upon
 a virtual mozilla-plugin-browser package? All browsers with
 the same plugin interface could provide this feature, and
 foreign browsers would not be kept out.
 
What is the point?

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: Mozilla- prefix. Was: Bug#402650: ITP: mozilla-foxyproxy -- advanced proxy management tool for iceweasel

[Alexander Sack]

On Tue, Dec 12, 2006 at 02:54:34PM -0500, Yaroslav Halchenko wrote:
 
 So possible ways I see
 1. leave it as is and have mozilla- prefix
 2. figure out substitution to the mozilla trademark 
 3. remove prefix once and forever and use appropriate tags. After all,
 many applications use some common codebase, but they are not required to
 have a common prefix.
 
 (1) seems to be the worst in the lengthy run, but the only one which fits
 the frozen state of etch now

I don't think that this itp will end up in etch as we are already in a
freeze, so all this is about the post-etch era ... for etch mozilla-*
would be fine.

 - Alexander
-- 
 GPG messages preferred.|  .''`.  ** Debian GNU/Linux **
 Alexander Sack | : :' :  The  universal
 [EMAIL PROTECTED]| `. `'  Operating System
 http://www.asoftsite.org/  |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Mozilla Mothballed now, is a Seamonkey package a possibility?

[Alexander Sack]

On Sun, Jul 23, 2006 at 11:56:50PM +1000, Rod Lovett wrote:
 As mentioned below by Joey from Debian weekly news, I personally would 
 much appreciate Debian Developers/ package maintainers to consider 
 discussing replacing Mozilla , now superseded and mothballed by Mozilla 
 and replaced by the Seamonkey Council, and now Seamonkey 1.02 stable 
 release.

I wondered about this too and contacted the ITP owner about it. He
works together with a debian developer to get this package started.

An initial version can be checked out from debian svn [1].


[1] - svn://svn.debian.org/svn/collab-maint/deb-maint/seamonkey

 - Alexander
-- 
 GPG messages preferred.|  .''`.  ** Debian GNU/Linux **
 Alexander Sack | : :' :  The  universal
 [EMAIL PROTECTED]| `. `'  Operating System
 http://www.asoftsite.org/  |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Mozilla Mothballed now, is a Seamonkey package a possibility?

[Jaldhar H. Vyas]

On Mon, 24 Jul 2006, Rod Lovett wrote:

As mentioned below by Joey from Debian weekly news, I personally would much 
appreciate Debian Developers/ package maintainers to consider discussing 
replacing the Mozilla browser , now superseded and mothballed by the Mozilla 
foundation and replaced by the Seamonkey Council, and now I think Seamonkey 
1.02 is the stable release.
This email was written in a Seamonkey 1.0 cmg, installed on a  Kanotix box, 
but a Deb package would be better perhaps, in the Debian repositories.

I greatly hope this will be considered soon in at Debian.
Thanks too Joey
All the Best in there
Rod


I am preparing a seamonkey package as my employers, Linspire, want to see 
it in their Debian-derived distro (as well as Debian proper.)  You can see 
the current state of things at:

http://svn.debian.org/wsvn/collab-maint/deb-maint/seamonkey/

The package works but I have mot uploaded it yet as lintian still shows a 
number of policy violations.


I welcome help from anyone who would like to work on getting these 
problems fixed.  Going forward, team-maintainence would be a good idea.



--
Jaldhar H. Vyas [EMAIL PROTECTED]
La Salle Debain - http://www.braincells.com/debian/


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Mozilla Foundation Trademarks

[Anthony DeRobertis]

Gervase Markham wrote:

 Then I'm slightly confused as to your concept of trademark infringement.
 If I label the car I've built as a Ford (even if it uses a lot of Ford
 parts), it infringes Ford's trademark.

OTOH, as has been pointed out before in one of the many related threads,
if I take a Ford, built by Ford Motor Company, replace the fuel pump, I
can still sell it as a Ford.

I'm not a trademark lawyer, haven't read much on trademark, etc. so I
don't feel competant at all trying to figure where that line is drawn in
software. However, I'd be surprised if putting

Mozilla Firefox
Modified by Debian
(see /usr/share/doc/mozilla-firefox/changelog.Debian.gz)

in the About box and similar things in the package description wouldn't
be allowed.

OTOH, I don't see any issue whatsoever with Debian taking the Mozilla
Foundation's trademark license offer, so long as it only gives Debian
additional rights.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Mozilla Foundation Trademarks

[Eric Dorland]

* Michael K. Edwards ([EMAIL PROTECTED]) wrote:
 On 6/19/05, Eric Dorland [EMAIL PROTECTED] wrote:
  * Michael K. Edwards ([EMAIL PROTECTED]) wrote:
   I wouldn't say accept it, I would say acknowledge the safety zone
   offered unilaterally by the Mozilla Foundation, and as a courtesy to
   them make some effort to stay comfortably within it while continuing
   to ship under the Mozilla names.  Their trademark policy is surely
   less draconian than, say, Red Hat's, and we aren't going around
   purging the RedHat Package Manager from Debian.
  
  I think you're playing word games now. Even if this is a unilateral
  gift we still need to decide if we want it or not.
 
 Of course; and as the maintainer, you are going to be the one making
 that call.  I'm just chary of using words like offer and accept
 because they suggest that we are in the contract zone.  I think (I
 could be wrong; IANAL) that, in the free software arena, it's actually
 better for both sides for the trademark holder to say:
 
 We aren't exactly licensing all and sundry to manufacture products
 under our brand.  Our product line includes both the source code and
 the 'official' binaries; we are of the opinion that third parties who
 follow these guidelines when building and distributing their own
 binaries are merely re-packaging our source code product (under
 standards like Coty v. Prestonettes in the US and X, Y, and Z
 elsewhere) and using our trademarks descriptively.
 
 We reserve the right to decide unilaterally that someone either has
 created a product of their own (to which our trademark can't be
 applied without license) or isn't doing an adequate job of QA in the
 course of re-packaging.  But if and when that happens, we're going to
 follow the steps outlined here to try to bring them into voluntary
 compliance before we demand that they either accept a formal license
 and traditional oversight procedures or cease to apply our trademarks
 to their modified version of our product.
 
 From what I've read, that's as open a policy as a trademark holder can
 offer and still retain control of the trademark in the long run.  I
 may be overstating here how far the Mozilla Foundation is willing to
 go; but if a modus vivendi can be reached in which the only thing
 special about Debian is that the guidelines more or less reflect the
 maintainer's actual practice, I think that sits more comfortably with
 DFSG #8 than a license per se.

If the mozilla foundation come up with something like that I would be
satisfied, as long as the guidelines as reasonable and allow me to do
things I need to do as a maintainer. 
 
   If the offer from six months ago still stands (which, to my
   recollection and in my non-lawyer view, read like a unilateral safety
   zone rather than a trademark license as such), that's extraordinarily
   accommodating on MoFo's part.  It's a square deal from people with a
   pretty good reputation for square deals.  They deserve better from
   Debian than to have their flagship products obscured by a rename when
   they haven't done anything nasty to anyone yet.
  
  What reputation are you referring to? Not that I necessarily disagree,
  but what are you basing that assessment on?
 
 Their rebranding isn't special for Netscape/AOL and other corporate
 partners; they've worked very hard to make it accessible to third
 parties without any need for explicit cooperation with them.  They're
 going through the agony of relicensing their entire code base under
 MPL/LGPL/GPL so that GPL projects can cherry-pick at source code
 level.  They're good citizens in W3C standards space even when the
 committee decisions go against them (e. g., XUL vs. XForms).  I don't
 know the details of their CA certificate handling, but at least they
 _have_ a policy and respond constructively to criticism of it.  And
 Mitch Kapor and the rest of the MoFo board have a lot of street cred
 as individuals.

Point taken. But I'm not sure what you mean by their Netscape
rebranding isn't special. Netscape doesn't claim their browser is
Firefox, so there isn't a problem from that perspective. 

   The FSF has, at best, completely failed to offer leadership with
   respect to free software and trademarks, as the MySQL case and the Red
   Hat / UnixCD mess have shown.  I think it would be rather gratifying
   if Debian could step in to fill the void.  And it would be kind of
   nice to have a workable modus vivendi to exhibit if and when the Linux
   Mark Institute (or the OpenSSL team or the PHP folks or Red Hat or
   MySQL) comes knocking.
  
  I do have to agree that guidance when it comes to trademark situations
  is sorely lacking. There doesn't seem to be that consistent a
  viewpoint with Debian either unfortunately.
 
 It's a sticky wicket.  Free software enthusiasts (among whom I count
 myself) don't like systems that exacerbate second-class-citizenship
 among those whose motivations aren't principally commercial.  Nowadays
 everyone's a 

Re: Mozilla Foundation Trademarks

[Eric Dorland]

* John Hasler ([EMAIL PROTECTED]) wrote:
 I wrote:
  If what we are doing does not actually infringe their trademark we would
  not be getting any special privileges.
 
 Eric Dorland writes:
  What we are doing already is against their trademark policy. We're being
  offered an agreement specific to Debian to bypass that. I would call that
  special privileges.
 
 If their policy is not legally enforceable our users have all the rights we
 have whether we accept the agreement of not.

If their policy is not legally enforceable then we've wasted a lot of
time discussing it. Do you have any backup to this claim? 

-- 
Eric Dorland [EMAIL PROTECTED]
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6

-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ 
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ 
G e h! r- y+ 
--END GEEK CODE BLOCK--


signature.asc
Description: Digital signature

Re: Mozilla Foundation Trademarks

[Eric Dorland]

* Eric Dorland ([EMAIL PROTECTED]) wrote:
 
 I'd certainly 
 

be interested in trying to develop some sort of policy for Debian
regarding trademarks. I'm not sure how much weight it could carry, but
at least if people like the ideas.


-- 
Eric Dorland [EMAIL PROTECTED]
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6

-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ 
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ 
G e h! r- y+ 
--END GEEK CODE BLOCK--


signature.asc
Description: Digital signature

Re: Mozilla Foundation Trademarks

[John Hasler]

Eric Dorland writes:
 We may be their friends, but that shouldn't give us special privileges.

If what we are doing does not actually infringe their trademark we would
not be getting any special privileges.
-- 
John Hasler


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Mozilla Foundation Trademarks

[Eric Dorland]

* John Hasler ([EMAIL PROTECTED]) wrote:
 Eric Dorland writes:
  We may be their friends, but that shouldn't give us special privileges.
 
 If what we are doing does not actually infringe their trademark we would
 not be getting any special privileges.

What we are doing already is against their trademark policy. We're
being offered an agreement specific to Debian to bypass that. I would
call that special privileges.  

-- 
Eric Dorland [EMAIL PROTECTED]
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6

-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ 
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ 
G e h! r- y+ 
--END GEEK CODE BLOCK--


signature.asc
Description: Digital signature

Re: Mozilla Foundation Trademarks

[John Hasler]

I wrote:
 If what we are doing does not actually infringe their trademark we would
 not be getting any special privileges.

Eric Dorland writes:
 What we are doing already is against their trademark policy. We're being
 offered an agreement specific to Debian to bypass that. I would call that
 special privileges.

If their policy is not legally enforceable our users have all the rights we
have whether we accept the agreement of not.
-- 
John Hasler (IANAL)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Mozilla Foundation Trademarks

[Eric Dorland]

* Michael K. Edwards ([EMAIL PROTECTED]) wrote:
 On 6/17/05, Eric Dorland [EMAIL PROTECTED] wrote:
  * John Hasler ([EMAIL PROTECTED]) wrote:
   Exactly.  If Debian doesn't need such an arrangement, neither do our 
   users.
   And if our users don't need such an arrangement, our accepting it does not
   put us in a privileged position with respect to them: they have the legal
   right to do everything that we want to do with or without permission.
  
   So let's accept the arrangement and move on.  There is no DFSG problem
   here even if we do accept the notion that the DFSG applies to trademarks.
  
  If we don't need the arragement, why exactly would we accept it
  anyway?
 
 I wouldn't say accept it, I would say acknowledge the safety zone
 offered unilaterally by the Mozilla Foundation, and as a courtesy to
 them make some effort to stay comfortably within it while continuing
 to ship under the Mozilla names.  Their trademark policy is surely
 less draconian than, say, Red Hat's, and we aren't going around
 purging the RedHat Package Manager from Debian.

I think you're playing word games now. Even if this is a unilateral
gift we still need to decide if we want it or not. 

 If the offer from six months ago still stands (which, to my
 recollection and in my non-lawyer view, read like a unilateral safety
 zone rather than a trademark license as such), that's extraordinarily
 accommodating on MoFo's part.  It's a square deal from people with a
 pretty good reputation for square deals.  They deserve better from
 Debian than to have their flagship products obscured by a rename when
 they haven't done anything nasty to anyone yet.

What reputation are you referring to? Not that I necessarily disagree,
but what are you basing that assessment on? 
 
 The FSF has, at best, completely failed to offer leadership with
 respect to free software and trademarks, as the MySQL case and the Red
 Hat / UnixCD mess have shown.  I think it would be rather gratifying
 if Debian could step in to fill the void.  And it would be kind of
 nice to have a workable modus vivendi to exhibit if and when the Linux
 Mark Institute (or the OpenSSL team or the PHP folks or Red Hat or
 MySQL) comes knocking.

I do have to agree that guidance when it comes to trademark situations
is sorely lacking. There doesn't seem to be that consistent a
viewpoint with Debian either unfortunately. 

-- 
Eric Dorland [EMAIL PROTECTED]
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6

-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ 
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ 
G e h! r- y+ 
--END GEEK CODE BLOCK--


signature.asc
Description: Digital signature

Re: Mozilla Foundation Trademarks

[Michael K. Edwards]

On 6/19/05, Eric Dorland [EMAIL PROTECTED] wrote:
 * Michael K. Edwards ([EMAIL PROTECTED]) wrote:
  I wouldn't say accept it, I would say acknowledge the safety zone
  offered unilaterally by the Mozilla Foundation, and as a courtesy to
  them make some effort to stay comfortably within it while continuing
  to ship under the Mozilla names.  Their trademark policy is surely
  less draconian than, say, Red Hat's, and we aren't going around
  purging the RedHat Package Manager from Debian.
 
 I think you're playing word games now. Even if this is a unilateral
 gift we still need to decide if we want it or not.

Of course; and as the maintainer, you are going to be the one making
that call.  I'm just chary of using words like offer and accept
because they suggest that we are in the contract zone.  I think (I
could be wrong; IANAL) that, in the free software arena, it's actually
better for both sides for the trademark holder to say:

We aren't exactly licensing all and sundry to manufacture products
under our brand.  Our product line includes both the source code and
the 'official' binaries; we are of the opinion that third parties who
follow these guidelines when building and distributing their own
binaries are merely re-packaging our source code product (under
standards like Coty v. Prestonettes in the US and X, Y, and Z
elsewhere) and using our trademarks descriptively.

We reserve the right to decide unilaterally that someone either has
created a product of their own (to which our trademark can't be
applied without license) or isn't doing an adequate job of QA in the
course of re-packaging.  But if and when that happens, we're going to
follow the steps outlined here to try to bring them into voluntary
compliance before we demand that they either accept a formal license
and traditional oversight procedures or cease to apply our trademarks
to their modified version of our product.

From what I've read, that's as open a policy as a trademark holder can
offer and still retain control of the trademark in the long run.  I
may be overstating here how far the Mozilla Foundation is willing to
go; but if a modus vivendi can be reached in which the only thing
special about Debian is that the guidelines more or less reflect the
maintainer's actual practice, I think that sits more comfortably with
DFSG #8 than a license per se.

  If the offer from six months ago still stands (which, to my
  recollection and in my non-lawyer view, read like a unilateral safety
  zone rather than a trademark license as such), that's extraordinarily
  accommodating on MoFo's part.  It's a square deal from people with a
  pretty good reputation for square deals.  They deserve better from
  Debian than to have their flagship products obscured by a rename when
  they haven't done anything nasty to anyone yet.
 
 What reputation are you referring to? Not that I necessarily disagree,
 but what are you basing that assessment on?

Their rebranding isn't special for Netscape/AOL and other corporate
partners; they've worked very hard to make it accessible to third
parties without any need for explicit cooperation with them.  They're
going through the agony of relicensing their entire code base under
MPL/LGPL/GPL so that GPL projects can cherry-pick at source code
level.  They're good citizens in W3C standards space even when the
committee decisions go against them (e. g., XUL vs. XForms).  I don't
know the details of their CA certificate handling, but at least they
_have_ a policy and respond constructively to criticism of it.  And
Mitch Kapor and the rest of the MoFo board have a lot of street cred
as individuals.

  The FSF has, at best, completely failed to offer leadership with
  respect to free software and trademarks, as the MySQL case and the Red
  Hat / UnixCD mess have shown.  I think it would be rather gratifying
  if Debian could step in to fill the void.  And it would be kind of
  nice to have a workable modus vivendi to exhibit if and when the Linux
  Mark Institute (or the OpenSSL team or the PHP folks or Red Hat or
  MySQL) comes knocking.
 
 I do have to agree that guidance when it comes to trademark situations
 is sorely lacking. There doesn't seem to be that consistent a
 viewpoint with Debian either unfortunately.

It's a sticky wicket.  Free software enthusiasts (among whom I count
myself) don't like systems that exacerbate second-class-citizenship
among those whose motivations aren't principally commercial.  Nowadays
everyone's a publisher, and the paperwork overhead of copyright has
dropped near to zero (until you try to enforce it); but not everyone
is a marketer, and that's what trademarks are about.  I think it's
possible to have a personal-freedom-compatible trademark policy, but
it's not trivial, and the first few tries are bound to have their
discontents.  Doesn't mean it's not worth trying, though.

Cheers,
- Michael
(IANADD, IANAL)

Re: Mozilla Foundation Trademarks

[Eric Dorland]

* John Hasler ([EMAIL PROTECTED]) wrote:
 Eric Dorland writes:
  If we don't need the arrangement, why exactly would we accept it
  anyway?
 
 Because they want it and it costs us nothing to give it to them.  They are
 our friends.  Let's accommodate them where we can.

We may be their friends, but that shouldn't give us special
privileges. 

Friendship is really not a valid justification to do something in this
context.

-- 
Eric Dorland [EMAIL PROTECTED]
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6

-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ 
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ 
G e h! r- y+ 
--END GEEK CODE BLOCK--


signature.asc
Description: Digital signature

Re: Mozilla Foundation Trademarks

[Michael K. Edwards]

On 6/17/05, Eric Dorland [EMAIL PROTECTED] wrote:
 * John Hasler ([EMAIL PROTECTED]) wrote:
  Exactly.  If Debian doesn't need such an arrangement, neither do our users.
  And if our users don't need such an arrangement, our accepting it does not
  put us in a privileged position with respect to them: they have the legal
  right to do everything that we want to do with or without permission.
 
  So let's accept the arrangement and move on.  There is no DFSG problem
  here even if we do accept the notion that the DFSG applies to trademarks.
 
 If we don't need the arragement, why exactly would we accept it
 anyway?

I wouldn't say accept it, I would say acknowledge the safety zone
offered unilaterally by the Mozilla Foundation, and as a courtesy to
them make some effort to stay comfortably within it while continuing
to ship under the Mozilla names.  Their trademark policy is surely
less draconian than, say, Red Hat's, and we aren't going around
purging the RedHat Package Manager from Debian.

If the offer from six months ago still stands (which, to my
recollection and in my non-lawyer view, read like a unilateral safety
zone rather than a trademark license as such), that's extraordinarily
accommodating on MoFo's part.  It's a square deal from people with a
pretty good reputation for square deals.  They deserve better from
Debian than to have their flagship products obscured by a rename when
they haven't done anything nasty to anyone yet.

The FSF has, at best, completely failed to offer leadership with
respect to free software and trademarks, as the MySQL case and the Red
Hat / UnixCD mess have shown.  I think it would be rather gratifying
if Debian could step in to fill the void.  And it would be kind of
nice to have a workable modus vivendi to exhibit if and when the Linux
Mark Institute (or the OpenSSL team or the PHP folks or Red Hat or
MySQL) comes knocking.

Cheers,
- Michael

Re: Mozilla Foundation Trademarks

[John Hasler]

Eric Dorland writes:
 If we don't need the arrangement, why exactly would we accept it
 anyway?

Because they want it and it costs us nothing to give it to them.  They are
our friends.  Let's accommodate them where we can.
-- 
John Hasler


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Mozilla Foundation Trademarks

[Gervase Markham]

John Hasler wrote:

Alexander Sack writes:


In general the part of the MoFo brand we are talking about is the product
name (e.g. firefox, thunderbird, sunbird). From what I can recall now, it
is used in the help menu, the about box, the package-name and the window
title bar.


I'm not convinced that any of these constitute trademark infringement.


Then I'm slightly confused as to your concept of trademark infringement. 
If I label the car I've built as a Ford (even if it uses a lot of Ford 
parts), it infringes Ford's trademark.


I haven't heard anyone else disputing that to ship a web browser called 
Firefox, Debian needs an arrangement with the owner of the trademark 
Firefox as applied to web browsers.


Gerv


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Mozilla Foundation Trademarks

[Michael K. Edwards]

On 6/17/05, Gervase Markham [EMAIL PROTECTED] wrote:
 John Hasler wrote:
  Alexander Sack writes:
 
 In general the part of the MoFo brand we are talking about is the product
 name (e.g. firefox, thunderbird, sunbird). From what I can recall now, it
 is used in the help menu, the about box, the package-name and the window
 title bar.
 
  I'm not convinced that any of these constitute trademark infringement.
 
 Then I'm slightly confused as to your concept of trademark infringement.
 If I label the car I've built as a Ford (even if it uses a lot of Ford
 parts), it infringes Ford's trademark.
 
 I haven't heard anyone else disputing that to ship a web browser called
 Firefox, Debian needs an arrangement with the owner of the trademark
 Firefox as applied to web browsers.

Debian doesn't need such an arrangement, as I argued in a previous
thread six months ago; there's the Coty v. Prestonettes standard and
all that.  But IMHO it would be advisable for both sides if such an
arrangement were reached.  I prefer the not-quite-a-trademark-license
arrangement discussed in the thread ending at
http://lists.debian.org/debian-legal/2005/01/msg00795.html .

But then, I tend to take the square deal / keep people's options
open when that won't result in a tragedy of the commons approach to
freedom rather than the natural right approach.  So I'm
pro-GPL-as-construed-under-the-actual-law,
pro-trademark-when-used-to-discourage-misrepresentation, and
pro-real-world-legal-system generally.  This may put me in a minority
among debian-legal regulars.  :-)

Cheers,
- Michael
(IANAL, IANADD)

Re: Mozilla Foundation Trademarks

[John Hasler]

Gerv writes:
 If I label the car I've built as a Ford (even if it uses a lot of Ford
 parts), it infringes Ford's trademark.

Not until you try to sell it.  Ford Motor Company does not own the word
'Ford'.  They merely have the exclusive right to sell automobiles (and
related parts and services) using that mark.
-- 
John Hasler 
[EMAIL PROTECTED]
Elmwood, WI USA


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Mozilla Foundation Trademarks

[John Hasler]

Michael writes:
 Debian doesn't need such an arrangement, as I argued in a previous
 thread six months ago; there's the Coty v. Prestonettes standard and all
 that.  But IMHO it would be advisable for both sides if such an
 arrangement were reached.

Exactly.  If Debian doesn't need such an arrangement, neither do our users.
And if our users don't need such an arrangement, our accepting it does not
put us in a privileged position with respect to them: they have the legal
right to do everything that we want to do with or without permission.

So let's accept the arrangement and move on.  There is no DFSG problem
here even if we do accept the notion that the DFSG applies to trademarks.
-- 
John Hasler
(IANAL, IAADD)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Mozilla Foundation Trademarks

[Eric Dorland]

* John Hasler ([EMAIL PROTECTED]) wrote:
 Michael writes:
  Debian doesn't need such an arrangement, as I argued in a previous
  thread six months ago; there's the Coty v. Prestonettes standard and all
  that.  But IMHO it would be advisable for both sides if such an
  arrangement were reached.
 
 Exactly.  If Debian doesn't need such an arrangement, neither do our users.
 And if our users don't need such an arrangement, our accepting it does not
 put us in a privileged position with respect to them: they have the legal
 right to do everything that we want to do with or without permission.
 
 So let's accept the arrangement and move on.  There is no DFSG problem
 here even if we do accept the notion that the DFSG applies to trademarks.

If we don't need the arragement, why exactly would we accept it
anyway? 

-- 
Eric Dorland [EMAIL PROTECTED]
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6

-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ 
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ 
G e h! r- y+ 
--END GEEK CODE BLOCK--


signature.asc
Description: Digital signature

Re: mozilla-locale-it

[Francesco Pedrini]

On Thu, 16 Jun 2005 10:16:07 +0200
Carlo Contavalli [EMAIL PROTECTED] wrote:

 Ciao,
   ho intenzione di orphanarlo nel giro di qualche giorno ... se 
 interessa a qualcuno, batta un colpo ...
 

BUM! :D

non sono dd per...
se posso prendermene cura lo stesso lo faccio volentieri :)


ciao
francesco

-- 
:wq

Re: mozilla-locale-it

[Marco Bertorello]

On Thu, 16 Jun 2005 15:03:01 +
Vincenzo Farruggia [EMAIL PROTECTED] wrote:

 Alle 08:16, gioved 16 giugno 2005, Carlo Contavalli ha scritto:
   ho intenzione di orphanarlo nel giro di qualche giorno ... se 
  interessa a qualcuno, batta un colpo ...
 
 Scusa la mia ignoranza
 Che significa orphanarlo? 

renderlo... oprhano :-)

bye
-- 
Marco Bertorello
System Administrator
Linux Registered User #319921


pgphUGbKFRsMb.pgp
Description: PGP signature

Re: mozilla-locale-it

[Francesco Pedrini]

On Thu, 16 Jun 2005 15:03:01 +
Vincenzo Farruggia [EMAIL PROTECTED] wrote:

 Alle 08:16, gioved 16 giugno 2005, Carlo Contavalli ha scritto:
   ho intenzione di orphanarlo nel giro di qualche giorno ... se 
  interessa a qualcuno, batta un colpo ...
 
 Scusa la mia ignoranza
 Che significa orphanarlo? 
 
renderlo senza maintainer e farlo passare sotto la cura del qa-team.


ciao
francesco


-- 
:wq

Re: Mozilla Foundation Trademarks

[Alexander Sack]

Humberto Massa Guimares wrote:

What trademarks are you referring to? Already the Debian
packages don't use any of the trademarked images and logos? 
  

If we don't use any trademarked images, logos, or phrases, what
exactly are we talking about here?



As I think this is a very nice question, could Eric or any other
person identify which Mozilla Foundation trademarks are used in our
packages (and where)?


  

In general the part of the MoFo brand we are talking about is the
product name (e.g. firefox, thunderbird, sunbird). From what I can
recall now, it is used in the help menu, the about box, the package-name
and the window title bar.

-- 
 GPG messages preferred.   |  .''`.  ** Debian GNU/Linux **
 Alexander Sack| : :' :  The  universal
 [EMAIL PROTECTED]   | `. `'  Operating System
 http://www.asoftsite.org  |   `-http://www.debian.org/

Re: Mozilla Foundation Trademarks

[John Hasler]

Alexander Sack writes:
 In general the part of the MoFo brand we are talking about is the product
 name (e.g. firefox, thunderbird, sunbird). From what I can recall now, it
 is used in the help menu, the about box, the package-name and the window
 title bar.

I'm not convinced that any of these constitute trademark infringement.
-- 
John Hasler


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: mozilla-firefox-locale package with all language translations

[Christian Perrier]

Quoting Cesar Martinez Izquierdo ([EMAIL PROTECTED]):

 I've just uploaded a new version (1.0-3) that generates separate binary 
 packages for each language.

This is great news. Thus you mean that in the future, as soon as a
language is added upstream, we will get a new Debian binary package
for Firefox localization? If so, this is a major improvement I have to
mention to the Arabeyes team who were concerned by getting an Arabic
localisation for Firefox in Debian.

I now just need telling them that it may automagically appear as soon
as they get their ar localisation upstream.

I think this could be a good addition to tasksel language
taskshowever, this would need firefox to be added to the desktop
task in tasksel...post-sarge, definitely..

As a man daily working as desktop architecture designer, I would say
that Firefox is about to become the obvious browser choice for a
Linux-based workstation (it as been chosen by the french Ministry of
Equipment Roads and Transportation as default browser for their 13000
Linux based workstations). So installing it by default in our
desktop task would be an important enhancement.



 
 The remaining issues are:
 - some of the binary packages will need specific Conflicts:, Provides: or 
 Replaces: lines that the script can't figure out automatically.
 Solution: We can add them by hand.
 
 - the description of the package should contain the name of the language it 
 provides, not only the name of the locale (eg: es-AR). Any ideas?
 (I guess I will need a list of locales+language names; /etc/locale.alias 
 seems 
 to be good but not complete).

I have seen these different es localisation packages and was a bit
puzzled by them. I have understood that Spanish and more specifically
technical Spanish is spoken differently on both sides of the Atlantic
Ocean but I really think that two separate packages/localisations is
really a waste of time. Moreover, a es_AR package will handle
Spanish/Argentina well, but what about other South American
spanish-speaking countries ?

I suppose that this is also an upstream problem : if upstream ships
different Spanish localisation packages, of course we in Debian have
no choice but shipping them, but imho, this is not a really good idea.

Anyway, if what I suggest above is added to tasksel, we will anyway
install the es package for all es localesOr we will need to
change tasksel so that it has a concept of locale tasks rather than
language tasks.

The addtionnal work and maintenance complication is maybe not worth it
just because people do not agree whether one should say computador
or ordenador or whatever else..

Bringing back my Arabic localization example : the ar localization
guys never ever imagined creating special ar_* packages for the
different flavours of Arabic and you all know that spoken Arabic is
way different in the various Arabic-speaking countries. Far more
different than Castillan and Argentinan Spanish are.

/me crosses fingers for never seeing fr_CA (tabarnak) or fr_BE (une
fois) or fr_FR(mon Dieu) packages.

Re: mozilla-firefox-locale package with all language translations

[Cesar Martinez Izquierdo]

El Miércoles 17 Noviembre 2004 07:10, Christian Perrier escribió:
 Quoting Cesar Martinez Izquierdo ([EMAIL PROTECTED]):
  I've just uploaded a new version (1.0-3) that generates separate binary
  packages for each language.

 This is great news. Thus you mean that in the future, as soon as a
 language is added upstream, we will get a new Debian binary package
 for Firefox localization? 

Yes, it means that. (But we lack a way to know if new languages are 
available).

Now I need one sponsor to get this package into Debian (as I'm not DD), and 
also to know which of the current mozilla-firefox-locale-xx packages are 
interested in change to this new aproach.

 I now just need telling them that it may automagically appear as soon
 as they get their ar localisation upstream.

Yes. Or they can directly send the XPI to me when it's ready.

 I think this could be a good addition to tasksel language
 taskshowever, this would need firefox to be added to the desktop
 task in tasksel...post-sarge, definitely..

 As a man daily working as desktop architecture designer, I would say
 that Firefox is about to become the obvious browser choice for a
 Linux-based workstation (it as been chosen by the french Ministry of
 Equipment Roads and Transportation as default browser for their 13000
 Linux based workstations). So installing it by default in our
 desktop task would be an important enhancement.

  The remaining issues are:
  - some of the binary packages will need specific Conflicts:,
  Provides: or Replaces: lines that the script can't figure out
  automatically. Solution: We can add them by hand.
 
  - the description of the package should contain the name of the language
  it provides, not only the name of the locale (eg: es-AR). Any ideas? (I
  guess I will need a list of locales+language names; /etc/locale.alias
  seems to be good but not complete).

 I have seen these different es localisation packages and was a bit
 puzzled by them. I have understood that Spanish and more specifically
 technical Spanish is spoken differently on both sides of the Atlantic
 Ocean but I really think that two separate packages/localisations is
 really a waste of time. Moreover, a es_AR package will handle
 Spanish/Argentina well, but what about other South American
 spanish-speaking countries ?

 I suppose that this is also an upstream problem : if upstream ships
 different Spanish localisation packages, of course we in Debian have
 no choice but shipping them, but imho, this is not a really good idea.

 Anyway, if what I suggest above is added to tasksel, we will anyway
 install the es package for all es localesOr we will need to
 change tasksel so that it has a concept of locale tasks rather than
 language tasks.

 The addtionnal work and maintenance complication is maybe not worth it
 just because people do not agree whether one should say computador
 or ordenador or whatever else..

 Bringing back my Arabic localization example : the ar localization
 guys never ever imagined creating special ar_* packages for the
 different flavours of Arabic and you all know that spoken Arabic is
 way different in the various Arabic-speaking countries. Far more
 different than Castillan and Argentinan Spanish are.

 /me crosses fingers for never seeing fr_CA (tabarnak) or fr_BE (une
 fois) or fr_FR(mon Dieu) packages.

I agree with you about these es_ES and es_AR translations, it has not too much 
sense (as both of them are correct spanish and totally understable to each 
other). In fact, I'm from Spain and I've tried both ES and AR translations 
and I don't find such important differences, they are pretty similar.
Anyway, for the moment upstream is only shiping es_AR translation, the 
es_ES one is only in nightly builds.
Maybe I will contact both translation teams and suggest to join efforts, but I 
don't hope to be too succesul...

  César

Re: mozilla-firefox-locale package with all language translations

[Cesar Martinez Izquierdo]

El Jueves 11 Noviembre 2004 07:50, Mike Hommey escribió:
 Anyways, I'd suggest to make a multi-binary package so that it produces
 several mozilla-firefox-locale-* packages.
 Mike

I've just uploaded a new version (1.0-3) that generates separate binary 
packages for each language.

The remaining issues are:
- some of the binary packages will need specific Conflicts:, Provides: or 
Replaces: lines that the script can't figure out automatically.
Solution: We can add them by hand.

- the description of the package should contain the name of the language it 
provides, not only the name of the locale (eg: es-AR). Any ideas?
(I guess I will need a list of locales+language names; /etc/locale.alias seems 
to be good but not complete).

The package is available at:

http://users.evtek.fi/~k0400388/debian/mozilla-firefox-locale-all


  Cesar Martinez Izquierdo

Re: mozilla-firefox-locale package with all language translations

[Wouter Hanegraaff]

Hi,

On Thu, Nov 11, 2004 at 06:47:15AM +0100, Cesar Martinez Izquierdo wrote:
 
 The rules file includes an wget rule that can download the available XPI 
 files with the translations.
 After download new XPI files, if you regenerate the package then you get all 
 the required files for these new XPIs.

This sounds like a very useful package! But why include all translations
in the package itself?

It should be possible to create an installer package that doesn't
include any translations, but instead downloads the translations you
selected after installation.  Something like the msttcorefonts package
does. It would be nice to have a similar package for installing
extensions, too.

Just a thought.

Best regards,

Wouter

Re: mozilla-firefox-locale package with all language translations

[Nikolai Prokoschenko]

On Thu, Nov 11, 2004 at 03:50:51PM +0900, Mike Hommey wrote:

 Anyways, I'd suggest to make a multi-binary package so that it produces
 several mozilla-firefox-locale-* packages.

A stupid question from my side: do we have any code in the mozilla-*
wrappers to automatically select the right language according to the
current locale?

PS. /me is angry about KDE not doing so.

-- 
Nikolai Prokoschenko 
[EMAIL PROTECTED] / Jabber: [EMAIL PROTECTED]

Re: mozilla-firefox-locale package with all language translations

[Bill Allombert]

On Fri, Nov 12, 2004 at 05:12:48AM +0100, Cesar Martinez Izquierdo wrote:
 El Jueves 11 Noviembre 2004 10:47, Jeroen van Wolffelaar escribió:
  Your package is native, I suggest supporting the 'get-orig-source'
  rules-target to make that one generate a .orig.tar.gz containing all
  upstream languages.
 
 
 You mean that should I create one rule looking like the following?
 get-orig-source:
  NAME=basename `pwd`
  mkdir $NAME.orig
  wget -N -P $(CURDIR)/$NAME.orig '$(FETCHADDRESS)*-*.xpi'
  rm -f $(CURDIR)/$NAME.orig/en-US.xpi
  tar -cvzf ../$NAME.orig.tar.gz $NAME.orig

Something like that, yes.

 What's the purpose of that? (I'm new in packaging).
 This way, will the package be considered non-native?

No, but it will comply to Debian policy 4.8./get-orig-source

 `get-orig-source' (optional)
  This target fetches the most recent version of the original
  source package from a canonical archive site (via FTP or WWW, for
  example), does any necessary rearrangement to turn it into the
  original source tar file format described below, and leaves it in
  the current directory.

  This target may be invoked in any directory, and should take care
  to clean up any temporary files it may have left.

  This target is optional, but providing it if possible is a good
  idea.

This will allow a developer that need to update the package to new
upstream version to use a documented procedure instead of guessing how
to proceed.

See eterm-themes for an example of package assembled that way.

Cheers,
-- 
Bill. [EMAIL PROTECTED]

Imagine a large red swirl here. 

Re: mozilla-firefox-locale package with all language translations

[Mike Hommey]

On Fri, Nov 12, 2004 at 10:52:35AM +0100, Nikolai Prokoschenko wrote:
 On Thu, Nov 11, 2004 at 03:50:51PM +0900, Mike Hommey wrote:
 
  Anyways, I'd suggest to make a multi-binary package so that it produces
  several mozilla-firefox-locale-* packages.
 
 A stupid question from my side: do we have any code in the mozilla-*
 wrappers to automatically select the right language according to the
 current locale?

There is one in firefox. I'm not sure mozilla supports the -UIlocale and
-contentLocale we can use on firefox to do the trick...

Mike

Re: mozilla-firefox-locale package with all language translations

[Eric Dorland]

* Mike Hommey ([EMAIL PROTECTED]) wrote:
 On Fri, Nov 12, 2004 at 10:52:35AM +0100, Nikolai Prokoschenko wrote:
  On Thu, Nov 11, 2004 at 03:50:51PM +0900, Mike Hommey wrote:
  
   Anyways, I'd suggest to make a multi-binary package so that it produces
   several mozilla-firefox-locale-* packages.
  
  A stupid question from my side: do we have any code in the mozilla-*
  wrappers to automatically select the right language according to the
  current locale?
 
 There is one in firefox. I'm not sure mozilla supports the -UIlocale and
 -contentLocale we can use on firefox to do the trick...

Yes it does, that's where I stole the idea/code from :)

-- 
Eric Dorland [EMAIL PROTECTED]
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6

-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ 
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ 
G e h! r- y+ 
--END GEEK CODE BLOCK--


signature.asc
Description: Digital signature

Re: mozilla-firefox-locale package with all language translations

[Mike Hommey]

On Thu, Nov 11, 2004 at 06:47:15AM +0100, Cesar Martinez Izquierdo wrote:
 Hi! Sometimes a package with all the firefox translations has been proposed.
 With the arrival of Firefox 1.0, localization has been normalized and now 
 this 
 package seems quite suitable.
 
 As a proof of concept, I have packaged mozilla-firefox-locale-all, 
 containing all the available translations at the moment.
 
 You can download the package at:
 http://users.evtek.fi/~k0400388/debian/mozilla-firefox-locale-all/
 
 The rules file includes an wget rule that can download the available XPI 
 files with the translations.
 After download new XPI files, if you regenerate the package then you get all 
 the required files for these new XPIs.
 
 The currently built package contains the XPI files downloaded from 
 ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-0.11-l10n/linux-xpi/.
 Maybe it would be better to use 
 ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/1.0/linux-i686/xpi/, 
 which contains less translations but they are supposed to be tested and 
 complete. Anyway the nightly XPIs seem to work fine for me.
 
 Opinions and testing is welcome.

You're not lucky, with the 1.0 package that just got uploaded to
unstable, your package is useless, 'cause support for
/var/lib/mozilla-firefox/chrome.d has been dropped.

Anyways, I'd suggest to make a multi-binary package so that it produces
several mozilla-firefox-locale-* packages.

As for how to make the thing work with new firefox package, I'm working
on an HTML version of what I sent to extensions packages maintainers 2
days ago about the new scheme. I'll send the URL here when it's done.
In the meanwhile, you can still guess what's going on by taking a look
at extensions and locales available in
http://glandium.org/debian/unstable/.

Mike

Re: mozilla-firefox-locale package with all language translations

[Jeroen van Wolffelaar]

On Thu, Nov 11, 2004 at 06:47:15AM +0100, Cesar Martinez Izquierdo wrote:
 Hi! Sometimes a package with all the firefox translations has been proposed.
 With the arrival of Firefox 1.0, localization has been normalized and now 
 this 
 package seems quite suitable.
 
 As a proof of concept, I have packaged mozilla-firefox-locale-all, 
 containing all the available translations at the moment.
 
 You can download the package at:
 http://users.evtek.fi/~k0400388/debian/mozilla-firefox-locale-all/
 
 The rules file includes an wget rule that can download the available XPI 
 files with the translations.
 After download new XPI files, if you regenerate the package then you get all 
 the required files for these new XPIs.

Your package is native, I suggest supporting the 'get-orig-source'
rules-target to make that one generate a .orig.tar.gz containing all
upstream languages.

Also, since the installed-size of the generated .deb is 17MB, maybe it's
still wise to have it generate multiple packages like is done now (it'll
also easy upgrades).

--Jeroen

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber  MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl

Re: mozilla-firefox-locale package with all language translations

[Mike Hommey]

On Thu, Nov 11, 2004 at 03:50:51PM +0900, Mike Hommey wrote:
 As for how to make the thing work with new firefox package, I'm working
 on an HTML version of what I sent to extensions packages maintainers 2
 days ago about the new scheme. I'll send the URL here when it's done.

And here it is:
http://glandium.org/debian/packages/mozilla-firefox/New_scheme_for_extensions/current.html

Mike