On Tue, Dec 12, 2017 at 8:36 AM, Jakob Bohm via dev-security-policy < [email protected]> wrote:
> On 12/12/2017 01:08, Adam Caudill wrote: > >> Even if it is, someone filed the paperwork. Court houses have clerks, >>>>> guards, video cameras, etc... It still may present a real physical >>>>> >>>> point >> >>> from which to bootstrap an investigation. >>>>> >>>> >>>> Court houses also have online systems. I think if you read both Ian and >>>> >>> James' work, you'll see the issues they're raising address this >> hypothetical. >> >>> >>> I shall certainly read their work closely on that matter. In my >>> >> experience, these generally don't allow filings for new businesses from >> those not previously known to the court/registrar in real life. >> >> I can say from my own experience, in some states in the US, it's a trivial >> matter to create a company online, with no validation of identity or other >> information. It takes about 10 minutes, and you'll have all the paperwork >> the next day. When I did this (in a state I had never done business in >> before), there was absolutely no identity checks, no identity documents, >> nothing at all that would tie the business to me if I had lied. Creating a >> business with no connection to the people behind it is a very, very simple >> thing to do. >> >> > A lot of people have posed suggestions for countermeasures so extreme > they should not be taken seriously. This includes discontinuing EV, > requiring that companies cannot get EV certs during their first year of > existence, or suggesting that only "famous" companies can get EV > certificates. > > Here is a more reasonable suggestion: > > 1. In the Fx UI, display the actual jurisdictionOfIncorporation instead > of just the country, especially where those differ (For example > Kentucky versus all-of-US). > I will note that suggestions of this nature are not particularly productive or in line with usability research. Beyond the simple fact that "UI is not a democracy" - it's a product decision - let's look at what we're saying: Users are expected to know and understand these distinguishing factors. Either they're expected to understand that the "Stripe, Inc" they want to use is not in Kentucky (an external piece of knowledge few have) or that the "Stripe, Inc" they normally deal with is something they have to memorize (in addition to the URL and other distinguishing factors) As such, this does not stand the basic "Is this a reasonable thing to ask all users" test. > 2. Add a rule that if there is a big national or international company > with a name, other companies cannot get certificates for the same > name in related jurisdictions. For example if there is a company > listed on NYSE or NASDAQ, no similarly named US company can get an > EV or OV certificate for that name. Ditto for a reasonable list of > national registries in each country. CAs should be required to > publicly state which "big-status" lists beat local > company/organization registrations in each country, and similar for > any special lists of major global organizations, such as Google or > The Red Cross. > I realize your intent is well, but this is a huge and tremendous challenge. If you don't believe me, understand why http://www.wipo.int/portal/en/index.html exists. There is not a 'reasonable list' here nor is there a good definition of 'big national or international company'. Or look at http://www.wipo.int/amc/en/domains/decisions/html/2000/d2000-1015.html 5. It is worth noting that some countries do use a national company > registry which ensures uniqueness directly. Denmark is one such > country (though the uniqueness checking is probably limited to exact > matches). > There are a number of such countries. I think it's great you're engaging, but it's not for lack of consideration of your proposals that the result is to remove EV. Rather, it's because the impracticality of them - as already demonstrated - that they shouldn't be on the table. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
