heads-up: code-review bot's clang-format message changing

[Frederik Braun]

Hi all,

You can stop reading, if you have a setup that never requires you to
applying clang-format manually. (Aside: For those that eagerly want to
belong to this group, but don't yet, I suggest you look into `./mach ide`.)


For all those who get the clang-format warning from code-review bot and
prefer not to download the suggested patches to apply locally, I have
moderately exciting news:

The new comment will give you a readily applicable command line
suggestion, that formats the affected files directly

The bot currently suggests you to run:
- `./mach clang-format -s -p dom/test.cpp` (C/C++)

The bot will soon tell you to run:
- `./mach clang-format -p dom/test.cpp`

This small patch is happening in
https://github.com/mozilla/code-review/pull/858.


That is all,
Frederik

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

Firefox Security Newsletter - Q4 2020

[Frederik Braun]

Hello fellow Mozillians,

Here comes our Q4 edition of the Firefox Security & Privacy Newsletter.
The shareable link for this newsletter is


(References are in footnotes at the bottom, due to dev-platform being a
text-only mailing list. You can always read on the wiki instead).



The various security and privacy teams at Mozilla work in different
parts of the organization, and on different projects, but all with one
goal in common: to improve every aspect of Firefox’s security and
privacy, and to keep our users safe. Since not all of these projects are
directly visible to everyone, we’ve pulled together the highlights from
Q4 2020. We also want to use this newsletter to acknowledge
contributions of folks whose day job is not specifically
privacy/security-related but who have improved security and
privacy-relevant aspects in their areas.

To ease consumption of the many security and privacy-related
improvements listed within this newsletter, we have grouped them into
the following categories:

-   Product Security & Privacy, showcasing new Security & Privacy
Products, Features and Services.
-   Core Security, outlining Security and Hardening efforts within the
Firefox Platform.
-   Cryptography, showcasing improvements to connection security.
-   Fuzzing, providing updates for automated security testing and
analysis.
-   Web Security, highlighting the support of new web application
security features.
-   Policy & Bug Bounty, providing updates on security policy
development.

Note: Some of the bugs linked below might not be accessible to the
general public and are still restricted to specific work groups. [We
derestrict fixed security bugs after a grace-period][], until the
majority of our user population have received their updates.

[We derestrict fixed security bugs after a grace-period]:
https://firefox-source-docs.mozilla.org/bug-mgmt/processes/fixing-security-bugs.html#keeping-private-information-private

Product Security & Privacy

HTTPS-Only Mode: The number of websites that support encrypted and
secure HTTPS connections has been increasing rapidly in recent years.
Despite major gains in the proportion of websites supporting https, the
web contains millions of legacy http links that point to insecure
versions of websites where browsers traditionally would connect using
the outdated and insecure http protocol. To compensate, [Firefox 83
provides an HTTPS-Only Mode][]. This new opt-in, security-enhancing
feature first tries to establish a secure connection to a website using
https and permits the user to fallback to http manually if a secure
connection cannot be established. We believe that HTTPS-Only paves the
way to achieving a fully secure web and this initial version is the
starting point for all browser vendors to re-evaluate their default
connection model.

Redirect Tracking Protection: The [Redirect tracking protection][] was
originally introduced into Firefox 79. In recent efforts we made the
data purging mechanism more intelligent to ensure that users are not
logged out of sites that they are visiting.

[Firefox 83 provides an HTTPS-Only Mode]:
https://blog.mozilla.org/security/2020/11/17/firefox-83-introduces-https-only-mode/
[Redirect tracking protection]:
https://blog.mozilla.org/security/2020/08/04/firefox-79-includes-protections-against-redirect-tracking/

Core Security

Visibility and Transparency: Providing architectural insights into the
security design of a system is crucial for truly working in the open and
ultimately allows contributors, hackers, and bug bounty hunters to
verify and challenge our design decisions. To increase transparency on
Mozilla’s Security and Privacy efforts we have invited three authors to
publish guest blog posts on the [Attack & Defense Blog][]. These posts
not only emphasize our relationships with the community but also
hopefully encourage more security and privacy-minded people to
contribute. In particular, we have published:

-   Insights into a [Rollback Attack][] from [Xiaoyin Liu][]
-   [Firefox for Android LAN-Based Intent Triggering][] from Chris
Moberly
-   [Good First Steps to Find Security Bugs in Fenix][] by Muneaki
Nishimura

In addition to the above articles featured on our Blog, we have also
published insights into Firefox-related bugs, news about browser
security in general, and further bite-sized security announcements on
our [Attack & Defense Twitter account][].

Ending support for Flash and AppCache: Firefox 84 is the last version to
support Flash - this change eliminates long-standing security
vulnerabilities within browsers for good, and there is no setting to
re-enable Flash as announced in [End of support for Adobe Flash.][]
Further, Firefox 84 has [disabled the application cache feature][],
which happened in collaboration with other major browsers.

Hardening Efforts: We have enabled the [Code Integrity Guard in the RDD
process][] before pr

Intent to Ship: Block HTTP ports 69, 137, 161, 1719, 1720, 1723, 6566, 10080

[Frederik Braun]

Hi,

A couple of weeks ago, I have added the ports mentioned above to the
existing list of blocked ports.
The additional port blocking is in response to an improvement of last
year's "NAT slipstreaming" attack, see footnote [1] for more.
Again, we acknowledge that this stops an instance of the attack rather
than solving the problem, which will have to happen elsewhere.

This announcement was delayed for the sake of coordinated disclosure
with other vendors.


Bugs: 1677940 and 1677047

Standard: If all goes well, this will be in fetch


Platform coverage: on all paltforms

Preference: We can revert this using the existing
network.security.ports.banned.override pref

DevTools bug: N/A

Other browsers: Blink shipped

web-platform-tests: Coming.


Thanks,
Freddy

[1]

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

Re: Status of Ubuntu 20.04 as a development platform

[Frederik Braun]

Just updated to 20.10 (not 20.04) last week and things work fine here.


(I have not tested rr yet)

Am 10.11.20 um 15:39 schrieb James Graham:
> On 10/11/2020 14:17, Kyle Huey wrote:
>> On Tue, Nov 10, 2020 at 3:48 AM Henri Sivonen 
>> wrote:
>>>
>>> Does Ubuntu 20.04 work properly as a platform for Firefox development?
>>> That is, does rr work with the provided kernel and do our tools work
>>> with the provided Python versions?
>>
>> rr works. I use 20.04 personally.
> 
> I've also been using 20.04 and all the Python bits have worked fine.
> ___
> 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

Firefox Security Newsletter - Q3 2020

[Frederik Braun]

Hello,

Here comes our Q3 edition of the Firefox Security & Privacy Newsletter.
The shareable link for this newsletter is


(References are in footnotes at the bottom, due to the text-only
mailing list. You can always read on the wiki instead).

The various security and privacy teams at Mozilla work in different
parts of the org, and on different projects, but with one goal in
common: to improve every aspect of Firefox’s security and privacy, and
to keep our users safe. Since not all of these projects are directly
visible to everyone, we’ve pulled together the highlights from July,
August, and September. We also want to use this newsletter to
acknowledge contributions of folks whose day job isn’t specifically
privacy/security-related but have improved things in their areas and
have made our protections tighter.

To ease consumption of the many improvements listed within this
newsletter, we have grouped them into the following categories:

- Product Security & Privacy, showcasing new Security & Privacy
Products, Features and Services.
- Core Security, outlining Security and Hardening efforts within the
Firefox Platform.
- Cryptography, showcasing improvements to connection security.
- Fuzzing, providing updates for automated security testing and
analysis.
- Web Security, highlighting the support of new web application
security features.
- Policy & Bug Bounty, providing updates on security policy
development.

Note: Some of the bugs linked below might not be accessible to the
general public and are still restricted to specific work groups. [We
derestrict fixed security bugs after a grace-period][], until the
majority of our user population have received their updates.

[We derestrict fixed security bugs after a grace-period]:
https://firefox-source-docs.mozilla.org/bug-mgmt/processes/fixing-security-bugs.html#keeping-private-information-private

Product Security & Privacy

Firefox Password Manager: We have made a variety of small yet
significant changes to our password manager.

- When a user types into a password field, a key icon will immediately
appear in the address bar. The icon will help make the “save
password” panel more discoverable, and this behavior also aligns
with Chrome.
- The password manager will also now [autofill logins][] and [show the
key icon][] on some pages where it previously didn’t work.
- Backups of logins.json (where saved logins are stored) are now
created in the profile folder and [automatically used to restore
logins when logins.json is missing or corrupt][]. This feature
addresses recurring, low-volume user complaints.
- The optional [Master Password feature has been renamed to Primary
Password][] to make it more inclusive and [text has been added in
preferences about the name change][].

*Tab-Modal Prompts: *Firefox system prompts can be abused for DoS
(Denial-of-Service) attacks by websites. They are not rate-limited and
can be spammed through Web APIs. Tab-Modal Prompts is our technique to
eliminate this DoS attack vector by migrating window prompts to a new
prompt type, tab level prompts.

We’ve cut over our first two prompts to the new [TabDialogBox][]:
[external protocol dialog][]s and[ dialogs for HTTP
authentication][].

DNS over HTTPS (DoH): Earlier this year, we rolled out [DoH][] to 100%
of our Release channel users in the US. We are now working on extending
our capabilities to support international rollouts. Meanwhile, the DoH
front-end has been converted from a system add-on into a [JSM][]
component. In case any of our support pages mention “add-on” or
“extension,” it’s worth noting that the DoH front-end is now directly
integrated with Firefox and is no longer an add-on.

*Enhanced Tracking Protection (ETP): *We introduced “redirect
tracking protection” to ETP. [Redirect tracking][] is an advanced
tracking technique, also known as bounce tracking. We have rolled out
[ETP 2.0][] to [block redirect trackers by default][] since Firefox 79.
Once every 24 hours ETP 2.0 will completely clear out any cookies and
site data stored by known trackers. This prevents redirect trackers from
being able to build a long-term profile of your activity.

*Research & Academia: *Steven Englehardt published two papers: The
first titled [No boundaries: data exfiltration by third parties
embedded on web pages ][]was presented at [Privacy Enhancing
Technologies Symposium 2020][]. The second titled [Fingerprinting the
Fingerprinters: Learning to Detect Browser Fingerprinting Behaviors][]
will be presented at the [42nd Symposium on Security and Privacy in
2021][]. One of the co-authors, Umar Iqbal, was a 2019 Security Research
Intern in the Security and Privacy Engineering Team.

[autofill logins]: https://bugzilla.mozilla.org/show_bug.cgi?id=1653138
[show the key icon]: https://bugzilla.mozilla.org/show_bug.cgi?id=1638587
[automatically used to restore logins when logins.json is missing or corrupt]:
https://bugzilla.mozilla.o

Intent to Ship: Block HTTP(s) requests to SIP ports 5060, 5061

[Frederik Braun]

Hi,


Summary: Adding ports 5060,5061 to the existing list of blocked ports

The intent for this block is to stop the specific attack of "NAT
slipstreaming". We acknowledge that this stops an instance of the attack
rather than solving the problem, which will happen later.


Bug: 1674735

Standard: If all goes well, this will be in fetch


Platform coverage: on all paltforms

Preference: We can revert this using the existing
network.security.ports.banned.override pref

DevTools bug: N/A

Other browsers: No public signs yet, expecting feedback in the fetch
issue linked above.

web-platform-tests: Existing wpt are being updated as part of this commit


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

Firefox Security Newsletter - Q2 2020

[Frederik Braun]

Hello fellow Mozillians,

Here comes our third edition of the Firefox Security & Privacy Newsletter.
The shareable link for this newsletter is

(References are in footnotes at the bottom, due to the text-only
mailing list. You can always read on the wiki instead).

The various security and privacy teams at Mozilla work in different
parts of the org on different projects, but with one goal in common: to
improve every aspect of Firefox’ security and privacy and to keep our
users safe. Since not all of these projects are directly visible to
everyone, we’ve pulled the highlights from April, May, and June. And we
also want to use this newsletter to acknowledge contributions of folks
whose day job isn’t specifically privacy/security but have improved
things in their areas and ratcheted our protections tighter.

To ease consumption of the many improvements listed within this
newsletter, we have grouped them into the following categories:

-   PRODUCT SECURITY, showcasing new Security Products, Features and
Services.
-   PRODUCT PRIVACY, showcasing new Privacy Products, Features and
Services.
-   CORE SECURITY, outlining Security and Hardening efforts within the
Firefox Platform.
-   CRYPTOGRAPHY, showcasing improvements to connection security.
-   FUZZING, providing updates for automated security testing and
analysis.
-   WEB SECURITY, highlighting the support of new web application
security features.
-   POLICY & BUG BOUNTY, providing updates on security policy
development.

_Note: Some of the bugs linked below might not be accessible to the
general public and are still restricted to specific work groups._ [_We
derestrict fixed security bugs after a grace-period_][]_, until the
majority of our user population have received their updates._


Product Security

TAB MODAL PROMPTS. Firefox system prompts can be abused for DoS attacks
by websites. They are not rate limited and can be spammed through web
APIs. Since most of these prompts are window modal, they take exclusive
focus, making the user unable to interact with the main browser window
before closing the prompt. In severe cases this can lead to the browser
freezing crashing and system memory exhaustion. This year, we eliminated
this DoS attack vector by migrating window prompts to a new prompt type,
[tab level prompts][], which is shown per tab, can not be spammed by
websites and still allows the user to switch tabs or close the main
browser window while it is open.

CERTIFICATE VIEWER. Previously, it’s difficult to access certificate
information. The only way was to view a specific certificate either from
a website info page or from the about:preferences#privacy section. This
year, we created a new certificate viewer. You can quickly access all of
your certificate information by browsing the about:certificate page.

FIREFOX PASSWORD MANAGER. The Password Manager integrated a new machine
learning model, powered by [Fathom][], which allows users to generate
passwords on more webpages. We increased the number of generated
passwords by 360% in Firefox 76 where more than 1.6 million passwords
are generated per week. The login autocomplete popup also appears 30%
faster due to [a performance fix][].

To bring Fenix to parity on login filling, [a GeckoView login
autocomplete API][] was implemented and also includes generated
passwords. Work is in progress to use this API in Fenix.

Further, about:logins now [warns users about vulnerable passwords][].
This new security feature locally checks for password re-use with saved
breached logins (i.e. a saved password is the same as one for a breached
login). Users are encouraged to change these passwords, hopefully using
password generation to improve their password hygiene. A new option was
added to the about:logins menu to export all logins to a CSV file, e.g.
for backup or migration purposes.

In order to help people save passwords on all websites, the key icon now
appears in the address bar whenever a password field is edited, rather
than waiting until a form submission is detected. The option to delete a
saved password also appears in the doorhanger to update a saved password
in case a user no longer wants to save that password in Firefox.

FIREFOX MOBILE. On Mobile, the Firefox Journey team helped to switch v25
of Firefox for iOS from Firefox Accounts client integration to the
shared [Application Services Rust component][]. Under the hood it
replaces over 5,000 lines of difficult-to-maintain [crypto-related
code][]—including certificate signing and subtle key management logic,
the ghosts of Persona past—with a light wrapper around some shared
cross-platform [Rust code][].


Product Privacy

PROTECTIONS DASHBOARD. Firefox has been providing a [Protections
Dashboard][], which provides insights into how users are tracked online,
since last year. To provide yet better insights for users and to protect
their online lives we took the ne

Intent to prototype: Sanitizer API

[Frederik Braun]

Hi all,


*Summary*:
We would like to expose a sanitizer API that accepts "bad" HTML (string,
DocFragment) and returns a sanitized DocFragment, using a pre-defined
list of allowed elements / attributes. The implementation is using code
that we have had in mozilla-central for a long while: The existing
nsTreeSanitizer is widely used (e.g., when pasting HTML into a document
or in Reader Mode). We believe that exposing this will be useful for
applications that want to protect themselves from XSS while allowing a
subset of HTML.

*Bug*: 

Standard: Still just a WICG draft at 

*Platform coverage*: All supported platforms.

*Preference*: Requires dom.security.sanitizer.enabled to be true

*DevTools bug*: 

*Other browsers*: Blink is prototyping, see



*web-platform-tests*: WPT will be the primary test suite. However, we'll
keep a small mochitest in central for easier testing while we experiment
with API details and the final WebIDL. This will allow us to test things
independently, before we reach consensus. We expect the mochitests to be
fully replaced before this is exposed by default.

*Secure contexts*: Yes, required.

*Is this feature enabled by default in sandboxed iframes?*
This API is exposed via JavaScript, which sandboxed iframes do not
allow. Sandboxed iframes with "allow-script" will be able to make use of
this API.

*Link to standards-positions discussion*: worth prototyping
()

*How stable is the spec*: The API is getting stabler, but there are lots
of open questions when it comes to what ought to be allowed by default.
Concerns with forward/backward compatibility are not yet completely
resolved. Even with a list of safe HTML elements, script gadget attacks
need to be taken into account
(https://raw.githubusercontent.com/google/security-research-pocs/master/script-gadgets/ccs_gadgets.pdf).

*Security & Privacy Concerns*: This API does not expose information
about the user, their system or session. Some security questions
regarding compatibility have not been fully answered though. See note above.

*Web designer / developer use-cases*: Implementations as JavaScript
libraries exist, e.g., DOMPurify. However these implementations face
significant challenges: 1) Walking an attacker-controlled DOM tree is
extremely challenging. The page at
 gives an
example of DOM clobbering attacks, in which elements with id="attribute"
can shadow the parent element's "attribute" property. 2) Parsing
ambiguities between security library and browser can lad to security
bugs. We're hoping that an implementation which matches the browser's
parsing behavior will eradicate this issue. In essence: We know
thatframeworks and single-page applications already make use of this
feature, but we hope to provide a better level of security that can
overcome the problems that a JS implementation has to face.

*Example*:
```
mySanitizer = new Sanitizer(/* some options *);
mySanitizer.sanitize("hello!alert('oops'););
// returns DocumentFragment [ hello! ]
```


Kind regards,
Freddy
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to string literals

[Frederik Braun]

Thank you Simon, that looks way more ergonomic!
A bummer, I'll have to modify my in-flight patches though :-)

Do you intend to update existing documentation at

(or move it to firefox source docs)?



Am 01.07.20 um 16:53 schrieb Simon Giesecke:
> Hi,
> 
> until Bug 1648010, there were some macros widely used for the handling of
> string literals, i.e. NS_LITERAL_STRING, NS_LITERAL_CSTRING,
> NS_NAMED_LITERAL_STRING, NS_NAMED_LITERAL_CSTRING. These macros have resp.
> will have been removed once all patches for that bug landed.
> 
> The non-NAMED variants are now replaced by user-defined literals using the
> _ns suffix:
> 
> - NS_LITERAL_CSTRING("foo") becomes "foo"_ns
> - NS_LITERAL_STRING("bar") becomes u"bar"_ns
> 
> This makes the string literals somewhat more concise and more consistent
> with normal literals.
> 
> Note that the "base" literal needs to use the correct underlying character
> type (char vs. char16_t), which is why the same user-defined literal is
> used for both cases.
> 
> For cases where a macro is used to construct a nsString-like literal,
> either
> - the definition of the macro can be changed to make use of the
> user-defined literal already,
> - the macro can be changed to a constexpr constant
> - in cases where neither of these is possible or desirable, the (new) macro
> NS_LITERAL_STRING_FROM_CSTRING can be used, which behaves just like
> NS_LITERAL_STRING did, but has intentionally a somewhat more verbose name
> to avoid its widespread use where it is not required
> 
> The NAMED variants have produced a non-standard syntax for declaring
> variables that are subsequently referenced by user code. These are now
> replaced by regular variable/constant declarations such as:
> 
> constexpr auto kNamedCLiteral = "foo"_ns;
> constexpr auto kNamedLiteral = u"bar"_ns;
> 
> This is slightly longer than the use of the NAMED macros, but uses a
> standard syntax.
> 
> Best wishes
> Simon
> ___
> 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: Please don't use locale-dependent C standard library functions (was: Re: Please don't use functions from ctype.h and strings.h)

[Frederik Braun]

I'm in the process of setting up documentation & examples on how to
implement new static analysis checks.

If we're OK with turning new usages of these functions into errors, I
can help whoever is volunteering to do this.

Am 12.06.20 um 22:40 schrieb Jeff Gilbert:
> It would be great to have CI linting for these!
> 
> On Fri, Jun 12, 2020 at 2:19 AM Henri Sivonen  wrote:
>>
>> This is an occasional re-reminder that anything in the C standard
>> library that is locale-sensitive is fundamentally broken and should
>> not be used.
>>
>> Today's example is strerr(), which returns a string that is meant to
>> be rendered to the user, but the string isn't guaranteed to be UTF-8.
>>
>> On Mon, Aug 27, 2018 at 3:04 PM Henri Sivonen  wrote:
>>>
>>> Please don't use the functions from ctype.h and strings.h.
>>>
>>> See:
>>> https://daniel.haxx.se/blog/2018/01/30/isalnum-is-not-my-friend/
>>> https://daniel.haxx.se/blog/2008/10/15/strcasecmp-in-turkish/
>>> https://stackoverflow.com/questions/2898228/can-isdigit-legitimately-be-locale-dependent-in-c
>>>
>>> In addition to these being locale-sensitive, the functions from
>>> ctype.h are defined to take (signed) int with the value space of
>>> *unsigned* char or EOF and other argument values are Undefined
>>> Behavior. Therefore, on platforms where char is signed, passing a char
>>> sign-extends to int and invokes UB if the most-significant bit of the
>>> char was set! Bug filed 15 years ago!
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=216952 (I'm not aware of
>>> implementations doing anything surprising with this UB but there
>>> exists precedent for *compiler* writers looking at the standard
>>> *library* UB language and taking calls into standard library functions
>>> as optimization-guiding assertions about the values of their
>>> arguments, so better not risk it.)
>>>
>>> For isfoo(), please use mozilla::IsAsciiFoo() from mozilla/TextUtils.h.
>>>
>>> For tolower() and toupper(), please use ToLowerCaseASCII() and
>>> ToUpperCaseASCII() from nsUnicharUtils.h
>>>
>>> For strcasecmp() and strncasecmp(), please use their nsCRT::-prefixed
>>> versions from nsCRT.h.
>>>
>>> (Ideally, we should scrub these from vendored C code, too, since being
>>> in third-party code doesn't really make the above problems go away.)
>>>
>>> --
>>> Henri Sivonen
>>> hsivo...@mozilla.com
>>
>>
>>
>> --
>> 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
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Firefox Security Newsletter - 2020 Q1

[Frederik Braun]

Firefox Security & Privacy Newsletter 2020-Q1

Here comes our second edition of the Firefox Security & Privacy Newsletter.

The shareable link for this newsletter and the back issues is at
https://wiki.mozilla.org/Firefox_Security_Newsletter. This link also
promises readable and stable markup across transports ;-)

Note: Some of the bugs linked below might not be accessible to the general
public and are still restricted to specific work groups. We de-restrict
fixed security bugs after a grace-period
,
until the majority of our user population have received their updates. If a
link does not work for you, please accept this as a precaution for the
safety of all of our users.
Privacy

Preventing tracking and online surveillance

The Anti-Tracking team shipped fingerprinting protections

as part of the Firefox 72 release. This is following a long period of
evaluating
and fixing website breakage
, so it’s a big
milestone for the team.

Erica landed our initial implementation of purging tracking cookies
 in Nightly. This
will enable ETP to better protect against so-called bounce trackers that
track users through first-party redirections.

The first pieces of dynamic first-party isolation
 (DFPI) landed in
Nightly. DFPI is an experimental approach to isolating all third party
cookies and storage, similar to FPI (which is enabled by default in the Tor
Browser and is also supported by Firefox). The most important difference
between DFPI and FPI is that DFPI will adhere to exceptions granted through
the storage access API and thus ensure better web compatibility.

Se-Yeon implemented versioning

for our Shavar blocklists that power Enhanced Tracking Protection (ETP),
Fingerprinting and Cryptomining protections.
Core Security

Securing/hardening the Firefox Platform

Freddy started enumerating flags and prefs that would dramatically reduce
Firefox security. We’re collecting and removing them one by one to kill
exploit chains that require just a single-byte overwrite in bug 1602485
. First patches have
already landed, kudos to volunteer Masatoshi Kimura [:emk] for his
excellent work!

This January, Security Researchers from Qihoo 360 ATA identified an active
attack against Firefox users. With their test case and great help from the
JavaScript team we could ship a security release as Firefox 72.0.1
 on the
next day. Kudos to our Engineers, Release Managers and Security staff for
jumping on this issue so quickly!

We’ve also made some progress to hinder patch gapping. We know that
attackers frequently watch commit logs of popular open source software to
find vulnerabilities that have been fixed but not yet shipped to our end
users. Minimizing this gap has long since been part of our practices for
fixing security bugs in Firefox
.
To help leak data and metadata about security vulnerabilities, Tom has
implemented a hook for hg.mozilla.org
 that disallows
pushing patches for security bugs to Continuous Integration. Furthermore,
Bugzilla has also started hiding security bugs in dependency and regression
fields if a user does not have access (bug 1591549
), but more to come.

The Firefox site isolation project “Fission” is almost ready for testing in
Firefox Nightly. There are some known issues with mixed content blocking
, but you can enable
fission  by
setting the prefs “fission.autostart” and “gfx.webrender.all” to true.

Bugs worth highlighting:

We removed a very, very old testing API called enablePrivilege
, that gave normal
web pages extra privileges beyond Web APIs. The API was used in exploit
chains and made attacks easier than they should have been.

Firefox is no longer going to use ShellExecuteByExplorer
 when launching
executable files in the download folder, this helps protect against
attackers placing malicious DLLs in the same folder.

Folks from the JS team have disabled JIT optimizations for JavaScript in
Proxy Auto Configuration (PAC)
 files as they are
currently run in the parent process.
F

[Intent To Close Component] Firefox :: Security: Review Requests

[Frederik Braun]

Hi all,

as per our guidance at <
https://wiki.mozilla.org/Bugmasters/Projects/Bugzilla_Clean_Up> I am
informing you that we are retiring the "Security: Review Request" component
under Firefox.

The bugzilla driven process belonged to the security team under  Paul
Theriault (pauljt) that has been disbanded in the Fall of 2019.
Dan Veditz has picked up security reviews and is using a different process
as documented at .

I have gone through unresolved bugs and WONTFIXed most of them.
The rationale is that most of the outstanding bugs were filed from the team
as follow-ups or "could be interesting" backlog. Other remaining bugs
involved either Fuzzing or Static Analysis and have therefore been moved to
the respective components in Core.

If you were hit by such a WONTFIX by surprise and wish to get further
security analysis, please reach out to Dan and myself to figure out how to
accommodate you.

As of today, there are no unresolved bugs in the component "Security:
Review Requests" and I made the suggestion to move it to the "Firefox
Graveyard" Product in Bugzilla for archiving purposes in <
https://bugzilla.mozilla.org/show_bug.cgi?id=1628224>.

Please respond before the 15th of April if you have any concerns.


Thank you,
Frederik
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: FTP protocol implementation

[Frederik Braun]

> We're doing this for security reasons. FTP is an insecure protocol and
> there are no reasons to prefer it over HTTPS for downloading resources.
> Also, a part of the FTP code is very old, unsafe and hard to maintain
> and we found a lot of security bugs in it in the past. 

I know this used to be (is?) a widely used feature, but I can second
these considerations. It's not right to waste smart network engineering
time on decades old legacy code and it's likely even harder to justify a
rewrite.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: FTP protocol implementation

[Frederik Braun]

AFAIU chrome removed all web-observable/web-exposed bits of FTP (e.g.,
navigations, subresources etc.)but still allows top-level navigations
from the user.


Am 19.03.20 um 09:02 schrieb Henri Sivonen:
> On Thu, Mar 19, 2020 at 2:24 AM Michal Novotny  
> wrote:
>> We plan to remove FTP protocol implementation from our code.
> 
> Chrome's status dashboard says "deprecated" and
> https://textslashplain.com/2019/11/04/bye-ftp-support-is-going-away/
> said the plan was to turn FTP off by default in version 80. Yet, I
> just successfully loaded ftp://ftp.funet.fi in Chrome 80 on Mac and in
> Edge 82 (Canary) on Windows 10, and I'm certain I haven't touched the
> flag in either. (The location bar kept showing the ftp:// URL, so it
> doesn't appear to be a case of automatically trying HTTP.)
> 
> Do we know why Chrome didn't proceed as planned? Do we know what their
> current plan is?
> 
> Do we know if Edge intends to track Chrome on this feature or to make
> an effort to patch a different outcome?
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: native rendering of outline-style: auto

[Frederik Braun]

How much of this platform-dependent rendering is web observable?
If yes, I guess we'll need an escape hatch for Resist Fingerprinting Mode.

Emilio Cobos Álvarez  schrieb am Mi., 15. Jan. 2020,
19:27:

> Hi,
>
> In bug 1031664 I plan to enable the themed rendering of outline-style:
> auto.
>
> Standard: https://www.w3.org/TR/css-ui/#outline-style (sorry for the TR
> version, but I have problems to access the current draft without
> building it locally :/)
>
> Platform coverage: Linux, Mac, Windows
>
> Preference: layout.css.outline-style-auto.enabled
>
> DevTools bug: N/A (works fine with existing tools)
>
> Status in other browsers is:
>
>   * EdgeHTML: Doesn't parse the value at all.
>   * Safari: Supports the value as intended, by using the platform theme.
>   * Chromium: Parses the value, and outputs a fixed-width outline in
> chromium with a slight radius (at least on Linux and Windows, not sure
> about Mac). It respects outline-color which is a bit weird.
>   * Epiphany: Uses 1px dotted outline instead, with some weird effects
> if you change outline-width. Also respects outline-color.
>
> Without this patch, our current behavior is that we just treat auto as
> solid, respecting width (unlike other browsers), and color (unlike
> Safari, but like Chrome).
>
> With this patch our behavior would match Safari's, effectively.
>
> web-platform-tests: This is pretty hard to test in WPT, as it is
> platform and browser-dependent behavior.
>
> Secure contexts: This is not restricted to secure contexts, like other
> CSS features, and features that other browsers ship in insecure contexts.
>
> Addendum:
>
> I want to use the auto value as the default for our form controls, so
> that I can fix bugs like [1] by omitting its rendering for themed form
> controls.
>
> That is not _theoretically_ blocked by this change, I guess, as we have
> the auto value in the computed style anyway, but it'd be nice to show
> the native outline even if the form control is not themed. Also falling
> back to solid for form controls may not be great (other focused things
> use dotted outlines).
>
> If we find any compat issues / developer or user complaints due to this
> (specially on Windows / Linux), we should probably reconsider and take
> an approach more similar to Chromium / Epi's and remove the
> widget-specific implementations. But I think it'd be nice to do what the
> feature was intended for, I think.
>
> That being said, given the (clearly sub-standard) compat situation, let
> me know if you think it's better to keep it turned this on only for
> Nightly / Beta for a release or two. We're early in the cycle but...
>
> If you find any rendering problems with them or pages looking worse
> because of them, please file a bug blocking bug 1031664 and needinfo me
> or such.
>
> Thank you,
>
>   -- Emilio
>
> [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1311444
> ___
> 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: The sec-approval process makes users safer

[Frederik Braun]

Hi Jeff,

thank you for bringing this up!

Halvar Flake (also formerly of P0) argues here that committing a patch
is not very different from committing the test case:

Which is not something I'm willing to believe in totality.
I think our sec-approval process is useful because it buys us some time.
But it's important to care about timing once a patch is committed. The
fact whether a bug is a sec bug is observable after all.





Am 10.09.19 um 02:58 schrieb Jeff Walden:
> Those of you longer in the tooth may remember Firefox was successfully 
> exploited in Pwn2own 2012...and we didn't have to lift a finger to fix it.  
> We already had -- in the Firefox release shipping days later.  🤦
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=735104 (pwn2own bug)
> https://bugzilla.mozilla.org/show_bug.cgi?id=720511 (cover bug, discussion 
> only of a spec-compliance issue)
> https://bugzilla.mozilla.org/show_bug.cgi?id=720079 (sec bug noting the sec 
> issue)
> 
> We later discussed whether the exploit had been "achieved" by reading our 
> public commits.  https://bugzilla.mozilla.org/show_bug.cgi?id=735104#c2  The 
> fruit of this discussion was our security approval process, where security 
> patches land only after approval, in relative lockstep close to release, with 
> incriminating tests/comments removed.  This is also where sec-approval 
> comment hoop-jumping began.
> 
> sec-approval is a pain.  Is it really worth it?
> 
> The recent Apple iOS WebKit/JSC exploits conclusively answer "yes".  The 
> Project Zero post 
> https://googleprojectzero.blogspot.com/2019/08/jsc-exploits.html discusses 
> the possibility that some exploits were acquired from published, pre-release 
> security fixes and testcases:
> 
>> For many of the exploits it is unclear whether they were originally 
>> exploited as 0day or as 1day after a fix had already shipped. It is also 
>> unknown how the attackers obtained knowledge of the vulnerabilities in the 
>> first place. Generally they could have discovered the vulnerabilities 
>> themselves or used public exploits released after a fix had shipped.
>>
>> Furthermore, at least for WebKit, it is often possible to extract details of 
>> a vulnerability from the public source code repository before the fix has 
>> been shipped to users.
>>
>> CVE-2019-8518 https://bugs.chromium.org/p/project-zero/issues/detail?id=1775 
>> can be used to highlight this problem (as can many other recent 
>> vulnerabilities). The vulnerability was publicly fixed in WebKit HEAD on Feb 
>> 9 2019 with commit 
>> .
>>  This commit contains a testcase that triggers the issue and causes an 
>> out-of-bounds access into a JSArray - a scenario that is usually easy to 
>> exploit. However, the fix only shipped to users with the release of iOS 12.2 
>> on March 25 2019, roughly one and a half months after details about the 
>> vulnerability were public.
>>
>> An attacker in possession of a working exploit for an older WebKit 
>> vulnerability would likely only need a few days to replace the underlying 
>> vulnerability and thus gain the capability to exploit up-to-date devices 
>> without the need to find new vulnerabilities themselves. It is likely that 
>> this happened for at least some of the following exploits. 
> 
> (paragraph breaks added)  Incredibly, saying, "It is likely that [attackers 
> used public commits/testcases to create exploits]" *soft-pedals* it.  The 
> first exploit the post discusses includes this text and image:
> 
>> [T]he exploit trigger is almost exactly the same as in the bug report and 
>> the regression test file in the WebKit repository. This can be seen in the 
>> following two images, the left one showing the testcase published in the 
>> WebKit code repository as part of the bugfix and the right showing the part 
>> of the in-the-wild exploit code that triggered the bug.
>> https://1.bp.blogspot.com/-PEZlVLEefs0/XWg4BdDSxkI/NUs/ELjHWgzHOZIRKSTV45E-moRivJKrAWIkACLcBGAs/s1600/JSC%2BDIFF.png
>>  (alt text: "This image shows a line-by-line, side-by-side comparison 
>> between the vulnerability test case from the webkit tracker on the left, and 
>> the vulnerability trigger code used in the exploit on the right. They are 
>> very similar, with matching variable names and code structure. The only 
>> difference is that one value which had the fixed value 1.45 in the test case 
>> has been parameterised out to a variable named ow in the exploit, and the 
>> trigger has been wrapped inside a function definition which takes ow as an 
>> argument.")
> 
> The *only* difference between testcase and exploit is s/1.45/ow/.  There's no 
> plausible way that similarity (including variable names) is coincidental.  
> Attackers (the Chinese government, it seems) copied the testcase into a 
> function, then changed the one bit of the test contr

Re: Intent to implement: Cookie SameSite=lax by default and SameSite=none only if secure

[Frederik Braun]

Having read the proposal, I think it's a good mechanism for us to know
about websites that want third-party cookies and it seems less costly to
deploy for websites than Storage Access API.

However, it seems this is Google's counter to Apple's Storage Access
API, which we have also implemented in
.

What's our plan here? Offer both and find out what's going to get more
traction?

Am 23.05.19 um 10:33 schrieb Andrea Marchesini:
> Link to the proposal:
> https://tools.ietf.org/html/draft-west-cookie-incrementalism-00
> 
> Summary:
>   "1.  Treat the lack of an explicit "SameSite" attribute as
>"SameSite=Lax".  That is, the "Set-Cookie" value "key=value" will
>produce a cookie equivalent to "key=value; SameSite=Lax".
>Cookies that require cross-site delivery can explicitly opt-into
>such behavior by asserting "SameSite=None" when creating a
>cookie.
>2.  Require the "Secure" attribute to be set for any cookie which
>asserts "SameSite=None" (similar conceptually to the behavior for
>the "__Secure-" prefix).  That is, the "Set-Cookie" value
>"key=value; SameSite=None; Secure" will be accepted, while
>"key=value; SameSite=None" will be rejected."
> 
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1551798
> 
> Platform coverage: all
> 
> Estimated or target release: 69 - behind pref
> 
> Preferences behind which this will be implemented:
>  - network.cookie.sameSite.laxByDefault
>  - network.cookie.sameSite.noneRequiresSecure (this requires the previous
> one to be set to true)
> 
> Is this feature enabled by default in sandboxed iframes? yes.
> 
> Do other browser engines implement this?
>  - Chrome is implementing/experimenting this feature:
> https://blog.chromium.org/2019/05/improving-privacy-and-security-on-web.html
>  - Safari: no signal yet.
> 
> web-platform-tests: There is a pull-request
> https://github.com/web-platform-tests/wpt/pull/16957
> Implementing this feature, I added a mochitest to inspect cookies via
> CookieManager.
> 
> Is this feature restricted to secure contexts? no
> ___
> 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: typeMustMatch attribute on elements

[Frederik Braun]

Hi,

In bug 1548773, annevk suggested to unship the `typeMustMatch`attribute
from  elements[1].

No other browser supports this and we have just learned that this
attribute can be used to leak information about cross-origin resources[2].

While it seems worth removing immediately to me, I'm interested in
additional feedback.

Thanks,
Freddy

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1548773
[2]
https://github.com/xsleaks/xsleaks/wiki/Browser-Side-Channels#object-typemustmatch
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Patching FF 52.9esr with v60+ Security updates possible?

[Frederik Braun]

Chiming in with the others here.
Without knowing more about your build issues, I'd rather try fixing them
than try amd build a custom 52.x

Q

Charles Robertson  schrieb am Sa., 13. Apr. 2019,
00:42:

> Hi,
>
> I know this sounds like a strange questions. However, we have a very large
> customer who is using our old OS which the last successful build of Firefox
> ESR was 52.9. But because of the massive updates to FF 60 we have been
> unable to get FF 60+ to build on that old OS. This customer has demanded we
> provide an updated Firefox for this old OS so I am asking if it would be
> possible to patch FF 52.9esr with the security updates since 60 was
> released?
>
> Thanks,
> Cheers
>   Charles Robertson
>   Firefox Maintainer - SUSE
>
>
> ___
> 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: To what extent is sccache's distributed compilation usable?

[Frederik Braun]

Am 01.04.19 um 22:16 schrieb Chris M.:
> Hi Emilio, if you're interested you're encouraged to try it out, however
> we're shipping machines to offices now to run the schedulers, the first of
> which I'll be testing in the SF office this week, so we're planning an
> officially supported setup in the near future.
> 

That's great news. Can we follow progress or detailed plans somewhere?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New and improved "about:config" for Firefox Desktop

[Frederik Braun]

Agreed. If there's one special feature besides search I've been using most,
it was sorting by modified

Am Fr., 25. Jan. 2019, 12:16 hat Tom Schuster  geschrieben:

> I am always happy to see more xul going away.
>
> Please implement a filter to only show modified preferences. Sorting
> by modified is probably my most common operation after search on the
> old page.
>
> Thanks
>
> On Fri, Jan 25, 2019 at 11:40 AM Axel Hecht  wrote:
> >
> > Is there a tracking bug for follow-ups?
> >
> > I'd have a few, adding pref w/out search (*), show add on screen for
> > long searches, filter/order by modified, search in values, can't abort
> edit.
> >
> > (*) I just realize that I didn't understand how "add" works. Maybe the
> > bug is to make that discoverable?
> >
> > Axel
> >
> > Am 24.01.19 um 20:31 schrieb Paolo Amadini:
> > > Last year a group of students, Luke, Matthias, and Vincent, designed
> and
> > > implemented a new version of "about:config" in order to improve the
> > > ergonomics and align the look and feel with other in-content Firefox
> > > pages. They did an amazing job, working with design input from Amy Lee
> > > and with myself doing code reviews.
> > >
> > > I'm happy to announce that this work will be available to everyone in
> > > Firefox 67, and can be already used in Nightly at this URL:
> > >
> > >  chrome://browser/content/aboutconfig/aboutconfig.html
> > >
> > > Most improvements are the natural result of using HTML instead of XUL:
> > >
> > >   * There are visible buttons for editing preferences
> > >   * String values are displayed in full as multiline text
> > >   * Find in page works for both names and values
> > >   * Triple click selects one preference name or value quickly
> > >   * Text selection works on multiple preferences
> > >   * The context menu is the same as regular web pages
> > >  - Copy to the clipboard
> > >  - Open selected link
> > >  - Search with your preferred engine
> > >   * Search results don't include spurious value matches anymore
> > >   * Closing and reopening the browser while the tab is pinned
> > >   preserves the search term
> > >
> > > We've not just converted the old page, we've designed something new
> > > based on actual use cases, telemetry data, and opportunity cost. We
> > > preferred natural HTML page interactions, for example a double click
> now
> > > selects text instead of toggling the value. The way the page is
> explored
> > > with screen readers has also changed, and we've ensured that the new
> way
> > > is still clear and easy to use.
> > >
> > > We're still keeping the old "about:config" around at the following URL
> > > for a while, to mitigate risk related to unforeseen circumstances:
> > >
> > >  chrome://global/content/config.xul
> > >
> > > Thunderbird will not be affected by this change initially, but at some
> > > point we'll remove the old code from mozilla-central since Thunderbird
> > > will be the only remaining user.
> > >
> > >
> > > *Performance*
> > >
> > > This page can be slower than the old one in some cases. On slower
> > > machines the page may take a moment to display all preferences, if you
> > > so choose. We worked around this by waiting for the first input before
> > > displaying results, as 93% of "about:config" page shows include a
> search
> > > anyway. Navigation, scrolling, and find in page are then fast.
> > >
> > > We've used performance profiling to optimize the page and avoid the
> > > slowest layout modes, but we've not compromised on using the latest
> > > best practices for Firefox Desktop like Fluent localization, which are
> > > anyways in the process of being optimized on their own.
> > >
> > > We've explicitly chosen to avoid virtualizing the list, that is only
> > > rendering visible DOM nodes, because this would add complexity that is
> > > not needed for an internal page. It would also nullify most of the
> > > advantages in accessibility and usability that we gained at a low cost
> > > just because we're using a simple HTML table. Effort would be better
> > > spent on optimizing the web for the layout of tables of about 3,000
> > > rows, which would benefit every web site instead of Firefox only.
> > >
> > >
> > > *Tutorials and screenshots on the web*
> > >
> > > While with some features there is a concern that a change would make it
> > > more difficult for users to follow instructions found in older
> tutorials
> > > on the web, this is much less of a concern in this case, given that the
> > > page caters to experienced users and the changes affect presentation
> > > rather than actual functionality.
> > >
> > > In fact, existing information on the web can more easily become
> obsolete
> > > because the preferences go away or change their meaning, rather than
> > > because of a change in how the values can be changed.
> > >
> > >
> > > *Features that have not been rewritten*
> > >
> > > If the new page is missing a feature that the old one used to have,
> > > there

Re: What is the future of XMLHttpRequest.mozAnon ?

[Frederik Braun]

On 14.09.2018 10:08, john.bieling--- via dev-platform wrote:
>... mozAnon XHR has advantages in other features over fetch().

Isn't this the same as supplying the crossOrigin:anonymous option to
fetch()?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Implement: Storage Access API

[Frederik Braun]

On 09.09.2018 11:05, Mike O'Neill wrote:
>>
>> We don’t necessarily believe that a model where the user is asked whether
>> they consent to sharing their data with third-party trackers is ideal,
>> because explaining the implications of the data sharing is very hard, and
>> there are many problems associated with asking for permission from the
>> user.  But we are looking at this API as a programmatic hook into the point
>> in time when a third-party context would like to obtain full storage access
>> rights, which would allow the browser to perform various forms of
>> security/privacy checks at that time. Prompting the user is only one of the
>> options we’ve thought about so far.  Note that the API limits granting
>> access only to callers coming at times when processing a user gesture.
>>
> The legal requirement in Europe is that storage can only be accessed if the 
> user has unambiguously given their "freely given, specific & informed" 
> consent. How will a European website top-level context (first-party) ensure 
> that embedded third-parties will not be granted storage access without the 
> user first being prompted?

This is not really about sharing, is it?
AFAIU we plan to limit how third parties can look at their own storage
buckets - generally.
This API just allows them to poke a relatively well-defined hole (and
thus giving us an opportunity for intervention).


This API is mostly orthogonal to any data sharing between the first and
the third party - isn't it?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Blocking FTP subresources

[Frederik Braun]

On 09.04.2018 15:13, Tom Schuster wrote:
> Summary: All FTP subresources in HTTPs pages (this also includes blob:
> etc) will be blocked. Opening FTP links as toplevel documents is still
> possible.
> 
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1404744
> 
> Platform coverage: All
> Target release: Firefox 61 (this already landed, but we forgot to send
> this, sorry!)
> Preference behind which this will be implemented: None
> Is this feature enabled by default in sandboxed iframes: Yes, enabled 
> everywhere
> DevTools bug: None

For those who have wondered about the same.
If you try loading an FTP url in an iframe, we show the following
warning in the DevTools:

Loading FTP subresource within http(s) page not allowed (Blocked loading
of: “ftp://evil.com/”)

> Do other browser engines implement this?
> Chrome shipped in M62?
> web-platform-tests: No
> Secure contexts: n/a
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

[Frederik Braun]

On 20.03.2018 04:33, Dave Townsend wrote:
> The DoH service
> we're using is likely more private than anything the user is currently
> using.

This is only true for some parts of the world.
I'd like us not to regress for our user base globally here.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: HTML injection in chrome documents is now automatically sanitized

[Frederik Braun]

My bad! This is certainly a bug in the linter.
The fix is underway.

On 09.02.2018 12:35, Gijs Kruitbosch wrote:
> Sorry about the waste of time. :-(
> 
> Re: difficulty: it depends on your measure of 'very'. Internally the
> sanitization is whitelist-based. It is used in many places (not just for
> chrome-privileged docs), where it would be wrong to show warnings
> (possibly very *many* warnings!). It may be possible to add a flag to
> the sanitizer to log warnings for every removed attribute/element, and
> to pass that explicitly from the callsites that Kris added. It'd be
> worth filing a bug for that.
> 
> To be honest, I would have expected there to have been an eslint error
> if using innerHTML/createContextualFragment with anything other than a
> fixed string, which might have saved you a lot of headache. If that
> linter isn't catching createContextualFragment, then we need to fix the
> linter so that it does. If you were using a fixed string that got
> sanitized, can you point me to the bug/patch that you're working on? I'm
> having trouble thinking of cases where we use innerHTML with fixed
> content that would get sanitized in this way, without any
> injection/replacement, but perhaps I'm missing something.
> 
> ~ Gijs
> 
> On 09/02/2018 02:18, Brendan Dahl wrote:
>> Would it be very difficult to warn when something is sanitized and
>> removed?
>>
>> I wasted a good deal of time trying to figure out why
>> createContextualFragment wasn't working.
>>
>> On Fri, Feb 2, 2018 at 2:10 AM, Gijs Kruitbosch
>> 
>> wrote:
>>
>>> FWIW, if you're running into this with the usecase "I have a localized
>>> string that needs to have links (or other markup) in it" and were
>>> formerly
>>> using getFormattedString combined with innerHTML, we now have a utility
>>> method that can help a little bit. Rather than hand-rolling splitting
>>> the
>>> string etc., on nightly you can use BrowserUtils.getLocalizedFragment as
>>> a replacement. Given a document, raw string (fetch using getString /
>>> GetStringFromName instead of the "formatted" APIs), and DOM nodes to
>>> insert, it'll produce a DocumentFragment that you can
>>> appendChild/insertBefore etc., take care of splitting your strings
>>> for you,
>>> and will work with both indexed (%1$S) and non-indexed (%S) replacement
>>> points in the localized string. In the further future, I expect this
>>> type
>>> of problem will go away entirely because of Fluent.
>>>
>>> ~ Gijs
>>>
>>>
>>> On 02/02/2018 07:13, Kris Maglione wrote:
>>>
 As of bug 1432966, any HTML injected into chrome-privileged
 documents[1]
 is automatically sanitized to remove any possibility of script
 execution.
 The sanitization is whitelist-based, and only allows a limited set
 of HTML
 elements and attributes. All scripts, XUL nodes, or privileged URLs
 will
 automatically be removed. This change has been uplifted all the way
 to 58
 release.

 If you're thinking about writing new code that injects HTML strings
 into
 chrome-privileged documents, please think again. Unless it's extremely
 simple, it probably won't be compatible with these changes (and will
 also
 be rejected by our default ESLint rules).

 Existing HTML injection in chrome documents is being gradually removed.
 Once that's done, the sanitization may be replaced with an outright
 prohibition.


 -Kris

 [1]: Using the usual HTML fragment creation methods such as
 `innerHTML`,
 `outerHTML`, `insertAdjacentHTML`, and `createContextualFragment`. Not,
 notably, when using document.write().
 ___
 firefox-dev mailing list
 firefox-...@mozilla.org
 https://mail.mozilla.org/listinfo/firefox-dev

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

Re: PSA: HTML injection in chrome documents is now automatically sanitized

[Frederik Braun]

Now would be a great time to file good first bugs.

New contributors could rewrite innerHTML and friends into code that uses
safer alternatives.



On 02.02.2018 08:13, Kris Maglione wrote:
> As of bug 1432966, any HTML injected into chrome-privileged documents[1]
> is automatically sanitized to remove any possibility of script
> execution. The sanitization is whitelist-based, and only allows a
> limited set of HTML elements and attributes. All scripts, XUL nodes, or
> privileged URLs will automatically be removed. This change has been
> uplifted all the way to 58 release.
> 
> If you're thinking about writing new code that injects HTML strings into
> chrome-privileged documents, please think again. Unless it's extremely
> simple, it probably won't be compatible with these changes (and will
> also be rejected by our default ESLint rules).
> 
> Existing HTML injection in chrome documents is being gradually removed.
> Once that's done, the sanitization may be replaced with an outright
> prohibition.
> 
> 
> -Kris
> 
> [1]: Using the usual HTML fragment creation methods such as `innerHTML`,
> `outerHTML`, `insertAdjacentHTML`, and `createContextualFragment`. Not,
> notably, when using document.write().
> ___
> 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()

[Frederik Braun]

On 04.01.2018 04:46, Karl Dubost wrote:
> Jonathan,
> 
> Le 4 janv. 2018 à 00:15, Jonathan Kingston  a écrit :
>> Firefox has an implementation that only can be used to allow a web page to
>> handle RSS feeds. 
> 
> in Firefox 8, the feeds panel was removed from Firefox. It created a bit of 
> bad press. 
> Some people have developed add-ons to cope with the removal.
> https://developer.mozilla.org/en-US/Firefox/Releases/2/Adding_feed_readers_to_Firefox
> 
> If I check https://addons.mozilla.org/en-US/firefox/search/?q=rss+reader
> I can see a couple of addons for reading RSS/Atom feeds.

I found 49 addons in DXR.

23 of those occurrences are irrelevant:
- uglify.js has list of known dom properties, which seem important for
mangling.
- Firefox OS simulators
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: SMIL accessKey support

[Frederik Braun]

Excellent! I won't miss it :)

On 05.12.2017 08:25, Brian Birtles wrote:
> Background: SMIL includes a feature for triggering animations based on
> keypresses:
> 
> e.g.
> 
> 
>   
> 
> 
> Proposal: In bug 1423098 I intend to remove this feature.
> 
> Rationale:
> 
> * Apart from Gecko, only Presto supports it.
> * accessKey has been the source of security issues in the past such as
> bug 704482.
> * We're trying to reduce the amount of SMIL-specific code in Gecko,
> since it is not used a lot, it increases our attack surface area, and
> it slows down other work on the style system like the Stylo project.
> 
> Status in other browsers:
> 
> Blink: No support. There is a "// FIXME: accesskey() support" in the code.[1]
> WebKit: No support. The FIXME appears to be pre-fork.[2]
> IE/Edge: No SVG SMIL support at all.
> Presto: Supports accessKey but you need to press Shift + Esc first.
> 
> I'm not planning on adding a developer console warning at this point
> unless someone suggests that would be useful.
> 
> Best regards,
> 
> Brian
> 
> [1] 
> https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/svg/animation/SVGSMILElement.cpp?q=syncbase+file:%5Esrc/+package:%5Echromium$&dr=CSs&l=465
> [2] 
> https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/svg/animation/SVGSMILElement.cpp#L425
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

[Frederik Braun]

On 02.10.2017 18:43, Anne van Kesteren wrote:
> On Mon, Oct 2, 2017 at 6:09 PM, Boris Zbarsky  wrote:
>> On 10/2/17 12:03 PM, Daniel Veditz wrote:
>>> Fair enough. Could we propose improvements to the APIs that would make
>>> them more usable? For example an object argument to createElement() that
>>> contained attribute/value pairs?
>>
>> This has definitely been proposed before.  Worth checking with Anne to see
>> what the status is.  Specifically, did it die, and if so why? Because I,
>> too, think this would be an interesting avenue to explore...
> 
> See https://github.com/whatwg/dom/issues/150. There's not really any
> dominant pattern that's succeeded here in libraries that we could
> adopt. You typically end up looking at templating and that has its own
> host of issues. The other thing that would solve some of this is
> browser-backed sanitization, but that's also a hard problem to solve
> nobody has been willing to tackle and get standardized.
> 
> 

Some folks are Google are working on a solution based on Types:


I've tried providing feedback here and there, but they are moving fast
and I'm not included in all of their conversations, since they are not
public (despite their good history of working with W3C WebAppSec). :(
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

[Frederik Braun]

On 02.10.2017 18:03, Daniel Veditz wrote:
> ​Fair enough. Could we propose improvements to the API​s that would make
> them more usable? For example an object argument to createElement() that
> contained attribute/value pairs?
> 
>   var div = document.createElement("div", null, {"id":"foo",
> "class":"bar"});
>   parent.prepend(div);
> 
> (the null is for the existing custom elements options param)

Well, you _could_ write something like

var div = Object.assign(document.createElement("div"), {
id: "foo",
className: "bar",
});
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Phabricator and confidential reviews

[Frederik Braun]

Having both reported, fixed and reviewed security bugs, I feel an
uni-directional sync from Phabricator to BMO is not going to cut it. I
think it will be unexpected for most users and might just lead to
additional "why can I not see the patch" bug comments.

I understand that it's more work, but I really think we should aim for
"perfect" rather than "good enough", when it comes to developer experience.

I don't see a strong "security reason" not to include people copied in
the bug to see the patch. Quite contrary: It's also what distinguishes
our bug bounty program from others. We're more open, we have outside
reporters work with us on the patch and see all the comments and
iterations that lead to its perfection. This encourages early feedback
and improves the outcome.

On 10.08.2017 00:57, Daniel Veditz wrote:
> On Wed, Aug 9, 2017 at 11:32 AM, Mark Côté  wrote:
> 
>> I actually like Gijs's proposal, to mirror *from* Phabricator *to* BMO.
>> That way, if you're looking at the bug and want to pull someone in, you CC
>> them; if you're looking at the fix and want to involve someone, you add
>> them as a subscriber which then incidentally lets them view the bug, for
>> background and updates and such.
> 
> 
> ​What if there's not "the" fix but multiple patches? This is quite common
> for security bugs where a testcase that reveals the vulnerability is done
> in a separate patch so it can be checked in after we release the fix. Or
> occasionally bugs like https://bugzilla.mozilla.org/show_bug.cgi?id=1371259
> that had 9 separate patches. Would the same people have to be separately
> subscribed to each?​
> 
> ​There's a case to be made for adding in both directions. How much work
> would it be to (add all CCs to subscriber list) when attaching a new patch,
> and (subscribe person to all existing patches)​ when someone new is CC'd to
> a bug? This was my attempt to match your "one time mirroring" approach to
> going the other way, which makes sense to me.
> 
> And don't forget reporter and assignees. Occasionally a reporter not in the
> security group will notice that a patch is insufficient which is nicer to
> find before the patch is committed than after the commit link is added to
> the bug. Sometimes someone other than the official assignee adds a patch
> for an alternate approach to a fix and asks the assignee for feedback,
> though that's uncommon and the assignee could just be manually subscribed
> to the patch at that point.
> 
> We can wait and see how common the "please subscribe me to the patch"
> requests are, but I suspect they'll be common enough.
> 
> -
> ​Dan Veditz​
> ___
> 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 remove: sensor APIs

[Frederik Braun]

As mentioned in thread, we will not disable deviceorientation.
Please see below.

On 02.08.2017 15:01, Salvador de la Puente wrote:
> I strongly encourage you to take a look at the telemetry stats regarding
> the usage of deviceorientation API and other. I don't know the penetration
> of proximity and ambient light APIs but deviceorientation is definitively
> used.
> 
> Please, consider twice before taking a final decision.
> 
> El 31 jul. 2017 3:44 p. m., "Anne van Kesteren"  escribió:
> 
>> On Mon, Jul 24, 2017 at 6:11 PM, Anne van Kesteren 
>> wrote:
>>> Please consider the request to remove device orientation retracted for
>>> now. We'll still need to figure out some kind of long term plan for
>>> that API though. WebVR building on it through libraries that abstract
>>> away the browser incompatibilities will just make it harder to fix the
>>> underpinnings going forward. (And there's always the risk that folks
>>> don't use libraries and code directly against what Chrome ships. Seems
>>> likely even.)
>>
>> Small update: we'll start by just disabling proximity. Disabling
>> ambient light will follow soon after, but is a little trickier as we
>> use the web-facing API in the Firefox for Android frontend.
>> (Suggestions for fixing the orientation interoperability mess are
>> still welcome!)
>>
>>
>> --
>> 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: git mirror

[Frederik Braun]

You could also look at git-cinnabar.
It's a git helper that allows you to talk to HG remotes developed by
Glandium, a Mozilla hacker.

See

for more

Hope this helps,
Freddy

P.S: If you only want to look at code and search for stuff, I can
recommend https://searchfox.org/


On 22.07.2017 21:42, Enrico Weigelt, metux IT consult wrote:
> Hi folks,
> 
> 
> are there any official git mirrors (at least for the esr branches),
> that are regularily updated ?
> 
> The repos is *really* huge - import really takes a long time (started
> about 10hrs ago, still just not much over 10%). Github even gives up.
> Even hg clone runs for hours.
> 
> I'm looking for an git repo, where I can do a (shallow) clone from,
> that also receives updates from the hg master.
> 
> 
> thx
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: More Rust code

[Frederik Braun]

On 18.07.2017 06:01, Jim Blandy wrote:
> BTW, speaking of training: Jason's and my book, "Programming Rust" will be
> available on paper from O'Reilly on August 29th! Steve Klabnik's book with
> No Starch Press is coming out soon as well, but I don't know the details
> there.
> 

Steve's book is the paper version of 
AFAIU.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: More Rust code

[Frederik Braun]

On 10.07.2017 12:29, Nicholas Nethercote wrote:
> 
> What are the obstacles? Here are some that I've heard.
> 
> - Lack of Rust expertise for both writing and reviewing code. We have some
> pockets of expertise, but these need to be expanded greatly. I've heard
> that there has been some Rust training in the Paris and Toronto offices.
> Would training in other offices (esp. MV and SF, given their size) be a
> good idea? What about remoties?

FYI I have been (secretly[1]) thinking about Rust trainings in the
Berlin office.
AFAIU the previous trainings used the professional development budget
from those who attended. Naturally, the same could be true for remoties?
Though of course they'd also have to budget for travel/accomodation.





[1] Maybe today is the day, I should start finding out what the demand is
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Enabling filesystem read-restrictions for content process sandbox

[Frederik Braun]

Hooray, this is great news!


On 06.07.2017 16:07, Alex Gaynor wrote:
> Hi dev-platform,
> 
> On behalf of the Runtime Content Isolation (aka sandboxing) team, I'm
> delighted
> to announce that starting later this week, our macOS and Windows nightly
> builds
> will prohibit read access to most of the filesystem in the content process!
> 
> What does this mean for you? First and foremost, a more secure browser!
> Second,
> it means that if you see bugs, please report them, our goal is to put this
> on
> the trains for 56! If you run into anything, please file it as a blocker for
> https://bugzilla.mozilla.org/show_bug.cgi?id=1377522 .
> 
> Finally, it means that in code you're writing, you should not expect to be
> able
> to read from the filesystem in the content process -- with the exception of
> inside the .app bundle, or in the chrome/ subdirectory of the profile
> directory.
> 
> If you need access to a file in content, you should plan on remoting that
> to the
> parent process. When designing these APIs, please be careful to ensure the
> parent process is able to perform appropriate permissions checks such that
> the
> IPC mechanism isn't able to bypass the sandbox's goal of preventing a
> malicious
> content process from accessing the entire file system.
> 
> This represents the culmination of a lot of work by a lot of folks, both on
> our
> team and on many other teams who helped out with refactoring their code --
> thank
> you!
> 
> We're looking forward to also shipping this for Linux soon.
> 
> Cheers,
> Alex
> ___
> 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

[Frederik Braun]

On 28.04.2017 05:56, Ehsan Akhgari wrote:
> On 04/27/2017 08:09 AM, Frederik Braun wrote:
>> On 27.04.2017 13:56, smaug wrote:
>>> On 04/25/2017 04:38 PM, Ehsan Akhgari wrote:
>>>> On 04/24/2017 06:04 PM, 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.
>>>> How does restricting this to secure contexts help?
>>> This is a good point to remember in this kinds of attacks. So often has
>>> use of secure context suggested as the way to
>>> fix issues, when it often doesn't really help at all with the core
>>> issue.
>>>
>>> And the initial email did have
>>> "Unshipping for non-secure context and making it HTTPS-only wouldn't
>>> address the attack."
>>>
>> While it does not address the attack, it should be limited to secure
>> context, if we keep the API. It's actually in the spec.
> Why is that an advantage?  Any attacker can use a secure context. The
> word "secure" here relates to the security of the transport layer, but
> if the origin itself is untrusted (which it is) exposing an unsafe
> functionality to a "secure" context is just as unsafe.
> 
> (And on the practical side of things, any attacker can use a free or
> paid CA service to deliver their attack code through a secure channel.)
> 

Yes, yes and yes. This is not about the attack at all.
This is about powerful features using secure contexts.

>>
>>>
>>> (Also, secure context itself is in its current design rather broken,
>>> IMO, yet hinting in its name that it is somehow secure.
>>>   BroadcastChannel or localStorage etc are easy ways to transfer data
>>> from secure context to non-secure. )
>>>
>>>
>>>If I understand correctly the attacks being discussed in the article
>>> referenced here are stealing
>>>> cross origin data and user's history.  These aren't things that we can
>>>> expose to secure contexts any more than we can expose to insecure
>>>> contexts.
>>>>> Since the amount of information that can be extracted is a function of
>>>>> the number of times the API is called and the accuracy of the reading,
>>>>> we should consider also reducing the accuracy of the reading.  The
>>>>> attack reduced its information extraction to 1 bit per reading, but
>>>>> you can't assume that this is the actual limit.  Fuzzing is much
>>>>> harder than it seems if your intent is to deal with an attack.  I can
>>>>> walk through some strategies if someone is interested in doing this.
>>>>>
>>>>> That all assumes that you aren't willing to add a dialog for this,
>>>>> which seems like the right answer.  That said, if the mitigation
>>>>> strategies - rate limiting in particular - can't be implemented in a
>>>>> reasonable time-frame, I would consider preffing this off (though the
>>>>> pref name suggests that there would be collateral).
>>>> It seems hard to explain the risks of granting this permission to a
>>>> site to a user correctly.  :-/  A permission prompt that doesn't allow
>>>> us do that
>>>> isn't very useful.  Also given that the API is an event handler, it
>>>> doesn't really lend itself to a permission prompt anyway.
>>>>
>>>> But also given the event handler nature of the API, not dispatching
>>>> the event makes it very unlikely to break pages, unless if the page's
>>>> functionality explicitly depends on the ambient light, I think, which
>>>> works in our favor if we decide in that direction.  I think I'm
>>>> leaning in that
>>>> way personally rather than coming up with a complicated heuristic here
>>>> and potentially getting it wrong.
>>>>> On Tue, Apr 25, 2017 at 12:06 AM, Jonathan Kingston 
>>>>> wrote:
>>>>>> As a follow up, it looks like the device motion events defined in the
>>>>>> device sensors:
>>>>>> http://searchfox.org/mozil

Re: Ambient Light Sensor API

[Frederik Braun]

On 27.04.2017 13:56, smaug wrote:
> On 04/25/2017 04:38 PM, Ehsan Akhgari wrote:
>> On 04/24/2017 06:04 PM, 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.
>>
>> How does restricting this to secure contexts help?
> This is a good point to remember in this kinds of attacks. So often has
> use of secure context suggested as the way to
> fix issues, when it often doesn't really help at all with the core issue.
> 
> And the initial email did have
> "Unshipping for non-secure context and making it HTTPS-only wouldn't
> address the attack."
> 

While it does not address the attack, it should be limited to secure
context, if we keep the API. It's actually in the spec.

> 
> 
> (Also, secure context itself is in its current design rather broken,
> IMO, yet hinting in its name that it is somehow secure.
>  BroadcastChannel or localStorage etc are easy ways to transfer data
> from secure context to non-secure. )
> 
> 
>   If I understand correctly the attacks being discussed in the article
> referenced here are stealing
>> cross origin data and user's history.  These aren't things that we can
>> expose to secure contexts any more than we can expose to insecure
>> contexts.
>>> Since the amount of information that can be extracted is a function of
>>> the number of times the API is called and the accuracy of the reading,
>>> we should consider also reducing the accuracy of the reading.  The
>>> attack reduced its information extraction to 1 bit per reading, but
>>> you can't assume that this is the actual limit.  Fuzzing is much
>>> harder than it seems if your intent is to deal with an attack.  I can
>>> walk through some strategies if someone is interested in doing this.
>>>
>>> That all assumes that you aren't willing to add a dialog for this,
>>> which seems like the right answer.  That said, if the mitigation
>>> strategies - rate limiting in particular - can't be implemented in a
>>> reasonable time-frame, I would consider preffing this off (though the
>>> pref name suggests that there would be collateral).
>>
>> It seems hard to explain the risks of granting this permission to a
>> site to a user correctly.  :-/  A permission prompt that doesn't allow
>> us do that
>> isn't very useful.  Also given that the API is an event handler, it
>> doesn't really lend itself to a permission prompt anyway.
>>
>> But also given the event handler nature of the API, not dispatching
>> the event makes it very unlikely to break pages, unless if the page's
>> functionality explicitly depends on the ambient light, I think, which
>> works in our favor if we decide in that direction.  I think I'm
>> leaning in that
>> way personally rather than coming up with a complicated heuristic here
>> and potentially getting it wrong.
>>>
>>> On Tue, Apr 25, 2017 at 12:06 AM, Jonathan Kingston 
>>> wrote:
>>>> As a follow up, it looks like the device motion events defined in the
>>>> device sensors:
>>>> http://searchfox.org/mozilla-central/source/dom/system/nsDeviceSensors.cp
>>>>
>>>> should also be restricting based on isSecureContext.
>>>>
>>>> The spec mentions "should take into consideration the following
>>>> suggestions"
>>>> :
>>>> https://www.w3.org/TR/orientation-event/#security-and-privacy
>>>>
>>>> We don't do those measures from what I can see.
>>>>
>>>> Can we make the webIDL represent this requirement for requiring secure
>>>> context instead?
>>>>
>>>> Thanks
>>>> Jonathan
>>>>
>>>> On Mon, Apr 24, 2017 at 2:41 PM, Jonathan Kingston 
>>>> wrote:
>>>>
>>>>> As mentioned a permission prompt isn't great.
>>>>>
>>>>> In it's current state it should probably be considered a "powerful
>>>>> feature" that we can remove just for secure context. Granted this
>>>>> doesn't
>>>>> fix the exploit mentioned here thou

Re: Ambient Light Sensor API

[Frederik Braun]

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

Ambient Light Sensor API

[Frederik Braun]

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

Re: Better download security through browsers

[Frederik Braun]

On 27.03.2017 16:21, Daniel Veditz wrote:
> On Mon, Mar 27, 2017 at 1:22 AM, Frederik Braun  <mailto:fbr...@mozilla.com>> wrote:
>
> UI hooks, for the SafeBrowsing
> ​ ​
> malicious file checks, where we really,
> ​ ​
> really discourage you from using
> ​ ​
> the downloaded file but you can still click around that with lots of
> ​ ​
> left-clicking.
>
>
> ​"Not known to be malicious" is completely different from "the exact
> file I intended you to download".
>

Yes. But the UX mechanics are similar, no?

A download finished, but the complete file is not going to make you
happy. We will tell you that there is a problem with an indicator and we
will not let you easily click/open that file, unless you right-click and
go through a dialog.

> -Dan Veditz​
>

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

Re: Better download security through browsers

[Frederik Braun]

On 24.03.2017 18:24, Mike Hoye wrote:
> My 2006 proposal didn't get any traction either.
> 
> https://lists.w3.org/Archives/Public/public-whatwg-archive/2006Jan/0270.html
> 
> 
> FWIW I still think it'd be a good idea with the right UI.

I think we already have _related_ UI hooks, for the SafeBrowsing
malicious file checks, where we really, really discourage you from using
the downloaded file but you can still click around that with lots of
left-clicking.

> 
> - mhoye
> 
> On 2017-03-24 1:16 PM, Dave Townsend wrote:
>> I remember that Gerv was interested in a similar idea many years ago, you
>> might want to see if he went anywhere with it.
>>
>> https://blog.gerv.net/2005/03/link_fingerprin_1/
>>
>>
>> On Fri, Mar 24, 2017 at 10:12 AM, Gregory Szorc  wrote:
>>
>>> I recently reinstalled Windows 10 on one of my machines. This involved
>>> visiting various web sites and downloading lots of software.
>>>
>>> It is pretty common for software publishers to publish hashes or
>>> cryptographic signatures of software so the downloaded software can be
>>> verified. (Often times the download is performed through a CDN,
>>> mirroring
>>> network, etc and you may not have full trust in the server operator.)
>>>
>>> Unless you know how to practice safe security, you probably don't bother
>>> verifying downloaded files match the signatures authors have provided.
>>> Furthermore, many sites redundantly write documentation for how to
>>> verify
>>> the integrity of downloads. This feels sub-optimal.
>>>
>>> This got me thinking: why doesn't the user agent get involved to help
>>> provide better download security? What my (not a web standard spec
>>> author)
>>> brain came up with is standardized metadata in the HTML for the download
>>> link (probably an ) that defines file integrity information. When the
>>> user agent downloads that file, it automatically verifies file integrity
>>> and fails the download or pops up a big warning box, etc or things don't
>>> check out. In other words, this mechanism would extend the trust
>>> anchor in
>>> the source web site (likely via a trusted x509 cert) to file downloads.
>>> This would provide additional security over (optional) x509 cert
>>> validation
>>> of the download server alone. Having the integrity metadata baked
>>> into the
>>> origin site is important: you can't trust the HTTP response from the
>>> download server because it may be from an untrusted server.
>>>
>>> Having such a feature would also improve the web experience. How many
>>> times
>>> have you downloaded a corrupted file? Advanced user agents (like
>>> browsers)
>>> could keep telemetry of how often downloads fail integrity. This
>>> could be
>>> used to identify buggy proxies, malicious ISPs rewriting content, etc.
>>>
>>> I was curious if this enhancement to the web platform has ever been
>>> considered and/or if it is something Mozilla would consider pushing.
>>>
>>> gps
>>> ___
>>> 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: Please do NOT hand-edit web platform test MANIFEST.json files

[Frederik Braun]

> Fun fact: lots of JSON documents also evaluate as Python data structures.
> So if you prepend "foo = " and throw that into eval(), you can
> magically evaluate a JSON document into a Python variable. Of course,
> eval() is a security concern. But people blindly execute code in
> mozilla-central (like the build system) all the time. So perhaps this is
> tolerable.

from ast import literal_eval

literal_eval does not execute code. Only accepts literals.
Works in all Python versions.

Please don't use eval!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The future of commit access policy for core Firefox

[Frederik Braun]

On 12.03.2017 04:08, Cameron Kaiser wrote:
> On 3/10/17 4:38 AM, Masatoshi Kimura wrote:
>> On 2017/03/10 6:53, Mike Connor wrote:
>>> - Two-factor auth must be a requirement for all users approving or
>>> pushing a change.
>>
>> I have no mobile devices. How can I use 2FA?
>>
>> Previously I was suggested to buy a new PC and SSD only to shorten the
>> build time. Now do I have to buy a smartphone only to contribute
>> Mozilla? What's the next?
> 
> I actually use a Perl script to do HOTP. And there are things like
> Firekey. No mobile device necessary.

Doesn't that defeat the point of a second factor?

> 
> Cameron Kaiser
> tier-3-2-1-contact!
> ___
> 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: Is there a way to improve partial compilation times?

[Frederik Braun]

Gotcha.
Problem for the Berlin office: There are only 3 people who have a
desktop and run linux. Two of them are part of our "cluster" :)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Is there a way to improve partial compilation times?

[Frederik Braun]

On 08.03.2017 01:17, Ralph Giles wrote:
> I second Jeff's point about building with icecream[1]. If you work in
> an office with a build farm, or near a fast desktop machine you can
> pass jobs to, this makes laptop builds much more tolerable.
>

What do you mean by build farm?
Do some offices have dedicated build machines?
Or is this "just" a lot of desktop machines wired up to work together?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

[Frederik Braun]

On 10.02.2017 01:09, Xidorn Quan wrote:
> On Fri, Feb 10, 2017, at 04:29 AM, Benjamin Smedberg wrote:
>> Will this also prevent loading downloaded .swf files into Firefox? This
>> is
>>> useful for running Flash games, which tend to work best in the browser
>>> (some media players also support loading Flash files, but their hotkeys
>>> tend to conflict).
>>
>> It will prevent them from loading via File > Open, yes (and that is the
>> fundamental change we need to make). If you were to serve them via
>> localhost you could still use them (e.g. with python -m
>> SimpleHTTPServer).
> 
> I kind of disagree with this. SimpleHTTPServer is simple for developers
> but not at all for normal users. I think it should be allowed to load a
> top level Flash file. What harm could it do if we allow that?
> 

toplevel loads includes opened via window.open and target=_blank, no?

This means HTML/JS from file:, ftp: etc. could still find a way to open
SWF from those non-HTTP/HTTPs sites.

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

Re: What are your use cases for the Touch Bar on the new MacBook Pro?

[Frederik Braun]

Tab Preview that allows quick scrolling
Open New Tab (+ Icon)

When already in a new tab: Quick access to most visisted websites (like
the tiles)



On 03.01.2017 18:17, Stephen A Pohl wrote:
> We are gathering ideas for possible use cases of the Touch Bar on the
> new MacBookPro and would like to hear from you! What would improve your
> workflow? What would help our users?
> 
> We will develop[1] a solid 1.0 API around the top features to get the
> ball rolling and will iterate on these going forward.
> 
> Apple has outlined guidelines and best practices[1] for the Touch Bar
> that are good to keep in mind. Here are some of the most important
> points to consider:
> 1. Design a contextual experience. Make the Touch Bar relevant to the
> current context on the main screen.
> 2. Use the Touch Bar as an extension of the keyboard and trackpad, not
> as a display.
> 3. **Don’t expose functionality solely in the Touch Bar.
> 4. Avoid using the Touch Bar for tasks associated with well-known
> keyboard shortcuts.
> 
> -Stephen
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1313455
> [2]
> https://developer.apple.com/library/content/documentation/UserExperience/Conceptual/OSXHIGuidelines/AbouttheTouchBar.html#//apple_ref/doc/uid/2957-CH104-SW1
> ___
> 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: Who loves multiple selection feature in editor?

[Frederik Braun]

On 19.12.2016 17:19, glazou wrote:
> Le jeudi 15 décembre 2016 10:47:28 UTC+1, masayuki nakano a écrit :
> 
>> So, it might be better to stop supporting multiple selection only in 
>> editor if the feature is not so loved by users.
> 
> We were already discussing this issue at Netscape 15 years ago but could not 
> come up with a good solution at that time. Thanks for bringing it back, this 
> could be the right time to finally solve it.
> 
> Some existing use cases:
> 
> 1. this is absolutely needed for table cell selection. Everyone extensively 
> using tables uses multiple selection at some point.
> 

I'm generally all for removing complexity and I hate to be a spoilsport.
 But table cell selection is pretty useful (e.g., a full row, a full
column and the possibility of removing a few here and there)


> 2. Microsoft Word on all platforms and in general all commercial Whysiwyg 
> Text editors allow multiple selection.
> 
> 3. multiple selection is really cool if you think of images representing 
> videoframes you select to edit/crop a video.
> 
> 4. "search a text" often ends with a multiple selection of all occurrences of 
> the pattern in the document
> 
> On another hand, I think selection would benefit from a boolean attribute 
> saying if the rendering engine allows or not multiple selection and if it 
> does not, having shortcut mechanisms allowing to get rid of the onmipresent 
> and painful getRangeAt(0). We do quite equivalent things when the selection 
> is collapsed.
> 
> 
> ___
> 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: HTML spec changes about data: URIs and origins

[Frederik Braun]

On Tue, Sep 13, 2016 at 5:02 PM, Boris Zbarsky  wrote:
> On 9/13/16 8:31 AM, Frederik Braun wrote:
>> I'd be happy to add a telemetry probe
>
>
> For what, exactly?  What do you propose to measure?
>

First of all, just to see how much breakage to expect when doing this
on the web.
So I wonder, is there a code path that we'd always call for DOM access
to other window objects than the current global scope (e.g., iframes,
popups), which have a data URL?

I assume the mere creation of those iframes/popups is possibly less useful.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

HTML spec changes about data: URIs and origins

[Frederik Braun]

Firefox treats iframes pointing to a data URL as same-origin. This is
all well-known, was part of the HTML spec and has been discussed before
[1,2]

What has changed now is the HTML spec text[3]: Given that EdgeHTML,
Webkit and Blink violated this requirement, the standard now turned
around and assigns them a unique opaque origin.
I'll gladly accept the fact that we are not the violator, given the
security implications [1].

The GitHub related issue[4] included a discussion with some of our DOM
folks, but did not come to a conclusion as to what we plan to do here.

Is back compat the main concern? I'd be happy to add a telemetry probe
and a devtools warning if someone is willing to point me in the right
direction.


Thanks,
Freddy


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=255107
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1018872
[3]
https://github.com/whatwg/html/commit/00769464e80149368672b894b50881134da4602f
[4] https://github.com/whatwg/html/issues/1753
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove:

[Frederik Braun]

Strong agreement for removing .

Looking at
,
it seems that Blink was successful in discouraging its use.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Spidernode/JXCore

[Frederik Braun]

There are indeed discussions in nodejs to became more vm agnostic.
This was also hinted at in
https://github.com/mozilla/spidernode/issues/3

On Thu, Apr 14, 2016 at 6:08 PM, Steve Fink  wrote:
> On 04/14/2016 06:21 AM, Philip Chee wrote:
>>
>> On 12/04/2016 19:27, Henri Sivonen wrote:
>>
>>> My understanding is that
>>> https://git.merproject.org/mer-core/qtmozembed/ still uses it. As we
>>> are figuring out how to be more embeddable (see
>>> https://medium.com/@david_bryant/embed-everything-9aeff6911da0 ), it's
>>
>> AFAICT Spidernode is an ex-parrot. However the JXCore fork of Node.js
>> can optionally use SpiderMonkey as their JavaScript engine. I wonder if
>> the JXCore people would be willing to upstream their changes back to
>> Mozilla?
>
>
> There's a new spidernode now -- . But
> it's much less complete than JXCore. Sadly, JXCore has itself been
> discontinued, but the source was released under an MIT-style license at
> .
>
> Neither makes any changes to SpiderMonkey afaik; the changes that could be
> upstreamed are to the Node source.
>
> I'm not that familiar with Node or either of these SpiderMonkey shim layers,
> but I have heard word that some of the changes may be fairly invasive. The
> best route probably depends on the changes required, and the willingness of
> the Node maintainers to accept these things. It's kind of feeling to me like
> it's about time for Node to abstract away from v8 a bit so that it can more
> easily run under either SpiderMonkey or ChakraCore (they've also done a Node
> port, some parts of which are the basis for the new spidernode.)
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: TV Control Working Group

[Frederik Braun]

On 10.03.2016 08:53, L. David Baron wrote:
> On Tuesday 2016-03-01 09:32 +0800, L. David Baron wrote:
>> The W3C is proposing a charter for:
>>
>>   TV Control Working Group
>>   https://www.w3.org/2016/02/tvcontrol.html
>>   https://lists.w3.org/Archives/Public/public-new-work/2016Feb/0005.html
>>
>> Mozilla has the opportunity to send comments or objections through
>> Friday, March 18.
>>
>> Please reply to this thread if you think there's something we should
>> say as part of this charter review.
> 
> 
> So given that we've been pretty involved in the work in the
> community group that led to this working group, I think we probably
> should say something here.  I just talked to SC Chien and Joe Cheng
> about our involment and ran this plan (although not the text) past
> them.
> 
> 
> I think we should abstain from the review, but abstain with
> comments, saying something like:
> 
>   Although we've participated in the development of this work in the
>   community group, this is an area that we're becoming less involved
>   in.
> 
>   We're also concerned about the general applicability of this work
>   to the Web.  Our own use of the subset of this API that we
>   implement has been restricted to privileged apps on Firefox OS,
>   and we're not aware of how it could fit in to the Web's security
>   model.
> 
> Does this seem reasonable?

I have been involved in FxOS TV security things and I agree with this
assessment about compatibility with the web security model.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: When the beta version of firefox with e10s would be released?

[Frederik Braun]

On 03.12.2015 12:55, Yonggang Luo wrote:
> On Thursday, December 3, 2015 at 4:57:28 PM UTC+8, Dave Townsend wrote:
>> The developer edition already ships with e10s so you can test against that.
> Indeed, I am looking for more stable version

I use Developer Edition (aurora) for many years now and have yet to
experience a moment of major instability.

I do not know your use case, but I'd argue that Developer Edition is a
very good test environment.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

[Frederik Braun]

On 02.12.2015 18:53, Robert O'Callahan wrote:
> On Wed, Dec 2, 2015 at 9:37 AM, Eric Rescorla  wrote:
> 
>> Are you thinking of something like WebUSB?
>> (https://reillyeon.github.io/webusb/)? This is something we've looked at
>> a bit but we're still trying to wrap our heads around the security
>> implications.
>>
> 
> Where are we discussing that? I'd really like to see WebUSB with USB device
> IDs are bound to specific origins (through a registry for legacy devices
> and through the USB protocol extensions defined in that spec) so that
> vendors can host apps that access their devices --- and so that vendor
> pages in an  can define and vend "safe" APIs to any third-party
> application. We'd finally have decentralized extensibility for Web APIs to
> hardware.
> 
> Rob
> 

This is an interesting architecture.
I was originally thinking about allowing to list all possible devices
*and* preventing fingerprinting through a chrome dialog that mediates
between content and the user: The user chooses which device(s) to expose
to the specific website they are on. Similar to .
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: ESLint is now available in the entire tree

[Frederik Braun]

On 30.11.2015 10:29, Patrick Brosset wrote:
> I don't how much work is involved with getting rid of non-standard
> spidermonkey syntax and pre-processors, but if it's a lot, then one option
> would be to fork the espree parser (used by eslint), make it support those,
> and configure eslint to use our fork:
> http://eslint.org/docs/user-guide/configuring.html#specifying-parser
> 

Or use babel, it supports a bigger portion of the bleeding edge, in my
experience :)

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

Re: Dan Stillman's concerns about Extension Signing

[Frederik Braun]

On 27.11.2015 13:16, Gervase Markham wrote:
> On 26/11/15 17:13, Mike Hoye wrote:
>> Stillman wrote some new code and put it through a process meant to catch
>> problems in old code, and it passed. That's unfortunate, but does it
>> really surprise anyone that security is an evolving process? That it
>> might be be full of hard tradeoffs? There is a _huge_gap_ between "new
>> code can defeat old security measures" and "therefore all the old
>> security measures are useless". 
> 
> But the thing is, members of our security group are now piling into the
> bug pointing out that trying to find malicious JS code by static code
> review is literally _impossible_ (and perhaps hinting that they'd have
> said so much earlier if someone had asked them).
> 
> You can evolve your process all you like, but if something is
> impossible, it's impossible. And not only that, but attempting it seems
> to be causing significant collateral damage.
> 

We can detect obfuscation and disallow it, though. It's not "all is
lost", but "impossible to be 100% exact, if we allow arbitrary
JavaScript". I think we already disallow certain language features (e.g.
eval?).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: TIFU by using Math.random()

[Frederik Braun]

On 25.11.2015 12:42, Philip Chee wrote:
> 
> 
> Hopefully Spidermonkey's Math.random() is better.
> 
> Phil
> 

There have been multiple insightful responses on HN and reddit/netsec.
The short version is, that Math.random() isn't providing statistically
good randomness, because JS benchmarks use it. So it has been optimized
for performance in most browsers.

Also, the person writing the post did not only want randomness, but
uniqueness. If someone wants unique, you should use a UUID-algorithm.
If all you need is a better PRNG use crypto.getRandomValues(), which is
providing cryptographically secure randomness.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: CSS Mask Image properties

[Frederik Braun]

This reads like it could pose similar problems than those we've had with
SVG Filters, i.e., repaint timing and history sniffing.

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

Who would be a good person to verify / analyze this?



On 10.11.2015 08:09, Ku(顧思捷)CJ wrote:
> *Summary*:
> Intend to implement CSS mask. By using this it, you can apply a mask to a
> graphical object, so that the graphical object will be painted onto the
> background through a mask, thus completely or partially masking out parts
> of the graphical object.
> 
> *Bug*:
> https://bugzilla.mozilla.org/show_bug.cgi?id=686281
> 
> *Link to standard*:
> https://drafts.fxtf.org/css-masking-1/
> 
> *Platform coverage*:
> everywhere
> 
> Estimated or target release:
> Firefox 43
> 
> *DevTools bug*:
> none
> 
> Supported by both Chrome and Safari.
> ___
> 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: Fido U2F, two-factor authentication support

[Frederik Braun]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

There is an experimental add-on being worked on that tries bring U2F
support to Firefox. The source code is at
, but it has not yet gone through
the Add-on review process.



Btw, the most important thing about the bug is comment 62
(https://bugzilla.mozilla.org/show_bug.cgi?id=1065729#c62).

To quickly summarize what Richard said:

Yes, nobody within the Mozilla corporation is officially assigned to
work on this.
The abstraction level of the API is not very interoperable with all
kinds of second factors that are not compliant with FIDO U2F, which is
a bit unfortunate.
We will allow third-party contributions and would suggest implementing
an USB HID API, which would be arguably more useful for any kind of
second factor implementation to sit on top.
Part of this is being worked on in
https://bugzilla.mozilla.org/show_bug.cgi?id=1198330, it seems?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWOxnyAAoJEOwSh5wL+fW4+UsIAMrSDpMgHZn7I0bBM1p6CmA/
+KU6rkyydV2FV3/cdDql/Z9xJLL2SJrclnIGuPfUIVbGdm+cO0zxVW/9ZUbk3u/E
7XfHV34ZvizPrNbsMpMu3z8O2a+M0UNH3PxbT8huvU1V2eCxlduPkpieO7uegbmE
kH9GX31wk+mCMGItkCdu4NIaBjLKv2xNeXyzZjMmOxRSgH3clKGyumiz+K6tj1FJ
yTjRLkCSP2mADopDQTQPxF6/DAV/INj/2uHNOA1jhd6gBiv46j3PaYf23iUGoPQt
y1OwQClwCsOvXHhxYotLLlHfb1dDgFO33b4bQGGqgwfIMYiWDvDTucFzezSesRQ=
=3zWK
-END PGP SIGNATURE-
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [feature] open certain domains into a private window

[Frederik Braun]

On 24.06.2015 10:09, Karl Dubost wrote:
> 
> Le 23 juin 2015 à 20:57, Andreas Tolfsen  a écrit :
>> Is it an option to register two browser handlers in the operating system for 
>> Firefox? 
> 
> nope. Because only Firefox knows based on your preferences which domains you 
> always want in a private mode silo. Imagine a series of Firefox silos (or 
> buckets), in this bucket I only accept these domains, subdomains. Each silo 
> is unable to communicate with another one. So you are sure that when you 
> surfing a certain domain there will be no spill of your data, tracking, etc.
> 
> 
> 

This reminds me of the great work Sid and Monica (from Firefox Security
Engineering) have done on explaining the notion of "Contextual Identity"
(http://www.w2spconf.com/2013/papers/s1p2.pdf)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Modifying Element.prototype for all globals

[Frederik Braun]

On 18.06.2015 15:51, smaug wrote:
> On 06/18/2015 03:37 PM, Frederik Braun wrote:
>> Hi,
>>
>> I am planning to do a little analysis of FxOS Gaia to identify instances
>> of innerHTML assignments at runtime[1]. I am hoping this gives me a more
>> precise number about hot paths (in contrast to just looking at the
>> source code).
> 
> What kind of information would you like to get out from the analysis?
> And before even spending too much time with innerHTML, are you sure the
> possible
> performance issues are about it, and not about creating/reflowing layout
> objects for the new elements?
> (innerHTML implementation is in common cases quite well optimized.)

Thanks for the pointers!

Ha, I sould have been more expressive. I am not interested in performance:

I have written an eslint plugin to identify and disallow future patches
that contain assignments of innerHTML which do not use our XSS sanitizer
(https://developer.mozilla.org/en-US/Firefox_OS/Security/Security_Automation).

Now I want to look at existing issues and identify those that should be
fixed first. I hope that an instrumentation (and stack traces) can give
me a better idea of what different code paths lead to these sinks.
(On the side, I was also hoping to learn something new :))



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

Re: Modifying Element.prototype for all globals

[Frederik Braun]

On 18.06.2015 14:56, Gijs Kruitbosch wrote:
> I'm sure this is a dumb question, but why not modify the actual
> implementation of innerHTML in the core DOM if you're doing a modified
> try-run anyway?
> 

This is actually a very good question.

Unfortunately, I'm not that great at C/C++ and was hoping for a JS solution.

(In the beginning of writing previous email, I was hoping for a solution
that could live completely in Gaia, thus saving me compile time and
enabling me to use try for running my test. But I dont think I can run
try for both a custom b2g as well as a custom gaia)

> ~ Gijs
> 
> On 18/06/2015 13:37, Frederik Braun wrote:
>> Hi,
>>
>> I am planning to do a little analysis of FxOS Gaia to identify instances
>> of innerHTML assignments at runtime[1]. I am hoping this gives me a more
>> precise number about hot paths (in contrast to just looking at the
>> source code).
>>
>> In an ideal world I would write a script along the lines of
>> `Object.defineProperty(Element.prototype, 'innerHTML', …)` and inject
>> this into every app, or at best run it somewhere so that every Element's
>> prototype chains back to mine.
>>
>> I know that I can not modify/inherit prototypes across origins, so I am
>> wondering if there is something I could do with chrome privileges -
>> maybe patching shell.js
>> (https://dxr.mozilla.org/mozilla-central/source/b2g/chrome/content/shell.js),
>>
>> as it is the main entrypoint from Gecko into Gaia.
>>
>> Does this sound feasible? Are there any previous experiments that I
>> could refer to?
>>
>>
>> Thanks!
>> Freddy
>>
>>
>> [1] I intend to run the full test suite, not in production or anything.
>>
> 
> ___
> 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

Modifying Element.prototype for all globals

[Frederik Braun]

Hi,

I am planning to do a little analysis of FxOS Gaia to identify instances
of innerHTML assignments at runtime[1]. I am hoping this gives me a more
precise number about hot paths (in contrast to just looking at the
source code).

In an ideal world I would write a script along the lines of
`Object.defineProperty(Element.prototype, 'innerHTML', …)` and inject
this into every app, or at best run it somewhere so that every Element's
prototype chains back to mine.

I know that I can not modify/inherit prototypes across origins, so I am
wondering if there is something I could do with chrome privileges -
maybe patching shell.js
(https://dxr.mozilla.org/mozilla-central/source/b2g/chrome/content/shell.js),
as it is the main entrypoint from Gecko into Gaia.

Does this sound feasible? Are there any previous experiments that I
could refer to?


Thanks!
Freddy


[1] I intend to run the full test suite, not in production or anything.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Browser API: iframe.executeScript()

[Frederik Braun]

On 16.06.2015 21:41, Paul Rouget wrote:
> On Tue, Jun 16, 2015 at 9:33 PM, Bobby Holley  wrote:
>> On Tue, Jun 16, 2015 at 12:28 PM, Paul Rouget  wrote:
>>>
>>> The goal is to build a browser in HTML. Not to run a browser in
>>> current Firefox Desktop or in Chrome.
>>
>>
>> Ok. Are you also aiming to remove the dependency on XPCOM (i.e. Components)?
>> In that case it seems reasonable to swap out the System Principal for a
>> privilege called "UniversalXSS" - just make sure it's clear that that's what
>> it does. ;-)
> 
> I will add a special permission called "universalxss".
> I'll ask you, Paul and Jonas to look at the patch.

For the sake of completeness, what's the bug id?


> 
>> Also, the eval API should almost certainly be asynchronous, right?
> 
> Current patch is asynchronous.
> 

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

Re: AdBlock Plus as a ServiceWorker?

[Frederik Braun]

I thought that the APIs we brought into Firefox by implementing Tracking
Protection were supposed to provide a better  (canonical?) way to hook
your own blocker into Firefox.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: Metrics API for FxOS data collection

[Frederik Braun]

This is going to be a certified API, right?

On 01.05.2015 23:43, Tamara Hills wrote:
> Hi All,
> 
> Summary: We want to expose a Web API to Gaia to collect metrics for FxOS.
> This API would leverage the existing Gecko toolkit/components/telemetry
> capabilities to provide histograms to Telemetry Servers for analysis by
> data owners.
> 
> Bug: 1160634
> 
> Link to standard: No formal specifications that I was able to find on W3C
> for this topic and I am not aware of any conversations with any other
> browser vendors.
> 
> Platform coverage: This would only be available on Firefox OS.  The plan
> right now is to only have this available to certified apps.  This may
> change in the future, but we would come back to the list if that happens.
> 
> Estimated or target release: We are looking to have an initial set of
> metrics exposed to FxOS by June 2015.
> 
> Preference behind which this will be implemented: Planning to use
> dom.telemetry-api.enabled
> 
> DevTools bug: 1160645
> 
> Thank you,
> 
> Tamara Hills
> ___
> 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: New Developer Tools Feature: prettifying JSON

[Frederik Braun]

On 16.04.2015 11:04, Jan Odvarko wrote:
> On Thu, Apr 16, 2015 at 10:30 AM, Frederik Braun  <mailto:fbr...@mozilla.com>> wrote:
> 
> 
> Running our code in someone else's origin sounds undesired indeed. Not
> only because of CSP: What if someone puts this in a frame (or a popup)
> and interacts with this JSON viewer?
> 
> Why iteration with a frame with the viewer could be an issue?
>  

In a clickjacking-style attack, users could be tricked to dragging &
dropping JSON that contains login tokens or other sensitive data.

Alternatively, a cut-out & zoomed iframe that just shows the first few
characters (e.g. a csrf token) could be used as a "fake captcha".
Unknowing users would copy the sensitive data from victim.com in the
fake captcha form of evil.com (which frames the JSON viewer)

See here for a discussion of a similar attack (against view-source in an
iframe): https://bugzilla.mozilla.org/show_bug.cgi?id=624883

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

Re: New Developer Tools Feature: prettifying JSON

[Frederik Braun]

On 15.04.2015 18:54, Jan Odvarko wrote:
> …
> This approach has one security implication, if the page uses "default-src
> 'none'" (or other security restrictions?) - injecting JS into it generates
> warnings: "Content Security Policy: The page's settings blocked the loading
> of a resource at self ("default-src 'none'")."
> 
> Another option is introducing specific URL (like:
> chrome://browser/devtools/jsonviewer.xul) that implements the entire app
> and avoids JS injection in the existing content. But direct conversion of
> JSON documents is handy... and perhaps we have yet another option...?
> 
> What do you think?
> What approach is the best here? (and without any security concerns)


Running our code in someone else's origin sounds undesired indeed. Not
only because of CSP: What if someone puts this in a frame (or a popup)
and interacts with this JSON viewer? A custom URL sounds more reasonable
- but we have to make sure it doesn't have special powers, in case we
mess up and the JSON viewer can be XSSed.

Maybe we can build a JSON-specific handler in `view-source'? The
view-source scheme has all the security details in place!
You can't put 'view-source' in a frame, object or embed tag.
It's on a unique origin. It has no special privileges.

WDYT? Maybe view-source could show colored HTML for _this_ content type
and prettified JSON for _that_ content type. AFAIR we even had something
like this for XML in the tree - didnt we?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Frederik Braun]

On 13.04.2015 20:52, david.a.p.ll...@gmail.com wrote:
> 
>> 2) Protected by subresource integrity from a secure host
>>
>> This would allow website operators to securely serve static assets from 
>> non-HTTPS servers without MITM risk, and without breaking transparent 
>> caching proxies.
> 
> Is that a complicated word for SHA512 HASH? :)  You could envisage a new http 
> URL pattern http://video.vp9?

I suppose Subresource Integrity would be http://www.w3.org/TR/SRI/ -

But, note that this will not give you extra security UI (or less
warnings): Browsers will still disable scripts served over HTTP on an
HTTPS page - even if the integrity matches.

This is because HTTPS promises integrity, authenticity and
confidentiality. SRI only provides the former.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [meta] "Intent to implement" and Security & Privacy concerns

[Frederik Braun]

On 01.04.2015 08:28, Tantek Çelik wrote:
> One of the suggested additions to "intent to implement" emails:
> 
> https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Intent_to_Implement
> 
> is a statement regarding Security & Privacy concerns, because those
> have often been noted as brief summary statements in some past "intent
> to implement" emails.
> 
> There has been some discussion among various W3C/TAG etc. folks of
> adding a security self-review to W3C specifications, based on this
> strawman list of questions to answer (e.g. perhaps informatively in a
> section in a spec)
> 
> https://mikewest.github.io/spec-questionnaire/security-privacy/
> 
> Until specs start publishing their answers to these security/privacy
> questions, should we consider doing so at least as part of "Intent to
> implement"?
> 

Yes! I found it quite useful to work on these questions. And those specs
who don't answer them, might even take it as a pull request :)

> Thoughts?
> 
> Tantek
> ___
> 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: Permission UI

[Frederik Braun]

The good news is that most of the complicated bits are already
implemented. See about:permissions.

Though it operates on hostnames and not origins (bug 1066517).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Memory management in C programs

[Frederik Braun]

On 29.01.2015 21:32, ISHIKAWA, Chiaki wrote:
> On 2015/01/12 22:46, Philip Chee wrote:
>> ""
>> One large difference between C and most other programming languages is
>> that in C, you have to handle memory yourself rather than having a
>> garbage collector do it for you. Ensuring that memory is allocated at
>> the correct moment is not very difficult (and something that needs to be
>> done manually in pretty much every language); the hard part is to ensure
>> that enough memory is allocated, and to ensure that the memory is
>> deallocated when it is no longer in use.
>>
>> There are several techniques available for memory management in C. Many
>> of them are used in NetHack 3.4.3; and even more are used somewhere in
>> NetHack 4. In this blog post, I'd like to look at them and discuss their
>> advantages and disadvantages. I'm mostly concerned about correctness,
>> rather than efficiency, here; that means that unless the performance
>> difference is very large, I care more about clean code than I do about
>> fast code.
>> ""
>>
>> 
>>
>> Phil
>>
> 
> Nethack? That nethack?
> I looked at the web page.
> Yes, *that* nethack.
> 
> Do people still play it? It seems so
> and on a UTF-8 capable terminal (?)
> We have come a long way from vt100.

FWIW, Nethack4 is actually not the true nethack, which lives on
nethack.org and is still working fine (e.g. public telnet servers on
nethack.alt.org).

Shameless pitch: I am currently struggling (but making _some_ progress)
to port nethack to the web with emscripten :-)
https://github.com/freddyb/nethack-3.4.3-js

I'll now put on a dunce cap of +2 shame for allowing this thread to
diverge into off-topic and try not to comment any further :D
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [b2g] Script Security Talk @ MozLandia

[Frederik Braun]

About recording the talk:

We will get recording gear from Rainer Cvillink and I'm happy to help
capturing the talk, but I am *terribly* inexperienced in doing this.
So any kind of help is very much appreciated!


I'll be the tall person who shows up early (my picture on the phonebook
is quite accurate).


On 30.11.2014 23:13, Bobby Holley wrote:
> For those going to Portland, I'll be giving a talk about our JS security
> architecture on Thursday afternoon. It will build on the material from
> my talk in Brussels [1] last October. Watching that talk first is
> encouraged, but not required - I'll briefly review all the important
> concepts.
> 
> The talk will discuss the advancements in our security architecture over
> the past year, and provide an overview of how to reason about JS
> security. If you hack on privileged JS code (JS-implemented WebAPIs,
> Firefox front-end, addons, etc), you should consider attending.
> 
> I'm also looking for someone to capture the talk on video for those who
> can't make it. If you have a reliable recording device and would like to
> help with that, shoot me an email.
> 
> Time: Thursday, December 4, 2014, 2PM-4PM PST
> Location: Marriott Waterfront Ballroom F
> 
> [1] https://air.mozilla.org/enter-the-compartment/
> 
> 
> ___
> dev-b2g mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g
> 

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

Re: Per-origin versus per-domain restrictions (Re: Restricting gUM to authenticated origins only)

[Frederik Braun]

On 12.09.2014 12:22, Anne van Kesteren wrote:
> On Fri, Sep 12, 2014 at 11:56 AM, Frederik Braun  wrote:
>> Yes and no. I identified this while working on a thesis on the Same
>> Origin Policy in 2012 and filed this only for Geolocation in bug
>> <https://bugzilla.mozilla.org/show_bug.cgi?id=812147>.
>>
>> But the general solution might be a permission manager rewrite, I suppose?
> 
> That seems like a good idea. TLS permissions leaking to non-TLS seems
> really bad. Cross-port also does not seem ideal. I hope it's not as
> bad as cookies in that it also depends on Public Suffix?
> 
> If we rewrite I think it would be good to take top-level browsing
> context partitioning under consideration. That is, if I navigate to
> https://example/ and grant it the ability to do X. And then navigate
> to https://elsewhere.invalid/ which happens to embed https://example/,
> the embedded https://example/ does not have the ability to do X.
> 
> 

I filed bug <https://bugzilla.mozilla.org/show_bug.cgi?id=1066517> for this.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Per-origin versus per-domain restrictions (Re: Restricting gUM to authenticated origins only)

[Frederik Braun]

On 12.09.2014 11:51, Henri Sivonen wrote:
> On Fri, Sep 12, 2014 at 12:39 PM, Frederik Braun  wrote:
>> On 11.09.2014 19:04, Anne van Kesteren wrote:
>>> On Thu, Sep 11, 2014 at 6:58 PM, Martin Thomson  wrote:
>>>> On 2014-09-11, at 00:56, Anne van Kesteren  wrote:
>>>>> Are we actually partitioning permissions per top-level browsing
>>>>> context or could they already accomplish this through an ?
>>>>
>>>> As far as I understand it, permissions are based on domain name only, they 
>>>> don’t include scheme or port from the origin.  So it’s probably less 
>>>> granular than that.
>>>
>>> That seems somewhat bad.
>>>
>>
>> Yes.
>>
>> AFAIU (I might be terribly wrong), this is because all of those
>> permissions (gUM, Geolocation, Offilne Storage, Fullscreen) are using
>> the Permission manager we still have from the Popup Blocker/Cookie
>> Manager. This is domain based. Not origin :(
>> You can see this in about:permissions.
> 
> This is shocking. Making the fundamental design bug of cookies affect
> everything else is *really* bad. Is there a bug on file for fixing
> this?
> 

Yes and no. I identified this while working on a thesis on the Same
Origin Policy in 2012 and filed this only for Geolocation in bug
<https://bugzilla.mozilla.org/show_bug.cgi?id=812147>.

But the general solution might be a permission manager rewrite, I suppose?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Restricting gUM to authenticated origins only

[Frederik Braun]

On 11.09.2014 19:04, Anne van Kesteren wrote:
> On Thu, Sep 11, 2014 at 6:58 PM, Martin Thomson  wrote:
>> On 2014-09-11, at 00:56, Anne van Kesteren  wrote:
>>> Are we actually partitioning permissions per top-level browsing
>>> context or could they already accomplish this through an ?
>>
>> As far as I understand it, permissions are based on domain name only, they 
>> don’t include scheme or port from the origin.  So it’s probably less 
>> granular than that.
> 
> That seems somewhat bad.
> 

Yes.

AFAIU (I might be terribly wrong), this is because all of those
permissions (gUM, Geolocation, Offilne Storage, Fullscreen) are using
the Permission manager we still have from the Popup Blocker/Cookie
Manager. This is domain based. Not origin :(
You can see this in about:permissions.

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

Re: Evaluating adding JOSE and JWS to mozilla-central

[Frederik Braun]

Well there is  which does JWS.
It is available in privileged JS through jwcrypto.jsm (i.e.
resource://gre/modules/identity/jwcrypto.jsm).

There's some code usage for these things in the MobileIdentityManager,
Webapps and Payments jsms.


On 12.08.2014 19:22, Gregory Szorc wrote:
> The possibility of using JavaScript Object Signing and Encryption (JOSE)
> - specifically the verification part of the JSON Web Signature (JWS)
> component - came up as part of planning a JavaScript-based feature I'm
> working on.
> 
> We don't appear to have an implementation in mozilla-central yet. I'm
> trying to weigh whether to spend extra effort to add JWS support to the
> tree or to try to shoehorn existing signing solutions to fit my need.
> 
> First, does anyone know of an existing browser-side implementation of
> JWS used by Mozilla? I know we have Python in Marketplace doing signing.
> We /may/ have parts of Firefox OS doing client-side signing
> verification. My requirement is for chrome-privileged JS to do X509
> signing verification. I'll settle for an XPIDL interface to NSS.
> 
> Second, would having JWS support in m-c be beneficial to anyone else?
> 
> If this isn't easy to add, I'll probably be lazy and leverage an
> existing solution. Convince me it is worth doing.
> 
> Gregory
> ___
> 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: Unimplement: @-moz-document regexp support?

[Frederik Braun]

On 09.07.2014 01:41, Ehsan Akhgari wrote:
> On 2014-07-08, 6:34 PM, L. David Baron wrote:
>> On Monday 2014-07-07 15:18 -0400, Ehsan Akhgari wrote:
>>> That seems pretty bad.  I think we should at least stop supporting
>>> it for Web content.  David, what do you think?
>>
>> I'm ok with restricting it to UA and user style sheets, although if
>> we're going to do that because of security risks I'd like to get a
>> good understanding of what those are and of what we do and don't
>> expect authors to do when sanitizing CSS from untrusted sources to
>> include in their Web content.
>>
>> I think it might make more sense to continue discussion in the bug.
> 
> Sounds great!

Agreed!

> 
>> (I also think sending this out in the format of an
>> intent-to-implement message was confusing for an initial proposal to
>> do something that hadn't yet been discussed with any owners or peers
>> of the module.  I think the format is intended to say that a change
>> has already been accepted by owners/peers but requires wider
>> review.)
> 
> Yes indeed.  Admittedly I was a bit confused.

I'm sorry, I thought the emails about this were to start the general
discussion. I really did not intend to imply peer acceptance - in fact I
meant to ask for it.

> 
 Summary:

 Attackers can extract secret URL components (e.g. session IDs, oauth
 tokens) using @-moz-document. Using the regexp support and assuming a
 CSS injection (no XSS needed!), the attacker can probe the current URL
 with some regular expressions and send the URL parameters to a third
 party.

 A demo of this exploit can be found at
 .
 This attack has also been published in the academic paper "Scriptless
 Attacks: Stealing the pie without touching the sill"[1] by Mario
 Heiderich et al. and numerous other presentations on this topic [2,3].

 My suggestion is to either kill -moz-document for public web content or
 remove regexp support.


 What do you think?


 Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1035091
 Spec: n/a. This was pushed out of CSS3 and did not make it to CSS4
 selectors.
 MDN: https://developer.mozilla.org/en-US/docs/Web/CSS/@document
 Target release: ??
 Platform coverage: desktop, android




 [1] http://www.nds.rub.de/research/publications/scriptless-attacks/
 [2] http://www.slideshare.net/x00mario/stealing-the-pie
 [3] https://speakerdeck.com/mikewest/xss-no-the-other-s-cssconf-eu-2013
 ___
 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

Unimplement: @-moz-document regexp support?

[Frederik Braun]

Summary:

Attackers can extract secret URL components (e.g. session IDs, oauth
tokens) using @-moz-document. Using the regexp support and assuming a
CSS injection (no XSS needed!), the attacker can probe the current URL
with some regular expressions and send the URL parameters to a third party.

A demo of this exploit can be found at .
This attack has also been published in the academic paper "Scriptless
Attacks: Stealing the pie without touching the sill"[1] by Mario
Heiderich et al. and numerous other presentations on this topic [2,3].

My suggestion is to either kill -moz-document for public web content or
remove regexp support.


What do you think?


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1035091
Spec: n/a. This was pushed out of CSS3 and did not make it to CSS4
selectors.
MDN: https://developer.mozilla.org/en-US/docs/Web/CSS/@document
Target release: ??
Platform coverage: desktop, android




[1] http://www.nds.rub.de/research/publications/scriptless-attacks/
[2] http://www.slideshare.net/x00mario/stealing-the-pie
[3] https://speakerdeck.com/mikewest/xss-no-the-other-s-cssconf-eu-2013
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Are you interested in doing dynamic analysis of JS code?

[Frederik Braun]

Thanks for bringing this to dev-platform.

Dynamic analysis is something the security teams are particularly
interested in. Especially tainting user input is something we could make
use of across the project: Existing security efforts for Firefox OS,
Firefox Desktop, Firefox Mobile and our websites would all greatly
benefit from it, as it could help preventing Cross-Site Scripting and
other content injection attacks.

Some people may know the work Stefano Di Paola has done to develop his
DOM-XSS scanner "DOMinator". There's also been an attempt to develop it
in-tree within the security mentorship program, but the outcome wasn't
fit to be merged into moz-central (bug 811877).

A mozilla-owned API would help make all future endeavors last. I have
also been in contact with folks in academia and the industry who are
interested in both implementation and consumption of the API.

I will make sure their attention is directed to this threat to provide
additional feedback.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Overriding the CSP for privileged protocols

[Frederik Braun]

There's this bug filed about user overrides for CSPs:
https://bugzilla.mozilla.org/show_bug.cgi?id=1014545
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Link coloring in private browsing (Was: Intent to ship: Hyperlink Auditing ())

[Frederik Braun]

On 20.05.2014 23:33, Ehsan Akhgari wrote:
> On 2014-05-20, 2:25 PM, Jonas Sicking wrote:
>> On Fri, May 16, 2014 at 7:45 AM, Justin Dolske 
>> wrote:

>> However we do implement some additional features in private browsing
>> mode. For example we disable link coloring. I'm not sure what the
>> exact goal of that is. I always guessed that it is to enable you to be
>> extra private about your identity while in private browsing. So that
>> might provide an argument for disabling  in private browsing.
> 
> The goal of disabling link coloring was IIRC to disable websites from
> being able to run attacks against your browsing history to be able to
> correlate your browsing sessions like I said above.  A smaller reason
> was that because we don't store history items from private navigations,
> the link coloring might "not work" in surprising ways to the user.  This
> was before dbaron's general fix for that issue, I don't actually think
> we need to keep doing that any more, but nobody has complained about
> that yet.  :-)

FWIW I'd like to keep colored links out of private browsing, which is a
"guest mode" benefit: Somebody else using a private browsing window on
your computer can't immediately see which websites you visit.

(I know private browsing isn't intended to be a guest mode)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Enhancing product security with CSP for internal pages

[Frederik Braun]

On 15.04.2014 22:45, Neil wrote:
> Frederik Braun wrote:
> 
>> On 15.04.2014 00:43, Neil wrote:
>>  
>>
>>> Frederik Braun wrote:
>>>
>>>> A few months ago I had the idea to add a Content Security Policy
>>>> (CSP) to our internal pages, like about:newtab for example.
>>>>
>>> So this just applies to about: pages?
>>>
>> Primarily yes. I think some people are already working on other bits
>> and pieces. Of course this also only makes sense for privileged about:
>> pages. This would mean about:home can stay as is.
>>  
>>
> So about:certError and about:blocked stay as is too?
> 

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

Re: Enhancing product security with CSP for internal pages

[Frederik Braun]

On 15.04.2014 00:43, Neil wrote:
> Frederik Braun wrote:
> 
>> A few months ago I had the idea to add a Content Security Policy (CSP)
>> to our internal pages, like about:newtab for example.
>>
> So this just applies to about: pages?
> 

Primarily yes. I think some people are already working on other bits and
pieces. Of course this also only makes sense for privileged about:
pages. This would mean about:home can stay as is.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Enhancing product security with CSP for internal pages

[Frederik Braun]

Hi folks,

For those who don't know me, I'm a Security Engineer working on Firefox
OS (mostly Gaia and Gecko things). I have been pursuing a security goal
for quite some time now but haven't yet announced this to throughout the
project.

A few months ago I had the idea to add a Content Security Policy (CSP)
to our internal pages, like about:newtab for example.
This is a "defense in depth" mechanism which can prevent Cross-Site
Scripting (XSS) flaws in chrome context (i.e., in privileged pages)
being exploited. These simple XSS oversights in privileged pages would
mean complete code execution on the system of the victim!
The benefit is therefore quite clear and there have been multiple issues
with script and other injections in the past.


To move on, all affected pages have to be modified so that stylesheets
and JavaScript live in different documents. This means moving inline
styles style tags and attributes, script tags and event attributes
(e.g., onclick, onload) into separate documents.

The good thing is that most of these changes are just tiny patches which
can be handed out to volunteers and new contributors: We have already
made some progress and rewrote some of those files (thanks to so many
volunteers). I filed "good first bugs" (linked to the tracking bug
923920) and the current progress is well documented on the wiki (link
below).

What I am asking of you is quite simple:
* If you have some spare time, file additional bugs and link them to the
tracking bug 923920
* If you are a module peer, consider to require that updated and new
internal pages contain no inline script. Our progress has been
diminished by pages being patched towards CSP incompatibility again.


Thanks!
Frederik


Further reading:
* XSS: https://en.wikipedia.org/wiki/Cross-site_scripting
* CSP: https://en.wikipedia.org/wiki/Content_Security_Policy
* Vulnerabilities: MFSA 2012-78, MFSA 2013-52, MFSA 2012-95
* This project on the Wiki:
https://wiki.mozilla.org/Security/Inline_Scripts_and_Styles
* Tracking bug for rewriting HTML/JS:
https://bugzilla.mozilla.org/show_bug.cgi?id=923920
* Tracking bug for Gecko changes:
https://bugzilla.mozilla.org/show_bug.cgi?id=923902
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform