Re: Intent to unship AppCache

[Jonathan Kingston]

I spoke to some folks who work on Chrome and they suggested because of
their larger usage numbers there wasn't a concrete timeline that they were
working towards, however they think there is an active plan to exchange
appcache for service worker on some Google products they have which will
aid in it's removal in the browser.

Due to the code freeze we should increase all those version numbers by one
in my original email, however I believe we should continue with this plan:
- As our usage numbers are much lower.
- Appcache is unique feature in that it's largely a progressive
enhancement, so removing it doesn't break the web as a whole.
- Removing this code is a bigger benefit to Firefox users from a
performance and security standpoint.

Thanks

On Thu, Aug 22, 2019 at 2:45 PM Andrew Overholt 
wrote:

> It's been a long time coming :) Do you know if Chrome plans to drop
> support, too?
>
> On Wed, Aug 21, 2019 at 5:01 PM Jonathan Kingston  wrote:
>
>> The design of AppCache brings many problems to the web platform from a
>> performance and security perspective. Service workers have long solved the
>> same use cases as AppCache.
>>
>> Removal of this code would bring a large reduction of code and complexity
>> that is largely unmaintained.
>>
>> History
>>
>> Four years ago, in Firefox 44, we marked the API as deprecated[1].
>>
>> Back last year in Firefox 62, we disabled insecure AppCache and Chrome
>> followed suit[2].
>>
>> Safari 11.1 added support for Service Workers, which are a replacement
>> technology [3].
>>
>> Metrics
>>
>> Chrome measures a few different metrics here which suggest 2.3%[4] of
>> secure page loads attempt to use the document visible API whilst only
>> 0.27%[5] actually use the offline cache.
>>
>> Firefox metrics suggest around 0.01% of pages are using an AppCache[6]
>> however we don’t have a distinct metric for the API usage.
>>
>> The last blocker for a removal was usage of AppCache by some Microsoft
>> online products.  I’m enquiring into if this is still applicable and also
>> want to ensure with this rollout plan that we don’t break these when the
>> user has an online connection.
>>
>> Implementation
>>
>> Bug where the code will be implemented[7].
>>
>> Plan
>>
>>-
>>
>>In Firefox 70, Remove the previous preference
>>“browser.cache.offline.insecure.enable” and related code, forcing all
>> of
>>the APIs to only ever be available over Secure Contexts despite user
>>choice. Due to the insecure nature of insecure context AppCache it is a
>>good time now to remove this fully.
>>
>>
>>-
>>
>>Create a new preference that disables only the storage and use of
>>AppCache data whilst permitting access to the dom property
>>window.applicationCache and the “OfflineResourceList” interface.
>>-
>>
>>   Disable access in Nighty and beta for 70 for two releases before
>>   disabling for all other releases in 72.
>>   -
>>
>>   Once storage is disabled in all releases:
>>   -
>>
>>  Disable the API access in Nightly and beta via the existing
>>  preference (browser.cache.offline.enable) in version 72.
>>  -
>>
>>  Wait two releases and then disable in all releases in Firefox 74.
>>
>>
>> This staged removal of AppCache is to reduce the risk of web compatibility
>> issues of the API being accessible to page scripts. Despite the API
>> presence it won’t have any ability to use the cache. We may look into
>> shimming these APIs depending on how the rollout plan goes.
>>
>> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1204581
>>
>> [2]
>>
>> https://groups.google.com/forum/#!msg/mozilla.dev.platform/qLTTpdzcDkw/WKJeq-4HAQAJ
>>
>> [3]
>>
>> https://developer.apple.com/library/archive/releasenotes/General/WhatsNewInSafari/Articles/Safari_11_1.html
>>
>>
>> [4] https://www.chromestatus.com/metrics/feature/timeline/popularity/1248
>>
>> [5] https://www.chromestatus.com/metrics/feature/timeline/popularity/1246
>>
>> [6] https://mzl.la/2TKRbvA
>> [7] https://bugzilla.mozilla.org/show_bug.cgi?id=1237782
>> ___
>> 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

Intent to unship AppCache

[Jonathan Kingston]

The design of AppCache brings many problems to the web platform from a
performance and security perspective. Service workers have long solved the
same use cases as AppCache.

Removal of this code would bring a large reduction of code and complexity
that is largely unmaintained.

History

Four years ago, in Firefox 44, we marked the API as deprecated[1].

Back last year in Firefox 62, we disabled insecure AppCache and Chrome
followed suit[2].

Safari 11.1 added support for Service Workers, which are a replacement
technology [3].

Metrics

Chrome measures a few different metrics here which suggest 2.3%[4] of
secure page loads attempt to use the document visible API whilst only
0.27%[5] actually use the offline cache.

Firefox metrics suggest around 0.01% of pages are using an AppCache[6]
however we don’t have a distinct metric for the API usage.

The last blocker for a removal was usage of AppCache by some Microsoft
online products.  I’m enquiring into if this is still applicable and also
want to ensure with this rollout plan that we don’t break these when the
user has an online connection.

Implementation

Bug where the code will be implemented[7].

Plan

   -

   In Firefox 70, Remove the previous preference
   “browser.cache.offline.insecure.enable” and related code, forcing all of
   the APIs to only ever be available over Secure Contexts despite user
   choice. Due to the insecure nature of insecure context AppCache it is a
   good time now to remove this fully.


   -

   Create a new preference that disables only the storage and use of
   AppCache data whilst permitting access to the dom property
   window.applicationCache and the “OfflineResourceList” interface.
   -

  Disable access in Nighty and beta for 70 for two releases before
  disabling for all other releases in 72.
  -

  Once storage is disabled in all releases:
  -

 Disable the API access in Nightly and beta via the existing
 preference (browser.cache.offline.enable) in version 72.
 -

 Wait two releases and then disable in all releases in Firefox 74.


This staged removal of AppCache is to reduce the risk of web compatibility
issues of the API being accessible to page scripts. Despite the API
presence it won’t have any ability to use the cache. We may look into
shimming these APIs depending on how the rollout plan goes.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1204581

[2]
https://groups.google.com/forum/#!msg/mozilla.dev.platform/qLTTpdzcDkw/WKJeq-4HAQAJ

[3]
https://developer.apple.com/library/archive/releasenotes/General/WhatsNewInSafari/Articles/Safari_11_1.html


[4] https://www.chromestatus.com/metrics/feature/timeline/popularity/1248

[5] https://www.chromestatus.com/metrics/feature/timeline/popularity/1246

[6] https://mzl.la/2TKRbvA
[7] https://bugzilla.mozilla.org/show_bug.cgi?id=1237782
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship X-Frame-Options: Allow-From

[Jonathan Kingston]

Allow-From is a value that is currently only supported by Firefox and
Internet Explorer/Edge. With Edge moving to a Chromium source base this
will mean Firefox will be the only implementer of this part of the standard.

Chrome marked an issue to support allow-from as wont-fix:

https://bugs.chromium.org/p/chromium/issues/detail?id=129139

Webkit also marked the bug as wont-fix around the same time frame-ancestors
was added to their browser:

https://bugs.webkit.org/show_bug.cgi?id=94836

In a draft version of the standard there was an AllAncestors flag that was
never added to the specification:
https://tools.ietf.org/id/draft-gondrom-frame-options-02.txt this would
have permitted web servers to prevent framing across all of the ancestor
chain. The standard never made it clear if the whole ancestor chain should
be inspected and so implementations have varied.

Chrome and Firefox now(https://bugzilla.mozilla.org/show_bug.cgi?id=725490)
implement this as the default for all X-Frame-Options SAMEORIGIN header
responses. However this same behaviour wasn’t added to Allow-From as Chrome
doesn’t implement the Allow-From value. This would cause Firefox to cause
breakage on sites that worked on Chrome for a limited advantage in security.

Because of the confusing implementation of how Allow-From is implemented in
contrast to SameOrigin, I think it makes sense to suggest that all
developers should be instead be using the Frame-Ancestors directive in CSP
which is a viable alternative that is consistently implemented across all
modern browsers.

Additionally this feature isn’t covered by cross browser web platform tests.

Currently Chrome issues a console warning for an X-Frame-Options header
that has the Allow-From keyword or anything it is unable to parse, this
patch will also implement the warning for developers. In the case of a
Allow-From Firefox will also fail open in the same manner, permitting
framing by any domain.

Work will be tracked in:
https://bugzilla.mozilla.org/show_bug.cgi?id=1301529
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship:

[Jonathan Kingston]

Client certificates are manually importable in about:preferences > Privacy
& security > View Certificates > import
Not much has changed since this article:
https://www.jscape.com/blog/firefox-client-certificate however we should
improve our support articles before this lands in release.

On Fri, Jun 14, 2019 at 12:02 PM Henri Sivonen  wrote:

> On Fri, Jun 14, 2019 at 1:24 PM Jonathan Kingston  wrote:
> > Most of the use cases are resolved by web crypto or u2f.
>
> Thanks for the removal. Do we have enterprise Web developer-facing
> documentation on 1) how TLS client cert enrollment should work now or
> 2) if there is no in-browser client cert enrollment path anymore, what
> concretely should be used instead? (To be clear: I'm not a fan of
> client certs, and I'm not requesting that there be an enrollment
> path.)
>
> --
> Henri Sivonen
> hsivo...@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

Intent to unship:

[Jonathan Kingston]

 has been removed in Chrome since version 56 in Jan 2017 and never
was implemented in Internet Explorer or Edge. The element has also been
removed from the HTML specification: https://github.com/w3c/html/issues/43
Firefox's implementation never matched the specification completely as the
parser changed the elements into a select with some hacks to make it work:
https://bugzilla.mozilla.org/show_bug.cgi?id=101019

The element didn't have clear usage numbers and also the user experience
wasn't clear at all (The firefox implementation was a select box with "high
grade" and "medium grade" options). It also poses a privacy risk as another
fingerprint vector. Most of the use cases are resolved by web crypto or u2f.

With code that was unmaintained for many years in Firefox it poses a unique
risk into nss and also including a DoS vector against the parent process.

The removal implementation is to change the parser to behave similar to
other void elements but also behave like HTMLUnknownElement. The
appropriate web platform tests that were put in place by Chrome developers
are now conforming to their implementation.

Keygen will be removed from Firefox 69.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1315460

Note: This is a post-hoc unship notice, this wasn't intentional I thought I
had already filed when I worked on this initially.

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

Re: Intent to unship xml:base

[Jonathan Kingston]

Sorry I forgot to link to the bug itself:
https://bugzilla.mozilla.org/show_bug.cgi?id=903372 which hasn't changed
from last time.

On Thu, Nov 29, 2018 at 8:18 PM Jonathan Kingston  wrote:

>
> Since the deprecation of this feature the usage of this feature has
> reached near 0 numbers in our usage counters[1]. 0.003% based on 64 beta [2]
>
> The specification has removed xml:base many years ago and this change has
> an advantage of code simplification and also reduces the need to compute
> base paths in the DOM.
>
> IE, Safari and Chrome don’t support this feature so we should remove this
> feature from the web platform given it’s declining usage.
>
> Mozilla attempted to remove this before[3] previously however the feed
> reader appears to have been a blocker for it’s removal due to xml:base
> usage within RSS feeds. However this has since been removed and no longer a
> blocker.
>
> Kind regards
>
> Jonathan
>
> [1]
> https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2018-11-26&include_spill=0&keys=__none__!__none__!__none__&max_channel_version=nightly%252F65&measure=USE_COUNTER2_DEPRECATED_XMLBaseAttribute_DOCUMENT&min_channel_version=nightly%252F62&processType=*&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2018-10-22&table=0&trim=1&use_submission_date=0
>
> [2]
> http://georgf.github.io/usecounters/#kind=page&group=DEPRECATED&channel=beta&version=64
>
> [3]
> https://groups.google.com/forum/#!topic/mozilla.dev.platform/1JDnJWefe1E/discussion
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship xml:base

[Jonathan Kingston]

Since the deprecation of this feature the usage of this feature has reached
near 0 numbers in our usage counters[1]. 0.003% based on 64 beta [2]

The specification has removed xml:base many years ago and this change has
an advantage of code simplification and also reduces the need to compute
base paths in the DOM.

IE, Safari and Chrome don’t support this feature so we should remove this
feature from the web platform given it’s declining usage.

Mozilla attempted to remove this before[3] previously however the feed
reader appears to have been a blocker for it’s removal due to xml:base
usage within RSS feeds. However this has since been removed and no longer a
blocker.

Kind regards

Jonathan

[1]
https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2018-11-26&include_spill=0&keys=__none__!__none__!__none__&max_channel_version=nightly%252F65&measure=USE_COUNTER2_DEPRECATED_XMLBaseAttribute_DOCUMENT&min_channel_version=nightly%252F62&processType=*&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2018-10-22&table=0&trim=1&use_submission_date=0

[2]
http://georgf.github.io/usecounters/#kind=page&group=DEPRECATED&channel=beta&version=64

[3]
https://groups.google.com/forum/#!topic/mozilla.dev.platform/1JDnJWefe1E/discussion
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: Element.toggleAttribute

[Jonathan Kingston]

Many JavaScript libraries exist to toggle attributes in the DOM. By moving
this to the web platform we will simplify the boilerplate developers have
to use.

This method will behave similar to Element.classList.toggle, this will
allow developers to pass an argument of the attribute to toggle:

element.toggleAttribute(“disabled”);

It also permits an optional second argument for the state of the boolean to
set:

inputElement.toggleAttribute(“checked”, isChecked);

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1469592

Link to standard: https://dom.spec.whatwg.org/#dom-element-toggleattribute

Platform coverage: This will be exposed to all platforms.

Estimated or target release: Firefox 63

Is this feature enabled by default in sandboxed iframes? N/A

DevTools bug: N/A

Do other browser engines implement this? Yes

Chrome intent to ship:
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/mAWBTaANvmE/OgaCRH04BAAJ

Edge are considering
https://github.com/whatwg/dom/issues/461#issuecomment-398206390

Browsers bugs:

https://bugs.chromium.org/p/chromium/issues/detail?id=854960

https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/17981545/

https://bugs.webkit.org/show_bug.cgi?id=186883

web-platform-tests: https://github.com/web-platform-tests/wpt/pull/11603

Secure contexts:

This feature isn’t restricted to Secure Contexts, this is mostly due to
providing similar behaviour with other element APIs such as hasAttribute
and setAttribute. There aren’t any increased risks in exposing this API to
insecure contexts and the behaviour can easily be implemented in a
JavaScript shim. It seems overly onerous on the web to mandate
SecureContext only for this when it could cause unexpected behaviour to
remove this API on an insecure connection.


In Firefox 63 I intend to turn Element.toggleAttribute on by default. Other
UAs are interested in implementing this feature as highlighted in the
standards thread: https://github.com/whatwg/dom/issues/461.

Bug implementing and enabling this feature: (
https://bugzilla.mozilla.org/show_bug.cgi?id=1469592)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Unship: Application Cache over Insecure Contexts

[Jonathan Kingston]

As the removal has rode the trains through Beta without issue I'm going to
remove AppCache over insecure contexts for stable as originally stated for
62.

The work is happening here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1460478

Mike west did a wonderful job of adding web-platform-tests thank you!

https://github.com/w3c/web-platform-tests/commit/bf17459a71ff4d1ea280bae54dd046ecf86e0628



On Fri, Feb 2, 2018 at 2:58 PM, Jonathan Kingston  wrote:

> This has now landed into central and appears to be sticking:
> https://www.fxsitecompat.com/en-CA/docs/2018/support-for-
> application-cache-on-insecure-sites-has-been-deprecated/
>
> I have filed a follow up bug to remove "OfflineResourceList" interface we
> use: https://bugzilla.mozilla.org/show_bug.cgi?id=1435261
>
> Also Anne filed a bug on the standard as it appears other browsers are
> interested now in doing the same: https://github.com/whatwg/
> html/issues/3440
>
> This also means we can move the tests into Web Platform Tests to ensure
> all browsers implement the same.
>
>
> On Fri, Jan 19, 2018 at 6:55 PM, Jonathan Kingston 
> wrote:
>
>> > Its been suggested before that we could leave the applicationCache
>> global in place, but just make it do nothing in insecure contexts.
>>
>> I did see this idea of keeping the applicationCache global in one of the
>> bugs, I think if we have breakage we could try this as a follow up piece of
>> work along with other approaches like expiring the cache more often.
>>
>> On Fri, Jan 19, 2018 at 5:47 PM, Ben Kelly  wrote:
>>
>>> On Fri, Jan 19, 2018 at 12:26 PM, Mike Taylor  wrote:
>>>
>>>> > When the pref is set to false the API will be removed:
>>>> >
>>>> >   -
>>>> >
>>>> >   window.applicationCache will be removed
>>>> >   -
>>>> >
>>>> >   The cache service Firefox implements for AppCache will be disabled
>>>> over
>>>> >   Insecure Contexts
>>>> >
>>>> >
>>>> > When the pref is set to true the code will produce an additional
>>>> developer
>>>> > console warning about the removal timeline.
>>>> >
>>>> > In Nightly and Early beta for 60; the pref will be set to false
>>>> removing
>>>> > the API.
>>>>
>>>> It will be interesting to see if we get reports of pages (that don’t
>>>> feature test) throwing with the missing applicationCache global. A few
>>>> years (and laptops) ago I had done some site corpus grepping — I’ll see if
>>>> I can find any of that data.
>>>>
>>>
>>> Its been suggested before that we could leave the applicationCache
>>> global in place, but just make it do nothing in insecure contexts.
>>>
>>
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship http-equiv cookies

[Jonathan Kingston]

Meta tags provide equivalent behaviour to sending HTTP headers via the
“http-equiv” attribute.

Set-Cookie can be used to provide cookies to the user via this attribute:


However this behaviour isn’t restrictable via a Content Security Policy.
This gives an attacker the ability to change a users cookies via an XSS
exploit and also fixate session cookies.

Impact on the Web:

The HTML specification has removed this behaviour:

https://github.com/whatwg/html/pull/3649

Web platform tests:

https://github.com/w3c/web-platform-tests/blob/master/cookies/meta-blocked.html

Chrome removed in version 65 and it appears Edge has implemented the
changes to land in the next release.

The usage of the feature is intermittent according to Chrome: “shows up on
~0.02% of pages, with intermittent spikes up to ~0.06%. Cloudflare's error
page seems like a reasonable explanation of this behavior”.

Chrome’s intent to deprecate:
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/0sJ8GUJO0Dw/iMmcXLIGBAAJ

Chrome code: https://bugs.chromium.org/p/chromium/issues/detail?id=767813

Removal implementation:

The rollout strategy is to disable via a preference and let it ride the
releases to stable.

Firefox will remove access to this feature in Firefox 62

The work will commence in:
https://bugzilla.mozilla.org/show_bug.cgi?id=1457503

Kind regards

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

Re: Intent to ship experimental Mixed Content upgrading (Nightly only)

[Jonathan Kingston]

This experiment has ended early so we can add some more telemetry to decide
on the next steps here. I will send out a new notice when we do the next
update to this.

On Wed, Feb 21, 2018 at 6:54 PM, Jonathan Kingston  wrote:

>
> We are experimenting with ways to eliminate insecure content on secure
> pages, while increasing HTTPS adoption. With bug 1435733
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1435733>, we are adding an
> experimental pref to upgrade all mixed passive content. The pref is enabled
> in Nightly-only by default.
>
> Mixed passive content[1] currently gets loaded in HTTPS pages with a
> degraded security UI - a grey padlock with a yellow triangle over it. With
> this change, we will upgrade HTTP mixed passive content (images and media)
> to HTTPS on secure pages. If the resource doesn’t exist over HTTPS, it will
> fail to load. The security UI will show the green lock, since no insecure
> content was loaded on the page.
>
> The categorization of mixed passive content we are using is the same as
> the one defined in the  Mixed Content Specification[2]. For example srcset
> and  won’t be upgraded.
>
> Chrome is currently also working to experiment in this area as a plan for
> a new version of the Mixed Content Specification[3].
>
> The preference to disable this is: 
> "security.mixed_content.upgrade_display_content"
> which will be enabled in Nighty by default for two weeks. The code will
> remain in Firefox.
>
> Developers and Nightly users can see which content is upgraded in the
> developer console[4].
>
> We would love to hear feedback and receive breakage reports.  Please file
> bugs here https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&;
> component=DOM%3A%20Security
>
>
> [1] https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content
>
> [2] https://w3c.github.io/webappsec-mixed-content/
>
> [3] https://github.com/mikewest/webappsec-mixed-content/blob/
> master/proposed-level-2-roadmap.md
>
> [4] https://imgur.com/Ig5QttW
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove Ambient Light and Proximity sensor APIs

[Jonathan Kingston]

As an update here the code has landed in 60 from
https://bugzilla.mozilla.org/show_bug.cgi?id=1359076

This adds:
- Deprecation warnings for DeviceOrientation and DeviceMotion sensors.
- Deprecation errors for AmbientLight and Proximity sensors.
- Preferences to control all 4 sensors independently:
  - "device.sensors.ambientLight.enabled" - devicelight event and
DeviceLightEvent constructor.
  - "device.sensors.proximity.enabled" - deviceproximity, userproximity
events and  DeviceProximityEvent and UserProximityEvent constructors.
 - "device.sensors.motion.enabled" - devicemotion event and
DeviceMotionEvent constructor.
 - "device.sensors.orientation.enabled" - deviceorientation event and
DeviceOrientationEvent constructor.
- In Nightly and Early beta releases the proximity and light sensors are
disabled by default.

My plan is to deprecate light and proximity sensors in Stable Firefox in
version 62 if no issues arise.

Please reach out if you have any questions or concerns.

Thanks
Jonathan

On Tue, Dec 19, 2017 at 7:01 AM, Anne van Kesteren  wrote:

> On Mon, Dec 18, 2017 at 7:36 PM, Gervase Markham  wrote:
> > appear.in, which supports both audio and video calling via WebRTC, works
> > in Firefox for Android, although performance is not awesome on my Z3C
> > Compact.
> >
> > It does not blank the screen when you place the device to your ear.
>
> There might be more secure ways we can address this use case. E.g.,
> having a dedicated signal just for that, perhaps only given if the
> user already granted access to the microphone and such.
>
> (And if something does require the full power of the proximity API, we
> should first work out how to expose it securely. I'm sure folks can
> come up with use cases for running arbitrary code as root too, but
> that doesn't mean we can offer it.)
>
>
> --
> 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: Intent to ship: Treating object subrequests as mixed active content

[Jonathan Kingston]

As a quick follow up we added a deprecation notice into 60 with
https://bugzilla.mozilla.org/show_bug.cgi?id=1441794 this will ride the
trains and provide more telemetry on the breakage.
There is a little more breakage than we would like so adding this warning
provides page and frame breakage rates too.

I suspect that we will make this change in stable 62 but we won't know
until late Beta of these numbers.

On Mon, Nov 27, 2017 at 5:11 PM, Jonathan Kingston  wrote:

> My understanding is all other browsers will still would load this request.
>
> Chrome marks this as Mixed Passive and warns in the console whilst the
> request still can be seen in the network panel. I was only testing with a
> self signed certificate so unsure if the URL bar would display as "Not
> Secure".
>
> Thanks
> Jonathan
>
> On Mon, Nov 27, 2017 at 4:33 PM, Alex Gaynor  wrote:
>
>> How does this behavior compare with other browsers?
>>
>> Alex
>>
>> On Mon, Nov 27, 2017 at 7:47 AM, Jonathan Kingston 
>> wrote:
>>
>>> Currently our mixed content blocker implementation treats object
>>> subrequests as mixed passive content. As part of our plan to deprecate
>>> insecure connections we are going to block insecure subrequests in flash.
>>> Mostly because such subrequests can contain data or functionality which
>>> might be dangerous for end users.
>>>
>>> Current telemetry suggest that ~0.03% requests would be impacted by this
>>> change of behaviour [1]. To roll that change out we initially are going
>>> to
>>> add a pref  "security.mixed_content.block_object_subrequest" which will
>>> be
>>> enabled for Nightly and Early Beta and ultimately will be flipped on
>>> permanently for FF60.
>>>
>>> We track overall progress here:
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1190623
>>>
>>> Thanks
>>>
>>> Jonathan
>>>
>>> [1]
>>> https://telemetry.mozilla.org/new-pipeline/dist.html#!cumula
>>> tive=0&end_date=2017-11-15&keys=__none__!__none__!__none__&
>>> max_channel_version=release%252F57&measure=MIXED_CONTENT_OBJ
>>> ECT_SUBREQUEST&min_channel_version=null&processType=*&produc
>>> t=Firefox&sanitize=1&sort_keys=submissions&start_date=
>>> 2017-11-12&table=0&trim=1&use_submission_date=0
>>> ___
>>> 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

Intent to ship experimental Mixed Content upgrading (Nightly only)

[Jonathan Kingston]

We are experimenting with ways to eliminate insecure content on secure
pages, while increasing HTTPS adoption. With bug 1435733
, we are adding an
experimental pref to upgrade all mixed passive content. The pref is enabled
in Nightly-only by default.

Mixed passive content[1] currently gets loaded in HTTPS pages with a
degraded security UI - a grey padlock with a yellow triangle over it. With
this change, we will upgrade HTTP mixed passive content (images and media)
to HTTPS on secure pages. If the resource doesn’t exist over HTTPS, it will
fail to load. The security UI will show the green lock, since no insecure
content was loaded on the page.

The categorization of mixed passive content we are using is the same as the
one defined in the  Mixed Content Specification[2]. For example srcset and
 won’t be upgraded.

Chrome is currently also working to experiment in this area as a plan for a
new version of the Mixed Content Specification[3].

The preference to disable this is:
"security.mixed_content.upgrade_display_content" which will be enabled in
Nighty by default for two weeks. The code will remain in Firefox.

Developers and Nightly users can see which content is upgraded in the
developer console[4].

We would love to hear feedback and receive breakage reports.  Please file
bugs here
https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=DOM%3A%20Security


[1] https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content

[2] https://w3c.github.io/webappsec-mixed-content/

[3]
https://github.com/mikewest/webappsec-mixed-content/blob/master/proposed-level-2-roadmap.md

[4] https://imgur.com/Ig5QttW
___
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"

[Jonathan Kingston]

Hey,

So we have two issues here:
- We have less testing on security.insecure_connection_text.enabled
- security.insecure_connection_icon.enabled is a lot heavier handed as MT
notes and also we use this for insecure passwords too.

We also have the pbmode variants if we wanted both enabled when in Private
Browsing mode.

We are discussing the impact of shipping the "Not Secure" text with product
at the moment which is likely much safer to ship right now.

Thanks
Jonathan

On Fri, Feb 9, 2018 at 2:02 PM, Tom Schuster  wrote:

> If you flip just security.insecure_connection_text.enabled and not
> security.insecure_connection_icon.enabled you get Chrome's behavior.
> Flipping both gives you the broken lock and the "Not Secure" text. I
> don't see a big difference there and I hope we can ship this as soon
> as possible.
>
> On Fri, Feb 9, 2018 at 1:55 AM, Martin Thomson  wrote:
> > +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
> >
> > ___
> > 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Unship: registerProtocolHandler() over insecure contexts

[Jonathan Kingston]

registerProtocolHandler() gives a webpage a mechanism to register itself to
control a protocol after a user consents. For example, a chat application
could control the irc: scheme (named protocol in the API).

Chromes current telemetry suggests a usage of 0.002836% on insecure pages
which is low enough to deprecate:
https://www.chromestatus.com/metrics/feature/popularity#RegisterProtocolHandlerInsecureOrigin
.

Due to the API being able to send URL’s path and parameters over insecure
pages and the low usage of the API I’d like a fast deprecation here.
Content that wants to keep this functionality should protect their users
with HTTPS.

Work is happening here: https://bugzilla.mozilla.org/show_bug.cgi?id=1429732
.

In Firefox 60 I plan to submit the code for deprecation, this will include:

   -

   A pref “dom.registerProtocolHandler.insecure.enabled” which controls if
   the API is enabled
   -

  When set to false, the API will be removed from pages with an
  insecure context.
  -

  This is identical to using [SecureContext] in WebIDL, but only when
  the pref is set to false.
  -

   A default pref value in Nightly of false - disabling the API for Nightly
   -

   Other builds will receive a deprecation warning which also implements
   telemetry for this feature.


Assuming there are no issues, In Firefox 62 I plan to remove usage of this
API on all builds for insecure contexts.


Thanks

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

Re: Intent to Unship: Application Cache over Insecure Contexts

[Jonathan Kingston]

This has now landed into central and appears to be sticking:
https://www.fxsitecompat.com/en-CA/docs/2018/support-for-application-cache-on-insecure-sites-has-been-deprecated/

I have filed a follow up bug to remove "OfflineResourceList" interface we
use: https://bugzilla.mozilla.org/show_bug.cgi?id=1435261

Also Anne filed a bug on the standard as it appears other browsers are
interested now in doing the same: https://github.com/whatwg/html/issues/3440

This also means we can move the tests into Web Platform Tests to ensure all
browsers implement the same.


On Fri, Jan 19, 2018 at 6:55 PM, Jonathan Kingston  wrote:

> > Its been suggested before that we could leave the applicationCache
> global in place, but just make it do nothing in insecure contexts.
>
> I did see this idea of keeping the applicationCache global in one of the
> bugs, I think if we have breakage we could try this as a follow up piece of
> work along with other approaches like expiring the cache more often.
>
> On Fri, Jan 19, 2018 at 5:47 PM, Ben Kelly  wrote:
>
>> On Fri, Jan 19, 2018 at 12:26 PM, Mike Taylor  wrote:
>>
>>> > When the pref is set to false the API will be removed:
>>> >
>>> >   -
>>> >
>>> >   window.applicationCache will be removed
>>> >   -
>>> >
>>> >   The cache service Firefox implements for AppCache will be disabled
>>> over
>>> >   Insecure Contexts
>>> >
>>> >
>>> > When the pref is set to true the code will produce an additional
>>> developer
>>> > console warning about the removal timeline.
>>> >
>>> > In Nightly and Early beta for 60; the pref will be set to false
>>> removing
>>> > the API.
>>>
>>> It will be interesting to see if we get reports of pages (that don’t
>>> feature test) throwing with the missing applicationCache global. A few
>>> years (and laptops) ago I had done some site corpus grepping — I’ll see if
>>> I can find any of that data.
>>>
>>
>> Its been suggested before that we could leave the applicationCache global
>> in place, but just make it do nothing in insecure contexts.
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Password autofilling

[Jonathan Kingston]

> But this vector is not realistic. The website _included_ the thirdparty.
They want this tracking to occur. If we blocked invisible login forms from
autofill - the website will make the forms unobtrusively visible so they
get autofilled.

Do we know this? My understanding was most research suggested trackers use
every technique possible that go undetected. If these scripts then
obviously degrade user experience then users complain to the site owner.
These scripts could already do many malicious things anyway.

> In the realistic model the browser is trying defend itself from both the
website and the tracking script

Yep. In reality we are trying to ensure the user wants to authenticate with
their consent.
I think we should continue investigating Credential Management or other
protections of user data from tracking scripts. However this won't protect
the user in the short term.

> We can try to block those scripts with Tracking Protection (and I think
we should.)

I agree, however this won't always be perfect.

> We can disable autofill - but that kind of sucks from a usability
standpoint,

Given we disable this on HTTP pages and also behave differently with CC and
address autofill; why should this have a different experience?

> Maybe there's a compromise. Assume we can detect _when_ a user submits a
login form that we have autofill data for*.

I think this makes it much more confusing to be honest.


On Thu, Jan 18, 2018 at 10:06 PM, Tom Ritter  wrote:

> It seems we are in a bad position here. There's two vectors:
>
> The browser and the website are collaborating to mitigate tracking by
> a third party.
> The third party makes an invisible login form - well we can restrict
> autofill to only visible elements. Or make a write-only form field
> that prevents reading.
>
> But this vector is not realistic. The website _included_ the third
> party. They want this tracking to occur.
> If we blocked invisible login forms from autofill - the website will
> make the forms unobtrusively visible so they get autofilled.
> If we made write-only form fields, maybe the website will auto-submit
> the login field to 'help' you login if it can detect there is a value
> there.
>
> In the realistic model the browser is trying defend itself from both
> the website and the tracking script (which might not even _be_ third
> party!) We can try to block those scripts with Tracking Protection
> (and I think we should.)  We can disable autofill - but that kind of
> sucks from a usability standpoint, as Gerv pointed out.
>
> Maybe there's a compromise. Assume we can detect _when_ a user submits
> a login form that we have autofill data for*. What if, alongside
> cookies and other site data, we store that boolean:
> userHasLoggedIntoSite. If that boolean is false (the user has never
> logged into the site) we require user interaction to populate the
> login form. If the boolean is true, we autopopulate the form (and let
> some tracking script read it.)
>
> I think that would match the tracking capabilities of the site**
> because if the user had logged in in the past, they probably have a
> cookie the website can correlate back to an authenticated session.
>
> -tom
>
> * Can we detect that? I'm hoping we can get it correct 'most' of the
> time, but it would still have edge cases.
> ** Ignoring user fingerprinting =)
>
> On Mon, Jan 8, 2018 at 8:21 AM, Jonathan Kingston  wrote:
> > So it turns out dev-platform is plain text.
> >
> > Here is a link explaining the states instead:
> > https://imgur.com/a/JO6pk
> >
> > Thanks
> > Jonathan
> >
> > On Mon, Jan 8, 2018 at 2:10 PM, Jonathan Kingston 
> wrote:
> >
> >> I wanted to follow up to make it clear what the change would look like.
> >>
> >> Here is what autofill population looks like:
> >>
> >>
> >> Here is what the it looks like after autofill is disabled:
> >>
> >>
> >>
> >>
> >> This then becomes consistent with Private Browsing mode and HTTP sites
> >> already work.
> >> This is also consistent with how we fill Credit Cards and Addresses, we
> >> always require a user selection.
> >>
> >> When the user has multiple accounts we choose not to populate by default
> >> also:
> >>
> >>
> >>
> >> The term Autofill is used inconsistently in Nightly, to mean "On
> >> selection" and also "Populate field on load". The research post
> >> concentrates on just the pre-population of fields in which advertisers
> are
> >> stealing details from users that are unaware.
> >> Making this change to credenti

Re: Intent to Unship: Application Cache over Insecure Contexts

[Jonathan Kingston]

> Its been suggested before that we could leave the applicationCache global
in place, but just make it do nothing in insecure contexts.

I did see this idea of keeping the applicationCache global in one of the
bugs, I think if we have breakage we could try this as a follow up piece of
work along with other approaches like expiring the cache more often.

On Fri, Jan 19, 2018 at 5:47 PM, Ben Kelly  wrote:

> On Fri, Jan 19, 2018 at 12:26 PM, Mike Taylor  wrote:
>
>> > When the pref is set to false the API will be removed:
>> >
>> >   -
>> >
>> >   window.applicationCache will be removed
>> >   -
>> >
>> >   The cache service Firefox implements for AppCache will be disabled
>> over
>> >   Insecure Contexts
>> >
>> >
>> > When the pref is set to true the code will produce an additional
>> developer
>> > console warning about the removal timeline.
>> >
>> > In Nightly and Early beta for 60; the pref will be set to false removing
>> > the API.
>>
>> It will be interesting to see if we get reports of pages (that don’t
>> feature test) throwing with the missing applicationCache global. A few
>> years (and laptops) ago I had done some site corpus grepping — I’ll see if
>> I can find any of that data.
>>
>
> Its been suggested before that we could leave the applicationCache global
> in place, but just make it do nothing in insecure contexts.
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Unship: Application Cache over Insecure Contexts

[Jonathan Kingston]

AppCache is a powerful feature on the web that permits a web page to be
viewed offline. This increases the risk that a user is unaware of the
source of the web page content when browsing over HTTP.

Besides fundamental issues with AppCache, which are summarized in this
article [http://alistapart.com/article/application-cache-is-a-douchebag],
AppCache increases the risk of a MitM attack to a user. The users cache
persists with a device once they change to a different network.

Example attack: Assume a user visits a website over an insecure WiFi
network and the connection to the site was MitM’ed. The MitM injected it’s
own content into the website and the browser then caches that content. The
user decides not to enter their sensitive data whilst on an insecure
network. The user then takes their device home and tries to visit the site
over the internet provided by their ISP. The user now assumes they can
enter sensitive information with less risk.  But since the page content was
cached over the insecure WiFi network, it will still be the malicious
content from the attacker. The sensitive data entered is then sent to the
attacker instead of the website. In addition, the cached content can also
redirect the user to a secure web page owned by the attacker.

For more explanations of the risks see Jake Archibald’s comment regarding
AppCache issues:

https://bugzilla.mozilla.org/show_bug.cgi?id=1237782#c34

Impact on the Web:

Firefox 44 has started to provide a deprecation for all of AppCache:

https://www.fxsitecompat.com/en-CA/docs/2016/application-
cache-support-will-be-removed/

Chrome has previously shown intent to deprecate and remove AppCache for
insecure origins, but for one reason or the other that didn’t happen:

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/UKF8cK0EwMI

Additionally, AppCache has been deprecated from the HTML standard::

https://html.spec.whatwg.org/multipage/offline.html#offline

Developers are advised to use service workers instead of AppCache which are
now supported in all major browser early releases including Safari
Technology Preview! Websites will be required to use HTTPS to use service
workers but websites will gain lots more functionality too.
https://developer.mozilla.org/en-US/docs/Web/API/Service_
Worker_API/Using_Service_Workers

In 2016 Chromes telemetry suggested “around 1.9% of all page loads use
include an AppCache main page load event, but only 0.05% do that over an
insecure origin”.

Firefox telemetry suggests 0.02% in stable 57 for documents and 0.17% for
pages (for secure and not secure): https://telemetry.mozilla.org/
new-pipeline/dist.html#!cumulative=0&end_date=2018-01-
03&keys=__none__!__none__!__none__&max_channel_version=
release%252F57&measure=USE_COUNTER2_DEPRECATED_AppCache_
PAGE&min_channel_version=null&processType=*&product=Firefox&
sanitize=1&sort_keys=submissions&start_date=2017-11-12&table=0&trim=1&use_
submission_date=0

Given that we also just announced that usage statistics were over counting
for use counters https://groups.google.com/forum/#!topic/mozilla.dev.
platform/3pdSQtwOz5g I think this is a safe position to remove from
insecure pages given the risks.

Removal Implementation:

Implementation is happening in: https://bugzilla.mozilla.org/
show_bug.cgi?id=1354175

The intent in Firefox 60 is to ship a pref
“browser.cache.offline.insecure.enable"
to remove AppCache over insecure contexts.

When the pref is set to false the API will be removed:

   -

   window.applicationCache will be removed
   -

   The cache service Firefox implements for AppCache will be disabled over
   Insecure Contexts


When the pref is set to true the code will produce an additional developer
console warning about the removal timeline.

In Nightly and Early beta for 60; the pref will be set to false removing
the API.

In Firefox 62 Stable I plan to switch the pref to false if no further
issues arise.

Kind regards

Jonathan


Resending notice as it didn't reach the Google group.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Password autofilling

[Jonathan Kingston]

I wanted to follow up to make it clear what the change would look like.

Here is what autofill population looks like:

​

Here is what the it looks like after autofill is disabled:
This then becomes consistent with Private Browsing mode and HTTP sites
already work.
This is also consistent with how we fill Credit Cards and Addresses, we
always require a user selection.

When the user has multiple accounts we choose not to populate by default
also:

​

The term Autofill is used inconsistently in Nightly, to mean "On selection"
and also "Populate field on load". The research post concentrates on just
the pre-population of fields in which advertisers are stealing details from
users that are unaware.
Making this change to credential population will make autofill a consistent
UX.

The login manager filling happens over multiple pages (like the Google
accounts screenshots above) which works the same with or without this
change.

Can we move to making signon.autofillForms = false the default on Nightly
and Early Beta and see if we have issues?

Kind regards
Jonathan

On Wed, Jan 3, 2018 at 2:51 AM, Jonathan Kingston  wrote:

> There are some other alternatives that we could take here:
>
> 1. Improve the UX of autofill
>   a. present the credentials to the user on visible forms when the page
> loads
>   - Google had a project on doing this and it never got completed. It
> appears there are many issues with this solution [4].
> 2. Prevent autofill on third party forms
>   - might not actually address the issue as advertisers are often first
> party
> 3. Add heuristics on if the form should be autofilled
>   a. Don't fill when a form isn't visible, editable etc
>
> I also think that removing autofill aligns with the Credential Management
> API, providing incentive for developers to use over having their forms
> autofilled by default and that users expect their details to require an
> interaction for filling.
>
> > There's an about:config pref, as [1] points out, which does this.
>
> My comment regarding this wasn't possible was misleading however I don't
> expect the pref is discoverable to most.
>
> [4] https://twitter.com/estark37/status/947667756400361474
>
>
> On Tue, Jan 2, 2018 at 5:23 PM, Axel Hecht  wrote:
>
>> Am 02.01.18 um 17:22 schrieb Gijs Kruitbosch:
>>
>> On 01/01/2018 20:08, Jonathan Kingston wrote:
>>>
>>>> We have the ability to turn off the whole login manager within Firefox
>>>> preferences: "Remember logins and passwords for web sites" but no way to
>>>> prevent autofill.
>>>>
>>>
>>> There's an about:config pref, as [1] points out, which does this.
>>>
>>> I wonder if there's a way to require user interaction only when pages
>>> contain non-same-origin scripts. Then again, it's not clear that that'd be
>>> "worth it", in the sense that that would actually significantly reduce the
>>> number of pages where user interaction would be required, nor that it
>>> wouldn't make the browser's behaviour less understandable to end users (as
>>> we would sometimes autofill without interaction, and sometimes wouldn't).
>>>
>>> In other form code we also care about whether form fields are focusable
>>> (ie visible, editable etc.), which is something we could also potentially
>>> use to mitigate these attacks, though it could probably be bypassed by
>>> having a visible element that is positioned "offscreen" in an
>>> overflow:hidden container, or something of that sort.
>>>
>>> ~ Gijs
>>>
>>
>> Or could we start blocking tracking-providers with this practice in
>> general?
>>
>> As much as this sounds like an arm-race, these providers are only
>> valuable if they're on a lot of sites, so this might actually be a winnable
>> arm-race.
>>
>> Axel
>> ___
>> 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

Intent to Unship: Application Cache over Insecure Contexts

[Jonathan Kingston]

AppCache is a powerful feature on the web that permits a web page to be
viewed offline. This increases the risk that a user is unaware of the
source of the web page content when browsing over HTTP.

Besides fundamental issues with AppCache, which are summarized in this
article [http://alistapart.com/article/application-cache-is-a-douchebag],
AppCache increases the risk of a MitM attack to a user. The users cache
persists with a device once they change to a different network.

Example attack: Assume a user visits a website over an insecure WiFi
network and the connection to the site was MitM’ed. The MitM injected it’s
own content into the website and the browser then caches that content. The
user decides not to enter their sensitive data whilst on an insecure
network. The user then takes their device home and tries to visit the site
over the internet provided by their ISP. The user now assumes they can
enter sensitive information with less risk.  But since the page content was
cached over the insecure WiFi network, it will still be the malicious
content from the attacker. The sensitive data entered is then sent to the
attacker instead of the website. In addition, the cached content can also
redirect the user to a secure web page owned by the attacker.

For more explanations of the risks see Jake Archibald’s comment regarding
AppCache issues:

https://bugzilla.mozilla.org/show_bug.cgi?id=1237782#c34

Impact on the Web:

Firefox 44 has started to provide a deprecation for all of AppCache:

https://www.fxsitecompat.com/en-CA/docs/2016/application-cache-support-will-be-removed/

Chrome has previously shown intent to deprecate and remove AppCache for
insecure origins, but for one reason or the other that didn’t happen:

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/UKF8cK0EwMI

Additionally, AppCache has been deprecated from the HTML standard::

https://html.spec.whatwg.org/multipage/offline.html#offline

Developers are advised to use service workers instead of AppCache which are
now supported in all major browser early releases including Safari
Technology Preview! Websites will be required to use HTTPS to use service
workers but websites will gain lots more functionality too.
https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers

In 2016 Chromes telemetry suggested “around 1.9% of all page loads use
include an AppCache main page load event, but only 0.05% do that over an
insecure origin”.

Firefox telemetry suggests 0.02% in stable 57 for documents and 0.17% for
pages (for secure and not secure):
https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2018-01-03&keys=__none__!__none__!__none__&max_channel_version=release%252F57&measure=USE_COUNTER2_DEPRECATED_AppCache_PAGE&min_channel_version=null&processType=*&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2017-11-12&table=0&trim=1&use_submission_date=0

Given that we also just announced that usage statistics were over counting
for use counters
https://groups.google.com/forum/#!topic/mozilla.dev.platform/3pdSQtwOz5g I
think this is a safe position to remove from insecure pages given the risks.

Removal Implementation:

Implementation is happening in:
https://bugzilla.mozilla.org/show_bug.cgi?id=1354175

The intent in Firefox 60 is to ship a pref
“browser.cache.offline.insecure.enable" to remove AppCache over insecure
contexts.

When the pref is set to false the API will be removed:

   -

   window.applicationCache will be removed
   -

   The cache service Firefox implements for AppCache will be disabled over
   Insecure Contexts


When the pref is set to true the code will produce an additional developer
console warning about the removal timeline.

In Nightly and Early beta for 60; the pref will be set to false removing
the API.

In Firefox 62 Stable I plan to switch the pref to false if no further
issues arise.

Kind regards

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

Re: Requiring secure contexts for new features

[Jonathan Kingston]

> One potential resolution to that sort of problem is to ship in secure
contexts anyway and ask other browsers to do the same.

It would be really great from a HTTPS adoption standpoint if we can hold
back as many features from being shipped to insecure contexts.

Perhaps Firefox could ship new features to HTTPS and provide prefs to
enable to insecure, which would allow flexibility for webcompat if we
needed to change the stance in stable.

Could we have a process to handle when to withhold these incompatibilities
from insecure contexts?

On Tue, Jan 16, 2018 at 11:02 PM, Martin Thomson  wrote:

> 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Orientation API future

[Jonathan Kingston]

> Specifically:  I was wondering about the real impact of the webvr
polyfill not working, on Firefox users.  My mention of the work
implementing WebVR was pointing out that we will hopefully not need to
worry about the webvr-polyfil working on Gecko-based browsers in the
not-to-distant future, whenever we have full platform coverage for a real
WebVR/WebXR implementation.

My ideal here is that we have an explicit user action / gesture or prompt
for: Magic window, WebVR/XR and device orientation. We might choose to make
several prompts rolled into one for VR but ultimately it will still require
the user to understand the risks. I'm not really sure there is an obvious
way of protecting the user from magic window being just as dangerous as
device orientation.

> if we’re including iOS in the list of platforms we may want to try and
remove device orientation from

I don't think we need to remove it just provide UI in the short term to
require the user to approve.

> when WebXR (including “Magic Window” support) will ship in all versions
of Firefox

I'm unsure here too, I'm not after restricting these websites from working
at least in the short term. I think the functionality should still exist if
we can come up with the right controls to these APIs.

I suspect we are mostly talking about fennec but I'm also not sure if any
laptops/tablets use these APIs if the sensors exist. If the APIs are in use
again I think the prompts should be clear to the user about the risks they
have.

One thing that we could try is taking the user though an on-boarding
tutorial when they first see a website that uses this API. The tutorial
could explain to them what the API will be called, how they will be
prompted and what the risks are to them.

On Thu, Jan 11, 2018 at 6:15 PM, Blair MacIntyre 
wrote:

> Oh, I see what you are saying.   I think there is some confusion here
> (perhaps on my part only).
>
> I do not know if the main use of (and motivation for) the sensor APIs is
> webvr, but I have not been involved in it.  I thought that (newer) API was
> brought up in this discussion as a suggestion for a replacement for the
> deviceorientation APIs.  (Again, I’m unaware of the history or motivations
> behind that API.)
>
> There has been some supposition in this discussion that the main use of
> the device orientation APIs is the WebVR polyfill.  I do not know if that
> is true, I don’t think Chris or I said that — I haven’t seen any mention of
> any data to support or not support that.  It is clear that _a_ use of the
> device orientation APIs is supporting WebVR polyfill.   But it also used
> for panoramic photo viewers, 360 video viewers, and probably other
> (legitimate) things.   Regardless, I fully understand the security/privacy
> concerns.
>
> My message this morning was intended to (perhaps) reframe the discussion
> and (perhaps) let us move forward.  Specifically:  I was wondering about
> the real impact of the webvr polyfill not working, on Firefox users.  My
> mention of the work implementing WebVR was pointing out that we will
> hopefully not need to worry about the webvr-polyfil working on Gecko-based
> browsers in the not-to-distant future, whenever we have full platform
> coverage for a real WebVR/WebXR implementation.
>
> What is/was unclear to me is:
> - if we’re including iOS in the list of platforms we may want to try and
> remove device orientation from.   Matters insofar as we WON’T be able to
> implement WebVR/WebXR there.
> - when WebXR (including “Magic Window” support) will ship in all versions
> of Firefox.  I could “guess” but that’s not useful (I have no control over
> that).
>
> But, if we laid out a plan that said “in the short term we’ll do X, which
> may not be ideal, when WebXR is available we’ll do Y”, that might help.  I
> hope that the second step is not too far in the future, but thinking of it
> that way at least doesn’t lock us into “we need to find a satisfactory
> solution that keeps the webxr-polyfill working indefinitely” since it
> doesn't need to work indefinitely.
>
> Please forgive me for the lack of clarity.  And, of course, if that sort
> of approach isn’t acceptable, just say so.
>
>
> > On Jan 11, 2018, at 12:53 PM, Anne van Kesteren 
> wrote:
> >
> > On Thu, Jan 11, 2018 at 6:48 PM, Blair MacIntyre 
> wrote:
> >>> In that case I'm not entirely sure why we'd also pursue new
> >>> variants separately.
> >>
> >> I’m not sure what this means?
> >
> > That if our main usage for the new sensor APIs (those discussed in
> > https://github.com/w3ctag/design-reviews/issues/207) is WebVR/XR and
> > we don't have any other uses that are compelling enough, and WebVR/XR
> > will come with their own APIs for this, there's no reason for us to
> > worry about the new sensor APIs.
> >
> >
> > --
> > https://annevankesteren.nl/
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Orientation API future

[Jonathan Kingston]

We have three categories of solutions suggested here:
- Throttling
- An explicit gesture to approve using the API
- A prompt

We might be able to do some/all of those depending on the situation. Is
there anything else I have missed that has been suggested?

I honestly would like to request we do some user studies on different
content strings for prompts and see if users understand the risks.
Prompts are a UX pattern that are convention already, inventing new ones
will take more experimenting to perfect. So if we can find the right
content where users understand some of the time, this is better than not
giving users the ability to ever understand where their data is going.

Thanks

On Thu, Jan 11, 2018 at 7:20 AM, Anne van Kesteren  wrote:

> On Thu, Jan 11, 2018 at 5:39 AM, 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?
>
> It sounds like Chrome's approach is throttling, which would probably
> work, but it doesn't work for WebVR, right? (At which point we're back
> at looking at a permission prompt and being unsure how to phrase the
> question.)
>
>
> --
> 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: Intent to unship: navigator.registerContentHandler()

[Jonathan Kingston]

I would like to see the expansion of this feature here, especially for
handling more types of content. Chrome has been working on Web Share Target
API[1] which somewhat overlaps this behaviour and could be expanded to cope
with the use cases here. I actually think web sharing is the answer here,
it also seems like we need to go back to the drawing board for this API if
we want this anyway.

Also if there is need for web extension functionality here that could
be addressed without having to expose this to the web.

I have an r+ on the patch which disables this in Nightly and early
Beta, unless there are objections I will land this in central in a few
days and we can measure if there is any issues before filing another
removal for stable.


[1] https://github.com/WICG/web-share-target/blob/master/docs/explainer.md



On Tue, Jan 9, 2018 at 4:54 PM, L. David Baron  wrote:

> On Tuesday 2018-01-09 08:51 -0800, L. David Baron wrote:
> > I'm a little hesitant here -- this is an important feature for
> > allowing Web apps to fulfil the function that desktop apps do, and
> > I'd rather push to see it expand.
> >
> > For example, if we added support for registering for text/calendar,
> > then Google Calendar could choose to register for that, and thus
> > become the handler for random ICS files that I'm served by sites
> > that allow me to make appointments.
> >
> > Right now desktop calendar apps have more power than web calendar
> > apps do here, for no good reason, and it seems like we ought to be
> > trying to change that.
>
> Though given Anne's point about wanting an API that doesn't do two
> loads of the content, I guess removal is probably the right thing.
> But it would really be good to work on standardizing something
> better here.
>
> -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

Re: Password autofilling

[Jonathan Kingston]

So it turns out dev-platform is plain text.

Here is a link explaining the states instead:
https://imgur.com/a/JO6pk

Thanks
Jonathan

On Mon, Jan 8, 2018 at 2:10 PM, Jonathan Kingston  wrote:

> I wanted to follow up to make it clear what the change would look like.
>
> Here is what autofill population looks like:
>
>
> Here is what the it looks like after autofill is disabled:
>
>
> ​
>
> This then becomes consistent with Private Browsing mode and HTTP sites
> already work.
> This is also consistent with how we fill Credit Cards and Addresses, we
> always require a user selection.
>
> When the user has multiple accounts we choose not to populate by default
> also:
>
> ​
>
> The term Autofill is used inconsistently in Nightly, to mean "On
> selection" and also "Populate field on load". The research post
> concentrates on just the pre-population of fields in which advertisers are
> stealing details from users that are unaware.
> Making this change to credential population will make autofill a
> consistent UX.
>
> The login manager filling happens over multiple pages (like the Google
> accounts screenshots above) which works the same with or without this
> change.
>
> Can we move to making signon.autofillForms = false the default on Nightly
> and Early Beta and see if we have issues?
>
> Kind regards
> Jonathan
>
> (Sorry for the super tiny images, dev-platform blocks bigger ones)
>
>
> On Wed, Jan 3, 2018 at 2:51 AM, Jonathan Kingston  wrote:
>
>> There are some other alternatives that we could take here:
>>
>> 1. Improve the UX of autofill
>>   a. present the credentials to the user on visible forms when the page
>> loads
>>   - Google had a project on doing this and it never got completed. It
>> appears there are many issues with this solution [4].
>> 2. Prevent autofill on third party forms
>>   - might not actually address the issue as advertisers are often first
>> party
>> 3. Add heuristics on if the form should be autofilled
>>   a. Don't fill when a form isn't visible, editable etc
>>
>> I also think that removing autofill aligns with the Credential Management
>> API, providing incentive for developers to use over having their forms
>> autofilled by default and that users expect their details to require an
>> interaction for filling.
>>
>> > There's an about:config pref, as [1] points out, which does this.
>>
>> My comment regarding this wasn't possible was misleading however I don't
>> expect the pref is discoverable to most.
>>
>> [4] https://twitter.com/estark37/status/947667756400361474
>>
>>
>> On Tue, Jan 2, 2018 at 5:23 PM, Axel Hecht  wrote:
>>
>>> Am 02.01.18 um 17:22 schrieb Gijs Kruitbosch:
>>>
>>> On 01/01/2018 20:08, Jonathan Kingston wrote:
>>>>
>>>>> We have the ability to turn off the whole login manager within Firefox
>>>>> preferences: "Remember logins and passwords for web sites" but no way
>>>>> to
>>>>> prevent autofill.
>>>>>
>>>>
>>>> There's an about:config pref, as [1] points out, which does this.
>>>>
>>>> I wonder if there's a way to require user interaction only when pages
>>>> contain non-same-origin scripts. Then again, it's not clear that that'd be
>>>> "worth it", in the sense that that would actually significantly reduce the
>>>> number of pages where user interaction would be required, nor that it
>>>> wouldn't make the browser's behaviour less understandable to end users (as
>>>> we would sometimes autofill without interaction, and sometimes wouldn't).
>>>>
>>>> In other form code we also care about whether form fields are focusable
>>>> (ie visible, editable etc.), which is something we could also potentially
>>>> use to mitigate these attacks, though it could probably be bypassed by
>>>> having a visible element that is positioned "offscreen" in an
>>>> overflow:hidden container, or something of that sort.
>>>>
>>>> ~ Gijs
>>>>
>>>
>>> Or could we start blocking tracking-providers with this practice in
>>> general?
>>>
>>> As much as this sounds like an arm-race, these providers are only
>>> valuable if they're on a lot of sites, so this might actually be a winnable
>>> arm-race.
>>>
>>> Axel
>>> ___
>>> 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

Fwd: Password autofilling

[Jonathan Kingston]

I wanted to follow up to make it clear what the change would look like.

Here is what autofill population looks like:


Here is what the it looks like after autofill is disabled:


​

This then becomes consistent with Private Browsing mode and HTTP sites
already work.
This is also consistent with how we fill Credit Cards and Addresses, we
always require a user selection.

When the user has multiple accounts we choose not to populate by default
also:

​

The term Autofill is used inconsistently in Nightly, to mean "On selection"
and also "Populate field on load". The research post concentrates on just
the pre-population of fields in which advertisers are stealing details from
users that are unaware.
Making this change to credential population will make autofill a consistent
UX.

The login manager filling happens over multiple pages (like the Google
accounts screenshots above) which works the same with or without this
change.

Can we move to making signon.autofillForms = false the default on Nightly
and Early Beta and see if we have issues?

Kind regards
Jonathan

(Sorry for the super tiny images, dev-platform blocks bigger ones)


On Wed, Jan 3, 2018 at 2:51 AM, Jonathan Kingston  wrote:

> There are some other alternatives that we could take here:
>
> 1. Improve the UX of autofill
>   a. present the credentials to the user on visible forms when the page
> loads
>   - Google had a project on doing this and it never got completed. It
> appears there are many issues with this solution [4].
> 2. Prevent autofill on third party forms
>   - might not actually address the issue as advertisers are often first
> party
> 3. Add heuristics on if the form should be autofilled
>   a. Don't fill when a form isn't visible, editable etc
>
> I also think that removing autofill aligns with the Credential Management
> API, providing incentive for developers to use over having their forms
> autofilled by default and that users expect their details to require an
> interaction for filling.
>
> > There's an about:config pref, as [1] points out, which does this.
>
> My comment regarding this wasn't possible was misleading however I don't
> expect the pref is discoverable to most.
>
> [4] https://twitter.com/estark37/status/947667756400361474
>
>
> On Tue, Jan 2, 2018 at 5:23 PM, Axel Hecht  wrote:
>
>> Am 02.01.18 um 17:22 schrieb Gijs Kruitbosch:
>>
>> On 01/01/2018 20:08, Jonathan Kingston wrote:
>>>
>>>> We have the ability to turn off the whole login manager within Firefox
>>>> preferences: "Remember logins and passwords for web sites" but no way to
>>>> prevent autofill.
>>>>
>>>
>>> There's an about:config pref, as [1] points out, which does this.
>>>
>>> I wonder if there's a way to require user interaction only when pages
>>> contain non-same-origin scripts. Then again, it's not clear that that'd be
>>> "worth it", in the sense that that would actually significantly reduce the
>>> number of pages where user interaction would be required, nor that it
>>> wouldn't make the browser's behaviour less understandable to end users (as
>>> we would sometimes autofill without interaction, and sometimes wouldn't).
>>>
>>> In other form code we also care about whether form fields are focusable
>>> (ie visible, editable etc.), which is something we could also potentially
>>> use to mitigate these attacks, though it could probably be bypassed by
>>> having a visible element that is positioned "offscreen" in an
>>> overflow:hidden container, or something of that sort.
>>>
>>> ~ Gijs
>>>
>>
>> Or could we start blocking tracking-providers with this practice in
>> general?
>>
>> As much as this sounds like an arm-race, these providers are only
>> valuable if they're on a lot of sites, so this might actually be a winnable
>> arm-race.
>>
>> Axel
>> ___
>> 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: navigator.registerContentHandler()

[Jonathan Kingston]

> I like the approach of  disabling a feature (behind a pref) in
non-Release (Beta and Nightly) for a few releases, to see what surfaces in
bug reports.

This is reasonable, it is the approach we will be taking with the device
sensors. Obviously it takes a little more work however I'm guessing the
breakage risk will be higher than events .

As you mention, I'm going to propose that we move to implement a pref to
disable this feature instead. In Nightly and early beta enable this pref by
default and see if we have any issues.

Thanks
Jonathan

On Wed, Jan 3, 2018 at 7:49 PM, Mike Taylor  wrote:

> Hi Jonathan,
>
> > On Jan 3, 2018, at 9:15 AM, Jonathan Kingston  wrote:
> > There is a small risk of breakage that we could decide to delay and
> instead
> > implement telemetry. However if the site is feature testing rather than
> > user agent testing there shouldn't be an issue here. As this API throws
> > errors there is likelihood websites account for it throwing anyway. I
> would
> > prefer however to let the removal ride the trains due to it's low risk
> > before 61 so our ESR doesn't have it.
>
> I’m never confident sites are doing feature detection or handling errors…
> I like the approach of  disabling a feature (behind a pref) in non-Release
> (Beta and Nightly) for a few releases, to see what surfaces in bug reports.
>
> > - Is only implemented by Firefox
>
> (It was also in Opera Presto 11.60+, RIP)
>
> --
> Mike Taylor
> Web Compat, Mozilla
>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Orientation API future

[Jonathan Kingston]

When the language for the permission prompt isn't going to be clear about
what the user is exposing (screen, camera and mic) we should be talking
about risks.

For GPS we only ever talk about "location", I still don't think that is a
far stretch from head/position tracking.

On Wed, Jan 3, 2018 at 2:47 PM, Blair MacIntyre 
wrote:

> I don’t think tying orientation to GPS is really a viable approach.
>
> The main use case for the orientation API, I think, is not AR;  it’s 360
> images and videos, and “cardboard VR”, right now.
>
> > On Jan 1, 2018, at 5:01 PM, Martin Thomson  wrote:
> >
> > 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
> >> <https://groups.google.com/forum/#!topic/mozilla.dev.
> platform/DcSi_wLG4fc>,
> >> we propose to discuss the future of the Device Orientation API.
> >>
> >> DeviceOrientation
> >> <https://w3c.github.io/deviceorientation/spec-source-orientation.html>
> >> (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
> >> <https://groups.google.com/a/chromium.org/forum/#!msg/
> blink-dev/RX0GN4PyCF8/6XVhJ_oTCgAJ>.
> >> 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
> >> <https://github.com/w3ctag/design-reviews/issues/207>, 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
> >> <https://docs.google.com/document/d/1XThujZ2VJm0z0Gon1zbFkYhYo6K8n
> MxJjxNJ3wk9KHo/edit#>
> >> 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.
> >>

Intent to unship: navigator.registerContentHandler()

[Jonathan Kingston]

I am suggesting the removal of navigator.registerContentHandler

API used to register a web page to handle content types.

Firefox has an implementation that only can be used to allow a web page to
handle RSS feeds. We don't have telemetry on this feature however we do
know that registerProtocolHandler has around 0.2% usage and this feature is
implemented in multiple browsers and isn't specific to Firefox.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1398169

There is a small risk of breakage that we could decide to delay and instead
implement telemetry. However if the site is feature testing rather than
user agent testing there shouldn't be an issue here. As this API throws
errors there is likelihood websites account for it throwing anyway. I would
prefer however to let the removal ride the trains due to it's low risk
before 61 so our ESR doesn't have it.

Alternatively we could restrict this API to Secure Context only due to the
risk of passing web content to an insecure context. This would be aligned
with our overall plan regarding HTTP APIs.

Removal of this feature requires the removal of some internal tests and to
stop ignoring a web platform test.

The rationale:

- This API had bugs filed on it's implementation
- Is only implemented by Firefox
- The API is now non standard
- No other browsers have intent to implement

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

Re: Password autofilling

[Jonathan Kingston]

There are some other alternatives that we could take here:

1. Improve the UX of autofill
  a. present the credentials to the user on visible forms when the page
loads
  - Google had a project on doing this and it never got completed. It
appears there are many issues with this solution [4].
2. Prevent autofill on third party forms
  - might not actually address the issue as advertisers are often first
party
3. Add heuristics on if the form should be autofilled
  a. Don't fill when a form isn't visible, editable etc

I also think that removing autofill aligns with the Credential Management
API, providing incentive for developers to use over having their forms
autofilled by default and that users expect their details to require an
interaction for filling.

> There's an about:config pref, as [1] points out, which does this.

My comment regarding this wasn't possible was misleading however I don't
expect the pref is discoverable to most.

[4] https://twitter.com/estark37/status/947667756400361474


On Tue, Jan 2, 2018 at 5:23 PM, Axel Hecht  wrote:

> Am 02.01.18 um 17:22 schrieb Gijs Kruitbosch:
>
> On 01/01/2018 20:08, Jonathan Kingston wrote:
>>
>>> We have the ability to turn off the whole login manager within Firefox
>>> preferences: "Remember logins and passwords for web sites" but no way to
>>> prevent autofill.
>>>
>>
>> There's an about:config pref, as [1] points out, which does this.
>>
>> I wonder if there's a way to require user interaction only when pages
>> contain non-same-origin scripts. Then again, it's not clear that that'd be
>> "worth it", in the sense that that would actually significantly reduce the
>> number of pages where user interaction would be required, nor that it
>> wouldn't make the browser's behaviour less understandable to end users (as
>> we would sometimes autofill without interaction, and sometimes wouldn't).
>>
>> In other form code we also care about whether form fields are focusable
>> (ie visible, editable etc.), which is something we could also potentially
>> use to mitigate these attacks, though it could probably be bypassed by
>> having a visible element that is positioned "offscreen" in an
>> overflow:hidden container, or something of that sort.
>>
>> ~ Gijs
>>
>
> Or could we start blocking tracking-providers with this practice in
> general?
>
> As much as this sounds like an arm-race, these providers are only valuable
> if they're on a lot of sites, so this might actually be a winnable arm-race.
>
> Axel
> ___
> 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

Password autofilling

[Jonathan Kingston]

A recent research post[1] have highlighted the need for Firefox to disable
autofilling of credentials. The research post suggests web trackers are
using autofilling to track users around the web.

Currently we take the stance to require user interaction for addresses and
credit card filling, however we don't do this for user credentials.

I have raised a bug[2] to tackle this issue, however we should discuss if
disabling autofill is the right approach first.

As I mention in the bug, Firefox has changed to be a single interaction to
show the logins for fields, previously this required two interactions. This
change significantly improves the usability of the login manager without
having to autofill.

We have the ability to turn off the whole login manager within Firefox
preferences: "Remember logins and passwords for web sites" but no way to
prevent autofill.

As part of [2] we could opt to allow users to enable the autofill feature
again in the about:preferences.

More explanation of the threat can be found on a post by Eric Lawrence[3].

Thanks
Jonathan

[1]
https://freedom-to-tinker.com/2017/12/27/no-boundaries-for-user-identities-web-trackers-exploit-browser-login-managers/
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1427543
[3] https://textslashplain.com/2017/12/28/taking-off-your-nametag/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: overly strict eslint rules

[Jonathan Kingston]

I'm not sure on the exact rule that was failing. However having failed code
reviews that would pass in one part of the codebase can be pretty
frustrating.

I would rather stylistic errors come from automated tests and such that
checking of algos and so on can be focused on in a code review.
Firefox has a style and I just think where possible should enforce that by
automation.

> AFAIK it does not even install with mach bootstrap.

It has worked for me for quite some time just running ./mach lint
filename.js after bootstrap.


Have a great holiday period too
Thanks
Jonathan

On Sun, Dec 24, 2017 at 7:41 PM, Ben Kelly  wrote:

> Hello,
>
> First let me say, I don't like participating in style discussions on the
> list.  I don't think they are productive in general and I don't want to
> have one of those threads here.
>
> I feel I need to raise as an issue, though, as eslint rules are being
> pushed out into components with what seem like overly restrictive style
> rules.
>
> I have no problem with eslint rules that check for language safety issues.
> For example, verifying that there are block braces on single line
> if-statements has safety value.  Verifying that semi-colons are used has
> safety values.  These are things that can break when new code is added to
> the file.
>
> But I also see rules about cosmetic things like what kind of quotes must be
> used for strings.  For example:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1423841
>
> AFAICT this kind of rule does not have any tangible safety benefit.  Its
> purely a cosmetic style choice.  I don't see why we should bounce patches
> out of the tree if the author and reviewer of a component prefer to use
> single quotes instead of double quotes in a file.
>
> I also find this kind of cosmetic rule especially frustrating because we do
> not run eslint by default.  AFAIK it does not even install with mach
> bootstrap.  If we are going to enforce this kind of thing these checks
> should be run as part of a build or when executing tests.  They should not
> require manual installation of tools and running separate commands.
>
> As a further anecdote, I have also had to fight eslint rules in devtools
> which required things like simultaneously using an extreme indent value and
> not exceeding a line width limit.  Basically conflicting and impossible
> rules to satisfy.  I ended up wasting close to an hour figuring out an ugly
> work around for the problem.  It did not feel like the lint was providing
> value.
>
> Anyway, I just want to make a plea that we don't push out overly
> restrictive eslint rules for cosmetic reasons.  We should be spending our
> time building the browser and not trying to do gymnastics to meet some
> arbitrary set of cosmetic rules.  Please focus eslint rules on things that
> provide code safety value.
>
> Thanks.  Have a great holiday.
>
> Ben
> ___
> 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

Device Orientation API future

[Jonathan Kingston]

Following the intent to deprecate filed on Sunday for the Ambient Light and
Proximity sensor APIs
<https://groups.google.com/forum/#!topic/mozilla.dev.platform/DcSi_wLG4fc>,
we propose to discuss the future of the Device Orientation API.

DeviceOrientation
<https://w3c.github.io/deviceorientation/spec-source-orientation.html>
(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
<https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/RX0GN4PyCF8/6XVhJ_oTCgAJ>.
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
<https://github.com/w3ctag/design-reviews/issues/207>, 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
<https://docs.google.com/document/d/1XThujZ2VJm0z0Gon1zbFkYhYo6K8nMxJjxNJ3wk9KHo/edit#>
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

Re: Intent to remove Ambient Light and Proximity sensor APIs

[Jonathan Kingston]

> Is it fair to say that after removal of the Proximity Sensor API, no
e.g. WebRTC-based audio-calling webapp will be able to blank the screen
when the user holds the device to their ear?

Yes, however this would be the case for all other browsers too.

Given that we are the only browser to implement the event based interface
<https://developer.mozilla.org/en-US/docs/Web/API/Proximity_Events> for
this I don't think we should block on the loss of this feature.

The next generation of these APIs are going through TAG review where many
of the concerns here are still being addressed:
https://github.com/w3ctag/design-reviews/issues/207

<https://github.com/w3ctag/design-reviews/issues/207>
We may be able to reimplement this functionality with the new APIs with far
less granular access and prompted if more granular is needed. There has
also been no real intent from browser makers to ship them despite their
improvements.

Thanks

On Mon, Dec 18, 2017 at 7:52 AM, Gervase Markham  wrote:

> On 17/12/17 15:29, Jonathan Kingston wrote:
> > I am suggesting the removal of both Ambient Light and Proximity Sensor
> APIs
> > via a preference so we can ensure there is no adverse impact to the web
> > with a quick mitigation if needed.
>
> Is it fair to say that after removal of the Proximity Sensor API, no
> e.g. WebRTC-based audio-calling webapp will be able to blank the screen
> when the user holds the device to their ear?
>
> That seems sad.
>
> Gerv
>
> ___
> 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

Intent to remove Ambient Light and Proximity sensor APIs

[Jonathan Kingston]

I am suggesting the removal of both Ambient Light and Proximity Sensor APIs
via a preference so we can ensure there is no adverse impact to the web
with a quick mitigation if needed.

If there are no issues with this, I plan to push the code early in the new
year to account for the holiday downtime.

Previous attempts have been made to remove these APIs however this intent
to remove *does not* include Device Orientation which will need further
work to deprecate:
https://groups.google.com/forum/#!topic/mozilla.dev.platform/45XApRxACaM


Previous thread:
https://groups.google.com/forum/#!searchin/mozilla.dev.platform/ambient$20light|sort:relevance/mozilla.dev.platform/QI2-SO-1jxY/-CrSbuH-BAAJ

The rationale:

* These APIs have various privacy leaks, including violating the
same-origin policy, without the user being informed or interaction.
* These APIs do not match the current standards for sensor APIs
* There's no interest to address these shortcomings. (Mostly in the sense
of engineering resources and having other problems to tackle first.)
* As these are event-driven APIs the compatibility impact should be minimal
to none. The events simply won't fire.

Work will be implemented here: https://bugzilla.mozilla.org/
show_bug.cgi?id=1359076
Thanks
Jonathan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to remove pcast and feed protocols

[Jonathan Kingston]

We have a two feed handling protocols that were never standardised and
aren't implemented in other browsers. These protocols have been subject to
various security bugs and also contribute to some technical debt.

The protocols are used to route URLs in Firefox to the feed reader. The
feed reader won't be impacted by this change or other registered feed
handlers.

The work was implemented here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1420622

I intend to fully remove this code and let it ride the trains.

As the telemetry suggests the pcast protocol is almost never used so is
safe to be removed for all users. The feed protocol however is used by the
"Subscribe to this page" functionality and was changed as part of this
patch to work without the protocol.

https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2017-11-28&keys=__none__!__none__!__none__&max_channel_version=release%252F57&measure=FEED_PROTOCOL_USAGE&min_channel_version=null&processType=*&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2017-11-12&table=0&trim=1&use_submission_date=0


Shout out to :bz who fixed a test that was depending on the feed protocol.

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

Re: W3C Proposed Recommendations: WAI-ARIA and Core Accessibility API Mappings

[Jonathan Kingston]

Hey David,

> * the problem is either: the web dev has reinvented something that would
have hasd baked-in accessibility had they followed best practice instead,
Or, best practice doesn't yet cover what web apps want or need to
do...(related, see rules here https://www.w3.org/TR/using-aria/#rule1)

I was aware of this document however it's pretty confusing that the main
ARIA spec doesn't link to it due to the complexity of ARIA.
I'm also confused if the "authoring guidelines" will supersede this
document, if so I couldn't see any mention of the "Use HTML first" wording
there.

If roles are mapped 1:1 to HTML features we basically:
- Promote the use of bad markup and the expectation that bad markup will
use good ARIA.
- The need to reimplement all of HTML into ARIA becomes greater.

As for the role=password there wasn't a clear set of use cases or web
developers asking for this feature. My concern is that the spec authors
have done exactly this for other parts of ARIA.

Thanks
Jonathan

On Fri, Dec 1, 2017 at 2:37 AM, David Bolter  wrote:

> Hi Jonathan,
>
> On Thu, Nov 30, 2017 at 9:23 PM, Jonathan Kingston 
> wrote:
>
>>
>> *Thoughts*
>> We should ensure ARIA provides clear justification for any other roles
>> that
>> already have HTML representation.
>> I'm pretty sceptical of ARIA helping Accessibility. I think there is more
>> impact when assistive and non-assistive improvements work together like
>> .
>>
>>
> I definitely agree with the impact part. But as long as web developers are
> able to build a dialog out of divs and spans, at least there is a way to
> give that jumble a role. The use of ARIA should be a smell* yes, but it has
> been essential to making what exists out there accessible.
>
> * the problem is either: the web dev has reinvented something that would
> have hasd baked-in accessibility had they followed best practice instead,
> Or, best practice doesn't yet cover what web apps want or need to do...
> (related, see rules here https://www.w3.org/TR/using-aria/#rule1)
>
> Cheers,
> D
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: W3C Proposed Recommendations: WAI-ARIA and Core Accessibility API Mappings

[Jonathan Kingston]

*The changelog might be slightly jumbled.*
The only involvement I had was with the password role.
I think both lines should be removed from the changelog as they add
confusion based on their current placements (it reads as if it was in 1.0
and since removed).

*Thoughts*
We should ensure ARIA provides clear justification for any other roles that
already have HTML representation.
I'm pretty sceptical of ARIA helping Accessibility. I think there is more
impact when assistive and non-assistive improvements work together like
.

On Fri, Dec 1, 2017 at 1:58 AM, Tantek Çelik  wrote:

> On Thu, Nov 30, 2017 at 4:10 PM, L. David Baron  wrote:
> > Two W3C Proposed Recommendations are available for the membership of
> > W3C (including Mozilla) to vote on, before it proceeds to the final
> > stage of being a W3C Recomendation:
> >
> >   Core Accessibility API Mappings 1.1
> >   https://www.w3.org/TR/core-aam-1.1/
> >   https://w3c.github.io/aria/core-aam/core-aam.html
>
> Quick review, seems good, and we implement a good chunk of it per the
> implementation report.
> * https://w3c.github.io/test-results/core-aam/
>
> tl;dr: Support Recommendation with comment
>
> Comment:
>
> Per the implementation report, it's hard to tell if there is at least
> one implementation of each mapping (on any platform). The highest %
> reported is 97% of mappings on a platform:
> "WebKitGTK on Linux using ATK - DEMONSTRATES IMPLEMENTABILITY
> status: 97% of mappings successfully implemented (231/237)"
>
> Does this mean 3% of the mappings are unimplemented anywhere? or are
> those 6 mappings implemented on other platforms?
>
> We request clarification in the implementation report as to whether
> each mapping is implemented on at least one platform, and if not (if
> there are mappings unimplemented anywhere, we would be concerned (not
> FO), that there may be a few mappings being standardized that did exit
> reasonable common W3C CR exit criteria expectations.
>
>
> >   Accessible Rich Internet Applications (WAI-ARIA) 1.1
> >   https://www.w3.org/TR/wai-aria-1.1/
> >   https://rawgit.com/w3c/aria/master/aria/aria.html
>
>
> Similarly quick review, seems good (aside from the RDF/OWL point
> already made), and we implement a good chunk of it per the
> implementation report.
> * https://w3c.github.io/test-results/wai-aria/
>
> tl;dr: Support Recommendation with comment
>
> Comment:
>
> (as dbaron noted)
>
> > The one comment I'd be inclined to make (based on feedback in that
> > email thread) is:
> >
> >   We're not entirely sure what to make of the RDF/OWL bits of this
> >   specification, which seem to be non-normative but also part of a
> >   plan for future extensibility.
>
> There's a lot of RDFisms sprinkled throughout the spec, normative parts
> thereof.
>
> It doesn't seem like the RDFisms are essential to implementation
> (which is why I presume the RDF/OWL references are in the Informative
> section at the end).
>
> The only thing I would add to the comment would be a stronger note of
> concern. Something like:
>
>  We are concerned that the many inline references to RDF/OWL bits in
> normative text imply (perhaps without intending to) a need to
> implement RDF/OWL processing to implement the specification. Please
> consider adding a note stating that RDF/OWL processing is not
> essential to interoperably implementing the specification, we believe
> such a note would help implementers of the specification.
>
> [If there is such a note / disclaimer already, I missed it in my
> review of the spec]
>
>
> >   Deadline for responses: today (oops!)
> >
> > Normally I'd ask for comments, but there isn't really much time
> > since this slipped through until I was sent email about it recently.
> > But I could still incorporate feedback in the next few hours.
>
> The above are the only time-sensitive feedback items.
>
>
> > (These are specs that we implement.)
>
> re: specs that we implement, for Firefox Platform Dev:
>
> Two things:
>
> 1. Do we have an Intent to Implement / Ship for the full testable
> feature set of these specifications? (I couldn't find any such
> "Intent" "ARIA" emails in dev-platform, but I may have missed it).
> If not, could the implementing team please send after-the-fact
> either/both Intent to Implement / Intent to Ship emails for both specs
> to dev-platform?
>
> 2. Assuming we have such intent, do we have bugs filed in Bugzilla to
> implement the remaining testable features of both specifications?  (to
> get the following %s to 100)
>
> From Core Mappings report above:
> Firefox on Linux using ATK: 79% of mappings successfully implemented
> (188/237)
> Firefox on macOS using AX API:: 41% of mappings successfully
> implemented (84/205)
> Firefox on Windows using MSAA + IAccessible2: 75% of mappings
> successfully implemented (181/242)
> (or do we have documented somewhere reasoning why we won't implement
> to 100% - and if so, do we have problems with some of the features?)
>
> From WAI ARiA report above:
> no % 

Re: Intent to ship: Changes to ‘X-Frame-Options: SAMEORIGIN’

[Jonathan Kingston]

I think you might be getting confused between frame-src and frame-ancestors.

"frame-src" is a allowlist for frames that can be loaded into the web page.
"frame-ancestors" is an allowlist of documents that can frame the web page.

So in your example code:
on a.com

  

  


X-Frame-Options behaves like frame-ancestors so SAMEORIGIN applies to
a.com/included,  a.com sends a XFO it prevents b.com from loading a.com.
This currently is only true when b.com is the top level and not also a
subframe.

So for example a page using XFO as a defence against being framed by other
websites actually could have content of their own website presented within
for example an advert network on the site.

Thanks
Jonathan

On Tue, Nov 28, 2017 at 1:51 AM, Luke Crouch  wrote:

> On Monday, November 27, 2017 at 9:32:20 AM UTC-6, Jonathan Kingston wrote:
> > Currently XFO only enforces same origin checks of the loading frame
> against
> > the top-level document when the SAMEORIGIN value is set[1][2]. However,
> XFO
> > does not check the entire ancestor chain before making a decision whether
> > the load should be allowed or blocked.
> >
> > In more detail, a load of: a.com -> b.com -> a.com would currently allow
> > frame a.com to be loaded. We plan to change that behavior so that for
> > X-Frame-Options the entire ancestors chain is consulted when the value
> > SAMEORIGIN is specified. In turn, that change of behavior would block the
> > iframe of a.com because the middle iframe has an origin of b.com.
>
> I like the change, but I'm scratching my head for example code? Would this
> be ...
>
> on a.com
> 
>   
> 
>   
> 
>
> It seems SAMEORIGIN would block the loading of b.com/include-a in the
> first place, so how will it know that b.com is including a.com?
> >
> > Please note that ALLOW-FROM or any other XFO values will not be affected
> by
> > that change. As Chrome does not implement the ALLOW-FROM behavior, web
> > sites shipping with an XFO header of ALLOW-FROM might not load in all
> > circumstances. However, developers relying on that behavior could ship a
> > CSP using frame-ancestors instead [3].
> >
> > Chrome implemented the ancestor checks to SAMEORIGIN in Chrome 61[4] and
> > has no intent to remove and no issues have been filed in the last ~4
> > months. Based on Chrome's telemetry the usage is ~0% making the impact
> very
> > low risk.
> >
> > This change is covered by web platform tests in:
> > https://github.com/w3c/web-platform-tests/tree/master/x-frame-options
> >
> > We track overall progress here:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=725490
> >
> > Thanks
> >
> > Jonathan
> >
> > [1]
> > https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-
> Frame-Options
> >
> > [2] https://tools.ietf.org/html/rfc7034
> >
> > [3] https://w3c.github.io/webappsec-csp/#directive-frame-ancestors
> >
> > [4]
> > https://groups.google.com/a/chromium.org/forum/m/#!topic/
> blink-dev/fsDaKFqvU20
>
> ___
> 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: Treating object subrequests as mixed active content

[Jonathan Kingston]

My understanding is all other browsers will still would load this request.

Chrome marks this as Mixed Passive and warns in the console whilst the
request still can be seen in the network panel. I was only testing with a
self signed certificate so unsure if the URL bar would display as "Not
Secure".

Thanks
Jonathan

On Mon, Nov 27, 2017 at 4:33 PM, Alex Gaynor  wrote:

> How does this behavior compare with other browsers?
>
> Alex
>
> On Mon, Nov 27, 2017 at 7:47 AM, Jonathan Kingston 
> wrote:
>
>> Currently our mixed content blocker implementation treats object
>> subrequests as mixed passive content. As part of our plan to deprecate
>> insecure connections we are going to block insecure subrequests in flash.
>> Mostly because such subrequests can contain data or functionality which
>> might be dangerous for end users.
>>
>> Current telemetry suggest that ~0.03% requests would be impacted by this
>> change of behaviour [1]. To roll that change out we initially are going to
>> add a pref  "security.mixed_content.block_object_subrequest" which will
>> be
>> enabled for Nightly and Early Beta and ultimately will be flipped on
>> permanently for FF60.
>>
>> We track overall progress here:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1190623
>>
>> Thanks
>>
>> Jonathan
>>
>> [1]
>> https://telemetry.mozilla.org/new-pipeline/dist.html#!cumula
>> tive=0&end_date=2017-11-15&keys=__none__!__none__!__none_
>> _&max_channel_version=release%252F57&measure=MIXED_CONTENT_
>> OBJECT_SUBREQUEST&min_channel_version=null&processType=*&
>> product=Firefox&sanitize=1&sort_keys=submissions&start_
>> date=2017-11-12&table=0&trim=1&use_submission_date=0
>> ___
>> 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

Intent to ship: Treating object subrequests as mixed active content

[Jonathan Kingston]

Currently our mixed content blocker implementation treats object
subrequests as mixed passive content. As part of our plan to deprecate
insecure connections we are going to block insecure subrequests in flash.
Mostly because such subrequests can contain data or functionality which
might be dangerous for end users.

Current telemetry suggest that ~0.03% requests would be impacted by this
change of behaviour [1]. To roll that change out we initially are going to
add a pref  "security.mixed_content.block_object_subrequest" which will be
enabled for Nightly and Early Beta and ultimately will be flipped on
permanently for FF60.

We track overall progress here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1190623

Thanks

Jonathan

[1]
https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2017-11-15&keys=__none__!__none__!__none__&max_channel_version=release%252F57&measure=MIXED_CONTENT_OBJECT_SUBREQUEST&min_channel_version=null&processType=*&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2017-11-12&table=0&trim=1&use_submission_date=0
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: Changes to ‘X-Frame-Options: SAMEORIGIN’

[Jonathan Kingston]

Currently XFO only enforces same origin checks of the loading frame against
the top-level document when the SAMEORIGIN value is set[1][2]. However, XFO
does not check the entire ancestor chain before making a decision whether
the load should be allowed or blocked.

In more detail, a load of: a.com -> b.com -> a.com would currently allow
frame a.com to be loaded. We plan to change that behavior so that for
X-Frame-Options the entire ancestors chain is consulted when the value
SAMEORIGIN is specified. In turn, that change of behavior would block the
iframe of a.com because the middle iframe has an origin of b.com.

Please note that ALLOW-FROM or any other XFO values will not be affected by
that change. As Chrome does not implement the ALLOW-FROM behavior, web
sites shipping with an XFO header of ALLOW-FROM might not load in all
circumstances. However, developers relying on that behavior could ship a
CSP using frame-ancestors instead [3].

Chrome implemented the ancestor checks to SAMEORIGIN in Chrome 61[4] and
has no intent to remove and no issues have been filed in the last ~4
months. Based on Chrome's telemetry the usage is ~0% making the impact very
low risk.

This change is covered by web platform tests in:
https://github.com/w3c/web-platform-tests/tree/master/x-frame-options

We track overall progress here:
https://bugzilla.mozilla.org/show_bug.cgi?id=725490

Thanks

Jonathan

[1]
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options

[2] https://tools.ietf.org/html/rfc7034

[3] https://w3c.github.io/webappsec-csp/#directive-frame-ancestors

[4]
https://groups.google.com/a/chromium.org/forum/m/#!topic/blink-dev/fsDaKFqvU20
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Still-supported cases of out-of-tree XPCOM code?

[Jonathan Kingston]

> Code search wouldn't have helped *this* case, but considering how
useful https://dxr.mozilla.org/addons/ has been previously, the notion
of there still existing out-of-tree XPCOM callers but them being dark
matter code search-wise worries me.

This was failing for quite some time, we kept ahead of the failures when
firefox was radically changing this.

I agree a test suite would help for these addons for stability going
forward as maintaining this for containers was a hard task.

I would like to re-iterate what Baku said, there was a log failure that
wasn't picked up and was thought to be the failure. It however wasn't and
the actual bug was in central impacting Nightly container users also.

> If the file is needed for <56, why does it even run in 57 or 58?

The code shouldn't run for those versions, there was an import for all
versions which caused an error however didn't even prevent the rest of the
file from loading which is used to make the embedded extension load.

On Wed, Nov 15, 2017 at 4:31 PM, Kris Maglione 
wrote:

> On Wed, Nov 15, 2017 at 04:12:06PM +0200, Henri Sivonen wrote:
>
>> On Wed, Nov 15, 2017 at 3:16 PM, Andrea Marchesini
>>
>>> This is why we had this issue. It should not be impossible for a
>>> 'standard'
>>> webextension to generate such mess.
>>>
>>
>> How many Mozilla-signed special extensions are there? Does an analog
>> of https://dxr.mozilla.org/addons/ exist for searching their code? Is
>> there a CI system testing that the continue to work?
>>
>
> The situation is pretty bad at this point. Ideally, all XPCOM add-ons that
> we support should run tests in treeherder on checkin, both for add-on
> changes and m-c changes. But as of now, most system add-ons, Test Pilot
> add-ons, and SHIELD studies are hosted on Github and do their own ad-hoc
> testing, mostly using Node-ish testing frameworks.
>
> There's also no standard place to host or index all of this add-on code,
> or even to get a list of what such add-ons exist. At one point, I asked for
> all SHIELD add-ons to at least be hosted in the same Github organization.
> The same should probably go for all other Mozilla-signed add-ons. That
> would at least give us a single place to find any XPCOM add-on code that we
> still support.
>
> In the mean time, though, as far as I'm concerned, the maintainers of
> those add-ons are responsible for dealing with breakage that results from
> not having in-tree tests and a standard place to search that code. If
> you're removing legacy XPCOM functionality, all you should need to care
> about is whether treeherder is green.
>
> ___
> 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: Any intent to implement the W3C generic sensor API in Firefox?

[Jonathan Kingston]

> Does this API avoid the problems described in
https://groups.google.com/forum/#!topic/mozilla.dev.platform/45XApRxACaM ?

Which specific issues?
The API in the specification is promise ready by using the permissions API,
is behind a permission prompt and requires a secure context.

My understanding is that there hasn't been a rework of the orientation
specification in regards to the Generic Sensor API but there has for
Ambient Light.

We could trial this for Ambient Light perhaps, given that we want to remove
the other implementation?


On Thu, Nov 2, 2017 at 5:14 PM, Boris Zbarsky  wrote:

> On 11/2/17 12:54 PM, hoehn6...@gmail.com wrote:
>
>> note: Chrome 63 does support it in it early version already
>>
>
> I should note that this is slightly misleading.  According to
> https://groups.google.com/a/chromium.org/forum/?utm_medium=
> email&utm_source=footer#!msg/blink-dev/2zPZt3watBk/M4qcI8wlBwAJ Chrome is
> doing an experiment, in which they will support this API in versions 63-65
> only, as an origin trial, after which the experiment will end.
>
> If someone likes to see a code snipped how it can be used with google's
>> cardboard to detect the magnetic "button", I provided something at
>> https://stackoverflow.com/questions/40270350/detect-google-
>> cardboard-magnetic-button-click-in-javascript
>>
>
> Right, as this post notes it's disabled by default unless you force-enable
> it or participate in the origin trial.  I'm not sure why your mail was
> worded to make it sound like Chrome 63 shipped actual support
>
>
> -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: Containers graduation from Test Pilot - we still care about 57+

[Jonathan Kingston]

Also AMO is accessible to 57 users to download from there instead too :)

On Tue, Oct 3, 2017 at 4:09 PM, Andrew McKay  wrote:

> Just to close the loop on this thread, in 57 this will no longer
> disable multi-e10s.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1404098
>
> Thanks for the heads up Ben.
>
> On 27 September 2017 at 10:53, Ben Kelly  wrote:
> > It disables multi-e10s.  Forced to one content process.
> >
> > On Sep 27, 2017 12:58 PM, "Andrew McKay"  wrote:
> >
> > Sorry, it disables e10s even though it has
> > true in the
> > install.rdf? That shouldn't be the case.
> >
> > On 27 September 2017 at 07:14, Ben Kelly  wrote:
> >> On Mon, Sep 25, 2017 at 9:28 AM, Ben Kelly  wrote:
> >>
> >>> Thanks Jonathan.
> >>>
> >>> Also, it seems the link to the web extension version of the container
> >>> addon is broken above.  This one works for me:
> >>>
> >>> https://github.com/mozilla/multi-account-containers/releases/latest
> >>>
> >>
> >> Sorry, I guess this isn't a web extension yet.  Its a legacy addon and
> >> therefore disables multi-e10s.
> >> ___
> >> 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

Containers graduation from Test Pilot - we still care about 57+

[Jonathan Kingston]

Hi All,

TL;DR - containers is going well, we made it a web extension and it will
continue on addons.mozilla.org

I just wanted to highlight that we have graduated our extension of Test
Pilot Containers to be on AMO: https://addons.mozilla.org/en-GB/firefox/
addon/multi-account-containers/

We have had a few confused users about what is happening with containers.

There is confusion around why the addon doesn't work in 57+ which is due to
it being a legacy addon to support 56, the extension can now be fully
WebExtensions after 57 and to install there you can use: https://github.com/
mozilla/multi-account-containers/releases/latest the addons team is working
on a fix for the website to allow Beta/Nightly users to download there.

We have also removed in Nightly the ability to use the drawer icon which
was native to nightly as it was a subset of features that were provided by
the extension.

To open a container:
- Long press on the + button
- Use the file menu (alt+f)
- Use the extension above (ctrl+period)
- Right click links with the context menu

:bkelly suggested I email here in this bug: https://bugzilla.mozilla
.org/show_bug.cgi?id=1402342 which provides further clarification.

We have exciting posts coming soon to explain further, I just wanted to
highlight we aren't dropping containers just clearing up experiences for
when 57 is stable.

Any user of >57 can actually install any container addon to enable
containers:
https://addons.mozilla.org/en-GB/firefox/collections/jkt/container-addons/

In Beta and Stable releases containers is still disabled by default,
installing a container addon will enable them. To reduce confusion here I
have raised: https://bugzilla.mozilla.org/show_bug.cgi?id=1402608 to allow
users of beta/stable to enable containers through about:preferences also.

If in doubt feel free to reach out to: contain...@mozilla.com

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

Re: Intent to Remove: Insecure use of WebCrypto

[Jonathan Kingston]

Hey Tim,

The only questions I have about this our are difference in implementation
over Chrome the more we increase the use of [SecureContext] the greater
risk we put on compat bugs.

Our implementation differs in that we actually abide to the specification
on window.opener insecure contexts making the openee insecure. This may for
example cause breakage on payment sites that want to use crypto.

Perhaps we should shift to using SecureContextIfOpenerIgnored instead; at
least for the time being?

The difference is somewhat a technicality anyway as the inverse isn't true
a SecureContext that opens an !SecureContext is not then treated as
insecure despite the risk being pretty much the same.

On Thu, Jul 20, 2017 at 3:47 PM, Tim Taubert  wrote:

> Summary: The WebCrypto spec [1] states that window.crypto.subtle
> should only be usable from a secure origin (i.e. on a domain being
> served over HTTPS). Currently Gecko's implementation works on insecure
> origins (i.e. sites served over unencrypted HTTP). To bring our
> implementation in line with the spec, we're going to remove access to
> crypto.subtle on non-secure origins.
>
> Sites using the WebCrypto API's crypto.subtle interface on a
> non-secure origin should switch to HTTPS as soon as possible.
>
> Chrome too is planning to remove access to crypto.subtle on non-secure
> origins [2]. Edge seems positive about implementing those restrictions
> as well [3].
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1333140
>
> Standard: https://w3c.github.io/webcrypto/Overview.html
>
> Platform coverage: This will affect Windows, MacOS, Linux, and Android.
>
> Estimated target date: This could land as early as Firefox 56, but
> should in Firefox 57. We probably want to coordinate with Chrome, they
> seem as ready as we are.
>
> Our telemetry [4] indicates that about 9% of crypto.subtle use is
> still on insecure origins. This was at around 1-2% - that's not the
> percentage of all users, but only of those that visit pages that use
> crypto.subtle - but became inflated around two weeks after we started
> measuring. The blink-dev thread [2] has a good summary and indicates
> that this is caused by Twitter launching AMP support serving from
> origins which may be insecure. AMP has a fallback that is lazy-loaded
> in case crypto.subtle isn't available, so no one's Twitter would break
> when we ship this.
>
>
> [1] https://w3c.github.io/webcrypto/Overview.html#crypto-interface
> [2] https://groups.google.com/a/chromium.org/forum/#!topic/
> blink-dev/ZD3NWqkk-bo/discussion
> [3] https://github.com/w3c/webcrypto/issues/28#issuecomment-243243989
> [4] https://mzl.la/2ttx8aV
> ___
> 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: Ambient Light Sensor API

[Jonathan Kingston]

Auth related images are the attack vector, that and history attacks on same
domain.

On Tue, Apr 25, 2017 at 11:17 PM, Salvador de la Puente <
sdelapue...@mozilla.com> wrote:

> Sorry for my ignorance but, in the case of Stealing cross-origin resources,
> I don't get the point of the attack. If have the ability to embed the image
> in step 1, why to not simply send this to evil.com for further processing?
> How it is possible for evil.com to get access to protected resources?
>
> On Tue, Apr 25, 2017 at 8:04 PM, Ehsan Akhgari 
> wrote:
>
> > On 04/25/2017 10:25 AM, Andrew Overholt wrote:
> >
> >> On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla  wrote:
> >>
> >> Going back to Jonathan's (I think) question. Does anyone use this at all
> >>> in
> >>> the field?
> >>>
> >>> Chrome's usage metrics say <= 0.0001% of page loads:
> >> https://www.chromestatus.com/metrics/feature/popularity#Ambi
> >> entLightSensorConstructor.
> >>
> >
> > This is the new version of the spec which we don't ship.
> >
> >
> > We are going to collect telemetry in
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1359124.
> >> ___
> >> 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: Ambient Light Sensor API

[Jonathan Kingston]

CSS may implement a 3 state light level for most use cases of this metric,
I would suggest that would be much better.

According to the removal bug I raised, it looks like the spec has vastly
changed anyway:
https://bugzilla.mozilla.org/show_bug.cgi?id=1359076#c7

I have a patch ready to measure all usages of the Generic Sensors from the
light sensors to orientation:
https://bugzilla.mozilla.org/show_bug.cgi?id=1359124

I would suggest we should check how often these are moved, but also move to
remove them when it makes sense to over insecure context.
If our implementations don't match what Google is pushing in it's origin
trial it may make sense to remove them anyway assuming there won't be much
breakage.

Thanks
Jonathan

On Tue, Apr 25, 2017 at 2:35 PM, Eric Rescorla  wrote:

> Going back to Jonathan's (I think) question. Does anyone use this at all in
> the field?
>
> -Ekr
>
>
> On Tue, Apr 25, 2017 at 6:10 AM, Kurt Roeckx  wrote:
>
> > On 2017-04-25 00:04, Martin Thomson wrote:
> > > 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.
> >
> > Note that they already talk about 2Hz being the rate they think is
> > realistic to do their attack, and that 5Hz is probably an upper bound of
> > their attack, so reducing it from 60 to 5 doesn't actually change
> anything
> > and you would need to go even lower. You could for instance do something
> > like only allowing it 1 time per minute, and require user approval for
> > higher frequencies.
> >
> > The other suggestion they have in their paper is to reduce the number of
> > values you return, say 4 different values.
> >
> >
> > Kurt
> >
> > ___
> > 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: Ambient Light Sensor API

[Jonathan Kingston]

Those stats aren't the old version of the spec, Google is pushing this
constructor version however the old version as mentioned in the issues is
event driven.

We perhaps remove safely for insecure based on previous comments though.

On Tue, Apr 25, 2017 at 4:46 PM, Eric Rescorla  wrote:

> This suggests that maybe we could just turn it off
>
> On Tue, Apr 25, 2017 at 7:25 AM, Andrew Overholt 
> wrote:
>
> > On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla  wrote:
> >
> >> Going back to Jonathan's (I think) question. Does anyone use this at all
> >> in
> >> the field?
> >>
> >
> > Chrome's usage metrics say <= 0.0001% of page loads:
> > https://www.chromestatus.com/metrics/feature/popularity#
> > AmbientLightSensorConstructor. We are going to collect telemetry in
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1359124.
> >
> ___
> 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: Ambient Light Sensor API

[Jonathan Kingston]

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

Re: Ambient Light Sensor API

[Jonathan Kingston]

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

Re: Revocation protocol idea

[Jonathan Kingston]

This seems a little like the idea WOT(https://www.mywot.com/) had, Showing
the user that they might be looking at a website that isn't considered
great but isn't perhaps bad enough to be blocked.

I agree that one web actor owning this power isn't a great place to be in
and that in itself might be enough justification in at least looking
further into this direction.

If there was enough evidence to suggest we should revoke an advert
providers ability to track someone without breaking the web that might be
interesting.
There is also some research (which I am not sure I can share publicly) to
suggest we should limit API usage to avoid security flaws within browsers
based upon a strong correlation of Lines of Code, CVE's and the low number
of sites that use those APIs. Perhaps there is a rationale to make websites
earn enough trust for new features that have a high risk. For example would
Reddits sub resources really need WebVR or WebGL?
But we would also have to counter the cost of building this over just
making the APIs secure in the first place and also understand we would hurt
web innovation with that too.

On Tue, Mar 21, 2017 at 10:11 PM, Eric Rescorla  wrote:

> There seem to be three basic ideas here:
>
> 0. Blacklisting at the level of API rather than site.
> 1. Some centralized but democratic  mechanism for building a list of
> misbehaving sites.
> 2. A mechanism for distributing the list of misbehaving sites to clients.
>
> As Jonathan notes, Firefox already has a mechanism for doing #2, which is
> to say
> "Safe Browsing". Now, Safe Browsing is binary, either a site is good or
> bad, but
> specific APIs aren't disabled, but it's easy to see how you would extend
> it to that
> if you actually wanted to provide that function. I'm not sure that's
> actually
> very attractive--it's hard enough for users to understand safe browsing.
> Safe
> Browsing is of course centralized, but that comes with a number of
> advantages
> and it's not clear what the advantage of decentralized blacklist
> dissemination
> is, given the networking realities.
>
> You posit a mechanism for forming the list of misbehaving sites, but
> distributed
> reputation is really hard, and it's not clear that Google is actually
> doing a bad
> job of running Safe Browsing, so given that this is a fairly major
> unsolved problem,
> I'd be reluctant to set out to build a mechanism like this without a
> pretty clear
> design.
>
> -Ekr
>
>
>
>
>
>
>
> On Tue, Mar 21, 2017 at 2:40 PM, Salvador de la Puente <
> sdelapue...@mozilla.com> wrote:
>
>> Hi Jonathan
>>
>> In the short and medium terms, it scales better than a white list and
>
> distributes the effort of finding APIs misuses. Mozilla and other vendor
>> browser could still review the code of the site and add its vote in favour
>> or against the Web property.
>>
>> In the long term, the system would help finding new security threats such
>> a
>> tracking or fingerprinting algorithms by encouraging the honest report of
>> evidences, somehow.
>>
>> With this system, the threat is considered the result of both potential
>> risk and chances of actual misuse. The revocation protocol reduces
>> threatening situations by minimising the number of Web properties abusing
>> the APIs.
>>
>> As a side effect, it provides the infrastructure for a real distributed
>> and
>> cross browser database which can be of utility for other unforeseen uses.
>>
>> What do you think?
>>
>>
>> El 8 mar. 2017 10:54 p. m., "Jonathan Kingston" 
>> escribió:
>>
>> Hey,
>> What would be the advantage of using this over the safesite list?
>> Obviously
>> there would be less broken sites on the web as we would be permitting the
>> site to still be viewed by the user rather than just revoking the
>> permission but are there other advantages?
>>
>> On Sun, Mar 5, 2017 at 4:23 PM, Salvador de la Puente <
>> sdelapue...@mozilla.com> wrote:
>>
>> > Hi, folks.
>> >
>> > Some time ago, I've started to think about an idea to experiment with
>> new
>> > powerful Web APIs: a sort of "deceptive site" database for harmful uses
>> of
>> > browsers APIs. I've been curating that idea and come up with the
>> concept of
>> > a "revocation protocol" to revoke user granted permissions for origins
>> > abusing those APIs.
>> >
>> > I published the idea on GitHub [1] and I was wondering about the utility
>> > and feasibility of such a system so I would thank 

Re: Revocation protocol idea

[Jonathan Kingston]

Hey,
What would be the advantage of using this over the safesite list? Obviously
there would be less broken sites on the web as we would be permitting the
site to still be viewed by the user rather than just revoking the
permission but are there other advantages?

On Sun, Mar 5, 2017 at 4:23 PM, Salvador de la Puente <
sdelapue...@mozilla.com> wrote:

> Hi, folks.
>
> Some time ago, I've started to think about an idea to experiment with new
> powerful Web APIs: a sort of "deceptive site" database for harmful uses of
> browsers APIs. I've been curating that idea and come up with the concept of
> a "revocation protocol" to revoke user granted permissions for origins
> abusing those APIs.
>
> I published the idea on GitHub [1] and I was wondering about the utility
> and feasibility of such a system so I would thank any feedback you want to
> provide.
>
> I hope it will be of interest for you.
>
> [1] https://github.com/delapuente/revocation-protocol
>
> --
> 
> ___
> 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: We should drop MathML

[Jonathan Kingston]

Hi Phil,

I'm going to say this isn't a plan I am aware of (the email you responded
to is pretty old and no know progression since then).

Various bugs are still being raised about modern MathML support (stylo is a
new integration of servo's CSS rendering as part of the quantum project -
https://wiki.mozilla.org/Stylo)
  https://bugzilla.mozilla.org/show_bug.cgi?id=1339711

Secondly when working on a pref for the tor patch uplift to Firefox there
wasn't a notion that we should be removing MathML at all:
  https://bugzilla.mozilla.org/show_bug.cgi?id=1173199

This change is just for Tor users who wish to increase their privacy by
removing a library which has known fingerprinting and exploits in the past.

Thanks
Jonathan


On Wed, Feb 15, 2017 at 4:51 PM,  wrote:

> On Sunday, May 5, 2013 at 11:38:39 AM UTC-4, Benoit Jacob wrote:
> > Hi,
> >
> > Summary: MathML is a vestigial remnant of the XML-everything era, and we
> > should drop it.
> >
>
> This is one of the worst ideas I've ever heard floated around Mozilla,
> dating back to the days when releases were numbered M1, M2 and so on.
>  MathML support is basically the ONLY regard in which Firefox has any real
> differentiator between itself and the rest of the browsers out there.
> Choosing to support MathML is one of the few examples of the Mozilla
> leadership group displaying any real vision and choosing to lead, rather
> than follow, in the browser market.  If you drop MathML support, I say you
> might as well just cancel the Firefox project altogether.
>
>
> Phil
> ___
> 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

ARIA membership and role="password"

[Jonathan Kingston]

 
Hey,

So I was just informed that Mozilla isn't a member of the ARIA working
group which shocked me, we have however had a hand in the spec over the
years (I have cc'd those mentioned).

I notice over the years some disappointment with the spec as it being a
separate module to semantics in HTML itself however I don't see a real
opposition not to be in the group. This seems more of a formality when the
group split into two working groups.

It appears that ARIA 1.1 is moving to be resolved in the next few weeks so
if we had any objections we would need to move now I have been told.

*role="password"* has been added to the spec:
https://rawgit.com/w3c/aria/master/aria/aria.html#password and I jotted my
objections in a post:
https://jotter.jonathankingston.co.uk/blog/2016/05/16/role-password-is-not-wise/

My post was largely dismissed in this mail:
https://lists.w3.org/Archives/Public/public-aria/2016May/0126.html

Is it worth us joining? Can we discuss the wider use of ARIA itself?
Rushing to standardise features seems a shame.

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