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

firefox-dev posting [was Re: unowned module: Firefox::New Tab Page, help me find an owner]

[Karl Tomlinson]

Justin and I did some investigation and weren't able to reproduce
the problems people were encountering last year.

We confirmed that it is not necessary to subscribe before posting.

If the sender is not whitelisted, then messages receive an
immediate reply with the subject "Your message to firefox-dev
awaits moderator approval".  Messages caught by the spam filter do
not receive this reply.

If a message does not get posted on the list and there is no
moderation auto-reply, then it has gone missing, perhaps
filtered with the spam.  firefox-dev-owner is the official contact
if there is a problem.

On Thu, 23 Mar 2017 00:55:19 -0700, Justin Dolske wrote:

> Can you follow up with me in separate email about what posts you're
> concerned about?
>
> I've done most of the rejection moderation on the list, and usually reply
> to people explaining why and where a better venue would be. Most stuff that
> has been moderated is exactly what's listed there as being off-topic, and
> that's fairly uncommon. Obvious spam gets silently plonked, but that's
> presumably not what you're talking about.
>
> This thread, had it been posted to firefox-dev, would very clearly be
> on-topic and not rejected.
>
> Justin
>
> On Wed, Mar 22, 2017 at 7:35 PM, Karl Tomlinson  wrote:
>
>> Benjamin Smedberg writes:
>>
>> > This is not the list for this question. Please respect this question to the
>> > firefox-dev list.
>>
>> https://wiki.mozilla.org/Firefox/firefox-dev says "Anyone can post. By
>> default, posts will be reviewed by a moderator before being sent to the
>> list."
>> bit in fact some unclear set of posts are redirected to /dev/null, even
>> when
>> contributing to the goal and abiding by the rules.
>> ___
>> 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: Proper way to return nsresult from Rust before Stylo is mandatory?

[Ehsan Akhgari]

On 2017-03-27 5:10 PM, Michael Layzell wrote:
> I don't think it would be too hard. At one point I had a WIP patch which
> implemented it, but I would have to dig it up again.
> 
> I'll see if I can get a patch up for the crate in my spare time.

Thank you!

> On Sun, Mar 26, 2017 at 11:26 PM, Ehsan Akhgari  > wrote:
> 
> On 2017-03-17 10:08 AM, Michael Layzell wrote:
> > I don't think we have any particularity good tools for this right now. A
> > while ago I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1320179
>  to
> > add a separate crate like the nsstring crate which provides the nsresult
> > bindings. If we are starting to get more use cases for it we probably 
> want
> > to implement something like it which moves the error code definition 
> code
> > into python or similar, and then generates both rust and C++ bindings in
> > the outdir.
> 
> I think the right way to do it is to have an nsresult crate as you
> suggest.  How much work would that be?
> 
> As far as code parsing goes, we already have nsError.h, so why can't we
> just use rustbindgen?  But I guess moving the definitions elsewhere and
> generating the headers out of them is easy as well.  The build system's
> support for generated files is pretty good as far as I know.  Whichever
> way is easier is better, I guess!
> 
> 

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

Re: Proper way to return nsresult from Rust before Stylo is mandatory?

[Michael Layzell]

I don't think it would be too hard. At one point I had a WIP patch which
implemented it, but I would have to dig it up again.

I'll see if I can get a patch up for the crate in my spare time.

On Sun, Mar 26, 2017 at 11:26 PM, Ehsan Akhgari 
wrote:

> On 2017-03-17 10:08 AM, Michael Layzell wrote:
> > I don't think we have any particularity good tools for this right now. A
> > while ago I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1320179
> to
> > add a separate crate like the nsstring crate which provides the nsresult
> > bindings. If we are starting to get more use cases for it we probably
> want
> > to implement something like it which moves the error code definition code
> > into python or similar, and then generates both rust and C++ bindings in
> > the outdir.
>
> I think the right way to do it is to have an nsresult crate as you
> suggest.  How much work would that be?
>
> As far as code parsing goes, we already have nsError.h, so why can't we
> just use rustbindgen?  But I guess moving the definitions elsewhere and
> generating the headers out of them is easy as well.  The build system's
> support for generated files is pretty good as far as I know.  Whichever
> way is easier is better, I guess!
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Switching to async/await from Task.jsm/yield

[Kris Maglione]

On Mon, Mar 27, 2017 at 12:42:46PM -0700, Dave Townsend wrote:
It looks like the main concern raised about switching over to async/await 
where possible is bug 1242505.


I personally wouldn't consider this a blocker. I'm all for it 
being fixed, but the benefit of not having Promise.jsm noise in 
my tests outweighs it. And there are places where we can't 
actually use Promise.jsm (content scopes, extension copes), so 
we wind up with a mix of the two models if we try to stick with 
Promise.jsm in some places and not in others.


We're going to try to get some resources for fixing that bug and it probably 
blocks doing a mass rewrite of existing code but I don't think it blocks 
people starting to use async/await right now as we're already using native 
Promises in lots of places.


I think that, if anything, it should probably the other way around. Existing 
tests that use Promise.jsm probably don't have many unhandled exceptions, but 
new tests are more likely to wind up with them. If we start using native 
promises in more new places and then add unhandled rejection tracking to 
tests, we're probably going to have to do a lot more work fixing existing 
issues to get it turned on than if we gradually migrated to native promises 
after it was fixed.


But I'd still rather we use native promises and async functions in new tests, 
so I'm all for mass converting old code as well, and making sure we invest 
time in fixing that bug as soon as possible.

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

Re: Switching to async/await from Task.jsm/yield

[Dave Townsend]

It looks like the main concern raised about switching over to async/await
where possible is bug 1242505. We're going to try to get some resources for
fixing that bug and it probably blocks doing a mass rewrite of existing
code but I don't think it blocks people starting to use async/await right
now as we're already using native Promises in lots of places. So lets go
ahead with this and avoid using Task.jsm in the future.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proper way to return nsresult from Rust before Stylo is mandatory?

[Ralph Giles]

On Fri, Mar 17, 2017 at 4:27 AM, Emilio Cobos Álvarez  wrote:

> Fedora didn't have libclang 3.9 packages IIRC, but that could've
> changed.

clang 3.9.1 in now in the fedora 25 updates repo.
https://koji.fedoraproject.org/koji/packageinfo?packageID=21848

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

Re: Async Iteration is available on non-release-only, for testing purpose

[Ryan VanderMeulen]

Let's make sure to add a test that's expected to fail as well for this 
so we can verify that we don't accidentally ship this enabled in chrome. 
Not that we've had any recent instances of thinking we'd disabled a 
feature only for it to get unknowingly shipped :)


-Ryan

On 3/27/2017 12:31 PM, Shu-yu Guo wrote:

I agree that disabling for chrome is the right thing here over prefs. I
want Nightly and DevEdition to have stage 3+ TC39 proposals unflagged and
ready to play with -- asking folks to turn on prefs to do that is not the
way to go here from my perspective.

Benjamin's concern is legit, though, so let's disable it in chrome.

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

Re: Async Iteration is available on non-release-only, for testing purpose

[Shu-yu Guo]

I agree that disabling for chrome is the right thing here over prefs. I
want Nightly and DevEdition to have stage 3+ TC39 proposals unflagged and
ready to play with -- asking folks to turn on prefs to do that is not the
way to go here from my perspective.

Benjamin's concern is legit, though, so let's disable it in chrome.

On Mon, Mar 27, 2017 at 9:12 AM, Till Schneidereit <
t...@tillschneidereit.net> wrote:

> I think disabling in chrome code is a good idea. We have done these kinds
> of non-release-only features in the JS engine in the past, and it hasn't
> always gone well precisely for the reasons that have you concerned. OTOH,
> adding a pref is annoyingly complicated for JS engine features (we should
> probably work on that!) and makes the feature much harder to test for web
> developers. Perhaps for now disabling for chrome is really the right
> trade-off?
>
> On Mon, Mar 27, 2017 at 7:56 AM, Benjamin Smedberg 
> wrote:
>
> > I am concerned about the accidental consequences of turning this on for
> > nightly/aurora. What if we start writing browser code that relies on
> these
> > features which unexpectedly starts failing in beta?
> >
> > I presume the value of enabling this in nightly/aurora is that we can get
> > web developers to experiment and report bugs?  Is that something we can
> do
> > asking them to explicitly turn this on via pref? Or are you worried about
> > this feature accidentally breaking existing web content and you want to
> get
> > bug reports from normal users?
> >
> > Could we mitigate risk by disabling this feature in chrome code by
> default
> > until you're confident in its readiness to ship?
> >
> > --BDS
> >
> >
> > On Mon, Mar 27, 2017 at 10:33 AM, Tooru Fujisawa 
> > wrote:
> >
> > > I just landed the initial implementation of Async Iteration proposal
> > > (async generator and for-await-of syntax), as non-release-only feature.
> > >
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1331092
> > >
> > > The implementation is only for the testing purpose (for finding spec
> bug
> > > etc), and the semantic change in the spec is highly expected.  They're
> > not
> > > yet ready for production usage, either in browser code or in testcases.
> > > Please wait for a while :)
> > >
> > > --
> > >
> > > arai
> > >
> > > ___
> > > 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
>



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

Re: Async Iteration is available on non-release-only, for testing purpose

[Shu-yu Guo]

Cross-posting to firefox-dev.

TL;DR:

arai has done truly excellent feature work implementing the ECMAScript
Async Iteration proposal. It is gated to Nightly/DevEd only for content
code. We will also be turning off the feature in chrome code to prevent
accidental dependence. Both these restrictions will be lifted when the
proposal fully matures to be in the next standard.

*PLEASE DO NOT USE ASYNC GENERATORS IN CHROME CODE.*

On Mon, Mar 27, 2017 at 9:31 AM, Shu-yu Guo  wrote:

> I agree that disabling for chrome is the right thing here over prefs. I
> want Nightly and DevEdition to have stage 3+ TC39 proposals unflagged and
> ready to play with -- asking folks to turn on prefs to do that is not the
> way to go here from my perspective.
>
> Benjamin's concern is legit, though, so let's disable it in chrome.
>
> On Mon, Mar 27, 2017 at 9:12 AM, Till Schneidereit <
> t...@tillschneidereit.net> wrote:
>
>> I think disabling in chrome code is a good idea. We have done these kinds
>> of non-release-only features in the JS engine in the past, and it hasn't
>> always gone well precisely for the reasons that have you concerned. OTOH,
>> adding a pref is annoyingly complicated for JS engine features (we should
>> probably work on that!) and makes the feature much harder to test for web
>> developers. Perhaps for now disabling for chrome is really the right
>> trade-off?
>>
>> On Mon, Mar 27, 2017 at 7:56 AM, Benjamin Smedberg > >
>> wrote:
>>
>> > I am concerned about the accidental consequences of turning this on for
>> > nightly/aurora. What if we start writing browser code that relies on
>> these
>> > features which unexpectedly starts failing in beta?
>> >
>> > I presume the value of enabling this in nightly/aurora is that we can
>> get
>> > web developers to experiment and report bugs?  Is that something we can
>> do
>> > asking them to explicitly turn this on via pref? Or are you worried
>> about
>> > this feature accidentally breaking existing web content and you want to
>> get
>> > bug reports from normal users?
>> >
>> > Could we mitigate risk by disabling this feature in chrome code by
>> default
>> > until you're confident in its readiness to ship?
>> >
>> > --BDS
>> >
>> >
>> > On Mon, Mar 27, 2017 at 10:33 AM, Tooru Fujisawa 
>> > wrote:
>> >
>> > > I just landed the initial implementation of Async Iteration proposal
>> > > (async generator and for-await-of syntax), as non-release-only
>> feature.
>> > >
>> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1331092
>> > >
>> > > The implementation is only for the testing purpose (for finding spec
>> bug
>> > > etc), and the semantic change in the spec is highly expected.  They're
>> > not
>> > > yet ready for production usage, either in browser code or in
>> testcases.
>> > > Please wait for a while :)
>> > >
>> > > --
>> > >
>> > > arai
>> > >
>> > > ___
>> > > 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
>>
>
>
>
> --
>shu
>



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

Re: Async Iteration is available on non-release-only, for testing purpose

[Till Schneidereit]

I think disabling in chrome code is a good idea. We have done these kinds
of non-release-only features in the JS engine in the past, and it hasn't
always gone well precisely for the reasons that have you concerned. OTOH,
adding a pref is annoyingly complicated for JS engine features (we should
probably work on that!) and makes the feature much harder to test for web
developers. Perhaps for now disabling for chrome is really the right
trade-off?

On Mon, Mar 27, 2017 at 7:56 AM, Benjamin Smedberg 
wrote:

> I am concerned about the accidental consequences of turning this on for
> nightly/aurora. What if we start writing browser code that relies on these
> features which unexpectedly starts failing in beta?
>
> I presume the value of enabling this in nightly/aurora is that we can get
> web developers to experiment and report bugs?  Is that something we can do
> asking them to explicitly turn this on via pref? Or are you worried about
> this feature accidentally breaking existing web content and you want to get
> bug reports from normal users?
>
> Could we mitigate risk by disabling this feature in chrome code by default
> until you're confident in its readiness to ship?
>
> --BDS
>
>
> On Mon, Mar 27, 2017 at 10:33 AM, Tooru Fujisawa 
> wrote:
>
> > I just landed the initial implementation of Async Iteration proposal
> > (async generator and for-await-of syntax), as non-release-only feature.
> >
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1331092
> >
> > The implementation is only for the testing purpose (for finding spec bug
> > etc), and the semantic change in the spec is highly expected.  They're
> not
> > yet ready for production usage, either in browser code or in testcases.
> > Please wait for a while :)
> >
> > --
> >
> > arai
> >
> > ___
> > 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: Upcoming C++ standards meeting in Kona, Hawaii

[Botond Ballo]

If you're interested in what happened at this meeting, my blog post has details:

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

Cheers,
Botond

On Fri, Feb 24, 2017 at 1:53 PM, Botond Ballo  wrote:
> Hi everyone!
>
> The next meeting of the C++ Standards Committee will be February 27 -
> March 4 in Kona, Hawaii.
>
> I've blogged in detail about the last meeting here [1]. The focus of
> that meeting was polishing the C++17 feature set by addressing
> comments from national standards bodies on the initial draft of the
> C++17 standard that was circulated last summer.
>
> This meeting will continue that work, while also moving forward the
> in-progress Technical Specifications (notable among them, Ranges,
> Networking, Coroutines, and - my favourite - Modules), and then
> looking more strategically towards C++20. (Notably, the pre-meeting
> mailing contains a paper called "To boldly suggest an overall plan to
> C++20" [2].)
>
> For a full list of new papers submitted to the committee since the
> last meeting, see [3] and [4].
>
> I will be attending this meeting, hanging out in the Evolution Working
> Group (where new language features are discussed at the design level)
> as usual. As always, if there's anything you'd like me to find out for
> you at the meeting, or any feedback you'd like me to communicate,
> please let me know!
>
> Finally, I encourage you to reach out to me if you're thinking of
> submitting a proposal to the committee. I'm always happy to help with
> formulating and, if necessary, presenting a proposal.
>
> Cheers,
> Botond
>
> [1] 
> https://botondballo.wordpress.com/2016/11/25/trip-report-c-standards-meeting-in-issaquah-november-2016/
> [2] http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0592r0.html
> [3] http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/#mailing2016-11
> [4] http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/#mailing2017-02
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Async Iteration is available on non-release-only, for testing purpose

[zbraniecki]

That's super exciting!

The new localization resources registry module is being written with async 
generators in mind. I have the patch ready in the bug, which can be flipped to 
go async with 8 lines of code.

I know we're not planning to make it ride trains just yet, but if you need a 
real-world use case to profile the perf or memory, I think I have a candidate 
for you :)

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

Re: Async Iteration is available on non-release-only, for testing purpose

[Benjamin Smedberg]

I am concerned about the accidental consequences of turning this on for
nightly/aurora. What if we start writing browser code that relies on these
features which unexpectedly starts failing in beta?

I presume the value of enabling this in nightly/aurora is that we can get
web developers to experiment and report bugs?  Is that something we can do
asking them to explicitly turn this on via pref? Or are you worried about
this feature accidentally breaking existing web content and you want to get
bug reports from normal users?

Could we mitigate risk by disabling this feature in chrome code by default
until you're confident in its readiness to ship?

--BDS


On Mon, Mar 27, 2017 at 10:33 AM, Tooru Fujisawa 
wrote:

> I just landed the initial implementation of Async Iteration proposal
> (async generator and for-await-of syntax), as non-release-only feature.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1331092
>
> The implementation is only for the testing purpose (for finding spec bug
> etc), and the semantic change in the spec is highly expected.  They're not
> yet ready for production usage, either in browser code or in testcases.
> Please wait for a while :)
>
> --
>
> arai
>
> ___
> 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

Async Iteration is available on non-release-only, for testing purpose

[Tooru Fujisawa]

I just landed the initial implementation of Async Iteration proposal (async 
generator and for-await-of syntax), as non-release-only feature.

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

The implementation is only for the testing purpose (for finding spec bug etc), 
and the semantic change in the spec is highly expected.  They're not yet ready 
for production usage, either in browser code or in testcases.  Please wait for 
a while :)

--

arai

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

Re: Better download security through browsers

[Daniel Veditz]

On Mon, Mar 27, 2017 at 1:22 AM, Frederik Braun  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".

-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: Future of out-of-tree spell checkers?

[Henri Sivonen]

On Fri, Mar 24, 2017 at 3:20 PM, Ehsan Akhgari  wrote:
> On 2017-03-24 4:20 AM, Henri Sivonen wrote:
>> On Fri, Mar 24, 2017 at 2:38 AM, Ehsan Akhgari  
>> wrote:
>>> On Wed, Mar 22, 2017 at 11:50 AM, Jeff Muizelaar 
>>> wrote:

 On Wed, Mar 22, 2017 at 11:08 AM, Henri Sivonen 
 wrote:
>
> dlopening libvoikko, if installed, and having thin C++ glue code
> in-tree seems much simpler, except maybe for sandboxing. What are the
> sandboxing implications of dlopening a shared library that will want
> to load its data files?

 My understanding is that the spell checker mostly lives in the Chrome
 process so it seems sandboxing won't be a problem.
>>>
>>>
>>> That is mostly correct.  The spell checker *completely* lives in the parent
>>> process and is completely unaffected by sandboxing.
>>>
>>> But that's actually a problem.  My understanding is that WebExtensions won't
>>> be allowed to load code in the parent process.  Bill, Kris, is that correct?
>>> If yes, we should work with the maintainers of the Finnish and Greenlandic
>>> dictionaries on adding custom support for loading their code...
>>
>> But when (according to doing a Google Web search excluding mozilla.org
>> and wading through all the results and by searching the JS for all
>> AMO-hosted extensions) the only out-of-tree spell checkers use
>> libvoikko, why involve Web Extensions at all? Why wouldn't we dlopen
>> libvoikko and put a thin C++ adapter between libvoikko's C API and our
>> internal C++ interface in-tree? That would be significantly simpler
>> than involving Web extensions.
>
> Is that different than what I suggested above in some way that I'm
> missing?

I thought you meant that Web Extensions were your primary choice if
they could load code into the parent process.

> I think it's better to engage the developers of those
> libraries first and ask them how they would like us to proceed.

I wanted to get an understanding of what we'd be OK with before
contacting Harri Pitkänen (libvoikko developer) or Timo Jyrinki
(libvoikko and mozvoikko maintainer for Debian and Ubuntu), because I
don't want to cause them to write code only to find a Mozilla decision
render the code useless.

On Fri, Mar 24, 2017 at 8:45 PM, Bill McCloskey  wrote:
> If we do end up going with the dlopen plan, let's make sure that we enforce
> some kind of code signing. We're finally almost rid of all the untrusted
> binary code that we used to load (NPAPI, binary XPCOM, ctypes). It would be
> a shame to open up a new path.

What threat do you intend to defend against?

On Linux, we should think of libvoikko as an optional system library.
(If you install Ubuntu choosing English as the system language at
install time, libvoikko is not installed by default. If you install
Ubuntu choosing Finnish as the system language at install time,
libvoikko is installed by default. In any case, you can get it from
the distro repo.) We already dlopen() PulseAudio as a system library
that we don't verify. In the Crash Reporter, we dlopen() libcurl and
some Gnome stuff. I expect that someone operating with the user's
privileges can cause whatever unverified code to be mapped into our
address space via LD_PRELOAD and system libraries that we link against
unconditionally.

As for Windows, since a spell checker doesn't add Web-exposed
functionality, we wouldn't have the risk that we had with NPAPI (or,
technically, with arbitrary add-ons) that a site could entice users to
run a random setup.exe in order to see some additional Web content.
The libvoikko API is pretty narrow, so I wouldn't expect it to enable
more anti-virus mischief than what can be done by hooking stuff into
the Windows system DLLs that we need to use.

The main problems I see are:
 1) Right now the libvoikko distribution point is without https.
(Fixable with Let's Encrypt.)
 2) We couldn't trigger a libvoikko autoupdate on Windows/Mac if there
was a crasher bug in the library. (I'd expect the distros to take care
of pushing an update in the Linux case. It's the same situation with
e.g. PulseAudio and Gtk anyway.)

On Sat, Mar 25, 2017 at 8:48 PM, Ehsan Akhgari  wrote:
> Another option would be talking to the maintainers of libvoikko and
> seeing if they would be open to maintaining the Mozilla bindings, in
> which case I think we should even consider doing something like what we
> do to download the OpenH264 binary at runtime when we need to.  We could
> even build and sign it in the infrastructure ourselves if we imported it
> into the tree, with task cluster this is possible today with a super
> simple shell script (well, at least the building side of it!).

If we are willing to do the engineering for that, that would be great!
(Of course, just putting libvoikko into libxul would be simpler, but
would cost an added 250 KB in libxul size for everyone who doesn't
need libvoikko.)

The situation with the Tracking Protection data suggests that we are
OK with GPLed run-time downloa