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

[Martin Thomson]

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

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

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

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

[Martin Thomson]

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

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

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

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

[Martin Thomson]

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

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

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

[Martin Thomson]

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

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

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

Re: Ambient Light Sensor API

[Martin Thomson]

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

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

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

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

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

Re: Ambient Light Sensor API

[Martin Thomson]

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

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

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

Re: Ambient Light Sensor API

[Martin Thomson]

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

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

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

Re: Intent to ship: SharedArrayBuffer and Atomics

[Martin Thomson]

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

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

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

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

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

Re: Improving visibility of compiler warnings

[Martin Thomson]

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

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

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

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

Re: Intent to ship: NetworkInformation

[Martin Thomson]

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

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

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

Re: Improving visibility of compiler warnings

[Martin Thomson]

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

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

Re: Phabricator Update, July 2017

[Martin Thomson]

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

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

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

Re: Phabricator Update, July 2017

[Martin Thomson]

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

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

Re: Extensions and Gecko specific APIs

[Martin Thomson]

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

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

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

Re: Restricting the Notifications API to secure contexts

[Martin Thomson]

More than fine, this is an overdue change :)

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

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

Re: Coding style: Argument alignment

[Martin Thomson]

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

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

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

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

Re: Coding style: Argument alignment

[Martin Thomson]

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

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

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

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

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

Re: Device Memory header and JS API

[Martin Thomson]

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

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

Re: Device Memory header and JS API

[Martin Thomson]

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

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

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

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

[Martin Thomson]

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

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

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

e.g.,

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

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

Re: Follow up on clang-format

[Martin Thomson]

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

For this you can use:

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

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

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

Re: Follow up on clang-format

[Martin Thomson]

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

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

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

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

Re: Device Orientation API future

[Martin Thomson]

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

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

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

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

Re: Device Orientation API future

[Martin Thomson]

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

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

Re: Device Orientation API future

[Martin Thomson]

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: Proposed W3C Charter: Second Screen Working Group

[Martin Thomson]

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

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

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

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

Re: Device Orientation API future

[Martin Thomson]

On Thu, Jan 4, 2018 at 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: Device Orientation API future

[Martin Thomson]

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

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

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

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

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

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

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

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

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

Re: Device Orientation API future

[Martin Thomson]

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: Proposed W3C Charter: Second Screen Working Group

[Martin Thomson]

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

Re: Device Orientation API future

[Martin Thomson]

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

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

Re: Device Orientation API future

[Martin Thomson]

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

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

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

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

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

Re: Device Orientation API future

[Martin Thomson]

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

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

Re: Requiring secure contexts for new features

[Martin Thomson]

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

Anne, your posting suggests an exception is likely if:

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

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

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

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

Re: Intent to implement and ship navigator.webdriver

[Martin Thomson]

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

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

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

Re: Chrome will start marking HTTP pages as "Not secure"

[Martin Thomson]

+ffxdev

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

On Fri, Feb 9, 2018 at 8:17 AM, Chris Peterson  wrote:
> Chrome will start marking HTTP pages as "Not secure" in July 2018 (Chrome
> 68):
>
> https://security.googleblog.com/2018/02/a-secure-web-is-here-to-stay.html
>
> Firefox has a similar insecure HTTP warning icon, currently disabled by the
> `security.insecure_connection_icon.enabled` pref added in bug 1310447.
>
> Are there any blockers for Firefox shipping this feature?
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Martin Thomson]

Yes, it pays to remember that this is Nightly.

The precautions Henri suggests are good, but more appropriate to
experiments we would do on Release.  For TLS 1.3, we did that sort of
thing so that we could get measurements from Release; we just flipped
the switch to "on" for Nightly.

I don't know if it is possible to know if you have a
manually-configured DNS server, but disabling this experiment there if
we can determine that would be good - that might not be something to
worry about with Nightly, but it seems like it might be needed for
this to hit the trains.

How do we otherwise determine that a DNS server is not safe to
replace?  Split horizon DNS is going to cause unexpected failures when
users - particularly enterprise users - try to reach names that aren't
public.  That's not just an enterprise thing; this will break my home
router in some ways as well, though I'm actually totally OK with that
in this case :)

On Mon, Mar 19, 2018 at 11:25 AM, Patrick McManus  wrote:
> The objective here is a net improvement for privacy and integrity. It is
> indeed a point of view with Nightly acting as an opinionated User Agent on
> behalf of its users. IMO we can't be afraid of pursuing experiments that
> help develop those ideas even when they move past traditional modes.
> Traditional DNS is a swamp - ignoring that isn't doing our users any
> favors. This is obviously not an engineering only driven effort.
>
> Nightly is an explicitly experimental channel which is part of the reason
> it is the choice for the first validation.
>
> A question came up about geo based DNS and I've got a couple technical
> comments about risk mitigation there:
>  1] geo dns use is on the wane as TCP anycast approaches work much better
> in practice
>  2] the granularity of the CDN being used is much finer than the
> granularity of most geoDNS resolution which tends to choose between very
> big regions (O(~ 1/2 a continent)) so that should continue to work the same.
>
> I initiated this thread on dev-platform because imo it is a reasonable
> scope for nightly changes, especially ephemeral flip pref changes, and
> that's why the FYI goes here. Its definitely not a secret. Messaging to a
> larger user base than is impacted invites confusion. Future possible
> changes impacting larger populations or putting things on trains would use
> other, more broadly read communications channels.
>
> -Patrick
>
>
>
> On Mon, Mar 19, 2018 at 9:05 AM, Henri Sivonen  wrote:
>
>> On Mon, Mar 19, 2018 at 10:07 AM, Daniel Stenberg 
>> wrote:
>> > On Sun, 18 Mar 2018, Eric Shepherd (Sheppy) wrote:
>> >
>> > I don't have such a far-reaching agreement with my ISP and its DNS.
>>
>> 1) Mozilla doesn't choose the ISP on users' behalf. (This is the key
>> reason.)
>> 2) The ISP sees the Host header in unencrypted traffic and SNI in
>> encrypted traffic anyway. (This is a secondary reason.)
>>
>> > I don't
>> > have such an agreement at all with 8.8.8.8 or other publicly provided DNS
>> > operators.
>>
>> Using such resolvers is a decision that the user makes and not a
>> decision that Mozilla *silently* makes on their behalf.
>>
>> > What other precautions or actions can we do to reduce the risk of this
>> being
>> > perceived as problematic?
>>
>> I suggested two ways on the bug.
>>
>> > Would reducing the test population really make it
>> > much different?
>>
>> No.
>>
>> --
>> Henri Sivonen
>> hsivo...@hsivonen.fi
>> https://hsivonen.fi/
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Martin Thomson]

This seems like a good idea.

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

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

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

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

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

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

[Martin Thomson]

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

Maybe.  We currently use tags.

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

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

Re: Intent to unship: URL.createObjectURL(MediaStream)

[Martin Thomson]

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

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

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

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

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

[Martin Thomson]

Hi Chris,

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

> Hi all,

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

> TL;DR
> -

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

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

> They are not equivalent.

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

> Requesting docs
> ---

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

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

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

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

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

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

> Reporting problems
> --

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

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

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

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

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

> Many thanks!

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

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

Re: DNS Rebinding protection

[Martin Thomson]

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

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

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

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

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

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

Re: Use of 'auto'

[Martin Thomson]

On Mon, Aug 3, 2015 at 6:07 PM, Jonas Sicking  wrote:
> How would you make a factory function like the above fail?


Don't allow for the possibility.  If Foo::Create() is directly
analogous to new Foo(), then it can't fail.  Leave the failing for
later method calls.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Fingerprinting of battery status?

[Martin Thomson]

On Tue, Aug 4, 2015 at 8:24 AM, Tim Taubert  wrote:
>> Can we just reduce the accuracy of the API?  Only give battery level at
>> certain broad breakpoints?
>
> The authors of the cited paper [1] filed a bug report and we fixed that
> for 38 [2].

I should think that more aggressive rounding would still be OK, maybe
for less trusted origins (of course, we still need to have a good
definition for "less trusted").
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Fingerprinting of battery status?

[Martin Thomson]

On Tue, Aug 4, 2015 at 9:33 AM, Jonas Sicking  wrote:
> So disabling the API, or fudging its return values, in private
> browsing windows sounds like a good idea. The same applies to features
> like device orientation, proximity/light sensors, network information
> (wifi vs. mobile etc), device orientation and probably a few more


TOR browser fudges keyboard input in the same way.  In that case,
small but random delays reduce fingerprinting exposure significantly.

Of course, don't expect to get away with the same trick with geolocation.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Can we make a plan to retire Universal Mac builds?

[Martin Thomson]

On Wed, Aug 5, 2015 at 3:59 PM, Matthew N.  wrote:
> If we have data on CPU architecture I don't think the OS version is relevant
> unless I'm missing something.

My understanding is that OS version is all that matters.  64-bit apps
require a 64-bit OS.  (Such an OS requires a 64-bit processor of
course.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Ship: Push API

[Martin Thomson]

On Tue, Aug 11, 2015 at 3:07 AM, Julien Wajsberg  wrote:
> Can you share what the plan is for Fx/Android and Firefox OS ?

Firefox OS can (and likely will) use the same basic technology, though
the UX story there is incomplete.

Fennec needs extra work in order to integrate with GCM (or Google Play
Services).  We won't directly use our push service for Android because
we lose much of the advantage that push provides if we use a second
push service.  That requires a fairly large amount of engineering
effort, I think, though see bug 1191367 for details.  Fennec UX would
also need work.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New policy: 48-hour backouts for major Talos regressions

[Martin Thomson]

On Fri, Aug 14, 2015 at 2:56 PM, Vladan D  wrote:
> Tests are reliable if they detect regressions, aren't very noisy, and if they 
> measure things that have a real impact on actual Firefox user experience.

Do we track false positives on these?  I say that because I got a mail
just last week for ts_paint that seemed spurious.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New policy: 48-hour backouts for major Talos regressions

[Martin Thomson]

On Fri, Aug 14, 2015 at 3:44 PM, Vladan Djeric  wrote:
> Is this the ts_paint regression you're referring to?
> https://groups.google.com/forum/#!searchin/mozilla.dev.tree-alerts/ts_paint/mozilla.dev.tree-alerts/FArVsa8guXg/FfY91JK7AAAJ

Yeah.  I only ask because in exercising judgment suppresses
information about the stability of the tests, so that all we have is
anectodal evidence.  That's probably OK here.  The process you
describe sounds pretty robust against false positives.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Implement and Ship: Permissions API

[Martin Thomson]

On Tue, Aug 25, 2015 at 2:12 AM, Anne van Kesteren  wrote:
>>> 3) It seems the API is evolving in ways to also request permission
>>> without then directly using that permission. It's not clear that is a
>>> good idea.
>>
>> This is something that is already doable. If a webpage calls
>> navigator.geolocation.getCurrentPosition(), it doesn't need to do
>> anything with the position (this can apply to roughly any API). The
>> Notififcations API has an explicit call for requesting too.
>
> The Notifications API is a special case as is noted in its
> specification. It's one of the few cases where we decided this was
> acceptable.

On this point, I agree with Anne.  Notifications doesn't get the
option of an in-context request, and what we have there is the best we
could do at the time.  It is possible that we could do better; I've
not given up on that just yet.

>> Furthermore,
>> allowing requests will open some new possibilities like requesting a
>> 'paste' permission which can't be done today.
>
> If we do indeed need that we could add an API for it. But we should
> first carefully consider if another approach is not better.

I'd like to more directly encourage that as well.  Asking permission
in context has its risks, but out of context has relevancy problems.
I'd rather we carefully examine every instance where we are tempted to
ask users questions, because I don't believe that asking questions
like that is good.

Reducing the friction for adding new ways to bother users with
questions is a drawback of the API.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship

[Martin Thomson]

WebRTC was shipped with a prefix.

Bug 1155923 moves our codebase to non-prefixed names, but includes a
patch to restore aliases with the prefix.  Thus we will expose
`RTCPeerConnection` and use that ourselves, but permit legacy code to
use `mozRTCPeerConnection`.

Maybe some day we can remove the aliases by just backing out the patch
that creates prefixed aliases, but that seems unlikely in the short
term [1][2].

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1155923
Link to standard: http://w3c.github.io/webrtc-pc/
Platform coverage: everywhere
Target release: 43
Preference behind which this will be implemented: none
DevTools bug: none

Chrome and Opera ship with a 'webkit' prefix.  I'm not aware of any
shipping implementation of this API in other browsers.

[1] Compatibility on the WebRTC API has been very poor in the past.
I'm not aware of any code that doesn't detect browsers based on the
prefixed names and then does something browser-specific.

[2] However, this situation has been improving rapidly.  In any case,
a less-than perfect interoperability situation is no excuse for using
prefixes.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship

[Martin Thomson]

On Tue, Aug 25, 2015 at 2:16 PM, Ehsan Akhgari  wrote:
> On 2015-08-25 4:07 PM, Martin Thomson wrote:
>>
>> WebRTC was shipped with a prefix.
>>
>> Bug 1155923 moves our codebase to non-prefixed names, but includes a
>> patch to restore aliases with the prefix.  Thus we will expose
>> `RTCPeerConnection` and use that ourselves, but permit legacy code to
>> use `mozRTCPeerConnection`.
>
> Is our RTCPeerConnection and the corresponding spec considered as stable?

Stable enough to use the name, certainly [see
https://tools.ietf.org/html/rfc6648].  But maybe that wasn't your
question...

The core parts of the spec are stable and have been for years.  There
are parts that are still unstable.  I don't expect that to change
appreciably for some time, even though the W3C working group has a
goal for a big 1.0 release.

>> Maybe some day we can remove the aliases by just backing out the patch
>> that creates prefixed aliases, but that seems unlikely in the short
>> term [1][2].
>
> Do the aliases only work when you call them or can the webpage also detect
> them?  IOW, what would code like below do?
>
> if (window.mozRTCPeerConnection)
>   foo();
> else if (window.RTCPeerConnection)
>   bar();

The following code would call foo().  In the patch that I have,
mozRTCPeerConnection looks exactly like RTCPeerConnection.  That means
that window.mozRTCPeerConnection is present, can be instantiated, can
be tested with instanceof, and can be passed to any functions that
accept RTCPeerConnection (there aren't any that I can think of there).

The only difference I'm aware of is that constructing the prefixed
version drops a polite warning (using document->WarnOnceAbout()) into
the console.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: MD5 - Re: On the future of and application/x-x509-*-cert MIME handling

[Martin Thomson]

Henry, I would rather you attempt to address Ryan's point 5, namely:

5)  just generates keys, and relies on
application/x-x509-*-cert to install certificates. This MIME handling,
unspecified but implemented by major browsers, represents
yet-another-way for a website to make persistent modifications to the
user system.

The key generation capability exists today with webcrypto.  I'm
actually more interested in the consequences of the MIME-type handling
and it's interaction with key stores on the browser.  That is the more
relevant piece of this whole issue.  I know that it is at the core of
the argument.

I honestly think that the best thing here - given the current state -
is to treat this as an opportunity to ask for new work in the W3C. We
can examine these needs on their own merits and determine if investing
in new technology based on TLS client certificates is the right thing
for the web.


On Fri, Sep 4, 2015 at 12:44 PM,   wrote:
> On Thursday, 30 July 2015 01:35:52 UTC+2, David Keeler  wrote:
>> [cc'd to dev-security for visibility. This discussion is intended to
>> happen on dev-platform; please reply to that list.]
>>
>> Ryan Sleevi recently announced the pre-intention to deprecate and
>> eventually remove support for the  element and special-case
>> handling of the application/x-x509-*-cert MIME types from the blink
>> platform (i.e. Chrome).
>>
>> Rather than reiterate his detailed analysis, I'll refer to the post here:
>>
>> https://groups.google.com/a/chromium.org/d/msg/blink-dev/pX5NbX0Xack/kmHsyMGJZAMJ
>>
>
> One of the elements of his detailed analysis is under fire, namely that the 
> reliance of keygen on PEM is a key security hole. I made this case in more 
> detail here:
> https://github.com/whatwg/html/issues/102
>
> But to avoid your needing to click on the link here it is in full:
>
>  has been deprecated a few days ago, and the issue has been taken up 
> by @timbl on the Technical Architecture Group as it removes a useful tool in 
> the asymmetric public key cryptography available in browsers.
>
> One reason given for deprecating that recurs often is that keygen uses MD5 
> which opens an attack vector presented in a very good paper "MD5 considered 
> harmful today" at the Chaos Communication Congress in Berlin in 2008 by a 
> number of researchers of which Jacob Appelbaum ( aka. @ioerror ) . ( That was 
> the time when Julian Assange was working freely on Wikileaks, so you can even 
> hear him ask a question at the end )
>
> The slides are here:
> https://www.trailofbits.com/resources/creating_a_rogue_ca_cert_slides.pdf
> The video is here:
> http://chaosradio.ccc.de/25c3_m4v_3023.html
>
> In short they were able to create a fake Certificate Authority (CA) because 
> the CA signed its certificates with MD5 and they were able to create hash 
> collisions, to use the certificate signed by the CA
> and change some information in it to produce their own top level certificate, 
> with which
> they could create a certificate for any site they wished to! ( Pretty 
> awesomely bad - though they did this carefully to avoid misuse ). This is why 
> projects such as IETFs DANE, DNSSEC, and many other improvements to the 
> internet infrastructure are vital.
>
> This was 7 years ago, so all of this should be fixed by now. There should be 
> no CA signing
> Server Certificates with MD5 anymore.
>
> Great. But that has nothing to do with what is going on with . The 
> problem
> may well be that the documentation of  is misleading here. The WHATWG 
> documentation on keygen currently states:
>
> If the keytype attribute is in the RSA state: Generate an RSA key pair using 
> the settings given by the user, if appropriate, using the 
> md5WithRSAEncryption RSA signature algorithm (the signature algorithm with 
> MD5 and the RSA encryption algorithm) referenced in section 2.2.1 ("RSA 
> Signature Algorithm") of RFC 3279, and defined in RFC 3447. [RFC3279] 
> [RFC3447]
> By whether or not keygen wraps the key and signs it with MD5 is of not much 
> importance, since this is the keyrequest we are speaking of here, not the 
> generated certificate!
>
> To summarise how the keygen is actually used:
> 1. The browser creates a public/private key, saves the private key in the 
> secure keychain
> 2. and sends the public key in an spkac request to the server which
> 3. which on receipt of the certificate request and verification of the data, 
> uses that to create a Client Certificate using any signature algorithm it 
> wants for the creation of the certificate ( And so it SHOULD NOT USE MD5: see 
> CCC talk above )
> 4. which it returns using one of the x509 mime types available to it,
>
> Here is an illustration of the flow that we use in the WebID-TLS spec to 
> illustrate this:
> Certificate Creation Flow
>
> http://www.w3.org/2005/Incubator/webid/spec/tls/#certificate-creation
>
> To see some real code implementing this I point you to my 
> ClientCertificateApp.scala code that receives a certificate R

Re: On the future of and application/x-x509-*-cert MIME handling

[Martin Thomson]

I have some questions, to which I was unable to find answers for in
the (numerous and long) threads on this subject.

1. When we download and install a client cert, what checking do we do?
 Do we insist upon it meeting the same algorithm requirements we have
for servers with respect to use of things like short RSA keys and weak
hashes (MD5/SHA-1)?

2. What is the potential scope of use for a client certificate?
Global?  The origin that provided it?  Something in-between like
domain or domain plus subdomains?

I'll go and dig around in the code if I have to, but if someone has
the answers readily available, or wants to do the rummaging for me,
that would be much appreciated.

On Wed, Jul 29, 2015 at 4:35 PM, David Keeler  wrote:
> [cc'd to dev-security for visibility. This discussion is intended to
> happen on dev-platform; please reply to that list.]
>
> Ryan Sleevi recently announced the pre-intention to deprecate and
> eventually remove support for the  element and special-case
> handling of the application/x-x509-*-cert MIME types from the blink
> platform (i.e. Chrome).
>
> Rather than reiterate his detailed analysis, I'll refer to the post here:
>
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/pX5NbX0Xack/kmHsyMGJZAMJ
>
> Much, if not all, of that reasoning applies to gecko as well.
> Furthermore, it would be a considerable architectural improvement if
> gecko were to remove these features (particularly with respect to e10s).
> Additionally, if they were removed from blink, the compatibility impact
> of removing them from gecko would be lessened.
>
> I therefore propose we follow suit and begin the process of deprecating
> and removing these features. The intention of this post is to begin a
> discussion to determine the feasibility of doing so.
>
> Cheers,
> David
>
>
> ___
> dev-security mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: On the future of and application/x-x509-*-cert MIME handling

[Martin Thomson]

Awesome, thanks Ryan.

This cements my opinion on their fate.  These are not just old and
crufty, they are actively harmful.  They can't be removed soon enough.

I'm not fundamentally opposed to the notion of having some sort of
site control of client authentication in general, and maybe even TLS
client authentication specifically, but this feature[7] cannot
continue to exist as part of the web platform.

[7] By which I mean the certificate download and install part, keygen
seems to be more on the cruft side based on what I've seen.

On Fri, Sep 11, 2015 at 9:42 PM, Ryan Sleevi  wrote:
> [No idea if these will show up on the lists since I'm not subscribed]
>
> On Fri, Sep 11, 2015 at 9:30 PM, Martin Thomson  wrote:
>
>> I have some questions, to which I was unable to find answers for in
>> the (numerous and long) threads on this subject.
>>
>> 1. When we download and install a client cert, what checking do we do?
>>  Do we insist upon it meeting the same algorithm requirements we have
>> for servers with respect to use of things like short RSA keys and weak
>> hashes (MD5/SHA-1)?
>>
>
> No. These are client certs (generally for internal systems), for which
> there are no imposed policies on (CA/B Forum or otherwise).
>
> The only checking re: algorithms are those which NSS itself has not
> disabled globally (MD5, minimum keysizes, etc), but only if they present as
> parse errors - not as signature validation errors.
>
> If it comes in as application/x-x509-user-cert (vs, say,
> application/x-x509-ca-cert, which can be used to quickly add a root
> certificate),
> http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/nsNSSCertificateDB.cpp#849
> is what first parses/interprets the byte stream.
>
> The validation requires:
> 1) That the user has an existing private key (from any source,  or
> otherwise - so you can use this as an existence proof of whether or not a
> user has a matching key). That's line 886
> 2) That it's syntactically valid for one of the forms Mozilla accepts - or
> one of the ones it can munge into something it accepts (a liberal decoder)
> - that's line 875
>
> If so, it'll toast the user (via
> http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/nsNSSCertificateDB.cpp#810
> ) to let them know a certificate was installed (after the fact)
>
> It'll then parse the rest of the bundle, and if they are certificates that
> chain to a CA the user trusts, they'll also be imported (that's line 924)
>
>
> This behaviour, however, is different than Chrome's in several ways
> (primarily related to the parsing of the bundle and handling the additional
> certificates). Chrome also explored a number of strict checks (is it a
> valid client certificate from a known CA), but those had to be relaxed for
> compatability with Firefox and the existing use cases.
>
> We also explored not committing the generated key to the persistent
> keystore until it'd been "confirmed" (via installation of a certificate),
> except that broke nearly every  use case outside of WebID. In
> particular, if you closed Chrome, we'd destroy the key - so that didn't
> work for situations where you'd do a  enrollment, close Chrome, a
> day later getting an email with a link from your CA w/ the certificate. So
> you'd need some form of semi-persistent, origin-scoped storage if you went
> that way.
>
>
>>
>> 2. What is the potential scope of use for a client certificate?
>> Global?  The origin that provided it?  Something in-between like
>> domain or domain plus subdomains?
>>
>
> Global - all domains, all applications. A common pattern, as seen on the
> CA/Browser Forum list, is to use this method to configure S/MIME
> certificates for Thunderbird, which uses the same NSS database.
>
> Any other domain could do an existence test to see if a user has such a
> certificate, by using  to create a key (which may or may not
> involve prompting; various criteria there), using
> application/x-x509-user-cert to deliver the user's cert that matches a
> chosen ("attacker") issuer string, and then doing a TLS handshake that
> requests a client certificate with the ca_names set to the attacker's
> unique fingerprint.
>
> The timing difference between the handshakes - whether or not the user has
> a matching certificate and private key - can reveal to any domain who knows
> the ca_names whether or not the user matches, at the cost of potentially
> prompting the user (if they do match).
> ___
> dev-security mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Extrapolating from telemetry

[Martin Thomson]

I want to get some very rough numbers for our entire userbase, but I
don't know how to go from "number of users who opted in to telemetry"
to "all users".  Do we have any information on the proportion of users
opt in to telemetry?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Local static analysis builds on Linux and Mac OS X

[Martin Thomson]

On Wed, Oct 14, 2015 at 6:32 PM, Gregory Szorc  wrote:
> As you stated, this helps detect errors earlier during development, which
> is a huge win. Is there a good reason configure doesn't enable the clang
> plugin by default?


Yes please.  If the checks are expensive, ac_add_options
--disable-clang-plugin sounds about right.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Please do not use the Date type in Web IDL APIs

[Martin Thomson]

On Fri, Oct 16, 2015 at 6:39 AM, Boris Zbarsky  wrote:
> You should _especially_ not create attributes of type Date.


Well, that's interesting.  I think that I might have to eat crow:
https://github.com/w3c/webrtc-pc/issues/324

I didn't read all the discussion, but what is wrong with treating Date
as a primitive type that happens to have methods?  I know that it
likely sucks to have all that custom code, but I've seen worse.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Please do not use the Date type in Web IDL APIs

[Martin Thomson]

On Fri, Oct 16, 2015 at 9:30 AM, Boris Zbarsky  wrote:
> I'm not sure what custom code you're talking about.  What exactly are you
> proposing?

Date is fundamentally just an integer when you get down to it.  Treat
it like one.  An integer value is copied when you return it, so
modifications don't affect the underlying structure.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Please do not use the Date type in Web IDL APIs

[Martin Thomson]

WFM.  I'll see what I can do about fixing RTCCertificate.  I think
that the breakage should be minimal if I just change it.

On Fri, Oct 16, 2015 at 11:44 AM, Boris Zbarsky  wrote:
> On 10/16/15 2:00 PM, Martin Thomson wrote:
>>
>> On Fri, Oct 16, 2015 at 9:30 AM, Boris Zbarsky  wrote:
>>>
>>> I'm not sure what custom code you're talking about.  What exactly are you
>>> proposing?
>>
>>
>> Date is fundamentally just an integer when you get down to it.  Treat
>> it like one.  An integer value is copied when you return it, so
>> modifications don't affect the underlying structure.
>
>
> Integer values also do structural ==, not object identity ==.  And can't be
> mutated (mutating actually just creates a new value)
>
> You seem to be arguing that Date should really be a value type in ES. That's
> an argument I'm sympathetic to, but that's not the Date we have right now.
>
> So if you want to have value type like behavior, use a value type; for now
> long long (in IDL terms; Number in JS terms) is good.  If you want to have a
> possibly-shared reference to a mutable thing, then Date makes sense.  Once
> ES grows actual value types, we can think about doing something like that
> for date return values in APIs.
>
>
> -Boris
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: WebUSB

[Martin Thomson]

On Fri, Dec 4, 2015 at 8:04 PM, Robert O'Callahan  wrote:
> However, for USB the "Web driver" approach seems better than that, to me.
> It makes it easy to update the vendor library to fix security bugs and
> update the API. If the Web API is baked into the device firmware that's a
> lot harder.

The only concession needed in option 4 would be some way of indicating
what was safe to use, which might be conditioned on origin.
Management of that might even be mediated by the browser rather than
the firmware.  In a sense, this is a more general form of option 1 if
the vendor's origin is whitelisted.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: WebUSB

[Martin Thomson]

On Thu, Dec 10, 2015 at 5:17 PM, Robert O'Callahan  wrote:
> On Fri, Dec 4, 2015 at 4:56 PM, Eric Rescorla  wrote:
>
>> (4) Have the APIs hidden behind access controls that need to be enabled by
>> an extension
>> (but a trivial one). Perhaps you think this is #2.
>>
>
> I realized I don't understand exactly what this means.


The basic idea is similar to what we are currently doing for
screensharing.  Maintain a whitelist of sites that can access USB (or
origin+device pairs). The extension/addon just adds a set of things to
this whitelist.  And yes, because this is installed in the same way
that the worst of our addons is installed, we gain the same (limited)
protections that we get from the addons, including the ability to
block the addon if it turns out to be bad.

For the record: I think is an awful solution, but it might work here.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement & ship: support for a subset of -webkit prefixed CSS properties & features

[Martin Thomson]

On Thu, Dec 31, 2015 at 5:40 PM, Daniel Holbert  wrote:
> Summary:
>   A good chunk of the web today (and particularly the mobile web)
> effectively relies on -webkit prefixed CSS properties & features. We
> wish we lived in a world where web content always included
> standards-based fallback (or at least multiple-vendor-prefixed
> fallback), but alas, we do not live in that world.  To be successful at
> rendering the web as it exists, we need to add support for a list of
> frequently-used -webkit prefixed CSS properties & features.

This is definitely worth doing.

If we intend to continue to support these, and particularly if we
anticipate more prefixed rules in future, I think that it would be
worthwhile providing developers with a more visible notice regarding
their status.  Something like the deprecation warning we use for DOM
APIs [1] could be useful.  Otherwise, I worry that the warnings will
go unnoticed.

[1] 
https://dxr.mozilla.org/mozilla-central/rev/22f51211915bf7daff076180847a7140d35aa353/dom/base/nsDocument.cpp#10354
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement & ship: support for a subset of -webkit prefixed CSS properties & features

[Martin Thomson]

On Fri, Jan 1, 2016 at 8:15 AM, Daniel Holbert  wrote:
>  (3) False positives: There are many "legitimate" ways that authors can
> use prefixed properties

Yep, you convinced me with this.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Feedback needed on proposal to add a web primitive for queuing microtasks

[Martin Thomson]

Well, if khuey ever got into splitting the event loop, we might be
able to make progress on other tasks, but as far as I can see, detect
and throw is probably the best option.

On Thu, Jan 14, 2016 at 8:44 PM, David Rajchenbach-Teller
 wrote:
> I also think that this makes sense. Can we already start thinking about
> countermeasures, though?
>
> It looks to me that catching a long-running/infinite microtask loop is
> much easier to detect and interrupt than a long-running sequential loop.
> However, if we wish to pause a page with such a microtask loop to
> display some UX, trigger a breakpoint or even to leave some CPU to other
> pages in the same process, is there anything specific we need to do to
> guarantee that no network/user input/layout/apz... can be processed
> during the interrupt?
>
> Cheers,
>  David
>
> On 14/01/16 00:35, Ehsan Akhgari wrote:
>> I think this makes sense.
> ___
> 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: How to remove #ifdef XP_MACOSX in xul files?

[Martin Thomson]

sed -i~ -e '/#ifdef XP_MACOSX/d' xul files

I think that we need more information on what it is that you intend to
do if we are to make a sensible suggestion.

On Mon, Feb 1, 2016 at 5:23 PM, Yonggang Luo  wrote:
> How to remove #ifdef XP_MACOSX in xul files?
> ___
> 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: Does SSE2 usage still need to be conditional?

[Martin Thomson]

On Tue, Feb 2, 2016 at 10:42 AM, Milan Sreckovic  wrote:
> Surprisingly, perhaps, there are a lot of people using Firefox on 32-bit 
> Windows.  If I’m reading the data correctly, more than half.  A small 
> percentage of those don’t have SSE2.

Do we have any, say telemetry, that would move this from speculation
into numbers?  Sure, numbers aren't necessarily perfect, but I'm sure
that they would help.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Does SSE2 usage still need to be conditional?

[Martin Thomson]

On Wed, Feb 3, 2016 at 12:54 AM, Benjamin Smedberg
 wrote:
>> Do we have any, say telemetry, that would move this from speculation
>> into numbers?  Sure, numbers aren't necessarily perfect, but I'm sure
>> that they would help.
>
> Milan is quoting numbers from telemetry data. The last time I calculated
> this was 8 months ago, but at the time our users were using an almost 50/50
> split of 32-bit Windows and 64-bit Windows. We expect that number to grow
> slowly over time with the device replacement cycle.

I'm afraid that those numbers don't answer the question that is asked,
namely: does the user have SSE2?  I suspect that a very large
proportion of users on 32-bit systems with 32-bit builds will still
have a 64-bit processor.  Far more than 48%, that is.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Does SSE2 usage still need to be conditional?

[Martin Thomson]

On Thu, Feb 4, 2016 at 2:21 AM, Milan Sreckovic  wrote:
> 99.77% of the users on all channels have SSE2 support;
> 51.7% of all users are on 32-bit Windows;
> 0.44% of all users on 32-bit Windows do not have SSE2 support.

Those numbers wouldn't justify a change to me.  When we make decisions
about what we break with TLS by disabling something that is maybe
dangerous, we try to avoid changes that break any more than 0.1% of
our population.  It looks like we are almost there, but unlike some of
the security changes, we can't just provide motivation to change [1]
because requesting a hardware change is a pretty high bar to clear.

[1] The normal process is announcements about deprecation, blog
postings about how X is or might be broken, etc...
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Returning dictionaries in WebIDL

[Martin Thomson]

I know that this is not good practice, but is there something written
down somewhere explaining why?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Returning dictionaries in WebIDL

[Martin Thomson]

Yep, thanks for that.  I somehow missed the bit where it says, very
clearly, that attributes MUST NOT be dictionaries.

I was looking for something to give someone else who doesn't like
explanations and prefers reading from the scripture.  Your explanation
matches my understanding.

BTW, there are some people who consider the fact that a dictionary
becomes outside the control of the browser to be a feature.  That is
partly why WebRTC is how it is.

On Mon, Feb 15, 2016 at 10:11 AM, Cameron McCormack  wrote:
> Martin Thomson:
>> I know that this is not good practice, but is there something written
>> down somewhere explaining why?
>
> I don’t know if it’s written down somewhere.  Using dictionary types for
> IDL attributes is forbidden by the spec, because it would mean that a
> new copy of the object would need to be returned each time the property
> were accessed.  This is the case for sequence types too, where you
> can much more obviously encourage wasteful object creation:
>
>   interface A {
> attribute sequence values;
>   };
>
>   for (var i = 0; i < myA.values.length; i++) {
> …
>   }
>
> That would create a new JS Array each time around the loop.  With
> dictionaries you might access a couple of properties from the return
> value of the getter property and have similar issues:
>
>   dictionary D {
> double x;
> doubly y;
>   };
>
>   interface A {
> attribute D d;
>   };
>
>   Math.sqrt(myA.d.x * myA.d.x + myA.d.y * myA.d.y);
>
> This would create four copies of the JS object for the dictionary.
>
> Another point is that these sequence and dictionary objects can’t be
> monitored for changes, so for example you couldn’t write a spec that
> required the browser to do something when you assign to myA.d.x since
> that’s just a plain data property on the object returned from d.  So for
> APIs where you do want to notice property value changes like this,
> you’ll need to use interfaces, and for array-ish things we’ve now got
> FrozenArray, which is an array reference type (as opposed to
> sequence’s (and dictionaries’) pass-by-value behaviour).
>
> We don’t currently have a type that means “reference to an object that
> has a particular shape defined by a dictionary”.  So for now if you
> really want an API that allows
>
>   myA.d = { x: 1, y: 2 };
>
> where the A object either immediately, or later, inspects the values on
> the object, then you have to use “object” as the type and invoke the
> type conversions or do the JS property getting in the spec yourself.
>
> --
> Cameron McCormack ≝ http://mcc.id.au/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Presto: Comparing Firefox performance with other browsers (and e10s with non-e10s)

[Martin Thomson]

On Mon, Feb 15, 2016 at 12:30 PM, Valentin Gosu  wrote:
>> Thumbnails, or columns on the right for each selected browser with
>> median (or mean), with the best (for that site) in green, the worst in
>> red would allow eyeballing the results and finding interesting
>> differences without clicking on 100 links...  (please!)  Or to avoid
>> overloading the page, one page with graphs like today, another with the
>> columns I indicated (where clicking on the row takes you to the graph
>> page for that side).
>>
>
> What I noticed is that pages with lots of elements, and elements that come
> from different sources seem to have a higher variability. So pages such as
> flickr, with lots of images with various sizes, or pages that load various
> ads.

You currently graph every test result, sorted.  This can be reduced to
a single measurement.  Here I think that you can take the 5th, 50th
and 95th percentiles (mean isn't particularly interesting, and you
want to avoid extreme outliers).  The x axis can then be used for
something else.  The obvious choice is that you turn this into a bar
graph with browsers on that x-axis.  You could probably remove the
browser selector then.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Presto: Comparing Firefox performance with other browsers (and e10s with non-e10s)

[Martin Thomson]

On Mon, Feb 15, 2016 at 1:12 PM, Martin Thomson  wrote:
> On Mon, Feb 15, 2016 at 12:30 PM, Valentin Gosu  
> wrote:
>>> Thumbnails, or columns on the right for each selected browser with
>>> median (or mean), with the best (for that site) in green, the worst in
>>> red would allow eyeballing the results and finding interesting
>>> differences without clicking on 100 links...  (please!)  Or to avoid
>>> overloading the page, one page with graphs like today, another with the
>>> columns I indicated (where clicking on the row takes you to the graph
>>> page for that side).
>>>
>>
>> What I noticed is that pages with lots of elements, and elements that come
>> from different sources seem to have a higher variability. So pages such as
>> flickr, with lots of images with various sizes, or pages that load various
>> ads.
>
> You currently graph every test result, sorted.  This can be reduced to
> a single measurement.  Here I think that you can take the 5th, 50th
> and 95th percentiles (mean isn't particularly interesting, and you
> want to avoid extreme outliers).  The x axis can then be used for
> something else.  The obvious choice is that you turn this into a bar
> graph with browsers on that x-axis.  You could probably remove the
> browser selector then.

Oh, to be a little less obtuse, I think that means that you get a
column graph with error bars on each column.  Your x-axis is by
browser (and version) with two columns for each (first view and
refresh).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: DOM Push API in Firefox for Android

[Martin Thomson]

This is great.

As I said elsewhere, I don't think that we can pref this on until bug
1252650 lands.  It turns out that "gecko not running" is pretty much
the only interesting state for push.

On Thu, Mar 3, 2016 at 5:06 AM, Nicholas Alexander
 wrote:
> Summary: "The Push API gives web applications the ability to receive
> messages pushed to them from a server, whether or not the web app is in the
> foreground, or even currently loaded, on a user agent. This lets developers
> deliver asynchronous notifications and updates to users that opt in,
> resulting in better engagement with timely new content."
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1206207
>
> Link to standard: https://w3c.github.io/push-api/
>
> Platform coverage: Firefox for Android.  This is already shipping in
> Firefox Desktop:
> the Firefox Desktop intent to implement message is at [1] and the intent to
> ship message is at [2].
>
> Estimated or target release: Firefox for Android 47 is desired.  48 seems
> most likely.
>
> Preference behind which this will be implemented: this is both behind a
> build flag (due to Android-specific permission changes, etc) and behind
> dom.push.enabled.
>
> DevTools bug: this should be covered by the Desktop devtools ticket:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1214248.
>
> Best,
> Nick
>
> [1] https://lists.mozilla.org/pipermail/dev-platform/2014-July/005828.html
> [2]
> https://groups.google.com/d/msg/mozilla.dev.platform/vU4NsuKhTOY/wc2PviRUBAAJ
> ___
> 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: Proposing preferring Clang over GCC for developer buidls

[Martin Thomson]

On Thu, Mar 3, 2016 at 10:45 AM, Mike Hommey  wrote:
> More importantly, changing the official toolchain has implications on
> performance.

Without any real evidence for this, I'm told that GCC still produces
better (i.e., faster) output.  But we could switch try builds to clang
if the time savings are that good.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Are we in favour of implementing the client hints header?

[Martin Thomson]

On Wed, Mar 9, 2016 at 6:42 AM, Jonas Sicking  wrote:
> I know there's some concern that always sending CH with all requests
> would generate too much header traffic which would be wasteful.


We could limit the feature to h2.  (Which would also address the other
request, which is to limit this to https://)

I'm surprised that the CORS interaction hasn't been raised:
https://github.com/httpwg/http-extensions/issues/141
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: W3C WebAppSec credentialmanagement API

[Martin Thomson]

On Fri, Mar 11, 2016 at 5:56 AM, Axel Nennker  wrote:
> no password generation help by the UA

I agree with MattN here, not doing this eliminates much of the
advantage of having a password manager.  Or do you have a plan to rely
on sites doing that with CredentialContainer.store()?  That doesn't
sound optimal to me.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: W3C WebAppSec credentialmanagement API

[Martin Thomson]

On 12 Mar 2016 7:28 PM, "Anne van Kesteren"  wrote:
> It should be identical to password manager integration.

But it is not,  though I suppose that a password manager might be exploited
to store state. I hope that isn't possible... (note to self, attempt this
attack)

> > In that case, credentials stored by a site should last no longer than
> > cookies. Credentials created by a user maybe can live longer.
>
> How do you distinguish the two if the access is through a UI-mediated API?

If credentials created in response to a `get()` call are stored at the
point they are created, you could treat calls to `store()` very
differently. Maybe. If the intent is to use a password manager, see
Richard's earlier mail.

> If we think this API should have no more power than storage/cookies,
> there's not much point in having this API.

Yes, the source of my concerns, right there. Sure, the fig leaf might allow
us to convince ourselves that we aren't creating a tracker that trumps the
rest.

If we are creating something that is somehow greater out of the framework
this provides (FIDO), then that is useful. But the stepping stone we are
being offered on that path looks suspicious. Why not go straight for the
real prize?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: W3C WebAppSec credentialmanagement API

[Martin Thomson]

Now that is a frightening observation. Is this creating a more persistent
(pernicious?) tracking mechanism?

In that case, credentials stored by a site should last no longer than
cookies. Credentials created by a user maybe can live longer.
On 12 Mar 2016 04:41, "Anne van Kesteren"  wrote:

> On Fri, Mar 11, 2016 at 6:08 PM,   wrote:
> > That does raise the question, however, of how such a credential differs
> from, say:
> >
> > * A cookie
> > * A random nonce in localStorage/IDB
> > * A non-extractable WebCrypto key
>
> The idea is that these are all less persistent. When you clear
> storage/cookies, you don't delete password manager entries. (Which is
> also why store() requires UI, if I remember correctly.)
>
>
> --
> https://annevankesteren.nl/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: W3C WebAppSec credentialmanagement API

[Martin Thomson]

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

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

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

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

Re: Old XUL, deprecated Error Console

[Martin Thomson]

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

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

Re: Announcing MozillaBuild 2.2.0 Release

[Martin Thomson]

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

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

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

[Martin Thomson]

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

And a lot more testing.

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

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

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

[Martin Thomson]

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

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

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

[Martin Thomson]

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

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

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

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

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

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

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

[Martin Thomson]

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

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

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

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

Intent to (sort of) unship SSLKEYLOGFILE logging

[Martin Thomson]

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

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

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

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

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

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

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

[Martin Thomson]

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

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

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

[Martin Thomson]

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

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

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

Re: Generating Visual Studio project files by default

[Martin Thomson]

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

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

Re: Proposed W3C Charter: Web of Things Interest Group

[Martin Thomson]

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

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

Re: MXR permanently offline, please transition to DXR

[Martin Thomson]

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

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

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

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

[Martin Thomson]

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

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

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

[Martin Thomson]

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

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

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

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

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

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

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

[Martin Thomson]

Sounds like a good plan.

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

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

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

[Martin Thomson]

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

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

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

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

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

[Martin Thomson]

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

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

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

Re: Proposed W3C Charter: Web of Things Working Group

[Martin Thomson]

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


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

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

Re: Proposed W3C Charter: Web of Things Working Group

[Martin Thomson]

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

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

Re: Proposed W3C Charter: Web of Things Working Group

[Martin Thomson]

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

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

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

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

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