NPAPI plugin use case: native chipcard reader

Hi, We are working for a bank that implements a plugin for signing login and transactions in an e-banking solution. This is a key part of the application, it supports the three major browsers (FF and IE through npapi, Chrome through native messaging). When we investigated the problem

Re: NPAPI plugin use case: native chipcard reader

On Mon, Oct 12, 2015 at 4:22 AM, Gijs Kruitbosch wrote: > Are you effectively saying that you use crypto for signing financial > transactions, and the PIN is used for authenticating the user but not > involved in the actual signature/crypto algorithm? Therefore, if a

[Firefox Desktop] Issues found: October 5th to October 9th

Hi everyone, Here's the list of new issues found and filed by the Desktop Manual QA team last week (Week 41: October 5 - October 9). Additional details on the team's priorities last week, as well as the plans for the current week are available at:

Re: NPAPI plugin use case: native chipcard reader

Are you effectively saying that you use crypto for signing financial transactions, and the PIN is used for authenticating the user but not involved in the actual signature/crypto algorithm? Therefore, if a user finds a way to invoke the same crypto without providing the PIN, they can effect

Re: NPAPI plugin use case: native chipcard reader

On Mon, Oct 12, 2015 at 5:01 AM, Gijs Kruitbosch wrote: > On 12/10/2015 12:34, Eric Rescorla wrote: > >> On Mon, Oct 12, 2015 at 4:22 AM, Gijs Kruitbosch < >> gijskruitbo...@gmail.com> >> wrote: >> >> Are you effectively saying that you use crypto for signing financial

Intent to unship: DocumentType.internalSubset

The current DOM standard says DocumentType.internalSubset should be removed: https://dom.spec.whatwg.org/#dom-documenttype-internalsubset It looks like Chrome has already removed it: https://code.google.com/p/chromium/issues/detail?id=272096 http://codereview.chromium.org/282823004 It seems

Re: Intent to unship: DocumentType.internalSubset

SGTM. It seems that the internal subset string was for non-HTML parsers to use for whatever SGML/XML processing, so it should be OK to yank it from the DOM. I can't find any docs on why it was added to the DOM in the first place, so I can't comment on use cases we have to cover with an alternative

Re: C++ feature proposal: specialize conversions for type of usage (local, member, parameter, etc.)

This would probably be implemented for us with the static analysis, and an attribute MOZ_PARAMETER_ONLY_RESULT. I don't know how hard that would be to implement, but it looks a lot like the work I'm doing in https://bugzilla.mozilla.org/show_bug.cgi?id=1191540, so I imagine that once I figure out