All, The Chrome Root Program is aware of the allegations against TrustCor by AppCensus <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/1df04806-96e0-4660-858b-6d890e7eb6b1n%40mozilla.org?utm_medium=email&utm_source=footer> and described in this <https://www.washingtonpost.com/technology/2022/11/08/trustcor-internet-addresses-government-connections/> Washington Post article. Chrome maintains a variety of mechanisms to protect its users, and is prepared to use them as necessary.
To be clear, behavior that attempts to degrade or subvert security and privacy on the web is incompatible with organizations whose CA certificates are included in the Chrome Root Store. The research by AppCensus, along with our own, has identified what could be described as “coincidences” that, when compiled, could call into question the honesty and security of a publicly-trusted root CA owner or operator. As described by Kathleen Wilson <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/3f8c3118-929b-4212-b0ba-4310b59c9399n%40mozilla.org?utm_medium=email&utm_source=footer>, we believe it is TrustCor’s responsibility to assuage community concern by publicly addressing the questions outlined in her message. Additionally, we noted the following coincidences and request further clarification from TrustCor: Coincidence #1 Audit Irregularities - TrustCor uses Princeton Audit Group (PAG) as its auditor. - According to CCADB records, PAG does not audit any other publicly-trusted CAs. - TrustCor’s most recent audit statements ([Standard <https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=c8857fc5-b201-4c4c-8717-f455b10ff5bc>] and [BR - TLS <https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=459d2155-e50c-4497-929c-ee8a57f77708>]) describe CA operations in Toronto, Ontario, Canada. - PAG is listed as a licensed practitioner only in the USA <https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services/licensed-webtrust-practitioners-international#:~:text=PrincetonAuditGroup%2CInc> . - TrustCor’s CPS <http://trustcor.com/resources/cps.pdf> indicates the data centers are located in Phoenix. - Though the management assertion references Phoenix, PAG’s attestation does not. - Beyond [1 <https://www.theinfostride.com/lbgloballaw-confirms-commitment-to-security-through-soc-2-type-2-and-soc-3-compliance/>], [2 <https://www.gep.com/newsroom/gep-attains-ssae-16-soc-2-certification>], and [3 <https://www.yumpu.com/en/document/read/42020572/audit-report-management-assertions-and-system-webtrust>], we found little public information specific to audits performed by PAG. Coincidence #2 WIPO Complaint - This page <https://www.wipo.int/amc/en/domains/search/text.jsp?case=D2018-1096#:~:text=Investigations%20conducted%20by,clients%20or%20employees> summarizes a 2018 complaint filed with the WIPO Arbitration and Mediation Center against Trustcor Systems S. De R.L. by Compagnie Générale des Etablissements Michelin, owner of BFGOODRICH. - The complaint cites concerns related to TrustCor registering bfgoodrichpromotions.net <https://www.whoxy.com/bfgoodrichpromotions.net>, and the risk of a related phishing scheme resulting from the registration and corresponding email servers configured on the disputed domain name. - Ultimately, the Panel found TrustCor’s passive holding of the disputed domain name indicated “bad faith”. Furthermore, the Panel also found that TrustCor’s failure to respond to the Complainant’s cease-and-desist letters was an additional circumstance evidencing the TrustCor’s “bad faith”. - This type of behavior is consistent with that described by Joel Reardon here <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/1df04806-96e0-4660-858b-6d890e7eb6b1n%40mozilla.org?utm_medium=email&utm_source=footer> (see discussion beginning with “Another strange thing is that whois information lists Wylie Swanson as the registrant for a number of domains that closely mimic other encrypted email products [26]). - We’ve separately confirmed the domain registrations described above were once registered as indicated by Joel. Additional Observations Separately, we noted the following observations after taking a closer look at Msgsafe.io and studying TrustCor’s certificate issuance. Msgsafe.io TrustCor owns msgsafe.io, a privacy-focused webmail platform that appears popular across ransomware attacks (examples [4 <https://www.bleepingcomputer.com/news/security/leaked-lockbit-30-builder-used-by-bl00dy-ransomware-gang-in-attacks/#:~:text=%27filedecryptionsupport%40msgsafe.io%27>], [5 <https://howtofix.guide/crypt-file-virus-decryptmsgsafe-io/>], and [6 <https://malwaretips.com/blogs/remove-bannedlands-msgsafe-io-contact/>]). Bad actors’ use of TrustCor’s service offering should not be considered a representation of the service, or TrustCor, itself. However, we are curious to understand actions TrustCor has taken against the addresses represented in the attacks described above, and others that may have been reported in the past. While TrustCor’s responses to known instances of abuse are not directly related to its position as a trusted CA, they could be interpreted as a demonstration of TrustCor’s commitment to upholding security and privacy on the web. Certificate Issuance We studied TrustCor's TLS server certificate issuance and did not find signs of mis-issuance or clear violations of the Baseline Requirements. We identified that ~35% of the dnsNames represented in the certificates issued by TrustCor were publicly accessible at the time of evaluation, and only 59% of those served TrustCor-issued Certificates. Closely studying issuance patterns, most TrustCor-issued certificates were issued to the following domains: ddns.net, hopto.org, sytes.net, zapto.org, myddns.me, servebeer.com, myftp.org, and servehttp.com. We would have expected a substantially broader set of publicly accessible domains, but this is not intended to express wrongdoing by TrustCor. If there are any questions regarding any of the items above, we’d be happy to address them. - Ryan On Tue, Nov 8, 2022 at 1:58 PM Rachel McPherson <[email protected]> wrote: > Hi Joel and Serge, > > Interesting that this is the first time you or anyone else in your > research group has reached out to us, except if you count the Washington > Post journalist who claims in his article that we did not respond, which is > one of the many false claims made in the article since we responded very > quickly to his contact. And before I begin, you should probably clarify if > your views are representing The University of Calgary’s views, The > University of California at Berkeley’s views, or your commercial endeavor > AppCensus’s views, or your views representing any customer, agency, etc…? > If in fact these views are completely independent and personal, that is > also helpful to note. > > For any of the technical details about MsgSafe.io <http://msgsafe.io/>’s > email software and service, that belongs in a different forum as it is not > related to CA operations or CA public policy based on your description. I > know you guys promote some kind of app security solution commercially, but > I did note in my earlier response that our company and MsgSafe has never > shipped an app that was not in BETA only and that the 5-year-old app beta > was abandoned years ago and replaced with a mobile-first web experience > that we think is really quite awesome on the phone browser itself without > having to install any app software which is (as you guys well know) > dangerous when it comes to navigating the 3rd party software that helps > make apps easier to use or helps monetize them or whatever, but may also > contain other stuff bad guys use for their own purposes. We abandoned > mobile development years ago (as you can clearly tell) and instead of > replacing it we just suggest users make use of their built-in browsers only > to use the service which as you can see for yourself works amazingly well > now based on React Native’s mobile capabilities. This is by far the safest > way to use the email app from what I’ve been told by the team, but again in > that other forum please share your suggestions because of course we want to > make it even better. I encourage you to follow those up with the > MsgSafe.io <http://msgsafe.io/> directly via their customer support > channels and I know for a fact they will be thrilled if you can provide any > positive suggestions for improving that product suite, and thank you in > advance for that. I know they get a lot of suggestions, but everything > helps when it comes to making products better and more secure, I think > that’s one thing we all agree on. My suggestion is you don’t start the > conversation with them talking about an abandoned app beta from many years > ago (except maybe to say remove it), and instead focus on improving their > production web application for mobile. > > Specific to your commentary on the certificate authority and policy > pertinent to this forum, I appreciate that you recognize and stated > multiple times throughout your post that you have found *no evidence* of > TrustCor mis-issuing certificates or otherwise abusing our authority or > violating established CA policies or root policies. We obviously agree. I’m > going to comment on a few of your other points for the benefit of this > forum, and then I suggest we take things off-line (sideline at least) and > either meet in person or have phone calls or professionally approach our > discourse some other way, without you guys using the media, your twitter > forces or slinging more false claims, which isn’t good for anyone including > the public that we both hope to serve. > > I’m not an attorney, but when a company registers itself as a corporate > entity and lists its officers and addresses and mailing addresses and uses > attorneys to do those things, often times the company initially gets > registered to the attorney or there and then that information gets > immediately obsoleted through amendments pointing to the real officers. I > can tell you we don’t have any crossover between our officers and the > officers of the other companies you mention, for certain. As for the > ownership or beneficial shareholders of the company, the names you list are > close, but wrong. We have had the same beneficial owners for 7 years, and > while their names are "similar to" the names you mentioned, they are not > identical and we certainly never had any ownership from companies > registered in the USA. As for the cross-over between officers, I am as > perturbed as you because what that website is showing (open corporates) and > probably what the gov attorneys have in our records is absolutely not what > exists in my files, so obviously it is my duty to reconcile this with the > ownership and get it corrected and most importantly explained. Without > having researched any of that, I will again refer to those other random USA > companies that are not us, and that were created in other jurisdictions 7 > years after we were incorporated, that sound similar to our ownership, and > their potential for foul play against us in this way along with the > insurance information attempt I mentioned before. It looks like the real > companies were there before, but were modified and the attorneys and > individuals were added to the record, whereas our records show slightly > different names and without that individual. Again, I will reconcile and > explain after I’ve done more research and compared these things on the > complete timeline of events. > > Also, we are not in USA territory based on ownership, though as you > pointed out we do host some equipment in the USA. I don’t think it’s common > for companies to disclose where any of their critical hosting > infrastructure is located, but yes we have infrastructure in the USA and in > the Caribbean, and our key locations are properly documented in our CA > audits and insurance filings. > > When I read your comments about the company names and the domain name, it > seems like we already explained this in our initial reply to the extent my > attorney is comfortable with me explaining publicly because we are > concerned about follow-on civil lawsuits. Plainly stated, it looks like 7 > or so years after we were founded, someone went and created companies with > similar names (but instead of creating them where they belong and are > already registered, they created them inside the USA). I don’t know for a > fact why anyone would do this, we certainly did not do it. Our attorneys > believe someone could have done this (and it agrees with our event timeline > we’re creating as we investigate) for physical actions taken and may have > used this with insurance companies to obtain additional nonpublic > information about our company and our insurance infrastructure which is > large and complicated just like every CA’s insurance has to be. When you > pair that with someone also having a lookalike domain name, obviously that > could be used for bad purposes (phishing, etc) against our clients or > against us or against our vendors I guess, … that doesn’t look like a good > combination. It looks quite nasty, actually. When we realized the domain > name was out there, we took legal action and we had asserted international > trademark claims and we were able to force the domain be sold to us and we > have it and use it today. Who would register those companies or domain or > do these things to us and why? That’s beyond me, but none of it sounds > like good behavior to me or to our attorneys. If you guys have any actual > evidence of better ideas as to how these could have been used, I’d like to > share that with our attorneys. > > I think I’ve hit on all the big points I can talk about publicly, > obviously I can’t comment on prior (whether deceased or not) employees, > etc. > > Oh and on our own domain ownership or prior employee domain ownership, > frankly that again has to do with that MsgSafe email product and not CA > operations, but our customers and the company and prior and current > employees etc all register domains through it by the hundreds or > thousand(s) there are at some level of provisioning or not, and we really > can’t be responsible for what they all register. Certainly if any violate > any guidelines we try to handle that on an individual case basis, but > hopefully abuse is kept to a minimum and we have a lot of protections > built-in like checking against Alexa top sites and other things CAs do > operationally as part of the business. Some but not all of these > protections are extended to the MsgSafe email product but that can be > blurry because people register some really weird domains quite naturally > and without any malice that contain weird words or substrings or whatever… > > As I said happy we are to take this offline with our CA operational > partners and fellow root program stakeholders and administrators, etc. > > Thank you everyone, > > Rachel > > Please note: this message is not in direct reply to Kathleen’s message > that just came in, we have not yet had time to absorb her post and will > reply to Kathleen’s message on all mentioned points within the timeframe > allotted. However, we did not feel the need to delay our response to Joel > and Serge. > > On Nov 8, 2022, at 11:38 AM, Serge Egelman <[email protected]> > wrote: > > I want to follow this up with some additional details that I've found: > > We initially came across this CA after discovering the malware SDK that > Joel described. We went through some of our app analysis data to find all > the apps impacted and reported those to Google. In every case, save one, > that SDK was heavily obfuscated (going so far as to encrypt strings, which > were then decrypted dynamically at runtime). We found a pre-release beta of > the MsgSafe app that contained the only unobfuscated version of the SDK > that we had seen in the wild. For example, here's a screenshot made after > decompiling that app using apktool: > <Screenshot 2022-11-08 at 8.26.43 AM.png> > > You can see full debug symbols, which don't exist in any other version of > the app that we've found. > > According to their Twitter feed, they released a beta of their Android app > in late 2017: > <Screenshot 2022-11-08 at 8.18.04 AM.png> > https://twitter.com/msgsafeio/status/951217954158530560 > https://twitter.com/msgsafeio/status/933450622271217665 > > While that app is no longer in the Play Store, there are third-party app > archives that have made it publicly available. For example: > > https://apkpure.com/msgsafe-io-unreleased/io.msgsafe.android/download?from=versions > > Like most Android apps, it's signed, so someone else can probably > independently verify its provenance. > > So the question is, why did MsgSafe appear to bundle an unobfuscated > version of this SDK in their app? How was it obtained, if as Rachel says, > they have nothing to do with the company that is spreading it? According to > her email, they don't have a public app; someone should probably tell that > to their social media person... > > > serge > > > > On Tuesday, November 8, 2022 at 7:52:25 AM UTC-8 [email protected] > wrote: > >> Hello all: >> >> I'm Joel Reardon, a professor at the University of Calgary, who researches >> privacy in the mobile space. Earlier this year, collaborators and I >> uncovered >> and disclosed a spyware SDK embedded in apps that were invasively >> tracking users >> [1]. The SDK was banned from the Play Store and apps that included this >> SDK were >> told to remove it or they would be removed from the Play Store. >> >> The SDK was from a Panamanian company [2] called Measurement Systems [3]. >> Their >> website's WHOIS information listed Vostrom Holdings [4] as their owner >> when >> I had started the investigation; it is now anonymized for privacy, but >> historical >> information is available [5]. >> >> Along with investigative journalists at the Wall Street Journal, we >> discovered >> that Vostrom Holdings is doing business as Packet Forensics [6], a >> company that sells lawful-intercept products [7]. The Measurement Systems >> company was also registered in Virginia [8] by "Raymond Alan Saulino", >> which was >> then made inactive when Google took action against the SDK [9]. "Raymond A >> Saulino" is also an officer for Packet Forensics International LLC [10], >> and >> despite the middle name not being an exact match, they both list the same >> residential address [11, 12]. >> >> So now let's get to why I'm talking about this here on this forum. After >> we found >> that the SDK domainss were registered by Vostrom, we looked to see what >> else was also >> registered [13]. One of the domains stood out: trustcor.co, which >> redirected at >> the time to the TrustCor CA's website. The NS records continue to point to >> nsX.msgsafe.io <http://nsx.msgsafe.io/> [14], the same as trustcor.com itself >> [15]. Msgsafe is a TrustCor >> encrypted email product [16]. >> >> Like Measurement Systems, Trustcor is also registered in Panama [17]. >> They were >> registered a month apart and they share an identical set of corporate >> officers >> (cf. [1]). It is my understanding that these officers only are involved >> in three >> companies, so it does not appear that they register, e.g., many companies >> in >> Panama. One of these officers is Frigate Bay Holding LLC [18]. Shortly >> after >> the WSJ article was printed, a "Raymond Saulino" filed paperwork for >> Frigate Bay >> Holdings LLC listed as its manager [19]. Raymond Saulino has also spoken >> to press >> publicly on behalf of Packet Forensics in the context of a Wired article >> about >> subverting SSL [20]. >> >> Trustcor also talks about their "geo-jurisdiction advantage" on an entire >> page >> [21] where they state that "TrustCor is a Panamanian registered company, >> with >> technical operations based in Curaçao---one of the most secure, privacy >> oriented >> jurisdictions in the world." Despite that, they have job openings for PKI >> Engineer and Systems Engineering in Phoenix, AZ [22, 23], the latter >> stating that >> the applicant "MUST be located near the Phoenix, AZ area - job is remote >> with >> occasional trips to data center facilities". Their own audit reports >> state that >> they are Canadian, with their data centres in Phoenix, AZ [24]. I am not >> particularly troubled by where they have their technical operations, but >> I think >> that it is strange to omit that the data centres are in Arizona on the >> lengthy >> descriptions of the "geo-jurisdiction advantage". Certificate authorities >> are >> about trust. >> >> I have also tested the Msgsafe encrypted email product in the browser, >> while >> saving the resulting traffic using Firefox and Chrome's "save to HAR" >> file option. >> I am not convinced there is E2E encryption or that Msgsafe cannot read >> users' >> emails. I see that email contents and attachments are sent plaintext >> (over TLS) to api.msgsafe.io, even when sending to other Msgsafe users >> or when >> using PGP or SMIME to send to non-Msgsafe users. The SMIME cert is sent >> inbound >> from the server, and there is no outbound traffic that embodies the >> public key >> to be signed. The password is sent plaintext to the server (over TLS) and >> thus >> any key derived from that password would also be known by the server. >> Hanlon's >> razor tells me I should not attribute these errors to malice; it could >> just be a >> developmental failure [25]. Nevertheless, I think it is reasonable >> expectation >> that a root certificate authority can get the crypto right, and so I'm >> concern >> regardless of the reason why. >> >> Another strange thing is that whois information lists Wylie Swanson as the >> registrant for a number of domains that closely mimic other encrypted >> email >> products [26]. This includes hushemail.net, protonmails.com, and >> tutanoto.com, >> which shadow competing services, and which redirect users who visit them >> to >> msgsafe.io. Wylie Swanson is the co-founder of Trustcor [27]. In my >> opinion, >> it looks like typo squatting and I would not expect that a root >> certificate >> authority to be engaged in this kind of behaviour. >> >> To be clear, I have found no evidence of Trustcor issuing a bad >> certificate or >> otherwise abusing the authority they have in code signing, SMIME, and >> domain >> validation. I have only checked the public certificate transparency logs >> because >> I am unaware of comparable public auditing for code signing and SMIME. >> Perhaps >> Vostrom registered a similar-sounding domain for Trustcor and redirected >> it >> as an act of service. Perhaps the identical ownership of Trustcor and >> Measurement >> Systems is a coincidence. Perhaps the Raymond Saulino of Frigate Bay >> holdings is >> a different Raymond Saulino than the one representing Packet Forensics. >> >> I'm not familiar with the full policy side of how CA membership works, so >> I >> don't know if there is an expectation of candor regarding a CA's foreign >> ownership or connection to lawful intercept companies. Perhaps what I'm >> reporting is already known and not a concern, or perhaps there is a >> totally >> reasonable explanation for all these coincidences. Nevertheless, I feel I >> should >> disclose my findings just in case it ends up being useful, because I >> think that >> it is reasonable for a root certificate authority to assuage my concerns. >> >> A final coincidence: one of Msgsafe's email domains is decoymail.com, >> which >> Msgsafe users can request and which redirects to msgsafe.io [28]. In >> 2014 it was >> registered to VOSTROM Holdings, Inc., while in 2015 it was registered to >> TRUSTCOR >> SYSTEMS S. DE R.L. [29]. DecoyMail was a company created by Rodney Joffe >> [30], >> who is the person who also filed the original registration of Packet >> Forensics >> [31] and was still an authorized agent for Packet Forensics in a 2019 >> filing >> [32] and a Manager for Packet Forensics in a 2021 filing [33]. The email >> [email protected] is linked to the domains rodneyjoffe.com, >> packetforensics.com, and decoymail.net [34]. Decoymail.net >> <http://decoymail.net/> currently redirects >> to msgsafe.io. >> >> Just to restate: I have no evidence that Trustcor has done anything >> wrong, and I >> have no evidence that Trustcor has been anything other than a diligent >> competent >> certificate authority. Were Trustcor simply an email service that >> misrepresented >> their claims of E2E encryption and had some connections to lawful >> intercept >> defense contractors, I would not raise a concern in this venue. But >> because it is >> a root certificate authority on billions of devices---including mine---I >> feel it >> is reasonable to have an explanation. >> >> [1] https://archive.ph/AuNOy (archive of WSJ article) >> [2] https://opencorporates.com/companies/pa/2337L >> [3] https://measurementsys.com/ >> [4] https://vostrom.com/about.opp >> [5] https://www.whoxy.com/measurementsys.com >> [6] >> https://cis.scc.virginia.gov/CommonHelper/DocumentStorageLocalFileget?DocumentId=1542553&sourceType=1 >> [7] https://www.packetforensics.com/products.safe >> [8] >> https://cis.scc.virginia.gov/CommonHelper/DocumentStorageLocalFileget?DocumentId=3476851&sourceType=1 >> [9] >> https://cis.scc.virginia.gov/CommonHelper/DocumentStorageLocalFileget?DocumentId=12188858&sourceType=1 >> [10] https://opencorporates.com/companies/us_nv/E0518742015-4 >> [11] https://opencorporates.com/officers/429641126 >> [12] https://opencorporates.com/officers/168691865 >> [13] https://www.whoxy.com/company/20189182 >> [14] https://www.whoxy.com/trustcor.co >> [15] https://www.whoxy.com/trustcor.com >> [16] https://trustcor.com/news/12012016.php >> [17] https://opencorporates.com/companies/pa/2326L >> [18] https://opencorporates.com/companies/us_wy/2020-000946985 >> [19] >> https://wyobiz.wyo.gov/Business/FilingDetails.aspx?eFNum=230084239221021253238165142128171020141144245186 >> (click on history, then address update pdf) >> [20] https://www.wired.com/2010/03/packet-forensics/ >> [21] https://trustcor.com/curacao >> [22] >> https://careers.jobscore.com/careers/trustcor/jobs/pki-security-engineer-cGlJUDydTp67nWF6LOxNC0?ref=rss&sid=68 >> [23] >> https://careers.jobscore.com/careers/trustcor/jobs/systems-engineer-aNkuyi0pKr6R6NaKlhlxBf?ref=rss&sid=68 >> [24] >> https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=c4f0e7c6-b310-4f5c-9907-8ecfad68366e >> [25] https://en.wikipedia.org/wiki/Hanlon%27s_razor >> [26] https://www.whoxy.com/email/28298508 >> [27] https://trustcor.com/leadership >> [28] https://decoymail.com >> [29] https://securitytrails.com/domain/decoymail.com/history/a (need to >> create account) >> [30] >> https://ecorp.azcc.gov/CommonHelper/GetFilingDocuments?barcode=00396622 >> [31] >> https://ecorp.azcc.gov/CommonHelper/GetFilingDocuments?barcode=02780271 >> [32] >> https://ecorp.azcc.gov/CommonHelper/GetFilingDocuments?barcode=19121111449561 >> [33] >> https://bizfileonline.sos.ca.gov/api/report/GetImageByNum/190229140180179177132144027172122051178173016008 >> [34] https://www.whoxy.com/email/23160817 >> > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/f5ab3236-2a16-42e6-b33d-6e142c1b49cen%40mozilla.org > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/f5ab3236-2a16-42e6-b33d-6e142c1b49cen%40mozilla.org?utm_medium=email&utm_source=footer> > . > <Screenshot 2022-11-08 at 8.18.04 AM.png><Screenshot 2022-11-08 at > 8.26.43 AM.png> > > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/63F407D0-3AD3-40CB-912E-3E4C2ABD2CCC%40trustcor.ca > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/63F407D0-3AD3-40CB-912E-3E4C2ABD2CCC%40trustcor.ca?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADEW5O-QOZuaEpZJV8hwxb_CZb17z%2BB1SARsgbn2wPXqhdVoEg%40mail.gmail.com.
