As one of the folks who brought up the initial concern let me be clear that
at this point my only real concern here is one of optics. The DoH service
we're using is likely more private than anything the user is currently
using. I just don't want to see random folks on the web "discover" these
DoH r
On 3/19/18 8:59 PM, Boris Zbarsky wrote:
> On 3/19/18 1:08 PM, Selena Deckelmann wrote:
>> There's a lot of thinking that went into the agreement we have with
>> Cloudflare to enable this experiment in a way that respects user privacy.
>
> I would like us to be very clear that there are two separa
On 3/19/18 1:08 PM, Selena Deckelmann wrote:
There's a lot of thinking that went into the agreement we have with
Cloudflare to enable this experiment in a way that respects user privacy.
I would like us to be very clear that there are two separate things here:
1) Is this behavior good for use
On Mon, Mar 19, 2018 at 07:27:39PM -0700, Nicholas Alexander wrote:
Hi all,
On Mon, Mar 19, 2018 at 3:56 PM, Xidorn Quan wrote:
It's fine to embed this experiment in the product, and blog about it, but
it's definitely not fine to have it enabled by default and send every DNS
request to a thir
Hi all,
On Mon, Mar 19, 2018 at 3:56 PM, Xidorn Quan wrote:
> It's fine to embed this experiment in the product, and blog about it, but
> it's definitely not fine to have it enabled by default and send every DNS
> request to a third-party.
>
> I can understand that the intent must be good, and f
Greetings,
For some time we have had a whitelist of prefs that get sent to content
processes very early, in dom/ipc/ContentPrefs.cpp, not via the standard IPC
channels. There is also some checking machinery that makes sure that prefs
not on that list aren't accessed too early. It is a significant
It's fine to embed this experiment in the product, and blog about it, but it's
definitely not fine to have it enabled by default and send every DNS request to
a third-party.
I can understand that the intent must be good, and for better privacy, but the
approach of doing so is not acceptable. Us
On Monday 2018-03-19 22:32 +, Jonathan Kew wrote:
> As of this week, for the mozilla-61 cycle, I plan to turn support for
> OpenType Font Variations on by default.
>
> It has been developed behind the layout.css.font-variations.enabled and
> gfx.downloadable_fonts.keep_variation_tables prefere
As of this week, for the mozilla-61 cycle, I plan to turn support for
OpenType Font Variations on by default.
It has been developed behind the layout.css.font-variations.enabled and
gfx.downloadable_fonts.keep_variation_tables preferences.
Other UAs shipping this or intending to ship it inclu
On Mon, Mar 19, 2018 at 08:49:10PM +0200, Henri Sivonen wrote:
It appears that currently we allow atomicizing invalid UTF-16 string,
which are impossible to look up by UTF-8 key and we don't allow
atomicizing invalid UTF-8.
I need to change some things in this area in response to changing
error
On Mon, Mar 19, 2018 at 7:08 PM, Selena Deckelmann wrote:
> and also in terms of the regulatory environment in the US) allows *all* of
> this data to be collected indefinitely and sold to third parties.
Some users are in countries where it's illegal for the ISP to sell
this information to third p
It appears that currently we allow atomicizing invalid UTF-16 string,
which are impossible to look up by UTF-8 key and we don't allow
atomicizing invalid UTF-8.
I need to change some things in this area in response to changing
error handling of UTF-8 to UTF-16 XPCOM string conversions to be more
s
Hi!
Thanks for all the thoughtful comments about this experiment. The intent of
this work is to provide users privacy-respecting DNS. Status quo for DNS
does not offer many users reasonable, informed choice about log retention,
and doesn't offer encrypted DNS. Users also cannot be reasonably expec
On Mon, 19 Mar 2018, Martin Thomson wrote:
I don't know if it is possible to know if you have a manually-configured DNS
server, but disabling this experiment there if we can determine that would
be good - that might not be something to worry about with Nightly, but it
seems like it might be ne
Is running the service ourselves out of the question? If so, how come?
I mean I know we're not really in the business of running massive
scale DNS; but running it for a month, and ramping up the people
included in the study so we can monitor load seems feasible.
The goal of the study is described
On Mon, Mar 19, 2018 at 1:25 PM, Patrick McManus wrote:
> The objective here is a net improvement for privacy and integrity.
I understand that the goal is better privacy. But it's likely that
people get outraged if a browser sends information about what is
browser to an off-path destination witho
Daniel
Le 19 mars 2018 à 17:07, Daniel Stenberg a écrit :
> What other precautions or actions can we do to reduce the risk of this being
> perceived as problematic?
opt-in only. That's the only way.
What seems innocuous for someone deep into the topic is not necessary the same
for others. W
On Mon, Mar 19, 2018 at 11:48 AM, Martin Thomson wrote:
> Yes, it pays to remember that this is Nightly.
Even on Nightly we place pretty severe restrictions on ourselves when
it comes to user data, e.g., for telemetry. This definitely goes
beyond the kind of data I would expect Mozilla, let alone
Yes, it pays to remember that this is Nightly.
The precautions Henri suggests are good, but more appropriate to
experiments we would do on Release. For TLS 1.3, we did that sort of
thing so that we could get measurements from Release; we just flipped
the switch to "on" for Nightly.
I don't know
The objective here is a net improvement for privacy and integrity. It is
indeed a point of view with Nightly acting as an opinionated User Agent on
behalf of its users. IMO we can't be afraid of pursuing experiments that
help develop those ideas even when they move past traditional modes.
Tradition
On 3/19/18 11:21 AM, Emilio Cobos Álvarez wrote:
> On 11/29/17 6:36 PM, Mike Taylor wrote:
>>
>>> On Nov 29, 2017, at 10:53 AM, Emilio Cobos Álvarez wrote:
>>>
>>> In bug 1035091 I intend to remove support for the @-moz-document CSS
>>> rule in content pages (more exactly in author stylesheets).
>
On 11/29/17 6:36 PM, Mike Taylor wrote:
>
>> On Nov 29, 2017, at 10:53 AM, Emilio Cobos Álvarez wrote:
>>
>> In bug 1035091 I intend to remove support for the @-moz-document CSS
>> rule in content pages (more exactly in author stylesheets).
>
> This is a pretty widely used mechanism to target st
On Mon, Mar 19, 2018 at 8:10 AM, Henri Sivonen wrote:
> On Mon, Mar 19, 2018 at 3:18 AM, Eric Shepherd (Sheppy)
> wrote:
>> I definitely see some easy ways this could be problematic from a public
>> relations perspective given things going on in the industry these days and
>> some of our own mist
On Mon, Mar 19, 2018 at 10:07 AM, Daniel Stenberg wrote:
> On Sun, 18 Mar 2018, Eric Shepherd (Sheppy) wrote:
>
> I don't have such a far-reaching agreement with my ISP and its DNS.
1) Mozilla doesn't choose the ISP on users' behalf. (This is the key reason.)
2) The ISP sees the Host header in un
I'd like to start to dispatch "keydown" and "keyup" events even if
composing, i.e., there is composition string of IME but only on Nightly
and early Beta for now.
https://bugzilla.mozilla.org/show_bug.cgi?id=1446401
This follows other browsers' behavior and conforms to UI Events spec:
https://w
On 19/03/2018 09:07, Daniel Stenberg wrote:
> On Sun, 18 Mar 2018, Eric Shepherd (Sheppy) wrote:
>
> I don't have such a far-reaching agreement with my ISP and its DNS. I
> don't have such an agreement at all with 8.8.8.8 or other publicly
> provided DNS operators.
Yes, you're perfectly right, but
On Mon, Mar 19, 2018 at 3:18 AM, Eric Shepherd (Sheppy)
wrote:
> I definitely see some easy ways this could be problematic from a public
> relations perspective given things going on in the industry these days and
> some of our own mistakes the in the past. It's definitely worth taking a
> little
On Sun, 18 Mar 2018, Eric Shepherd (Sheppy) wrote:
I don't have such a far-reaching agreement with my ISP and its DNS. I don't
have such an agreement at all with 8.8.8.8 or other publicly provided DNS
operators.
What other precautions or actions can we do to reduce the risk of this being
per
Hello,
Here's the list of new issues found and filed by the Desktop Release QA team
last week.
Additional details on the team's priorities last week, as well as the plans for
the current week are available at: https://goo.gl/SM4Ro7
Bugs logged by Desktop Release QA in the last 8 days
Firefox:
29 matches
Mail list logo
