Re: Intent to Implement: canvas-imagedata permission

[Gervase Markham]

On 10/01/18 18:40, Tom Ritter wrote:
> This proposal is that. Add a permission 'canvas-imagedata' that will
> return 'granted' when Resist Fingerprinting mode is disabled, and
> 'prompt' when RP is enabled and appropriate.

As this is basically a "is RF turned on?" flag, why not just call it
that? Or are we going to add more permissions for any other things about
RF mode that people might want to query?

Gerv

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

Re: Password autofilling

[Gervase Markham]

On 01/01/18 20:08, Jonathan Kingston wrote:
> A recent research post[1] have highlighted the need for Firefox to disable
> autofilling of credentials. The research post suggests web trackers are
> using autofilling to track users around the web.

Autofill is restricted to same-domain (roughly) so how can they track
users "around the web"?

Other than not being cleared when cookies are cleared, how is this
technique more powerful than a cookie containing one's email address?

Autofill is an extremely, extremely convenient browser function, and the
fact that Firefox's current implementation doesn't always do the right
thing (e.g. offering me 3 choices of username and, when I pick one, 3
choices of password rather than autofilling the one which matches the
username, ) is a source of regular frustration. Let's not break
the usability more.

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

Re: Intent to unship: navigator.registerContentHandler()

[Gervase Markham]

On 03/01/18 15:15, Jonathan Kingston wrote:
> I am suggesting the removal of navigator.registerContentHandler
> 
> API used to register a web page to handle content types.

I'm sure unshipping it is the right thing to do, but it's very sad. :-(
Allowing web pages to register for content types and protocols seems
kind of important if you want the web to have the capability of
seamlessly replacing desktop and mobile apps.

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

Re: Intent to remove Ambient Light and Proximity sensor APIs

[Gervase Markham]

On 18/12/17 18:25, Tantek Çelik wrote:
> Do you know of a specific (URL?) mobile-device-capable (which
> device(s)?) WebRTC-based audio-calling webapp that works today? I
> would be very interested in testing it out.

appear.in, which supports both audio and video calling via WebRTC, works
in Firefox for Android, although performance is not awesome on my Z3C
Compact.

It does not blank the screen when you place the device to your ear.

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

Re: Intent to remove Ambient Light and Proximity sensor APIs

[Gervase Markham]

On 17/12/17 15:29, Jonathan Kingston wrote:
> I am suggesting the removal of both Ambient Light and Proximity Sensor APIs
> via a preference so we can ensure there is no adverse impact to the web
> with a quick mitigation if needed.

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

That seems sad.

Gerv

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

Re: Stylesheet wait timeout?

[Gervase Markham]

On 31/08/17 19:08, Boris Zbarsky wrote:
> The symptoms you observe sound like (A) is happening, possible from an
> extension or our browser UI...  If you have a link to a specific url
> that reproduces for you, especially in a clean profile, that would be
> pretty useful.  This is usually pretty simple to debug when (A) happens:
> set a breakpoint on when we start layout and see what the JS stack is.
> The hard part is catching it happening.

Restarting with no extensions causes my browser to feel a whole lot
faster (I'd love to know why that is, but that's a separate issue!) but
I can't reproduce the FOUC in a few minutes of trying. :-|

I will try and gather more data.

Gerv

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

Re: Stylesheet wait timeout?

[Gervase Markham]

On 31/08/17 20:00, Michael Froman wrote:
> I’ve seen this behavior too on OSX.  I did a restart with all add-ons
> disabled and could not reproduce.  Restarted with all add-ons on, and
> can reproduce.  I narrowed it down to Ghostery.  If I disable
> Ghostery, it no long appears to happen for me.  YMMV.

I do not have Ghostery, although I do have quite a few other addons.

Gerv

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

Re: Stylesheet wait timeout?

[Gervase Markham]

On 31/08/17 18:45, Chris Peterson wrote:
> Gerv, do you have Stylo enabled? Even if you did not flip the pref
> (layout.css.servo.enabled), you might be in the Stylo experiment for
> Nightly users. Check about:support for "Stylo".

about:support says "Stylo: true (enabled by default)".

Gerv

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

Re: Stylesheet wait timeout?

[Gervase Markham]

On 18/08/17 12:11, Gervase Markham wrote:


Whereas what I meant to say was:

Have we changed the timeout recently regarding how long Firefox waits
for a stylesheet before rendering the page? In the past few weeks I've
seen many more instances of a page loading unstyled, then re-laying out
a second later with style. It happens for me quite a bit on xkcd.com,
but there are other pages too.

I think we may have set the timeout a bit low, because the result is ugly.

I'm using Nightly 57.0a1 (2017-08-30) (64-bit) on Ubuntu 16.04 LTS.

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

Stylesheet wait timeout?

[Gervase Markham]

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

Re: IDNA processing

[Gervase Markham]

On 18/05/17 14:14, Anne van Kesteren wrote:
> That's fairly non-specific, unless you really mean that you don't want
> "A" lowercased.

Well, yes, as you note, with UTS#46 or whatever it is.

> I don't think it's that big, there's plenty of other things disallowed
> that we should always be able to find something, if it comes to that.

Then I think whatever you decide about how to deal with ASCII fast paths
is fine. :-)

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

Re: IDNA processing

[Gervase Markham]

On 12/05/17 08:46, Anne van Kesteren wrote:
> For about five years I've been trying to figure out the IDNA algorithm
> that a) browsers follow and b) browsers want to follow, but I've not
> had much luck thus far getting folks to reply. E.g.,
> https://lists.w3.org/Archives/Public/www-archive/2017Feb/0006.html
> went largely unaddressed.

Well, you generally know my opinion :-) IDNA 2008 non-transitional.

> One big difference between http://www.unicode.org/reports/tr46/ and
> browsers is how ASCII is handled. Per UTS #46 ASCII is handled the
> same as non-ASCII. However, in browsers ASCII takes a "fast path" and
> skips the ToASCII algorithm. YouTube now depends on that (it has CDN
> domains with hyphens in the third and fourth position, as reported at,
> e.g., https://github.com/nodejs/node/issues/12965).

ISTM that the 3rd/4th placed hyphens were banned so the domain name
system had an extension mechanism, and that was used for IDNA (xn--). If
we allow domains of that form, we no longer have that extension
mechanism. The question is, how big a loss is that?

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

Re: Ambient Light Sensor API

[Gervase Markham]

On 25/04/17 16:46, Eric Rescorla wrote:
> This suggests that maybe we could just turn it off

It would be sad to remove a capability from the web platform which
native apps have. Surely we can avoid this problem without being so
drastic? Is it right that one key use of this sensor is to see if the
person has the phone up against their face, right? If so, reducing to a
small number of quantized levels would do the trick.

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

Re: Better download security through browsers

[Gervase Markham]

On 24/03/17 17:12, Gregory Szorc wrote:
> This got me thinking: why doesn't the user agent get involved to help
> provide better download security? What my (not a web standard spec author)
> brain came up with is standardized metadata in the HTML for the download
> link (probably an ) that defines file integrity information. 

https://www.gerv.net/security/link-fingerprints/ .

The SRI team apparently didn't cover  in their first version because
it was in some way more complicated to get right than the tags they did
cover. But perhaps they remain open to doing so in a future version?

Gerv

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

Re: ANN: Default bug view for BMO changed today!

[Gervase Markham]

On 02/03/17 17:11, Byron Jones wrote:
> set "Use absolute format instead of relative time when viewing a bug"

Or if you just want to see it, mouse over and read the tooltip.

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

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

[Gervase Markham]

On 03/01/17 17:17, Stephen A Pohl wrote:
> We are gathering ideas for possible use cases of the Touch Bar on the
> new MacBookPro and would like to hear from you! What would improve your
> workflow? What would help our users?

When the developer tools are open, change the Touch Bar to give quick
access to various Developer functions? I can imagine a web-developer
feeling supercharged with one-touch console, or one-touch inspect, or
one-touch JS toggle.

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

Re: Async scrollbar dragging enabled on Nightly

[Gervase Markham]

On 19/12/16 19:16, Botond Ballo wrote:
> The third one, bug 1251617, is that a quick drag on a long page
> results in checkerboarding. 

Why do we paint a checkerboard rather than the default single background
colour of the page?

Checkerboarding makes it really clear Firefox can't keep up. The
background colour just makes it seem like the content hasn't rendered
yet, which seems less jarring as people see that all the time on page load.

Gerv

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

Re: Intent to ship: NetworkInformation

[Gervase Markham]

On 16/12/16 20:25, Jason Duell wrote:
> So a switch that toggles the "network is expensive" bit, plus turns off
> browser updates, phishing list fetches, etc?  I can see how this would be
> nice for power users on a tethered cell phone network.  One issue would be
> to make sure users don't forget to turn it off (and never update their
> browser again, etc).  Maybe it could time out.

We already do network change detection now, ISTR; could we pop a
doorhanger when we get a network change event, of the form of something
like "maintain 'expensive data' status Y/N?"...?

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

Re: Intent to ship: NetworkInformation

[Gervase Markham]

On 15/12/16 14:20, Daniel Stenberg wrote:
> Looking at that collection of existing user, basically all of them want
> the user to anser this question:
> 
>  "Use expensive traffic (y/n)"

And this should be an OS-level switch which the browser and other apps
both respect and reflect. Doesn't Android already have a "background
data" switch?

If I'm on the train wifi, I want to turn off all unnecessary traffic,
both to show love to other users, and because it'll make what I'm
actually focussed on doing faster. Now is not the time to run a backup.
I'd love such a switch on my laptop which my apps and web pages respected.

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

Re: RSSOwl

[Gervase Markham]

Hi Jonathan,

On 22/11/16 08:30, Jonathan Moore wrote:
> I was wondering if the RSSOwl feed reader could become part of the
> Mozilla foundation?
> Anyone have any thoughts?

Well, Mozilla very rarely adopts projects started outside itself in this
way. Perhaps Rust is the only example I can think of offhand. To be
adopted by Mozilla, a project would need to reach a very high bar of
potential impact on the web. As a user of RSSOwl myself, I'm not sure it
would meet that.

But why? Why do you think this is a good idea?

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

Re: Windows XP and Vista Long Term Support Plan

[Gervase Markham]

On 24/10/16 18:44, Eric Rescorla wrote:
> This seems to assume facts not in evidence, namely that people will stop
> using those
> machines rather than just living with whatever the last version we updated
> them to.

I think you've misread what I said. I said that if it turns out that
(for example) the entire web moves to require TLS 1.3 final and ESR 52
doesn't support it, and as a result these old machines can no longer
browse the secure web, and therefore people decide they can't use them
for web surfing any more - that's a feature, not a bug, and it's not
something we should worry about happening. Same goes for any other
TLS/cert-related requirement which "breaks" their browsing experience.

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

Re: Intent to restrict to secure contexts: navigator.geolocation

[Gervase Markham]

On 24/10/16 21:12, Ehsan Akhgari wrote:
> I suppose we can use the HTTPS Everywhere ruleset for this purpose,
> assuming it's something we can (and want to) ship?

Shipping this seems like a heavyweight way to deal with the deprecation
of the geolocation permission. If we want to implement HTTPS Everywhere,
that's another discussion entirely. (I think Brave ships it.)

Gerv

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

Re: Intent to restrict to secure contexts: navigator.geolocation

[Gervase Markham]

On 22/10/16 18:12, Ehsan Akhgari wrote:
> Have we considered doing something here to help the user when we block
> this API?  For example, we could check to see whether the site has a TLS
> version 

If there were a reliable way to do this, HTTPS Everywhere would be a
whole lot easier to write and maintain :-) AIUI, it's not as simple as
adding an extra s to the protocol, doing a fetch and seeing if the
response is 2xx.

Gerv


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

Re: Intent to restrict to secure contexts: navigator.geolocation

[Gervase Markham]

On 22/10/16 18:12, Ehsan Akhgari wrote:
> Have we considered doing something here to help the user when we block
> this API?  For example, we could check to see whether the site has a TLS
> version 

If there were a reliable way to do this, HTTPS Everywhere would be a
whole lot easier to write and maintain :-) AIUI, it's not as simple as
adding an extra s to the protocol, doing a fetch and seeing if the
response is 2xx.

Gerv

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

Re: Windows XP and Vista Long Term Support Plan

[Gervase Markham]

On 22/10/16 10:16, keithgallis...@gmail.com wrote:
> My concern is that by killing digital certificate updates and TLS
> updates, still in use machines whose main purpose is Internet access
> are essentially bricked.

This is a feature, not a bug. If those machines shouldn't be on the
Internet, and things happen which keep them off the Internet, then hooray.

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

Re: Want to learn TLS certificate verification best practices

[Gervase Markham]

Hi Ben,

This question might be better off in mozilla.dev.tech.crypto.

On 30/09/16 23:00, Ben Cottrell wrote:
> I'm working on an (unfortunately closed-source) project that needs
> to closely approximate the behavior of an actual web browser, in
> the limited scope of making HTTPS connections and accurately warning
> about certificate problems.

You know about:
https://www.ssllabs.com/ssltest/
right? It seems like they have already done all the work you are
planning to do, including handshake simulation.

> 1. In as much detail as possible, what steps does Firefox take to
>verify certificates? If there's a formal engineering spec that
>describes the whole process, I'd love a pointer to it.

No, I don't think so, sorry. Read the code :-|

>Specifically, I'm interested in questions like: Does Firefox even
>bother with "traditional" CRLs, 

No, it doesn't.

> or does it rely entirely on OCSP
>and/or stapling from the server? What X.509 extensions does it pay
>attention to on the certificates? Does Firefox implement the
>entirety of RFC5280 section 6 or does it omit things like policy
>mapping and permitted subtrees? Does it use Authority Key
>Identifier / Subject Key Identifier, as the RFC suggests, *only* in
>cases where the issuer/subject DNs are ambiguous, or does it treat
>the key identifiers (if present) as the primary source of truth?

Many of these are questions about NSS, the security library we use,
hence my suggestion of asking elsewhere.

> 2. How bad is OpenSSL's certificate-verifying behavior, really? I know
>you folks felt like you had to write mozilla::pkix from scratch to
>get the quality you needed. And it's true that I haven't yet tried
>to make OpenSSL do OCSP, so I'm not sure yet how hard that will be.

I don't think just pinching OpenSSL's library was ever an option, but I
wasn't deep in those technical discussions. We don't use OpenSSL in
Firefox at all.

> I'd also be happy with pointers to best-practices type documents that
> you folks trust. What did the people who wrote mozilla::pkix read, as
> preparation for that project? 

That project was mostly coded by Brian Smith, who no longer works for
Mozilla, but can be found quite easily:
https://github.com/briansmith

Gerv

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

Re: Report your development frustrations via `mach rage`

[Gervase Markham]

On 09/08/16 08:57, Chris Mills wrote:
> mach issue
> mach complain
> mach complaint
> mach feedback? (does it have to be negative, necessarily?)

mach itbetter ?
mach animprovement ?

:-)

Gerv


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

Re: Owner for Commit Access Policy

[Gervase Markham]

On 04/08/16 16:22, Hal Wine wrote:
> On Thu, Aug 4, 2016 at 1:48 AM, Gervase Markham  <mailto:g...@mozilla.org>> wrote:
> 
> I had a few abortive goes at this a few years ago; it's an enormous
> effort to get everyone on the same bandwagon, and just leads to the
> creation of bureaucracy for no value. Let's not try it again. 
> 
> Actually, there are some modern attempts at this - times have changed.

I'm not sure any of the things you name amount to an attempt to write a
single policy for all Mozilla repos governing who can check in or not; I
accept that there have been more scope-limited efforts, of course.

> But I
> agree with you that having a formal policy for Firefox, and any repos
> which are upstream of it, makes sense. Knowing who can check in to a
> codebase which gets shipped to hundreds of millions of people is a good
> idea.
> 
> Since key upstream repos are now on GitHub (e.g Rust), this really means
> we need a plan that covers GitHub, imo.

A very fair point. (Although it need not cover all of our Github.)

> As is often the case, these "nice to haves" are "underfunded mandates"
> until something happens. There are a few of us who keep trying to push
> the rock up the hill in between the events that get everyone's attention.

:-) It's one of those "buying insurance" things - if we don't do this,
perhaps nothing bad will happen, but perhaps something will, and it'll
be much worse for not having done it.

Gerv

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

Re: Owner for Commit Access Policy

[Gervase Markham]

On 04/08/16 06:06, Gregory Szorc wrote:
> I'm going to say something that might be a bit contentious: I think a
> single commit access policy for all of Mozilla reflects the needs of
> Mozilla from several years ago, not the needs of Mozilla today. The world
> has changed. Mozilla has changed. The policy was written before distributed
> version control was popular, before services like GitHub.

I don't think that's contentious; I think it's a totally accurate
assessment :-)

> The reality of today is that the "Mozilla Commit Access Policy" is
> effectively the "Firefox Commit Access Policy."

Yep. And we should probably rename it as such.

> I'm not sure how formal we want to be on a commit policy that attempts to
> govern all of Mozilla and/or that governs less established projects or
> projects outside the Firefox umbrella.

I had a few abortive goes at this a few years ago; it's an enormous
effort to get everyone on the same bandwagon, and just leads to the
creation of bureaucracy for no value. Let's not try it again. But I
agree with you that having a formal policy for Firefox, and any repos
which are upstream of it, makes sense. Knowing who can check in to a
codebase which gets shipped to hundreds of millions of people is a good
idea.

Gerv

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

Re: Triage Plan for Firefox Components

[Gervase Markham]

On 12/04/16 21:01, Mark Côté wrote:
> Meant to reply to this earlier... BMO has a User Story field that sounds
> like it does exactly what you want.  It's an editable field that keeps
> history (admittedly not in an easy-to-read way, but that could be
> improved).  Despite the name of the field, I've found it useful for
> summarizing the current state of the discussion in the bug (sometimes
> along with the "obsolete" comment tag).

If the manager of the Bugzilla dev team is 'abusing' this field in this
way, perhaps it is indeed time for it to be relabelled - or for us to
finally fix bug 540:

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

Gerv

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

Re: Triage Plan for Firefox Components

[Gervase Markham]

On 01/04/16 15:51, Mike Hommey wrote:
> Bug status is currently, IMHO, completely misused and thus useless:
> - people with editbug capability file as NEW by default. Why should a bug
>   I file in a component I'm not working on (because I noticed a bug
>   in Firefox) be NEW?
> - there is a long tail of bugs assigned to people that are not being worked
>   on (I should know, I have a lot of those, shame on me)
> 
> So it feels to me triage should replace/subsume it in some way.

I suspect they want to add a new field because changing bug statuses
seems like a massive change. Which it would be. However, not doing it
will leave us with two workflow widgets in Bugzilla instead of one, with
all the ambiguity that brings. In the long term, I see pain here.

If Bugzilla supported per-product workflow that might help. Is it worth
investing the BMO-hacking resources for this plan into that?

Gerv

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

[Gervase Markham]

On 08/03/16 06:22, Andrew Overholt wrote:
>  Implement Client-Hints HTTP header
> https://bugzilla.mozilla.org/show_bug.cgi?id=935216

Well, we are in favour of adaptive content, progressive enhancement,
responsive images in HTML, and feature detection. The question is
whether we think that these things cover all the use cases or not.

Do we know whether anyone's using this in Chrome?

Gerv


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

Re: APNG and Accept-Encoding

[Gervase Markham]

On 22/02/16 14:58, Xidorn Quan wrote:
> But older Firefoxes go away fairly quickly, so I wouldn't consider
> this as a valid reason blocking us moving forward.

I'm not sure that's as true as we'd like it to be :-|

Gerv

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

Re: APNG and Accept-Encoding

[Gervase Markham]

On 21/02/16 14:30, maxste...@gmail.com wrote:
> Here's interesting live example, this website provides lots of
> animated cursors to download, and they show them online as APNGs in
> Firefox and Safari, and as GIFs in other browsers. Cursor's ANI
> format is 32bit and animated, but it's not supported by browsers, so
> they have to convert.
> 
> One such set: 
> http://www.rw-designer.com/cursor-set/blue-white-reloaded
> 
> I think they decide server-side.

If they show them as APNGs in Firefox, that means they are not using the
Accept: header to choose what to send. If Firefox started sending an
Accept: value for APNG, they would continue to need to sniff server-side
anyway, in order to support older Firefoxes.

Gerv


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

Re: APNG and Accept-Encoding

[Gervase Markham]

On 18/02/16 07:45, Jeff Muizelaar wrote:
> Is there a response to the criticism of Accept outlined here:
> https://wiki.whatwg.org/wiki/Why_not_conneg#Negotiating_by_format

As Guardian of the Accept Header, that would be my question too.

Using Accept to detect APNG support will never be reliable because not
everyone who has shipped it sends the header. So you have to detect
support by sniffing anyway. So what does Accept give you, other than the
promise of perhaps being able to rely on it in 10 years time if nothing
else goes wrong?

Gerv

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

Re: Bug Program Next Steps

[Gervase Markham]

On 30/01/16 00:45, Emma Humphries wrote:
> This is a terminal state for a NEW bug. We acknowledge the bug exists, it
> affects people, but it is not important enough to warrant working on it.
> The team will review and accept patches from the community for this bug
> report.

Without wanting to pile on, as I know others have concerns about other
parts of this plan, and without wanting to say it's only you doing this,
but: can we all please stop using the word "community", as this sentence
implies, as "people outside the paid 'team' who get to work on things
which are not important enough for the important people to spend their
time on"? Community is not the antonym of "team", nor is it the antonym
of "employee".

The original message was about the world we are working towards. In the
world I'm working towards, every team includes people we pay and people
we don't, on an equal basis, and we are all one community.

Thank you :-)

Gerv

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

Re: Dan Stillman's concerns about Extension Signing

[Gervase Markham]

On 27/11/15 15:50, Gavin Sharp wrote:
> No, that's not right. There's an important distinction between
> "finding malicious JS code" and "finding _all_ malicious JS code". The
> latter is impossible, but the former isn't.
> 
> Proving "the validator won't catch everything" isn't particularly
> relevant when it isn't intended to, in the overall add-on signing
> system design.

If the validator is open source, which it is, then anyone who wants to
get code past it can just use it as an oracle until it passes.
Therefore, given malicious intent, I would expect the validator not to
catch _anything_.

We need to base the system on reputation, not on code scanning. We can
either hand out code signing certs and do the reputation based on them,
or have an _automated_ code signing portal and tie the reputation to the
accounts on that. As cert revocation doesn't work well, the latter seems
to offer much more control and to be the better plan.

If we accept, as you seem to, that no system can catch everything, then
I think the right "not catching everything" is the risk of AMO
high-reputation account compromise. Having that as your weak spot allows
the building of a system where people like Dan, who have high
reputation, can automatically sign as many builds as they want and,
fundamentally, keep shipping products. Which is what we all want.

Gerv

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

Re: Dan Stillman's concerns about Extension Signing

[Gervase Markham]

On 26/11/15 17:13, Mike Hoye wrote:
> Stillman wrote some new code and put it through a process meant to catch
> problems in old code, and it passed. That's unfortunate, but does it
> really surprise anyone that security is an evolving process? That it
> might be be full of hard tradeoffs? There is a _huge_gap_ between "new
> code can defeat old security measures" and "therefore all the old
> security measures are useless". 

But the thing is, members of our security group are now piling into the
bug pointing out that trying to find malicious JS code by static code
review is literally _impossible_ (and perhaps hinting that they'd have
said so much earlier if someone had asked them).

You can evolve your process all you like, but if something is
impossible, it's impossible. And not only that, but attempting it seems
to be causing significant collateral damage.

> It's an even bigger step from there to
> the implication that people working on this either haven't thought about
> it already, or just don't care.

I agree with that.

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

Re: Fido U2F, two-factor authentication support

[Gervase Markham]

On 18/11/15 19:26, phow...@ccvschools.com wrote:
> This is definitely an important feature, but I'm not holding my
> breath.  I have had a lot of experience with Mozilla over the years
> and I really doubt anything will materialize in the near future.

Feeling particularly entitled today, are we?

>From the look of the bug, it seems like patches are certainly being
accepted.

Gerv


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

Re: Intent to ship: WebVR

[Gervase Markham]

On 29/10/15 17:07, vladi...@mozilla.com wrote:
>> At one point, integrating with available hardware required us to use
>> proprietary code. Is shipping proprietary code in Firefox any part of
>> this plan, or not?
> 
> No.

Awesome! :-)

Gerv


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

Re: Intent to ship: WebVR

[Gervase Markham]

On 26/10/15 19:19, Kearwood "Kip" Gilbert wrote:
> As of Oct 29, 2015 I intend to turn WebVR on by default for all
> platforms. It has been developed behind the dom.vr.enabled preference. 
> A compatible API has been implemented (but not yet shipped) in Chromium
> and Blink.

At one point, integrating with available hardware required us to use
proprietary code. Is shipping proprietary code in Firefox any part of
this plan, or not?

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

Re: Changes in chrome JS code due to ES6 global lexical scope

[Gervase Markham]

On 17/09/15 19:59, Shu-yu Guo wrote:
> ​Because ​until now, our global 'let' semantics have been identical to
> those of 'var', I have already landed a patch that mass replaces global
> 'let' with 'var' as part of bug 1202902.

I think someone should make you a "var is the new let" t-shirt...

Gerv

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

Re: Web API equivalent of nsIEffectiveTLDService / publicsuffix.org database?

[Gervase Markham]

On 10/08/15 08:22, Tim Guan-tin Chien wrote:
> The list "... changes a few times per month" [1]. What's the
> consequence of using an outdated list in the app?

It depends very much on what you are using the list for, and what
changes your copy doesn't have.

If you were using the list for setting appropriate scope for cookies,
and you missed the change which allowed top-level registrations in the
UK (so you can now get foo.uk instead of just foo.co.uk), then the
result would be that the owner of foo.uk could not set a cookie for his
entire domain in your browser. On the other hand, if you missed the
latest batch of gTLD updates, there may be no effect at all, because the
fallback rule for cookie scope is that any unknown domain is treated as
a single top-level, like .com or .net, and most of the new gTLDs work
that way anyway.

People are strongly encouraged not to bake static copies of the list
into their software.

Gerv

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

Re: Web API equivalent of nsIEffectiveTLDService / publicsuffix.org database?

[Gervase Markham]

On 09/08/15 03:10, Andrew Sutherland wrote:
> On 08/08/2015 10:00 PM, Andrew Sutherland wrote:
>> Are there any plans to surface the contents of
>> https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIEffectiveTLDService
>> from https://publicsuffix.org/ via a web-facing URI?
> 
> And of course I meant API here.  Most specifically, content-facing API.

You mean, exposed to the entire web? Or to any B2G app? Or to certified
apps? Or something else?

Gerv


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

Re: Web API equivalent of nsIEffectiveTLDService / publicsuffix.org database?

[Gervase Markham]

On 09/08/15 10:51, Anne van Kesteren wrote:
> There is https://www.w3.org/Bugs/Public/show_bug.cgi?id=25865 which is
> about more formally defining eTLDs and perhaps even exposing an API.
> However, it's unclear whether exposing an API is a good thing. eTLDs
> are used for cookies, storage boundaries in certain browsers, and
> document.domain. However, nobody is really pleased with that situation
> and wishes everything used origins instead.

I think that might be a slightly hyperbolic use of "nobody"... Origins
mean "exactly the same host and port", right? If I were the owner of a
large website or group of websites which shared state or a login, I
would not be excited about the idea of having to present that group of
websites to the world as if they were served off a single DNS name.

Gerv

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

Re: Proposed W3C Charters: Web Platform and Timed Media Working Groups

[Gervase Markham]

On 09/08/15 19:59, L. David Baron wrote:
> The Timed Media WG splits some of the media work that was happening
> in HTML (MSE, EME) into a separate group.

Do we see a risk here that this group will become captured by the
promoters of DRM, more than was possible when it was done in the HTML WG?

Gerv

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

Re: LGPL external library support in gecko

[Gervase Markham]

On 08/07/15 07:17, Kyle Machulis wrote:
> If you've had requirements for an external library with an LGPL license, we
> now have a place to put them. There's still some odd things that you have
> to do with symbol visibility to get this to work (feel free to ping me or
> hit #build on IRC if you have issues), and obviously licenses will still
> need to be vetted by gerv and added to the about:license page. This should
> make things easier to integrate overall though.

This is great, Kyle - thanks :-)

Gerv

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

Re: State synchronization - use cases?

[Gervase Markham]

At last! Hallelujah! :-)

On 26/06/15 10:38, Richard Barnes wrote:
> 1. You want every browser to have the same set of data
> 2. The data change relatively slowly (we are aiming for ~24hr deliveries)
> 
> If anyone has use cases in addition to the above, please let me know.

* The Public Suffix List.
* User Agent overrides.

Gerv


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

Re: Voting in BMO

[Gervase Markham]

On 09/06/15 23:07, Mark Côté wrote:
> I would ask, then, what the purpose of the feature is.  If we know it
> isn't used to make decisions, why use it?  The only thing I can think of
> is as a sort of "spam honeypot", to get people to not "+1" or "me too"
> bugs, but this seems strange at best and actively misleading at worst.

It used to do this job extremely well; I have no information on how true
that is today, as developers seem rather free to say "actually, we
ignore votes"...

Gerv

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

Re: Intent to implement and ship: document.execCommand("cut"/"copy")

[Gervase Markham]

On 06/05/15 19:38, Adam Roach wrote:
> action." I think this position is pretty strongly bolstered by Dave
> Graham's message about GitHub behavior: "Although IE 11 supports this
> API as well, we have not enabled it yet. The browser displays a popup
> dialog asking the user for permission to copy to the clipboard.
> Hopefully this popup is removed in Edge so we can start using JS there too."

Is that popup one time only per site, or every time?

> Basically, requiring the extra step of requiring the user to click on an
> "okay, do it" button is high enough friction that the function loses its
> value.

Yeah, I can see that. OK.

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

Re: Intent to implement and ship: document.execCommand("cut"/"copy")

[Gervase Markham]

On 06/05/15 18:36, Tom Schuster wrote:
> I think the ribbon would be really useful if it allowed the user to
> restore the previous clipboard content. However this is probably not
> possible for all data that can be stored in clipboards, i.e. files.

Which is why we wouldn't overwrite the clipboard until the permission
was granted :-)

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

Re: Intent to implement and ship: document.execCommand("cut"/"copy")

[Gervase Markham]

On 06/05/15 08:00, Tantek Çelik wrote:
> Result: loss of user data that user had put into the clipboard
> previously. This isn't possible with current DOM APIs and is a new
> vulnerability introduced by cut/copy.

Given that most text-editing applications have "undo" (if you used "cut"
originally), this strikes me as a low-level web page annoyance on a par
with auto-playing irritating music. Although perhaps a little less
discoverable as to the cause. I doubt this will be an issue in practice
- as the page doesn't get to see the data its deleting, doing so would
be pure vandalism, not worthy of an attacker who was trying to actually
accomplish something.

Gerv

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

Re: Intent to deprecate: Insecure HTTP

[Gervase Markham]

On 01/05/15 20:40, Eric Shepherd wrote:
> In my case, the situation is that I have classic computers running 1-10
> megahertz processors, for which encrypting and decrypting SSL is not a
> plausible option.

For this edge case, I would say the solution is to use a proxy, run on
one of your other (faster) computers. As noted elsewhere, that's what
jwz did to get Netscape 1.0 (which only spoke HTTP 1.0) working again.

Gerv

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

Re: Intent to deprecate: Insecure HTTP

[Gervase Markham]

On 03/05/15 03:39, Xidorn Quan wrote:
> This has been happening in the Internet in China. I would suggest you use
> "360 Secure Browser", one of the major browsers in China. They completely
> consider the experience of developers and users. Their browser allows user
> to access a website even if the website provides a broken certificate :)

Translation: their browser makes MITM attacks much easier.

Gerv


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

Re: Intent to deprecate: Insecure HTTP

[Gervase Markham]

On 01/05/15 19:02, Matthew Phillips wrote:
> You must have missed my original email:
> It's paramount that the web remain a frictionless place where creating a
> website is dead simple. 

That is not true today of people who want to run their own hosting. So
people who want "frictionless" use blogspot.com, or one of the thousands
of equivalent sites in many different jurisdictions, to say what they
want to say.

In an HTTPS future, such sites would simply provide HTTPS for their users.

Gerv


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

Re: Intent to deprecate: Insecure HTTP

[Gervase Markham]

On 24/04/15 23:06, Roger Hågensen wrote:
> On Tuesday, April 21, 2015 at 2:56:21 PM UTC+2, Gervase Markham
> wrote:
>> This makes checking in with the browser maker a necessary
>> prerequisite for secure connections. That has problems.
> 
> How so? Certificates have to be checked today as well (if they have
> been revocated or not).

Yes, and this has privacy problems too. Hence the move towards OCSP
stapling, which does not.

>>> 3. When the user later connect to a server that support automatic
>>> encryption, the browser sends a (public) session key that the
>>> server should use, this key is signed with the browser
>>> installation key, the server can verify the signature and that
>>> this key is not modified by checking the certificate server.
>> 
>> What you just built is a unique identifier for every browser which
>> can be tracked across sites.
> 
> How can this be tracked? This can be tracked just like any other
> client certificate can be tracked currently, no difference.

Right. And that's one reason why people don't use client certificates! :-)

Client certificates allow users to be tracked with 100% accuracy across
every site which requests the cert. Which is why IIRC, by default, users
are prompted in Firefox before sending a client certificate.

> DNSSEC exists and should help mitigate who you are talking to issue. 

And is not fully deployed, and certainly not where it's most needed, at
the endpoints.

> Also certificates have been falsified (didn't Mozilla just untrust
> all certificates by a certain certificate issuer recently that
> allowed fake Google.com certificates to be made?)

"Sometimes certs are misissued -> certs can never be trusted" is not
good logic.

> Also with certificates like the free ones from StartSSL the only site
> identity you can see is "identity not verified" yet the connection is
> still HTTPS. 

The domain name is the site identity for a DV certificate.

> DNSSEC enabled (does all latest browsers support that?) So one can be
> relatively sure to be talking to skuldwyrm.no without https.

Perhaps, in this one case, if Firefox checked DNSSEC, which it doesn't.
But you would have no guarantee of content integrity without HTTPS - an
attacker could alter the content during transmission.

> What I'm proposing is no worse than automatic domain verified
> certificates currently are.

Then why re-engineer the entire secure Internet just to get something
which is "no worse"?

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

Re: Intent to deprecate: Insecure HTTP

[Gervase Markham]

Very briefly:

On 21/04/15 12:43, skuldw...@gmail.com wrote:
> 1. User downloads a browser (be it Firefox, Chrome, Opera, etc.)
> securely (https?) from the official download location. 2. Upon
> installation a private key is created for that browser installation
> and signed by the browser's certificate server. 

This makes checking in with the browser maker a necessary prerequisite
for secure connections. That has problems.

> 3. When the user
> later connect to a server that support automatic encryption, the
> browser sends a (public) session key that the server should use, this
> key is signed with the browser installation key, the server can
> verify the signature and that this key is not modified by checking
> the certificate server.

What you just built is a unique identifier for every browser which can
be tracked across sites.

> 4. The server exchanges it's session key with
> the browser. 5. A secure/encrypted connection is now possible.

Except that the browser has not yet identified the site. It is important
for the user to check the site is genuine before the user sends any
important information to it.

> The benefit is that there is no server side certificates needed to
> establish a encrypted connection. 

They are needed if the user wants to have any confidence in who they are
actually talking to.

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

Re: Intent to deprecate: Insecure HTTP

[Gervase Markham]

On 16/04/15 02:13, Karl Dubost wrote:
> Definitely. The resistance in this thread is NOT about "people
> against security", but 1. we want to be able to choose 2. if we
> choose safe, we want that choice to be easy to activate.

I'd have it the other way. If you even assume choice should be possible
then:

1) We want to be able to choose
2) If we choose unsafe, we want that choice to be relatively hard to
activate.

In other words, "safe" should be the default.

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

Re: Intent to deprecate: Insecure HTTP

[Gervase Markham]

On 15/04/15 10:59, Anne van Kesteren wrote:
> HTTPS already has mixed content, we should not make it worse.

What's actually wrong with mixed content?

1) The risk of content tampering. Subresource integrity makes that risk
go away.

2) Reduced privacy. And that's why the connection would be marked as
insecure in the UI.

Gerv


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

Re: Intent to deprecate: Insecure HTTP

[Gervase Markham]

On 14/04/15 17:46, j...@chromium.org wrote:
> I just wanted to mention that regarding subresource integrity
> (https://w3c.github.io/webappsec/specs/subresourceintegrity/), the
> general consensus over here is that we will not treat origins as
> secure if they are over HTTP but loaded with integrity. We believe
> that security includes confidentiality, which that would approach
> would lack. --Joel

Radical idea: currently, the web has two states, insecure and secure.
What if it still had two states, with the same UI, but insecure meant
"HTTPS top-level, but some resources may be loaded using HTTP with
integrity", and secure meant "HTTPS throughout"?

That is to say, we don't have to tie the availability of new features to
the same criteria as we tie the HTTP vs. HTTPS icon/UI in the browser.
We could allow powerful features for
HTTPS-top-level-and-some-HTTP-with-integrity, while still displaying it
as insecure.

Gerv


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

Re: Intent to deprecate: Insecure HTTP

[Gervase Markham]

On 14/04/15 16:39, david.a.p.ll...@gmail.com wrote:
> 
>> There are already multiple sources of free publicly-trusted certificates,
>> with more on the way.
>> https://www.startssl.com/
>> https://buy.wosign.com/free/
>> https://blog.cloudflare.com/introducing-universal-ssl/
>> https://letsencrypt.org/
> 
> I think that you should avoid making this an exercise in marketing Mozilla's 
> "Let's Encrypt" initiative.

Perhaps that's why Richard took the time to make a comprehensive list of
all known sources of free certs, rather than just mentioning LE?

Gerv


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

Re: Intent to deprecate: Insecure HTTP

[Gervase Markham]

On 14/04/15 22:59, northrupthebandg...@gmail.com wrote:
> The article assumes that when folks connect to something via SSH and
> something changes - causing MITM-attack warnings and a refusal to
> connect - folks default to just removing the existing entry in
> ~/.ssh/known_hosts without actually questioning anything.

https://www.usenix.org/system/files/login/articles/105484-Gutmann.pdf

> "The first important thing to note about this model is that key
> changes are an expected part of life."
> 
> Only if they've been communicated first. 

How does a website communicate with all its users that it is expecting
to have (or has already had) a key change? After all, you can't exactly
put a notice on the site itself...

> "You can't provide [Joe Public] with a string of hex characters and
> expect it to read it over the phone to his bank."
> 
> Sure you can.  Joe Public *already* has to do this with social
> security numbers, credit card numbers, checking/savings account
> numbers, etc. on a pretty routine basis, whether it's over the phone,
> over the Internet, by mail, in person, or what have you.  What makes
> an SSH fingerprint any different?  The fact that now you have the
> letters A through F to read?  Please.

You have missed the question of motivation. I put up with reading a CC
number over the phone (begrudgingly) because I know I need to do that in
order to buy something. If I have a choice of clicking "OK" or phoning
my bank, waiting in a queue, and eventually saying "Hi. I need to verify
the key of your webserver's cert so I can log on to do my online
banking. Is it 09F9.?" then I'm just going to click "OK" (or
"Whatever", as that button should be labelled).

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

Re: Intent to deprecate: Insecure HTTP

[Gervase Markham]

On 14/04/15 13:32, Eric Shepherd wrote:
> My main concern with the notion of phasing out unsecured HTTP is that
> doing so will cripple or eliminate Internet access by older devices that
> aren't generally capable of handling encryption and decryption on such a
> massive scale in real time.
> 
> While it may sound silly, those of us who are intro classic computers
> and making them do fun new things use HTTP to connect 10 MHz (or even 1
> MHz) machines to the Internet. These machines can't handle the demands
> of SSL. So this is a step toward making their Internet connections go away.

If this is important to you, then you could simply run them through a
proxy. That's what jwz did when he wanted to get Netscape 1.0 running again:
http://www.jwz.org/blog/2008/03/happy-run-some-old-web-browsers-day/

Gerv


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

Re: Intent to deprecate: Insecure HTTP

[Gervase Markham]

On 14/04/15 08:51, lorenzo.kel...@gmail.com wrote:
> 1) Caching proxies: resources obtained over HTTPS cannot be cached by
> a proxy that doesn't use MITM certificates. If all users must move to
> HTTPS there will be no way to re-use content downloaded for one user
> to accelerate another user. This is an important issue for locations
> with many users and poor internet connectivity.

Richard talked, IIRC, about not allowing subloads over HTTP with
subresource integrity. This is one argument to the contrary. Sites could
use HTTP-with-integrity to provide an experience which allowed for
better caching, with the downside being some loss of coarse privacy for
the user. (Cached resources, by their nature, are not going to be
user-specific, so there won't be leak of PII. But it might leak what you
are reading or what site you are on.)

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

Re: Intent to deprecate: Insecure HTTP

[Gervase Markham]

On 14/04/15 08:47, david.a.p.ll...@gmail.com wrote:
>> realistic idea. Meanwhile, HTTPS exists, is widely deployed, works,
>> and is the focus of this thread. 
> 
> http://www.zdnet.com/article/google-banishes-chinas-main-digital-certificate-authority-cnnic/
>  
> 
> Sure it works :)

Yep. That's the system working. CA does something they shouldn't, we
find out, CA is no longer trusted (perhaps for a time).

Or do you have an alternative system design where no-one ever makes a
mistake and all the actors are trustworthy?

Gerv

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

Re: Intent to deprecate: Insecure HTTP

[Gervase Markham]

On 14/04/15 01:57, northrupthebandg...@gmail.com wrote:
> * Less scary warnings about self-signed certificates (i.e. treat
> HTTPS+selfsigned like we do with HTTP now, and treat HTTP like we do
> with HTTPS+selfsigned now); the fact that self-signed HTTPS is
> treated as less secure than HTTP is - to put this as politely and
> gently as possible - a pile of bovine manure 

http://gerv.net/security/self-signed-certs/ , section 3.

But also, Firefox is implementing opportunistic encryption, which AIUI
gives you a lot of what you want here.

Gerv

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

Re: Intent to deprecate: Insecure HTTP

[Gervase Markham]

On 13/04/15 18:40, DDD wrote:
> I think that you'll need to define a number of levels of security, and decide 
> how to distinguish them in the Firefox GUI:
> 
> - Unauthenticated/Unencrypted [http]
> - Unauthenticated/Encrypted   [https ignoring untrusted cert warning]
> - DNS based auth/Encrypted[TLSA certificate hash in DNS]
> - Ditto with TLSA/DNSSEC 
> - Trusted CA Authenticated[Any root CA]
> - EV Trusted CA   [Special policy certificates]

I'm not quite sure what this has to do with the proposal you are
commenting on, but I would politely ask you how many users you think are
both interested in, able to understand, and willing to take decisions
based on _six_ different security states in a browser?

The entire point of this proposal is to reduce the web to 1 security
state - "secure".

Gerv


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

Re: Intent to deprecate: Insecure HTTP

[Gervase Markham]

On 13/04/15 15:57, Richard Barnes wrote:
> Martin Thomson and I drafted a
> one-page outline of the plan with a few more considerations here:
> 
> https://docs.google.com/document/d/1IGYl_rxnqEvzmdAP9AJQYY2i2Uy_sW-cg9QI9ICe-ww/edit?usp=sharing

Are you sure "privileged contexts" is the right phrase? Surely contexts
are "secure", and APIs or content is "privileged" by being only
available in a secure context?

There's nothing wrong with your plan, but that's partly because it's
hard to disagree with your principle, and the plan is pretty high level.
I think the big arguments will be over when and what features require a
secure context, and how much breakage we are willing to tolerate.

I know the Chrome team have a similar plan; is there any suggestion that
we might coordinate on feature re-privilegings?

Would we put an error on the console when a privileged API was used in
an insecure context?

Gerv

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

Re: Chrome removed support for multipart/x-mixed-replace documents. We should too.

[Gervase Markham]

On 12/03/15 16:04, Seth Fowler wrote:
> It looks like it doesn’t anymore, because it works fine in Chrome.

It does; it browser-sniffs.

Gerv

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

Re: Project Silk on Desktop

[Gervase Markham]

On 11/03/15 18:12, Mason Chang wrote:
> Project Silk (http://www.masonchang.com/blog/2015/1/22/project-silk),
> which aligns rendering to vsync, will be landing over the next couple
> of weeks (bug 1071275). You should expect smoother animations and
> scrolling while browsing the web. It'll land in 4 parts, with the
> vsync compositor on OS X landing today. We'll start landing the vsync
> compositor on Windows a week or two from now, then the vsync refresh
> driver's on OSX and Windows a week or two after the vsync compositor.
> If you have any issues, please file bugs and make them block bug
> 1071275.

ObQuestion: what about Linux? :-)

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

Re: Permission UI

[Gervase Markham]

On 05/03/15 07:40, Anne van Kesteren wrote:
> This would require everything that's like github.io to register as a
> public suffix. 

github.io already is a public suffix :-) If some private entity is
handing out subdomains to mutually-untrusting 3rd parties, there are a
number of reasons they should be in the PSL. If they aren't, they'll
have bigger problems than one site not being able to use localstorage
because another one has sucked it all up.

> And if someone actually wants to attack users I doubt
> the budget would only allow for a single domain. This is why I'm not
> really convinced this eTLD coupling is really of help.

Doesn't it also prevent accidental as well as deliberate problems? If
there was no eTLD coupling, one site that was doing something they
thought was perfectly reasonable could nevertheless exhaust the
available resources for everyone on a resource-constrained device.

Gerv

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

Re: HTTP/2 and User-Agent strings?

[Gervase Markham]

On 05/02/15 02:24, Karl Dubost wrote:
> Maybe something we can discuss soon: Feb 18, 2015. Some Microsoft people will 
> be there.
> https://wiki.mozilla.org/WebCompat_Summit_%282015%29#Summit_Schedule

Yes; I'd love to hear their take on this.

Duelling product groups in Microsoft?

Gerv

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

Re: HTTP/2 and User-Agent strings?

[Gervase Markham]

On 28/01/15 15:45, Gijs Kruitbosch wrote:
> That's IE11, which is not the same as Spartan.

Hmm. I'm surprised that having managed to trim down the UA for IE 11 to
be "not old IE, standards compliant stuff please", they then take the
opposite approach with Spartan, when they want to send basically the
same message. 

Gerv

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

Re: HTTP/2 and User-Agent strings?

[Gervase Markham]

On 27/01/15 09:16, Chris Peterson wrote:
> btw, here is the "spartan" User-Agent string for Microsoft's new Spartan
> browser:
> 
> Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like
> Gecko) Chrome/39.0.2171.71 Safari/537.36 Edge/12.0

Really?
http://www.nczonline.net/blog/2013/07/02/internet-explorer-11-dont-call-me-ie/
suggests that it's:

Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv 11.0) like Gecko

Gerv

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

Re: landing soon: core APIs for VR

[Gervase Markham]

On 19/11/14 17:15, Vladimir Vukicevic wrote:
> - Figure out how to ship/package/download/etc. the Oculus runtime
> pieces. 

The last discussions on these were that you were planning to approach
Oculus to enquire about getting them under an open source license. How
did that go? If that's not going to happen, what is your current
proposal for how we deal with that?

I'm sure the APIs you are adding are device-agnostic; but what's the
plan for extending device support? Do we just tell other device
manufacturers what our interface is and get them to write their own  glue?

Gerv

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

Re: http-schemed URLs and HTTP/2 over unauthenticated TLS

[Gervase Markham]

On 18/11/14 04:03, voracity wrote:
> The issue isn't that people are cheapskates, and will lose 'a few
> dollars'. The issue is that transaction costs
>  can be crippling.

https://letsencrypt.org/ .

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

Re: Moratorium on new XUL features

[Gervase Markham]

On 15/10/14 14:24, Boris Zbarsky wrote:
> I haven't thought much about #3; it's somewhat in its own little world
> and has no web tech equivalent.

Although glazou did propose one a decade ago:
http://disruptive-innovations.com/zoo/20040830/HTMLoverlays.html

Gerv

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

Re: Intent to implement: WOFF2 webfont format

[Gervase Markham]

On 08/10/14 15:44, Patrick McManus wrote:
> I'm not aware of font negotiation - but negotiation is most useful when
> introducing new types (such as woff2). The google compression proxy already
> does exactly that for images and people are successfully using the AWS
> cloudfront proxy in environments where the same thing is done. Accept is
> used to opt-in to webp on those services and that allows them to avoid
> doing UA sniffing. 

OK. So it can work if every browser that supports the format puts in in
Accept: as soon as it begins support. That may be true of WebP; I don't
believe it's true of WOFF. Is it?

Gerv

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

Re: Intent to implement: WOFF2 webfont format

[Gervase Markham]

On 07/10/14 14:53, Patrick McManus wrote:
> content format negotiation is what accept is meant to do. Protocol level
> negotiation also allows designated intermediaries to potentially transcode
> between formats. 

Do you know of any software which transcodes font formats on the fly as
they move across the network?

> imo you should add woff2 to the accept header.

Do you know of any software which pays attention to this header?

Given that other browsers don't set it, why would anyone else write such
software?

(This situation is basically "the Accept: problem".)

Gerv

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

Re: http-schemed URLs and HTTP/2 over unauthenticated TLS

[Gervase Markham]

On 15/09/14 16:34, Anne van Kesteren wrote:
> It seems very bad if those kind of devices won't use authenticated
> connections in the end. Which makes me wonder, is there some activity
> at Mozilla for looking into an alternative to the CA model?

What makes you think that switching away from the CA model will
significantly reduce the amount of crypto operations such devices have
to do?

Gerv

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

Re: Intent to support apple-touch-icon with Browser API

[Gervase Markham]

On 28/07/14 17:12, Dale Harvey wrote:
> We specifically chose a User Agent to something compatible with our Android
> release to get more compatible websites, despite the "standard" way would
> be to not do browser sniffing. 

I'm not quite sure what you mean here. Who is "we" in that sentence? The
Content HTTP Headers team did a load of analysis and decided that the UA
for Firefox OS should not contain "Android". Has that changed for some
or all of Firefox OS without us knowing?

https://wiki.mozilla.org/B2G/User_Agent

Gerv

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

Re: Intent to implement: webserial api

[Gervase Markham]

On 13/07/14 18:35, tzi...@gmail.com wrote:
> Jonas, I would be really interested in your thoughts. Try as we might
> (in the WebSerial API docs, at least), noone could actually think of
> a use case where providing access to a physical (RS232), or Virtual
> (VirtualUSB or VirtualBluetooth) serial port could be a privacy
> and/or security issue.
> 
> It's a whole different beast when you provide access for cameras or
> any USB device, of course, but what could someone do with access to a
> serial port?

The WebSerial interface doesn't cover the Universal Serial Bus, then?

For USB, the OS has some underlying knowledge of what the device is,
right? So we could do permissions for USB on a per-device rather than
per-port basis, which is the right way to do it IMO. But AFAIK that's
not possible for RS232.

Gerv

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

Re: B2G, email, and SSL/TLS certificate exceptions for invalid certificates

[Gervase Markham]

On 30/05/14 18:53, Joshua Cranmer 🐧 wrote:
>> Forgive me, but that sounds like "I'm going to propose a solution with
>> one glaring flaw that has always sunk it in the past, and then gloss
>> over that flaw by saying 'I don't have the security experience - someone
>> else fix it'."
> 
> Actually, that is essentially what I'm saying. I know other people at
> Mozilla have good security backgrounds and can discuss the issue, and I
> was hoping that they could weigh in with suggestions on this thread. I
> acknowledge that the re-keying is a difficult issue, but I also don't
> have the time to do the research myself on this topic, since I'm way
> backed up on a myriad of other obligations.

https://www.youtube.com/watch?v=BKorP55Aqvg&feature=youtu.be

:-)

> The EFF does things that aren't public?! :)

It would appear so. There are many reasons why this might be - privacy,
lack of time to publish, etc. I haven't asked them.

> More seriously, are they actively attempting to detect potential MITMs,
> and would they announce if they did detect one? 

I don't know, and presumably yes :-)

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

Re: B2G, email, and SSL/TLS certificate exceptions for invalid certificates

[Gervase Markham]

On 28/05/14 17:49, Joshua Cranmer 🐧 wrote:
> * Insufficiently secure certificate (e.g., certificates that violate
> CA/Browser Forum rules or the like. I don't know if we actually consider
> this a failure right now, but it's a reasonable distinct failure class
> IMHO)

We would refuse e.g. a cert with an MD5 signature. In the future, we
hope to refuse certs of insufficient bitlength.

> It seems to me that some of these are more tolerable than others. There
> is a much different risk profile to accepting a certificate that expired
> two days ago versus one that fails an OCSP validation check.

Actually, no. Because as soon as a certificate expires, the CA has no
obligation to keep revocation information available for that cert. So
the two are actually equivalent.

That is to say, if a cert is expired, then you may not receive an OCSP
response for it. And you can't make any assumptions about what that
response might have been - it might have been "revoked".

> We have an excellent chance to try to rethink CA infrastructure in this
> process beyond the notion of a trusted third-party CA system (which is
> already more or less broken, but that's beside the point). My own views
> on this matter is that the most effective notion of trust is some sort
> of key pinning: using a different key is a better indicator of an attack
> than having a valid certificate; under this model the CA system is
> largely information about how to trust a key you've never seen before.
> There is a minor gloss point here in that there are legitimate reasons
> to need to re-key servers (e.g., Heartbleed or the Debian OpenSSL
> entropy issue), and I don't personally have the security experience to
> be able to suggest a solution here.

Forgive me, but that sounds like "I'm going to propose a solution with
one glaring flaw that has always sunk it in the past, and then gloss
over that flaw by saying 'I don't have the security experience - someone
else fix it'."

> Doesn't the EFF's SSL Observatory already track the SSL certificates to
> indicate potential MITMs?

The SSL Observatory's available data is a one-off dump from several
years ago. They are collecting more data as they go along, but it's not
public.

> 1. Any solution should try to only permit the "easy" certificate
> override on account configuration. This minimizes scope for potential
> MITM attacks.

That sounds like a reasonable idea, actually; by analogy with Bluetooth
pairing.

Gerv

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

Re: B2G, email, and SSL/TLS certificate exceptions for invalid certificates

[Gervase Markham]

On 29/05/14 07:01, Mike Hoye wrote:
> It's become clear in the last few months that the overwhelmingly most
> frequent users of MITM attacks are state actors with privileged network
> positions either obtaining or coercing keys from CAs,

I don't think that's clear at all. Citation needed.

I think it's more likely that they are intercepting SSL using crypto or
implementation vulnerabilities without explicit CA cooperation.

> using attacks that
> the CA model effectively endorses, using tech you can buy off the shelf.
> In that light, it's not super-obvious what SSL certs protect you from
> apart from some jackass sniffing the coffeeshop wifi.

Even if you are right, the answer is still "everyone apart from the US
government".

Gerv


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

Re: Intent to Implement: Encrypted Media Extensions

[Gervase Markham]

On 27/05/14 19:44, Chris Pearce wrote:
> Encrypted Media Extensions specifies a JavaScript interface for
> interacting with plugins that can be used to facilitate playback of DRM
> protected media content. We will also be implementing the plugin
> interface itself. We will be working in partnership with Adobe who are
> developing a compatible DRM plugin; the Adobe Access CDM.

Is now the time to have the UX discussion? If not, when and where will
that be happening?

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

Re: Intent to implement: WebGL 2.0

[Gervase Markham]

On 08/05/14 12:56, Benoit Jacob wrote:
> (*plug*) this might be useful reading:
> https://hacks.mozilla.org/2013/04/the-concepts-of-webgl/

Comedy. I just read that article, and thought "this article is awesomely
useful." I then looked at the comments, and it turned out that the first
comment is from me a year ago, saying "this article is awesomely
useful". :-)

Gerv

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

Test message: trying to deal with supp...@lativio.com autoresponder spam

[Gervase Markham]

Apologies for the inconvenience. People who post here are getting
autoresponder spam indirectly from supp...@lativio.com. I'm trying to
write STRs so the admin at that site can work out how this is happening.

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

Re: Oculus VR support & somehwat-non-free code in the tree

[Gervase Markham]

On 17/04/14 05:55, Vladimir Vukicevic wrote:
> Already in the works. :)

Awesome :-)

> The good news is that with the preview release of the latest SDK,
> they added a C API that does everything that we need.  So this might
> become a moot point; we can dlopen/dlsym our way to victory, and I'm
> already reworking the code that I have in terms of that.
> 
> We'll have to build and package the DLLs for all the platforms for
> nightly builds, but that's not a huge deal.

At the risk of sounding like a broken record: shipping not-open-source
code in Firefox nightly builds is a big deal. As Mike says, can't we
just go for an addon at this point, while we work on the open source
replacement code? How many Rifts are there in the world right now anyway?

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

Re: Oculus VR support & somehwat-non-free code in the tree

[Gervase Markham]

On 14/04/14 23:41, Vladimir Vukicevic wrote:
> I'd like to get this checked in so that we can either have it enabled
> by default in nightlies (and nightlies only), or at least allow it
> enabled via a pref.  However, there's one issue -- the LibOVR library
> has a not-fully-free-software license [1].  It's compatible with our
> licenses, but it is not fully "free".

As others in this thread have guessed, this discussion is the follow-up
to the bug Vlad opened to ask about this issue. It's here:
https://bugzilla.mozilla.org/show_bug.cgi?id=989903
although because it's a legal bug, sadly few of you will be able to see
it. I don't think there's anything secret in it, but it's not within my
power to open.

So people may be interested in what I said. My apologies that I am late
to this thread.

tl;dr: Henri is right that checking it in would reduce Oculus' desire to
work with us. We should talk to them first, and quickly.

> 1. Check in the LibOVR sources as-is, in other-licenses/oculus.  Add
> a configure flag, maybe --disable-non-free, that disables building
> it.  Build and ship it as normal in our builds.

The license concerned is here:
https://developer.oculusvr.com/license

Here are the issues I found with it after a quick read:

* You can only distribute or re-distribute LibOVR in whole, not in part.
An Open Source license "must allow modifications and derived works" (OSD).

* If your applications cause health and safety issues, or if you upset
them in other ways, you may lose your right to use the Oculus VR SDK,
including LibOVR. Open Source licenses need to be irrevocable, and they
need to not restrict what you can use the software for.

* Modifications to the Oculus VR SDK in source or binary form must be
shared with Oculus VR. The most that an Open Source license can require
is that they be shared with anyone to whom you give a copy of the
binary. This requirement goes beyond that.

* Certain sorts of changes have to be copyright-assigned to Oculus VR,
and you do not get a permissive license back to use them how you choose.

* You can't use the code to interface with other headsets. An Open
Source license cannot restrict what you can use the code for.

* They can change the license on you at any time. Open Source licenses
must not be revocable.

This license is a fairly long way from open source. So Mozilla policy
 would say that we don't
check this code into our repos (either in source or binary form) and
also, whether it's in our repos or not, we don't ship it with Firefox.

Making Firefox not-open-source would have a number of fairly serious
ramifications. Calling this "licensing dogma" is like calling the right
to trial-by-jury "freedom dogma". As others have said, there are a large
number of people in the project to whom this is important.

> 2. Contact Oculus with our concerns about the license, and see if
> they would be willing to relicense to something more standard.

I think we should definitely do this.

> 3. Start investigating "Open VR", with the intent being to replace
> the Oculus-specific library with a more standard one before we
> standardize and ship the API more broadly than to nightly users.
>
> The goal would be to remove LibOVR before we ship (or keep it in
> assuming it gets relicensed, if appropriate), and replace it with a
> standard "Open VR" library.

This strategy of using the Oculus code temporarily was not in view in
the original bug filed on this issue. It is perhaps an improvement, but
(without attributing bad motives to anyone) I suspect that once code is
in, integrated and working, the pressure to ship it would become so
great that the "and replace it with some open source stuff later" part
would get dropped and lost.

I can certainly name one Mozilla project where a non-open-source library
was used, and the bug to replace it with something open source never got
any attention after the code was shipped and working.

> 1. We could ship the VR glue in nightly, but the Oculus support
> packaged as an addon.  This is doable, but it requires significant
> rework in changing the interfaces to use XPCOM, to do category-based
> registration of the Oculus provider, in building and packaging the
> addon, etc.  It also requires a separate install step for
> developers/users.

This is my proposal. Given that the hardware here costs $1500 and is
available in limited quantities, I am not too worried about the burden
on developers and users of installing an add-on.

Add-ons are where non-free code lives in the Firefox ecosystem. (Well,
and plugins, but we don't like them any more.)

> Any objections to the above, or alternative suggestions?  This is a
> departure in our current license policy, but not a huge one. 

I think making Firefox non-free in the name of the new shiny is a pretty
huge departure, myself. Particularly as there are other options
available, and people already working on free drivers.

> There
> were some concerns

Re: Oculus VR support & somehwat-non-free code in the tree

[Gervase Markham]

On 15/04/14 06:21, Nick Alexander wrote:
> Can somebody save me some license reading and explain what the existing
> framework around shipping libovr is?  Is it explicitly allowed?
> Explicitly dis-allowed?  If I read gerv's post [1] correctly, it is
> allowed, but it's hard to distinguish gerv's opinion from Mozilla legal's.
> 
> [1] http://blog.gerv.net/2014/03/mozilla-and-proprietary-software/, in
> particular section 1B.

1B would not apply in this case, at least as I envisaged it. As others
have noted, the headset prevents itself as a USB device and then
provides a data stream to be interpreted in userspace. The exception in
1B was for lower-level things like wifi chipsets.

And, as Vlad says, that post is only my opinion (albeit one on which I
have received positive feedback), not official Mozilla policy.

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

Re: Spring cleaning: Reducing Number & Footprint of HG Repos

[Gervase Markham]

On 27/03/14 00:53, Taras Glek wrote:

*User Repos*
TLDR: I would like to make user repos read-only by April 30th. We should
archive them by May 31st.


I think that if you truly intend to go ahead with this, the news will 
need way, way wider circulation than mozilla.dev.platform. I have some 
useful software stored in a user repo, and I only happen to read this 
group. It will also need much more lead time than a month.


I'm also somewhat surprised that this has been proposed without any 
previous attempt to measure the impact of doing it. Or has such work 
been done, but the results not published? How often are all these repos 
pulled from or pushed to? Could we achieve many of the gains by getting 
people to clean up after themselves, rather than eliminating the 
capability entirely?


I don't think you're suggesting this, but just to be clear: I'm against 
storing our repo of record for anything of long-term importance on any 
system other than our own. And yes, I know about B2G.


Gerv

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

Re: Including Adobe CMaps

[Gervase Markham]

On 28/02/14 12:37, Jonathan Kew wrote:
> Presumably we always want the complete PSL available. So it really
> should be part of the base product, not a [try-to-]load-on-demand resource.

I was proposing it be part of the base product, but updated on demand.

> Isn't it sufficient to update that with each new Firefox release?

Not everyone takes those. :-|

> If there is data such as this that is always included, but would benefit
> from being updated separately from the regular release schedule (without
> actually pushing out a dot release or chemspill), I think that's a
> rather different use-case, even if a common underlying mechanism could
> perhaps end up serving both.

Fair enough; it is scope creep, then :-)

Gerv


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

Re: Including Adobe CMaps

[Gervase Markham]

On 26/02/14 20:21, Jonathan Kew wrote:
>> Lets turn this question around. If we had an on-demand way to load
>> stuff like this, what else would we want to load on demand?
> 
> A few examples:
> 
> Spell-checking dictionaries
> Hyphenation tables
> Fonts for additional scripts

If this came with an update system (i.e. a way for Firefox to know the
data is out of date) then the Public Suffix List would benefit. It's a
small amount of data, but non-ideal if it goes stale.

But maybe that's scope creep.

Gerv


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

Re: Mozilla style guide issues, from a JS point of view

[Gervase Markham]

On 07/01/14 22:26, Jeff Walden wrote:
> which was unreadable.  You simply can't easily skim and see where the body 
> starts and where the condition ends, even with braces.  We shoved the opening 
> brace to its own line:
> 
> if (somethingHere() &&
> somethingElse())
> {
> doSomething();
> }

AIUI, many style guides which ask for the brace to be on the end of the
"if" have an exception for multi-line conditionals, exactly as you state.

Gerv


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

Re: Mozilla style guide issues, from a JS point of view

[Gervase Markham]

On 07/01/14 00:46, Jeff Walden wrote:
> JS widely uses 99ch line lengths (allows a line-wrap character in
> 100ch terminals).  Given C++ symbol names, especially with templates,
> get pretty long, it's a huge loss to revert to 80ch because of how
> much has to wrap.  Is there a reason Mozilla couldn't increase to 99
> or 100?  Viewability on-screen seems pretty weak in this era of
> generally large screens.  Printability's a better argument, but it's
> unclear to me files are printed often enough for this to matter.  I
> do it one or two times a year, myself, these days.
> 
> I don't think most JS hackers care for abuse of Hungarian notation
> for scope-based (or const) naming.

It would be very interesting for someone to see if any of the references
Mike Hoye gives explain _which_ types of change lead to loss of
productivity. For example, it could be that brace style does, and line
length does not.

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

Re: Should we disable "autoplay" feature of HTMLMediaElement on mobile?

[Gervase Markham]

On 08/12/13 12:28, Tetsuharu OHZEKI wrote:
> On today's web, there are many "interactive" web sites which play
> sounds when open them. 

I suspect this is somewhat dependent on your culture and environment;
it's not a problem on the set of websites I visit :-)

> Some of them are not controlled by users
> because they doesn't not provide any control. 

If a website played music at me with no way to turn it off, I'd probably
leave and never come back...

Personally, also, "it makes it easier for people to hide their porn use
from others" is not an argument which gets much traction with me.

Gerv

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

Re: On closing old bugs

[Gervase Markham]

On 27/11/13 07:36, Gabriele Svelto wrote:
> I'm always tempted to close the former as duplicates of the actual fix
> and the latter as WONTFIX so that they won't show up on the following
> searches but I'm also afraid that closing a bug several years old is
> akin to thread necromancy [1].

Validly closing a bug is not thread necromancy. With Henri's concerns in
mind, feel free to clean up Bugzilla on bug at a time :-)

Gerv

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

Re: Is there any reason not to shut down bonsai?

[Gervase Markham]

On 21/11/13 21:12, Laura Thomson wrote:
> bonsai is old code, and written in very old-fashioned perl. As such,
> security bugs are frequently filed against it, and it's very hard to
> find people who are willing and able to fix them. If you are willing
> and able, let me know: I can hook you up with bugs as they arise.

We do have Perl expertise in the Bugzilla team...



Seriously: can we put it behind a Mozillians-powered Persona login to
reduce the attack surface somewhat? At least then it would be safe from
automated scans.

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

Re: Cost of ICU data

[Gervase Markham]

On 16/10/13 16:02, Axel Hecht wrote:
> We'll need to go down a path that works for Firefox OS.

With Firefox OS, we don't have the download-size issue, do we? So we can
ship all the data.

Gerv

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