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

Stylesheet wait timeout?

[Gervase Markham]

___
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

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 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 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: 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: 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 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: 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 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: 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 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: 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 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: 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: 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: 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: 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: 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: 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: 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: 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: 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 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: Supporting the Windows Certificate Store

[Gervase Markham]

On 05/03/13 23:54, cpmf2...@gmail.com wrote:
> I read the articles for certutil and I have to ask, "what idiot came
> up with that as the only method???" Seriously, not being able to do
> it easily through Group Policy or some other centralized method is a
> GIGANTIC FAIL. If you want enterprises to take you seriously, take us
> and our needs seriously. Otherwise whatever point Mozilla is trying
> to make is being lost and you will never be installed again in our
> shop.

The EWG may well be able to help you (or anyone else in a similar
position) with alternative, better methods of managing this:
https://wiki.mozilla.org/Enterprise

Gerv


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

Re: End of life for tinderbox.mozilla.org

[Gervase Markham]

On 03/04/13 15:32, Ed Morley wrote:
> Agreed - TBPL's successor is going to be called something other than
> TBPL2 (name chosen so far is treeherder).

Surely then it should be called "Ent"? :-)

Gerv

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

Re: Preparing for the next windows PGO build memory exhaustion

[Gervase Markham]

On 16/04/13 12:27, Mike Hommey wrote:
> I doubt we can get a satisfactory response from MS before things blow
> out (if at all)

But if we'd asked them last time, we might have one by now. And if we
don't ask them this time, then we'll get to next time and still not have
one. :-)

Gerv


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

Re: Some data on mozilla-inbound

[Gervase Markham]

On 23/04/13 10:17, Ed Morley wrote:
> Given that local machine time scales linearly with the rate at which we
> hire devs (unlike our automation capacity), I think we need to work out
> why (some) people aren't doing things like compiling locally and running
> their team's directory of tests before pushing. I would hazard a guess
> that if we improved incremental build times & created mach commands to
> simplify the edit-compile-test loop, then we could cut out many of these
> obvious inbound bustage cases.

That would be the carrot. The stick would be finding some way of finding
out whether a changeset was pushed to try before it was pushed to m-i.
If a developer failed to push to try and then broke m-i, we could (in a
pre-commit hook) refuse to let them commit to m-i in future unless
they'd already pushed to try. For a week, on first offence, a month on
subsequent offences :-)

This, of course, is predicated on being able to detect in real time
whether a changeset being pushed to m-i has previously been pushed to try.

Gerv

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

Re: Storage in Gecko

[Gervase Markham]

On 06/05/13 20:12, David Dahl wrote:
> That is unfortunate. The Kyoto-* tools are FAST and easy to use. I
> wonder if the author would be willing to issue Mozilla a license that
> is compatible with MPL?

That would be the functional equivalent of relicensing under the MPL,
which is a weaker copyleft than he is using. Given that they have
thought about their licensing hard enough to have a FLOSS linking
exception etc. etc., I suspect that would not go down well. But if you
want the licensing team to look into it, file a bug :-)

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

Re: Replacing Gecko's URL parser

[Gervase Markham]

On 04/07/13 17:22, Anne van Kesteren wrote:
> On Thu, Jul 4, 2013 at 5:17 PM, Kyle Huey  wrote:
>> Presumably we could have a blacklist of the handful of protocols that are
>> internal to browsers and have compat issues.  "It violates the standard"
>> isn't a very compelling argument when the standard is in the process of
>> being written and nobody implements it.
> 
> Then we might as well define them. It's not like their parsing
> behavior is particularly hard.

Didn't bsmedberg say that chrome:// in Mozilla is different to chrome://
in Chromium? Who wins?

Gerv

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

Re: We should drop MathML

[Gervase Markham]

On 04/06/13 23:30, Jonas Sicking wrote:
> It would be cool to find a solution that makes the simple things
> simpler than MathML, while keeping the complicated things possible.

Isn't the answer to that sort of question normally something like: a
mini-language for simple math, plus a JS library you can include which
will automatically turn it into MathML?

And lo, there was ASCIIMath:
http://www1.chapman.edu/~jipsen/mathml/asciimath.html

Gerv


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

Re: Sandboxed, off-screen pages for thumbnail capture

[Gervase Markham]

On 17/06/13 21:48, Drew Willcoxon wrote:
> Toolkit already has a thumbnail module, [PageThumbs], but it can only
> capture thumbnails of open content windows, same as they appear to
> the user. Windows may contain sensitive data that should not be
> recorded in an image, however, like bank account numbers and so on,
> so Firefox uses some [heuristics] to determine when it's safe to
> capture a given window. 

Can I challenge an assumption here? I'm not sure I know of a website
which puts up sensitive data large enough that it would show up on a
thumbnail. And even if it did, it's my browser on my machine.

Do we have actual examples of where a thumbnail becomes dangerous?

Could we consider using blurring, or just using the favicon, instead of
this seemingly highly complicated parallel request infrastructure?

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

Re: Sandboxed, off-screen pages for thumbnail capture

[Gervase Markham]

On 26/06/13 08:45, Mark Hammond wrote:
> There is evidence users find this troubling - eg, bug 762610 reports
> that a couple of users wrote to the mozilla webmaster about this.  While
> it may just be a perception, it seems a perception worth managing.  And
> even if someone can't read the exact bank balance figure, they might be
> able to count the columns, or see the balance is written in red.

People can already delete a site using the X button - would making that
more prominent help?

> It's not that uncommon for people to "borrow" a machine that happens to
> sit in, say, a living-room.  If a guest in our house jumps on our
> communal "family machine" to (say) log into their bank or quickly check
> facebook, I'd expect them to be uncomfortable if their bank screen or
> photos from their facebook feed remain as thumbnails after they are
> logged out.

This seems to be one of those cases where their discomfort is caused by
actually having some way of noticing something which has always happened
anyway. Their stuff may be still in the cache; and the user could have
installed a logger anyway.

>> Could we consider using blurring, or just using the favicon, instead of
>> this seemingly highly complicated parallel request infrastructure?
> 
> I'd guess that blurring enough to obscure a red "account balance" figure
> or to render a photo from Facebook completely unrecognizable would look
> fairly ugly. 

I can't recognise Facebook photos from the Thumbnails as it is... The
bank balance is a slightly odd case because it's one where there is
information available from colour alone. And it's only a single bit of
info at that.

I still think we should look at a blurring solution as a much smaller
amount of engineering effort for almost the same win.

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 09/07/13 21:29, Chris Peterson wrote:
> I've seen people change their Bugzilla name to include a comment about
> being on PTO. We should promote this practice. We could also add a
> Bugzilla feature (just a simple check box or a PTO date range) that
> appends some vacation message to your Bugzilla name.

Hey, if we had a PTO app that tracked all absences, we could integrate
with it...


> Some review tools track review comments, so checking subsequent patches
> is easier. A couple months, I heard discussion about an investigation of
> Review Board for Bugzilla. Is anyone still investigating Review Board?

Yes; it's on the BMO roadmap to be integrated; I believe its even being
worked on now. CCing glob.

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 10/07/13 23:14, Taras Glek wrote:
> I tried to capture feedback from this thread in
> https://wiki.mozilla.org/Code_Review

I just did a pass over that page to highlight the key points.

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 10/07/13 15:09, Boris Zbarsky wrote:
> And communicated via bzapi so bzexport can also warn.

BzAPI could add a flag based on a parsing of the name - but then, if
there was an accurate algorithm for parsing a name to extract absence
information, bzexport could use it directly.

Perhaps we could enhance bzexport to request the username of the user of
whom you are requesting review, and display it to you at the time of
submission? You could then notice manually if they were away.

Gerv

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

Generic data update service?

[Gervase Markham]

We keep hitting cases where we would like Firefoxes in the field to have
some data updated using a process which is much lighter in expended
effort than shipping a security release. Here are some examples of the
data Firefox stores that I know of which might benefit from this:

- The Public Suffix List (more important with new TLDs coming)
- The Root CA store, or trust lists in general
- Addon and plugin blacklists
- The default prefs file
- The UA override list (needed for B2G, at least)

(In addition, the IDN TLD whitelist would have been on that list until
it was recently obsoleted, and there are possible future additions -
intermediate CA whitelists being one I know some people want. Safe
Browsing already has its own dedicated service.)

It was the last of these which has triggered this conversation. Given
that we need a system for dynamically updating the UA override list on
B2G and maybe Android too, and that I know Brian Smith is thinking about
how we can have dynamic updates to the Root CA store, is it worth
spending a little extra effort to build something which can be used for
these other cases too, and any others which come along?

The question for webdev is: do we have existing services we can
repurpose or tweak for this?

v1 requirements:

- Firefox polls server every 24 hours
- Secure connection
- Server sends names of files to be replaced and new data
- File on disk at Firefox end gets replaced (and would be reloaded on
  restart)
- Ability to send different data to different clients
- Ability to cope and fall-back to profile-stored per-user info if
  Firefox directory is read-only

Future stuff:

- Ability to trigger data reload without restart
- Ability to integrate data not stored in separate file
- Send only deltas
- Intelligent scheduling
- Server-side ability to send different data to different versions of
  the same client

Gerv

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

Re: [webdev] Generic data update service?

[Gervase Markham]

On 12/07/13 18:20, Benjamin Smedberg wrote:
> I think the general concept of making more of our "lists" be dynamic is
> sound, but I'm very skeptical of the technical solution that you appear
> to be outlining.

The technical solution was 3 minutes on the back of an envelope. Feel
free to tear it apart entirely. But for this discussion, can we focus on
the general rightness or wrongness of such a thing?

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

Re: Generic data update service?

[Gervase Markham]

On 12/07/13 21:12, Nicholas Nethercote wrote:
> Would such an update increment the version number?  I suspect you'd
> want to be able to easily determine if an update has been applied, and
> having to distinguish e.g. "Firefox 30 without update 1" vs. "Firefox
> 30 with update 1" could be annoying (and makes me think of Windows
> service packs).

Good question; don't know. Perhaps each resource needs to be separately
versioned, and have info about that tucked away somewhere less obvious
than Help|About where it can be referenced for the small subset of bugs
where it's useful?

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 13/07/13 00:36, Clint Talbert wrote:
> This is all good stuff, and I want to support us being nimble. We also
> need to balance that against security and quality in our builds. We go
> through the release process for a reason, and we exert the energy to QA
> these builds and ensure we can update them incrementally, reliably, and
> repeatably. I think that such a service like this can be fine, but I'd
> want to be very certain we only change certain, safe items in the
> profile directory, and we stay away from items in the application
> directory.

If that's the general feeling, then we'd need to move any of these data
items which are currently not profile-specific (e.g. the PSL) to be
profile-specific. (Which itself suggests that updating them should rev.
the Firefox version number.)

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: new root certs

[Gervase Markham]

On 15/07/13 17:56, emada.ad...@gmail.com wrote:
> How can i add a new root cert to xulrunner from the command line in linux?

Ask in mozilla.dev.tech.crypto.

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

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

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

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

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