Boycott websites that send you email with your password in clear text - <AUTHOR> http://imsaar.posterous.com/boycott-websites-that-send-you-email-with-you

<comment><USER2> > Anybody sending you back your password in clear text is also storing it that > way in their database

Incredibly ignorant statement. If it's encrypted in a reversible format then it's not cleartext. If it's being sent in a confirmation email, then it could even be stored as a one-way hash: password extracted from the form, inserted into email, hashed and stored (This is what WordPress, for example, does).

A case can be made against both of those procedures, but that is a separate issue from his statement being ignorant.

<comment><USER3> If the app can "reverse" the encryption, so can an attacker. The case against storing passwords this way is pretty strong.

<comment><USER4> If the key is embedded in the app and you don't keep the source on the server, reversing the binary (if the attacker even thinks to steal it) is enough of a hassle to deter most people. And maybe the attack only allowed them to copy the database.

It's not foolproof, but for stupid free websites (that's what we're talking about right?), storing encrypted passwords isn't an automatic gimme for the attacker.

<comment><USER3> It's a pernicious myth that passwords on "free" websites don't matter, because no money is changing hands. Most people use the same password for random apps as they do for their email account.

I don't even want to get into the rat-trap of "what kinds" of attackers are stopped by reversably encrypted passwords. There's no kind of attacker that can reverse a properly hashed password, and so that's what you should use.

</comment></comment></comment></comment><comment><USER5> The key is to just use a different password on every site by employing a special password structure.

For example, for HN, you can use:

orycPASSWORDy

[2 last letters][2 first letters][master password][1 first letter]

Good idea to mix and match numbers in the master password for added security. So for HN it can be: orycpassword1y

The good thing is that you only need to remember a single password for all your sites, yet they are all different. And if you ever forget a password, you can figure out what it was by simply looking at the url.

<comment><USER6> at this point there's no real reason not to use a random password generator for _every_ site. There are plenty of apps out there for auto login, and / or most browsers will do this for you. Yes, there's some pain syncing with mobile devices but this will go away at some point (modified oauth to validate devices?).

Password schemes like this are still inherently breakable; as soon as someone gets your key password then the rest is trivial to figure out - so why bother with the complication?

<comment><USER5> until your computer crashes and you find yourself locked out of every site on the internet. No thank you.

\+ what do you do when you aren't using your own computer. Want to check your email at work? Nope sorry, gotta provide the 25 digit randomly generated password.

Nothing is unbreakable, if someone wants your password they'll get it. For the password generator case they can just break into your house and steal your computer. Or organize a group of mercenaries to take hostages at AT&T to gain access to your packets....hey we are talking about a nemesis right?

And here is an added bonus...how do you know that random password generator app isn't sending all your passwords to a master file? Whoa, did I just blow your mind?

Different passwords is all you need for protection. That way if the company loses your username/passwords, the bots that will be using that information to check the passwords on other sites, won't get a hit.

<comment><USER6> So, you made all kinds of awesome points that I went thru before i switched to random passwords...

a. (on not having access to your passwords). iPhone with them helps. (yes, i have to unlock that db with my hashing password). But in reality, I prefer that I can't get access to my email/facebook/whatever without having my machine. If i'm at work, I should be working... but it's the same machine anyhow ;)

b. true about stealing my machine. But again, my passwords are locked by my one key control password (which i don't easily remember either... yay for muscle memory ;)). Yes, it's a SPoF.

c. I clarified with Little Snitch. I don't really care that much. Because you're right: if one company screws you over and unveils your passwords, then having a scenario where people could then log into your email or bank means end of identity and a life of credit hell.

I just think that having a predictable password scheme is about the same as having _the same_ password. If it's easy to guess, then you may as well have the same. IMHO, the only way to guarantee against any problems if one of your passwords is exposed is to go random. :)

</comment></comment></comment></comment><comment><USER7> I don't think a boycott is the best way to proceed with this problem. For starters, I don't think you will get enough publicity to bring a boycott to critical mass. Secondly, I think it would be more useful and effective to send an email to the perpetrating website, inquiring or complaining about their password storage techniques. When customers/users complain, a good business will respond and attempt to resolve the problem.

<comment><AUTHOR> I agree with you. I have written to such website before but it is just more one thing to do and follow up on. I was thinking if I start collecting all of them together I can do some kind of bulk action one day. This blog entry is just the starting point and is no means the last action on this.

Boycott might be too strong of a word. I just want to bring attention to this point that the user community care about security and this is not a good practice.

</comment></comment><comment><USER8> I posted a similar screed about iPhone/Twitter apps that send passwords in the clear or with broken encryption a few days ago: <http://scott.wolchok.org/plaintext.html> (HN post at <http://news.ycombinator.com/item?id=877460>)

Not sure what is difference that made people care about this but not that, but open to enlightenment.

<comment><AUTHOR> May be it was my 'incredibly ignorant statement' :-) May be it was the title of the post.

Your post looks pretty relevant, related and good. I have voted it up if that helps.

</comment></comment><comment><AUTHOR> I am glad I am not the only one who feel sending passwords email is a bad thing:

[http://www.techconsumer.com/2008/02/11/bad-form-companies- st...](http://www.techconsumer.com/2008/02/11/bad-form-companies-still- sending-my-passwords-via-email/)

Thank you tomfakes for the comment.

</comment><comment><USER9> So, you're telling me I should boycott the tax office here ?

That'll go down real well with them. I think I'll skip this one.

</comment><comment><AUTHOR> At least record your protest or change your password to something not related to your real secret password.

</comment><comment><USER10> Ummm. Google Apps does this.

<comment><AUTHOR> I think Google Apps does this when you are setting up a new user account for other user. Sending that is different as in they need the password to access their account for the first time.

Although there are better ways to setup an account and may be gogle app should force the user to change their password on their first login but this is not the same as me setting up my own account and getting an email with my own password I just typed twice to register.

<comment><USER6> I think they also prompt new users to reset their password on first login too...</comment></comment></comment>


Test Driven Development Cargo Cult - <AUTHOR> http://ntoll.org/article/tdd-cargo-cult

<comment><USER2> tl;dr - Developer writes a legitimate test to prove Test Driven Development will force us to write decent code. We write code that cheats by using knowledge of the test to pass in the lamest possible way.

This proves that TDD is worthless? Really? I agree with his view that TDD has a "behaviorist" mindset if approached in the most superficial way. But, his example only shows that while you can go out of your way to perfectly cheat a unit test, if they had programmed a sensible component (that also happened to pass the unit test) they'd have some assurance that it was in good working order.

That's all that unit tests do. Create simple tests to assure basic functionality. Add more complex tests to verify more complex functionality and wider range of test cases. Rinse and repeat.

<comment><AUTHOR> > This proves that TDD is worthless?

No and the I don't think the article suggests anything along those lines or attempts to prove anything.</comment></comment>


University to require residents wear 'BioButton, to track health - <AUTHOR> https://www.clickondetroit.com/news/2020/08/03/oakland-university-to-require-residents-to-wear-biobutton-to-track-health-students-launch-petition/ <comment><USER2> I wonder if there are HIPAA implications around the data collected from these? This might be slightly more reasonable if HIPAA applies to this data. If not, I wouldn't step within 200 yards of those things.

From press releases, health insurance companies seem to love these things, which makes me very uneasy about how the data will be used.

</comment><comment><USER3> The button could also estimate if you were drinking alcohol based on the monitored changes. Next time a student says they need an extension, let's see what they were doing last night, and if they got proper sleep... _shudder_

What I'm surprised to see missing from this is proximity tracking to other buttons/phones. You would think that would be very useful for contact tracing

</comment><comment><USER4> Leaving aside my visceral reaction to attaching mandatory trackers to people:

>The "BioButton" is wearable technology that monitors your vitals, including temperature and heart-rate, in real time. It can last for up to 90 days. It's meant to be worn on the chest and connects to your mobile device.

Once again, technologists attempting to make covid solutions have forgotten that not everyone uses smartphones. On top of that, what're the odds that this doesn't work on any version of android older than oreo, or that don't have google play services installed?

</comment><comment><USER5> I certainly wouldn't wear that thing, but I imagine that most of the comments in this thread will say the same thing.

<comment><USER6> You would think so, I would hope so but truth is most people haven't learned to be afraid of this stuff. They have to relearn history's lessons and everyone else with them

</comment></comment><comment><USER7> It isn't required, but voluntary.

[https://www.clickondetroit.com/news/local/2020/08/04/oakland...](https://www.clickondetroit.com/news/local/2020/08/04/oakland- university-hopes-biobutton-can-help-prevent-spread-of-covid-19-by-monitoring- health/)

</comment><comment><USER8> There's something about this quote on the manufacturers website:

      The BioIntelliSense Data-as-a-Service (DaaS) platform and FDA-cleared BioSticker™ on-body sensor are bringing medical grade monitoring and management to the home for scalable remote care.

</comment><comment><USER9> How did this "BioButton" only seem to come into existence in the past few months?

What is this tech based on? What was it called pre C19? It seems suspicious to me.

The Cayman Islands are looking into it for visitors as well

[https://www.caymancompass.com/2020/07/23/government-gives- mo...](https://www.caymancompass.com/2020/07/23/government-gives-more-details- on-biobutton/)

</comment><comment><USER10> Nope, I can't imagine anyone that would want to use this.

</comment><comment><USER11> Surprise, location tracking built in. Forgot to mention until 6 months later :)

</comment><comment><USER12> Religious basis? What religion prohibits the biobutton?

<comment><USER13> Jews might have an issue with being 'tracked'</comment></comment>


The Reddit problem: Learning from mistakes - <AUTHOR> http://www.royans.net/arch/reddit-learning-from-mistakes

<comment><USER2> I've mixed feelings about this mistake.

Even if your error was not using consistent hashing, what's preventing you to modify the program in order to use two caching systems for a limited period (the time needed to rebuild the cache)?

So you can use a better distribution strategy, and finally shut down the old cache and use the new.

</comment><comment><USER3> I think Reddit will be doing something like that. Jereny from Reddit responded to the thread and mentioned they might be moving to cassandra. Its however not a trivial task for a site with that kind of load and data to cutover :) [http://www.royans.net/arch/reddit-learning-from- mistakes/com...](http://www.royans.net/arch/reddit-learning-from- mistakes/comment-page-1/#comment-534)</comment>


Intent to Deprecate and Remove: Trust in Existing Symantec-Issued Certificates - <AUTHOR> https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/rpxMXjZHCQAJ <comment><USER4> TLDR: Google has lost trust in Symantec's ability to properly validate certificates they issue. Chrome has a Root Certificate Policy that expects a CA to perform in a manner commensurate with the trust being placed in them and the Google team appears to see evidence that they are not living up to the standard laid out.

They propose a gradual distrust of existing certificates by reducing the 'maximum age' of the certificates with each release of Chrome.

EV certificates are proposed to have their EV indicators stripped _immediately_ until Symantec, for one year, demonstrates sustained compliance.

<comment><USER5> They're also planning on stripping EV status from their Certs too... that's going to be fun for a lot of banks.

<comment><USER6> Banks can just switch to better SSL services...

<comment><USER7> ha.ha.ha.

I worked at a financial institution for several years. There are many, many IT folks, internal auditors, and others who are probably wishing they wore their brown pants to work today.

SSL certificates are cheap in contrast to the labour intensive management practices that exist around them, especially around legacy platforms that may have been hardcoded to use certificates from a specific issuer (not that I have _ever_ seen that before, no one would be that foolish right? :/)

<comment><USER8> >especially around legacy platforms that may have been hardcoded to use certificates from a specific issuer (not that I have ever seen that before, no one would be that foolish right? :/)

D'ya know, I would have naively assumed this wasn't technically possible. I shudder not only to think of the code, but also of the thought process that could compel someone to undergo the effort of bricking themselves into this corner because honestly, that sounds a lot harder than doing it right.

<comment><USER5> It happened to me - I was working on an application for the pre-paid electricty system in Texas: the server-side code connects to a data-source over a TLS connection (complete with client-side certificates too), except the server-side used a self-signed certificate, and my code didn't have admin/root rights on the client hardware so it had to use in-app certification verification code. I had to hard-code the root CA's fingerprints directly into my code so it would be baked into the signed binary (this was a project requirement). That thing is going to fall-apart if the root CA ever changes - fortunately it won't expire until 2099.

(Yes, I gave the client a strongly worded statement of my misgivings - and all the other bad code-smells in the project)

<comment><USER9> So basically you're pinning the server certificate chain into your signed client code? Actually that sounds like a good thing!

[https://www.owasp.org/index.php/Certificate_and_Public_Key_P...](https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning)

<comment><USER7> Pinning is a good thing, assuming you have built in a reliable upgrade path (oh hey, browsers update themselves automagically now so yay!) but when you have occasionally connected devices that have low bandwidth that have a long deploy lifecycle, it's not always feasible, or even a good idea.

It's even worse if said device is embedded and has severe hardware constraints for compliance and regulatory reasons, and those same reasons prevent you from deploying patches on the regular.

Layer in some "built by the lowest bidder" and "accumulation of 30-odd years of poor practices for smart payment cards" and you have a big mess of a situation to unravel.

Oh yeah, and lest you think this is not an issue because this is browser related, may I introduce you to the world of services that proxy legacy green terminal applications into web front ends, ranging from IBM HATS to bespoke AJAXy things that unwrap screen scraped terminal emultor content from XMLHttpRequests.

Jeez. Remembering why I used to drink more when I worked in fintech :)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> If anyone here hasn't realised, Symantec bought Verisign back in 2010 - <USER2> own many brand names, like GeoTrust, Equifax, Thawte etc. You can see a list of their roots certs here: [https://chromium.googlesource.com/chromium/src/+/master/net/...](https://chromium.googlesource.com/chromium/src/+/master/net/data/ssl/symantec)

In case you missed it at the bottom:

> From Mozilla Firefox's Telemetry, we know that Symantec issued certificates > are responsible for 42% of certificate validations

<comment><USER11> Symantec bought Verisign's authentication business, still two different companies.

GeoTrust was started from buying Equifax's security business. Symantec bought GeoTrust. Symantec doesn't own the Equifax brand or company.

</comment></comment><comment><USER12> This is huge, Symantec owns about 15% of the SSL certificate market[1], and as stated in the article, has issued 30% of in-use certificates. No certificate authority of this size has ever been raked over the coals like this.

[1] [https://w3techs.com/technologies/history_overview/ssl_certif...](https://w3techs.com/technologies/history_overview/ssl_certificate)

<comment><USER13> Pretty much it will decide the question on whether or not the certificate system is even workable. My thesis is that either Symantec will not be able to respond (and so lose their ability to be a root certificate) in which case it will warn other root cert authorities to shape up or lose their business, or they will placate the Google and Chromium teams somehow and show that root cert authorities can be brought to bear.

Or they will ignore Google, continue to create bad certs, and users will start getting instructed by sites that they have to manually add a root certificate in order to use they site, and the entire ecosystem will collapse.

<comment><USER14> I think it's likelier that Symantec will start a negative PR campaign, leading its users to yell at google to change things, perhaps calling this FUD. Whether that'll be effective is another question.

<comment><USER15> _> Symantec will start a negative PR campaign, leading its users to yell at google to change things,_

It seems Google has the leverage, not Symantec.

A PR awareness campaign is out-of-band information that's separate from the web surfer actually navigating to a site. Millions of users would see a scary message similar to _" This site's security certificate is not trusted!"_[1].

To prevent scary security popups, which is more likely?

1) The website owners abandon Symantec and switch to a Certificate Authority not flagged by Chrome

or

2) Users get "educated" on Symantec's side of the story and manually add Symantec as a trusted root certificate. (Some can switch browsers but for many non-techies, that's a pain because they have all their bookmarks in Chrome -- and migrating them on mobile phone is not obvious.)

[1] [https://www.google.com/search?q=google+chrome+this+site%27s+...](https://www.google.com/search?q=google+chrome+this+site%27s+security+certificate+is+not+trusted&source=lnms&tbm=isch)

<comment><USER16> or

3) Large websites using Symantec certs start telling users Chrome is "broken" and we find out if users will switch browsers, not care about the security, and/or complain to the sites.

I definitely find any variation of #3 to be more likely than #2. I see it as a battle between #1 and #3.

<comment><USER15> _> Large websites using Symantec certs start telling users Chrome is "broken" _

I'm having a hard time thinking of a scenario where a large website concludes it's _cheaper_ to convince web shoppers at ecommerce sites and web visitors at news sites to _switch_ to Firefox/IE instead of the website just switching CA vendors.

If you're a website that wants to put up _zero friction_ between buyers submitting their credit-card info and _pay you money_ , why try to "educate" them? If you're a website that wants visitors to _see your ads_ next to your journalists' stories, why make it more difficult than it has to be? Does Symantec as a CA offer up extra benefits that no other CA has such that it makes sense to "train" web visitors to switch browsers?

Of the millions of non-geeks that use Android phones, what % download and use Firefox instead of the default Chrome browser?

<comment><USER17> This line of reasoning works for banks or commercial entities.

But note, it does not work for governments. They can, and will, put up a red banner instructing the user to install another browser (or in case of Firefox 52, explain how to disable updates so you can keep using NPAPI plugins).

<comment><USER15> Interesting point. I spot checked CAs for some of the most popular USA government websites.

irs.gov (Internal Revenue Service): Entrust CA

va.gov (Veterans Affairs) : Symantec CA

So if Symantec is the CA for a critical mass of government websites that won't abandon them, Google Chrome could lose this battle.

Without looking at traffic data (e.g Alexa), my intuition says the vast majority of web traffic is not government websites. If Veterans Affairs forces user to switch browsers, I'm guessing people would still use their Chrome browser for all the _other websites_ because that's where all their bookmarks live.

As for non-government websites, I notice that Netflix.com currently has a Symantec Class 3 CA. I'm guessing Netflix would rather switch to another CA.

<comment><USER17> I believe it is actually a matter of political campaigning in South Korea to get rid of ancient IE ActiveX requirements for government websites.

<comment><USER18> It's not just government websites, it's requirements that the government placed on _all_ e-commerce sites in South Korea.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> I've often wondered: why is trust in CAs an all-or-nothing proposition (aside from EV certs), and why should my particular browser vendor have all the authority over who I should trust?

For the vast majority of users that's probably just fine, but I would have thought that there'd be a browser or extension or something that allows security-conscious power users more fine-grained control over this by now.

For example, I could subscribe to changes in CA trust levels from _every_ major browser vendor, and if they don't agree my browser could show me a warning with an explanation.

Or I could subscribe to feeds from other entities I trust, like the EFF. Or my security-conscious friends.

Or if I decide I have lower trust in certificates issued by governmental CAs, or CAs in certain regions, I could mark them as lower trust.

Basically a web of trust for CAs.

<comment><USER20> > I've often wondered: why is trust in CAs an all-or-nothing proposition > (aside from EV certs), and why should my particular browser vendor have all > the authority over who I should trust?

It doesn't. You can adjust your root certs in Firefox by going to about:preferences#advanced and clicking on certificates.

But what does partial trust look like? Showing half of the HTML? An eyebrow raised emoji instead of a lock?

<comment><USER21> I wish CA management was easier to bulk-edit. Show me a table of root CAs with their data, their country of origin, etc., and allow me to filter and enable/disable all based on filters.

Full disable would shut down trust entirely, and get the warnings similar to a self-issued cert.

Reduced trust would have a "not Secure" label or something, like a plain http connection.

<comment><USER22> "Country of origin" is a really interesting one for precisely the Symantec scenario.

Symantec is a US company right? But the main _problem_ happened at a company called CrossCert, full name Korea Electronic Certification Authority. They're Korean.

So if you decided you don't trust Koreans, Symantec's root looks fine, nothing Korean about that. Except, somewhere Symantec signed a contract with CrossCert saying "OK, we'll issue any certificate you want, so long as you pay us and promise to do all these things". Oh, and then they didn't actually check CrossCert did any of the other things (I think we can assume they checked they got paid...). You don't get to see that contract. It wasn't even prohibited by the rules Symantec had agreed to. If Symantec hadn't been caught issuing bogus certificates as a result you wouldn't even be reading about it.

</comment></comment></comment></comment><comment><USER23> It looks like the questions that Google/Mozilla asked Symantec and didn't like the answers to are posted here:

[https://knowledge.symantec.com/support/ssl-certificates- supp...](https://knowledge.symantec.com/support/ssl-certificates- support/index?page=content&id=INFO4154)

(Archive link: [http://archive.is/Cq9VO](http://archive.is/Cq9VO) )

Really interesting reading!

<comment><USER22> Because the process happens in the public newsgroup mozilla.dev.security.policy anyone with a legitimate interest in the Web PKI can ask questions during incidents like this or indeed during Mozilla's new CA application process.

Some of the questions on that list are mine. I don't remember if representatives from Google or Mozilla explicitly told Symantec they needed to answer my questions, beyond a certain point it's implied that smart questions (and I hope mine are smart) should be answered regardless of who asks them.

Other than Google and Mozilla, major trust stores mostly prefer to conduct their activities in private, so we don't know what (if anything) Symantec were asked by Microsoft, Apple, etc.

</comment></comment><comment><USER24> I was curious if this would affect my Symantec issued certs... according to my date math:

Chrome 59 (Apr 13, 2017) +1023 days: 2020-01-31

Chrome 60 (May 25th, 2017) +837 days: 2019-09-09

Chrome 61 (Jul 20th, 2017) +651 days: 2019-05-02

Chrome 62 (Aug 31st, 2017) +465 days: 2018-12-09

Chrome 63 (Oct 12th, 2017) +279 days: 2018-07-18

<comment><USER25> If I'm reading the post right, it's stricter than that:

> ...distrusting certificates whose validity period (the difference of > notBefore to notAfter) exceeds the specified maximum.

I.e., a certificate valid from 1/2015..1/2019 is distrusted as of Chrome 59.

And the more lax restrictions only apply to certificates that have already been issued. Any one issued after Chrome 61 are held to the highest (9 mo) limit.

> In addition, we propose to require that all newly-issued certificates must > have validity periods of no greater than 9 months (279 days) in order to be > trusted in Google Chrome, effective Chrome 61.

<comment><USER24> I agree with the newly issued certs. The other, that's going to be painful, and a mess to figure out, if you are right.. and that's quite possible that you are. UGH.

EDIT: Update, I'm not sure you are correct, I just downloaded the latest dev release (Version 59.0.3047.0 (Official Build) dev (64-bit)) and it accepts a rapidssl issued(symantec owned) cert valid for 1187 days, which would exceed the 1023 days.

It's also possible it just hasn't made it into the release yet, I'll have to keep like a daily eye on this, and plan to replace much much sooner just in case.

<comment><USER26> > It's also possible it just hasn't made it into the release yet,

The proposal was just made, so you shouldn't expect it to be reflected in code just yet.

</comment></comment></comment></comment><comment><USER27> > _All Symantec issued certificates. GeoTrust and Thawte are CAs operated by > Symantec, simply afforded different branding.

>While this list may need to be updated for some recently created roots, [https://chromium.googlesource.com/chromium/src/+/master/net/...](https://chromium.googlesource.com/chromium/src/+/master/net/data/ssl/symantec/README.md) may accurately capture the state of impact_

Damn. There goes my certificate (Rapidssl). Anybody know what are the remaining, trustworthy certificate issuers ?

No we cannot use LetsEncrypt for convenience reasons (we bake our certificate pub key in many places)

<comment><USER28> I have heard lots of good things about Digicert, FWIW. No personal experience as my use case can be covered by LetsEncrypt.

<comment><USER29> Digicert works for us. Wouldn't mind switching to LetsEncrypt but vendors are the issue (oh, the joy of approved lists).

</comment></comment></comment><comment><USER30> > Intent to Deprecate and Remove: Trust in Existing Symantec-Issued > Certificates

When I read that something like this popped up in my head:

"Google is using the nuclear option on Symantec. Neat!"

<comment><USER31> Perhaps it's neat for you, I just found out that our newly issued EV certificate status is being revoked in the next build of Chrome, so our expensive EV certificates may as well be $5 StartSSL certificates.

I imagine that there will be a lot of angry customers asking for refunds from Symantec/Verisign for certificates already issued which no longer conform to the offered product.

<comment><USER32> I for one find it totally neat that people realize their expensive EV cert was a waste of money. Although that was true before, too. EV certs are a waste of money, the only thing they do is show a green bar. They don't improve security.

<comment><USER33> EV certificates have the same level of confidentiality and integrity as DV certs, but they have different authentication - specifically, they tie the certificate to a legal entity rather than a domain name.

ie.

        https://paypal.com-customerservice.ru

vs

        PayPal Inc [US] | https://paypal.com

I run [https://certsimple.com](https://certsimple.com). We sell EV certs. But you can verify the above pretty easily by checking out the EV guidelines, the additional requirements that apply only to EV certs ([https://cabforum.org/extended-validation/](https://cabforum.org/extended- validation/)). You can also see the difference with openssl pretty easily:

Here is a DV cert:

        openssl x509 -in domain-validated-example.com.crt -noout -text | grep Subject
         OU=Domain Control Validated
         CN=example.com
         DNS:example.com

Here is an EV cert:

        openssl x509 -in extended-validated-example.com.crt -noout -text | grep Subject:
           jurisdictionOfIncorporationCountryName=GB
           businessCategory=Private Organization
           serialNumber=09378892
           C=GB
           ST=City of London
           L=London
           O=example Limited
           CN=example.com
           DNS:example.com -

<comment><USER26> If a site with an EV cert is being spoofed using a similar-looking domain name and a DV cert, how realistically is the user going to remember that the real site is supposed to have an EV cert? (Besides just maybe remembering it for Paypal in particular.)

See also the Nordea section at [https://hsivonen.fi/bank- idp/](https://hsivonen.fi/bank-idp/) . How is a user supposed to form a mental model about multi-server org who don't use EV consistently?

<comment><USER33> That's a legitimate concern. The bank in the link is harming itself with mixed validation and further issues with mixed content (and yes the banking industry surprisingly bad at crypto - Barclays in the UK has mixed content issues pretty frequently).

There's no simple, single answer here: you can stop validation downgrades is pinning to EV roots but browser UI is also a huge part: mobile Safari, for example, simply uses the validated legal entity as the address and keeps it on screen during the entire session (even when you scroll). Visit [https://stripe.com](https://stripe.com) on mobile Safari and you'll see

> _______________Stripe Inc.______________

...persistently on top of the screen throughout the entire session [1]. Other browsers don't show validated identity as effectively though.

[1] Safari should also add a country indicator to distinguish other validated legal entities called 'Stripe, Inc.' in different jurisdictions.

</comment></comment></comment></comment></comment></comment><comment><USER34> Good. The security of certificate system is dependent on an incentive model where misbehavior is punished with revocation. It is important not just because we shouldn't give individual authorities trust after they have demonstrated themselves untrustworthy (although that is an important factor), but also as a punitive measure to disincentive misbehavior.

</comment><comment><USER35> It amazes me how often Symantec is in the news about the same subject, yet they seem to be incapable of learning a lesson from it.

<comment><USER36> As they say "It is difficult to get a man to understand something, when his salary depends upon his not understanding it."

<comment><USER37> I don't think that's the case here, I think Symantec understood perfectly but thought they were too big to get anything more than a slap on the wrist from Chrome. Chrome's previous sanctions on Symantec, though very helpful for those trying to evaluate Symantec and inconvenient to implement on Symantec's side, were not much of a threat to their business.

</comment></comment></comment><comment><USER38> Google's also been looking to limit the maximum validity lifetimes in general through the CA/B Forum[1] in a ballot that ended up not passing (with hints[2] that Chrome would end up enforcing something similar itself even if it wasn't part of the Baseline Requirements).

This seems to be indicative of the general indication that Chrome wants to head in anyway[3].

[1] [https://cabforum.org/pipermail/public/2017-January/009373.ht...](https://cabforum.org/pipermail/public/2017-January/009373.html)

[2] [https://cabforum.org/pipermail/public/2017-February/009746.h...](https://cabforum.org/pipermail/public/2017-February/009746.html) \- there was a more explicit post elsewhere but I can't find it in the archives right now

[3] [https://twitter.com/sleevi_/status/829804370900426752](https://twitter.com/sleevi_/status/829804370900426752)

<comment><USER39> > with hints[2] that Chrome would end up enforcing something similar itself > even if it wasn't part of the Baseline Requirements

Kinda undermines the idea of having a standards group if Google is going to strongarm the industry by doing their own thing anyways

<comment><USER40> "Baseline Requirements" sort of implies that what is specified is minimum, rather than exhaustive, rules, and that specific applications will have additional rules.

<comment><USER22> And they all do.

Mozilla's rules are public so you can go read them, and indeed you can help write them. But most famously they required all CAs to disclose loads of stuff, and they require CAs to do lots of stuff in public where everybody can see it, not behind closed doors where we don't know what they're up to.

Google's rules include lots of stuff about their Certificate Transparency idea, which has helped no end.

Microsoft's rules famously include them getting a veto where they can order any CA to revoke a certificate or else leave their trust programme. They mostly use this to zap malware / phishing sites.

Apple's rules forbid having lots of roots at once. Although apparently this didn't apply to Symantec, or various other people. Huh.

</comment></comment></comment></comment><comment><USER41> Symantec thinks Google is being inflammatory. Symantec fired the people who made the test cert a couple of years ago.

Here's Symantec's press release:

Google's statements about our issuance practices and the scope of our past mis-issuances are exaggerated and misleading. For example, Google's claim that we have mis-issued 30,000 SSL/TLS certificates is not true. In the event Google is referring to, 127 certificates – not 30,000 – were identified as mis-issued, and they resulted in no consumer harm. We have taken extensive remediation measures to correct this situation, immediately terminated the involved partner's appointment as a registration authority (RA), and in a move to strengthen the trust of Symantec-issued SSL/TLS certificates, announced the discontinuation of our RA program. This control enhancement is an important move that other public certificate authorities (CAs) have not yet followed.

<comment><USER22> The 30 000 certificates don't have any documentation. The BRs require that a CA keeps documentation showing how they validated the Subject, because without that any CA could issue anything and then say "Er, I forget why, but it was definitely OK" and who can prove they were wrong?

CrossCert wasn't able to produce any documentation for the certificates they got Symantec to issue. Maybe their dog ate it, or they kept it in the Recycle Bin on somebody's laptop and then mistakenly hit "Empty" one day. Most likely they simply never created the documentation at all, because Symantec had never asked them to produce it, so why bother?

But that means we have no reason, other than a general sense that CrossCert appear to have been incompetent rather than malevolent, to believe any of those certificates was actually validated. On that basis they're mis-issued, and so Symantec revoked them.

The 127 certificates discovered by investigators are clearly bogus, some aren't even for valid domain names, but the thousands of others weren't magically fine - we have no idea, and not having any idea is itself unacceptable.

It is true that Symantec shut down their entire RA partner programme (the relationship with CrossCert and half a dozen others) without explicitly being told to do that, and personally I felt that might be enough, but Google clearly don't see it the same way.

</comment></comment><comment><USER42> Not much focus in the comments has been put on the 9-month certificate validity, but it seems like that is going to be almost as big a punishment for Symantec as the deprecation. Because dealing with SSL is so painful for some large corporates, being told that you have to go from a 3 year renewal schedule to a 9 month one would be enough to cause many to go looking elsewhere.

<comment><USER23> Since certificate revocation is pretty much unworkable, reducing the maximum lifetime of certificates is probably a good thing for security in general.

</comment></comment><comment><USER43> SYMC is at an all time high, and every one of their EV certificate customers is about to start talking to different security vendors. The Jan18, Jan19 near ATM puts are quite reasonably priced.

<comment><USER44> Crazy! A third of SYMC's revenue might be going POOF! and the market is just shrugging?

<comment><USER45> They'll all be caught by surprise and lose their shirts when Symantec releases their financials next quarter and the stock tanks. The market is full of ignorant people.

<comment><USER46> Just remember that the market can afford to be wrong longer than you can afford to bet against it.

<comment><USER43> Usually I agree, but SYMC is at an all time high and trading at 40x price per earnings. The price already implies a massive bet on increased profits, but there is no way that is going to happen.

</comment></comment></comment></comment></comment><comment><USER47> It's a bit scary how much power do browser creators wield. Even if it's being used for good.

<comment><USER48> It's better than it used to be. We have 4 major browser vendors now, Apple (Safari and iOS), Microsoft, Google (Chrome and Android), and Mozilla, all of which have plenty of market share and none of which have most of it.

There was a long period of many years when IE was king and anything else was irrelevant. There was also, even earlier than that, a period where Mosaic/Netscape/Mozilla and its kin were dominant.

This is the best it's been in a long time in terms of no single browser maker controlling the market.

<comment><USER49> Indeed, there was a set of roots IE 5.01/NT4 SP6/Win2000 and later trusted, and at that time only XP did automatic root cert update making them very valuable. Just before then, I think IE/SChannel only trusted VeriSign/Thawte/CyberTrust, and VeriSign bought Thawte just after IE 5.01 and NT4 SP6 was released.

</comment></comment></comment><comment><USER50> Related: not valid certs should show a red warning after accepting them: [https://bugzilla.mozilla.org/show_bug.cgi?id=1349897](https://bugzilla.mozilla.org/show_bug.cgi?id=1349897)

is this for all the certs or just symantec certs?

</comment><comment><USER51> Why not immediately begin treating these connections as plain HTTP? Don't show the padlock or "Secure".

Don't fail the connection, so people will still be able to use the site, but don't present it as secure.

This would be a stronger action than treating EV certs as non-EV, which only a few geeks will notice. Or reducing the maximum age of certificates.

<comment><USER52> And teach your grandpa it's ok if his bank's website no longer displays that green address bar?

<comment><USER51> Making your grandpa think everything is right with the bank defeats the whole point of what Google is trying to do.

</comment></comment></comment><comment><USER53> Symantec being well... Symantec, I'd expecting them to lawyer up in order to delay, or outright block this.

They're big enough to afford the higher end law firms likely needed too. :(

<comment><USER54> They're not bigger than Google. And it's Google's browser and the open source Chromium project, so I'm having a hard time seeing how Symantec is going to get a judge to say anything along the lines of "I forbid any and all members of the Chromium project to commit anything to the codebase that would no longer treat Symantec issued certificates as before". Especially considering since plenty aren't under US jurisdiction nor necessarily employed by Google.

Then they'd also have to strong arm Mozilla, Apple and Microsoft since they're rather likely to act too and at least the latter two don't disclose such changes until they've made them.

<comment><USER53> Sure, it'd probably be an uphill battle.

But, Symantec has generally shown little/no morals in past times when it comes to attempting to protect their business interests. Not really seeing why this would be different. :/

</comment></comment></comment><comment><USER55> Anyone have any more information on the incidents that triggered this response? I was able to find this article on Google's Security Blog: [https://security.googleblog.com/2015/10/sustaining- digital-c...](https://security.googleblog.com/2015/10/sustaining-digital- certificate-security.html)

But that's almost 2 years old. Have there been any more recent incidents that I'm unaware of?

<comment><USER56> [https://www.mail-archive.com/dev-security- firstname.lastname@example.com...](https://www.mail-archive.com/dev-security- email@example.com/msg05455.html)

<comment><USER57> TL;DR: in 2016 Symantec issued unauthorized certs for example.com (owned by ICANN) and a multi-domain cert with SANs for test1.com, test2.com, test3.com... even though those domains are each owned by very different organizations and did not all agree to have a common cert.

<comment><USER56> It's more than that. The ensuing thread uncovered that Symantec had exercised very lacking oversight over their partners (called Registration Authorities, or RAs) who were allowed to perform certificate validation on Symantec's behalf.

<comment><USER58> ...and at least one of those RAs didn't seem to be doing any validation at all!

</comment></comment></comment></comment></comment><comment><USER59> What's Mozilla doing?

<comment><USER17> [https://groups.google.com/forum/#!topic/mozilla.dev.security...](https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/kxs3kyqRqYU)

As far as I can tell, discussion about what to do with Symantec was ongoing, Google didn't think the outcome was going to be what they wanted, and then enacted a different policy on their own.

</comment></comment><comment><USER60> We need a service to check if your certs could be flagged as bad. Especially since this spans so many brands (Symantec, Equifax, VeriSign, GeoTrust, Thawte, etc). Something like, plug in the domain name, and it'll tell you if you need to update the cert.

<comment><USER23> Since Google typically enacts the restricts through major Chrome updates, running the Beta version of Chrome can give you some early warning at least.

</comment></comment><comment><USER61> Is there a list anywhere of which EV cert providers use Symantec as a CA?

<comment><USER62> From the Google link on Symantec root certs:

[http://pastebin.com/raw/nUEq5cFP](http://pastebin.com/raw/nUEq5cFP)

Not sure if all of them issue EV.

<comment><USER10> I extracted a readable list of cert providers:

      Equifax
      VeriSign
      TC TrustCenter GmbH
      RSA Data Security
      Equifax Secure
      Symantec Corporation
      GeoTrust Inc.
      Thawte Consulting cc
      thawte
      Thawte Consulting
      Equifax Secure Inc.
      TC TrustCenter for Security in Data Networks GmbH
      The USERTRUST Network
      Thawte

Source here in case I screwed up or anyone wants to verify my terrible regex: [https://gist.github.com/JodiWarren/376aebbf7ce6902b06766843f...](https://gist.github.com/JodiWarren/376aebbf7ce6902b06766843f4d44dc7)

</comment></comment></comment><comment><USER63> I do not know how to observe if this has been accepted, does it not require 3 others to approve and say 'looks good to me' to continue with this proposal?

sorry if I missed this...

</comment><comment><USER50> But why is [https://w3techs.com/technologies/history_overview/ssl_certif...](https://w3techs.com/technologies/history_overview/ssl_certificate) saying Let's Encrypt has 0.1% when [https://letsencrypt.org/stats/](https://letsencrypt.org/stats/) says 32 million Fully-Qualified Domains Active?

32 million = 0.1% 32 000 million SSL certs? = 100%

? what?

<comment><USER64> TLDR: Look at the IdenTrust numbers if you want to know the real Let's Encrypt numbers.

Not many people use Let's Encrypt's own root for their validation chain when they use Let's Encrypt certificates. The Let's Encrypt root is not propagated widely enough across clients.

We (Let's Encrypt) have a cross-signature from IdenTrust, that's what most people use because it's widely trusted. IdenTrust issuance is otherwise very small, so you can effectively consider the IdenTrust numbers in charts like this to be a proxy for Let's Encrypt.

-Josh from Let's Encrypt

<comment><USER65> W³Techs also understates the fraction of "web sites" that use LE certs because it counts only the 10,000,000 top sites. But LE alone has current valid issuance covering over 30,000,000 subject names, most of which are small sites not in the top 10,000,000 sites by traffic volume or search engine ranking.

[https://w3techs.com/technologies](https://w3techs.com/technologies)

[https://letsencrypt.org/stats/](https://letsencrypt.org/stats/)

</comment></comment></comment><comment><USER66> in _chris palmer_ mar 23, 19:33 (9th answer)

> _Combined with the gradual move to certificates with shorter lifespans > anyway (as a way of coping with problems like this, and with the difficulty > of certificate revocation generally), automation is a necessity going > forward._

Interesting. What are the effects of _automation_? E.g. is it possible to automate the update of EV certs? Is this opinion fueled by the idea that websites should be hosted in the public cloud? What is OWASP's stance?

Where can I find more on pro & con automated cert renewal? Around the time when Letsencrypt was introduced, there must have been someone who wrote an informed article/blog on _automated cert renewal_.

</comment><comment><USER67> I'd rather trust Google to be a/the defacto CA than some has been AV company.

</comment><comment><USER24> What is the chrome release schedule? i.e. what is the timeline for the 59 - <USER3> releases to happen? A quick google isn't getting me an answer(and I don't use Chrome, so don't really pay attention).

<comment><USER68> What'd you search for? I typed in: chrome release schedule

and this was the first link: [https://www.chromium.org/developers/calendar](https://www.chromium.org/developers/calendar).

<comment><USER24> Thanks! My date math says:

Chrome 59 (Apr 13, 2017) certs invalid after 2020-01-31

Chrome 60 (May 25th, 2017) certs invalid after 2019-09-09

Chrome 61 (Jul 20th, 2017) certs invalid after 2019-05-02

Chrome 62 (Aug 31st, 2017) certs invalid after 2018-12-09

Chrome 63 (Oct 12th, 2017) certs invalid after 2018-07-18

</comment></comment></comment><comment><USER69> PKI is broken. The problem isn't the crypto, it's the wardens.

</comment><comment><USER70> Unless Mozilla and IE goe along with this, effected orgs could just inform users that Chrome is not a supported browser? Have we heard from the other browser vendors?

<comment><USER71> Let's be honest, switching your cert is a far cheaper option than the lost business of telling 50% of your users that they need to switch browsers. Whith ecommerce sites being so hyper focused on abandoned cart stats, this is the easiest change they'll make all year.

<comment><USER70> For ecommerce yes, but the people most impact here are prob. banks... and if somones back tells them they have to install and use FF or use Edge over Chrome, they will probably do it.

</comment></comment></comment><comment><USER72> "...pour encourager les autres"

<comment><USER73> In English please?

<comment><USER72> _Byng 's execution is referred to in Voltaire's novel Candide with the line "Dans ce pays-ci, il est bon de tuer de temps en temps un amiral pour encourager les autres" – "In this country, it is wise to kill an admiral from time to time to encourage the others."_[1]

[1] [https://en.wikipedia.org/wiki/Battle_of_Minorca_(1756)](https://en.wikipedia.org/wiki/Battle_of_Minorca_\(1756\))

</comment></comment></comment><comment><USER74> Why trust central CA who say security charge for it but do not implement it? Why not instead use a distributed security model such as LetsEncrypt and Blockchain?

The whole security model of the web is quite centralized maybe we need something more distributed? What if you had strong hashing on content, distributed webservers and distributed content?

</comment><comment><USER75> I'd be very surprised if Symantec doesn't have some backroom deal with intelligence agencies, and not just in the U.S. either, especially since they've acquired BlueCoat - a "security company" known for selling surveillance tools to authoritarian regimes - and after they made the BlueCoat CEO the CEO of Symantec.

<comment><USER76> Prior to the Symantec aquisition, VeriSign used to pitch just this thing as a product. AFAIK the usage was limited to DoD and a few mundane things.

The IC wasn't interested because it was easier for them to just steal certificates or work around TLS completely.

<comment><USER75> Interesting that it would be "so much easier" for the U.S. intelligence community to steal most certificates or work around TLS, when countries like Thailand, which have much fewer resources, prefer to get Microsoft to install their own root certificate for them in Windows. Perhaps this is what the IC meant as well, when it said there are other easier ways? Why bother with Verisign's solution, when they could have their own root certs in Windows?

The CA system is such an untrustworthy mess.

[http://www.theverge.com/2017/1/25/14381174/microsoft- thailan...](http://www.theverge.com/2017/1/25/14381174/microsoft-thailand- government-surveillance-thai-censorship-encryption)

<comment><USER76> Because using your own CA is not deniable. You aren't allowed to move forward with any solution that may lead to attribution.

</comment></comment></comment></comment><comment><USER77> TL;DR Google prefers to override what the standards say about validity of certicates instead of what would be the logical thing: stop trusting Symantec root Certs. A dangerous precedent.

<comment><USER54> Google is divesting trust from Symantec but is doing it in a way that avoids hurting end-users and badly breaking the internet. They explicitly state why they don't just want to revoke it in one go and they have really decent arguments. What are yours?

Aside from that, to the best of my knowledge the CA/B forum doesn't set forth any rules that require the immediate and complete removal of trust of a CA that is found to be in violation of the guidelines. I also don't see how they could, the best they could do is put out some form of recommendation but it's up to the parties that actually include the CAs to decide how they get removed, which is normally stipulated in the rules for inclusion in a Root Certificate bundle.

</comment></comment><comment><USER78> Are they just hoping to drive business to their new CA: Google Trust Services?

<comment><USER79> That's unlikely, as they currently do not offer certificates to the general public. I imagine if they do at some point, it might be as part of something like their version of Amazon's ACM for their Cloud offerings, or for custom domains on sites like Blogger. I'd expect both to be free. They're also a platinum sponsor of Let's Encrypt.

<comment><USER80> This happened recently with all my free StartSSL / Startcom certificates. I switched to LetsEncrypt. Also noticing Google and Mozilla's sponsorship.

<comment><USER17> Google and Mozilla were heavy sponsors of LetsEncrypt (in money and in Mozilla's case manpower too) because they wanted to push out HTTPS more, and mandate HTTPS for some new HTML features. That would have been problematic if certificates weren't free or convenient.

In Mozilla's case, HTTPS is better for privacy. In Google's case, HTTPS makes it harder to substitude their ads.

</comment></comment></comment></comment><comment><USER52> TLDR: for the next few months, expect to tell your relatives "just click yes on the big red warning dialog". Not sure if this is good conditioning.

<comment><USER79> The schedule they're proposing tries to specifically avoid as much of this as possible. This is probably as close to "no impact for average users" as you can get if you don't want to accept that too-big-to-fail is a thing in the Web PKI.</comment></comment>


The Fictional Nuke Film That Won the Oscar for Best Documentary - <AUTHOR> https://medium.com/war-is-boring/the-fictional-nuke-film-that-won-the-oscar-for-best-documentary-b63b42798aeb

<comment><USER2> Another classic British film on the subject was _Threads_. It's basically "Well, wow, we're rather boned while the US/NATO and the Soviets hash it out."</comment>


Activists Release Nearly 100 Years of TIME Magazine Issues for Free - <AUTHOR> https://motherboard.vice.com/read/activists-release-nearly-100-years-of-time-magazine-issues-for-free <comment><USER2> All of that information is already available from other sources for free. The only thing released that wasn't already accessible was the presentation and art-work from TIME. I hate feeling like I have to chime in on the side of large organizations against individuals, but in this case the thieves are absolutely in the wrong.</comment>


MapKit JavaScript (Beta) - <AUTHOR> https://developer.apple.com/maps/web/ <comment><USER2> Having all those examples on the same page is a really bad idea for mobile; they all block each making it the page pretty much unusable.

</comment><comment><AUTHOR> Could this be an alternative to Google Maps?</comment>


Bringing Clang to Windows - <AUTHOR> http://blogs.msdn.com/b/vcblog/archive/2015/05/01/bringing-clang-to-windows.aspx <comment><USER3> I agree with folks who think this is a bit confusing.

This blog post is announcing:

1\. Using clang as a frontend.

2\. Using C2 (MS compiler) as a backend.

What the LLVM community (IE not MS so far, but participation is of course, welcome)) has been building:

1\. Using clang as a frontend

2\. Using llvm as a backend

and even more specifically

1\. Using MS Headers + MS Libraries

2\. Using clang as a frontend

3\. Using llvm as a backend.

(see blog.llvm.org/2014/07/clangllvm-on-windows-update.html for a 9 month old view)

Some of the mingw32 folks have been working on replacing #1 with non-ms stuff, but let's put that aside for the sake of this description )

Using clang as a frontend is where almost all of the ABI compatibility happens anyway (and where various developers have been focusing), so you end up with VC++ ABI compatible binaries whether you use C2 or not, if you/they use the pre-existing clang stuff.

Whether they are doing that (and then lowering llvm ir to c2 ir) , or if they've built an alternative IR generation with clang (IE generating c2 ir directly from clang), that they haven't released, is not clear.

If they've built something that generates C2 IR from clang, they would have had to write their own ABI compat, which would mean it may be different than the binaries clang would build.

(exception handling is also codegen'd by llvm, so exception handling could end up different, though of course, compatibility is the goal)

<comment><USER4> Hi DannyBee, sorry if we didn't get the message out clearly. Jim Radigan gives a deeper technical explanation in the build talk he did yesterday. [http://channel9.msdn.com/events/Build/2015/3-610](http://channel9.msdn.com/events/Build/2015/3-610) It's translating LLVM IR to C2 IR. We know that the Clang/LLVM community is hard at work on implementing the MS-ABI and we've reached out to a few developers working on ABI stuff as well as symbols support. We intend to engage with that community more openly now that we've announced but of course shipping the code will be our top priority. One important contribution of the Clang/C2 approach is that we will have full native VS debugger support. This is just the first step in a longer journey. Thanks, Steve, VC Dev Mgr

<comment><USER5> Hello! Is there any chance that this would work with other language front-ends that generate LLVM IR?

<comment><USER4> see Jim Radigan's build talk on compiling Objective-C for windows for more info on this :)

</comment></comment></comment></comment><comment><USER6> I'm a bit confused about how this will work exactly. If I have Clang and VC++ compiled code trying to interop with each other, what happens if Clang decided to use a different memory layout for std::string (or any other type really) than VC++? What compiler is doing which task in the pipeline here exactly?

I mean, the reason everyone does interop strictly in C is that there are zero standards for how a compiler implements the C++ features exactly down-low.

<comment><USER7> Clang has, for some time now, supported the MSVC ABI.

Here is their implementation of name mangling: [http://llvm.org/viewvc/llvm- project/cfe/trunk/lib/AST/Micros...](http://llvm.org/viewvc/llvm- project/cfe/trunk/lib/AST/MicrosoftMangle.cpp?revision=235831&view=markup)

Here is their implementation of record layout: [http://llvm.org/viewvc/llvm- project/cfe/trunk/lib/AST/Record...](http://llvm.org/viewvc/llvm- project/cfe/trunk/lib/AST/RecordLayoutBuilder.cpp?revision=235680&view=markup#l2075)

Here is their implementation of vtable generation: [http://llvm.org/viewvc/llvm- project/cfe/trunk/lib/AST/VTable...](http://llvm.org/viewvc/llvm- project/cfe/trunk/lib/AST/VTableBuilder.cpp?revision=236355&view=markup#l2384)

Here is their implementation of RTTI: [http://llvm.org/viewvc/llvm- project/cfe/trunk/lib/CodeGen/Mi...](http://llvm.org/viewvc/llvm- project/cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp?revision=236161&view=markup#l2919)

Here is their implementation of C++ throw metadata: [http://llvm.org/viewvc/llvm- project/cfe/trunk/lib/CodeGen/Mi...](http://llvm.org/viewvc/llvm- project/cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp?revision=236161&view=markup#l3644)

<comment><USER8> But none of that was written by Microsoft employees, so I'm a bit confused about what exactly this blog post is announcing. It feels a bit like they're taking credit for the work done by the clang community.

<comment><USER4> We are announcing that we will ship a hybrid compiler that combines the clang frontend with the c2 existing backend. We will fully support that for building portable code within Visual Studio for Windows. We definitely don't want to take credit for the clang community's work. We have a ton of respect for those developers. We intend to make contributions back to the community and we've started to reach out to some of the relevant parties. Thanks, Steve, VC Dev Mgr

</comment></comment></comment></comment><comment><USER9> I'm starting to see a strategy here. I've been wondering how Microsoft can make money from all.this open source activity. Their platform is becoming obsolete, but is being replaced by OSX, iOS, and android. That makes developers unhappy because of the multiple OSes they need to support. But MS can step in and bring their own platform as an abstraction over these others and make developers happy. Build once, target everything. I'm betting key pieces will not become open source, they want to have control over the new platform. That is the midterm goal - regain control (even a little bit) of a dominant platform.

<comment><USER10> Windows is not becoming obsolete. Quite the opposite. In the enterprise Windows will stay for a long time. I'm working at company > 500000 employees and our IT will be very happy when they can replace the iOS devices with Windows equivalents. And certainly the Desktops aren't going to be replaced by OSX. Even more with Windows 10 around.

MS strategy is much more straight forward. Simply offer reasons and make it easier for customers to use their products. Mainly the cloud and mobile services. They're just smart enough to understand where Google and Facebook make their money with - not by selling OS.

<comment><USER11> I agree. We've been using OpenLDAP for 3 years now, and it has been a very scary, black magic experience, just trying to get basic stuff like DNS, NFS, mac, windows clients, working. Hoping to move to Windows AD as soon as possible.

</comment></comment></comment><comment><USER12> Hell yeah! Microsoft just became one of the viable platforms this week in the cheap segment with reasonable licensing.

<comment><USER13> Still not in the free as in speech and beer segment though.

</comment></comment><comment><USER14> "So, any minor divergence in features of Clang and Visual C++ will cause you as a developer to have to worry about these compiler differences or limit you to using the smallest subset of the two compiler features"

In other words, the set of vc++ features.

<comment><AUTHOR> Yes. We know we are behind on conformance.

</comment></comment><comment><USER15> Wow! Microsoft! Wow! You should've had Satya Nadella as CEO ages ago! Congrats!

</comment><comment><USER16> At approx. 26min he mentions four processors that their code generator has to target: ARM32, x86, x64, and a new one coming out in the fall. What would that be? ARM64? *edit - never mind. Last five seconds they hint at it as arm64. MS is definitely doing some interesting stuff these days.

</comment><comment><USER17> If the Windows team at MS thinks of c2 and the MS linker as part of the Windows ABI, then I guess the MinGW toolchain (and a hypothetical clang toolchain where LLVM generates the native code) will always be second class, and therefore best avoided by developers who want to target Windows, even for classic Win32 desktop apps.

<comment><USER18> It all depends on how cutting edge you want to be in the windows platform. If you want access to the latest technology, MS tools will always be the necessary choice -- Borland learned this lesson after a lot of hard work. But if you want to create products using the stable version of the windows API, gcc is already a very good choice.

<comment><USER19> I kind of disagree here. Compilers reached commodity status a long time ago. Nobody makes money off them compared to how it was in the 90s and the list of ex-compiler makers is as long as your arm (Watcom, Metrowerks etc).

'clang' is probably approaching the point that its good enough so the question for Microsoft is do they still see any value in continuing the develop their own compiler or should they just switch to 'clang' ?

I think this is the big shift we are seeing in MS this year. Instead trying to owning everything, they seem to be shifting their focus to owning the parts that have value and commoditizing the rest. The strategy was successful for Apple so its unsurprising that Microsoft is looking to a similar strategy as part of their salvation.

<comment><USER18> I think they want compatibility with other compilers, but unless they move alway from Windows, there is a lot of their APIs that require close compiler/library support: COM, DCOM+, .NET, etc. They will probably need at least to maintain VC++ for a long time.

<comment><AUTHOR> Add WinRT to that list and you have a set that is somehow reason enough for Visual C++ compiler front-end to stay relevant.

</comment></comment></comment></comment></comment><comment><USER20> The broader stroke is MS to be relevant in the platforms side of the story. Sometime people will argue that windows is used extensively in enterprises, but obviously the today startup which will be tomorrows enterprises are using almost no MS eco system.

</comment><comment><USER21> Where does C2 come in on the stack? Is it compiling/translating LLVM IR?

<comment><AUTHOR> The latter.

</comment></comment><comment><USER22> What's the situation with SEH these days in Clang?

<comment><USER4> [http://clang.llvm.org/docs/MSVCCompatibility.html](http://clang.llvm.org/docs/MSVCCompatibility.html) says minimal. Note that this is about cross-plat conformant c++ code. SEH is windows specific.

<comment><USER7> That document is out of date. SEH works OK for 64-bit X86, 32-bit X86 is ongoing. Catching C++ exceptions has been implemented for 64-bit X86 but isn't ready for prime time.

</comment></comment></comment><comment><USER23> > and is fast becoming the preferred C++ compiler for non-Windows platforms.

They wish. Microsoft still hates GNU.

<comment><USER24> It is, though. And Microsoft isn't alone in hating GNU - FreeBSD no longer ships with or uses GCC; the entire FreeBSD kernel and userland is built with Clang these days. And, of course, Apple's the one that started this whole stampede away from GCC in the first place. LLVM/Clang really and truly have hit GCC hard - and definitely for the best. Look at the improvements to GCC spurred by newer features in the Clang build toolchain.

EDIT:

In reply to davidgerard's comment below:

> I will not believe this falsifiable claim without numbers. FreeBSD has > almost no users compared to Linux.

Non-Windows does not mean Linux.

And what falsifiable claim? They didn't say Clang _is_ the most popular - <USER2> said it's becoming. But if that's really the game you want to play, then it's _Linux_ that has almost no users compared to the number of iPhones/iPads/iWatches/MacBooks out there - Clang/LLVM-powered, each and every one of them.

<comment><USER12> There are several reasons why FreeBSD is ditching GCC, one of them is licensing. I am wondering what are the technical reasons though...

<comment><USER25> There was a Stack Exchange question answering exactly this question:

[http://unix.stackexchange.com/questions/49906/why-is- freebsd...](http://unix.stackexchange.com/questions/49906/why-is-freebsd- deprecating-gcc-in-favor-of-clang-llvm/49970#49970)

Another contributing factor may be momentum. Clang is easier to work with than GCC, and doesn't have the baggage of GCC, so more and more people and companies are starting to use it, fund it, and commit code to it. It's been improving in leaps and bounds, and still rapidly improving. It's only a matter of time before it's all around better than GCC.</comment></comment></comment></comment>


Should Depressed People Avoid Having Children? - <AUTHOR> http://healthland.time.com/2012/06/05/should-depressed-people-avoid-having-children/

<comment><USER2> > By selecting against our "worst" genes, we may run the risk of losing our > greatest gifts.

So why don't we assume that our children will have similar genes to us, and provide an environment that would have nurtured these particular set of genes?

</comment><comment><USER3> You can't seriously think that the choice to have children should be anything but personal, can you?

<comment><USER4> Imagine (and this is a pure thought experiment for the sake of it) that you know with a fair percentage of certainty that any kid you would conceive would have highly sociopathic/psychopathic tendencies and thus likely affect society negatively. Does your choice to conceive become more than just personal?

<comment><USER5> Nope.

I suppose that you're thinking that I would be worried about the harm that my child would do to other people; that I would sympathize sufficiently with a potentially (1-P_fair_percentage) non-existent group of strangers more strongly that I would take into consideration my own future negative feelings about parenting a psychopath.

On the scale that includes 'regard for my personal well-being' and 'my love for my children', the 'concern about others' specified in your scenario is very close to zero.

Although the converse doesn't hold: I'm confident that my children are going to be better than me in infinite ways and manners, and they're going to make the world a better place.

<comment><USER6> Before you have had any children, does the calculation include your love for your children? They don't exist yet and might never exist, so I can't see how a decision can be founded on love for them, before they exist. After they exist is another issue.

<comment><USER3> The love you have for your child is inexplicable and illogical. You may not know or understand the love you'll have for your child but I can guarantee (with reasonable certainty) that it will exist.

I'm sure there are exceptions, but they're just that -- exceptions.

<comment><USER6> I said nothing about the love I will have for my child. I was talking about the love I have now for children who do not yet exist. If they don't yet exist, it doesn't even make irrational sense to love them yet. At best, I love a vague image in my head of what I think having children will be like.

<comment><USER3> I'm saying that the love you have for your current child is the same (relatively speaking) that you'd have for future children.

I understand what you're saying but I guess I disagree that it matters. For example, if you want to have a child to experience the type of love we're talking about then you have a child.

No one's to say someone else shouldn't have a child and thus not experience that kind of love. That's really the point I was trying to make.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> The question sounds too close to eugenics for me.</comment>


Risch Algorithm – An Algorithm for Indefinite Integration - <AUTHOR> https://en.wikipedia.org/wiki/Risch_algorithm <comment><USER2> Is there a complete open source implementation of Risch's Algorithm?

<comment><AUTHOR> I don't know of a full implementation but SymPy has a simplified version of the Risch algorithm, called the Risch-Norman algorithm.

[https://docs.sympy.org/latest/modules/integrals/integrals.ht...](https://docs.sympy.org/latest/modules/integrals/integrals.html#internals)</comment></comment>


Snowden's whereabouts unknown - <AUTHOR> http://www.washingtonpost.com/world/national-security/russia-says-it-has-no-authority-to-expel-snowden/2013/06/24/325281f2-dcaf-11e2-bd83-e99e43c336ed_story.html

<comment><USER2> Funny how the prominent left politicians (not citizens) are coming out and showing who they really are: Neocons.

The only thing 'deeply troubling' is that both sides are labeling a whistleblower as a 'leaker' and 'traitor' when all he's done is expose that U.S. citizens info is collected without warrants, a likely constitutional violation.

<comment><USER3> Calling them neocons ignores the basis of their political beliefs: Statism. The American Democrats are essentially Statists who will - at any cost - support the advancement of the state, specifically the state's control over every aspect of life. Their mantra is "What you can control cannot hurt you."

Personally I also equate American Republicans with fascists, whom spout rhetoric about patriotism and some measure of ethnocentrism.

<comment><USER2> Yes - Statism is a better term! I agree.

<comment><USER4> Neocons and Neoliberals (which is what I would characterize the "liberal" elite in DC) are pretty similar in most ways. They simply differ on whether it is military force or economic "liberalization" that should be used to promote "freedom and democracy."

</comment></comment></comment></comment><comment><USER5> > A frustrated Secretary of State John F. Kerry said he was troubled by the > apparent refusal of fellow world powers China and Russia to respond to > espionage charges the United States had filed against Snowden, who leaked > top-secret documents about U.S. surveillance programs.

This is kind of a strange statement. On what grounds could/would China or Russia "respond to espionage charges" in the absence of extradition treaties with the US?

Its also somewhat strange the US would expect any other country, especially these two, to care deeply about leaks against it that expose massive US/British spying against basically the whole world.

<comment><USER6> You're taking Kerry's words WAY to literally. The US wanted Snowden and Russia said no, therefore the US had to respond. Kerry wasn't literally thinking "Oh my god! They said no! How dare they? What do you do now???"

The US knew what the answer was going to be before they even asked the question.

<comment><USER7> That's exactly what he said -- throwing a hissy fit because Russia is not treating the US as a superpower...

</comment></comment></comment><comment><USER8> I wonder how those reporters feel signing up for a 12 hour flight to Cuba now for nothing. I have to confess I chuckled with the "they locked the doors and he's not on the flight!" tweet. Rountrip to Cuba for nothing.

<comment><USER9> Hopefully they use the 12 hours to discuss and write about the actual issue, instead of the person that reported it.

<comment><USER10> No they will be hitting the duty free booze - you obviously haven't been around many Journalists :-)

And probably trying to persuade their editors that they should stay on Cuba for a few days just in case _nudge_ _nudge_

<comment><USER11> Apparently there's no booze served on the flight either. The journalists are very disappointed.

</comment></comment></comment></comment><comment><USER12> This is ironic.

Snowden is able to pass through Russian territory because, according to the law of Russia, it is allowed. This, says Mr Kerry, is deeply troubling.

However, blanket monitoring of internet activity, which according to the law of the US, is allowed, is not deeply troubling?

</comment><comment><USER13> >He cited U.S. refusals to extradite bankers convicted in crimes in Ecuador, saying Quito was now free to exercise its "sovereignty" in the same way.

Way to go Ecuador!

>"There is no small irony here," Kerry added, posing the hypothetical question of whether Snowden sought refuge in China and Russia "because they're such powerful bastions of Internet freedom."

No sign of shame or embarrassment. Disgusting.

</comment><comment><USER14> Hm. His passport was revoked. Reminds me of the communist era here in eastern Europe when people were not allowed to hold passports, unless the state decided that it's safe to let them travel abroad.

</comment><comment><USER15> > [Rep. Ileana Ros-Lehtinen (R-Fla.)] added: "These are countries that violate > press freedoms every day. And yet [Snowden]'s seeking political asylum in > those very countries where . . . if he were to pull a Snowden in these > countries, they'd jail him immediately."

...exactly as the US has attempted to do, on trumped-up espionage charges no less? The _only_ reason that didn't happen in this case is because he learned from previous leakers and was smart enough to protect himself by fleeing the country beforehand.

</comment><comment><USER16> >"Ecuador puts its principles above its economic interests," he said.

Something about this statement made me wonder: is Ecuador just collecting political fugitives so that it can cut some nice deal with the US in the future? This isn't a country with a stellar human rights record. I'm not sure how comfortable I am with them accumulating a stable of high profile asylum- seeking bargaining chips.

<comment><USER17> >This isn't a country with a stellar human rights record.

The same could be said of the US. Surely you know this. [http://www.nytimes.com/2012/06/25/opinion/americas- shameful-...](http://www.nytimes.com/2012/06/25/opinion/americas-shameful- human-rights-record.html)

I assume when the US shelters human rights activists you will question its motives in a similar manner, no?

Also, cute how you jump to that reasoning first. Surely there is no other reason a sovereign nation would need a bargaining chip with the USA.

<comment><USER16> >The same could be said of the US. Surely you know this.

Yes, but the US has much bigger guns in the game of diplomatic bargaining than Ecuador - including actual guns. Handing over political refugees would be an unnecessary sacrifice of reputation for the US when there are so many other tools at its disposal. Other nations already mostly do whatever the US tells them to, and when they don't, a minor play like that wouldn't make a difference.

Ecuador does not have such clout, so political refugees are a far more useful bargaining chip.

<comment><USER17> Since when is the US "handing over" anyone?

<comment><USER16> They aren't. I think you should reread my comment.

<comment><USER17> I did. Several times. I still don't understand what's being "handed over" exactly.

<comment><USER16> Nothing is being handed over by the US. The US doesn't stand to gain more by handing over political refugees than they could gain by other tools available to them, and they would lose reputation by handing over political refugees. So they don't. They don't hand over refugees because it would hurt them more than it would help them.

My point is that that reasoning does not necessarily hold for Ecuador. This is why it's _not_ necessary to suspect that the US is collecting refugees as future bargaining chips, while it _is_ necessary to consider that Ecuador might be.

If you still think I'm suggesting that the US is handing over refugees, please point out where I said anything of the sort, and I will clarify.

<comment><USER17> Ahh, ok. Thanks for the clarification!

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> From the article: _The flight from [Moscow] was packed with journalists who had purchased tickets believing that Snowden would be on the flight._

It would be hilarious if Snowden and his companions tried to get seats on that flight, but could not, because it was already fully booked by these proactive journalists.

</comment><comment><USER19> "It would be very disappointing if he was willfully allowed to board an airplane," said Kerry, who was traveling in New Delhi. _"There would be without any doubt . . . consequences."_ [emphasis mine].

What is he insinuating by saying something cryptic like this?

<comment><USER20> It's standard sabre rattling. There's not a lot America could do to China or Russia to upset them, so it's pointless rattling of the political sabre to try and look tough on the big stage. Well, in my opinion anyway, unless Kerry means he's going to unleash a torrent of US cyberspooks to pwn their networks even more.

</comment></comment><comment><USER21> > "if he were to pull a Snowden in these countries, they'd jail him > immediately."

This is the first time I've noticed this usage of "Snowden". Anyone noticed it earlier?

</comment><comment><USER22> > "The bottom line is very simple," Schumer said. "Allies are supposed to > treat each other in decent ways, and Putin always seems almost eager to put > a finger in the eye of the United States, whether it is Syria, Iran and now, > of course, with Snowden. That's not how allies should treat one another, and > I think it will have serious consequences for the United States-Russia > relationship."

And spying on so many of the citizens of so many allies is somehow perfectly ok?

<comment><USER23> Well...Russia _does_ seem a bit bitter about other spying incidents: [http://www.interfax.com/newsinf.asp?id=425431](http://www.interfax.com/newsinf.asp?id=425431)

So it's not just the spying on citizens, it's also the...uhm...spying in general.

</comment></comment><comment><USER24> The tone of this article suggests Snowden is nothing more than a pawn in someone else's game.

Why should anyone care so much about him? We've heard repeatedly that what he has disclosed - a massive amount of spying on Americans and other nationals - was already known by everyone.

Who was that person who said: If you are worried about someone discovering your "secret" activities, then maybe you be doing those activities in the first place.

Maybe the sooner politicians accept that "frictionless sharing" is the future, the better off we'll all be? What do you think?

Other commenters have pointed out that most users outside HN do not care about data privacy. So why should politicians care? Are they a special case? I thought they represent the views of their constituents.

</comment><comment><USER25> These politicians are increasingly sounding desperate. Like the parents of a teenager who realize that their power is not limitless and is in fact evaporating.

</comment><comment><USER26> He may actually make it, which is amazing. This is probably the best outcome Snowden could have possibly hoped for.

</comment><comment><USER27> Kerry really comes off as a crybaby here

</comment><comment><USER28> How is Snowden pulling this off? Can anyone elaborate on the balance of power that has allowed him to stay free and travel? This seems to be quite a feat, but I can't read between the lines enough to sort out why these foreign powers are staying out of his hair.

<comment><USER29> What do you think would happen in the symmetrical situation where a Russian or Chinese whistleblower, exposing evidence of his respective country spying on the Americans, were to seek protection from the US? There's no chance the Yanks would just meekly accede to an extradition request.

</comment></comment><comment><USER30> From a politics standpoint, this is really really poor diplomacy, giving a public tone which makes us look weak and forcing us into a position where the US looks servile to other countries. It's just sloppy.

Why can't we have Clinton back as Secretary of State?</comment>