Re: Intent to ship: OpenType Variation Font support

2018-03-21 Thread Dominik Röttsches 
Hi Jonathan,

This led me to believe something isn't completely hooked up on
> further experimentation, though, I find that it does work as expected if
> the font is loaded from a @font-face resource with the appropriate
> descriptors. So this seems to be only a limitation for installed fonts?


Yes, this is the reason, currently we do not support variable system fonts
on platforms other than Mac. In your example, it also only works if you
load the font through src: url(), not local() for example. This limitation
is tracked in Chromium issue 792874
. I have
plans to work on this soon.

Dominik
___
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)

2018-03-21 Thread Peter Saint-Andre 
On 3/21/18 9:04 AM, Axel Hecht wrote:
> I have a couple of further questions:
> 
> One is about the legal impact on users. DNS mangling is part of law
> enforcement strategies in many parts of the world (incl Germany). 

Would you mind describing this in more detail? What kind of DNS mangling
do you have in mind? How is the transport method used for DNS resolution
(HTTPS vs. unsecured TCP or UDP) relevant? Why would the end user take
on legal responsibility?

> We
> should restrict this experiment to regions where Mozilla knows that
> there's no legal trouble of using DoH and cloudflare. Circumventing law
> enforcement can get pretty hairy in some regions, I suspect.

Pending your answers to the questions above, I don't see how this is a
matter of circumventing law enforcement (HTTPS is used for just about
everything these days, so resolving DNS queries over HTTPS is simply
another use case).

> The other is a bit more detail on the scope of Mozilla's agreement with
> cloudflare extending the experiment. Does our agreement extend to people
> not using Firefox? 

Are you thinking about other Mozilla applications (say, Lockbox), or
non-Mozilla applications? The scope of the proposed shield study is
Firefox Nightly, so perhaps the agreement is limited to that, but I
don't know.

> What happens to folks that in some weird way are
> stuck with the experiment DoH setup once the experiment ends? 

How would that happen?

> It'd be a
> great pitch if the agreement was that cloudflare offers this service
> with said terms. If they stopped liking the terms, they'd have to shut
> the service down.

Typically, agreements of this kind have clauses that enable either party
to disengage under certain conditions. I'd think that if Mozilla stops
liking the terms, we can stop using their service. Forcing Cloudfare to
stop offering a service seems a bit orthogonal to the proposed shield
study because we can always turn it off in Nightly. What happens after
the study is done is another matter (I don't know if the agreement
extends beyond the scope of this study).

> These questions are really only about the scope, not so much about if we
> should do it.

With appropriate safeguards, we should do what is good for Mozilla users
(including their privacy and security) and the health of the Internet in
general:

https://www.mozilla.org/en-US/about/manifesto/

We think that DNS over HTTPS improves the privacy and security of
Mozilla users (which is why we've been working to implement and deploy
it, and why the proposed shield study is important), so all things being
equal we should do it (IMHO). Of course we should do it in the most
transparent and user-respecting manner possible, but we also need to
keep the broader goal in mind because the existing state of DNS
resolution (and the user information is throws off) is not good. We can
and should do better by our users.

Peter



signature.asc
Description: OpenPGP digital signature
___
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)

2018-03-21 Thread Boris Zbarsky 

On 3/21/18 10:53 AM, tom...@gmail.com wrote:

On Wednesday, March 21, 2018 at 3:30:48 PM UTC+1, Boris Zbarsky wrote:

The point is to gather data on how this behaves in the wild.  If the
study is opt-in, then you have to try to figure out what part of the
effect you're seeing (if any) is just selection effects.


 From my understanding of Patrick's original message, the control in this study isn't 
"the 50% of Nightly users who don't have DoH enabled", but instead the existing 
DNS calls on each and every resolve


Sure.  But the point is that you have to assume that the relationship 
between DoH and the existing DNS calls among the study sample is somehow 
representative of that relationship in the overall userbase, right?



While yes, self-selection bias could still influence the results, it isn't 
obvous to me at least that it would be significant.


My point is that to evaluate whether it's significant one needs to know 
about who is self-selecting into the study and how they differ from the 
people who are not self-selecting.


How would you propose evaluating that?


So this doesn't _need_ to be opt-out, as long as you're willing to not
believe any data it produces.  But then what's the point?


Thats seems like an exageration.


OK, fair.  If we have a large-enough group self-select in and BoH turns 
out to not work well enough for a large enough percentage of it, that 
can be used to place a lower bound on the fraction of users it won't 
work for in general.


But conclusions other than that seem a bit hard to come by...

-Boris

P.S.  There is, of course, the problem that the nightly audience is 
_already_ subject to serious selection effects.


P.P.S. Note that I am not explicitly advocating for this study; just 
presenting an argument for why making sense of opt-in data might be ... 
complicated at best.


___
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)

2018-03-21 Thread Axel Hecht 

I have a couple of further questions:

One is about the legal impact on users. DNS mangling is part of law 
enforcement strategies in many parts of the world (incl Germany). We 
should restrict this experiment to regions where Mozilla knows that 
there's no legal trouble of using DoH and cloudflare. Circumventing law 
enforcement can get pretty hairy in some regions, I suspect.


The other is a bit more detail on the scope of Mozilla's agreement with 
cloudflare extending the experiment. Does our agreement extend to people 
not using Firefox? What happens to folks that in some weird way are 
stuck with the experiment DoH setup once the experiment ends? It'd be a 
great pitch if the agreement was that cloudflare offers this service 
with said terms. If they stopped liking the terms, they'd have to shut 
the service down.


These questions are really only about the scope, not so much about if we 
should do it.


Axel

Am 19.03.18 um 18:08 schrieb Selena Deckelmann:

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 expected
to negotiate on their own with their ISPs/VPN providers for things like
24-hour retention for logs that can be used to create profiles. Today's
default environment (speaking technically wrt lack of encryption and log
storage, 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.

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.
We also want to explain the impact we think this kind work will have on the
privacy of the Internet. I'd like the team to share this in a blog post
about the experiment, and so have started work with them on it. More on
this shortly!

-selena



On Mon, Mar 19, 2018 at 8:16 AM Daniel Stenberg 
wrote:


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 needed for this to hit the trains.

How do we otherwise determine that a DNS server is not safe to replace?
Split horizon DNS is going to cause unexpected failures when users -
particularly enterprise users - try to reach names that aren't public.
That's not just an enterprise thing; this will break my home router in

some

ways as well, though I'm actually totally OK with that in this case :)


I don't think it is possible - with any particularly high degree of
certainty
- to know if a DNS server has been manually configured (or even if the term
itself is easy to define). The system APIs for name lookups typically don't
even expose which DNS server they use, they just resolve host names to
addresses for us.

For TRR, we've instead focused pretty hard on providing a
"retry-algorithm" so
that Firefox can (if asked), retry a failed name resolve or TCP connect
without TRR and then "blacklist" that host for further TRR use for a period
into the future.

For hosts that are TRR-blacklisted this way, we also check the next-level
domain of it in the background to see if we should also blacklist the whole
domain from TRR use. Ie if "www.example.com" fails with TRR, it gets
blacklisted, retried with the native resolver and "example.com" is tested
to
see if the entire domain should be blacklisted.

--

   / daniel.haxx.se
___
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: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

2018-03-21 Thread tomica 
On Wednesday, March 21, 2018 at 3:30:48 PM UTC+1, Boris Zbarsky wrote:
> The point is to gather data on how this behaves in the wild.  If the 
> study is opt-in, then you have to try to figure out what part of the 
> effect you're seeing (if any) is just selection effects.

>From my understanding of Patrick's original message, the control in this study 
>isn't "the 50% of Nightly users who don't have DoH enabled", but instead the 
>existing DNS calls on each and every resolve:

On Saturday, March 17, 2018 at 11:51:02 AM UTC+1, Patrick McManus wrote:
> This initial test is focused on performance feasibility assessment and we
> won't actually be using the DNS data returned from the DoH server (i.e. the
> traditional DNS service is used in parallel and only those answers are used
> - the code calls this shadow mode.) 

While yes, self-selection bias could still influence the results, it isn't 
obvous to me at least that it would be significant.

> So this doesn't _need_ to be opt-out, as long as you're willing to not 
> believe any data it produces.  But then what's the point?

Thats seems like an exageration.


-Tom
___
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)

2018-03-21 Thread Boris Zbarsky 

On 3/21/18 10:02 AM, tom...@gmail.com wrote:
I also don't see any arguments why this *needs* to be opt-out? 


The point is to gather data on how this behaves in the wild.  If the 
study is opt-in, then you have to try to figure out what part of the 
effect you're seeing (if any) is just selection effects.


Controlling for selection effects is possible if you have enough 
information about who is selecting into the study vs not selecting into 
it to see whether there are biases in the study participants.  But doing 
that requires having _way_ more information about the study participants 
than Mozilla has or wants to have.


So this doesn't _need_ to be opt-out, as long as you're willing to not 
believe any data it produces.  But then what's the point?


-Boris
___
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)

2018-03-21 Thread tomica 
On Tuesday, March 20, 2018 at 3:35:48 AM UTC+1, Kris Maglione wrote:
> >Let me add my voice as a person outside the network team who can understand
> >the concerns and _still thinks we should be doing this_.
> 
> I'll second this.
> 
> I think it's reasonable to be concerned about the public reaction to 
> this, but I also think it's worth doing. 

I don't see anyone in this thread arguing against doing this.  I also don't see 
any arguments why this *needs* to be opt-out?  Or even why we can't open a tab 
with details upon enabling it (if it's on by default).

Otherwise, someone should start drafting the next apology.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Use cases for invalid-Unicode atoms

2018-03-21 Thread Henri Sivonen 
> I'll go ahead with doing WHATWG-compliant "with replacement" when
> trying to atomize invalid UTF-8 (which shouldn't happen anyway).

For code archeologists: Don't believe what I said upthread about
non-atomic empty-string atoms. My code reading was evidently wrong
considering that we have test case that shows that the atom returned
for invalid UTF-8 is *the* empty-string atom.

Anyway, currently we assert in debug builds if invalid UTF-8 is
atomized. I'm going to keep it that way but in release builds I'm
going to return an atom that doesn't collapse garbage into nothingness
but into U+FFFD.

-- 
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

2018-03-21 Thread Henri Sivonen 
On Wed, Mar 21, 2018 at 11:40 AM, Anne van Kesteren  wrote:
> On Wed, Mar 21, 2018 at 10:27 AM, Henri Sivonen  wrote:
>>  * A bunch of things atomicize URL components. I'd hope that the URLs
>> were converted from UTF-16 to UTF-8 at some prior point ensuring UTF-8
>> validity, but it's hard to be sure.
>
> At least per the specification all URL components end up with only
> ASCII code points after parsing the URL.

Good point. Thanks.

I'll go ahead with doing WHATWG-compliant "with replacement" when
trying to atomize invalid UTF-8 (which shouldn't happen anyway).

-- 
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)

2018-03-21 Thread Joseph Lorenzo Hall 
+1 (as a Moz fan and privacy expert)

On Tue, Mar 20, 2018 at 2:35 AM, Kris Maglione  wrote:
> 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 third-party.
>>>
>>> I can understand that the intent must be good, and for better privacy,
>>> but
>>> the approach of doing so is not acceptable. Users would think Firefox is
>>> going to just send data to arbitrary third-party without agreement from
>>> them.
>>>
>>> As you can see from the replies, almost all people outside the network
>>> team has expressed concerns about this, which should be considered a
>>> signal
>>> already that how other technical users may feel about this experiment,
>>> and
>>> how technical news would create a title for this.
>>>
>>
>> Let me add my voice as a person outside the network team who can
>> understand
>> the concerns and _still thinks we should be doing this_.
>
>
> I'll second this.
>
> I think it's reasonable to be concerned about the public reaction to this,
> but I also think it's worth doing. The end result of this will almost
> certainly be improved privacy and security for users who have this enabled
> by default, and we can't get to that point without doing a study like this.
>
> I think it's worth the risk of a backlash. But I also think we should do
> what we can to minimize that backlash.
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform



-- 
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: j...@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

CDT's Annual Dinner, Tech Prom, is March 29, 2018. Don't miss the tech
event of the year!
Reserve a table today.: https://cdt.org/annual-dinner/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: OpenType Variation Font support

2018-03-21 Thread Jonathan Kew 

On 21/03/2018 08:03, dr...@chromium.org wrote:


font-{weight,stretch,style} are parsed and hooked up to the variable fonts 
rasterization backend since we initially shipped OpenType Variations in M62. I 
implemented this in Blink, so if you are observing any issues, mind sharing 
them? I'd be happy to take a look.


Hi Dominik,

Thanks for the note - that's interesting. Maybe I'm missing something?

Simple testcase (requires Avenir Next Variable installed):




body { font-family: Avenir Next Variable; font-size: 24px; }



for (i = 400; i <= 700; i += 50) {
  e = document.createElement("div");
  e.textContent = "font-weight " + i;
  e.style.fontWeight = i;
  document.body.appendChild(e);
  e = document.createElement("div");
  e.textContent = "variation wght " + i;
  e.style.fontVariationSettings = "'wght' " + i;
  document.body.appendChild(e);
}


When I view this with Chrome, I see the expected range of weights for 
the elements that use font-variation-settings. But those using 
font-weight are all rendered with the default weight of Avenir, just 
with a slight (and constant) synthetic-bold effect applied at 
font-weight:550 and higher.


This led me to believe something isn't completely hooked up on 
further experimentation, though, I find that it does work as expected if 
the font is loaded from a @font-face resource with the appropriate 
descriptors. So this seems to be only a limitation for installed fonts?


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

Re: Use cases for invalid-Unicode atoms

2018-03-21 Thread Anne van Kesteren 
On Wed, Mar 21, 2018 at 10:27 AM, Henri Sivonen  wrote:
>  * A bunch of things atomicize URL components. I'd hope that the URLs
> were converted from UTF-16 to UTF-8 at some prior point ensuring UTF-8
> validity, but it's hard to be sure.

At least per the specification all URL components end up with only
ASCII code points after parsing the URL. I think we match that these
days, though for UI purposes we go back to Unicode at times. I don't
think we convert to Unicode if the percent-encoded sequences are not
valid UTF-8 byte sequences though.


> To the extent these are used for
> security checks, having NaN atoms that match nothing could be safer
> than having different inputs yield the same U+FFFD sequences to make
> them match.
>
> The query string can introduce invalid UTF-8 into a URL, but I believe
> we never do security checks based on query part. I believe we're
> supposed to be doing security checks on the scheme (always ASCII),
> port (number) and the Punycode form of the host (always ASCII). Is
> this true?

We do some important checks on other parts (e.g., what service worker
to use depends on the path), but again, I'd assume those are all full
ASCII comparisons.


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

Re: Use cases for invalid-Unicode atoms

2018-03-21 Thread Henri Sivonen 
On Tue, Mar 20, 2018 at 8:22 PM, Steve Fink  wrote:
> 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?

So it seems from reading the code.

> 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'm quite a bit more worried about the case of using the string value
of the atom than about comparing them. These kind of NaN atoms yield
the empty string as the string value, so if you atomicize an invalid
UTF-8 string and then obtain the string value from the atom, the
errors have collapsed into nothingness. While I don't have an idea how
to exploit this given how atoms are used in Gecko, this general
behavior is known-bad on the level that it's called out in the Unicode
Security Considerations:
https://www.unicode.org/reports/tr36/#Substituting_for_Ill_Formed_Subsequences
.

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

What I'm proposing is equivalent to converting the UTF-8 string to
UTF-16 "with replacement" (in the WHATWG sense) and then atomicizing
the UTF-16 string. AFAICT, the main user of atomicizing by UTF-8 is
the new style system, which has already performed the equivalent
substitution.

Looking at the other callers:
 * One case uselessly atomicizes by UTF-8, considering that it had a
UTF-16 string available a couple of lines earlier.
 * One case uses a contract ID as input, so the input is internal anyway.
 * Some uses are language atoms, where it would be fine to have U+FFFD
in bogus atoms, since they don't match anything useful anyway.
 * A bunch of things atomicize URL components. I'd hope that the URLs
were converted from UTF-16 to UTF-8 at some prior point ensuring UTF-8
validity, but it's hard to be sure. To the extent these are used for
security checks, having NaN atoms that match nothing could be safer
than having different inputs yield the same U+FFFD sequences to make
them match.

The query string can introduce invalid UTF-8 into a URL, but I believe
we never do security checks based on query part. I believe we're
supposed to be doing security checks on the scheme (always ASCII),
port (number) and the Punycode form of the host (always ASCII). Is
this true?

-- 
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

2018-03-21 Thread drott 
Hi Jonathan,

On Tuesday, March 20, 2018 at 1:16:42 PM UTC+2, Jonathan Kew wrote:

> (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.)

font-{weight,stretch,style} are parsed and hooked up to the variable fonts 
rasterization backend since we initially shipped OpenType Variations in M62. I 
implemented this in Blink, so if you are observing any issues, mind sharing 
them? I'd be happy to take a look.

We do ship our own FreeType on Linux and Android, so we have support for 
Variations there independent of system FreeType. On Windows, it's done through 
FreeType and available everywhere. On Mac we use FreeType for Mac OS < 10.12.

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