Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

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

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

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

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

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

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

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

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

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

dom/ipc/ContentPrefs.{h,cpp} are gone

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

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

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.

Re: Intent to ship: OpenType Variation Font support

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

Intent to ship: OpenType Variation Font support

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

Re: Use cases for invalid-Unicode atoms

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

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

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

Use cases for invalid-Unicode atoms

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

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

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

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

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

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

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

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

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

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

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

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

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

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

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

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

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.

Re: Intent to unship: @-moz-document from content pages.

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

Re: Intent to unship: @-moz-document from content pages.

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

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

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

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

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

Intent to ship: Start to dispatch "keydown" and "keyup" events even if composing (only in Nightly and early Beta)

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:

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

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

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

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

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

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

[desktop] Bugs logged by Desktop Release QA in the last 8 days

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: