Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`

[Tom Ritter]

> > > Example 1: Let’s say touchId is currently set to 0 and no fingers are 
> > > touching the touchpad.  When a finger touches the touchpad, touchId of 
> > > this event would be 1.  As that finger moves around the touchpad, new 
> > > touch events are added with updated coordinates, however, the touchId is 
> > > still 1 to denote that the finger has not been lifted from the touchpad.  
> > > If the finger is released and touches again, the touchId would then be 2.
> > >
> > > Example 2: In the case of multi touch, the first finger that touches the 
> > > touchpad would have a touchId of 1.  The next finger that touches the 
> > > touchpad before the first finger is released would have a touchId of 2.  
> > > If the first touch finger is released and touches again, that touchId 
> > > would be 3.  This way, the application can distinguish between different 
> > > touches that have or haven’t been removed from the touchpad.
> >
> >
> > In this situation, it seems like the actual value of the field doesn't
> > matter, only that it is increasing relative to the last value. So it
> > should be possible to have separate values based on the origin.
> >
> > Not doing so creates a cross-origin tracking and fingerprinting vector.
> >
>
> Thanks for your feedback!
>
> First of all. I am not quite sure I understand the cross-origin tracking 
> mean, the `touchId` will increase when there is a new touch on the touchpad. 
> It is exactly increasing relative to the last value, I would like to know why 
> it would be an issue. We also have some APIs like timestamp that are also 
> increased relative to the last value. If you suggest to separate the value, 
> what is the possible approach?

Any state that is shared and exposed to unrelated origins becomes a
potential vector for either directly tracking or otherwise correlating
a user.  For example:

a) A heavy gamer may rack up a touchid in the millions during a
browser session. When visiting sites a.com and b.com, they see that
one person in particular has a gigantic touchid. They have a good idea
it is the same visitor to both sites.

b) A user leaves a game on a.com and starts a game on b.com. By
comparing timestamps and touchid, the sites are quite certain it is
the same user who left with touchid 400 and appeared with touchid 401.

As far as separating the value; it kind of depends on how you
implement it; but let's say you were going to use a static uint64_t or
something like that.  Instead of heaving a static uint64_t, create a
Dictionary and look up the uint64_t using
the OriginAttrbutes of the top level page.

Also, as Ehsan mentioned, we should change the spec so that touchId is
keyed by the top level domain.

> In our implementation, we will wait until users' first intention like button 
> press, axis movement. Then, Firefox will fire a `gamepadconnected`[1]. Chrome 
> also does the same restriction although the spec doesn't describe this is a 
> must.
>
> Regarding to GamepadPose, we only implement it for VR controllers, we only 
> can start to poll input events once users confirm they wanna enter the VR 
> mode. Then, keep waiting for the first event like button press, axis 
> movement, or pose change. Lastly, we will fire a `gamepadconnected`. Also, 
> once they switch the VR tab to the background, we will close this VR session 
> and don't listen to VR input events any more.

Okay, good, not making this data available until the user activity
engages with the gamepad/VR controller (mostly) assuages my concerns
on this component. My remaining concern is around the sensitivity of
axis movement. If I have my controller on my desk, and I am
typing/bumping it - I am curious if that would cause the controller to
suddenly activate.  I don't think I have a gamepad to test with
though.

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

Re: Upcoming C++ standards meeting in Kona

[Botond Ballo]

For those interested, my blog post about this meeting is now online:

https://botondballo.wordpress.com/2019/03/20/trip-report-c-standards-meeting-in-kona-february-2019/

It's also available on Planet Mozilla.

Cheers,
Botond

On Tue, Feb 12, 2019 at 9:08 PM Botond Ballo  wrote:
>
> Hi everyone!
>
> The next meeting of the C++ Standards Committee (WG21) will be
> February 18-23 in Kona, Hawaii.
>
> The C++20 cycle is starting to wrap up, and the fate of several large
> features is likely to be decided at this meeting. Concepts and Ranges
> have merged at the last meeting, while Coroutines and Contracts are
> continuing to attract controversy. Modules has achieved fairly broad
> implementer consensus, and schedule-wise is largely on track to make
> C++20, but there are concerns about it in the tooling community [1].
> The eventual shape of Reflection (a post-C++20 feature) continues to
> be debated.
>
> If you're curious about the state of C++ standardization, I encourage
> you to check out my blog posts where I summarize each meeting in
> detail (most recent one here [2]), and the list of proposals being
> considered by the committee (new ones since the last meeting can be
> found here [3] and here [4]).
>
> I will be attending this meeting, likely splitting my time between the
> Evolution Working Group (where new language features are discussed at
> the design level), and the EWG Incubator group (where proposals bound
> for Evolution undergo a preliminary round of feedback). As always, if
> there's anything you'd like me to find out for you at the meeting, or
> any feedback you'd like me to communicate, please let me know!
>
> Finally, I encourage you to reach out to me if you're thinking of
> submitting a proposal to the committee. I'm always happy to help with
> formulating and, if necessary, presenting a proposal.
>
> Cheers,
> Botond
>
> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1427r0.pdf
> [2] 
> https://botondballo.wordpress.com/2018/11/30/trip-report-c-standards-meeting-in-san-diego-november-2018/
> [3] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/#mailing2018-11
> [4] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/#mailing2019-01
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`

[dmu]

On Friday, March 15, 2019 at 8:35:41 AM UTC-7, Tom Ritter wrote:
> Thanks for more details on the use case.
> 
> On Wed, Mar 6, 2019 at 1:35 AM  wrote:
> >
> > On Monday, February 25, 2019 at 4:17:29 PM UTC-8, Martin Thomson wrote:
> > > To add to Dan's comments here...
> > >
> > > Assuming that I'm reading this correctly [1], the fingerprinting risks are
> > > pretty extreme here.  In the touch spec, we have a monotonically 
> > > increasing
> > > counter that doesn't appear to be origin-bound in any way.  What is the
> > > purpose of this identifier?  In the light spec, we have full RGB control
> > > over the light.  Does the light change back to a default state when the
> > > origin is no longer the primary input focus?
> > >
> > > Implementing specs of a private GitHub account is fine for the purposes of
> > > getting feedback, but I think that we want a clearer signal that this is 
> > > an
> > > accepted approach before we ship something like this.  When you consider
> > > the potential for security and privacy implications, this is particularly
> > > important.
> > >
> > >
> >
> > Hi Martin,
> >
> > Sorry for reply late.
> > We will restrict theses APIs to secure contexts to help it be more secure. 
> > Regarding to the touchId, the reason we wanna make it monotonically 
> > increasing is order to recognize if fingers have been released after the 
> > last touch. Let me give you two examples.
> >
> > Example 1: Let’s say touchId is currently set to 0 and no fingers are 
> > touching the touchpad.  When a finger touches the touchpad, touchId of this 
> > event would be 1.  As that finger moves around the touchpad, new touch 
> > events are added with updated coordinates, however, the touchId is still 1 
> > to denote that the finger has not been lifted from the touchpad.  If the 
> > finger is released and touches again, the touchId would then be 2.
> >
> > Example 2: In the case of multi touch, the first finger that touches the 
> > touchpad would have a touchId of 1.  The next finger that touches the 
> > touchpad before the first finger is released would have a touchId of 2.  If 
> > the first touch finger is released and touches again, that touchId would be 
> > 3.  This way, the application can distinguish between different touches 
> > that have or haven’t been removed from the touchpad.
> 
> 
> In this situation, it seems like the actual value of the field doesn't
> matter, only that it is increasing relative to the last value. So it
> should be possible to have separate values based on the origin.
> 
> Not doing so creates a cross-origin tracking and fingerprinting vector.
> 

Thanks for your feedback!

First of all. I am not quite sure I understand the cross-origin tracking mean, 
the `touchId` will increase when there is a new touch on the touchpad. It is 
exactly increasing relative to the last value, I would like to know why it 
would be an issue. We also have some APIs like timestamp that are also 
increased relative to the last value. If you suggest to separate the value, 
what is the possible approach?

> 
> > In terms of lightColor,  we would give the default color to [0, 0, 0] if 
> > there is no one set it yet or when it is just plugged in. Then, the 
> > application is allowed to set the controller's lightbar color whenever they 
> > want. I have reached the author and ask him add this description into his 
> > proposal.
> 
> It appears that one can set but cannot read the lightColor, so that's good.
> 
> GamepadPose gives me a lot of concern as well. If I have a gamepad
> resting on my desk, I don't want every website to get a persistent
> identifier about me because of the pose it's resting in.  I think/hope
> that there's something in the main gamepad spec where you can't
> enumerate gamepads until the user has interacted with them, but I
> don't recall for sure.
> 
> I am very opposed to shipping this spec without addressing these concerns.
> 
> -tom

In our implementation, we will wait until users' first intention like button 
press, axis movement. Then, Firefox will fire a `gamepadconnected`[1]. Chrome 
also does the same restriction although the spec doesn't describe this is a 
must.

Regarding to GamepadPose, we only implement it for VR controllers, we only can 
start to poll input events once users confirm they wanna enter the VR mode. 
Then, keep waiting for the first event like button press, axis movement, or 
pose change. Lastly, we will fire a `gamepadconnected`. Also, once they switch 
the VR tab to the background, we will close this VR session and don't listen to 
VR input events any more.


[1] 
https://dxr.mozilla.org/mozilla-central/rev/25398e555020fef80c7b2a06a0d4c667e861cd6f/dom/gamepad/GamepadManager.cpp#425


- Daosheng Mu

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

Re: Using inline variables (C++17) in Gecko

[Marco Castelluccio]

The code coverage build is using GCC 6, if you do a try build don't
forget to
include that too (you'll need to pass the "--full" argument if you are using
mach try fuzzy).

The last time I tried, switching to GCC 7 caused a lot of timeouts
(https://bugzilla.mozilla.org/show_bug.cgi?id=1410217#c5), but I didn't
investigate more.

- Marco.


Il 20/03/19 10:57, Mike Hommey ha scritto:
> Sorry for the late answer. Thanks for prodding me on irc.
>
> On Sat, Feb 23, 2019 at 06:36:39PM -0800, Emilio Cobos Álvarez wrote:
>> Hey,
>>
>> I have a use-case for inline variables, and it's not 100% clear to me
>> how up-to-date is [1], so asking this mailing-list directly.
>>
>> Looks like they're supported from clang 3.9 [2] and gcc 7 [3].
>>
>> We're requiring clang 4.0+ to build already, and IIUC we don't build
>> with MSVC anymore. But looks like we still support gcc 6 (which I guess
>> means I can't use them right now).
>>
>> Is that right? If so, how far are we from requiring gcc 7 to build?
> According to [1], the only main distro that would have a hard time
> _building_ Firefox with such a requirement and that is not EOL is Debian
> 9.
>
> Now, two things that do not appear yet on that table, because I haven't
> added them, is rustc and nasm.
>
> As only the ESR version really has any sort of impact on Debian stable,
> and the next ESR is, afaik, going to be 68, the requirements for rustc
> and nasm for that version are going to be, respectively, (probably) 1.33
> and 2.13. Neither of those is available in Debian 9, so Debian will have
> to backport those anyways. In the process of backporting rustc, they'll
> have to backport a recent llvm too (probably 7, maybe 8), which will
> mechanically bring a newer version of clang. So, with my Debian hat on,
> even if a backport of a more recent version of GCC is not made for ESR68
> (there's precedent on using a "gcc-mozilla" package to build Firefox, so
> that's also a possibility), there's going to be a recent enough version
> of clang to build Firefox (and even then, Debian 9 has clang-4 too).
>
> So... with both my Debian and Mozilla hats on, I think we can reasonably
> bump the requirement to GCC 7.
>
> However, there have been hurdles in the past with GCC 7 on Mozilla CI,
> but IIRC that was related to trying to _ship_ those builds. We still do
> have builds using GCC for various reasons, but we don't ship them, so
> that should be fine. We _do_ have jobs that use a GCC plugin that may
> not be ready to be updated to GCC 7, though.
>
> So, I'd say, change all occurrences of linux64-gcc-6 with linux64-gcc-7
> under taskcluster/ci, change the minimum GCC version supported in
> build/moz.configure/toolchain.configure, and do a try build including
> all the build types you changed the toolchain dependencies of, and see
> how it goes. And file bugs if things don't go well :).
>
> Cheers,
>
> Mike
>
> 1. 
> https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Linux_compatibility_matrix
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using inline variables (C++17) in Gecko

[Mike Hommey]

Sorry for the late answer. Thanks for prodding me on irc.

On Sat, Feb 23, 2019 at 06:36:39PM -0800, Emilio Cobos Álvarez wrote:
> Hey,
> 
> I have a use-case for inline variables, and it's not 100% clear to me
> how up-to-date is [1], so asking this mailing-list directly.
> 
> Looks like they're supported from clang 3.9 [2] and gcc 7 [3].
> 
> We're requiring clang 4.0+ to build already, and IIUC we don't build
> with MSVC anymore. But looks like we still support gcc 6 (which I guess
> means I can't use them right now).
> 
> Is that right? If so, how far are we from requiring gcc 7 to build?

According to [1], the only main distro that would have a hard time
_building_ Firefox with such a requirement and that is not EOL is Debian
9.

Now, two things that do not appear yet on that table, because I haven't
added them, is rustc and nasm.

As only the ESR version really has any sort of impact on Debian stable,
and the next ESR is, afaik, going to be 68, the requirements for rustc
and nasm for that version are going to be, respectively, (probably) 1.33
and 2.13. Neither of those is available in Debian 9, so Debian will have
to backport those anyways. In the process of backporting rustc, they'll
have to backport a recent llvm too (probably 7, maybe 8), which will
mechanically bring a newer version of clang. So, with my Debian hat on,
even if a backport of a more recent version of GCC is not made for ESR68
(there's precedent on using a "gcc-mozilla" package to build Firefox, so
that's also a possibility), there's going to be a recent enough version
of clang to build Firefox (and even then, Debian 9 has clang-4 too).

So... with both my Debian and Mozilla hats on, I think we can reasonably
bump the requirement to GCC 7.

However, there have been hurdles in the past with GCC 7 on Mozilla CI,
but IIRC that was related to trying to _ship_ those builds. We still do
have builds using GCC for various reasons, but we don't ship them, so
that should be fine. We _do_ have jobs that use a GCC plugin that may
not be ready to be updated to GCC 7, though.

So, I'd say, change all occurrences of linux64-gcc-6 with linux64-gcc-7
under taskcluster/ci, change the minimum GCC version supported in
build/moz.configure/toolchain.configure, and do a try build including
all the build types you changed the toolchain dependencies of, and see
how it goes. And file bugs if things don't go well :).

Cheers,

Mike

1. 
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Linux_compatibility_matrix
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: URL classifier classification by default

[Dimi Lee]

I intend to remove nsILoadInfo::LOAD_CLASSIFY_URI[1] in Firefox 68. If a
channel will be classified by the URL classifier is based on the
information in the channel after landing Bug 1522412
.


## Introduction

The URL classifier provides services for phishing protection, flash
blocking, and anti-tracking features to identify channels to block.

Channels need to opt in themselves so they can be classified by the URL
classifier.

In the past, we aimed to ensure that all the channels that need to be
classified are properly configured[2] by manually reviewing each of them,
but that is a huge list[3]. There are channels that haven't been reviewed,
and while at the same time, we added new unclassified channels to the code
base. Those unclassified channels may become loopholes that attackers can
exploit[4] to bypass our protection.

# Proposal

We propose to move from a model where URL classification is opt-in to a
model where it is enforced by default unless a channel opts out or is
deemed to be a critical channel based on simple heuristics. By doing so, we
eliminate the URL classifier bypassing loopholes once and for all.

## How it works

The opt-in model was based on the flag nsILoadInfo::LOAD_CLASSIFY_URI. This
flag is now removed and replaced with a heuristic which exempts channels
from classification.

The idea of the heuristic is:

   1.

   Channels created by non-privileged code should be classified.
   2.

   Top-level document’s channels, if loaded by privileged code (system
   principal), should be classified.
   3.

   Any other channel, created by privileged code, is considered safe.


This is how it looks like in the code


nsCOMPtr loadInfo = aChannel->LoadInfo();

nsContentPolicyType type = loadInfo->GetExternalContentPolicyType();

if (nsContentUtils::IsSystemPrincipal(loadInfo->TriggeringPrincipal()) &&

   nsIContentPolicy::TYPE_DOCUMENT != type) {

   return false;  // Should NOT classify

}

## Risk

A bad/hacked/corrupted safebrowsing database, plus a mistakenly classified
critical channel (this may result from a bug in the exemption rules or
incorrect information being passed into) can cause serious problems. For
example, if the updater channel is classified and blocked by the Safe
Browsing, Firefox can't update itself, and there is no way to recover from
that.

We want to be extremely careful about such scenarios, so to ensure critical
channels are never classified, we have included additional safeguards to
exempt channels from classification prior to applying the exemption rules.

Two safeguards have been added:

1. ServiceRequest, introduced in Bug 1325501
 to ensure channels
that fetch update use conservative TLS setting

2. nsILoadInfo::LOAD_BYPASS_URL_CLASSIFIER, will be added after Bug 1522412
has landed. Critical channels not created via XMLHttpRequest can use this
flag to enforce bypassing classification.

## For module owners

For module owners, if there are any "critical channels" in your component,
we might want to ensure they are not classified by using the method
mentioned above (this is just to add an extra safeguard, without this,
critical channels will still bypass URL classification as long as
everything works as expected).


Here are some criteria to determine if a channel is "critical":

- channels related to an update

- channels may cause security issues if blocked

- channels may prevent the browser to launch if blocked

- channels break basic functionality if blocked

If there is, and it hasn’t been replaced with ServiceRequest, please feel
free to let me know, we can replace it with ServiceRequest or include
nsILoadInfo::LOAD_BYPASS_URL_CLASSIFIER.

Note that right now, any use of the fetch API does not bypass the URL
classifier. If this is a problem, let’s discuss it and find a good way to
support it.

Tracking bugs: bug 1442496


## Follow Up

This is not the end for strengthening protection in the URL classifier. We
will continue to work on:

1. Finding channels that should force bypassing the URL classifier check,
as described in ##Risk, to ensure critical channels are never classified. (bug
1442496 )

2. Adding test cases to cover more loading channel scenarios. It is very
important to make sure all the channels work as expected because as long as
there is a loophole, attackers can use that to bypass our protection. (bug
1532961 )

3. Fixing bugs that we don't use correct origin for the third-party check.
Even if the rule applies to all the channels correctly, classification may
still be skipped due to a bug in the third-party check. (bug 1437626
, bug 1456486
, bug 1408410