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 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
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 separate things here: > > 1) Is this behavior good for users? > 2) Will people think this behavior is good for users and for them? > (Maybe this should itself be two separate things.) > > Here's how I see this: [snipping all the stuff Boris has saved me from writing] >> I'd like the team to share this in a blog post >> about the experiment > > This seems like a good start, and we may want to then make sure whatever > information we are trying to put out there actually gets picked up by > widely-enough-read news bits so people aren't blindsided. It'd be great if we could write about it in such a compelling way that people get excited about participating in the experiment (BTW I think opt-in is best). This work is important and, if successful, will help us protect people's privacy more effectively. Let's do everything we can to make sure it's a success. 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)
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 users? 2) Will people think this behavior is good for users and for them? (Maybe this should itself be two separate things.) Here's how I see this: * There are some concerns being raised about item 1 (e.g. it may be good for users in the US but less good for users in jurisdictions where the legal obligations of ISPs are qutie different). Have we considered doing the experiment only in some geographies, ones where we can make a particularly strong case for the status quo being user-hostile? * For item 2, fundamentally, we want to avoid people feeling like they are being betrayed when they discover they are part of this experiment. To me that seems like it requires clear messaging that they _are_ part of the experiment. If we tell a nightly user "you are part of a DNS experiment, here are the details, here is how you opt out", that leaves a _very_ different impression from (hypothetically; I haven't checked whether this would be a failure mode of the proposed setup) the nightly user being unable to access some intranet site that they set up /etc/hosts entries for, spending a bunch of time figuring out why, and then discovering that we silently changed how their browser does DNS. In the latter situation people will be predisposed to believe the worst and not listen to any explanations. * Assuming we go forward with this, we should very seriously think about the messaging, both in-product and out-of-product. For example, I would think that we would want this to appear on tech news sites _before_ we start doing the experiment, not after. That gives us a chance to present our case in a non-crisis atmosphere, gives people a heads-up about what they should expect, and is a lot less likely to be perceived as us trying to sneak things in. * A lot of this is about trust; both building trust and destroying it. Fundamentally, for most people (I'd guess nearly all) trust is not a logical decision; it's based on gut reactions. Trying to logically convince people that they should trust us is just not going to work if their instincts are screaming at them not to trust us. That means that even if we're 100% sure something is better for users and even if we have super-convincing arguments for it, we need to seriously think about the way it's messaged (or not) and the resulting impact on trust. It doesn't help that what comes across as reassuring to one person comes across as weaselly information-free double-speak to another I'd like the team to share this in a blog post about the experiment This seems like a good start, and we may want to then make sure whatever information we are trying to put out there actually gets picked up by widely-enough-read news bits so people aren't blindsided. -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)
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
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 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_. In particular, I'd like to argue against Henri Sivonen's rhetorical question, "Why risk upsetting users in this case instead of obtaining consent first?" In today's age of impenetrable licensing agreements, the defaults matter. It's not reasonable for users of the Web to assume the totality of the risks of using the Web, and I think it's critical that Mozilla assume some risk for its users. That's why we should be bold, try things, and figure out if we can move the default to be better for the mass market. (This was one of the points that Mikko Hyppönen emphasized for the security industry in his recent talk to Mozilla.) With regard to this experiment: we have a default right now that has evolved over the last two decades to privilege forces close to the user (ISP, DNS provider). This experiment privileges forces farther away from the user (the DoH provider). The hope, as I see it, is that there will be more robust competition in the market when the DoH provider can be unbundled from the last mile connectivity provider. (We've seen that last mile connectivity providers don't have a lot of competition in many parts of the world.) I am interpreting this as something parallel to VPN providers, where there's a robust market with diversified offerings. Right now, users have two functional choices: ISP-provided DNS or Google's DNS, and both have serious downsides. I think it's 100% Mozilla's role to negotiate privacy-respecting agreements and service contracts -- things that no individual user can arrange at this time. I'm willing to upset some users in order to shift the defaults at scale. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 piece of
e10s technical debt that often trips people up (e.g. bug 1432979, bug
1439406).
I just landed the patch in bug 1436911, which eliminates the entire
mechanism by sending all necessary prefs early.
dom/ipc/ContentPrefs.{h,cpp} have been removed.
Nick
___
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)
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. I strongly suggest we make this experiment opt-in rather than opt-out. You can use various channels to ask people to opt-in this experiment themselves, but making them on by default is not the right thing to do I fear. - Xidorn On Tue, Mar 20, 2018, at 4:08 AM, Selena Deckelmann wrote: > 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 ___ 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 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 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 This sounds great; it's a highly requested feature that's being shipped with a decent amount of synchronization [1] across multiple browser engines. 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 is, are there substantive cases where some systems will have variation font support on other browsers but not Firefox, or substantive features that other implementations will be shipping but we won't? -David [1] At least, it's pretty good synchronization compared to the recent track record in the CSS, fonts, and layout world, though other parts of the platform have somewhat better records here. -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla https://www.mozilla.org/ 𝄂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: PGP signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 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. ___ 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 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 parties, so they might rightly be upset about diverting this information elsewhere without opt-in. > 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. This seems like a great feature when the user is in control of whether to use it. I think it's a problem when we determine that Mozilla has negotiated privacy terms, therefore users are protected by policy and there's no problem. Our review processes show things are fine but some people still get upset. Legal review doesn't cover the spectrum of attitudes that users have. Partly it's that people get upset before they stop to read what policy Mozilla negotiated. Partly it's that people take the position that they want privacy by design where the third party isn't contacted in the first place so whatever the third party has promised is moot. For yet other people, it's just a matter of feeling that they are in control if they opt in but feel they are not in control when Mozilla does these things without prior consent. Why risk upsetting users in this case instead of obtaining consent first? -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 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.) -- 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)
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)
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
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 as "performance feasibility" - but won't the data we get from it assume a performance conclusion based on Cloudflare? (Which we might consider 'best-case'?) And that any other DoH provider would be worse performance, by a factor we don't know? If we ran the backend ourselves, we would know the geo distribution of clients sending us traffic and it seems like we could even measure their latency passively[1]. So we'd have more data than if we used Cloudflare. -tom [0] Not necessary keeping people running the study for a month; but over a month ramping up until we have encompassed 100% of the population. [1] It seems possible to do this since the client's going to be sending us multiple packets, but yea I don't know any tools that would actually do this. On Mon, Mar 19, 2018 at 9:02 AM, Henri Sivonen wrote: > 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 without explicit consent regardless > of intention, nightliness or promises the destination has made. > > Opt-in is the way to go to avoid damaging trust. > > Like I said on the bug: "the way people are known to react this kind > of thing isn't in our power to negotiate". Hence, the intention being > more privacy doesn't mean that if we do this without explicit consent > people won't be outraged. > >> Nightly is an explicitly experimental channel which is part of the reason >> it is the choice for the first validation. > > It's totally reasonable from a user perspective to expect Nightly to > run the latest and potentially buggy code, but it doesn't follow that > it's OK to give Nightly users less control of their privacy. > > FWIW, from the point of view of my expectations as a Nightly user, > this goes against the old "No surprises" privacy language we had. (It > seems that the "No surprises" privacy language has been removed. It's > not good that the new language doesn't make it obvious at a glance > whether Mozilla permits itself to do what's proposed here without > explicit opt in. It think it would be better for Mozilla to > unambiguously promise not to do the kind of thing that's being > proposed here without explicit opt in.) > >> I initiated this thread on dev-platform because imo it is a reasonable >> scope for nightly changes, especially ephemeral flip pref changes, and >> that's why the FYI goes here. Its definitely not a secret. Messaging to a >> larger user base than is impacted invites confusion. Future possible >> changes impacting larger populations or putting things on trains would use >> other, more broadly read communications channels. > > It seems to me that the appropriate messaging would be in-Nightly > messaging asking if the user wants to participate in an experiment > that uses Cloudflare as the DNS provider in place of whatever DNS > provider their system would otherwise use. > > -- > Henri Sivonen > hsivo...@hsivonen.fi > https://hsivonen.fi/ > ___ > 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)
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 without explicit consent regardless of intention, nightliness or promises the destination has made. Opt-in is the way to go to avoid damaging trust. Like I said on the bug: "the way people are known to react this kind of thing isn't in our power to negotiate". Hence, the intention being more privacy doesn't mean that if we do this without explicit consent people won't be outraged. > Nightly is an explicitly experimental channel which is part of the reason > it is the choice for the first validation. It's totally reasonable from a user perspective to expect Nightly to run the latest and potentially buggy code, but it doesn't follow that it's OK to give Nightly users less control of their privacy. FWIW, from the point of view of my expectations as a Nightly user, this goes against the old "No surprises" privacy language we had. (It seems that the "No surprises" privacy language has been removed. It's not good that the new language doesn't make it obvious at a glance whether Mozilla permits itself to do what's proposed here without explicit opt in. It think it would be better for Mozilla to unambiguously promise not to do the kind of thing that's being proposed here without explicit opt in.) > I initiated this thread on dev-platform because imo it is a reasonable > scope for nightly changes, especially ephemeral flip pref changes, and > that's why the FYI goes here. Its definitely not a secret. Messaging to a > larger user base than is impacted invites confusion. Future possible > changes impacting larger populations or putting things on trains would use > other, more broadly read communications channels. It seems to me that the appropriate messaging would be in-Nightly messaging asking if the user wants to participate in an experiment that uses Cloudflare as the DNS provider in place of whatever DNS provider their system would otherwise use. -- 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)
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. We all have different moral compass on what is acceptable and not acceptable. So Mozilla should just propose in this case and let the person decides. -- Karl Dubost, mozilla 💡 Webcompat http://www.la-grange.net/karl/moz ___ 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 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 a third-party, to collect from Nightly users. -- https://annevankesteren.nl/ ___ 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)
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 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 :) On Mon, Mar 19, 2018 at 11:25 AM, Patrick McManus wrote: > 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. > Traditional DNS is a swamp - ignoring that isn't doing our users any > favors. This is obviously not an engineering only driven effort. > > Nightly is an explicitly experimental channel which is part of the reason > it is the choice for the first validation. > > A question came up about geo based DNS and I've got a couple technical > comments about risk mitigation there: > 1] geo dns use is on the wane as TCP anycast approaches work much better > in practice > 2] the granularity of the CDN being used is much finer than the > granularity of most geoDNS resolution which tends to choose between very > big regions (O(~ 1/2 a continent)) so that should continue to work the same. > > I initiated this thread on dev-platform because imo it is a reasonable > scope for nightly changes, especially ephemeral flip pref changes, and > that's why the FYI goes here. Its definitely not a secret. Messaging to a > larger user base than is impacted invites confusion. Future possible > changes impacting larger populations or putting things on trains would use > other, more broadly read communications channels. > > -Patrick > > > > On Mon, Mar 19, 2018 at 9:05 AM, Henri Sivonen wrote: > >> 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 unencrypted traffic and SNI in >> encrypted traffic anyway. (This is a secondary reason.) >> >> > I don't >> > have such an agreement at all with 8.8.8.8 or other publicly provided DNS >> > operators. >> >> Using such resolvers is a decision that the user makes and not a >> decision that Mozilla *silently* makes on their behalf. >> >> > What other precautions or actions can we do to reduce the risk of this >> being >> > perceived as problematic? >> >> I suggested two ways on the bug. >> >> > Would reducing the test population really make it >> > much different? >> >> No. >> >> -- >> Henri Sivonen >> hsivo...@hsivonen.fi >> https://hsivonen.fi/ >> ___ >> 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 ___ 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)
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. Traditional DNS is a swamp - ignoring that isn't doing our users any favors. This is obviously not an engineering only driven effort. Nightly is an explicitly experimental channel which is part of the reason it is the choice for the first validation. A question came up about geo based DNS and I've got a couple technical comments about risk mitigation there: 1] geo dns use is on the wane as TCP anycast approaches work much better in practice 2] the granularity of the CDN being used is much finer than the granularity of most geoDNS resolution which tends to choose between very big regions (O(~ 1/2 a continent)) so that should continue to work the same. I initiated this thread on dev-platform because imo it is a reasonable scope for nightly changes, especially ephemeral flip pref changes, and that's why the FYI goes here. Its definitely not a secret. Messaging to a larger user base than is impacted invites confusion. Future possible changes impacting larger populations or putting things on trains would use other, more broadly read communications channels. -Patrick On Mon, Mar 19, 2018 at 9:05 AM, Henri Sivonen wrote: > 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 unencrypted traffic and SNI in > encrypted traffic anyway. (This is a secondary reason.) > > > I don't > > have such an agreement at all with 8.8.8.8 or other publicly provided DNS > > operators. > > Using such resolvers is a decision that the user makes and not a > decision that Mozilla *silently* makes on their behalf. > > > What other precautions or actions can we do to reduce the risk of this > being > > perceived as problematic? > > I suggested two ways on the bug. > > > Would reducing the test population really make it > > much different? > > No. > > -- > Henri Sivonen > hsivo...@hsivonen.fi > https://hsivonen.fi/ > ___ > 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 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 author stylesheets).
>>
>> This is a pretty widely used mechanism to target styles for Gecko. Would it
>> be possible to disable in non-release for a few releases to sniff out any
>> major layout/compat bustage?
>
> Just for completeness, we did find breakage (see dependencies of that
> bug). I fixed most of those, and Youtube fixed theirs on their side.
>
> All of it was related to @-moz-document url-prefix(), so even though I'd
> still like to eventually get rid of it, for now I've added a pref:
>
> layout.css.moz-document.url-prefix-hack.enabled
>
> which controls whether @-moz-document url-prefix() parses or not.
>
> The intention is that for pre-release builds there's no change (no
> @-moz-document in content at all) since we still want to eventually flip
> that pref, but for release we'll ship:
>
> layout.css.moz-document.content.enabled = false;
> layout.css.moz-document.url-prefix-hack.enabled = true;
>
> That is, pages with @-moz-document url-prefix() { foo } will keep
> working, but not other matching function like regex().
>
> Let me know if there's any concern with doing this.
Oh, missed it, this is tracked in bug 1446470.
>
> -- Emilio
> ___
> 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 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 mechanism to target styles for Gecko. Would it
> be possible to disable in non-release for a few releases to sniff out any
> major layout/compat bustage?
Just for completeness, we did find breakage (see dependencies of that
bug). I fixed most of those, and Youtube fixed theirs on their side.
All of it was related to @-moz-document url-prefix(), so even though I'd
still like to eventually get rid of it, for now I've added a pref:
layout.css.moz-document.url-prefix-hack.enabled
which controls whether @-moz-document url-prefix() parses or not.
The intention is that for pre-release builds there's no change (no
@-moz-document in content at all) since we still want to eventually flip
that pref, but for release we'll ship:
layout.css.moz-document.content.enabled = false;
layout.css.moz-document.url-prefix-hack.enabled = true;
That is, pages with @-moz-document url-prefix() { foo } will keep
working, but not other matching function like regex().
Let me know if there's any concern with doing this.
-- Emilio
___
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 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 mistakes the in the past. It's definitely worth taking a >> little while to consider the implications before throwing the switch. > > Indeed. > > Sending the hostnames the browser accesses to a third party that would > not normally be part of the network activity (regardless of what > policy agreements Mozilla has with them) should be opt-in even if it > makes the study data less representative, even if it's Nightly only > and even if Cloudflare is better than some people's ISPs. Agreed, especially since the experiment as announced is Cloudflare in addition to your ISP. So even if we could say they're better than your ISP, which seems tough on a world-wide scale, that defense won't work here. -- https://annevankesteren.nl/ ___ 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 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 unencrypted traffic and SNI in encrypted traffic anyway. (This is a secondary reason.) > I don't > have such an agreement at all with 8.8.8.8 or other publicly provided DNS > operators. Using such resolvers is a decision that the user makes and not a decision that Mozilla *silently* makes on their behalf. > What other precautions or actions can we do to reduce the risk of this being > perceived as problematic? I suggested two ways on the bug. > Would reducing the test population really make it > much different? No. -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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:
https://w3c.github.io/uievents/#event-type-keydown
https://w3c.github.io/uievents/#event-type-keyup
https://w3c.github.io/uievents/#events-composition-key-events
Before this change, I changed EventUtils.synthesizeComposition() and
EventUtils.synthesizeCompositionChange() to dispatch keydown event and
keyup event if you don't specify |key: {}| or |key: null| explicitly.
https://bugzilla.mozilla.org/show_bug.cgi?id=1446253
So, if you write mochitests to test composition events, this new
behavior is tested automatically (e.g., whether the composition is
accidentally committed by a keydown or keyup event handler).
Some additional info:
Gecko's traditional behavior of keyboard/composition/input events are:
1-1: keydown
1-2: compositionstart
1-3: compositionupdate
1-4: input
1-5: compositionupdate
1-6: input
1-7: compositionupdate
1-8: input
1-9: compositionend
1-10: input
1-11: keyup
This becomes:
2-1: keydown
2-2: compositionstart
2-3: compositionupdate
2-4: input
2-5: keyup
2-6: keydown
2-7: compositionupdate
2-8: input
2-9: keyup
2-10: keydown
2-11: compositionupdate
2-12: input
2-13: compositionend
2-14: input
2-15: keyup
If you want to do nothing during composition with keydown/keyup
listeners, you can do it really easily:
foo.addEventListener("keydown", (e) => {
if (e.isComposing) {
return;
}
// Do anything what you want to do.
});
KeyboardEvent.isComposing is set to true if "keydown" and "keyup" events
are fired between "compositionstart" and "compositionend".
And be aware, if keydown and keyup events are already processed by IME,
their keyCode value is set to 229 (KeyboardEvent.DOM_VK_PROCESSKEY) and
their key value is set to "Process". I call those keyboard events as
"marked as processed by IME". So, you cannot retrieve actual key
information with KeyboardEvent.keyCode nor KeyboardEvent.key. However, I
cannot say which "keydown" and "keyup" events in above example are
marked as "processed by IME" because it depends on native IME's behavior
and OS itself. Typically keydown events (including the one immediately
before compositionstart) are marked as "processed by IME", but keyup
events are not marked as "processed by IME". So, except the "keydown"
event immediately before "compositionstart", using
KeyboardEvent.isComposing is really safer.
Finally, please do NOT use "keydown" events and "keyup" events for doing
something what should be done immediately after every character input.
In such purpose, "input" event is the right event because "keydown"
event and "keyup" event may not be fired even after the bug fix. For
example, if the IME is backend of voice input or handwriting system,
Gecko won't fire "keydown" nor "keyup" event unless OS or IME
synthesizes native key events for backward compatibility. And if native
IME completely consumes native key events before Gecko, Gecko won't fire
those events too.
--
Masayuki Nakano
Software Engineer, Mozilla
___
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 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 you had a chance to choose it (or at least, you feel like you've got the option). > > What other precautions or actions can we do to reduce the risk of this > being perceived as problematic? Would reducing the test population > really make it much different? Reducing the population won't make any difference, unless that population feels they had a choice. If possible, I'd suggest to give maximum publicity to this experiment beforehand, exposing all the good arguments above (and not having it "discovered" after the fact on Reddit or Slashdot, which ensures only the "shady" and possibly baseless edges get told in outrage) and proposing the change with a splash page or something like that, even as the default choice, but not silently pre-enabled. Just my 2 cents. -- G > >> 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 while to consider the implications before throwing the switch. >> >> On Sun, Mar 18, 2018 at 8:39 PM, Dave Townsend >> wrote: >> >>> On Sun, Mar 18, 2018 at 5:27 PM Patrick McManus >>> wrote: >>> Obviously, using a central resolver is the downside to this approach - >>> but its being explored because we believe that using the right resolver can >>> be a net win compared to the disastrous state of unsecured local DNS and privacy and hijacking problems that go on there. Its just a swamp out >>> there (you can of course disable this from about:studies or just by setting >>> your local trr.mode pref to 0 - but this discussion is meaningfully about defaults.) >>> >>> I believe that a good resolver makes all the difference. I'm just >>> concerned >>> about the privacy aspects of this, particularly since we're not really >>> messaging this to users. Is there a reason we need a full 50% of >>> Nightly >>> population to get the data we need here? >>> >>> On that topic I'm interested in what data we expect to get, is it just >>> comparing how the resolver performs from a variety of locations and >>> for a >>> variety of lookups? >>> Is there some mechanism in place for users who's normal DNS resolver >>> intentionally returns different results to global DNS (e.g. for region >>> spoofing etc.)? >>> >>> And in this case the operating agreement with the dns provider is part of making that right choice. For this test that means the operator will not retain for themselves or sell/license/transfer to a third party any PII (including ip addresses and other user identifiers) and will not combine the data it gets from this project with any other data it might have. A small amount of data necessary for troubleshooting the service can be >>> kept at most 24 hrs but that data is limited to name, dns type, a timestamp, a response code, and the CDN node that served it. >>> >>> Not retaining IP addresses is good. Can they perform aggregate >>> tracking of >>> hostname requests, or tie common hostname requests from an origin >>> together >>> somehow? What is our recourse if they break this agreement (the recent >>> Facebook debacle seems likely to make folks jumpy). >>> ___ >>> dev-platform mailing list >>> dev-platform@lists.mozilla.org >>> https://lists.mozilla.org/listinfo/dev-platform >>> >> >> >> >> > -- Giorgio Maone https://maone.net ___ 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 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 while to consider the implications before throwing the switch. Indeed. Sending the hostnames the browser accesses to a third party that would not normally be part of the network activity (regardless of what policy agreements Mozilla has with them) should be opt-in even if it makes the study data less representative, even if it's Nightly only and even if Cloudflare is better than some people's ISPs. -- 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 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 perceived as problematic? Would reducing the test population really make it much different? 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 while to consider the implications before throwing the switch. On Sun, Mar 18, 2018 at 8:39 PM, Dave Townsend wrote: On Sun, Mar 18, 2018 at 5:27 PM Patrick McManus wrote: Obviously, using a central resolver is the downside to this approach - but its being explored because we believe that using the right resolver can be a net win compared to the disastrous state of unsecured local DNS and privacy and hijacking problems that go on there. Its just a swamp out there (you can of course disable this from about:studies or just by setting your local trr.mode pref to 0 - but this discussion is meaningfully about defaults.) I believe that a good resolver makes all the difference. I'm just concerned about the privacy aspects of this, particularly since we're not really messaging this to users. Is there a reason we need a full 50% of Nightly population to get the data we need here? On that topic I'm interested in what data we expect to get, is it just comparing how the resolver performs from a variety of locations and for a variety of lookups? Is there some mechanism in place for users who's normal DNS resolver intentionally returns different results to global DNS (e.g. for region spoofing etc.)? And in this case the operating agreement with the dns provider is part of making that right choice. For this test that means the operator will not retain for themselves or sell/license/transfer to a third party any PII (including ip addresses and other user identifiers) and will not combine the data it gets from this project with any other data it might have. A small amount of data necessary for troubleshooting the service can be kept at most 24 hrs but that data is limited to name, dns type, a timestamp, a response code, and the CDN node that served it. Not retaining IP addresses is good. Can they perform aggregate tracking of hostname requests, or tie common hostname requests from an origin together somehow? What is our recourse if they break this agreement (the recent Facebook debacle seems likely to make folks jumpy). ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- / daniel.haxx.se ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
[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: Session Restore NEW - https://bugzil.la/1445644 - Input data is lost after session restore Firefox: Theme NEW - https://bugzil.la/1445939 - [Linux] The item is not visible while drag and drop it to Overflow Menu (using dark theme) This is available as a Bugzilla bug list as well: https://mzl.la/2FVq49c Regards, Bogdan (:bogdan_maris) Desktop Release QA ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
