Kyle Hamilton wrote:
As I recall, cacert.org was planning to be audited by one of the
Mozilla guys directly. I don't know who, and I don't know when, but I
kinda recall some discussion of this.
I remember hearing someone say this, but when I asked, the name given
wasn't anyone I'd ever heard
Balint Balogh wrote:
Without this security measure, any CA that has its certificates in client
software has the power to thwart SSL/TLS security by issuing fake certificates
claiming to belong to *.example.com servers or email addresses.
If you think they might do that, why might they not do
[Important note: this discussion is taking place in
mozilla.dev.security; please respect the Followup-To: header.]
For some time, the Mozilla Foundation has been taking part in a group
called the CA/Browser Forum (CABF), an association of the major
public-facing CAs and all the major
Wolfgang Eibner wrote:
Hi!
I would like to have an Firefox (Portable) started from a CD and showing
HTML files from the CD. The html files on the cd should be encrypted because
so the can't be copied from the CD easily.
This approach will never succeed in the long run. You are giving your
Gervase Markham wrote:
If I am correct, then it seems that the following Firefox minor
release transitions added new certs:
* Firefox 1.0.1 - 1.0.2(UserTrust)
* Firefox 1.5.0.9 - 1.5.0.10 (Taiwan GRCA, Firmaprofesional, Wells
Fargo, Swisscom, GeoTrust
Frank Hecker wrote:
Of course using name constraints in the classic sense requires the
cooperation of the CA (since they have to add the extension to the CA
cert). I think Gerv was thinking of the more general case where for
policy reasons we might want to impose constraints on a CA even in
Bob Relyea wrote:
In addition, we only parse these kinds of constraints on intermediate
certs (we currently don't have a mechanism to place name constraints on
a trusted root. Even if the trusted root had constraints itself, they
would be ignored once we identify the cert as trusted.
Would
Paul Hoffman wrote:
A related question that I was intending to do some research on: if a
trust anchor (trusted root in this thread) has an expiration date in
the past, doe NSS still treat it as a trust anchor, or does it ignore it?
I can't say for certain because I haven't seen the code, but
We are revising the Mozilla project Contributors Agreement (CVS access
agreement) to address deficiences caused by the passage of time, and the
upcoming problem that if and when we migrate away from CVS, a lot of the
document will become inappropriate. The new document is an agreement
with a
timeless wrote:
Did Camino do this when they created, added, or enhanced their
security UI?
Possibly not; you'd need to ask them.
To provide a more amusing variant. Did the people who wrote help
(Netscape, and third parties) for the Security UI in Mozilla 1.7 or
Firefox (to the extent that
Kyle Hamilton wrote:
I thought we'd had this type of conversation before... or maybe it was
on the TLS discussion list, and I'm not remembering. Regardless...
I don't remember participating in one; maybe I wasn't around, or maybe
it was elsewhere. Regardless, you need to dust off your trusty
Gervase Markham wrote:
I am drawing this to the attention of the Mozilla cryptography community
especially, because the document contains a section (Section 5) which
explicitly deals with cryptographic code. So far, I haven't made any
significant changes to it in the new draft. Does anyone
Kyle Hamilton wrote:
The Mozilla Foundation is the authority which determines whether a
given root certificate is included in its default certificate list.
If you're going to assert that it's provable, you suddenly create a
lot more liability for the Foundation -- because it's not provable.
GlobalSign has applied to add some certs to the Mozilla root store, as
documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=367245
and in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/
I have evaluated their request, as per
DigiCert has applied to add some certs to the Mozilla root store, as
documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=364568
and in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/
I have evaluated their request, as per the
Paul Hoffman wrote:
At 10:00 AM + 3/14/07, Gervase Markham wrote:
Paul Hoffman wrote:
A related question that I was intending to do some research on: if a
trust anchor (trusted root in this thread) has an expiration date
in the past, doe NSS still treat it as a trust anchor, or does
Nelson Bolyard wrote:
Your proposal would require storing the equivalent of a name constraints
extension along with the root CA cert. It would also require additional
processing, because name constraints are generally not processed inside
trust anchors. That is, usually a CA puts the name
Keynectis has applied to add some certs to the Mozilla root store, as
documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=335392
and in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/
I have evaluated their request, as per the
I've been feeling my way around the JSS API. The Using JSS document,
the FAQ and the test code are (just) enough to get going. But I've come
across several points where the API seems really low-level. I was
wondering if I've missed something?
I can go through the following long chain to find
Nelson Bolyard wrote:
I propose that we add additional requirements to the policy for root CAs
that apply for inclusion in mozilla products. I propose that we require a
minimum key size for the root CA cert *AND* for any intermediate CA certs
issued by that root CA cert. Here's why.
I
Nelson Bolyard wrote:
I propose that we add additional requirements to the policy for root CAs
that apply for inclusion in mozilla products. I propose that we require a
minimum key size for the root CA cert *AND* for any intermediate CA certs
issued by that root CA cert. Here's why.
I have
StartCom has applied to add some certs to the Mozilla root store, as
documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=362304
and in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/
I have evaluated their request, as per the
There are currently two CAs who have applied for inclusion in the NSS
store but their audits were done by their respective governments and are
classified, and/or they are directly controlled by those governments.
They are:
KISA (South Korea, .kr)
David E. Ross wrote:
I believe that trust should require public disclosure.
Citizens of France have no choice but to trust their government, to a
certain extent. In that the government can exercise jurisdiction over
them. Is the proposed certificate arrangement not just a reflection of
Paul Hoffman wrote:
That makes the assumption that all domains from those countries are in
the countries' TLDs; that is a bad assumption.
You mean that these CAs will not be able to sign certificates for some
sites that they might want to (e.g. www.myfrenchsite.com)? Yes, but
that's just
Merely commenting on matters of fact:
Kaspar Brand wrote:
That doesn't imply everything was perfect with this application at that
time. Have you ever seen a root certificate with a nonRepudiation
keyUsage extension? Yes, Startcom's current one does have that... Or,
what RSA key size would you
Frank Hecker wrote:
So the question is, if a government CA provided a statement roughly
equivalent to the (public) WebTrust report, would that be sufficient for
us? I think the answer is arguably yes, provided that we have the same
general level of confidence in the organization doing the
Alaric Dailey wrote:
There were CAs approved in the past with non-webtrust audits much older then
that. Just see http://hecker.org/mozilla/ca-certificate-list
As a point of fact, that list is not a list of approved CAs, it's a list
of applications.
Gerv
Paul Hoffman wrote:
The current thread is about a proposal that says, in essence, we are
willing to accept a secret audit of a trust anchor that we cannot see
from a national government security agency, but if we accept that, the
trust anchor can only bind identities that contain a domain
Benjamin Smedberg wrote:
I prefer to think of this in terms of limiting expoure: the Korean
government should have the ability to define our trust of the .ko domain,
but not our trust of non-.ko domains.
That's a good way to put it.
Gerv
___
David E. Ross wrote:
Face it: some governments are corrupt. Others are not corrupt in the
sense of officials taking bribes and acting on their self-interests, but
they act in ways that western democracies might find offensive. In
this latter group are nations that practice or at least allow
David E. Ross wrote:
Your last sentence is exactly my point. It would be very difficult to
create an objective policy that allows some governments to certify CAs
but not allow others. This is true without regard for the issue of
secret certifications.
An objective policy would be all
Gervase Markham wrote:
My proposal is that we accept such CAs, but use this technical
capability to restrict them to signing certificates for domains under
the appropriate TLD.
Having considered the discussion, it looks like this idea is not going
to fly. Instead, we will do what Frank
Dave Townsend wrote:
What I want is to be able to be able to establish some trust that the
update file retrieved is correct, and has not been tampered with,
intercepted and is as it was originally written by the add-on author.
Link Fingerprints was designed for precisely this purpose, and is
Dave Townsend wrote:
It doesn't cover those that won't pay for the SSL and don't want to host
on AMO. Yes there are people saying they are in that situation. Numbers
are difficult to guess at though.
I'm sure there are people saying they are in that situation; there are
people who want
Arrakis wrote:
Why not use digital certificates provided by CACert. They are free, and
have high levels of assurity, as opposed to a CAs like Verisign that
have little to no assurity, and charge a ransom.
Because CAcert have not applied for inclusion into (and therefore,
obviously, not been
A-Trust has applied to add some certs to the Mozilla root store, as
documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=373746
and in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/
I have evaluated their request, as per the
Jean-Marc Desperrier wrote:
Gervase Markham wrote:
Jean-Marc Desperrier wrote:
You don't care *who* the owner of the cert is. What you care about is
if he intends to use his signing cert to distribute spyware
extensions. And his identity tells you nothing about that.
No, but it does tell
Eddy Nigg (StartCom Ltd.) wrote:
Under section 6 of the Mozilla CA policy
(http://www.mozilla.org/projects/security/certs/policy/) it states:
/provide some service relevant to typical users of our software products/
This CA seems to issue certificates to Austrian citizens only
Are
Eddy Nigg (StartCom Ltd.) wrote:
If I remember right, there was a discussion on that issue? Don't
remember its outcome however...Perhaps the Mozilla CA policy should be
clearer in that respect and explain if a CA should be public or not
(Assuming that a CA for Austria citizens only is not a
Nelson B wrote:
One needs a trusted source AND a trusted channel to that source.
Yes, although there's also a herd immunity feature, as I discuss below.
At the moment, spotting things like the Wordpress download tarball
trojan took quite a while, because someone had to bother to check the
Michael Vincent van Rantwijk, MultiZilla wrote:
Note that we asked (per e-mail) the top 500 download sites, and most of
them prefer to wait and see what Link Fingerprinting is and can do for
them, because so far nobody really believes that it will do any good for
them, but that it will add
David E. Ross wrote:
On 7/9/2007 1:07 PM, Gervase Markham wrote:
Michael Vincent van Rantwijk, MultiZilla wrote:
Hm, and where is this 15% coming from? Just another assumption?
It's a conservative estimate of the market share of Firefox.
Gerv
That implies the assumption that ALL Firefox
Jean-Marc Desperrier wrote:
But I'd like to point out I'm not the only who is doubtful about the
real level of authentication current commercial CA provide for code
signing certificate.
No. I also have my doubts in this area. That's one reason I think EV is
important.
- grev : barrier to
I apologise for the delay in looking at this.
Eddy Nigg (StartCom Ltd.) wrote:
2.) The links under section documents point to various CA policies and
practices:
With the exception of question 1, which you have already addressed,
these are all good questions. Thank you very much for taking
ARGE DATEN has applied to add some certs to the Mozilla root store, as
documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=348987
and in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/
I have evaluated their request, as per
IdenTrust has applied to add some certs to the Mozilla root store, as
documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=359069
and in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/
I have evaluated their request, as per the
Eddy Nigg (StartCom Ltd.) wrote:
Gerv, can you change the links of the certificates of
http://www.mozilla.org/projects/security/certs/pending/#IdenTrust to
something installable in Firefox?
http://apps.identrust.com/roots/DSTROOTCAX3.cer seems to send the wrong
headers, even so the
Frank Hecker wrote:
The above is why I don't think we need to reference the WebTrust
document specifically. Your thoughts?
Sounds fine. :-) If, in some strange universe, the CABForum decided not
to require audits for compliance any more, then we could just update our
policy again.
Gerv
Nelson Bolyard wrote:
I suspect (and speculate here) that this is because code signing just
isn't very important to Mozilla.
I think it may (also) be true that all of the Mozilla people subscribed
either do not know very much about code signing (me, for one) or don't
feel empowered to speak
Eddy Nigg (StartCom Ltd.) wrote:
I think what Jean-Marc (and me previously) meant, is not related to the
domain name or email address but about the other details in the subject
line. Obviously the CN (or emailAddress) field is to be verified
accordingly...
Oh, I see. Yes, it's definitely
C.J. Adams-Collier wrote:
* Date of last audit
For CAs approved under the new regime, this information is tracked
informally as text in their approval notice, plus also you can click
through to their WebTrust etc. statement to see.
* Auditor profile
What is that, exactly?
* Canonical
Eddy Nigg (StartCom Ltd.) wrote:
Pure ASCII / Latin characters would do...do we need a spec for that?
How did a discussion about avoiding homograph spoofing turn into a
suggestion that we only allow Latin characters?
That's entirely unreasonable. We've spent years working on things like
IDN
C.J. Adams-Collier wrote:
Organization contact information; certificate of authenticity; certifying
body; name, birth date, governmental ID, blood type, gender of all
personnel; you know... the usual :)
We have some of this - see the list.
Nelson Bolyard wrote:
Now, there is a request asking that NSS's code for matching the
application's desired host names to the names in the cert adopt the more
restricting IETF standards, and the NSS team wholeheartedly agrees.
What is the rationale for the request? Does it increase security in
Eddy Nigg (StartCom Ltd.) wrote:
I explained it before. Because YOU can't read the subject line
/C=ישראל/ST=דרום/O=סטארטקום בעמ/CN=אדי ניק
It's completely useless to you.
Absolutely. So I would seriously consider not trusting a site with such
a subject line.
A passport or international
Eddy Nigg (StartCom Ltd.) wrote:
Gervase Markham wrote:
Eddy Nigg (StartCom Ltd.) wrote:
I explained it before. Because YOU can't read the subject line
/C=ישראל/ST=דרום/O=סטארטקום בעמ/CN=אדי ניק
It's completely useless to you.
Absolutely. So I would seriously consider not trusting
Eddy Nigg (StartCom Ltd.) wrote:
But back to our issue, if a compromised server issues a certificate from
within the name constraint and uses it to attack another user (by
claiming to send mail from [EMAIL PROTECTED] or setting up a fake
site for https://really.allowed-domain.com), this
Eddy Nigg (StartCom Ltd.) wrote:
So it would be fine with you, if you've received a signed document or
email (even encrypted) and you are going to trust your VISA and other
personal data to a spoofed email or web site, issued by such a Blackbox
CA?
It wouldn't be fine with me; my point is
Frank Hecker wrote:
I didn't quite say that, but I can understand why Kyle interpreted my
comments that way. What I have said in the past is that because of the
impact of removing a root, particular a root that has lots of server
certs chained up to it, we're not going to remove a root
David E. Ross wrote:
Periodic audits of CAs are required by WebTrust to maintain their seal
of approval and should thus be required by Mozilla for continued
inclusion in the NSS store.
I don't know if it's in the policy explicitly, but it's always been my
view that if a CA failed its
Kyle Hamilton wrote:
Why, as a user, am I being asked by ANYONE in this forum if I can
point to any CA that is violating their CPS, or 'not keeping up with
their auditing'? Why does anyone even remotely think that this is
appropriate? The fact that I caught Thawte violating their CPS at the
Eddy Nigg (StartCom Ltd.) wrote:
Currently the ratio of EV certs is below 1% of overall SSL secured web
sites. If EV doesn't get a significant market share, your priorities
might have been wrong and we should have addressed other issues as well.
I don't really have the bandwidth to dive
Kyle Hamilton wrote:
Please tell me how to completely disable all Mozilla Foundation
included CAs without having to individually change the trust settings
on all of them? I can't trust Mozilla's certificate policy to protect
my interests -- I can't trust Mozilla's policy to ensure that
Nelson B Bolyard wrote:
The situation has simply become intolerable, so as your list moderator,
I have taken steps to cut it off, and am prepared to take more steps.
As moderator, you of course have that right. I would note for your info
that the IT team at the Corporation are aware of this
Nelson B Bolyard wrote:
Thanks for telling me.
Is that being discussed in some newsgroup or mailing list?
I'd like to follow the progress on that topic.
https://bugzilla.mozilla.org/show_bug.cgi?id=425122
Gerv
___
dev-tech-crypto mailing list
Nelson B Bolyard wrote:
It seems that our mailing list server does not apply ANY of its mail
filters to messages that go through the news-mail gateway, so those
filters provide no relief against spam from the news server.
I have now taken the next step. I have disabled the news-mail
pascal wrote:
FNMT has emailed gerv asking if they should open a separate bug or not
asking if we needed more information and if they were following the
right process. They didn't get any response that's why I attached the
files they had sent to the bug.
If people are emailing me specifically
Paul Hoffman wrote:
Let's talk specifics. The Verisign Class 3 Public Primary Certification
Authority, which is widely used to create popular SSL certs on the
Internet (see https://www.amazon.com/), has a 1024-bit RSA key and has
an expiration date of Aug 1 23:59:59 2028. Yes, that's a bit
[Please respect the Followup-To header, set to mozilla.dev.security]
Many of you will know about the problem with weak keys generated on
Debian or Debian-derivative systems between certain dates.[0] This
affects SSL certificates generated on those systems. CAs trusted by
Firefox have signed, and
Andrews, Rick wrote:
I just wanted to mention that we've been working feverishly to automate
checking of all valid certs in our databases. It's taking time because
it's a huge task - we have hundreds of thousands of certs to check - but
we intend to notify any customer who is using a weak key.
Kyle Hamilton wrote:
There has been evidence of Microsoft, at the least, following this
group and acting on good ideas that started here.
We do talk to each other, you know :-)
January 1 2009 particularly because it provides slightly less than 2
quarters of notice.
Indeed. Which doesn't
Rob Stradling wrote:
FYI, Microsoft already require a minimum 2048-bit RSA key size for new Root
Certificate submissions.
Then we might want to implement the same policy, with an exception (for
compatibility reasons) for roots which already have a signficant degree
of deployment but which, for
Nelson B Bolyard wrote:
But one could imagine that we make use of them, and allow the values of
the CKA_END_DATE to be different from (earlier than) the notAfter date
in the related certificate.
It's good to know that this is technically possible.
But actually, I don't see this as a high
Frank Hecker wrote:
I agree that it would be a good thing if Entrust (or any CA, for that
matter) used technical means (like sending email to postmaster or
whatever) to verify domain name ownership for non-EV SSL certs, in
addition to whatever other procedures are used.
In the past, at
Jean-Marc Desperrier wrote:
Kaspersky Lab announces the launch of Stop Gpcode, an international
initiative against the blackmailer virus
http://www.kaspersky.com/news?id=207575651
That seems pointless to me. If they crack it after a few months, the
virus author will just generate a new key
Robert Relyea wrote:
1) work with CA's, in their existing infrastructures to get those certs
revoked.
2) include that list of keys in the browser itself to detect this
compromise.
3) build a parallel revocation scheme to phone home to mozilla (a.la.
anti-phishing) to identify sites with
Jean-Marc Desperrier wrote:
Well, CRL can also be made to scale properly to handle a large number of
revocation, but this requires a few operationnal changes.
...which presumably have to be made before you issue the certs?
The alternative in order to avoid changing the CA constantly would be
Nelson Bolyard wrote:
Do we really want to allow this?
Should this at least be a question that CAs must answer as they apply
for cert inclusion or EV status upgrades?
At a minimum, please add it to the Questionable CA practices document
on the wiki.
It doesn't sound particularly wise to me.
Nelson Bolyard wrote:
If you haven't already done so, read Dan Kaminsky's slides from his
talk at blackhat. http://www.doxpara.com/DMK_BO2K8.ppt
After he presents the DNS attack, he talks about SSL, certs, and what
browsers must do to get read security against DNS attacks from SSL and
Eddy Nigg wrote:
Even though I'm in favor of not mixing EV and other content, I think
this argument is moot. Chances that such an attack on a CA is successful
is most likely less than having you encounter such an attack yourself.
What makes you think that's true?
Attacking a CA's DNS server
Kyle Hamilton wrote:
Even in the case where you require all-EV content, if you try to
perform any additional matching of the Subject (which is what needs to
be matched anyway) you're going to break third-party data feeds and
services. For example, in the aforementioned case, even if Google
Eddy Nigg wrote:
Because CAs (SHOULD) have controls in place to prevent that.
Well, of course. But if another vulnerability in DNS is discovered like
the recent one, no amount of controls is going to help for the period
during which the Internet remains unpatched (assuming it's fixable at
all -
Nelson B Bolyard wrote:
How does the user
a) know that some content is the responsibility of a different entity than
the one identified by Larry, and
b) find the identity of the entity responsible for that other content?
They don't, because any UI which attempted to display all the
Eddy Nigg wrote:
Gervase Markham:
Exactly my point. If the CA's DNS is secure, the EV system is safe. If
it's not, it's not. So the two are linked, and they shouldn't be.
I think you meant DV, not EV here...
No, I mean EV, because the security of EV depends on the security of DV
Kyle Hamilton wrote:
MisterSSL, I'm rather appalled that you are ignoring the realities of
US government user requirements.
I would note in this connection that the Mozilla project as a whole does
not seem to have enterprise use as a specific goal - although many
enterprises happily use it.
Kyle Hamilton wrote:
My view:
Anything that comes from an EV-validated site should be viewed as
being approved by that EV-validated site.
Right. So shouldn't we be concerned if it's possible, by subverting DNS,
to make this not true for EV+DV mixed sites?
The details of the contracts are
Eddy Nigg wrote:
Well yes, EV shouldn't mix with DV...
Right! So, after all that arguing, you actually agree with me?
Gerv
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Eddy Nigg wrote:
I wouldn't state it this way, otherwise we urgently need to modify the
Mozilla CA policy! An attacker shouldn't be successful in such an
attempt and CAs should have controls in place to detect such attempts.
If that's true, then what controls to Startcom (to take an example)
Julien R Pierre - Sun Microsystems wrote:
If the root could revoke itself, in the case of root cert key
compromise, ie. the root cert's private key becoming public, anybody
could then sign revocation information for that root CA - whether to
mark it revoked or unrevoked.
Leaving aside the
Frank Hecker wrote:
Do you mean the UTN-UserFirst-Hardware root? According to the screenshot
on your blog post, that's the root the bogus cert chains up to. Also, if
we were to take action of this general sort (as a hypothetical), what
about adding the PositiveSSL CA cert to NSS with the SSL
Michael Ströder wrote:
Given the large amount of self-generated server certs this problem
already exists.
Large number != large % of visits. A million Joe Publics might use the
Internet for 5 years to do their online shopping without once
encountering a self-signed cert or a certificate error.
sayrer wrote:
The truth is that we are basically unable to act without a lot of
collateral damage. We should keep this in mind with future security
technology. Relying on companies willing to take money for doing
absolutely nothing (not even the bare minimum they agreed to) is not a
pleasant
Kyle Hamilton wrote:
How would this work? Split nssckbi out to be managed by the non-code
module owner, though a coder would need to be enlisted to finalize the
decisions made by that person?
Non-code module arrangements don't require code changes.
As I understand it, having a CA Certificate
Eddy Nigg wrote:
On 12/27/2008 02:34 PM, Gervase Markham:
One of the points of EV was to allow us to act against a CA without
massive collateral damage. We can remove EV status from a root without
disabling the root entirely.
Which unfortunately isn't really effective for the issue we
Ben Bucksch wrote:
We try to train users to check that the bar is green (on sites where it
was green before), and not use the site when it's merely blue.
Otherwise, EV is useless, as the scammer could get a, say, CertStar
cert, to fake an EV site, right? Only when people start getting
Ian G wrote:
As far as I heard, the CABForum was also formed or inspired from a
similar group of vendors (browsers) that got together at the invite of
the Konqueror guy to talk about phishing one day ...
I'm fairly sure it wasn't at the invitation of the Konqueror guy (George
Staikos), but a
Eddy Nigg wrote:
perhaps Mozilla should start to use EV
certs for the update mechanism of Firefox and *enforce* it? There might
be many other sites which potentially could wreak havoc not measurable
in terms of money only.
Perhaps we should. Can you file a bug about this, please? There may be
Kyle Hamilton wrote:
Hmmm... actually, it would be possible, but only with the cooperation
of the CAs.
We currently know the EV policy OIDs for EV-enabled roots. What we
don't know is the policy OIDs assigned for different types of
validation,
...nor do we have, more to the point, a
Ian G wrote:
My personal view of Mozilla is this: the ecosystem is developer-led.
But the ecosystem isn't our representative on the CAB Forum. Our
current representative is Johnathan Nightingale, our Human Shield and
security and user experience expert.
Gerv
1 - 100 of 200 matches
Mail list logo
