Re: Enabled CRLite in Nightly

[Martin Thomson]

Great news JC.

I've been watching this with interest.  It's one of those rare cases
where we get a win-win-win.  Faster page loads, better security
through more reliable revocation information, and better privacy.

It's taken a lot of effort, but it's definitely worth it.

On Thu, Nov 12, 2020 at 8:08 AM J.C. Jones  wrote:
>
> CRLite ships compressed revocation information for the public Web to
> Firefox users, four times a day. We have a blogpost series on CRLite at the
> Security Blog  (with another
> post coming later this month), there’s additional information at Github
> , and for the Gecko-side, a meta-bug
> .
>
> We’ve been collecting telemetry on how much CRLite can speed up first TLS
> connections
> 
> all year. Since August, we’ve been publishing the datasets consistently
> four times per day, with “stashes” (delta updates) averaging about 66 kB. (
> https://github.com/mozilla/crlite/wiki#how-can-i-access-statistics-about-the-available-filters
> )
>
> If you’d like to poke around inside the filter data, see
> https://github.com/mozilla/crlite/wiki#how-can-i-query-my-crlite-filter
>
> Nightly is now preferring CRLite  for
> revocation information, meaning fresh TLS connections will skip OCSP when
> CRLite can substitute. (e.g., we set security.pki.crlite_mode to 2,
> “Enforce”). We expect to see improvement in the SSL_TIME_UNTIL_READY
> telemetry: it’s mostly expected to speed up the outliers in the graph,
> since revocation checks get cached, and it is likely to have the largest
> effects for Firefox users with slower network connections.
>
> We don’t expect breakage from this change, as we’ve grown fairly confident
> in the dataset, but this is going to remain in Nightly for now.
>
> After this speed-up testing, our likely next step is to add telemetry to
> compare live OCSP results against CRLite’s results for outlier-accuracy
> (encountering revocations is rare, so care is needed). We’ll ultimately run
> both the accuracy and the speedup tests in early Beta as well.
>
> We’ll develop Release-path plans based on early Beta testing and telemetry.
>
> For more information, come see us in #crlite in Slack or #crlite:mozilla.org
> on Matrix
> 
> .
>
> - J.C. on behalf of Mozilla Crypto Engineering
> ___
> 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: backdrop-filter

[Martin Thomson]

On Wed, Jun 10, 2020 at 8:01 AM L. David Baron  wrote:
> It's also something that I think we shouldn't be doing, at least not
> without a clear and relatively short timeline for having the feature
> available across all graphics backends (whether by implementing it
> for more backends or by no longer shipping those backends).

I agree with David's reasoning here about this being potentially
harmful, but I do recognize the value of prototyping or experimenting.
This doesn't seem to be either of those though.

To that end, is there a plan for making this capability uniformly available?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: AVIF (AV1 Image Format) support

[Martin Thomson]

This sounds good.  In the interests of transparency, it might be good to
get this (and AV1 even) added to our standards positions repo (
https://mozilla.github.io/standards-positions/).  I don't know if this
necessarily rises to "important" in the same way that AV1 does, but it
would be good to have a clear signal from us that other browsers can use in
their decision making.

On Thu, Jan 16, 2020 at 5:27 AM Jon Bauman  wrote:

> AVIF is an image format based on the AV1 video codec [1] from the Alliance
> for Open Media [2]. AV1 support shipped in release 55 [3] and is currently
> supported in Chrome, but not Safari. There is an open issue for AVIF
> support in Chrome [4].
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=avif
>
> Standard: https://aomediacodec.github.io/av1-avif/
>
> Platform coverage: All
>
> Restricted to secure contexts: No. There's currently no mechanism to
> enforce this for image formats, but we can revisit this before enabling
> this by default. The same goes for CORS.
>
> Target Release: 76
>
> Preference behind which this will be implemented: image.avif.enabled,
> turned off by default.
>
> [1] https://en.wikipedia.org/wiki/AV1
> [2] https://aomedia.org/
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=av1
> [4] https://bugs.chromium.org/p/chromium/issues/detail?id=960620
> ___
> 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: Proposed W3C Charter: Service Workers Working Group

[Martin Thomson]

I agree with this assessment.  Maintaining accountability when sites don't
have a window to attribute activity to is a recurrent issue that this group
has never properly resolved.  Asking for permission seems to be the defense
of choice, but that only prevents the initiation of unaccountable
activities.

We grappled with the same with push and I don't know that we ever
satisfactorily addressed it, though our limitations on background activity
without notifications at least encourages a degree of visibility.


On Fri, Dec 6, 2019 at 5:08 AM Anne van Kesteren  wrote:

> On Tue, Dec 3, 2019 at 3:58 PM L. David Baron  wrote:
> > The W3C is proposing a revised charter for:
> >
> >   Service Workers Working Group
> >   https://www.w3.org/2019/11/proposed-sw-wg-charter-2019.html
> >   https://lists.w3.org/Archives/Public/public-new-work/2019Nov/0004.html
>
> A couple of us looked at Background Sync and thus far have not been
> able to come up with a way to get informed consent from users for
> executing scripts in the background in a way that is non-intrusive and
> doesn't lead to abuse. Given that, I think Mozilla should object to it
> being in the charter. Background Fetch has a similar issue, but
> (thanks to Youenn Fablet for the insight) there might be a way to
> salvage that, by running the "fetches completed" script on next visit.
> This might require some API changes though so hopefully the charter
> can indicate that somehow. (Bikeshed: Background Downloads.)
>
> (The description for Service Workers, "This specification defines an
> API to enable applications to take advantage of persistent background
> processing.", also seems wrong or perhaps multiple uses of
> "background" are used in the same text, but development of SW remains
> important of course.)
> ___
> 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: TLS 1.0 and TLS 1.1

[Martin Thomson]

On Fri, Dec 6, 2019 at 5:08 AM  wrote:

> >> … Safari, Firefox, Edge and Chrome are removing support for TLS 1.0 and
> 1.1 in March of 2020. …
>
> Is that (timeline) still a _shared_ intent – for all four browsers?
>

I recently confirmed this, yes.


> Re: the screenshot at <
> https://user-images.githubusercontent.com/192271/70135931-e7e00800-1682-11ea-84f7-de2c397fa5eb.png>
> I do like how things are shaping up in Firefox 71.0 with
> security.tls.version.min set (or preset) to 3.
>

The intent is to have that dialog to disappear some time after March next
year or for the exceptions to be more narrowly targeted.  Re-enabling TLS
1.0 will still be possible via about:config for some time after that, so
people with a real need can always turn it back on if they need to
(including through enterprise policy if corporate services are stuck).
That's still inadvisable; ultimately, we'd like to ensure that TLS 1.2 or
higher is always used.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: DTLS 1.0 for WebRTC

[Martin Thomson]

This is somewhat more aggressive than our plans for HTTPS.  The usage rate
is significantly higher (that's about 3x) and we don't have DTLS 1.3 yet,
though the spec is now close to publication.

On balance, this is still justifiable given the nature of this feature.

On Fri, Nov 8, 2019 at 5:29 PM Nils Ohlmeier  wrote:

> With the intent to unship TLS 1.0 and 1.1
> https://groups.google.com/forum/#!topic/mozilla.dev.platform/8EFRYDR3N1c <
> https://groups.google.com/forum/#!topic/mozilla.dev.platform/8EFRYDR3N1c>
> we don’t want to leave Firefox users left with the old DTLS 1.0 when using
> WebRTC.
>
> The latest draft on WebRTC security architecture (which soon going to be
> published as an RFC) requires all implementations to support DTLS 1.2
> https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-20#section-6.5
> <
> https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-20#section-6.5
> >
>
> In Firefox 71 we landed user prefs which enables developers to test their
> WebRTC services with DTLS 1.2 only.
>
> Chrome has announced to also turn off DTLS 1.0 for WebRTC in M81
> https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topicsearchin/discuss-webrtc/dtls;context-place=searchin/discuss-webrtc/PSA$3A/discuss-webrtc/Dsq_14_WoUk
> <
> https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topicsearchin/discuss-webrtc/dtls;context-place=searchin/discuss-webrtc/PSA$3A/discuss-webrtc/Dsq_14_WoUk
> >
>
> Last time when we measured DTLS 1.0 usage was 1.88% in Firefox 68 Beta
> https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2019-06-18&include_spill=0&keys=__none__!__none__!__none__&max_channel_version=beta%252F67&measure=WEBRTC_DTLS_PROTOCOL_VERSION&min_channel_version=null&processType=*&product=Firefox&sanitize=0&sort_by_value=0&sort_keys=submissions&start_date=2019-03-10&table=0&trim=0&use_submission_date=0
> <
> https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2019-06-18&include_spill=0&keys=__none__!__none__!__none__&max_channel_version=beta%2F67&measure=WEBRTC_DTLS_PROTOCOL_VERSION&min_channel_version=null&processType=*&product=Firefox&sanitize=0&sort_by_value=0&sort_keys=submissions&start_date=2019-03-10&table=0&trim=0&use_submission_date=0
> >
>
> We want to disable DTLS 1.0 in WebRTC together with TLS 1.0 and 1.1 in
> March 2020.
>
> Disabling DTLS 1.0 is tracked at
> https://bugzilla.mozilla.org/show_bug.cgi?id=1506392 <
> https://bugzilla.mozilla.org/show_bug.cgi?id=1506392>
>
> Best
>   Nils Ohlmeier
>
> ___
> 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: TLS 1.0 and TLS 1.1

[Martin Thomson]

On Sun, Oct 6, 2019 at 6:35 PM  wrote:

> I would agree that these changes and changes that have already occurred
> over the last year or so, have broken access to admin consoles of older
> networking kit. I had to pull a WinXP machine out of storage recently to
> manage an HP 2610 switch.
>

For the foreseeable future, we will retain the pref
(security.tls.version.min, accessible through about:config) that will allow
individual overrides for this default configuration.  I expect that we will
eventually remove this capability and you will have to go searching for
insecure software so that you can do insecure things.  I appreciate the
pain this causes, but the fact is that the Internet is a sufficiently
hostile environment that all devices connected to it really do need an
up-to-date version of important software, especially networking software.

Ultimately, there isn't a good distinction between devices that are on the
(big "I") Internet and devices that are on (private) networks. For
instance, we don't want to have airport or coffee shop WiFi being able to
access the sorts of exceptions we create for your home network.

If this is sufficiently widespread, we might look into what it would take
to build in some way to override on a per-host basis or carve out
exceptions for private numbering spaces, but we need to be very careful
about opening avenues for attack.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: WebIDL Reviewers Group

[Martin Thomson]

Hi Nika, this is great.  Is there a documented process for setting up and
maintaining the alias?

On Sat, Sep 21, 2019 at 1:37 AM Nika Layzell  wrote:

> As of yesterday, a phabricator reviewers group for WebIDL has been created.
> If your patch needs review for WebIDL changes, you can tag this group using
> '*r=#webidl*'.
>
> Once specific DOM peer(s) are working with you on a web standard, you
> should continue to reach out to them for reviews as the standard evolves.
>
> We're testing this out, and hope this will more evenly spread review load
> and make it easier to find a peer :-)
> ___
> 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: TLS 1.0 and TLS 1.1

[Martin Thomson]

On Thu, Sep 12, 2019 at 5:50 PM Henri Sivonen  wrote:

> Do we know what the situation looks like for connections to RFC 1918
> addresses?
>

That's a hard one to even speculate about, and that's all we really have
there.  Our telemetry doesn't really allow us to gain insight into that.
The big question being enterprise uses, where there is some chance of
having names on servers in private address space.  Most use of 1918 outside
of enterprise is likely still unsecured entirely.


> What expectations are there for being able to remove the code from NSS?
>

Pretty low in any reasonable time frame.  The use of new NSS releases in
old versions of RHEL and their very long support cycles means that Red Hat
are reluctant to have code removed.  We still have SSLv3 code hanging
around and will likely have that for a few more years.

That said, there is a lot of shared code between SSLv3, TLS 1.0, TLS 1.1,
and TLS 1.2.  There isn't a whole lot to gain from trying to take any one
of those versions out of the code, because there isn't that much to remove.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: TLS 1.0 and TLS 1.1

[Martin Thomson]

(We’ve had a couple of blog postings about this [1][2], but this list
hasn’t received an explicit intent notice.  Now that we’re starting to make
changes, it seems like a good time to correct that oversight.)

TLS 1.0 and 1.1 are old.  They are also broken in myriad subtle ways. [3]
explains in more detail.

Disabling TLS 1.0 and 1.1 is part of an agreement we have negotiated with
other browsers.  We have agreed with Apple, Google, and Microsoft to
disable this version in March 2020. Safari Tech Preview has already made
this change [4].

We have been measuring the impact of this change at [5], which shows steady
progress from sites.  Telemetry shows that TLS 1.0 usage is much higher
than we would ordinarily tolerate for this sort of deprecation [6], but we
are confident in the commitment that other browsers have made. The trend in
both measurements supports the view that the number of sites that will be
affected is reducing steadily [7].

The first step on this path landed in Firefox 68.  That was to show a
warning in developer tools.

The step we’re about to take disables TLS 1.0 and 1.1 in Nightly.  The plan
is to do that in the Firefox 71 cycle. Bug 1579270 tracks this change.

After that we plan to start progressively disabling TLS 1.0 and 1.1 in Beta
as that Firefox 71 and subsequent versions are deployed.  This will likely
start by making the change for a very small percentage of people using
Beta, then increasing as we gather feedback. The idea is to have all of
Beta switched over ahead of March.

Finally, we will disable TLS 1.0 and 1.1 for all people using the Release
channel of Firefox in March 2020.  Exact plans for how and when this will
happen are not yet settled.

Bug 1579285 is tracking updates to the SSL_ERROR_UNSUPPORTED_VERSION error
page that we expect will get more use.  That page currently offers to reset
preferences. We are considering offer the option to re-enable old TLS
versions.  However, we would remove that capability in a build that will go
to Release in or shortly after March.

Independent of this, WebRTC uses DTLS, which has a similar story. DTLS 1.0
is effectively TLS 1.1.  However, WebRTC has higher DTLS 1.0 usage rates
[8]. The WebRTC team are considering disabling support for DTLS 1.0 at the
same time, but might defer that decision.

This is a potentially disruptive change, but we believe that this is good
for the security and stability of the web.

---

[1]
https://blog.mozilla.org/security/2018/10/15/removing-old-versions-of-tls/

[2] https://hacks.mozilla.org/2019/05/tls-1-0-and-1-1-removal-update/

[3] https://tools.ietf.org/html/draft-ietf-tls-oldversions-deprecate-05

[4]
https://webkit.org/blog/9526/release-notes-for-safari-technology-preview-91/

[5] The second graph at
http://tlscanary-plot-8e95d89854d73f4d.elb.us-west-2.amazonaws.com/ ;
ignore the jump prior to May, that’s the result of a methodology change to
switch the list of sites that are scanned.

[6] https://sql.telemetry.mozilla.org/queries/64283#164115 shows values for
Release, which puts TLS 1.0 between 0.46% and 0.68% depending on the time
of week.  TLS 1.1 is virtually non-existent at 0.02%, we could have removed
that already if it weren’t for the fact that this isn’t how TLS version
negotiation works.

[7] ibid. In October last year, TLS 1.0 was in the range of 0.65% to 1%.
[8] https://mzl.la/2ZIHK55
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Implement- Double-keyed HTTP cache

[Martin Thomson]

Hi Sebastian,

I'm glad to see us moving toward having better isolation in this way.

In discussions of this sort of keying strategy, the guidance I repeatedly
hear is that "double-keying" isn't sufficient and that you need to key on
the chain of origins.  That is, if A frames B and C, and B in turn also
frames C, then the two C frames are isolated from each other in the same
way that they are isolated from a top-level C.

I took a look at both the fetch issue and your patch and it wasn't clear
what strategy we're using.  As an aside, an issue on a repo isn't really a
specification.  I couldn't find a PR on fetch either.

What is the tuple we're keying on?

Cheers,
Martin

On Thu, Aug 22, 2019 at 3:40 AM Sebastian Streich 
wrote:

> Intent to Implement- Double-keyed HTTP cache
>
>
> Summary:
>
> Currently Browsers are vulnerable to cache-timing attacks, commonly
> referred to as XS Leaks attacks. Starting with Firefox 70 we want to
> explore a double-keyed HTTP cache. Instead of solely using the origin of
> the resource, we will double key the HTTP Cache using the top-level origin.
> Using the top-level origin as the 2nd Key in the HTTP Cache allows to
> counterfeit XS Leaks and eliminates the ability of checking cache contents
> across Origins.
>
> Bug:  Bugzilla 1536058
> 
>
> Standard: https://github.com/whatwg/fetch/issues/904
>
> Platform coverage: all platforms
>
> Estimated or target release: Firefox 70
>
> Preference: The feature will be pref'd behind
> “browser.cache.cache_isolation”
>
>  and disabled by default.
>
> Other browsers:
>
> webkit: shipped
>
> Chrome :
> implementing
>
> web-platform-tests: 
>
> Secure contexts:  This feature isn’t restricted to Secure Contexts.
> Estimated or target release: Firefox 70
> ___
> 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: restrict access to request notification permissions from cross-origin iframes

[Martin Thomson]

This is a great move for improving transparency and accountability of
sites. Good work to all those who helped get us this far.

On Sat, 10 Aug. 2019, 01:02 Ehsan Akhgari,  wrote:

> Hi everyone,
>
> We currently allow cross-origin iframes to request notification
> permissions.  This is problematic because we'd like to move to a model
> where permissions are only requested for the top-level document’s origin in
> order to show non-address-bar origins as little to the user as possible.
> Therefore, in Firefox 70 I plan to land a change in bug 1560741[1] to deny
> such permission requests without showing a prompt.
>
> Chrome has announced this change over 2 years ago[2], but have yet to ship
> it.  Our telemetry for beta 68 shows that cross-origin use of this feature
> has very low usage[3] at around 0.02% of notification requests.
>
> We’ll also log a warning in the web console when denying the permission
> request because of this reason.
>
> Please let me know if you have any questions or concerns.
>
> Thanks,
> Ehsan
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1560741
> [2]
>
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/n37ij1E_1aY
> [3] https://mzl.la/2Mafa6q
> ___
> 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 implement and ship: Gamepad Extensions `multi touch` and `light indicator`

[Martin Thomson]

On Thu, Mar 21, 2019 at 1:11 PM Tom Ritter  wrote:

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

There's a research question that suggests: gamepad accelerometers are
pretty good, can they be used to recover what someone is typing based on
those vibrations?  Setting a minimum activation threshold to start using
the controller might be wise.  A button press is guaranteed to activate it,
so we can be a little less sensitive for that.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Dynamic module imports (JS 'import()' syntax)

[Martin Thomson]

Thanks.  (And ugh, but that's how these things go.)

On Fri, Mar 8, 2019 at 2:40 PM Boris Zbarsky  wrote:

> On 3/7/19 10:27 PM, Martin Thomson wrote:
> > Is there a way that doesn't rely on eval or eval-like mechanisms?
>
> I suspect the only detectable thing here (and Jon might wake up tomorrow
> and tell me I'm wrong!) is that import('stuff') is a syntax error
> without the support but is not a syntax error otherwise.
>
> That means you need to trigger at least a new parse of some JS that you
> control to run the detection.
>
> Now you could probably manage this with something like (using non-inline
> scripts for all this stuff):
>
>
>  var oldError = window.onerror;
>  window.onerror = function(...args) {
>/* check for syntax error */
>  }
>
>function() { import(''); }
>window.onerror = oldError;
>
> or so.
>
> -Boris
> ___
> 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: Dynamic module imports (JS 'import()' syntax)

[Martin Thomson]

Is there a way that doesn't rely on eval or eval-like mechanisms?

On Fri, Mar 8, 2019 at 1:55 PM Boris Zbarsky  wrote:

> On 3/7/19 6:14 PM, rekt...@gmail.com wrote:
> > Is there any way to feature detect support for import() syntax?
>
> In Firefox, yes, as far as I can tell:
>
>try {
>  new Function("import('')");
>  // supported
>} catch (e) {
>  // not supported
>}
>
> -Boris
> ___
> 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 implement and ship: Gamepad Extensions `multi touch` and `light indicator`

[Martin Thomson]

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.



On Tue, Feb 26, 2019 at 11:08 AM Daosheng Mu  wrote:

> Hi Daniel,
>
> We didn't have a chance to discuss privacy issues in Gamepad Extension or
> Gamepad API. We were trying to get responses for the Privacy review [1] but
> without any updates yet.
>
> Cheers,
>
> [1]
> https://lists.w3.org/Archives/Public/public-privacy/2018AprJun/0030.html
>
> --
> Daosheng Mu
> Software Engineer | Mozilla
> d...@mozilla.com
>
>
> On Mon, Feb 25, 2019 at 2:47 PM Daniel Veditz  wrote:
>
> > Neither of the words "security" or "privacy" appear in this spec (most w3
> > web specs have at least a token attempt at a "Privacy and Security
> > Considerations" section). At a surface glance this appears to add
> > additional fingerprinting exposure. Have you talked to the privacy team
> > about ways to minimize this?
> >
> > -Dan Veditz
> >
> > On Mon, Feb 25, 2019 at 11:45 AM Daosheng Mu  wrote:
> >
> >> Summary:
> >> In order to support controllers which have multi touch and light bar
> >> features like Sony DualShock 4. The `*multi touch*` and `*light
> >> indicator*`
> >> APIs for gamepad extensions are the things we must have. In
> >> `*GamepadTouch*`
> >> API, it would make us know touch surface's dimension and its unique id.
> We
> >> also will have a way to know where is the place we are touching
> according
> >> to its position and the unique id. Regarding to
> `*GamepadLightIndicator*`,
> >> it could tell users the color of controller's light bar. The color is a
> >> 8-bit size integer for defining `*red*`, `*green*`, `*blue*`, or other
> >> colors to indicate the on-off light indicator is ON.
> >>
> >> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1523350
> >>
> >> Link to standard:
> >> W3C Multi touch spec proposal:
> >> https://github.com/knyg/gamepad/blob/multitouch/extensions.html
> >> W3C Light indicator spec proposal:
> >> https://github.com/knyg/gamepad/blob/lightindicator/extensions.html
> >>
> >> Platform coverage: Windows, Mac OS, Linux
> >>
> >> Estimated or target release: Firefox 68
> >>
> >> Preference behind which this will be implemented:
> >> "dom.gamepad.extensions.multitouch" and
> >> "dom.gamepad.extensions.lightindicator"
> >>
> >> Do other browser engines implement this? Nope
> >>
> >> web-platform-tests: none exist (and I don't plan to write WPTs but we do
> >> have gamepad mochitest, I will add new tests to cover these two new
> APIs.)
> >>
> >> Is this feature restricted to secure contexts? Nope
> >>
> >> How stable is the spec? This is a proposal from a vendor, I suppose it
> >> would be some minor adjustments coming when other developers start to
> >> implement it. I would suggest to make it pref'd off by default until
> this
> >> proposal be merged to w3c's branch.
> >>
> >>
> >> --
> >> Daosheng Mu
> >> Software Engineer | Mozilla
> >> d...@mozilla.com
> >> ___
> >> 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 require Secure Context for Web Notifications

[Martin Thomson]

Thanks for doing this Johann.

On Tue, Feb 26, 2019 at 12:31 AM Johann Hofmann 
wrote:

> The Notifications API [0] allows websites to show notifications outside of
> the browser viewport, integrating into the native OS-like notification
> system. In combination with service workers this can be used to send push
> notifications that work even when the website is not opened. While the
> latter has always required secure context [1], the plain Notifications API
> in Firefox has been available to sites loaded over insecure connections so
> far.
>
> Notifications is a powerful feature that should not be exposed to websites
> over HTTP and we intend to deny permission requests for Notifications that
> were not made in secure contexts from Firefox 67. This supports our general
> policy that already made us disallow geolocation on insecure contexts [2].
>
> Blink shipped this change over a year ago:
>
>
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/IVgkxkRNtMo/discussion
>
> Around 2% of notification permission requests are currently done over HTTP
> in Firefox Beta 65 [3]. The resulting breakage should, in many cases, not
> affect the overall website functionality.
>
> I plan to make this change in bug 1429432 [4] and let it ride the trains
> targeting Firefox 67. Instead of restricting the
> Notification.requestPermission API via [SecureContext] attribute, we will
> follow the pattern established by other browsers and deny the permission
> without asking the user. We will also log a warning to the developer
> console, similar to the geolocation one.
>
> Standardization is tracked in
> https://github.com/whatwg/notifications/issues/93.
>
> Thanks,
>
> Johann
>
> [0] https://notifications.spec.whatwg.org/
>
> [1] https://www.w3.org/TR/secure-contexts/
>
> [2]
> https://groups.google.com/forum/#!topic/mozilla.dev.platform/BvcsTpAqIsQ
>
> [3] https://mzl.la/2H2dJmW
> [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1429432
> ___
> 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: Cookie policy/permission in live documents - proposal

[Martin Thomson]

Thanks for the piece about StoragePrincipal.  I think that motivates this
well for me.  Changing principal is not something we can do trivially (or
not something we should even contemplate ideally).

I do want to pick out one comment you made, which is probably off-topic for
the thread, but I think important in this context.  I'm happy to discuss
more separately if you think I'm taking this too far afield.

On Fri, Jan 25, 2019 at 12:23 AM Andrea Marchesini 
wrote:

> We should not treat the cookie policy as a normal permission setting.
>

I want to challenge this, because I think that our posture toward storage
might set a pattern for how we deal with other things as well.  The
question here is what sort of special treatment we give to storage/cookie
access.  There are two aspects I think that you are concerned with: hiding
what we are doing from pages, and the whole discussion we're having on this
thread.

There are two reasons I can see why we might consider access to storage to
require "hiding" of some sort.

The first is that we want to make sure that pages that were built with an
expectation of access to persistent storage, continue to work more or less
as they did before.  We don't want them to be able to track people, but we
don't want them to suddenly catch fire.  In that light, we're not really
hiding the fact that we are compartmentalizing persisted data, we're just
ensuring that those pages aren't surprised by errors.

The second possibility is that we might want to be able to present a fake
environment to trackers that mimics a real one, but is limited.  That is,
they might think that they are operating in an unconstrained iframe, but
they really aren't.

I think that the fact that you can query with document.hasStorageAccess
puts us firmly in the first bucket.  While we might present a somewhat
functional API, we're only doing that to avoid bustage for old documents,
and we're not trying to hide the fact that we're blocking their ability to
track.  From that perspective, having this modelled as a permission (and
even allowing permission.query() to work) is probably OK.

So this is really about the dynamism aspects of this.  Clearly, building a
system where you can switch out the fake storage with the real one
dynamically is hard.  The surface area is surprisingly big and the changes
are pervasive.  That's infeasible.  But I think that rather than saying
that permissions are a poor fit, I think that it would pay to think more
about how maybe we might fix this in permissions.  Because I think that
this is something that works with permissions in many other respects - it's
something that we might want to bake into feature policy for instance.

When we talked about permissions recently, we concluded that there were
some aspects of the .query() API that didn't properly reflect the range of
policies that might apply.  For instance, permission for some actions is
conditional on an engagement gesture (a click or key press).  Here I think
that we might have a new condition: the permission is conditional on the
page being refreshed.  Now, I concede that perhaps this is too ambitious
and in the absence of other cases that share this constraint this might be
overgeneralizing, but I think that this fits reasonably well.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Cookie policy/permission in live documents - proposal

[Martin Thomson]

On Thu, Jan 24, 2019 at 8:33 AM Andrea Marchesini 
wrote:

> With my proposal, you will have 2 tabs, loading the same origin with 2
> different cookie behaviors.
> Let's assume that one is BEHAVIOR_ACCEPT and the other one BEHAVIOR_REJECT,
> doesn't matter the order.
> The 2 tabs will not be able to communicate to each other because:
>

Presumably if there is an opener relationship between the tabs, things
might be a little odd, because you can postMessage, but not use
localStorage.  So I don't think that this is exactly like private-normal
browsing.

I get that this is difficult, but can you talk a bit about what you think
the driving principles are here?  You mention presenting a consistent
experience with respect to access to state, which is a fine principle.  If
we model access to that state as a permission that can be actively
requested by a site - as per - document.requestStorageAccess - how does
that fit?  (I confess to not having good kept up with developments on that
API, so I apologize if this is off the reservation.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How do we land `./mach vendor rust` patches, these days?

[Martin Thomson]

On Sat, Jan 19, 2019 at 7:42 AM Emilio Cobos Álvarez 
wrote:

> For others (assuming you're hitting the max_post_size limit) I think
> you're out of luck and need to submit them via splinter[2].
>

When vendoring NSS, which we do often, we've sometimes resorted to asking
for review for a script, or one-line command.  As long as that identifies
the thing that is being vendored precisely, then you can go and review the
changes based on the command.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nasm will soon become a build dependency

[Martin Thomson]

On Fri, Dec 21, 2018 at 3:01 PM Cameron McCormack  wrote:

> On Fri, Dec 21, 2018, at 11:05 AM, Thomas Daede wrote:
> > nasm is now required for building on Linux.
>
> Is there a minimum version required?  I am getting errors like this
> building:
>

The OP said >= 2.10.  But you appear to have that.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: UTF-8 autodetection for HTML and plain text loaded from file: URLs

[Martin Thomson]

On Thu, Dec 13, 2018 at 1:14 AM Henri Sivonen  wrote:
> I changed the limit to 4 MB.

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

Re: Intent to implement and ship: UTF-8 autodetection for HTML and plain text loaded from file: URLs

[Martin Thomson]

This seems reasonable, but 50M is a pretty large number.  Given the
odds of UTF-8 detection failing, I would have thought that this could
be much lower.  What is the number in Chrome?

I assume that other local sources like chrome: are expected to be
annotated properly.
On Mon, Dec 10, 2018 at 11:28 PM Henri Sivonen  wrote:
>
> (Note: This isn't really a Web-exposed feature, but this is a Web
> developer-exposed feature.)
>
> # Summary
>
> Autodetect UTF-8 when loading HTML or plain text from file: URLs (only!).
>
> Some Web developers like to develop locally from file: URLs (as
> opposed to local HTTP server) and then deploy using a Web server that
> declares charset=UTF-8. To get the same convenience as when developing
> with Chrome, they want the files loaded from file: URLs be treated as
> UTF-8 even though the HTTP header isn't there.
>
> Non-developer users save files from the Web verbatim without the HTTP
> headers and open the files from file: URLs. These days, those files
> are most often in UTF-8 and lack the BOM, and sometimes they lack
> , and plain text files can't even use  charset=utf-8>. These users, too, would like a Chrome-like convenience
> when opening these files from file: URLs in Firefox.
>
> # Details
>
> If a HTML or plain text file loaded from a file: URL does not contain
> a UTF-8 error in the first 50 MB, assume it is UTF-8. (It is extremely
> improbable for text intended to be in a non-UTF-8 encoding to look
> like valid UTF-8 on the byte level.) Otherwise, behave like at
> present: assume the fallback legacy encoding, whose default depends on
> the Firefox UI locale.
>
> The 50 MB limit exists to avoid buffering everything when loading a
> log file whose size is on the order of a gigabyte. 50 MB is an
> arbitrary size that is significantly larger than "normal" HTML or text
> files, so that "normal"-sized files are examined with 100% confidence
> (i.e. the whole file is examined) but can be assumed to fit in RAM
> even on computers that only have a couple of gigabytes of RAM.
>
> The limit, despite being arbitrary, is checked exactly to avoid
> visible behavior changes depending on how Necko chooses buffer
> boundaries.
>
> The limit is a number of bytes instead of a timeout in order to avoid
> reintroducing timing dependencies (carefully removed in Firefox 4) to
> HTML parsing--even for file: URLs.
>
> Unless a  declaring the encoding (or a BOM) is found within the
> first 1024 bytes, up to 50 MB of input is buffered before starting
> tokenizing. That is, the feature assumes that local files don't need
> incremental HTML parsing, that local file streams don't stall as part
> of their intended operation, and that the content of local files is
> available in its entirety (approximately) immediately.
>
> There are counter examples like Unix FIFOs (can be infinite and can
> stall for an arbitrary amount of time) or file server shares mounted
> as if they were local disks (data available somewhat less
> immediately). It is assumed that it's OK to require people who have
> built workflows around Unix FIFOs to use  and that it's
> OK to potentially start rendering a little later when file: URLs
> actually cause network access.
>
> UTF-8 autodetection is given lower precedence that all other signals
> that are presently considered for file: URLs. In particular, if a
> file:-URL HTML document frames another file: URL HTML document (i.e.
> they count as same-origin), the child inherits the encoding from the
> parent instead of UTF-8 autodetection getting applied in the child
> frame.
>
> # Why file: URLs only
>
> The reason why the feature does not apply to http: or https: resources
> is that in those cases, it really isn't OK to assume that all bytes
> arrive so quickly as to not benefit from incremental rendering and it
> isn't OK to assume that the stream doesn't intentionally stall.
>
> Applying detection to http: or https: resources would mean at least on
> of the following compromises:
>
> * Making the detection unreliable by making it depend on non-ASCII
> appearing in the first 1024 bytes (the number of bytes currently
> buffered for scanning ). If the  was always near the
> start of the file and the natural language used a non-Latin script to
> make non-ASCII in the  a certainty, this solution would be
> reliable. However, this solution would be particularly bad for
> Latin-script languages with infrequent non-ASCII, such as Finnish or
> German, which can legitimately have all-ASCII titles despite the
> language as a whole including non-ASCII. That is, if a developer
> tested a site with a title that has some non-ASCII, things would
> appear to work, but then the site would break when an all-ASCII title
> occurs.
>
> * Making results depend on timing. (Having a detection timeout would
> make the results depend on network performance relative to wall-clock
> time.)
>
> * Making the detection unreliable by examining only the first buffer
> passed by the networking subsystem to th

Re: Plan for Sunsetting MozReview

[Martin Thomson]

On Wed, Sep 5, 2018 at 4:42 PM Mark Banner  wrote:
> A couple of things that may help with the scrolling & finding, that
> people may or may not have found yet...

The keyboard shortcuts are more accessible (type ? to see the list
[1]), though in my experience they interact poorly with concurrent
mouse actions.  One one or the other exclusively for best results.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: DNS Rebinding protection

[Martin Thomson]

On Thu, Jun 28, 2018 at 1:21 AM Benjamin Francis  wrote:
> On 25 June 2018 at 16:50, Brannon Dorsey  wrote:
>
> > As far as I see it, a
> > domain name should never be allowed to respond with a private IP address
> > moments after it first responded with a public IP address.
> >
>
> If I understand correctly, this is exactly what we plan to do on our Mozilla
> IoT gateway  project.

That particular fix won't affect you (if you do indeed plan to use two names).

> We're currently in the process of implementing this, and we're not sure yet
> whether it will work, but if it does this could be a use case that we
> wouldn't want Firefox to block. (Daniel's comments about DNS-over-HTTPS are
> a bit concerning).

If we ever have code to support .local in the browser, then those will
need to avoid using the DoH stack for resolving those names.  mDNS is
a completely/mostly different stack, so that's to be expected.
Similar concerns apply to other special names like .home.arpa and
.onion.  So I wouldn't worry about that aspect of this.

Daniel's point is that DoH has implications for people who have a
local DNS server that produces different or extra results for local
services.  This is common in enterprise where the enterprise DNS
server provides results for local services that aren't addressable, or
ideally even knowable, from outside that network (i.e., other DNS
servers would return NXDOMAIN).  That this is difficult to distinguish
from a rebinding attack is something that the techniques Brannon
describes might help with, but getting that right is tricky and maybe
expensive.

Ultimately, the answer is to use HTTPS throughout, but we're all aware
of the difficulty of doing that in some environments.  (Enterprise
should be easy, but we've seen some reluctance there.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How to request documentation for new features or report problems on MDN

[Martin Thomson]

Hi Chris,

I assume that "just fix it" is still a viable alternative to the processes
you describe.  For small things, that might be easier for all involved.
On Thu, May 17, 2018 at 5:39 AM Chris Mills  wrote:

> Hi all,

> I am sending a mail around to explain how to request MDN documentation
for new features you are working on (e.g. new web platform features, web
extensions features, devtools features), or report docs problems. We've had
a fair few people show a misunderstanding of how this process works
recently.

> TL;DR
> -

> There are two main ways to ask for docs on MDN:

> * Requesting docs by adding the "dev-doc-needed" keyword to an
engineering bug
> * Reporting problems by filing a bug against the "Developer
Documentation" product (
https://bugzilla.mozilla.org/enter_bug.cgi?product=Developer%20Documentation
)

> They are not equivalent.

> * "dev-doc-needed" means "some code in Firefox has changed, and as a
result the docs need to be updated"
> * a "Developer Documentation" bug means "some docs on MDN are
wrong/misleading/incomplete"

> Requesting docs
> ---

> So, if you are working on a bug to add a new feature or update an
existing feature, and it will require documentation changes, add the
keyword "dev-doc-needed" to it. This keyword doesn't mean "we will document
this NOW". It means "we will document this in the future, when appropriate".

> The way the system works is that when "dev-doc-needed" is put on a bug,
as soon as that bug is then resolved our system picks it up and then we
will act on it as appropriate (by documenting the feature, or maybe just
ignoring it if it was WONTFIX’ed, etc.)

> Using this system, we are ready to document new features, if and when
they are needed. Please add "dev-doc-needed" for any such features you are
working on. It makes our lives much easier. Thanks!

> Note: You can set "dev-doc-needed" any time, but we will only look at it
once the bug it's attached to is resolved. Once the bug is resolved we'll
schedule time to update the docs for it, always aiming to have the docs
updated before the version of Firefox containing the change is released
(hopefully before that Firefox is in beta, but we don't always manage that).

> Note: Feature removal/unship bugs should also have "dev-doc-needed" added
— these are still changes that require docs updates.

> Note: We don't add notes in our docs to cover bugs/regressions that crop
up. These are often shortlived, and we don't have the bandwidth for this.

> Reporting problems
> --

> If you notice a problem of some kind with an MDN doc, such as a doc that:

> * should really be added to make a resource complete, but is not linked
to a specific feature addition
> * is located in the wrong place
> * contains a code, spelling or grammar error
> * looks outdated
> * contains spam
> * etc.

> Please file a new bug to report it, under the "Developer Documentation"
product.

> We triage these bugs weekly, and prioritise and handle them in a similar
kind of way to engineering bugs.

> Important: Don't file "Developer Documentation" bugs for feature
additions that already being tracked in an engineering bug. Instead, add
the "dev-doc-needed" keyword to the engineering bug. We've had a few
duplications recently because of this.

> Many thanks!

> Chris Mills
> MDN content lead & writers' team manager || Mozilla
> developer.mozilla.org || MDN Web Docs
> cmi...@mozilla.com || @chrisdavidmills

> ___
> 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: URL.createObjectURL(MediaStream)

[Martin Thomson]

This seems like it's about time.  bz's numbers aren't awe-inspiring,
but low enough that I think we'll manage.

I checked, and there was a question about reviving this in the spec,
but that resolved over a year ago (just before when the deprecated
message was added in Firefox, perhaps coincidentally).

https://github.com/w3c/mediacapture-main/issues/404

On Mon, Apr 23, 2018 at 9:50 AM, Andrea Marchesini
 wrote:
> Per spec ( https://w3c.github.io/mediacapture-main/ ),  this was removed in
> 2013.
> I introduced a deprecated message in bug 1334564, the 7th, February 2017.
>
> I think it's time to remove this method completely. I wrote the patch in
> bug 1454889.
>
> About other browsers:
> . chrome has a deprecated message as well but the method has not removed
> yet: https://bugs.chromium.org/p/chromium/issues/detail?id=591719
> . safari throws
> . I haven't checked edge (I don't run windows locally)
> . We have WPT.
> ___
> 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 Require Manifests For Vendored Code In mozilla-central

[Martin Thomson]

On Tue, Apr 10, 2018 at 6:41 AM, glob  wrote:
>> You don't permit the use of a tag for vendoring, is that intentional?
>
> to echo gps and mike's responses use of a sha to is preferred over tags.

Maybe.  We currently use tags.

Think about the usage model.  If the process is to author the YAML,
then run a tool to vendor the identified code, the opportunity for
mischief is small.  It depends on whether you consider this to be
defense against attack, or a user interface.  I was thinking the
latter.  Presumably every change to the YAML would be reviewed and
tested.

I'm sure that users can be trained to run `git ls-remote`, but it
would be better to consider the UX trade-offs at least a little.
Simple fix: have the vendoring tool add the hash if a tag is
specified.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent To Require Manifests For Vendored Code In mozilla-central

[Martin Thomson]

This seems like a good idea.

Please consider adding hg.mozilla.org to your list of things you will
clone from.  That will allow us to remove some ugly hacks from the
tree for vendoring NSS and NSPR.  (libffi uses the same script, but it
seems to be on GitHub now, so that seems like an easy win assuming
even that libffi still uses that script.)  We could use the NSS GitHub
mirror, but NSPR doesn't have one yet and those can't be the only
projects that we have using mercurial.  Of course, if that is the
case, then don't worry, we'll just have to talk more seriously about
moving NSS to GitHub.

You don't permit the use of a tag for vendoring, is that intentional?
Tags for releases are so commonplace that you should consider it.  You
shouldn't need a branch AND a tag either.  More so because branches
move, which makes them not reliable here.

Having a version in addition to a tag is redundant and therefore
likely to result in mismatches.  I'd say that the tag is enough.

(FWIW, NSS does some of its own vendoring for test runs, so maybe you
could look at https://searchfox.org/nss/source/fuzz/config/git-copy.sh
- vendoring git repos without pulling history turned out to have a few
gotchas.)

On Tue, Apr 10, 2018 at 2:25 PM, glob  wrote:
> mozilla-central contains code vendored from external sources. Currently
> there is no standard way to document and update this code. In order to
> facilitate automation around auditing, vendoring, and linting we intend to
> require all vendored code to be annotated with an in-tree YAML file, and for
> the vendoring process to be standardised and automated.
>
>
> The plan is to create a YAML file for each library containing metadata such
> as the homepage url, vendored version, bugzilla component, etc. See
> https://goo.gl/QZyz4x for the full specification.
>
>
> We will work with teams to add moz.yaml files where required, as well as
> adding the capability for push-button vendoring of new revisions.
>
>
> Please address comments to the dev-platform list.
>
> --
> glob — engineering workflow — moz://a
>
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
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)

[Martin Thomson]

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: Chrome will start marking HTTP pages as "Not secure"

[Martin Thomson]

+ffxdev

There's a tangible difference between text saying "Not Secure" and a
broken lock icon.  I think that we're close, but we'd be making a
stronger statement than Chrome if we did this.

On Fri, Feb 9, 2018 at 8:17 AM, Chris Peterson  wrote:
> Chrome will start marking HTTP pages as "Not secure" in July 2018 (Chrome
> 68):
>
> https://security.googleblog.com/2018/02/a-secure-web-is-here-to-stay.html
>
> Firefox has a similar insecure HTTP warning icon, currently disabled by the
> `security.insecure_connection_icon.enabled` pref added in bug 1310447.
>
> Are there any blockers for Firefox shipping this feature?
> ___
> 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 implement and ship navigator.webdriver

[Martin Thomson]

On Tue, Feb 6, 2018 at 3:37 AM, Andreas Tolfsen  wrote:
> Motivation:
> To give web authors a way to infer if user agent is controlled by
> automation, so the document can take alternate code paths when under
> test.

Can you speak more about why this is a good idea?  I've poor
experience with "this code is now under test" in the past.  You create
the risk that code becomes split into two: code that works as tested,
and code that doesn't work because it isn't tested.

(Not an objection, there's definitely value in consistency between
implementations.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Requiring secure contexts for new features

[Martin Thomson]

Great news.  Thanks to all those involved for getting to this point.

Anne, your posting suggests an exception is likely if:

* other browsers already ship the feature insecurely
* it can be demonstrated that requiring secure contexts results in
undue implementation complexity.

Either of these criteria are sufficient, right?  However, I expect
that we'll want to hold the line in some cases where other browsers
ship anyway.  How do we plan to resolve that?  One potential
resolution to that sort of problem is to ship in secure contexts
anyway and ask other browsers to do the same.

My expectation is that we'll discuss these and exercise judgment.  But
I thought that I'd raise this point here.  I want to avoid creating an
expectation here that we're happy with lowest common denominator when
it comes to these issues.

On Wed, Jan 17, 2018 at 5:11 AM, Anne van Kesteren  wrote:
> Yesterday Mozilla announced Firefox will be restricting new features
> to secure contexts (i.e., HTTPS):
>
>   https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/
>
> I'm glad to report that thus far this has been very well received.
>
> I'm posting this here per suggestion from Ben Kelly and because:
>
> * Not all module owners and peers might have seen the blog post and
> this might impact them if their module currently, or in the future,
> exposes features to web content.
> * Modules might want to look into ways of enforcing this
> programmatically, to ease ongoing maintenance and guide everyone to do
> the right thing without having to ask/review/etc. E.g.,
> https://bugzilla.mozilla.org/show_bug.cgi?id=1429014 has some ideas
> for enforcement around our bindings.
> * Mozillians might have questions not addressed in the post and this
> seems like a good place to centralize those and address them.
>
> Insofar as documenting this policy elsewhere goes I've updated
> https://wiki.mozilla.org/WebAPI/WebIDL_Review_Checklist and I'll
> update https://wiki.mozilla.org/WebAPI/ExposureGuidelines too in some
> manner. (The latter will probably also need to be generalized as
> currently it suggests it's for APIs only.)
>
> Hope that helps,
>
>
> --
> https://annevankesteren.nl/
> ___
> 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: Device Orientation API future

[Martin Thomson]

As Anne said, I don't know why you would define a new API rather than
enhancing the existing one, other than NIH.  But I guess the damage is
now done.

On Fri, Jan 12, 2018 at 4:48 AM, Blair MacIntyre  wrote:
>> On Thu, Jan 11, 2018 at 5:30 PM, Blair MacIntyre  
>> wrote:
>>> First, this discussion pertains to FF on Windows, Mac, Android and Linux, I 
>>> assume?  FF for iOS just uses the wkWebView and it’s up to Apple to decide 
>>> on things like this.  Is this correct?
>>
>> I believe there's some tricks we could pull on iOS in theory.
>
> Perhaps.  But is that part of the discussion?  I ask because
>>
>>
>>> From a WebVR perspective, the polyfill (that uses device-orientation) 
>>> defers to the built in WebVR API if it exists.
>>
>> So WebVR/XR has its own equivalents for these APIs? I was not aware of
>> that.
>
> No, it’s different:  WebVR/XR provide precise 3D orientation and position 
> (assume 3D position tracking is available) of the display.  Typically, that’s 
> a Head-Worn Display (ie., a Vive or Rift or whatever).  Currently, WebVR has 
> only been implemented only for head-worn displays.  The polyfill was used to 
> fill in the gaps;  provide “VR” on those paper “cardboard” display holders, 
> for example.
>
> Moving forward, WebXR will include the notion of “Magic Window” displays, 
> meaning “you’re holding the device in your hands and it tries to give the 
> appearance of a portal into the virtual or AR world”.  So, “tracked 3D 
> content”.
>
> For the WebVR/XR api to work, it must provide a super-set of the 
> device-orientation capabilities to the application.  There are separate 
> discussions about the security aspects of WebVR/XR:  it will not be 
> accessible without permission or user-gesture, as this API is.
>
> So, it’s not an “equivalent” API, but is rather providing the information 
> needed to do 3D AR/VR directly, without relying on getting device orientation 
> from this API.
>
>
>> In that case I'm not entirely sure why we'd also pursue new
>> variants separately.
>
> I’m not sure what this means?
>
>>
>>
>> --
>> https://annevankesteren.nl/
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Orientation API future

[Martin Thomson]

On Thu, Jan 11, 2018 at 3:39 PM, Chris Van Wiemeersch  wrote:
> Anne and Martin, can you think of changes to request for the Sensor API that
> we would resolve or reasonably improve the existing fingerprinting concerns?

In general, we can't improve the situation by adding more
functionality.  That's just physics.

The API will necessarily degrade fingerprinting for every sensor we
decide to support.

Let's say that we add the ability to get access to a humidity sensor.
Even making it possible to learn that the capability exists will allow
sites to divide users into two groups: those with a humidity sensor
and those with out.

I'm not saying that we shouldn't make these capabilities available.
There can be reasons that outweigh the costs (for instance, I think
that we generally agree that VR is a use case that justifies some
increase in fingerprinting exposure), but we should consider each
capability individually and provide justification and mitigations.  If
we can find that justification and adequate mitigations, we might then
conclude that this is a net gain for the people who trust us enough to
install Firefox.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Orientation API future

[Martin Thomson]

What Anne said.  None of these actions help address the primary concern.

On Wed, Jan 10, 2018 at 2:23 PM,   wrote:
> Exciting to hear, Kyle!
>
> As mentioned earlier, Chrome for Android M63+ has shipped an implementation 
> (disabled by default, with an Origin Trial) of the Generic Sensor API, but 
> TAG review (https://github.com/w3ctag/design-reviews/issues/207) feedback 
> needs to be addressed.
>
> For our WebVR use cases, there's an ongoing discussion for the WebVR Polyfill 
> here: https://github.com/googlevr/cardboard-vr-display/issues/10
>
> Jonathan/Anne/Martin/Kyle, feel free to correct me, but as I see it, here's a 
> potential process of the actionable steps we can take to securing the legacy 
> Device Sensor APIs today and eventually deprecating them in favor of an 
> implementation of the Generic Sensor APIs.
>
> 1. Lock down the Device Sensor APIs APIs in Gecko to only secure contexts, 
> with `deviceorientation`, `absolutedeviceorientation`, and `devicemotion` 
> being enabled by default.
> * Despite the bug title, the WIP patches in http://bugzil.la/1359076 do 
> handle this with the `device.sensors.orientation.enabled` flag:
> * https://reviewboard.mozilla.org/r/160400/diff/#index_header
>
> 2. Implement the Generic Sensor APIs in Gecko.
> * Spec:
> * https://w3c.github.io/sensors/
> * File a Bugzilla tracking bug for Gecko implementation (à la 
> https://crbug.com/750018).
> * Announce Intent to Implement.
> * Chrome's platform status:
> * Platform feature page:
> * https://www.chromestatus.com/feature/5698781827825664
> * Blink's Implementation (shipped in M63):
> * https://crbug.com/750018
> * 
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/TkfdVqYAYiE
> * 
> https://developers.google.com/web/updates/2017/09/sensors-for-the-web
> * Blink's Origin Trial (ends Feb 27, 2018):
> * 
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/2zPZt3watBk
> * 
> https://github.com/GoogleChrome/OriginTrials/blob/gh-pages/available-trials.md#current-experimental-features
>
> 2. Implement the Feature Policy API in Gecko.
> * Spec:
> * https://wicg.github.io/feature-policy/
> * https://w3c.github.io/sensors/#feature-policy-api
> * 
> https://github.com/WICG/feature-policy/blob/gh-pages/features.md#sensor-features
> * 
> https://docs.google.com/document/d/1k0Ua-ZWlM_PsFCFdLMa8kaVTo32PeNZ4G7FFHqpFx4E/edit
> * File a Bugzilla tracking bug for Gecko implementation for implementing the 
> Feature Policy (à la Blink's: https://crbug.com/623682).
> * File a Bugzilla tracking bug for Gecko implementation for having the legacy 
> Device Orientation API (or Generic Sensor API, if it's implemented) use the 
> Feature Policy (à la Blink's: https://crbug.com/750018).
> * Announce Intent to Implement the Feature Policy.
> * Announce Intent to Implement the Feature Policy for the Device Orientation 
> and/or Generic Sensor APIs.
> * Chrome's platform status:
> * Platform feature page for Feature Policy:
> * https://www.chromestatus.com/feature/5694225681219584
> * Blink's Implementation for Feature Policy (shipped in M60):
> * https://crbug.com/623682
> * https://bugs.chromium.org/p/chromium/issues/detail?id=623682&desc=2
> * Platform feature page for page for Feature Policies for the Device 
> Orientation API (i.e., `deviceorientation`, `deviceorientationabsolute`, and 
> `devicemotion` events):
> * https://www.chromestatus.com/feature/5758486868656128
> * Blink's in-progress Implementation for Feature Policy for the Device 
> Orientation API:
> * https://crbug.com/750018
>
> 4. Deprecate the legacy Device Orientation API in Gecko.
> * This email thread could suffice, but a new thread might be best.
> * Close http://bugzil.la/1359076, and file a new Bugzilla tracking bug for 
> removing Gecko implementation.
> * Announce Intent to Deprecate.
> ___
> 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: Proposed W3C Charter: Second Screen Working Group

[Martin Thomson]

t; > be harmful rather than helpful to the end goal for some reason, or
> >> > > if he has other disagreements with this approach, or better
> >> > > suggestions for what remedy we should suggest.
> >> > >
> >> > > -David
> >> > >
> >> > > =
> >> > >
> >> > > The current situation with the API developed by this Working Group
> >> > > is that it is a API for a web page to interact with a connection
> >> > > between the web browser and a separate screen that exists entirely
> >> > > in a closed ecosystem.  For example, a browser made by Google might
> >> > > connect to displays that support the proprietary Chromecast
> >> > > protocol, whereas one made by apple might connect to displays that
> >> > > support the proprietary AirPlay protocol.
> >> > >
> >> > > We know that parts of an Open Screen Protocol are in an early stage
> >> > > of development at https://github.com/webscreens/openscreenprotocol
> >> > > (as linked from the charter), and the goal of this work is to
> >> > > improve on this situation.  We hope it will allow for interoperable
> >> > > discovery of, identification of, and communication with presentation
> >> > > displays.  However, we're deeply concerned about chartering a second
> >> > > iteration of the work that continues building the Presentation API
> >> > > on top of a closed ecosystem, when the work to make the ecosystem
> >> > > more open has a lower priority.  While we understand that the work
> >> > > on building an open ecosystem still requires incubation, we believe
> >> > > it should have the highest priority in this space.  We believe that
> >> > > rechartering the Second Screen WG should wait until that work is
> >> > > ready to be in a working group, and that advancing the current
> >> > > specifications (developed under the existing charter) to Proposed
> >> > > Recommendation probably depends on this new work in order to
> >> > > demonstrate real interoperability, although we are open to other
> >> > > paths toward fixing this situation.
> >> > >
> >> > >
> >> > > On Thursday 2018-01-04 09:29 -0700, Peter Saint-Andre wrote:
> >> > > > +1 to Martin's feedback.
> >> > > >
> >> > > > On 1/3/18 10:19 PM, Martin Thomson wrote:
> >> > > > > Without the protocol pieces, this remains vendor-specific.  We
> should
> >> > > > > comment on this and make it clear that we think that definition
> of a
> >> > > > > generic protocol for interacting with the second display has
> not been
> >> > > > > given sufficient priority.  Allowing this to proceed without a
> generic
> >> > > > > protocol would be bad for the ecosystem.
> >> > > > >
> >> > > > > From what I can see, there seem to be a bunch of options that
> are
> >> > > > > described for the protocol, without extremely scant detail.
> Certainly
> >> > > > > not enough to implement anything.
> >> > > > >
> >> > > > > I'm concerned with the statement "This Working Group does not
> >> > > > > anticipate further changes to this specification" regarding the
> >> > > > > presentation API.  I haven't reviewed this thoroughly, but there
> >> > > > > appear to be some gaps in rather fundamental pieces.  For
> instance -
> >> > > > > and maybe this doesn't change the API at all - but the means of
> >> > > > > identification for screens is unclear.  Some of these details
> are
> >> > > > > important, such as whether knowledge of a presentation URL is
> all the
> >> > > > > information necessary to use that URL (i.e., are they capability
> >> > > > > URLs?).
> >> > > > >
> >> > > > > On Thu, Jan 4, 2018 at 2:31 PM, Shih-Chiang Chien <
> sch...@mozilla.com> wrote:
> >> > > > > > The SecondScreen WG intended to move the protocol development
> to CG, and
> >> > > > > > will possibly move to IETF after the incubation phase.
> >> > > > > > The revised charter is trying to associate the work of CG to
> the t

Re: Device Orientation API future

[Martin Thomson]

My hope is that any stickiness would be transitory.

If someone is obviously using a VR headset, I don't think we would
require much movement at all to trigger the automatic permission.
That's clearly a primary input interface.

On Thu, Jan 4, 2018 at 9:15 PM, Blair MacIntyre  wrote:
> I’m unclear of which side of the line we want to fall on between supporting 
> existing sites or requiring them to change.
>
> If we are going to break existing websites, then perhaps looking at the 
> Generic Sensor API (as CVan suggests in his email) is a more rational 
> approach;  is it implemented in FF yet?  Plans for it?
>
> For device orientation, my assumption (perhaps incorrect?) has been that we’d 
> be trying to support existing sites.  The worry I have with the gross motion 
> idea is that the UX would be terrible.  Right now, you start a site (VR, 360 
> image, etc) and can look around:  in my own experience, the motion is rarely 
> fast.  So the site would appear stuck, and the user may never discover it’s 
> stuck.
>
> But, perhaps if we’re willing to change the browser itself to provide some 
> feedback, this could work though.
> - I go to a site, it requests motion
> - motion events are not sent initially
> - FF waits a bit to see if the user shakes or grossly moves the phone (e.g., 
> perhaps a newer site says “shake the phone to activate panoramic viewing”)
> - if it does happen, FF slides in/down a message saying something similar 
> (e.g., “site wants to watch the movements of your device;  shake phone or 
> click yes to confirm, no to deny”)
> - if shake doesn’t happen in short time, or they click no, that’s that.  If 
> they shake or click yes, motion is used.
>
> But, perhaps this is too confusing.
>
> For the perms API, I imagined it might just work with devicemotion:  setting 
> up the callback could trigger a perms request, and the data would only start 
> flowing on acceptance.
>
>> On Jan 3, 2018, at 11:52 PM, Martin Thomson  wrote:
>>
>> On Thu, Jan 4, 2018 at 1:09 PM, Blair MacIntyre  
>> wrote:
>>> We could chat about it, sure;  how do you envision it working without 
>>> breaking old websites?
>>
>> With the understanding that this is purely spitballing...
>>
>> We would stop providing events (or provide them with extremely low
>> frequency [1]), but if the currently focused context has an event
>> handler registered for orientation events, we would enable events once
>> the orientation changes by a large amount or quickly.  The thresholds
>> might need some tuning, but a shake or large movement should work.
>>
>> That means that sites that expect and only receive subtle movement
>> would stop receiving events.  Sites that don't receive input focus
>> would stop receiving events (that prevents an embedded iframe from
>> getting events).  But sites that legitimately use the API will only
>> appear to be a little "sticky" initially.  We might also persist this
>> "implicit" permission to remove that stickiness for sites that are
>> used often (or reduce the activation thresholds over repeat visits).
>>
>> We should also look at getting a hook into the permission API so that
>> the current state can be queried.  But that API doesn't really
>> understand this sort of model, so that might be tricky to work out.
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Orientation API future

[Martin Thomson]

On Thu, Jan 4, 2018 at 9:06 PM, chris  wrote:
> Thanks for the clarification, Martin. Providing that the UA persists
> permissions (based on user action –or perhaps also leveraging Google’s Safe
> Browsing API which Firefox and all other browsers already rely upon –
> revoked and prompted -> denied/granted), do you have any additional concerns
> about requiring secure contexts for the Sensor APIs?

To be clear: secure contexts is table stakes now.  Anything that is
exposed outside of secure contexts needs a pretty strong story for
why.

> If not, do you have ideal mitigation solutions given these use cases (e.g.,
> “magic windows,” WebXR [VR/AR], UI effects based on gyroscope)?

"Ideal" isn't necessarily useful.  I want people to be aware when
these features are being used.  Beyond that, for the features to only
be available for use when intended.  These are "inputs", and when
someone intentionally activates these inputs, that is the ideal
situation.  If we're talking pie in the sky, then we might also
ideally remove the side-channel information without compromising the
usefulness of the APIs.

Of course, these ideals are basically impossible to assess.  Even if
we went so far as to add a permissions prompt, which I'm not sure is
the right answer for this case.  But we do what we can.

> Which are, in your opinion, the paramount attack vectors and mitigation
> strategies? And the limitations of the latter?

Of most concern here is the lengthy list of ways in which data might
be obtained using these APIs by the drive-by web.  If there is no
indication that these APIs are in use, then a random website can use
them to obtain passwords, record audio, etc...  Note that a discrete
indicator is probably not sufficient for this purpose.  The one we use
for audio only really works because we also have audio playing, which
is often[1] more noticeable than the indicator.

The mitigation strategies described in the sensors API are a good
baseline, but ideally we have some way of receiving some signal that
the API is being used intentionally.

[1] Ultrasonics are a great way to exfiltrate information from a
browser without users noticing.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Orientation API future

[Martin Thomson]

On Thu, Jan 4, 2018 at 5:50 PM,   wrote:
> FYI: As implemented in Chrome, permission is automatically granted to use the 
> Generic Sensor API (`chrome://flags/#enable-generic-sensor`) in secure 
> contexts (e.g., HTTPS, localhost).

Requiring secure contexts is not a security feature.  It's necessary
if we are to persist permission, but an attacker can use HTTPS.
Requiring focus is good, as is using feature policy (and a default
allowlist of 'self' is a good starting point), but neither of those is
entirely sufficient either.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Second Screen Working Group

[Martin Thomson]

Without the protocol pieces, this remains vendor-specific.  We should
comment on this and make it clear that we think that definition of a
generic protocol for interacting with the second display has not been
given sufficient priority.  Allowing this to proceed without a generic
protocol would be bad for the ecosystem.

From what I can see, there seem to be a bunch of options that are
described for the protocol, without extremely scant detail.  Certainly
not enough to implement anything.

I'm concerned with the statement "This Working Group does not
anticipate further changes to this specification" regarding the
presentation API.  I haven't reviewed this thoroughly, but there
appear to be some gaps in rather fundamental pieces.  For instance -
and maybe this doesn't change the API at all - but the means of
identification for screens is unclear.  Some of these details are
important, such as whether knowledge of a presentation URL is all the
information necessary to use that URL (i.e., are they capability
URLs?).

On Thu, Jan 4, 2018 at 2:31 PM, Shih-Chiang Chien  wrote:
> The SecondScreen WG intended to move the protocol development to CG, and
> will possibly move to IETF after the incubation phase.
> The revised charter is trying to associate the work of CG to the timeline
> of Presentation API development.
>
> At the meantime, WG will tackle the testability issue found while creating
> test cases and cultivating Level 2 API requirements for advanced use cases.
>
> I'll vote to support this revised charter.
>
> Best Regards,
> Shih-Chiang Chien
> Mozilla Taiwan
>
> On Thu, Jan 4, 2018 at 10:08 AM, L. David Baron  wrote:
>
>> The W3C is proposing a revised charter for:
>>
>>   Second Screen Working Group
>>   https://w3c.github.io/secondscreen-charter/
>>   https://lists.w3.org/Archives/Public/public-new-work/2017Dec/.html
>>
>> Mozilla has the opportunity to send comments or objections through
>> Friday, January 52.  (Sorry for failing to send this out sooner!)
>>
>> A diff relative to the current charter is:
>> https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2014%
>> 2Fsecondscreen%2Fcharter-2016.html&doc2=https%3A%2F%2Fw3c.
>> github.io%2Fsecondscreen-charter%2F
>>
>> The participants in the working group are:
>> https://www.w3.org/2000/09/dbwg/details?group=74168&public=1&order=org
>>
>> Please reply to this thread if you think there's something we should
>> say as part of this charter review, or if you think we should
>> support or oppose it.
>>
>> One longstanding concern for me with this work is to what extent it
>> defines an API that lets an Google-made browser talk to a Google
>> screen, and an Apple-made browser talk to an Apple screen, versus to
>> what extent it allows any browser to talk to any screen that
>> supports a particular piece of technology.  I think there might
>> have been some encouraging news on this front at TPAC in November,
>> but I don't remember the details.  But if there was, I'd rather
>> expect it to be incorporated into this charter, but I don't really
>> see that after a first read.  I'm curious what others know and think
>> about this issue.
>>
>> -David
>>
>> --
>> 𝄞   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)
>>
> ___
> 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: Device Orientation API future

[Martin Thomson]

On Thu, Jan 4, 2018 at 1:09 PM, Blair MacIntyre  wrote:
> We could chat about it, sure;  how do you envision it working without 
> breaking old websites?

With the understanding that this is purely spitballing...

We would stop providing events (or provide them with extremely low
frequency [1]), but if the currently focused context has an event
handler registered for orientation events, we would enable events once
the orientation changes by a large amount or quickly.  The thresholds
might need some tuning, but a shake or large movement should work.

That means that sites that expect and only receive subtle movement
would stop receiving events.  Sites that don't receive input focus
would stop receiving events (that prevents an embedded iframe from
getting events).  But sites that legitimately use the API will only
appear to be a little "sticky" initially.  We might also persist this
"implicit" permission to remove that stickiness for sites that are
used often (or reduce the activation thresholds over repeat visits).

We should also look at getting a hook into the permission API so that
the current state can be queried.  But that API doesn't really
understand this sort of model, so that might be tricky to work out.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Orientation API future

[Martin Thomson]

On Thu, Jan 4, 2018 at 2:52 AM, Blair MacIntyre  wrote:
> I was more concerned about the idea (or, at least what I though might be
> suggested) that you only get orientation if they give location permission.
> This seems overkill:  even if I know what the data means, I can see uses of
> orientation that I’d be comfortable with but that I wouldn’t be comfortable
> giving my geolocation.  that’s all I was talking about.

I guess that someone needs to work out how to control access to
orientation without invoking that prompt then.  I think that we could
easily give access to orientation with geolocation, but I can see that
there are plenty of cases for orientation *without* geolocation.
Could we explore the gross movement idea some more?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Orientation API future

[Martin Thomson]

The suggestion that was made in the past was to tie orientation to
geolocation.  I think that this would be obvious enough to pass.
Orientation is basically a refinement of position.  It clearly makes
sense for AR applications.  Pure VR applications might only care about
relative orientation and so might suffer a little.

I realize that friction is always a concern, but the amount of
side-channel information that leaks through the API is hard to ignore.
I think that a prompt is wise, while we investigate ways in which we
might improve the UX.

For instance, we could attempt to interpret gross movement as a
deliberate indication of intent.  Then sites could use this to
implement their own permission process ("shake your phone/head to
start").

On Fri, Dec 22, 2017 at 2:52 AM, Jonathan Kingston  wrote:
> Following the intent to deprecate filed on Sunday for the Ambient Light and
> Proximity sensor APIs
> ,
> we propose to discuss the future of the Device Orientation API.
>
> DeviceOrientation
> 
> (deviceorientation, deviceorientationabsolute, and devicemotion events) has
> far more usage than the other two sensor APIs and so we need to be more
> careful with it to prevent breakage.
>
> Currently this API is restricted to first party domain scripts only,
> however Chrome has filed an intent to ship to have a feature policy to
> enable this in third party scripts
> .
> This would mean that advertisements and others would have unrestricted
> access to the users sensor information assuming they’re included through an
> iframe with the relevant allow attribute set.
>
> Risks
>
> Some of the keylogging risks are outlined in papers [1] and [2], however
> there are also risks of the user being identified by physical or
> environmental factors like mapping the swing of the device to walking gate
> patterns and the angle and shaking of the phone to match to patterns in
> altitude and terrain type.
>
> The current API provides unprompted floating point precision of sensor data
> at 60hz to the website.
>
> Generic sensor API
>
> These APIs are being replaced by the work on the generic sensor API as
> outlined in the following TAG thread
> , though it’s
> currently unclear how to properly deal with the risks of sensors other than
> throttling. It’s unclear that throttling sufficiently addresses the risks
> and also makes them a poor choice for VR.
>
> Chrome has stated their plan for the UX of the generic sensor API
> 
> and it doesn’t address the unprompted access to sensors, nor do we feel
> showing a new indicator about sensor usage goes far enough to mitigate the
> risk.
>
> We feel that Firefox should prompt users in some manner when accessing
> granular sensor information. Until these concerns are mitigated it seems we
> shouldn’t open up access to these sensors via a feature policy to third
> parties.
>
> Ideas to reduce user risk from the current API:
>
> - Dialling down the precision of this event or frequency it is fired from
> 60hz to 5hz however this would limit it’s usage in Web VR.
>
> - Restrict to secure contexts; this reduces some risk in particular with
> man-in-the-middle proxies that modify traffic, but is not going to address
> the overall issue on its own
>
> - We could place these events behind a permission prompt preventing drive
> by usage; a big problem with this suggestion is that it’s unclear what to
> ask the user
>
> - Restrict access to only the active tab
>
> Kind regards,
>
> Anne van Kesteren, Jonathan Kingston, and Frederik Braun
>
> [1] https://www.usenix.org/legacy/event/hotsec11/tech/final_files/Cai.pdf
>
> [2] https://dl.acm.org/citation.cfm?id=2714650
> ___
> 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: Follow up on clang-format

[Martin Thomson]

On Wed, Sep 27, 2017 at 7:34 AM, Mike Hommey  wrote:
> And then you end up with something like:
>
> class Foo {
>   Type MethodA() { do_something(); }
>   Type MethodB()
>   {
> do_something_that_happens_to_be_long_enough_not_to_fit_on_the_same_line();
>   }
>   Type MethodC() { do_something_else(); }
> };
>
> And I find that distracting. Is there a pref to make it not reformat things
> that look reasonable already, although not "optimally" so?

Not in my experience.  The example above is governed by
AllowShortFunctionsOnASingleLine [1], which doesn't have a "leave it
be" option.  You get all or nothing generally.  In the above case you
probably want consistency and so A and C should match B, but it's not
that smart.

I had the same problem with some long statements.  The way I "fixed"
that was to add comments.  You could do the same if you cared.

[1] http://clang.llvm.org/docs/ClangFormatStyleOptions.html
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Follow up on clang-format

[Martin Thomson]

On Tue, Sep 26, 2017 at 10:49 PM, Sylvestre Ledru 
wrote:
>> clang-format messes up really badly many macros.
>> For example nsElementTable.cpp becomes unreadable.
>
> Yeah, for this kind of structure & presentation layout, we should just
ignore the formatting on these.
>
> It is hard for reformatting tools to know exactly to do with such
patterns.

For this you can use:

/* clang-format off */
...manually aligned macro stuff...
/* clang-format on */

I think that is preferable. When we did a big sweep on NSS we took a little
time out to find things that we wanted to preserve in this way and added
these guards.

Sometimes the macros can be tweaked to fix this, but that can come later.
For example, we had macros that were being used to wrap multiple (x,
sizeof(x)) in parameter lists, those had a semicolon in the macro and
clang-format interpreted that line as being a declaration rather than a
code block. The code was in the form TEST_P(x, y) { MACRO(blah) } and
clang-format broke the line after the "x,". Moving the semi-colon out fixed
it. But those are just nits.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: Placement of binary operators when breaking a long line

[Martin Thomson]

On Fri, Sep 8, 2017 at 1:08 AM, Ehsan Akhgari  wrote:
> The great majority of code changing is quite expected for any project
> switching to clang-format, since as it turns out automated tools are much
> better at doing this grunt work than humans are.  The reason projects choose
> to switch to using clang-format is increasing developer productivity by
> allowing editor/IDE integration for formatting the code as you're editing
> it, ensuring the code formatting remains consistent over time without
> needing to spend invaluable engineering time on it, and being able to stop
> debating whitespace issues and moving on to focus on more productive
> discussions.  ;-)

I am 100% behind this idea.  NSS is already there and it's so nice.

One question, because it hurts me every day now, which version of
clang-format will we use?  NSS actually has checks in CI that will
fail if you submit unformatted code (it gives you a nice patch you can
download and apply to fix the problem even), so we're very particular
about this.  However, my local version of clang-format is more recent.
There are small differences in its handling of certain constructs.
It's been screwing up my pre-commit hook for a while now (I just
haven't gotten around to fixing it just yet).

e.g.,

3.9
-  CheckAcks(client_filters_, 0, {0,  // SH
- 0x0002ULL,  // EE
- 0x00020002ULL}  // CT2
4.0
+  CheckAcks(client_filters_, 0,
+{0,  // SH
+ 0x0002ULL,  // EE
+ 0x00020002ULL}  // CT2

Have we had the version discussion yet?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Memory header and JS API

[Martin Thomson]

On Fri, Sep 8, 2017 at 5:32 AM, Tom Ritter  wrote:
> On Thu, Sep 7, 2017 at 1:09 PM, Shubhie Panicker via dev-platform
>  wrote:
>> Curious - are there concerns with implementing Client Hints in general?
>
> Yes. But the fingerprinting team (specifically, I'm not sure what
> other teams have done) haven't investigated Client Hints yet to see
> what we may wish to obscure. =)

I reviewed some changes to the spec, and am of the opinion that there
are problems with Client Hints in this area:  see
https://github.com/httpwg/http-extensions/pull/373#pullrequestreview-54009185

That's not a proper review of the sort that Tom is talking about, but
the issues are suggestive of problems.  As with here, the biggest
concern I have is over the amount of control a UA has when it comes to
how this is used.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Memory header and JS API

[Martin Thomson]

Why do the numbers need to be standardized?  Could we give browsers
the ability to change the value in response to their understanding of
the current situation.

Surely an Android device is easily identifiable as such, so we could
choose values that reflect our Android population at the current
moment and we could choose numbers so that no bucket is too small.  We
could say that the number is decimal, that it needs to be at least the
identified value, and have a  wrote:
> On 2017-09-06 11:48 AM, Tom Ritter wrote:
>>
>> Steam's hardware survey shows the following distribution percentages.
>>
>> Less than 512 MB 0.00%
>> 512 Mb to 999 MB 0.03%
>> 1 GB 0.52%
>> 2 GB 3.30%
>> 3 GB  6.27%
>> 4 GB  14.96%
>> 5 GB  0.66%
>> 6 GB  3.23%
>> 7 GB  2.33%
>> 8 GB  42.77%
>> 9 GB  0.04%
>> 10 GB  0.29%
>> 11 GB  0.18%
>> 12 GB and higher  25.39%
>
>
> The memory distribution of Firefox desktop users is shared on the Firefox
> Hardware Report dashboard. Unsurprisingly, Firefox users have less memory
> than Steam users.
>
> https://hardware.metrics.mozilla.com/#goto-cpu-and-memory
>
> ___
> 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: Coding style: Argument alignment

[Martin Thomson]

On Wed, Aug 30, 2017 at 5:21 PM, Sylvestre Ledru  wrote:
> Could you report a bug? We wrote a few patches upstream to improve
> the support of our coding style.

This isn't a bug either, but I've noticed that alignment anywhere can
cause collateral changes.  `clang-format -style=Mozilla -dump-config`
says `AlignTrailingComments: true` so, this is something you might
see:

static const uint8_t x[] = {
  a, // this only
  b, // has short
  c  // names
};

static const uint8_t x[] = {
  a,   // this no longer
  b,   // has short
  c,   // names, and
  0xff // everything has to change
};

However, I think that the benefits of clang-format greatly outweigh
this type of minor niggle.  It's relatively rare that this pollutes
blame, and there are ways to skip these changes.  And I can see how
it's easier to read than the alternative.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: Argument alignment

[Martin Thomson]

On Wed, Aug 30, 2017 at 12:07 PM, L. David Baron  wrote:
> I think I do this because (b) has the disadvantage that more code
> changes require touching additional lines, which is both changes
> blame and is extra work (although it's not extra work if we're using
> clang-format tree-wide).  Option (b) is also more likely to lead to
> overly long lines that require wrapping.

NSS had a lot of option (b) and we agreed that it was bad for these
reasons.  You also have to agree not to do this, another thing that
NSS was infested with:

  nsresult ShortFunction(witharg, and another);
  void   Function2  (HasOnlyOne* arg);

Does clang-format even *do* this?  AlignConsecutiveDeclarations is the
closest I could find to a directive that would do this sort of crazy
alignment, but that seems more likely to govern my example than
argument lists.  For the record, we should not enable that either.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Restricting the Notifications API to secure contexts

[Martin Thomson]

More than fine, this is an overdue change :)

Notifications being available on http:// origins is a source of a
small amount of pain for web push, because the two share the same
permission.

On Tue, Aug 8, 2017 at 2:24 AM, Eric Rescorla  wrote:
> This seems fine.
>
> -Ekr
>
>
> On Mon, Aug 7, 2017 at 6:45 AM, Anne van Kesteren  wrote:
>
>> Chrome wants to restrict the Notifications API
>> https://notifications.spec.whatwg.org/ to secure contexts:
>>
>>   https://github.com/whatwg/notifications/issues/93
>>   https://github.com/w3c/web-platform-tests/pull/6596
>>
>> Given that the API involves prompting the user as well as a permission
>> that remains stored across different networks it seems like a good
>> idea to restrict this API to HTTPS.
>>
>> I was wondering if anyone has concerns with restricting the API as
>> such. If there are no concerns within a week I'll let Chrome go ahead
>> with the change to the standard and tests and file the necessary
>> implementation bugs against the remaining browsers, including Firefox.
>>
>>
>> --
>> https://annevankesteren.nl/
>> ___
>> 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: Extensions and Gecko specific APIs

[Martin Thomson]

On Wed, Jul 26, 2017 at 6:20 AM, Andrew Overholt  wrote:
> On Tue, Jul 25, 2017 at 3:06 PM, David Teller  wrote:
>> Should we moz-prefix moz-specific extensions?
>
> We have been trying not to do that for Web-exposed APIs but maybe the
> extensions case is different?

I don't think that it is.  If there is any risk at all that someone
else might want to use it, then prefixing will only make our life
harder long term.  Good names are cheap enough that we don't need to
wall ours off.

See also https://tools.ietf.org/html/rfc6648
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Phabricator Update, July 2017

[Martin Thomson]

On Wed, Jul 12, 2017 at 1:34 PM, Byron Jones  wrote:
> instead of disabling splinter for phabricator backed products, we could make
> it a read-only patch viewer.

Given the number of bugs that exist with patches attached, that would
be greatly appreciated.  I would also assume that attaching patches
won't stop completely either.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Phabricator Update, July 2017

[Martin Thomson]

On Wed, Jul 12, 2017 at 6:41 AM, Mark Côté  wrote:
> * MozReview and Splinter turned off in early December.

Is this bugzilla-wide?  I know that other project use splinter still.
Will those projects be able to use phabricator for their projects?

For instance, NSS uses a separate instance of phabricator, but not all
the developers are using it already.  I don't think that we have NSPR
setup yet.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Improving visibility of compiler warnings

[Martin Thomson]

On Thu, May 25, 2017 at 6:03 AM, Nathan Froyd  wrote:
> Where does NSS do this?  Cloning the NSS tree and grepping for
> sign-compare turns up no disabling of -Wsign-compare, except perhaps
> in XCode for gtest itself.

My bad, -Wsign-compare is in -Wextra, and we don't enable anything
extra.  We disable errors for C4018 on MSVC, which is what I was
thinking of.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Martin Thomson]

On Sat, May 20, 2017 at 2:05 AM, Ben Kelly  wrote:
> Can the people who have concerns about the NetworkInformation API please
> provide the feedback to google on this blink-dev thread:

https://groups.google.com/a/chromium.org/d/msg/blink-dev/UVfNMH50aaQ/FEQNujAuBgAJ

In short, I don't think that the privacy concerns are that
significant.  It's just that in assessing value against cost they seem
much more significant.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Improving visibility of compiler warnings

[Martin Thomson]

On Sat, May 20, 2017 at 4:55 AM, Kris Maglione  wrote:
> Can we make some effort to get clean warnings output at the end of standard
> builds? A huge chunk of the warnings come from NSS and NSPR, and should be
> easily fixable.

Hmm, these are all -Wsign-compare issues bar one, which is fixed
upstream.  We have an open bug tracking the warnings
(https://bugzilla.mozilla.org/show_bug.cgi?id=1307958 and specifically
https://bugzilla.mozilla.org/show_bug.cgi?id=1212199 for NSS).

NSS is built with -Werror separately, but disables errors on
-Wsign-compare.  Disabling those warnings for a Firefox build of NSS
wouldn't be so bad now that we share gyp config.  Based on a recent
build, that's 139 messages (add 36 if you want to add nspr).

I've spent a little time looking into the real issues.  Fixing
requires some care, since it touches ABI compat in many places.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: SharedArrayBuffer and Atomics

[Martin Thomson]

On Thu, May 11, 2017 at 5:57 PM, Lars Hansen  wrote:
> We do think there are
> architectural improvements that hardware manufacturers, operating systems,
> and browsers can make [19], and we intend to investigate them.

I think that the work you cite is promising.  However, listening to
this presentation, there's a little soundbite that seems relevant to
this point.  Forgive any transcription errors, but I think that David
(the author of the paper) says:

"For example, Javascript is currently considering adding shared
memory.  That would destroy this entire model."  -- start at 27:00 for
the question and this answer.

Do you have a strategy for dealing with this problem?  The UCSD paper
doesn't provide any suggestions from what I can see.

A major issue here is that once we ship a feature like this, it's very
difficult to un-ship if we find that we need to change things to deal
with issues.  Given that we know those issues, having a framework for
dealing with those issues ahead of time would allow us to gain some
confidence that we aren't setting ourselves up for some serious pain.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ambient Light Sensor API

[Martin Thomson]

On Fri, Apr 28, 2017 at 1:56 PM, Ehsan Akhgari  wrote:
>> While it does not address the attack, it should be limited to secure
>> context, if we keep the API. It's actually in the spec.
>
> Why is that an advantage?  Any attacker can use a secure context. The word
> "secure" here relates to the security of the transport layer, but if the
> origin itself is untrusted (which it is) exposing an unsafe functionality to
> a "secure" context is just as unsafe.
>
> (And on the practical side of things, any attacker can use a free or paid CA
> service to deliver their attack code through a secure channel.)

While this is all true, a secure origin at least gives us the ability
to disable the feature on a per-origin basis if we decided to do that.

I feel like I've had this conversation before...
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ambient Light Sensor API

[Martin Thomson]

On Wed, Apr 26, 2017 at 10:26 PM, Eric Rescorla  wrote:
>> Surely we can avoid this problem without being so
>> drastic?
>
>
> Perhaps, but actually designing such security measures is expensive, so
> absent some argument that this is in wide use, probably doesn't
> pass a cost/benefit test.

Yeah, after looking at the papers here, this doesn't look salvagable.
Other ways of accessing cross-origin data are all gated behind
permissions.  Given that this is in effect a camera with low
resolution and framerate, and also a screen capture device, that's the
bar the API has to meet.

Combined with low usage rates, (lower than battery status?), this
seems pretty clear-cut to me.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ambient Light Sensor API

[Martin Thomson]

I think that 60Hz is too high a rate for this.

I suggest that we restrict this to top-level, foreground, and secure
contexts.  Note that foreground is a necessary precondition for the
attack, so that restriction doesn't really help here.  Critically,
rate limit access much more than the 60Hz recommended for the
accelerometer.  5Hz might be sufficient here, maybe even lower.

Since the amount of information that can be extracted is a function of
the number of times the API is called and the accuracy of the reading,
we should consider also reducing the accuracy of the reading.  The
attack reduced its information extraction to 1 bit per reading, but
you can't assume that this is the actual limit.  Fuzzing is much
harder than it seems if your intent is to deal with an attack.  I can
walk through some strategies if someone is interested in doing this.

That all assumes that you aren't willing to add a dialog for this,
which seems like the right answer.  That said, if the mitigation
strategies - rate limiting in particular - can't be implemented in a
reasonable time-frame, I would consider preffing this off (though the
pref name suggests that there would be collateral).

On Tue, Apr 25, 2017 at 12:06 AM, Jonathan Kingston  wrote:
> As a follow up, it looks like the device motion events defined in the
> device sensors:
> http://searchfox.org/mozilla-central/source/dom/system/nsDeviceSensors.cp
> should also be restricting based on isSecureContext.
>
> The spec mentions "should take into consideration the following suggestions"
> :
> https://www.w3.org/TR/orientation-event/#security-and-privacy
>
> We don't do those measures from what I can see.
>
> Can we make the webIDL represent this requirement for requiring secure
> context instead?
>
> Thanks
> Jonathan
>
> On Mon, Apr 24, 2017 at 2:41 PM, Jonathan Kingston  wrote:
>
>> As mentioned a permission prompt isn't great.
>>
>> In it's current state it should probably be considered a "powerful
>> feature" that we can remove just for secure context. Granted this doesn't
>> fix the exploit mentioned here though.
>>
>> Freddy highlighted that the spec itself suggests the Generic Sensor API is
>> the security model which requires: https://www.w3.org/TR/generic-
>> sensor/#secure-context I can't see that as a restriction in our codebase
>> though?
>>
>> This looks like a specification violation here.
>>
>> Thanks
>> Jonathan
>>
>> On Mon, Apr 24, 2017 at 2:38 PM, Frederik Braun 
>> wrote:
>>
>>> The Ambient Light spec defers its security and privacy considerations to
>>> the generic sensors specification, which states
>>>
>>> > all interfaces defined by this specification or extension
>>> specifications must only be available within a secure context.
>>>
>>>
>>> Would we require telemetry before we restricted this to secure contexts?
>>>
>>>
>>>
>>> On 24.04.2017 15:24, Frederik Braun wrote:
>>> > Hi,
>>> >
>>> > there is a relatively recent blog post [1] by Lukasz Olejnik and Artur
>>> > Janc that explains how one can steal sensitive data using the Ambient
>>> > Light Sensor API [2].
>>> >
>>> > We ship API and its enabled by default [3,4] and it seems we have no
>>> > telemetry for this feature.
>>> >
>>> >
>>> > Unshipping for non-secure context and making it HTTPS-only wouldn't
>>> > address the attack.
>>> >
>>> > The API as implemented is using the 'devicelight' event on window.
>>> > I suppose one might also be able to implement a prompt for this, but
>>> > that doesn't sound very appealing (prompt fatigue, etc., etc.).
>>> >
>>> >
>>> > What do people think we should do about this?
>>> >
>>> >
>>> >
>>> > Cheers,
>>> > Freddy
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > [1]
>>> > https://blog.lukaszolejnik.com/stealing-sensitive-browser-
>>> data-with-the-w3c-ambient-light-sensor-api/
>>> > [2] https://www.w3.org/TR/ambient-light/
>>> > [3] It is behind the dom.sensors.enabled (sic!) flag.
>>> > [4]
>>> > http://searchfox.org/mozilla-central/source/dom/system/nsDev
>>> iceSensors.cpp
>>> >
>>>
>>> ___
>>> 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: Should &&/|| really be at the end of lines?

[Martin Thomson]

On Mon, Feb 20, 2017 at 3:18 AM, smaug  wrote:
> I don't care too much about &&/|| coding style, though the current style
> does feel easier to
> read, per the reasoning dmajor gave.

I suspect that a lot of people think this way.  While it's tempting to
suggest that arguments like "that's the way I've always done it" are
bogus, there's a value in maintaining the current set of wiring in
your brain.  I've learned to eyeball code pretty quickly over time and
changing layout risks reducing my efficiency.

I don't know if there's a material difference in this case, and like
smaug, I don't feel passionately about this.  Absent good evidence
that we're losing somehow, there is always at least some value in
retaining the current practice.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Should &&/|| really be at the end of lines?

[Martin Thomson]

On Sat, Feb 18, 2017 at 9:28 AM, Bobby Holley  wrote:
>> If our main repository is going to always be under the control of some
>> official clang-format style, it should be possible for anybody to pull the
>> repository, and use a different formatter locally with their favorite
>> style. And when pushing, their modified code could be automatically
>> reformatted with the official formatter -- Everybody feels good when
>> programming! :-)
>>
>
> Please no. That would make reviewing a nightmare.

Yes, though this is totally technically possible, it means that it is
also possible to generate the most awesome confusion.  "Line 517 is
broken, looks fine to me."
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Should &&/|| really be at the end of lines?

[Martin Thomson]

On Fri, Feb 17, 2017 at 10:39 AM, Robert O'Callahan
 wrote:
>> Using clang-format on the entire tree has the massive value of:
>
> Also, it's very liberating not having to think about formatting while
> writing code, knowing it will be automatically fixed up later. This is
> especially helpful for partially-automated changes such as mass
> find-and-replace.

NSS recently reached this point.  Formatting is checked in CI and both
David and roc are right about the benefits.  We even have a pre-commit
hook now that catches errors early.

It was only mildly disruptive getting there, but worth it.  Firefox
is, of course, bigger and more diverse, but I don't see why it
couldn't eventually reach the same point.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Exposing SSLStatus to WebExtensions (and possibly extending it)

[Martin Thomson]

I think that it is reasonable to expose this sort of information to
web extensions, and - for some things - possibly even to the web.

I don't think that we should start with nsISSLStatus directly.  Though
it does have some relevant values, we should be careful to specify -
and justify - individual values.  A short list of the things you care
about and a reason for each would be quite helpful.

On Fri, Jan 27, 2017 at 4:44 AM, Giorgio Maone  wrote:
> Hello everybody,
>
> In https://bugzilla.mozilla.org/show_bug.cgi?id=1322748#c4 David Keeler
> suggested to bring this issue up in a public forum in order to decide
> how and how much to expose of the nsISSLStatus interface and its
> dependencies to WebExtensions, considering that many Firefox add-ons use
> it either to provide enhanced security UIs  or to enforce stricter
> security policies tailored on specific use cases.
>
> Additionally, exposing also ECDHE/DHE parameters has been asked for the
> same reasons ( https://bugzilla.mozilla.org/show_bug.cgi?id=1312195 ).
>
> The most natural place to provide WebExtensions with this data is, IMHO,
> in webRequest.onBeforeSendHeaders or in an ad-hoc event (onConnect?)
> which needs anyway to be called before any HTTPS payload is actually
> exchanged on the wire.
>
> Personally (i.e. for the purposes of the Tails Download and Verify
> Extension which I maintain) I would be fine with a thin wrapper over
> nsISSLStatus and nsIX509Cert, but platform developers, security guys and
> other add-ons authors likely have different but hopefully reconcilable
> views on this matter, therefore I'm cross-posting to dev-platform,
> dev-security and dev-addons hoping for the best outcome.
>
> Cheers
>
> --
> Giorgio Maone
> https://maone.net
>
>
> ___
> 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 Implement and Ship: Large-Allocation Header

[Martin Thomson]

On Thu, Jan 19, 2017 at 10:17 AM, Michael Layzell
 wrote:
> @Martin There is a pref (dom.ipc.processCount.webLargeAllocation - default
> 2) which controls the maximum number of processes which may be allocated to
> Large-Allocation processes. Any requests past that number (firefox-globally)
> will not cause new processes to be created.

That prevents unlimited spawning of processes, but doesn't stop a site
from blocking another one from getting a new process.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Implement and Ship: Large-Allocation Header

[Martin Thomson]

On Thu, Jan 19, 2017 at 9:21 AM, Michael Layzell
 wrote:
> Security & Privacy Concerns: none

I doubt that this is true.  You have provided a way for sites to gain
a whole process to themselves, on request.  Denial of service seems
like something that would need to be considered if you intend to ship
this.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: HTML5 element

[Martin Thomson]

On Fri, Dec 23, 2016 at 6:20 PM, Boris Zbarsky  wrote:
>> I mean, the attribute is probably a lost cause
>
> Why?  Is there significant usage, or at least wide implementation, of that
> part of the API already?  The original intent said that only Chrome is
> shipping this.

Fair point.  I guess the question becomes whether Chrome compatibility
is the reason we are doing this.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: HTML5 element

[Martin Thomson]

On Fri, Dec 23, 2016 at 7:14 AM, Boris Zbarsky  wrote:
> Note that I expect that this spec was written before Promise was a thing.
> The setup where we return a value in an attribute of the element (!) is
> pretty bizarre...

Is this irredeemable?  I mean, the attribute is probably a lost cause,
but a void function can usually be safely transformed into a
Promise-bearing one.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Martin Thomson]

On Mon, Dec 19, 2016 at 8:23 PM, Gervase Markham  wrote:
> We already do network change detection now, ISTR; could we pop a
> doorhanger when we get a network change event, of the form of something
> like "maintain 'expensive data' status Y/N?"...?

No more doorhangers please.  I have no issue with providing UX around
this, but we need to be careful about how often we bother users.
Especially with things that we should be handling for them.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Martin Thomson]

On Fri, Dec 16, 2016 at 10:28 AM, Boris Zbarsky  wrote:
> 2)  Figure out a way to map the one bit of information we actually want to
> expose into some sort of values that look like the existing API. Change the
> spec as needed to allow tweaks we want to make here (e.g. to allow having
> the max speed thing not be defined or always be 0 or always +Infinity, or
> always NaN, or always 42 or something).

Patrick suggested that we send a fixed downlink (+Infinity is always
correct by the spec) always and use wifi/cellular.  I assume that we
need to pick one of those in the case that we can't/don't know, but I
like that plan.

We could create a new API as well, but I'm not sure what it would *do*.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Verifiable Claims Working Group

[Martin Thomson]

On Tue, Dec 13, 2016 at 5:56 AM, Eric Rescorla  wrote:
> Following up to myself: if the plan is really that people will have a
> single identity that they then present to everyone and that claims hang
> off, I think W3C should not standardize that.

A lot hinges on the nature of that identifier, but couldn't it be a
pseudonymous identifier, even unique to the specific transaction?

Building a set of issuers that sites are willing to trust creates a
whole new set of problems.  Say that I accept claims from the
California DMV for the purposes of age.  When you produce a document
signed by the DMV saying that you are 21, I also learn that (with high
probability) you live in California.

If which entities are trusted, that has another set of consequences.
What consequences on whether the relying party does or is able to
advertise which entities it trusts.

All of this stuff matters at the scale of the web.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Automotive Working Group

[Martin Thomson]

I'm not going to respond in detail, but I think that this quote cuts to the nub.

On Thu, Nov 24, 2016 at 10:09 PM,   wrote:
> [W3C Auto] A number of Automotive Manufacturers and Tier 1 suppliers have 
> contributed to the ideas in the specification which focusses on exposing 
> vehicle signals and data to clients in a controlled and secure manner. W3C 
> Automotive Group members have a very good understanding of vehicle 
> architectures and signals and this expertise is being supplemented by 
> security specialists within the Group, but the Group is open to contributions 
> on how security best practice can best be incorporated and/or referenced from 
> the spec. [W3C Auto]

It's clear that there is sufficient interest in pursuing this work.
That's not in question.  The concern is with the level of maturity of
the security story.  My hope is that deferring the formation of the
working group will give those involved time to gain or enlist the
necessary security expertise to do this work.  As it stands, there
isn't a strong enough demonstration that the security architecture has
been developed to enough depth for formal standards development.

A system like this needs a security architecture that has an in-depth
authentication and authorization story, doubly for anything connecting
to a CAN bus.  Some due consideration to privacy aspects wouldn't hurt
either.

For example, your response talks about security authorities, but
provides no details on how those are established, what systems are put
in place to ensure that those actors are accountable and trustworthy.
You mention shared both certificates and symmetric keys, but not the
systems for establishing proof-of-possession, and - for symmetric keys
- how those keys are agreed.  The details of the identities that are
asserted in such a system are critical in assessing a system, but
there isn't enough detail in the documents to reach any conclusions.

I have the same concerns about the protocol engineering aspects as
well, but the security aspects are what are of most concern.

> [W3C Auto] The W3C Automotive Working Group was established approx.
two years ago and has published a First Public Working Draft of the
Vehicle Signal Server Specification. [W3C Auto]

I would suggest that this was a mistake on the above grounds.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: W3C Proposed Recommendation: Webmention

[Martin Thomson]

On Fri, Nov 4, 2016 at 1:25 PM, L. David Baron  wrote:
>   W3C Editor's draft: https://webmention.net/draft/

Wow, that is an extraordinarily wordy document for something that does
so little.  It's the first I've heard of this, but it's remarkably
similar to (albeit much narrower than):

https://www.w3.org/Protocols/HTTP/Methods/Link.html
https://tools.ietf.org/html/draft-pritchard-http-links-00
and recently:
https://tools.ietf.org/html/draft-snell-link-method-12

I wouldn't bother saying anything, though, it's just yet another specification.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing navigator.buildID?

[Martin Thomson]

On Tue, Nov 1, 2016 at 11:15 PM, Aryeh Gregor  wrote:
> Taking a step back: is fingerprinting really a solvable problem in
> practice?  At this point, are there a significant fraction of users
> who can't be fingerprinted pretty reliably?  Inevitably, the more
> features we add to the platform, the more fingerprinting surface we'll
> expose.  At a certain point, we might be taking away a lot of features
> for the sake of trying to stop the unstoppable.  (I have no idea if
> this is actually true now, though.  This is a genuine question.  :) )

https://www.w3.org/2001/tag/doc/unsanctioned-tracking/

The conclusion: it's probably a lost cause, but we still shouldn't be
building more of these.

The more principled position is that we shouldn't have to rely on UA
sniffing (which this is) to determine what a browser can and cannot
do.  That there are bugs is the main reason we have these things.

Fixing the buildID to the major version (52) plus the channel
(Nightly) would be the simplest fix without adding lots of extra
complexity.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Windows XP and Vista Long Term Support Plan

[Martin Thomson]

On Sat, Oct 22, 2016 at 8:16 PM,   wrote:
> My concern is that by killing digital certificate updates and TLS updates, 
> still in use machines whose main purpose is Internet access are essentially 
> bricked.

Yep, I just designated a relatives machine to recycling on that basis.
I could have updated the OS, but they had other better options, so
we're reclaiming the space.  I know that neither option is that
pleasant, but it's not doing anyone a service to have these machines
on the internet.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: TLS 1.3 draft

[Martin Thomson]

As of Firefox 52 I intend to turn TLS 1.3 on by default. TLS 1.3 has
been developed using the existing security.tls.version.max preference
to control maximum version.

TLS 1.3 is the next version of TLS, the protocol that secures the web.
TLS 1.3 removes old and unsafe cryptographic primitives, it is built
using modern analytic techniques to be safer, it is always forward
secure, it encrypts more data, and it is faster than TLS 1.2.  TLS 1.3
also provides a 0-RTT mode which removes the round-trip of handshake
latency.  (We will not however enable 0-RTT as part of this change).

We intend to ship draft 16 of TLS 1.3 and update to 17 as we are able.
Since this is a draft version of the spec going into an ESR release,
we intend to disable the feature for the ESR.

TLS 1.3 has a number of measures that will ensure that we remain
compatible with existing servers.  We have tested for incompatibility
and found no issues (though our tests are naturally limited).

We already have support for TLS 1.3 in developer tools and the UI.

We did not previously send an intent to implement.  I’ve included
relevant details in this mail.

Chrome Canary has TLS 1.3 support, but it is behind a flag.  Also,
Cloudflare support TLS 1.3 (by request only).

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

Link to spec: https://tools.ietf.org/html/draft-ietf-tls-tls13-16
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Automotive Working Group

[Martin Thomson]

This seems to be a more specific instance of WoT.  As such, the goals
are much clearer here.  While some of the concerns with the WoT
charter apply (security in particular!), here are a few additional
observations:

Exposing the level of information that they claim to want to expose
needs more privacy treatment than just a casual mention of the PIG.

Websockets?  Protocol?  Both of these are red flags.  Protocol
development is an entirely different game to APIs and the choice of
websockets makes me question the judgment of the people involved.  Of
particular concern is how the group intends to manage interactions
with SOP.  Do they intend to allow the web at large to connect to
parts of the car?  The security architecture is worrying in its lack
of detail.

If this proceeds, the naming choice (wwwivi) will have to change.  It
is not OK to register a new GTLD (see
https://tools.ietf.org/html/rfc6761).  A similar mistake was made
recently in the IETF, and it was ugly. For people interested in the
gory details, I can provide more details offline.

On Tue, Oct 18, 2016 at 6:32 AM, L. David Baron  wrote:
> The W3C is proposing a new charter for:
>
>   Automotive Working Group
>   https://lists.w3.org/Archives/Public/public-new-work/2016Oct/0003.html
>   https://www.w3.org/2014/automotive/charter-2016.html
>
> Mozilla has the opportunity to send comments or objections through
> Monday, November 7.  However, I hope to be able to complete the
> comments by Tuesday, October 25.
>
> Please reply to this thread if you think there's something we should
> say as part of this charter review, or if you think we should
> support or oppose it.
>
> Note that this is a new working group.  I don't know of anyone from
> Mozilla being involved in the discussions that led to this charter.
>
> -David
>
> --
> 𝄞   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)
>
> ___
> 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: Proposed W3C Charter: Web of Things Working Group

[Martin Thomson]

On Thu, Oct 13, 2016 at 11:26 AM, Tantek Çelik  wrote:
> Security is the number one problem for anything "ot" (iot, wot,
> wotever),

I agree with this sentiment, but I don't think that we need to insist
that a new W3C group solve these issues.  I'm very much concerned with
the question of how a new "thing" might be authenticated, even how
clients of the thing are authenticated, those are definitely well
within their remit and it should be an important consideration.

We shouldn't hold the group responsible for the failings of the
industry at large though, no matter how egregious those failings.

> All that being said, I think we should non-formally object to the
> Proposed W3C Charter: Web of Things Working Group with reasons of:
> * insufficient incubation of security aspects
> * overall risk (greatly increased vulnerability) to the web/internet as a 
> whole
> being the reasons (with above citations).

This is probably OK.  I would start with this though:
* insufficiently precise statement of goals; needs more research and
incubation time
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web of Things Working Group

[Martin Thomson]

On Thu, Oct 13, 2016 at 6:21 AM, Benjamin Francis  wrote:
> Much more compelling is the member submission from EVRYTHNG which also forms
> the basis of the book, Building the Web of Things.

Yes, that is a much clearer articulation of a vision.  It starts going
off the rails in a few places as it gets into specifics (MUST support
all the basic HTTP verbs, WTF), but it is *much* more concrete.  I
still don't know how to bridge the gap completely, particularly when
it comes to things like identification and - dare I say it -
discovery, but you can see a potential way forward at least.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web of Things Working Group

[Martin Thomson]

On Tue, Oct 11, 2016 at 12:52 PM, L. David Baron  wrote:
> My initial reaction would be to worry about whether there's
> properly-incubated material here that's appropriate to charter a
> working group for, or whether this is more of a (set of?) research
> projects.  W3C has an existing Interest Group (not a Working Group,
> so not designed to write Recommendation-track specifications) in
> this area: https://www.w3.org/WoT/IG/ .


I share your concerns.  Looking at the work that the WoT IG has
produced, including the charter, these are highly nebulous.  It's hard
to see how the world that is imagined in their documents intersects
with the web we know (I'm actually having trouble seeing the overlap
with reality, but that could be a consequence of a lack of understand
on my part...).  That suggests need for more research, not
engineering.

Does anyone at Mozilla intend to join this working group? I see no
Mozilla members in the IG.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to put Permission API's .revoke() method behind a pref

[Martin Thomson]

On Wed, Aug 17, 2016 at 5:34 PM, Anne van Kesteren  wrote:
> Interesting, I guess I didn't realize that covered more than just
> query(). If we ship a subset of an API it probably would help to be
> clear, indeed.

Well, it only mentioned .query() explicitly, but then said "other
parts will be implemented". That's what we need to watch out for.

The discussion was negative on .request(); I guess that .revoke() was
implemented because no one objected to it specifically.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to put Permission API's .revoke() method behind a pref

[Martin Thomson]

On Wed, Aug 17, 2016 at 5:02 PM, Anne van Kesteren  wrote:
> The main problem with query as I see it is that since we haven't
> agreed on what permissions are keyed on, an application cannot really
> do anything with the answer it gets from query. E.g., communicating
> the answer with other open tabs and then attempting to use the
> permission there is futile for certain permissions. That kind of thing
> would only work if they are all origin-keyed, but some are per
> session, some are scoped to the top-level browsing context, etc.

Are you suggesting that .query() has terrible flaws or that it is
completely beyond hope of fixing?

I agree that the keys are unclear[1].  But isn't that something that
can be more easily addressed by opening an issue on the spec?

[1] At the moment, the only sensible thing that can be said is that if
you had replaced the .query() call with a call to the corresponding
API, then it would not have failed due to a permission error.  That
implies realm+instant-in-time are the keys.  This is - of course -
super-useful in the sense that it is left to speculation about how a
result might be applied to predict future behaviour.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to put Permission API's .revoke() method behind a pref

[Martin Thomson]

Sounds like a good plan.

(For those who might be wondering: .request() was never exposed.)

On Wed, Aug 17, 2016 at 2:48 PM,   wrote:
> Summary: It seems we prematurely shipped the .revoke() method on the 
> Permissions API before it was stable or deciding if we even wanted it in the 
> platform.
>
> For those that don't know it: navigator.permission.revoke() allows a site to 
> self-revoke a permission after a user has granted that permission. For 
> example, a user may grant foo.com access to geolocation, but upon signing out 
> of a site, a site might call .revoke({name:"geolocation"}) so that the next 
> user to log into the site doesn't automatically get access to geolocation (as 
> permissions are bound to origin).
>
> A few folks (who can chime in) working on the standard have raised concerns 
> about the API, so we would like to suggest we put it behind a pref for now. 
> Particularly, using in-browser user profiles can handle the above use case 
> without a site taking away a user's decision.
>
> There is consensus that .query() is beneficial, so that one can remain.
>
> Bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1295877
>
> Link to standard:
> https://w3c.github.io/permissions/#dom-permissions-revoke
>
> Platform coverage: All.
>
> Estimated or target release: Firefox 51
>
> Preference behind which this will be implemented:
> dom.permissions.revoke.enable
>
> ___
> 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: Checkin-needed requests - Please include complete information in the commit message :)

[Martin Thomson]

On Mon, Jul 11, 2016 at 2:18 PM, Xidorn Quan  wrote:
> Isn't it still necessary for people who don't yet have permission to
> push?

That suggests to me that there are missing safeguards on autoland.
Otherwise we could just enable it even for those with try access.

> I also use checkin-needed for small changes which I don't think it's
> worth to run a full testset for, to save some infra resources.

Hmm, that's an odd optimization.  I'd have thought that sheriff time
is more valuable than infra.

On Mon, Jul 11, 2016 at 2:48 PM, Nils Ohlmeier  wrote:
> Another use case for checkin-needed are probably sec bugs, as you can’t use 
> mozreview for them AFAIK.

As for sec-critical bugs, as long as the change is going to hit the
tree with the bug number in it, then I don't see why it can't go via
mozreview.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Checkin-needed requests - Please include complete information in the commit message :)

[Martin Thomson]

Is now the right time to start talking about retiring checkin-needed,
or is it still heavily used?

On Sat, Jul 9, 2016 at 4:58 AM, Gregory Szorc  wrote:
> On Fri, Jul 8, 2016 at 11:39 AM, Felipe G  wrote:
>
>> Is there a way to make the checkin-needed flag generate a template comment
>> (like the approval-* ones do) with something like this? (Or encourage
>> people to use the per-patch checkin? flag)
>>
>> """
>> Has this patch been through try? [ Yes / No, I believe it's not necessary ]
>> Does this patch contain the correct author / commit message? [ Yes
>> (preferred) / No, but I'm providing it here: ]
>> Are there any other dependencies that should be landed together? [ Yes, ...
>> / No ]
>> """
>>
>> Probably just asking if the information is present will reduce the number
>> of requests made without it
>>
>
> My knee jerk reaction is we shouldn't bother: MozReview handles most of
> this "validation" and usage of MozReview has been steadily increasing.
> We're trending towards a world where the only patches on Splinter are for
> security-sensitive bugs (MozReview can't handle those yet) and the people
> submitting patches to security bugs tend to know what they're doing so I
> don't think these added checks will help.
>
>
>>
>> On Fri, Jul 8, 2016 at 10:47 AM, Ryan VanderMeulen 
>> wrote:
>>
>> > FWIW, there's also an MDN page that documents a lot of this as well:
>> >
>> >
>> https://developer.mozilla.org/en-US/docs/Mercurial/Using_Mercurial#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F
>> >
>> > -Ryan
>> >
>> >
>> > On 7/8/2016 2:32 AM, Carsten Book wrote:
>> >
>> >> Hi,
>> >>
>> >> someone might not know that doing checkins for checkin-needed request is
>> >> not automated yet and completely a fully human task :) (no we Sheriffs
>> are
>> >> not bots ;)
>> >>
>> >> It would help us a lot if a checkin needed request would contain
>> complete
>> >> Author/Patch information like:
>> >>
>> >>
>> >>- Author (use the information from their Bugzilla account if needed)
>> >>with Name *and *Emailadress.
>> >>- Bug number
>> >>- Commit message (keeping in mind that the commit message should be a
>> >>brief description of what the patch is *doing*)
>> >>   - Format should be something like "Bug 123456 - Add a null check
>> to
>> >>   XYZ to avoid a crash. r=somebody"
>> >>
>> >>
>> >> And also if there is a specific sequence/dependency you want to checkin
>> >> the
>> >> patches it would help also a lot  if you could make a short comment in
>> the
>> >> Bug like please checkin part x then patch y or like first bug 123 then
>> >> this
>> >> bug and then bug 8910.
>> >>
>> >> This would help us a lot :)
>> >>
>> >> Thanks!
>> >>
>> >> - Tomcat
>> >>
>> >>
>> > ___
>> > 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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: MXR permanently offline, please transition to DXR

[Martin Thomson]

On Fri, Jul 1, 2016 at 9:55 AM, Robert O'Callahan  wrote:
> In theory responses 301 and 308 mean "permanent redirect" so the browser
> could do that for those responses.

Those would only work for as long as the 3xx is remembered, and it
wouldn't work for /x if you have only seen /y redirect.

To gps' question, yes, such a feature would be awesome, but it's
hairy.  I might be working on something that would do that, though for
almost unrelated reasons.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web of Things Interest Group

[Martin Thomson]

On Thu, Jun 23, 2016 at 3:19 AM, Anne van Kesteren  wrote:
> We should just let them do their thing and do our thing elsewhere.

This seems like a reasonable plan.  Unless and until someone thinks
that a course correction is feasible, or decides that it's worth
trying.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Generating Visual Studio project files by default

[Martin Thomson]

On Tue, May 24, 2016 at 7:29 PM, Jeff Gilbert  wrote:
> What's the build-time impact of this?

The implicit question being, if this impact is non-zero, can I turn it
off?  Also, does it make any sense to do this on try machines?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

[Martin Thomson]

On Tue, Apr 26, 2016 at 6:08 PM, Jonas Sicking  wrote:
> Limiting this to aurora builds might make the most sense here since
> that's what we're pushing as the build that developers should use.

I'm OK with that; that's why I asked here.

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

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

[Martin Thomson]

On Tue, Apr 26, 2016 at 4:10 PM, Xidorn Quan  wrote:
> Could we probably restrict it to non-release builds (aurora and nightly)
> rather than restrict them to debug builds only? Debug builds are harder to
> get, and are slow.

That was suggested, but we decided against it in bug 1188657.  I think
that we'd be happy to land a patch that restored this if there was
enough demand.  Maybe I'm unusual, but I just run debug builds when I
want to investigate this sort of thing.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to (sort of) unship SSLKEYLOGFILE logging

[Martin Thomson]

In NSS, we have landed bug 1183318 [1], which I expect will be part of
Firefox 48.

This disables the use of the SSLKEYLOGFILE environment variable in
optimized builds of NSS.  That means all released Firefox channels
won't have this feature as it rides the trains.

This feature is sometimes used to extract TLS keys for decrypting
Wireshark traces [2].  The landing of this bug means that it will no
longer be possible to log all your secret keys unless you have a debug
build.

This is a fairly specialized thing to want to do, and weighing
benefits against risks in this case is an exercise in comparing very
small numbers, which is hard.  I realize that this is very helpful for
a select few people, but we decided to take the safe option in the
absence of other information.

(I almost forgot to send this, but then [3] reminded me in a very
timely fashion.)

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1183318
[2] https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format
[3] https://lists.mozilla.org/pipermail/dev-platform/2016-April/014573.html
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal: use nsresult& outparams in constructors to represent failure

[Martin Thomson]

On Fri, Apr 22, 2016 at 1:05 AM, Nicholas Nethercote
 wrote:
> The third example I looked at was CycleCollectedJSRuntime. Again
> problems, specifically this line in Init():
>
>   mOwningThread->SetScriptObserver(this);

Others have already said what I would have here generally, but this
example is a good one to show.  Note that this happens very early in a
fairly complex initialization.  In general, doing this sort of thing
means that you have released a pointer to an incompletely initialized
object.  That means that whatever partial initialization might happen,
all methods on the class need to handle the state the object might be
in.

It might be that this call could be deferred until after the fallible
stuff happens, but I don't understand this code well-enough to know
for certain.  I certainly hope that the success of the Initialize
function doesn't depend on receiving upcalls during the process.

(As an aside, when I worked in Java, we had static analysis tools that
prevented us from passing `this` to others during constructors.  It's
a nice rule to have.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal: use nsresult& outparams in constructors to represent failure

[Martin Thomson]

I prefer the fallible, if failed return null else return new pattern
myself also.  With a little RAII, it keeps manual cleanup to a
minimum.

On Thu, Apr 21, 2016 at 8:24 PM, Nicholas Nethercote
 wrote:
> - It doesn't appear to work with stack-allocated objects?

The advantage with a heap-allocated object is that it exists or not.

Sticking something on the stack has advantages, is the intent here to
allow the creation of stack objects with these properties, because it
seems like Maybe<> or something Maybe<>-like is the best choice there,
maybe (hah) following the same pattern.

> - I suspect that in some heap-allocated objects it will be hard to do
> the fallible parts without having an object of the relevant type. I
> don't have specific examples, just a hunch.

I'm not aware of any way that necessary state can't be fully
established before constructing an object.  If you find a way in which
this is possible, please let me know.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Martin Thomson]

On 17 Apr 2016 2:37 AM, "Haik Aftandilian"  wrote:
>
> Sites might depend on a combination of https and non-https cookies and
then
> act strangely when a user returns to the site with only the https cookies.

This is also known as a security vulnerability. See
https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/zheng
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Martin Thomson]

I would like to see other browsers on board before taking on these risks.

And a lot more testing.

For instance, is there a way to collect telemetry on the impact of
such a change without actually implementing it?  Does restricting it
to 3rd party requests change things?

On Fri, Apr 15, 2016 at 1:42 AM, Benjamin Smedberg
 wrote:
> I don't see how we can do this by default without harming our users. We can
> be confident that this will break persistent login for lots of sites. I
> appreciate the goal of moving HTTPS forward, but we are not in a position
> where we our marketshare would force changes to the web ecosystem.
>
> Before turning this on by default, could we try exposing this to advanced
> users (perhaps via test pilot or a similar extension), and try out some UI
> options so that users have some ability to override this?
>
> Or could we explore doing this first only for 3rd-party requests.
>
> I oppose this proposal as written.
>
> --BDS
>
>
> On Thu, Apr 14, 2016 at 4:54 AM, Chris Peterson 
> wrote:
>
>> Summary: Treat cookies set over non-secure HTTP as session cookies
>>
>> Exactly one year ago today (!), Henri Sivonen proposed [1] treating
>> cookies without the `secure` flag as session cookies.
>>
>> PROS:
>>
>> * Security: login cookies set over non-secure HTTP can be sniffed and
>> replayed. Clearing those cookies at the end of the browser session would
>> force the user to log in again next time, reducing the window of
>> opportunity for an attacker to replay the login cookie. To avoid this,
>> login-requiring sites should use HTTPS for at least their login page that
>> set the login cookie.
>>
>> * Privacy: most ad networks still use non-secure HTTP. Content sites that
>> use these ad networks are prevented from deploying HTTPS themselves because
>> of HTTP/HTTPS mixed content breakage. Clearing user-tracking cookies set
>> over non-secure HTTP at the end of every browser session would be a strong
>> motivator for ad networks to upgrade to HTTPS, which would unblock content
>> sites' HTTPS rollouts.
>>
>> However, my testing of Henri's original proposal shows that too few sites
>> set the `secure` cookie flag for this to be practical. Even sites that
>> primarily use HTTPS, like google.com, omit the `secure` flag for many
>> cookies set over HTTPS.
>>
>> Instead, I propose treating all cookies set over non-secure HTTP as
>> session cookies, regardless of whether they have the `secure` flag. Cookies
>> set over HTTPS would be treated as "secure so far" and allowed to persist
>> beyond the current browser session. This approach could be tightened so any
>> "secure so far" cookies later sent over non-secure HTTP could be downgraded
>> to session cookies. Note that Firefox's session restore will persist
>> "session" cookies between browser restarts for the tabs that had been open.
>> (This is "eternal session" feature/bug 530594.)
>>
>> To test my proposal, I loaded the home pages of the Alexa Top 25 News
>> sites [2]. These 25 pages set over 1300 cookies! Fewer than 200 were set
>> over HTTPS and only 7 had the `secure` flag. About 900 were third-party
>> cookies. Treating non-secure cookies as session cookies means that over
>> 1100 cookies would be cleared at the end of the browser session!
>>
>> CONS:
>>
>> * Sites that allow users to configure preferences without logging into an
>> account would forget the users' preferences if they are not using HTTPS.
>> For example, companies that have regional sites would forget the user's
>> selected region at the end of the browser session.
>>
>> * Ad networks' opt-out cookies (for what they're worth) set over
>> non-secure HTTP would be forgotten at the end of the browser session.
>>
>> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1160368
>>
>> Link to standard: N/A
>>
>> Platform coverage: All platforms
>>
>> Estimated or target release: Firefox 49
>>
>> Preference behind which this will be implemented:
>> network.cookie.lifetime.httpSessionOnly
>>
>> Do other browser engines implement this? No
>>
>> [1]
>> https://groups.google.com/d/msg/mozilla.dev.platform/xaGffxAM-hs/aVgYuS3QA2MJ
>> [2] http://www.alexa.com/topsites/category/Top/News
>> ___
>> 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: Announcing MozillaBuild 2.2.0 Release

[Martin Thomson]

On Wed, Mar 30, 2016 at 12:41 PM, Xidorn Quan  wrote:
> I'd suggest you use https instead, it seems to work with ftp.mozilla.org :)

Indeed.  Don't drop the scheme entirely either, since Firefox attempts
to use FTP, which isn't available on that server.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Old XUL, deprecated Error Console

[Martin Thomson]

On Wed, Mar 23, 2016 at 10:59 PM, Philip Chee  wrote:
> Thunderbird cannot migrate (easily). The only functionality in Devtools
> that they currently can use is the Debugger (as a remote client).

If they are alone, then maybe they might consider adoption.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: W3C WebAppSec credentialmanagement API

[Martin Thomson]

I don't think that there was any misunderstanding in what it is that
is being proposed, just disagreement about cost-benefit.

On Mon, Mar 14, 2016 at 8:02 PM, Mike West  wrote:
> Websites use passwords today. While I agree that we can and should be
> working on something better, I don't think that we should overlook small
> improvements in the status quo. We can give users a better experience on
> their favourite sites if we allow developers to bypass status quo
> heuristics, and we keep users safer if we mitigate some of the XSS risks of
> password managers today. I think this API does both, and is worth
> experimenting with to see if it's a framework we can build upon.

Maybe it's a value thing, I don't see that gold-plating this
experience is going to make a difference commensurate with the cost.
The fetch API changes are the core of the purported benefit, and that
turns out to be a non-trivial thing, with the added cost of indefinite
support for a feature we don't really want in support of a mechanism
that isn't that great.

The actual benefit is something that is only realized once a site puts
in the effort required.  That is small, yes, but we're seeing sites
actively avoid password managers, hence the aggressive heuristics, and
rAC is much more likely to work for that, since it's implemented and
deployed already.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform