Re: Proposed W3C Charter: Second Screen Working Group

[L. David Baron]

So I think Martin, Peter, and I share similar concerns here, and I'm
inclined to turn those concerns into an objection to this charter.

So how does this sound for proposed comments on the charter
(submitted as a formal objection)?  Note that I've tried to turn the
comments into a specific suggestion for a remedy, but I'm far from
sure if that suggestion is the right one.

I've avoided mentioning the comment about "further changes" in the
specs that the existing working group has in CR, to avoid
distracting from what I think is the main piece.  But let me know if
you see a good way to work it in.

But I'd be particularly interested to hear if SC thinks this might
be harmful rather than helpful to the end goal for some reason, or
if he has other disagreements with this approach, or better
suggestions for what remedy we should suggest.

-David

=

The current situation with the API developed by this Working Group
is that it is a API for a web page to interact with a connection
between the web browser and a separate screen that exists entirely
in a closed ecosystem.  For example, a browser made by Google might
connect to displays that support the proprietary Chromecast
protocol, whereas one made by apple might connect to displays that
support the proprietary AirPlay protocol.

We know that parts of an Open Screen Protocol are in an early stage
of development at https://github.com/webscreens/openscreenprotocol
(as linked from the charter), and the goal of this work is to
improve on this situation.  We hope it will allow for interoperable
discovery of, identification of, and communication with presentation
displays.  However, we're deeply concerned about chartering a second
iteration of the work that continues building the Presentation API
on top of a closed ecosystem, when the work to make the ecosystem
more open has a lower priority.  While we understand that the work
on building an open ecosystem still requires incubation, we believe
it should have the highest priority in this space.  We believe that
rechartering the Second Screen WG should wait until that work is
ready to be in a working group, and that advancing the current
specifications (developed under the existing charter) to Proposed
Recommendation probably depends on this new work in order to
demonstrate real interoperability, although we are open to other
paths toward fixing this situation.


On Thursday 2018-01-04 09:29 -0700, Peter Saint-Andre wrote:
> +1 to Martin's feedback.
> 
> On 1/3/18 10:19 PM, Martin Thomson wrote:
> > Without the protocol pieces, this remains vendor-specific.  We should
> > comment on this and make it clear that we think that definition of a
> > generic protocol for interacting with the second display has not been
> > given sufficient priority.  Allowing this to proceed without a generic
> > protocol would be bad for the ecosystem.
> > 
> > From what I can see, there seem to be a bunch of options that are
> > described for the protocol, without extremely scant detail.  Certainly
> > not enough to implement anything.
> > 
> > I'm concerned with the statement "This Working Group does not
> > anticipate further changes to this specification" regarding the
> > presentation API.  I haven't reviewed this thoroughly, but there
> > appear to be some gaps in rather fundamental pieces.  For instance -
> > and maybe this doesn't change the API at all - but the means of
> > identification for screens is unclear.  Some of these details are
> > important, such as whether knowledge of a presentation URL is all the
> > information necessary to use that URL (i.e., are they capability
> > URLs?).
> > 
> > On Thu, Jan 4, 2018 at 2:31 PM, Shih-Chiang Chien  
> > wrote:
> >> The SecondScreen WG intended to move the protocol development to CG, and
> >> will possibly move to IETF after the incubation phase.
> >> The revised charter is trying to associate the work of CG to the timeline
> >> of Presentation API development.
> >>
> >> At the meantime, WG will tackle the testability issue found while creating
> >> test cases and cultivating Level 2 API requirements for advanced use cases.
> >>
> >> I'll vote to support this revised charter.
> >>
> >> Best Regards,
> >> Shih-Chiang Chien
> >> Mozilla Taiwan
> >>
> >> On Thu, Jan 4, 2018 at 10:08 AM, L. David Baron  wrote:
> >>
> >>> The W3C is proposing a revised charter for:
> >>>
> >>>   Second Screen Working Group
> >>>   https://w3c.github.io/secondscreen-charter/
> >>>   https://lists.w3.org/Archives/Public/public-new-work/2017Dec/.html
> >>>
> >>> Mozilla has the opportunity to send comments or objections through
> >>> Friday, January 52.  (Sorry for failing to send this out sooner!)
> >>>
> >>> A diff relative to the current charter is:
> >>> https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2014%
> >>> 2Fsecondscreen%2Fcharter-2016.html=https%3A%2F%2Fw3c.
> >>> github.io%2Fsecondscreen-charter%2F
> >>>
> >>> The participants in 

Re: Hiding 'new' statements - Good or Evil?

[Jeff Gilbert]

I would say it comes down to the module. I'm very comfortable in my
modules using auto, perhaps because our lifetime management is more
clear. To me, the unsafe examples are pretty strawman-y, since it's
very clear that there are at-risk lifetimes involved. (Returning a
bare pointer and relying on it staying valid is bad; const auto& takes
a reference, not a strong reference. If you want a new strong
reference, you obviously can't just use a reference)

`auto` was formalized in c++11, and it is now 2018. C++11 has been
required to compile Firefox since Firefox 25 in mid 2013. The rules
for auto are pretty easy to understand, too. (strips the c/v/r
decorations from the returning type, so that `const int& bar(); auto
foo = bar();` gives `foo` type `int`) In my mind, pushing back on auto
here is effectively a statement that we never expect our reviewing
ability to expand to include any new constructs, because we might
potentially maybe use those new constructs wrong. Yes, we should
always carefully consider new things. No, we shouldn't use every
new-fangled bit of the language. But honestly if you're writing c++
without auto today, it's not modern c++.

If you think auto isn't right for your module, don't accept it. That
much is agreeable, I think. To my knowledge, we've been using it for
years and so far I've only run into one at-all-related issue with it,
which ended up being a miscompilation on gcc<7 that affects all
references (including non-auto) to member scalars.
(https://bugzilla.mozilla.org/show_bug.cgi?id=1329044)

On Thu, Jan 4, 2018 at 11:31 AM, Randell Jesup  wrote:
> [SNIP]
>>> If foo->bar() can mutate the lifetime of foo, of course you must take a 
>>> strong
>>> reference to foo. Nothing about auto or range-for changes this.
>>
>>What auto does is make it really hard to tell whether a strong reference is
>>being taken.
>>
>>> If you don't understand your lifetimes, you get bugs.
>>
>>Fully agreed.  The discussion is about whether auto helps or hinders that
>>understanding.  The answer is that it depends on the surrounding code, from
>>where I sit...
>>
>>-Boris
>
> So, where do we go from here?
>
> It's clear that auto is not as safe as some/many believe it to be; it
> can as Boris (and smaug and Xidorn) say hide lifetime issues and lead to
> non-obvious UAFs and the like.  Some uses are certainly safe, but it
> isn't always obvious looking at a patch (per above), requiring more code
> investigation by the reviewer.  If the resultant type isn't obvious,
> then using it isn't helping comprehension.  When reading the code in the
> future, if the reader has to do non-trivial investigation just to know
> what's going on, it's hurting our work.
>
> If the win is to avoid typing I'd say it's not worth the risk.  Or
> allow it, but only with commentary as to why it's safe, or with rules
> about what sort of types it's allowed with and anything other than those
> requires justification in comments/etc.
>
> --
> Randell Jesup, Mozilla Corp
> remove "news" for personal email
> ___
> 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: Refactoring proposal for the observer service

[Gijs Kruitbosch]

On 04/01/2018 23:47, Gijs Kruitbosch wrote:

On 04/01/2018 22:49, Gabriele Svelto wrote:

On 04/01/18 00:05, Gijs Kruitbosch wrote:

Unfortunately, there are quite a lot (
https://searchfox.org/mozilla-central/search?q=obs.addObserver=false=false= 


-- sync, the add-ons manager, session store, etc. etc.).

That's not exactly what I meant. JS clients are fine as long as the
topic has already been declared. The issue with artifact builds arises
only when adding an entirely new topic that is used only in JS code
(i.e. both the notifier and listener are JS-only). I don't know how many
patches we've had but my guess is that they're not that many. JS code
usually has better ways to deal with this kind of scenarios than using
the observer service.
But the examples I gave are exactly that. sync, the add-ons manager and 
sessionstore all live in JS-land and have, to the best of my knowledge, 
(almost?) no C++ consumers of their "own" observer notifications. And 
they all have several observer notifications. They are also not the only 
components that do this, just the first few I spotted in the searchfox 
query.


Though of course, if we wanted to, we could decide that JS-only observer 
topics should get their own mechanism/component entirely, which also 
gets rid of this problem and avoids any xpconnect costs for this stuff, 
at the cost of having 2 implementations publish/subscribe... But hey, 
it's just a pub/sub implementation, not rocket science - and esp. in 
JS-land I know the limitations of the observer service as-is in terms of 
parameters etc. has been unfortunate at times.


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

Re: Refactoring proposal for the observer service

[Gijs Kruitbosch]

On 04/01/2018 22:49, Gabriele Svelto wrote:

On 04/01/18 00:05, Gijs Kruitbosch wrote:

Unfortunately, there are quite a lot (
https://searchfox.org/mozilla-central/search?q=obs.addObserver=false=false=
-- sync, the add-ons manager, session store, etc. etc.).

That's not exactly what I meant. JS clients are fine as long as the
topic has already been declared. The issue with artifact builds arises
only when adding an entirely new topic that is used only in JS code
(i.e. both the notifier and listener are JS-only). I don't know how many
patches we've had but my guess is that they're not that many. JS code
usually has better ways to deal with this kind of scenarios than using
the observer service.
But the examples I gave are exactly that. sync, the add-ons manager and 
sessionstore all live in JS-land and have, to the best of my knowledge, 
(almost?) no C++ consumers of their "own" observer notifications. And 
they all have several observer notifications. They are also not the only 
components that do this, just the first few I spotted in the searchfox 
query.

Ideally, I would like a solution where especially JS-only observer
topics don't require a non-artifact build.

I've given this a little thought and there could be a simpler solution,
though a little hacky. Instead of making the number of topic a
compilation constant one could put it somewhere were it could be
discovered at runtime (such as a preference) then leave a few empty
slots in the table for "unexpected" observers. In an artifact build one
would add the new topic which would regenerate the JS code, update the
number of topics but not the C++ side. At runtime C++ code would then
see the "unexpected" topic but since it would still end up in the
expected range at runtime would handle it correctly.

It wouldn't be super-pretty but it would work for common cases such as
adding only one new topic (or a few).
Well, I assume we ideally want the file to be organized. Not willy-nilly 
collections of "useful observer topics", like the way in which all.js 
and Histograms.json are basically a giant mess. I would further assume 
that we (automatically) number items sequentially. So adding items in 
the middle of the list and not recompiling the C++ is going to cause 
off-by-N errors for however many N observers you add, right? I don't see 
a good way of distinguishing the "new" topics at build-time and 
numbering them differently. Of course, patches could add the topic at 
the end for testing and then move it for review/landing, but that's 
still going to be annoying for developers, esp. if there's multiple 
review cycles, and we'll probably forget to do it sometime, etc. etc. So 
not very ergonomic...


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

Re: Refactoring proposal for the observer service

[Gabriele Svelto]

On 04/01/18 22:47, Nathan Froyd wrote:
> This is very doable, it just requires some build system hackery: we
> accept preprocessed/generated WebIDL files, and generated IDL files
> would require basically the same approach.  I can help with the build
> system hackery if you want to continue pursuing this approach.

If it's possible then I think it would be worth pursuing. With this
approach the constants would be held together with the methods within
the interface object/class versus three separate entities of my current
approach (the interface object/class, a C++ enum and a JS object).
Having everything in one place is definitely a better approach from a
code design perspective (and would prevent potential issues such as
including the interface definition but not the header with the enum
declaration). We'd also retain the other advantages such as the ability
to add further metadata to the declaration, having the constants
generated instead of written by hand, etc...

The only drawback I can think of is that we'd lose the ability to use an
enum in C++ for extra type safety. But that really isn't a big deal. For
crash annotations it mattered because the JS interface is built on top
of an already exposed C++ one which could be made type-safe. For
observers the interface used is always the generated one which - being
the same for JS and C++ - cannot use C++ enums directly anyway.

 Gabriele



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Refactoring proposal for the observer service

[Nathan Froyd]

On Thu, Jan 4, 2018 at 4:44 PM, Gabriele Svelto  wrote:
> On 04/01/18 22:39, Ben Kelly wrote:
>>  Or make your "generator"
>> create the idl which then creates the js/c++?
>
> I tried as that could have worked! Unfortunately it doesn't seem to be
> possible ATM. mach bailed out with a weird error when I tried to put an
> IDL file among the generated ones. I didn't really dig into it but I
> suspect that since we already generate code from IDL files they're not
> expected to be generated in turn.

This is very doable, it just requires some build system hackery: we
accept preprocessed/generated WebIDL files, and generated IDL files
would require basically the same approach.  I can help with the build
system hackery if you want to continue pursuing this approach.

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

Re: Refactoring proposal for the observer service

[Gabriele Svelto]

On 04/01/18 22:39, Ben Kelly wrote:
> We can't have a comment explaining "please add any new constants in
> sequential order in the following list"?

We could, but what about removing one? Also if we have hundreds (or
thousands) the risk that one is accidentally duplicated is significant.
My rationale for this is that managing topics the way we do know simply
doesn't scale so if we can avoid manual work we should.

>  Or make your "generator"
> create the idl which then creates the js/c++?

I tried as that could have worked! Unfortunately it doesn't seem to be
possible ATM. mach bailed out with a weird error when I tried to put an
IDL file among the generated ones. I didn't really dig into it but I
suspect that since we already generate code from IDL files they're not
expected to be generated in turn.

 Gabriele



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Refactoring proposal for the observer service

[Ben Kelly]

On Thu, Jan 4, 2018 at 4:35 PM, Gabriele Svelto  wrote:

> On 03/01/18 23:30, Ben Kelly wrote:
> > Could we use our existing idl/webidl/ipdl for this?  It would be nice
> > not to have to maintain another code generator in the tree if possible.
>
>
> AFAIK there is no way in IDL to declare an enum. Constants can be
> declared but one needs to manually assign them a value which makes it
> unsuitable for this task. Also there's no way to attach other metadata
> to the declaration (such as a mandatory comment).
>

We can't have a comment explaining "please add any new constants in
sequential order in the following list"?  Or make your "generator" create
the idl which then creates the js/c++?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Refactoring proposal for the observer service

[Gabriele Svelto]

On 03/01/18 23:30, Ben Kelly wrote:
> Could we use our existing idl/webidl/ipdl for this?  It would be nice
> not to have to maintain another code generator in the tree if possible.


AFAIK there is no way in IDL to declare an enum. Constants can be
declared but one needs to manually assign them a value which makes it
unsuitable for this task. Also there's no way to attach other metadata
to the declaration (such as a mandatory comment).

Don't get me wrong though, I am convinced it would be better if this
could be done in IDL because it could then be attached to the relevant
interface (such as nsIObserverService) and we wouldn't need separate
generation of the C++ and JS code, but we would need to significantly
extend it for the purpose.

 Gabriele



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Hiding 'new' statements - Good or Evil?

[Randell Jesup]

[SNIP]
>> If foo->bar() can mutate the lifetime of foo, of course you must take a 
>> strong
>> reference to foo. Nothing about auto or range-for changes this.
>
>What auto does is make it really hard to tell whether a strong reference is
>being taken.
>
>> If you don't understand your lifetimes, you get bugs.
>
>Fully agreed.  The discussion is about whether auto helps or hinders that
>understanding.  The answer is that it depends on the surrounding code, from
>where I sit...
>
>-Boris

So, where do we go from here?

It's clear that auto is not as safe as some/many believe it to be; it
can as Boris (and smaug and Xidorn) say hide lifetime issues and lead to
non-obvious UAFs and the like.  Some uses are certainly safe, but it
isn't always obvious looking at a patch (per above), requiring more code
investigation by the reviewer.  If the resultant type isn't obvious,
then using it isn't helping comprehension.  When reading the code in the
future, if the reader has to do non-trivial investigation just to know
what's going on, it's hurting our work.

If the win is to avoid typing I'd say it's not worth the risk.  Or
allow it, but only with commentary as to why it's safe, or with rules
about what sort of types it's allowed with and anything other than those
requires justification in comments/etc.

-- 
Randell Jesup, Mozilla Corp
remove "news" for personal email
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Orientation API future

[Kyle Machulis]

I took over the DOM: Device Interfaces component last month, and as part of
that was looking at the Generic Sensor APIs (and have been following this
conversation too). I've read over the spec, but that's about it so far.
While we've had a couple of outside questions about implementation, it
hasn't been mentioned as a priority.

On Thu, Jan 4, 2018 at 2:21 AM, Anne van Kesteren  wrote:

> On Thu, Jan 4, 2018 at 11:15 AM, Blair MacIntyre 
> wrote:
> > If we are going to break existing websites, then perhaps looking at the
> Generic Sensor API (as CVan suggests in his email) is a more rational
> approach;  is it implemented in FF yet?  Plans for it?
>
> See https://github.com/w3ctag/design-reviews/issues/207. There are
> quite a few concerns with the new APIs (that also apply to the old
> ones, granted, which is why we're discussing limiting those first). I
> also don't think we have anyone signed up to do the necessary
> implementation work.
>
>
> --
> https://annevankesteren.nl/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Announcing the next Extended Support Release of Firefox - ESR60 with policy engine

[Tom Ritter]

I am curious what Enterprise users are asking for.  I'd like to
think/hope that a primary concern of enterprise is "Security" (or the
separate topic of Privacy); but I'm not certain it is.

In particular, I am curious if enterprise users would be interested in
flipping preferences that would provide stronger security isolation at
the cost of more resources (like process/memory).  This is basically
what Chrome is providing with command-line flags for site isolation. A
company can decide that domains of their choosing get allocated into
per-origin processes, at the potential cost of a bunch of additional
processes.

-tom

On Thu, Dec 21, 2017 at 10:09 AM, Mike Kaply  wrote:
> We currently do not plan to allow arbitrary preferences, but if certain
> preferences are important, we can add policies for them.
>
> We could also add policies that set groups of preferences for specific
> purposes.
>
> Mike
>
> On Thu, Dec 21, 2017 at 10:03 AM, Luke Crouch  wrote:
>
>> On Wednesday, December 20, 2017 at 9:42:50 AM UTC-6, Sylvestre Ledru wrote:
>> > First, as Dave Camp mentioned during the Firefox All Hands, we are
>> started some developments to improve
>> > our support for enterprise users.
>> > More information can be found on the wiki: https://wiki.mozilla.org/
>> Firefox/EnterprisePolicies
>>
>> The first example configuration.json I saw on the page only shows some
>> custom policy configs - e.g., bookmarks_on_toolbar, allow_popups_from, etc.
>>
>> Will the policy config allow admins to set other/any about:config prefs to
>> custom values?
>>
>> I'm thinking specifically it would be cool to let Enterprise+InfoSec
>> admins set some security + privacy about:config prefs to more hardened
>> defaults.
>> ___
>> 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: Refactoring proposal for the observer service

[Matthew N.]

On 2018-01-04 10:00 AM, Nathan Froyd wrote:
…

2) How would one shoehorn this into *DL?  The options that come to mind are:

- Separate methods for every observer topic, which sounds terrible
from a code duplication perspective.  Though maybe this would be nice
for JS clients, so we could say things like:

   Services.obs.notifyXPCOMShutdown(...)

which would save on some xpconnect traffic and representing a
large-ish enum in JS?
- WebIDL enums (I think), which would carry a large space penalty and
make everything that wants to use the observer service depend on code
from dom/, which seems undesirable.
- IDL enums, which aren't reflected into JS, so we'd need some custom
work there.


As Ben said, XPIDL const's on an interface seem like a missing option 
that would work with JS. Random example: 
https://dxr.mozilla.org/mozilla-central/search?q=RECOVER_SESSION=false



- IPDL doesn't even have the concept of definable enums, and wouldn't
reflect things into JS, so we'd need even more work there.  (Some of
this may be desirable; we talked about extending IPDL bits into JS in
Austin, and kmaglione felt this was reasonable, so...)

The first and third don't sound *too* bad, but I don't think that
writing a one-off code generator would be strictly worse...


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

Re: Proposed W3C Charter: Second Screen Working Group

[Peter Saint-Andre]

+1 to Martin's feedback.

On 1/3/18 10:19 PM, Martin Thomson wrote:
> Without the protocol pieces, this remains vendor-specific.  We should
> comment on this and make it clear that we think that definition of a
> generic protocol for interacting with the second display has not been
> given sufficient priority.  Allowing this to proceed without a generic
> protocol would be bad for the ecosystem.
> 
> From what I can see, there seem to be a bunch of options that are
> described for the protocol, without extremely scant detail.  Certainly
> not enough to implement anything.
> 
> I'm concerned with the statement "This Working Group does not
> anticipate further changes to this specification" regarding the
> presentation API.  I haven't reviewed this thoroughly, but there
> appear to be some gaps in rather fundamental pieces.  For instance -
> and maybe this doesn't change the API at all - but the means of
> identification for screens is unclear.  Some of these details are
> important, such as whether knowledge of a presentation URL is all the
> information necessary to use that URL (i.e., are they capability
> URLs?).
> 
> On Thu, Jan 4, 2018 at 2:31 PM, Shih-Chiang Chien  wrote:
>> The SecondScreen WG intended to move the protocol development to CG, and
>> will possibly move to IETF after the incubation phase.
>> The revised charter is trying to associate the work of CG to the timeline
>> of Presentation API development.
>>
>> At the meantime, WG will tackle the testability issue found while creating
>> test cases and cultivating Level 2 API requirements for advanced use cases.
>>
>> I'll vote to support this revised charter.
>>
>> Best Regards,
>> Shih-Chiang Chien
>> Mozilla Taiwan
>>
>> On Thu, Jan 4, 2018 at 10:08 AM, L. David Baron  wrote:
>>
>>> The W3C is proposing a revised charter for:
>>>
>>>   Second Screen Working Group
>>>   https://w3c.github.io/secondscreen-charter/
>>>   https://lists.w3.org/Archives/Public/public-new-work/2017Dec/.html
>>>
>>> Mozilla has the opportunity to send comments or objections through
>>> Friday, January 52.  (Sorry for failing to send this out sooner!)
>>>
>>> A diff relative to the current charter is:
>>> https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2014%
>>> 2Fsecondscreen%2Fcharter-2016.html=https%3A%2F%2Fw3c.
>>> github.io%2Fsecondscreen-charter%2F
>>>
>>> The participants in the working group are:
>>> https://www.w3.org/2000/09/dbwg/details?group=74168=1=org
>>>
>>> Please reply to this thread if you think there's something we should
>>> say as part of this charter review, or if you think we should
>>> support or oppose it.
>>>
>>> One longstanding concern for me with this work is to what extent it
>>> defines an API that lets an Google-made browser talk to a Google
>>> screen, and an Apple-made browser talk to an Apple screen, versus to
>>> what extent it allows any browser to talk to any screen that
>>> supports a particular piece of technology.  I think there might
>>> have been some encouraging news on this front at TPAC in November,
>>> but I don't remember the details.  But if there was, I'd rather
>>> expect it to be incorporated into this charter, but I don't really
>>> see that after a first read.  I'm curious what others know and think
>>> about this issue.
>>>
>>> -David
>>>
>>> --
>>> 턞   L. David Baron http://dbaron.org/   턂
>>> 턢   Mozilla  https://www.mozilla.org/   턂
>>>  Before I built a wall I'd ask to know
>>>  What I was walling in or walling out,
>>>  And to whom I was like to give offense.
>>>- Robert Frost, Mending Wall (1914)
>>>
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
> 



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Refactoring proposal for the observer service

[Ben Kelly]

On Thu, Jan 4, 2018 at 10:00 AM, Nathan Froyd  wrote:

> On Wed, Jan 3, 2018 at 5:30 PM, Ben Kelly  wrote:
> > On Wed, Jan 3, 2018 at 5:09 PM, Gabriele Svelto 
> wrote:
> >> So after validating my approach in that bug (which is almost ready) I've
> >> thought that it might be time to give the observer service the same
> >> treatment. First of all we'd have a list of topics (I've picked YAML for
> >> the list but it could be anything that fits the bill):
> >
> > Could we use our existing idl/webidl/ipdl for this?  It would be nice
> not to
> > have to maintain another code generator in the tree if possible.
>
> I don't understand this objection on two levels:
>

It wasn't an objection.  It was a question.  If possible, can we use
something we already have?  The answer can be "no".


> 1) Why does maintaining another code generator in tree hurt anything?
> We have many one-off code generators for specific purposes:
>
> https://searchfox.org/mozilla-central/search?q=GENERATED_
> FILES=false=false=moz.build
>
> Some of these use non-Python generators (e.g. the a11y files and gfx
> shaders), but there are probably enough to count on multiple hands.
>
> I would expect modifications of the code generator to be infrequent,
> and the code generator itself is liable to be a screenful or so of
> straightforward code.
>

Sure, but having someone understand and able to modify additional code
generators does require additional effort.  Its not impossible, but it
makes it harder.  So it would be nice to avoid if we can.  If we can't
avoid it, then ok.


> - WebIDL enums (I think), which would carry a large space penalty and
> make everything that wants to use the observer service depend on code
> from dom/, which seems undesirable.
> - IDL enums, which aren't reflected into JS, so we'd need some custom
> work there.
>

Yea, I was mostly thinking webidl or idl enums.  The enums could be stuck
on an idl interface as constants, no?

Anyway, I was mostly just asking that we consider these options before
writing something new.  If they're not a good fit, then so be it.

Thanks.

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

Re: Refactoring proposal for the observer service

[Nathan Froyd]

On Wed, Jan 3, 2018 at 5:30 PM, Ben Kelly  wrote:
> On Wed, Jan 3, 2018 at 5:09 PM, Gabriele Svelto  wrote:
>> So after validating my approach in that bug (which is almost ready) I've
>> thought that it might be time to give the observer service the same
>> treatment. First of all we'd have a list of topics (I've picked YAML for
>> the list but it could be anything that fits the bill):
>
> Could we use our existing idl/webidl/ipdl for this?  It would be nice not to
> have to maintain another code generator in the tree if possible.

I don't understand this objection on two levels:

1) Why does maintaining another code generator in tree hurt anything?
We have many one-off code generators for specific purposes:

https://searchfox.org/mozilla-central/search?q=GENERATED_FILES=false=false=moz.build

Some of these use non-Python generators (e.g. the a11y files and gfx
shaders), but there are probably enough to count on multiple hands.

I would expect modifications of the code generator to be infrequent,
and the code generator itself is liable to be a screenful or so of
straightforward code.

2) How would one shoehorn this into *DL?  The options that come to mind are:

- Separate methods for every observer topic, which sounds terrible
from a code duplication perspective.  Though maybe this would be nice
for JS clients, so we could say things like:

  Services.obs.notifyXPCOMShutdown(...)

which would save on some xpconnect traffic and representing a
large-ish enum in JS?
- WebIDL enums (I think), which would carry a large space penalty and
make everything that wants to use the observer service depend on code
from dom/, which seems undesirable.
- IDL enums, which aren't reflected into JS, so we'd need some custom
work there.
- IPDL doesn't even have the concept of definable enums, and wouldn't
reflect things into JS, so we'd need even more work there.  (Some of
this may be desirable; we talked about extending IPDL bits into JS in
Austin, and kmaglione felt this was reasonable, so...)

The first and third don't sound *too* bad, but I don't think that
writing a one-off code generator would be strictly worse...

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

Re: Refactoring proposal for the observer service

[Gijs Kruitbosch]

On 03/01/2018 23:18, Nihanth Subramanya wrote:

++ from me as well, this sounds awesome.


Ideally, I would like a solution where especially JS-only observer topics don't require a non-artifact build. A JS forwarder for the 
"real" observer service may help with that goal, by making the "new" arguments into strings transparently, and using 
the same string as a webidl name property for artifact builds. This would mean "new" JS-only observer calls in an artifact build 
would be slower than the int-based "real" ones (and would perform "normally" once you actually did a "real" 
build, ditto for distributed stuff). I think that's an OK trade-off.

Would you mind expanding on how you see this working? Specifically, I didn’t 
understand "using the same string as a webidl name property for artifact 
builds”.
We'd have a JS artifact-build-only version of the topics list that was a 
proxy on the 'real' thing. So you'd access ObsTopics.Foo, and if the 
'real' thing knew about "Foo", it'd just forward the relevant int. If 
not, it would return the topic string (so "Foo"). When the JS forwarder 
for the 'real' service gets called with a string (instead of an int), it 
notifies/adds/removes observers on itself only, and doesn't pass the 
relevant call to C++.


The reason for using strings and forwarding is that I don't see a 
reasonable way for the build system to distinguish topics that the 
binary blobs it's using know about, from topics they have no idea about 
(that the developer just added to the manifest). Whereas at runtime it's 
easy to make that determination. I guess you could maybe do it at build 
time by firing up xpcshell as part of the build process, and then 
generate new ints for the new topics into the JS file, but that seems 
cumbersome at best.


Plus you'd probably want to make the observer service throw for calls 
with invalid topic ints, so then you need a way to distinguish the new 
JS-only ones on the JS side before passing it to the 'real' observer 
service. I guess we could have the C++ side expose the "maximum valid 
topic int" or whatever, and the JS side could check that... but having 
them be different JS types seems simpler.



Also related: in this JS forwarder world you’re describing, what exactly does 
the workflow look like for a frontend developer using artifact builds? I’d 
imagine the following:


Get an artifact build ready to go
Make changes, including adding the new observer topics to the manifest (or 
list, or whatever you want to call it)
mach build faster
Changes are immediately testable, though there will be a perf cost unless you 
do a “normal” build.

Yes, that seems right to me.

~ Gijs


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

Re: Device Orientation API future

[Anne van Kesteren]

On Thu, Jan 4, 2018 at 11:15 AM, Blair MacIntyre  wrote:
> If we are going to break existing websites, then perhaps looking at the 
> Generic Sensor API (as CVan suggests in his email) is a more rational 
> approach;  is it implemented in FF yet?  Plans for it?

See https://github.com/w3ctag/design-reviews/issues/207. There are
quite a few concerns with the new APIs (that also apply to the old
ones, granted, which is why we're discussing limiting those first). I
also don't think we have anyone signed up to do the necessary
implementation work.


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

Re: Device Orientation API future

[Martin Thomson]

My hope is that any stickiness would be transitory.

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

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

Re: Device Orientation API future

[Martin Thomson]

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

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

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

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

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

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

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

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

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

Re: Device Orientation API future

[Blair MacIntyre]

I’m unclear of which side of the line we want to fall on between supporting 
existing sites or requiring them to change.

If we are going to break existing websites, then perhaps looking at the Generic 
Sensor API (as CVan suggests in his email) is a more rational approach;  is it 
implemented in FF yet?  Plans for it?

For device orientation, my assumption (perhaps incorrect?) has been that we’d 
be trying to support existing sites.  The worry I have with the gross motion 
idea is that the UX would be terrible.  Right now, you start a site (VR, 360 
image, etc) and can look around:  in my own experience, the motion is rarely 
fast.  So the site would appear stuck, and the user may never discover it’s 
stuck.

But, perhaps if we’re willing to change the browser itself to provide some 
feedback, this could work though.  
- I go to a site, it requests motion
- motion events are not sent initially
- FF waits a bit to see if the user shakes or grossly moves the phone (e.g., 
perhaps a newer site says “shake the phone to activate panoramic viewing”)
- if it does happen, FF slides in/down a message saying something similar 
(e.g., “site wants to watch the movements of your device;  shake phone or click 
yes to confirm, no to deny”)
- if shake doesn’t happen in short time, or they click no, that’s that.  If 
they shake or click yes, motion is used.

But, perhaps this is too confusing.  

For the perms API, I imagined it might just work with devicemotion:  setting up 
the callback could trigger a perms request, and the data would only start 
flowing on acceptance.  

> On Jan 3, 2018, at 11:52 PM, Martin Thomson  wrote:
> 
> On Thu, Jan 4, 2018 at 1:09 PM, Blair MacIntyre  
> wrote:
>> We could chat about it, sure;  how do you envision it working without 
>> breaking old websites?
> 
> With the understanding that this is purely spitballing...
> 
> We would stop providing events (or provide them with extremely low
> frequency [1]), but if the currently focused context has an event
> handler registered for orientation events, we would enable events once
> the orientation changes by a large amount or quickly.  The thresholds
> might need some tuning, but a shake or large movement should work.
> 
> That means that sites that expect and only receive subtle movement
> would stop receiving events.  Sites that don't receive input focus
> would stop receiving events (that prevents an embedded iframe from
> getting events).  But sites that legitimately use the API will only
> appear to be a little "sticky" initially.  We might also persist this
> "implicit" permission to remove that stickiness for sites that are
> used often (or reduce the activation thresholds over repeat visits).
> 
> We should also look at getting a hook into the permission API so that
> the current state can be queried.  But that API doesn't really
> understand this sort of model, so that might be tricky to work out.

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

Re: Device Orientation API future

[Martin Thomson]

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

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

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