Re: Intent to ship: RC4 disabled by default in Firefox 44

[Richard Barnes]

And from Microsoft:

http://blogs.windows.com/msedgedev/2015/09/01/ending-support-for-the-rc4-cipher-in-microsoft-edge-and-internet-explorer-11/

On Tue, Sep 1, 2015 at 1:03 PM, Richard Barnes  wrote:

> Speaking of other browsers, the corresponding Chromium thread is here:
>
>
> https://groups.google.com/a/chromium.org/forum/#!msg/security-dev/kVfCywocUO8/vgi_rQuhKgAJ
>
>
> On Tue, Sep 1, 2015 at 12:56 PM, Richard Barnes 
> wrote:
>
>> For a while now, we have been progressively disabling the known-insecure
>> RC4 cipher [0].  The security team has been discussing with other the
>> browser vendors when to turn off RC4 entirely, and there seems to be
>> agreement to take that action in late January / early February 2016,
>> following the release schedules of the various browsers.  For Firefox, that
>> means version 44, currently scheduled for release on Jan 26.
>>
>> More details below.
>>
>>
>> # Current status
>>
>> Since Firefox 37, RC4 has been partly disabled in Firefox.  It still
>> works in Beta and Release, but in Nightly and Aurora, it is allowed only
>> for a static whitelist of hosts [1][2].  Note that the whitelist is not
>> systematic; it was mainly built from compatibility bugs.
>>
>> RC4 support is controlled by three preferences:
>>
>> * security.tls.unrestricted_rc4_fallback - Allows use of RC4 with no
>> restrictions
>> * security.tls.insecure_fallback_hosts.use_static_list - Allow RC4 for
>> hosts on the static whitelist
>> * security.tls.insecure_fallback_hosts - A list of hosts for which RC4 is
>> allowed (empty by default)
>>
>>
>> # Proposal
>>
>> The proposed plan is to gradually reduce RC4 support by making the
>> default values of these preferences more restrictive:
>>
>> * 42/ASAP: Disable whitelist in Nightly/Aurora; no change in Beta/Release
>> * 43: Disable unrestricted fallback in Beta/Release (thus allowing RC4
>> only for whitelisted hosts)
>> * 44: Disable all RC4 prefs by default, in all releases
>>
>> That is, as of Firefox 44, RC4 will be entirely disabled unless a user
>> explicitly enables it through one of the prefs.
>>
>>
>> # Compatibility impact
>>
>> Disabling RC4 will mean that Firefox will no longer connect to servers
>> that require RC4.  The data we have indicate that while there are still a
>> small number of such servers, Firefox users encounter them at very low
>> rates.
>>
>> Telemetry indicates that in the Beta and Release populations, which have
>> no restrictions on RC4 usage, RC4 is used for around 0.08% for Release and
>> around 0.05%  for Beta [3][4].  For Nightly and Aurora, which are
>> restricted to the whitelist, the figure is more like 0.025% [5].  These
>> numbers are small enough that the histogram viewer on
>> telemetry.mozilla.org won't show them (that's why the below references
>> are to my own telemetry timeline tool, rather than telemetry.mozilla.org
>> ).
>>
>> That said, there is a small but measurable population of servers out
>> there that require RC4.  Scans by Mozilla QA team find that with current
>> Aurora (whitelist enabled), around 0.41% of their test set require RC4, 820
>> sites out of 211k.  Disabling the whitelist only results in a further 26
>> sites broken, totaling 0.4% of sites.  I have heard some rumors about there
>> being a higher prevalence of RC4 among enterprise sites, but have no data
>> to support this.
>>
>> Users can still enable RC4 in any case by changing the above prefs,
>> either by turning on RC4 in general or by  adding specific hosts to the
>> "insecure_fallback_hosts" whitelist.  The security and UX teams are
>> discussing possibilities for UI that would automate whitelisting of sites
>> for users.
>>
>> [0] https://tools.ietf.org/html/rfc7465
>> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1128227
>> [2]
>> https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/IntolerantFallbackList.inc
>> [3]
>> https://ipv.sx/telemetry/general-v2.html?channels=release=SSL_SYMMETRIC_CIPHER_FULL=1
>> [4]
>> https://ipv.sx/telemetry/general-v2.html?channels=beta=SSL_SYMMETRIC_CIPHER_FULL=1
>> [5]
>> https://ipv.sx/telemetry/general-v2.html?channels=nightly%20aurora=SSL_SYMMETRIC_CIPHER_FULL=1
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How would you like to spell check this?

[Jörg Knobloch]

On 1/09/2015 16:01, Ehsan Akhgari wrote:
I suppose you can find them on #fx-team. 


Just for the record from IRC:

jorgk:

Hi, #fx-team. I had this discussion with Ehsan 
https://groups.google.com/forum/#!topic/mozilla.dev.platform/Et02D8Mk2d0 
on improving the spell checking in Firefox. Currently the website 
dictates the dictionary, the user can select another one, which is 
remembered for this website only, and there is some weird fallback 
behaviour. Ehsan suggested to improve the UI first to allow for a global 
override (as does Chrome) and then fix the internals. Bug 1073840 is 
about that. There is also a meta-bug 1073827 which reflects the general 
user confusion. So should we make a start to clean this up?


dolske (Justin Dolske):

I think I'd defer to ehsan's comment about this being a complicated 
issue full of pitfalls.

Not a priority for us to work on right now.

In other words: We will maintain the current "status quo" for the 
foreseeable future.


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

Re: Intent to ship: RC4 disabled by default in Firefox 44

[Richard Barnes]

Speaking of other browsers, the corresponding Chromium thread is here:

https://groups.google.com/a/chromium.org/forum/#!msg/security-dev/kVfCywocUO8/vgi_rQuhKgAJ

On Tue, Sep 1, 2015 at 12:56 PM, Richard Barnes  wrote:

> For a while now, we have been progressively disabling the known-insecure
> RC4 cipher [0].  The security team has been discussing with other the
> browser vendors when to turn off RC4 entirely, and there seems to be
> agreement to take that action in late January / early February 2016,
> following the release schedules of the various browsers.  For Firefox, that
> means version 44, currently scheduled for release on Jan 26.
>
> More details below.
>
>
> # Current status
>
> Since Firefox 37, RC4 has been partly disabled in Firefox.  It still works
> in Beta and Release, but in Nightly and Aurora, it is allowed only for a
> static whitelist of hosts [1][2].  Note that the whitelist is not
> systematic; it was mainly built from compatibility bugs.
>
> RC4 support is controlled by three preferences:
>
> * security.tls.unrestricted_rc4_fallback - Allows use of RC4 with no
> restrictions
> * security.tls.insecure_fallback_hosts.use_static_list - Allow RC4 for
> hosts on the static whitelist
> * security.tls.insecure_fallback_hosts - A list of hosts for which RC4 is
> allowed (empty by default)
>
>
> # Proposal
>
> The proposed plan is to gradually reduce RC4 support by making the default
> values of these preferences more restrictive:
>
> * 42/ASAP: Disable whitelist in Nightly/Aurora; no change in Beta/Release
> * 43: Disable unrestricted fallback in Beta/Release (thus allowing RC4
> only for whitelisted hosts)
> * 44: Disable all RC4 prefs by default, in all releases
>
> That is, as of Firefox 44, RC4 will be entirely disabled unless a user
> explicitly enables it through one of the prefs.
>
>
> # Compatibility impact
>
> Disabling RC4 will mean that Firefox will no longer connect to servers
> that require RC4.  The data we have indicate that while there are still a
> small number of such servers, Firefox users encounter them at very low
> rates.
>
> Telemetry indicates that in the Beta and Release populations, which have
> no restrictions on RC4 usage, RC4 is used for around 0.08% for Release and
> around 0.05%  for Beta [3][4].  For Nightly and Aurora, which are
> restricted to the whitelist, the figure is more like 0.025% [5].  These
> numbers are small enough that the histogram viewer on
> telemetry.mozilla.org won't show them (that's why the below references
> are to my own telemetry timeline tool, rather than telemetry.mozilla.org).
>
> That said, there is a small but measurable population of servers out there
> that require RC4.  Scans by Mozilla QA team find that with current Aurora
> (whitelist enabled), around 0.41% of their test set require RC4, 820 sites
> out of 211k.  Disabling the whitelist only results in a further 26 sites
> broken, totaling 0.4% of sites.  I have heard some rumors about there being
> a higher prevalence of RC4 among enterprise sites, but have no data to
> support this.
>
> Users can still enable RC4 in any case by changing the above prefs, either
> by turning on RC4 in general or by  adding specific hosts to the
> "insecure_fallback_hosts" whitelist.  The security and UX teams are
> discussing possibilities for UI that would automate whitelisting of sites
> for users.
>
> [0] https://tools.ietf.org/html/rfc7465
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1128227
> [2]
> https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/IntolerantFallbackList.inc
> [3]
> https://ipv.sx/telemetry/general-v2.html?channels=release=SSL_SYMMETRIC_CIPHER_FULL=1
> [4]
> https://ipv.sx/telemetry/general-v2.html?channels=beta=SSL_SYMMETRIC_CIPHER_FULL=1
> [5]
> https://ipv.sx/telemetry/general-v2.html?channels=nightly%20aurora=SSL_SYMMETRIC_CIPHER_FULL=1
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[henry . story]

On Thursday, 30 July 2015 12:34:30 UTC+2, Anne van Kesteren  wrote:
> On Thu, Jul 30, 2015 at 12:28 PM, Teoli
>  wrote:
> > Do you think it is already worth to flag it as deprecated in the MDN
> > documentation as Google plans to remove it too?
> 
> Yeah, seems worth a note at least given that Microsoft doesn't ship it
> either (nor plans to ever). I'll probably get the HTML Standard
> updated too in due course.

MS ships an equivalent JS api 
https://msdn.microsoft.com/en-us/library/aa374863(VS.85).aspx

Were there discussions on ways to improve keygen? It seems like what happened 
is that the JS crypto API led people to believe that an equivalent would be 
found there, and this equivalent never appeared.

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

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

[henry . story]

On Thursday, 30 July 2015 20:32:07 UTC+2, Richard Barnes  wrote:
> On Thu, Jul 30, 2015 at 6:53 AM, Hubert Kario  wrote:
> 
> > On Wednesday 29 July 2015 16:35:41 David Keeler wrote:
> > > [cc'd to dev-security for visibility. This discussion is intended to
> > > happen on dev-platform; please reply to that list.]
> > >
> > > Ryan Sleevi recently announced the pre-intention to deprecate and
> > > eventually remove support for the  element and special-case
> > > handling of the application/x-x509-*-cert MIME types from the blink
> > > platform (i.e. Chrome).
> > >
> > > Rather than reiterate his detailed analysis, I'll refer to the post here:
> > >
> > >
> > https://groups.google.com/a/chromium.org/d/msg/blink-dev/pX5NbX0Xack/kmHsyMG
> > > JZAMJ
> >
> > 
> > Well, gmail doesn't support S/MIME or GPG/MIME so obviously  is
> > useless and should be removed.
> > 
> >
> > > Much, if not all, of that reasoning applies to gecko as well.
> > > Furthermore, it would be a considerable architectural improvement if
> > > gecko were to remove these features (particularly with respect to e10s).
> > > Additionally, if they were removed from blink, the compatibility impact
> > > of removing them from gecko would be lessened.
> > >
> > > I therefore propose we follow suit and begin the process of deprecating
> > > and removing these features. The intention of this post is to begin a
> > > discussion to determine the feasibility of doing so.
> >
> > because pushing people to use Internet Explorer^W^W Spartan^W Edge in
> > enterprise networks is a good plan to continue loosing market share for
> > Mozilla products! /s
> >
> > lack of easy, cross-application certificate deployment is the _reason_ for
> > low
> > rates of deployment of client certificates, but where they are deployed,
> > they
> > are _critical_
> >
> 
>  doesn't help you with cross-application deployment.  After all, IE
> doesn't support it.
> 
> 
> 
> > you really suggest I should tell regular people to copy paste CSR's, keep
> > safe
> > their private keys and be able to pair keys to certs when even programmers
> > and
> > system administrators have problems with current certificate deployments?
> > (user certs vs web server certs)
> >
> 
> The point has been made a couple of times that you can pretty effectively
> polyfill  with either WebCrypto or JS crypto libraries.  You can do
> the whole key generation and enrollment process that way, and the only
> manual step is to download the cert and import it into the browser.  Do it
> with JS, and you can support far more browsers than  supports today.

I don't think you can. I argued this in more detail on the html5 commit to 
deprecate keygen
https://github.com/whatwg/html/commit/1b438067d84da2ee95988842cdd8fe2655444936
which I noted has not had much discussion other than a PR that was quickly 
accepted.

I opened an issue on the whatwg github database so that the discussions could 
be cross referenced, and the arguments be out in the open.

> 
> --Richard
> 
> 
> > suggesting removal of such a feature because is not often used is like
> > suggesting removal of mains valve because it is not used often
> >
> > And I say it as a former sysadmin, not Red Hat employee.
> > --
> > Regards,
> > Hubert Kario
> >
> >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> >
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Implement and Ship: Permissions API

[Jonas Sicking]

On Mon, Aug 24, 2015 at 11:57 PM, Anne van Kesteren  wrote:
> On Sat, Aug 22, 2015 at 5:03 AM, Birunthan Mohanathas
>  wrote:
>> Summary: The Permissions API allows a web application to be aware of
>> the status of a given permission, to know whether it is granted,
>> denied or if the user will be asked whether the permission should be
>> granted.
>
> I'm not a big fan of this API.
>
> 1) It doesn't map well to what browsers do internally. Rather than
> simple strings it uses some kind of convoluted dictionary design.

I agree that this is somewhat unfortunate. But in practice it'll mean
that the syntax will be

navigator.permissions.query({ name: "foo" })
rather than
navigator.permissions.query("foo")

which I think in practice is not that big of a problem.

> 2) It would be better to simply expose the permission status of a
> particular feature near a particular feature. If you want to know
> whether geolocation is already granted you should just be able to call
> navigator.geolocation.permission() or some such.

I'm not convinced of this argument. I think this runs the risk of each
API having subtle differences in the querying which IMO is even worse.

Most importantly, I think this API fills a need long asked for by
developers. I.e. while geolocation and similar APIs have taken their
sweet time solving this problem, this API solves the problem here and
now. That's much more valuable than arguing over the exact syntax.

> 3) It seems the API is evolving in ways to also request permission
> without then directly using that permission. It's not clear that is a
> good idea.

I don't see that this risk is higher with a dedicated API compared to
a per-API solution.

But I agree that we should make it clear that we do not intend to
implement a request API.

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

Re: Intent to Implement and Ship: Permissions API

[Ehsan Akhgari]

On 2015-09-01 9:57 PM, Jonas Sicking wrote:

But I agree that we should make it clear that we do not intend to
implement a request API.


There is actually a valid use case for a request API.  It has become 
clear that we need to expose pasting functionality to the Web, and the 
most natural way of doing so is document.execCommand("paste").  This 
operation however cannot be exposed without permission because of 
privacy reasons.  And this is an API where modifying it to add support 
for requesting permission doesn't make sense.


AFAIK right now the Chrome team is experimenting with creating a 
solution for this use case using the request API.  If they manage to 
come up with a good UX, I think we need to implement it (at least for 
the "paste" permission) as well.


Cheers,
Ehsan

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

Web APIs documentation/engagement/dev team meeting Thursday at 8 AM PDT

[Eric Shepherd]

The Web API documentation community meeting, with representatives from
the technical evangelism and the API development teams, will take place
on Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for your
time zone).

Typical meetings include news about recent API development progress and
future development plans, discussions about what the priorities for
documenting and promoting new Web technologies should be, and the status
of ongoing work to document and evangelize these technologies.

We have an agenda, as well as details on how to join, here:

https://etherpad.mozilla.org/API-docs-meeting-2015-09-03.

If you have topics you wish to discuss, please feel free to add them to
the agenda.

We look forward to seeing you there!

If you have topics you wish to discuss, please feel free to add them to
the agenda. Also, if you're unable to attend but have information or
suggestions related to APIs on the Web, their documentation, and how we
promote these APIs, please add a note or item to the agenda so we can be
sure to address it, even if you're unable to attend.


-- 

Eric Shepherd
Senior Technical Writer
Mozilla 
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How would you like to spell check this?

[Jörg Knobloch]

Hi all,

I hope we can at least agree on fixing the problems with the current 
behaviour.

I raised bug https://bugzilla.mozilla.org/show_bug.cgi?id=1200533 for that.

The clear order of priorities that will be established will be:
1) content preference, not ignoring an "en-GB" setting on a plain "en" site.
2) language set by the website, or any other dictionary that partly 
matches that, so if the website is "en-GB", a user who only has "en-US" 
will get that.
3) the value of "spellchecker.dictionary" which reflects a previous 
language choice of the user on another site.

4) the user's locale
5) the content of the "LANG" environment variable (if set)
6) the first spell check dictionary installed.

Feedback?

Jorg K.



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

Sheriffing Newsletter September!

[Carsten Book]

Hi,

to give a little insight into our work and make our work more visible
 for our Community we decided to create a new monthly report from
whats going on in the Sheriffs Team and our work.

If you have questions or feedback just let us know!

This is the first edition of this newsletter so let me know what you think
of it.

In case you don't know who are the sheriffs and if there are current
 issues on the tree see:

https://sheriffs.etherpad.mozilla.org/sheriffing-notes

Topics of this months!
1. Ryan's last week as sheriff!
2. How-To article of the month
3. Get involved
4. Statistics
5. Orange Factor
6. Meeting notes
7. Contact

1. Ryan's last week as Sheriff!

As you might have heard that RyanVM is leaving the Sheriff Team to he will
be leading a new quality team as part of the Firefox org. So its his last
week as Sheriff this week.
Thanks for all what do you did for keeping the Trees open and making the
Sheriff-Role and Sheriffing what it is today and all the best for your new
Role Ryan!

Also of course there will be other Sheriffs around if you have questions
let us know anytime (see the contact section below).

2. How-To Article of the month :) - Notable things!

Ever wondered how Sheriffs do work ? We have a lot of how-to articles
 here: https://wiki.mozilla.org/Sheriffing/How:To

We also do checkins for checkin-needed requests. We have documented
this task here
https://wiki.mozilla.org/Sheriffing/How:To:Landing_checkin-needed_patches
and we are always interested in feedback and how we can make things
better.

3. Get involved!

Ever interested in getting a Community Sheriff and helping checking
test results ? Let us know !

4. Statistics

Intermittent Bugs filed last month [1] : 309
Intermittent Bugs closed last month [2] : 190

For Tree Closing times and reasons see :
http://futurama.theautomatedtester.co.uk/

5. Orange Factor

Current Orangefactor [3] : 7.89

6. Meeting Notes:*

We Sheriffs hold regular meetings. Our notes can be found here:

https://sheriffs.etherpad.mozilla.org/meeting-2015-08-03
and
https://sheriffs.etherpad.mozilla.org/meeting-2015-08-31

7.  How to contact us ?

There are a lot of ways to contact us. The fastest one is to contact
the sheriff on duty (the one with the |sheriffduty tag on this nick
:) or by emailing sheriffs @ mozilla dot org

Cheers,

on behalf of the Sheriff Team
- Tomcat

[1]: http://mzl.la/1KQsqmZ
 [2]: http://mzl.la/1SNM4Hg
 [3]:https://brasstacks.mozilla.com/orangefactor/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How would you like to spell check this?

[lalo . martins]

Oh come on, this is getting ridiculous.

THIS IS A BUG, no matter how much some contributors want to pretend it isn't. 
It's a conceptually simple bug that's been sitting around for at least 3.5 
years (since reported).

To put it simply, if I select a language via the context menu, it should still 
be there next time I visit the same site; it's the intended behaviour for the 
current code, and even if I don't think it's ideal, it's currently broken, and 
I don't understand how there can be any resistance to fixing it.

I understand open source projects need some sort of structure, but a large 
project (not single-developer) where one person can say "I don't have time or 
interest to look into this or read the many different tickets, but in 
principle, I don't want this bug to be fixed" is dysfunctional. It's a bug. It 
needs to be fixed. There's nothing to discuss or approve there, except for 
reviewing the fix code itself.

On Tuesday, 1 September 2015 18:28:47 UTC+2, Jörg Knobloch  wrote:
> On 1/09/2015 16:01, Ehsan Akhgari wrote:
> > The fundamental issue is that different people have different needs, 
> > and there is also the information that the website gives us which we 
> > need to take into account somehow.  You are describing what _you_ 
> > would like to see.
> 
> Actually: No. I was complaining about a bug. A single language user with 
> one dictionary installed visiting a site which prescribes another 
> dictionary is left with no spell checking. Not his locale, not the only 
> dictionary he has installed, not the last choice he made and was stored 
> in "spellchecker.dictionary". This user needs to set the language on 
> every single "foreign" site he visits. My example was just a US user 
> visiting a Korean or German or French or Spanish site. This is what I 
> call "leaving users stand out in the rain".

I'm a multi-lingual user. Since my preferred language (en-gb) matches my 
locale, it never gets saved. So if any site selects a different one via lang 
attribute, this propagates to all my windows. Selecting English-UK again 
through the context menu is *supposed* (as currently specced) to save a content 
preference, but it doesn't, so if I visit a site that selects a different one 
again, it again propagates to all windows.

Or, sometimes, I have no idea under which conditions (maybe a site specifies 
"en" in their lang?), it switches to en-ca or en-au.

Please explain to me how this is not a bug and not worth fixing. Please explain 
to me how a fix will break desired behaviour here -- if there's anyone who 
*expects* this to happen, I'm sorry, but they're insane.

Yes I'd prefer the behaviour to be different. But I can accept that changing it 
would be complex. However, the current state is broken, and it needs to be 
fixed. Anyone who disagrees, please try to replicate my setup and live with it 
for a couple of weeks.

1: set your locale to a variation of en-XX where XX is not US.
2: have other dictionaries installed (and don't tell me this is a corner case; 
on Linux, Firefox uses system dictionaries, and it's nontrivial to filter which 
ones you want installed on a system level; Ubuntu lets you choose a language, 
but not block specific regional variations).
3: frequently visit sites that have in their lang a different language, for 
which you do have an installed dictionary (maybe because you occasionally write 
in that language).

If in two weeks you still don't think this is worth fixing, we can talk again.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How would you like to spell check this?

[Jörg Knobloch]

On 1/09/2015 16:01, Ehsan Akhgari wrote:
The fundamental issue is that different people have different needs, 
and there is also the information that the website gives us which we 
need to take into account somehow.  You are describing what _you_ 
would like to see.


Actually: No. I was complaining about a bug. A single language user with 
one dictionary installed visiting a site which prescribes another 
dictionary is left with no spell checking. Not his locale, not the only 
dictionary he has installed, not the last choice he made and was stored 
in "spellchecker.dictionary". This user needs to set the language on 
every single "foreign" site he visits. My example was just a US user 
visiting a Korean or German or French or Spanish site. This is what I 
call "leaving users stand out in the rain".


Your Korean user with a en-US build should most probably install a 
Korean dictionary to avoid defaulting to en-US, if he/she switches on 
checking in the first place. So I don't think your example compensates 
for those getting wet.


No amount of changes to the fallback paths in the code mentioned above 
will make things work well for everyone.

Sure, but we should fix the most obvious errors.




"Your" code is broken here:


I'm not going through a line by line analysis of this code on the 
mailing list since this is besides the point, and I am trying to not 
take the "your" above personally!


This was actually a reply to what you had written before (quote):
"... the spellchecker.dictionary pref is only set by *our* code ..."
I don't know who you referred to by "we" and "our", but I am addressing 
the same people ;-)


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

Re: How would you like to spell check this?

[Ehsan Akhgari]

On 2015-08-31 5:57 PM, Jörg Knobloch wrote:

On 31/08/2015 17:18, Ehsan Akhgari wrote:

Just wanting to reiterate that the problem is not as big as you claim
it is.  We did not break Firefox for "single language users".


If you take a good look at the fallback processing in
editor/composer/nsEditorSpellCheck.cpp, you will notice that it is
highly broken. Single language users who visit a site where the language
doesn't match any on the dictionaries (or the only dictionary) they
have, end up with no dictionary set. Try:

element ko (which is not installed)

or visit https://www.kyobo.co.kr on your Firefox now, assuming that you
don't have Korean installed.
This code is in desperate need of a clean-up. Some fallbacks only work
if the site doesn't supply a language, see below for a list of all the
problems I encountered.


The fundamental issue is that different people have different needs, and 
there is also the information that the website gives us which we need to 
take into account somehow.  You are describing what _you_ would like to 
see.  But a Korean speaking user who is using an en-US build would 
probably like a different behavior (they may not expect the en-US 
dictionary to be used there since neither they speak English nor the 
website they are visiting is English.)


No amount of changes to the fallback paths in the code mentioned above 
will make things work well for everyone.  That is why in my previous 
email I said that we should get out of the guessing game and let the 
user actually tell us what they want to happen.



This is a mish-mash of probably unrelated bugs that have any number of
causes and solutions.  Not sure why this is relevant to anything
discussed here.

While some of the bugs may be unrelated, you get the general idea of
users not understanding why a specific spell check language is used.


Sure.


Part of the discussion here is to establish clear rules that everybody
can understand. The rule: "If you visit site 1 and change the spelling
language (which is currently stored in the preference) and then visit
site 2 you may or may not get the language you just set" is something no
one understands.


I agree.

But what is?  What you are describing is definitely not something that 
users will understand either.



If nothing else, I'd clean-up the fallback behaviour, since it's broken
and unclear. I'd also clean up the content preference behaviour since I
cannot store "en-GB" on an "en" website, resulting the explicit user
choice to be forgotten all the time.


Believe me when I say that *every single time* we have tried to "fix" 
something here, someone has told us that they actually want a different 
behavior.  As such, I think that any change here must be performed as a 
larger project to fix our spell checking UI.  Even fixing bugs in this 
code has proved to cause more issues.



"Your" code is broken here:


I'm not going through a line by line analysis of this code on the 
mailing list since this is besides the point, and I am trying to not 
take the "your" above personally!



I've looked at this code for a few days now and tested a few things, and
it simply doesn't work in any meaningful way.


I have looked at this code for years.  May I suggest that looking at 
things for a few days may not give you the full picture of where the 
problems are?  :-)



I don't really have any concrete suggestions unfortunately.  If this
is an area that interests you I suggest to start working on the UX
with the help of our UX team.  The implementation strategy needs to
come after agreeing on what UI/UX we want to support here.

I think the first step should be to clean up the current mess, even if
we mostly maintain the current behaviour of storing
"spellchecker.dictionary" as a possible fallback.

Then yes, I'd be interested to get to know the UX people you talk about.


I suppose you can find them on #fx-team.


From the Thunderbird side I know Blake and Jim.


Again, note that spell checking in a web browser is very different than 
in an email client.  Everything I said here was about Firefox, not 
Thunderbird.


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

Re: Smart Card and WebCrypto (Re: On the future of and application/x-x509-*-cert MIME handling)

[Joseph Lorenzo Hall]

On Sun, Aug 30, 2015 at 1:50 AM, Anne van Kesteren  wrote:
> On Sun, Aug 30, 2015 at 7:33 AM, Tim Guan-tin Chien
>  wrote:
>> It's also worthy to point out many nation-state deploys Smart Card
>> identifications (despite the privacy concern), allow it's citizens (or
>> subjects) to authenticate with government services online.
>
> It seems a potential future for that which works within the web's
> security model is FIDO, see
>
>   https://fidoalliance.org/
>   https://support.google.com/accounts/topic/6103521
>
> I don't think we're currently working on this though.

(from the inveterate lurker...)

I've said this to a number of FF folks but it would be great to get
FIDO U2F support in FF; the U2F-enabled yubikeys/harware tokens etc.
are a great, usable 2-factor technology, but it's hard to recommend
people use them when they only work in Chrome. :/

best, Joe

-- 
Joseph Lorenzo Hall
Chief Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
j...@cdt.org
PGP: https://josephhall.org/gpg-key
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform