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: 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 <g...@mozilla.org
> <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 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: 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: 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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: 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: 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. shrug

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
 http://en.wikipedia.org/wiki/Transaction_cost 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: 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 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=BKorP55Aqvgfeature=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: 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: 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: 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: 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

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

ducks and runs

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 15/10/13 17:06, Benjamin Smedberg wrote:
 With the landing of bug 853301, we are now shipping ICU in desktop
 Firefox builds. This costs us about 10% in both download and on-disk
 footprint: see https://bugzilla.mozilla.org/show_bug.cgi?id=853301#c2.
 After a discussion with Waldo, I'm going to post some details here about
 how much this costs in terms of disk footprint, to discuss whether there
 are things we can remove from this footprint, and whether the footprint
 is actually worth the cost. This is particularly important because our
 user research team has identified Firefox download weight as an
 important factor affecting Firefox adoption and update rates in some
 markets.

You have given on-disk footprint values, but surely download size values
are the important ones for the issue you are raising? After all, some of
this data may be very compressible, and some may not.

 * currency tables - 1.9 MB
 
 These are primarily the localized name of each currency in each
 language. This is used by the Intl.NumberFormat API to format
 international currencies.
 
 * timezone tables - 1.7MB
 
 Primarily the name of every time zone in each language. This data is
 necessary for implementing Intl.DateTimeFormat.

I wonder if we could do this as a webservice? That is, when the browser
is asked to render a timezone string or a currency string in a
particular language, it goes and grabs all the data for that language.
We could therefore have full support, but a one-off delay for each new
language the user wanted to see UI rendered in (which, for most people,
will be a very small set). We could ship a set of common ones plus the
UI language one to reduce still further the number of times the service
would get hit.

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 14:47, Anne van Kesteren wrote:
 The API is synchronous so that seems like a bad idea.

As in, it'll cause the tab to freeze (one time only, when a new language
is called for) while the file is downloading? OK, that's bad, but so is
having Firefox be a lot bigger...

Perhaps, as Brian suggested, we should be looking at using the Windows
APIs and/or system ICU for some of this data, even if there are some
things for which we want to ship our own implementation.

Gerv

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

Re: What platform features can we kill?

[Gervase Markham]

On 10/10/13 00:28, Philipp Kewisch wrote:
 So you are saying, we should start removing features that could decrease
 the attack surface?

...and that we don't need.

What I'm saying is: perhaps feature-ectomies (and driving the web or our
code to a position where we can make them) may be higher priority than
we thought. Unused but enabled code is not cost-free.

Gerv

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

What platform features can we kill?

[Gervase Markham]

Attack surface reduction works:
http://blog.gerv.net/2013/10/attack-surface-reduction-works/

Removing E4X broke the NSA's EGOTISTICALGOAT attack - a type confusion
vulnerability in E4X.

In the spirit of learning from this, what's next on the chopping block?

A quick survey of the security-group led to the following suggestions,
and I'm sure there are more:

* JS engine: Proxy.create, Object.prototype.watch, __noSuchMethod__,
legacy (pre-ES6) generators, __iterator__, non-ES6 let-blocks, pre-ES6
expression closures

* Editor (share a JS implementation with Servo instead)

* Most OOM recovery in the JS engine

* FTP (perhaps replace with JS implementation from FireFTP)

* Windows integrated auth

* XSLT (Chrome have already announced they will remove it:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/zIg2KC7PyH0
;
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/k8aIeI6BCG0
)

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

Re: Detection of unlabeled UTF-8

[Gervase Markham]

On 06/09/13 16:17, Adam Roach wrote:
 To the first point: the increase in complexity is fairly minimal for a
 substantial gain in usability. Absent hard statistics, I suspect we will
 disagree about how fringe this particular exception is. Suffice it to
 say that I have personally encountered it as a problem as recently as
 last week. If you think we need to move beyond anecdotes and personal
 experience, let's go ahead and add telemetry to find out how often this
 arises in the field.

Data! Sounds like a plan.

Or we could ask our friends at Google or some other search engine to run
a version of our detector over their index and see how often it says
UTF-8 when our normal algorithm would say something else.

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

Re: Detection of unlabeled UTF-8

[Gervase Markham]

On 29/08/13 19:41, Zack Weinberg wrote:
 All the discussion of fallback character encodings has reminded me of an
 issue I've been meaning to bring up for some time: As a user of the
 en-US localization, nowadays the overwhelmingly most common situation
 where I see mojibake is when a site puts UTF-8 in its pages without
 declaring any encoding at all (neither via meta charset nor
 Content-Type). It is possible to distinguish UTF-8 from most legacy
 encodings heuristically with high reliability, and I'd like to suggest
 that we ought to do so, independent of locale.

That seems wise to me, on gut instinct. If the web is moving to UTF-8,
and we are trying to encourage that, then it seems we should expect that
this is what we get unless there are hints that we are wrong, whether
that's the TLD, the statistical profile of the characters, or something
else.

We don't want people to try and move to UTF-8, but move back because
they haven't figured out how (or are technically unable) to label it
correctly and it comes out all wrong.

Gerv


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

Re: Intent to implement: NavigationController

[Gervase Markham]

On 08/08/13 23:52, Ehsan Akhgari wrote:
 I think you forgot the bug number.  :-)

Ehsan: any chance you could trim your responses? I had to page-down 9
times in my mail client just to read this one line...

Thanks :-)

Gerv

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

Re: On indirect feedback

[Gervase Markham]

On 05/08/13 14:53, Bas Schouten wrote:
 Although I agree fully that by far the best way of offering feedback
 is by talking to that person directly. I do think we have to face the
 fact that at this point in time a significant amount of people find
 it very hard to speak to people directly about things. Even when
 their intention is to provide constructive criticism, they will often
 rather avoid the confrontation for fear of creating grudges, damaging
 their reputation, their career, etc. It also simply takes some amount
 of training and social skills to deliver criticism in such a way that
 the target of that feedback will perceive it as the intent to improve
 them, rather than an attempt to simply criticize them or even bring
 them down.

If we accept all that as true for the sake of argument, then it doesn't
legitimise complaining to random 3rd parties. If you are unwilling to
talk to someone directly, find someone who will, and approach them with
a specific request to raise the issue with the person concerned. This is
not as good as approaching them directly, and it should be an indicator
that either you need to work on your feedback-giving or they need to
work on their feedback-receiving, but it's a lot better than the other
alternatives.

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

Re: Generic data update service?

[Gervase Markham]

On 15/07/13 14:57, Benjamin Smedberg wrote:
 Or it means that we need to be willing to issue dot-releases to update
 these items. We're pretty nimble with the desktop release cycle already.
 We should definitely measure this tradeoff before doing a bunch of
 engineering on this. As I understand it, the major factor here is that
 we are not nearly as nimble for FxOS updates, and so this is more of an
 issue, correct?

Certainly the original motivation for this discussion was a desire to be
able to update the UA override list on Firefox OS after shipping, and I
assume there was an implied without shipping a full update to the
device in there somewhere.

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

Re: review stop-energy (was 24hour review)

[Gervase Markham]

On 11/07/13 14:24, Boris Zbarsky wrote:
 On 7/11/13 7:59 AM, Gervase Markham wrote:
 Hey, if we had a PTO app that tracked all absences, we could integrate
 with it...
 sigh
 
 Just in case you were talking about the moco PTO app, it doesn't track
 absences for non-MoCo employees, and even for employees it does not
 track non-PTO absences (being a PTO app and all).

I was talking about a possible future app which did this. Hence the
sigh that we don't have it. (We do have a new PTO app, but it's not
been deployed, ostensibly due to legal reasons because it tracked
non-PTO absences!)

Gerv

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