Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)
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
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
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)
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)
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
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
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)
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
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
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
Re: Intent to ship: OpenType Variation Font support
On 20/03/2018 10:40, Emilio Cobos Álvarez wrote: 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. Yeah, that's the PR that bug 1436588 relates to. :) Many of the tests there are concerned with the CSS extensions to font-{weight,stretch,style}, which we haven't yet implemented (that's bug 1436048, bug 1436061). (Note that Blink also hasn't fully implemented this, at least judging by testing of Chrome stable: they have done the CSS parsing extensions, but not hooked it up to the rendering side. Maybe that's in Canary by now? Anyhow, just a data point that supports doing a gradual roll-out of the feature, starting with font-variation-settings, which is the most basic piece of support.) I'm hopeful that we can get these extensions ready within the next cycle or two, but in any case I don't think that should block exposing the basic feature. JK ___ 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.
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
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)
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
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
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
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
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
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