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

[Ben Kelly]

Note, this effort is already being reported in the tech press based on this
thread.  For example:

https://www.theregister.co.uk/AMP/2018/03/20/mozilla_firefox_test_of_privacy_mechanism_prompts_privacy_worries/

A blog post does sound like a good idea.

On Mon, Mar 19, 2018, 11:33 PM Dave Townsend  wrote:

> 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 requests and not be able to find details about them and so cause a
> press cycle.
>
> Having a good blog post up, particularly if it jumps out when you search
> for the address that we're querying for DoH and gives good instructions on
> how to opt-out does a lot to mitigate that. Reducing the population would
> likely also help with that if that is an option.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: OpenType Variation Font support

[Jonathan Kew]

On 20/03/2018 20:50, gwhi...@gmail.com wrote:



Will 61 bring support for font-optical-sizing as well?


Yes; it's behind the same pref as font-variation-settings, so the two 
properties will be enabled together.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: OpenType Variation Font support

[gwhitms]

On Tuesday, March 20, 2018 at 4:39:36 AM UTC-7, Jonathan Kew wrote:
> On 19/03/2018 22:42, L. David Baron wrote:
> 
> > Is there something with a little more detail about how our (a)
> > feature set and (b) platform support compares with what other
> > engines are shipping? 
> 
> That sounds like it could be a worthwhile blog post somewhere
> 
> In brief: everyone supports font-variation-settings, the most basic tool 
> authors can use to control these fonts.
> 
> The CSS spec also calls for higher-level linkage to (enhanced forms of) 
> the font-{weight,stretch,style} properties. Edge implements this; Blink 
> currently accepts [at least some of] the extended CSS values (e.g. 
> non-integer font-weight values) but doesn't have them hooked up to 
> variation font rendering; we don't yet implement this.
> 
> Regarding platform support: Edge, Safari and Firefox only support 
> variation fonts on up-to-date versions of Win10 and macOS, while Chrome 
> (AIUI) also supports them on older versions (by shipping an embedded 
> copy of FreeType to use in place of the system font rasterizer when it 
> doesn't have variation support).
> 
> On Linux, official Mozilla builds have variation support; distro builds 
> that use --with-system-freetype will also work provided the system 
> freetype is fairly recent, but old distros may still have a freetype 
> that lacks variation support.
> 
> I haven't tested recent Chrome on Android but I presume they have the 
> same support there as on desktop (as does Firefox).
> 
> So to sum up
> 
>  > That is, are there substantive cases where
>  > some systems will have variation font support on other browsers but
>  > not Firefox,
> 
> On older releases of macOS and Windows, Chrome will have it but Firefox 
> won't (neither will Safari/IE/Edge, however).
> 
>  > or substantive features that other implementations will
>  > be shipping but we won't?
> 
> Support for the enhanced font-{weight,stretch,style} properties is 
> currently only shipping in Edge, AFAICT; Blink has parsing but not full 
> rendering support.


Will 61 bring support for font-optical-sizing as well?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

On Tue, Mar 20, 2018 at 3:02 AM, Henri Sivonen  wrote:

> 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 without explicit consent regardless
> of intention, nightliness or promises the destination has made.
>

Today the Mozilla blog says:

> At Mozilla, our approach to data is simple: no surprises, and user choice
is critical.
https://blog.mozilla.org/blog/2018/03/20/mozilla-statement-petition-facebook-cambridge-analytica/

It would be unfortunate to undermine that message in the current
environment.

Rob
-- 
Su ot deraeppa sah dna Rehtaf eht htiw saw hcihw, efil lanrete eht uoy ot
mialcorp ew dna, ti ot yfitset dna ti nees evah ew; deraeppa efil eht. Efil
fo Drow eht gninrecnoc mialcorp ew siht - dehcuot evah sdnah ruo dna ta
dekool evah ew hcihw, seye ruo htiw nees evah ew hcihw, draeh evah ew
hcihw, gninnigeb eht morf saw hcihw taht.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Kris Maglione]

On Tue, Mar 20, 2018 at 11:43:13AM +0100, Frederik Braun wrote:



On 20.03.2018 04:33, Dave Townsend wrote:

The DoH service
we're using is likely more private than anything the user is currently
using.


This is only true for some parts of the world.
I'd like us not to regress for our user base globally here.


That's only true to a certain extent. Some parts of the world may have 
better regulations for ISPs than others, but the situation for users on 
shared networks and unencrypted WiFi is more or less the same. DNS is 
still the most easily snoopable and spoofable security/privacy weak 
point for those users.


In any case, the point of this experiment, as described, is to figure 
out how useful/workable DoH would be for users in the wild. If we limit 
the study to certain regions, it's hard to say with any certainty that 
users in other regions wouldn't benefit from it.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Use cases for invalid-Unicode atoms

[Steve Fink]

On 03/20/2018 06:49 AM, Henri Sivonen wrote:

On Tue, Mar 20, 2018 at 12:44 PM, Henri Sivonen  wrote:

On Tue, Mar 20, 2018 at 11:12 AM, Henri Sivonen  wrote:

OK. I'll leave the UTF-16 case unchanged and will make the minimal
changes on the UTF-8 side to retain the existing outward behavior
without burning the tree. Hopefully I can make the UTF-8 case faster
while at it. It depended on not-so-great code.

I still have doubts about retaining the exact invalid-UTF-8 behavior.
The current behavior appears to be that if we try to atomicize an
invalid UTF-8 string, the returned atom is new atom representing the
empty string--not the pre-existing atom for the empty string.

Is there a reason why it's desirable behavior to potentially have
multiple atoms representing the empty string? Is there a reason why we
don't MOZ_CRASH on invalid UTF-8 if we are convinced enough that it's
not supposed to happen to the point that we let go of the atomicity of
atoms if it does happen?

Furthermore, we validate UTF-8 strings anyway as a side effect of
hashing them as if they were UTF-16, so if we don't want to MOZ_CRASH,
we could at that point swap a valid string (invalid byte sequences
replaced with U+FFFD) in the input string's place and atomicize that.
It could be a MOZ_UNLIKELY branch on the validation result that we
compute anyway and would avoid the weirdness of non-atomic atoms that
have no resemblance to the input string.

Thoughts?
My only thought is that the atomize-to-non-canonical-empty-string 
behavior sounds like a crazy footgun. But changing it also sounds scary 
-- currently, it sounds like valid strings produce unique atoms, and 
invalid strings produce unique placeholder things that will never match 
anything, even themselves, sort of like a string version of NaN. Is that 
correct?


If so, then your proposed change would not only make invalid strings 
compare equal to themselves, but also to other *different* invalid 
strings with same-length invalid byte sequences. That also seems kind of 
footgunny.


I don't really know how Gecko atoms work or are used, though, so I may 
be totally off base here.


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: macOS Flash NPAPI Sandbox

[Haik Aftandilian]

We intend to ship a process-level sandbox for the NPAPI Flash plugin on
macOS in 61. This will provide a degree of process isolation at the expense
of some lesser-used Flash functionality[1]. You can enable the sandbox now
on Nightly, globally for all sites, by setting
dom.ipc.plugins.sandbox-level.flash=1 and restarting the browser[2]. Before
this rides the trains, we intend to offer a per-site opt-out UI. But we
will enable this on Nightly by default earlier to get early feedback.

If you run Firefox on Mac and depend on any Flash sites, please give the
site a try with the sandbox enabled. And if you encounter any issues,
please file bugs blocking bug 1433577[3].

Thanks,
Haik

1. Flash applets that attempt to write to the filesystem will be impacted
because the plugin process has limited write access. Adobe Air installs
triggered by Flash applets will no longer work. Printing to PDF or
postscript, and Open in Preview from the print dialog does not work. No
issues have been found with any Flash games.

2. The same pref is used on Windows, but the numerical levels are not
comparable or related in any way to the Mac version.

3. https://bugzilla.mozilla.org/show_bug.cgi?id=1433577
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[mhoye]

On 2018-03-19 11:33 PM, Dave Townsend wrote:

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.


It isn't explicit right now that using nightly means opting in to 
participating in studies like this, and I think the text of the download 
page antedates our ability to do those studies. The text of the Firefox 
privacy page says that prerelease products "may contain different 
privacy characteristics" than release, but doesn't enumerate them. I 
also can't find a public-facing description of how we handle, secure and 
audit PII data in experiments involving partner organizations.


In both cases I'm confident we have solid policies and protocols there, 
I just don't see a way to point a concerned user to that information.


I'm working on that now.

- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Use cases for invalid-Unicode atoms

[Henri Sivonen]

On Tue, Mar 20, 2018 at 12:44 PM, Henri Sivonen  wrote:
> On Tue, Mar 20, 2018 at 11:12 AM, Henri Sivonen  wrote:
>> OK. I'll leave the UTF-16 case unchanged and will make the minimal
>> changes on the UTF-8 side to retain the existing outward behavior
>> without burning the tree. Hopefully I can make the UTF-8 case faster
>> while at it. It depended on not-so-great code.
>
> I still have doubts about retaining the exact invalid-UTF-8 behavior.
> The current behavior appears to be that if we try to atomicize an
> invalid UTF-8 string, the returned atom is new atom representing the
> empty string--not the pre-existing atom for the empty string.
>
> Is there a reason why it's desirable behavior to potentially have
> multiple atoms representing the empty string? Is there a reason why we
> don't MOZ_CRASH on invalid UTF-8 if we are convinced enough that it's
> not supposed to happen to the point that we let go of the atomicity of
> atoms if it does happen?

Furthermore, we validate UTF-8 strings anyway as a side effect of
hashing them as if they were UTF-16, so if we don't want to MOZ_CRASH,
we could at that point swap a valid string (invalid byte sequences
replaced with U+FFFD) in the input string's place and atomicize that.
It could be a MOZ_UNLIKELY branch on the validation result that we
compute anyway and would avoid the weirdness of non-atomic atoms that
have no resemblance to the input string.

Thoughts?

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: OpenType Variation Font support

[Jonathan Kew]

On 19/03/2018 22:42, L. David Baron wrote:


Is there something with a little more detail about how our (a)
feature set and (b) platform support compares with what other
engines are shipping? 


That sounds like it could be a worthwhile blog post somewhere

In brief: everyone supports font-variation-settings, the most basic tool 
authors can use to control these fonts.


The CSS spec also calls for higher-level linkage to (enhanced forms of) 
the font-{weight,stretch,style} properties. Edge implements this; Blink 
currently accepts [at least some of] the extended CSS values (e.g. 
non-integer font-weight values) but doesn't have them hooked up to 
variation font rendering; we don't yet implement this.


Regarding platform support: Edge, Safari and Firefox only support 
variation fonts on up-to-date versions of Win10 and macOS, while Chrome 
(AIUI) also supports them on older versions (by shipping an embedded 
copy of FreeType to use in place of the system font rasterizer when it 
doesn't have variation support).


On Linux, official Mozilla builds have variation support; distro builds 
that use --with-system-freetype will also work provided the system 
freetype is fairly recent, but old distros may still have a freetype 
that lacks variation support.


I haven't tested recent Chrome on Android but I presume they have the 
same support there as on desktop (as does Firefox).


So to sum up

> That is, are there substantive cases where
> some systems will have variation font support on other browsers but
> not Firefox,

On older releases of macOS and Windows, Chrome will have it but Firefox 
won't (neither will Safari/IE/Edge, however).


> or substantive features that other implementations will
> be shipping but we won't?

Support for the enhanced font-{weight,stretch,style} properties is 
currently only shipping in Edge, AFAICT; Blink has parsing but not full 
rendering support.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: No longer needed to annotate tests differently for stylo-disabled platforms.

[Emilio Cobos Álvarez]

In bug 1446954 I'm removing those platforms from our automation in
preparation to removing the old code, now that stylo is enabled everywhere.

This mostly affects you if you're hacking on the style system itself, or
in Shadow DOM stuff, which only works on the new style system.

There's probably a fair amount of WPT expectations and mochitest cleanup
that we can do. I went through the reftests in that same bug. Help on
that would be lovely :)

 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Use cases for invalid-Unicode atoms

[Henri Sivonen]

On Tue, Mar 20, 2018 at 11:12 AM, Henri Sivonen  wrote:
> OK. I'll leave the UTF-16 case unchanged and will make the minimal
> changes on the UTF-8 side to retain the existing outward behavior
> without burning the tree. Hopefully I can make the UTF-8 case faster
> while at it. It depended on not-so-great code.

I still have doubts about retaining the exact invalid-UTF-8 behavior.
The current behavior appears to be that if we try to atomicize an
invalid UTF-8 string, the returned atom is new atom representing the
empty string--not the pre-existing atom for the empty string.

Is there a reason why it's desirable behavior to potentially have
multiple atoms representing the empty string? Is there a reason why we
don't MOZ_CRASH on invalid UTF-8 if we are convinced enough that it's
not supposed to happen to the point that we let go of the atomicity of
atoms if it does happen?

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Frederik Braun]

On 20.03.2018 04:33, Dave Townsend wrote:
> The DoH service
> we're using is likely more private than anything the user is currently
> using.

This is only true for some parts of the world.
I'd like us not to regress for our user base globally here.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: OpenType Variation Font support

[Emilio Cobos Álvarez]

On 03/20/2018 11:22 AM, Jonathan Kew wrote:> There are a handful of
tests now in
> web-platform/tests/css/css-fonts/variations, and there a bunch more
> currently in preparation (e.g. see
> https://bugzilla.mozilla.org/show_bug.cgi?id=1436588).

There's also https://github.com/w3c/web-platform-tests/pull/9373. Do you
know how interoperable are we on those tests? They seem to have caught
at least a few Blink and Edge compat issues.

 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: OpenType Variation Font support

[Jonathan Kew]

On 20/03/2018 09:54, James Graham wrote:

On 19/03/2018 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 preferences.


Other UAs shipping this or intending to ship it include:
   Safari (on macOS 10.13 or later)
   Chrome (and presumably other Blink-based UAs)
   MSEdge (on Windows 10 Fall Creators Update or later)

Bug to turn on by default: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1447163


This feature was previously discussed in this "intent to implement" 
thread: 
https://groups.google.com/d/topic/mozilla.dev.platform/_FacI6Aw2BQ/discussion 



Are there now (cross-browser) tests for this feature?


There are a handful of tests now in 
web-platform/tests/css/css-fonts/variations, and there a bunch more 
currently in preparation (e.g. see 
https://bugzilla.mozilla.org/show_bug.cgi?id=1436588).


JK
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: OpenType Variation Font support

[James Graham]

On 19/03/2018 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 preferences.


Other UAs shipping this or intending to ship it include:
   Safari (on macOS 10.13 or later)
   Chrome (and presumably other Blink-based UAs)
   MSEdge (on Windows 10 Fall Creators Update or later)

Bug to turn on by default: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1447163


This feature was previously discussed in this "intent to implement" 
thread: 
https://groups.google.com/d/topic/mozilla.dev.platform/_FacI6Aw2BQ/discussion 


Are there now (cross-browser) tests for this feature?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Use cases for invalid-Unicode atoms

[Henri Sivonen]

On Tue, Mar 20, 2018 at 11:00 AM, smaug  wrote:
> On 03/19/2018 09:30 PM, Kris Maglione wrote:
>>
>> 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 handling of UTF-8 to UTF-16 XPCOM string conversions to be more
>>> secure, so I want to check if I should change things a bit more.
>>>
>>> I can well imagine that the current state is exactly what we want:
>>> Bogosity on the UTF-16 side round-trips and bogus UTF-8 doesn't
>>> normally reach the atom machinery.
>>>
>>> Am I correct in assuming we don't want changes here?
>>>
>>> (One imaginable change would be replacing invalid sequences in both
>>> UTF-16 and UTF-8 with U+FFFD and then atomicizing the result.)
>>
>>
>> Leaving aside the question of whether validation is desirable, I'd worry
>> about the performance impact. We atomize UTF-16 strings all over the place
>> in DOM code (and even have a main-thread pseudo-hashtable optimization for
>> them). Validation might be relatively cheap, but I'd still expect that
>> relative cheapness to add up fairly quickly.
>
>
> Yeah, all the atom handling is very hot code.  Unless there is some actual
> serious bug to fix, I wouldn't
> change the handling.

OK. I'll leave the UTF-16 case unchanged and will make the minimal
changes on the UTF-8 side to retain the existing outward behavior
without burning the tree. Hopefully I can make the UTF-8 case faster
while at it. It depended on not-so-great code.

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Use cases for invalid-Unicode atoms

[smaug]

On 03/19/2018 09:30 PM, Kris Maglione wrote:

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 handling of UTF-8 to UTF-16 XPCOM string conversions to be more
secure, so I want to check if I should change things a bit more.

I can well imagine that the current state is exactly what we want:
Bogosity on the UTF-16 side round-trips and bogus UTF-8 doesn't
normally reach the atom machinery.

Am I correct in assuming we don't want changes here?

(One imaginable change would be replacing invalid sequences in both
UTF-16 and UTF-8 with U+FFFD and then atomicizing the result.)


Leaving aside the question of whether validation is desirable, I'd worry about the performance impact. We atomize UTF-16 strings all over the place in 
DOM code (and even have a main-thread pseudo-hashtable optimization for them). Validation might be relatively cheap, but I'd still expect that 
relative cheapness to add up fairly quickly.


Yeah, all the atom handling is very hot code.  Unless there is some actual 
serious bug to fix, I wouldn't
change the handling.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform