:''The following discussion is an archived discussion of a [[WP:requested moves|requested move]]. <span style="color:red">'''Please do not modify it.'''</span> Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a [[Wikipedia:move review|move review]]. No further edits should be made to this section. ''
The result of the move request was: '''No move.''' Supports and opposes were about evenly split. There were essentially two points of argument: whether "heartbleed bug" was the subject's common name over just "heartbleed", and whether the bug is the [[WP:PRIMARYTOPIC]] for "heartbleed" (and therefore, whether the dab page should be at "heartbleed"). Several editors suggested other articles or topics existed that challenged the bug's status as primary topic, but this largely was not in evidence. I detect a rough consensus against moving this article and replacing it with a dab page. Several editors who supported (or were amenable to) a move specifically felt "heartbleed" should remain a redirect. However, the level of support still did not reach consensus for a move. No other proposal garnered much support; as such I'm closing as "no move." [[User:Cuchullain|Cúchullain]] [[User talk:Cuchullain|<sup>t</sup>]]/[[Special:Contributions/Cuchullain|<small>c</small>]] 20:42, 24 April 2014 (UTC)
----
[[:Heartbleed]] → {{no redirect|Heartbleed bug}} – This is likely going to be a current events report that will pass from memory in a few months once all internet services have patched their latest version of OpenSSL, whereas "heartbleed" is a common term referring to any number of [[heart condition]]s and should have been left as a disambiguation page. Per [[Wikipedia:Article titles#Deciding on an article title]] criteria:
[[:Heartbleed]] → {{no redirect|Heartbleed bug}} – This is likely going to be a current events report that will pass from memory in a few months once all internet services have patched their latest version of OpenSSL, whereas "heartbleed" is a common term referring to any number of [[heart condition]]s and should have been left as a disambiguation page. Per [[Wikipedia:Article titles#Deciding on an article title]] criteria:
Line 201:
Line 207:
*'''Oppose''': No such medical condition in evidence. Nom appears to be confused at best. If there was already DAB page with entries on it that would be won thing, but ti is an obvious case where the primary, really only, topic is this bug, so the disambiguation isn't necessary (nor would it be necessary to use "(bug)" where the plain-Englsh "bug" will do fine, should it ever become necessary). <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''' ☺]] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 07:12, 24 April 2014 (UTC)
*'''Oppose''': No such medical condition in evidence. Nom appears to be confused at best. If there was already DAB page with entries on it that would be won thing, but ti is an obvious case where the primary, really only, topic is this bug, so the disambiguation isn't necessary (nor would it be necessary to use "(bug)" where the plain-Englsh "bug" will do fine, should it ever become necessary). <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''' ☺]] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 07:12, 24 April 2014 (UTC)
* '''Oppose''': When looking through sources listed as supporting saw several cases were after bug was mentioned once it was just referred to as heartbleed. I agree that there doesn't seem to be a disambiguation problem, so concise seems to be the way to go. As for the passage of time and Heartbleed by itself not being recognized as well.. that can wait til it is an issue. There is also the advantage of looking at the bug and the impact as separate but related things, and agree with the points above on the matter. [[User:PaleAqua|PaleAqua]] ([[User talk:PaleAqua|talk]]) 07:30, 24 April 2014 (UTC)
* '''Oppose''': When looking through sources listed as supporting saw several cases were after bug was mentioned once it was just referred to as heartbleed. I agree that there doesn't seem to be a disambiguation problem, so concise seems to be the way to go. As for the passage of time and Heartbleed by itself not being recognized as well.. that can wait til it is an issue. There is also the advantage of looking at the bug and the impact as separate but related things, and agree with the points above on the matter. [[User:PaleAqua|PaleAqua]] ([[User talk:PaleAqua|talk]]) 07:30, 24 April 2014 (UTC)
<hr />
:''The above discussion is preserved as an archive of a [[WP:RM|requested move]]. <span style="color:red">'''Please do not modify it.'''</span> Subsequent comments should be made in a new section on this talk page or in a [[WP:move review|move review]]. No further edits should be made to this section.</div><!-- Template:RM bottom -->
== total length of a HeartbeatMessage: 2^14 or 16 KByte, not 64 KByte ==
== total length of a HeartbeatMessage: 2^14 or 16 KByte, not 64 KByte ==
Revision as of 20:42, 24 April 2014
This is the talk page for discussing improvements to the Heartbleed article. This is not a forum for general discussion of the article's subject.
This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
This article is within the scope of WikiProject Internet, a collaborative effort to improve the coverage of the Internet on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.InternetWikipedia:WikiProject InternetTemplate:WikiProject InternetInternet articles
The image at http://heartbleed.com/heartbleed.png appears to be used in a lot of news articles. It originates from a website called heartbleed.com. I'm thinking about asking the copyright owners for permission to use it on Wikipedia and license it under CC-BY-SA, but I want to first confirm whether or not it would be appropriate. It's definitely not the "official logo" or what not for the security bug, but it's being used to represent it at CNET, BBC, Epoch Times, and other sources. Thoughts, concerns? Mz7 (talk) 21:45, 9 April 2014 (UTC)[reply]
Asking them to release it under CC-BY-SA is a good idea, but don't expect "yes" (although it is quite possible!). πr2 (t • c) 23:06, 9 April 2014 (UTC)[reply]
It might be very possible that this logo (and the dedicated website) helped in spreading knowledge about the bug (and thus encouraging rapid response), because it gave media something to show. (refs: [1], [2]) It might be worth keeping an eye out for analyses of this aspect of the whole event. --Rhymoid (talk) 00:09, 10 April 2014 (UTC)[reply]
– Yep, I've just got an email confirming CC0, the website has been updated to confirm this too. Looks like it's already been uploaded. Mz7 (alt) (talk) 14:38, 10 April 2014 (UTC)[reply]
"Bug is in the OpenSSL's implementation of the TLS/DTLS (transport layer security protocols) heartbeat extension (RFC6520). When it is exploited it leads to the leak of memory contents from the server to the client and from the client to the server." Hence Heartbleed. kencf0618 (talk) 04:40, 10 April 2014 (UTC)[reply]
"The HEARTBEAT chunk is sent by one of the peers to probe and find out if a specific SCTP endpoint address is up. This is sent to the different addresses that was negotiated during the initialization of the association to find out if they are all up. . . .
"Heartbeat Information TLV - bit 32-n. This is a variable-length parameter as defined inside the RFC 2960 - Stream Control Transmission Protocol document. This is a mandatory parameter for the HEARTBEAT chunks that contains 3 fields, info type = 1, info length and a sender-specific Heartbeat Information parameter. The last field should be a sender-specific information field of some kind, for example a timestamp when the heartbeat was sent and a destination IP address. This is then returned in the HEARTBEAT ACK chunk."
Jo3sampl (talk) 01:58, 12 April 2014 (UTC)[reply]
Purpose of "Affected websites and services" section
I don't see how the section will be too useful in the future when all the servers have been patched and the filippo.io links no longer detect the bug. The websites listed should be supported by secondary sources instead of relying on so many primary sources (the tests run by filippo.io); it also seems like indiscriminate information to me, but this could also be made relevant by secondary sources. Whisternefet (t · c) 23:13, 10 April 2014 (UTC)[reply]
Maybe the list should be condensed in the near future to just a few of the biggest sites because the list may be relatively useless in just a year. Piguy101 (talk) 23:58, 10 April 2014 (UTC)[reply]
That section needs to be deleted in its entirety. It serves no real purpose considering OpenSSL is used in millions of servers including ALL top 1000 websites. There is no need to list them all. It's also missing many major ones anyway (Google, Facebook, etc.). And what on earth is the point of the whole "fixed on [or before] 10 April 2014" next to each website? That's already outdated... --CyberXRef☎13:50, 11 April 2014 (UTC)[reply]
I agree, the list is too large and has a potential to grow too large to be useful. Only sites that have been reported as vulnerable in secondary sources should be listed, if at all. –xenotalk15:37, 11 April 2014 (UTC)[reply]
"The second log seems much more troubling. We have spoken to Ars Technica's second source, Terrence Koeman, who reports finding some inbound packets, immediately following the setup and termination of a normal handshake, containing another Client Hello message followed by the TCP payload bytes 18 03 02 00 03 01 40 00 in ingress packet logs from November 2013. These bytes are a TLS Heartbeat with contradictory length fields, and are the same as those in the widely circulated proof-of-concept exploit.
Koeman's logs had been stored on magnetic tape in a vault. The source IP addresses for the attack were 193.104.110.12 and 193.104.110.20. Interestingly, those two IP addresses appear to be part of a larger botnet that has been systematically attempting to record most or all of the conversations on Freenode and a number of other IRC networks. This is an activity that makes a little more sense for intelligence agencies than for commercial or lifestyle malware developers." — Preceding unsigned comment added by StephenK51 (talk • contribs) 23:47, 10 April 2014 (UTC)[reply]
It is a feature of Datagram TLS, a relatively new extension of TLS, that allows a DTLS peer to check the responsiveness of the other end, since the normal TCP machinery isn't around to do this. I think it's worth including some description of this in the article. OpenBSD has turned it off, FWIW.[3]— Preceding unsigned comment added by 70.36.142.114 (talk) 15:38, 14 April 2014 (UTC)[reply]
Assumptions based on incomplete checks and bare domain names
Heartbleed#Affected websites and services has a list of "websites and services" that were alleged to be vulnerable on April 8 but fixed on April 10 or later. But it appears to be WP:SYNTHESIS analysis based on the flawed assumption that testing https for the bare domain name host (without www. or anything else) for the Heartbleed bug is actually the indication of whether the institution's servers have now been secured. There are several major holes in these assumptions:
It's a flawed assumption that HTTPS servers that answer for the bare domain name (for example https://google.com/) are the ones that carry the important traffic, rather than just being a redirect to the www. or other servers (for example https://www.google.com/) where the main traffic is.
It's a flawed assumption that the "valuable" data to steal is on the main website. Many major websites actually have a totally different set of web servers (e.g. https://login.google.com/ or http://login.yahoo.com/) for entering your username and password, entering your credit card information, and the other main targets of data theft. These are the public servers that would be the most valuable (but not the only valuable) targets to connect to and exploit Heartbleed on.
It's a flawed assumption that having fixed the bug for https on the "visible" websites made the logins and passwords or other authentication secure again. If the usernames/passwords/secrets are leaking on any protocol that is using them, the information is still compromised. Think of how many organizations now have mobile apps and instant messengers that are taken care of a different group of people with a different time schedule, or even a third-party contractor in a different city/country, and who weren't consulted about whether they're secure before the announcement was made to change passwords (which will instantly be exposed by those apps). Now think of how many of those apps and instant messengers "helpfully" log in automatically all the time without asking the user anymore. Until all the servers for apps that log in are fixed, the company's customer usernames and passwords are still compromised.
It's a flawed assumption that no longer having the Heartbleed bug is the indication that the organization is back to being safe for the public. Tech news sites have mentioned that many purportedly-"fixed" websites seem to still be using pre-April SSL certificates that are supposed to prove the site is the real one. The certificates were reportedly leaked regularly by this bug and are potentially floating around out there ready to be used by fake websites now. Unless the organization revokes the certificates and uses newly-generated ones on all of its SSL services (see apps and instant messaging above), the services with old certificates are potentially as vulnerable to man-in-the-middle attacks and other phishing scams as if they were using plain HTTP with no encryption at all.
Because of all this, we need more reliable sources than just the improper synthesis assumption that the bare domain name HTTPS check is a good indicator that the organization's services are secured again. As mentioned in #3 above, we may have a primary sources problem also, because even the organizations themselves may even be inaccurately announcing that they are "secure" or "fixed" now just because they think their main web server team upgrading the web server software was the fix. Information from parties that explicitly have noted what services an organization has, and which have been secured, are probably necessary. Examples:
Google: Are Google Talk's XMPP servers patched and certificates re-issued? What about the Google login servers that authenticate every Android app that uses a Google account for access? What about the Google Play servers?
Yahoo: Are Yahoo Messenger's login servers patched and certificates re-issued?
Internet relay chat (IRC): Encrypted connections are exposing an IRC network's nickname/NickServ/ChanServ passwords unless every encrypted server on that IRC network has been patched and certificates re-issued. (The servers are often run by separate administrators.)
GitHub, SourceForge, and all those other source code/programming sites: Any distributed revision control systems that use SSL? MySQL and PostgreSQL and other database servers that public users can use for hosting? These source-code hosting organizations usually have several publicly-accessible services with SSL that most other organizations don't have. SSH wasn't vulnerable to Heartbleed; however, if an organization makes SSH or other arbitrary executable programs available to the public, then every SSL service available to "authenticated users" is open to silent attack from a random obscure customer also, even if it's firewalled from non-users.
Basically, for any site with encrypted communication other than the main website's pages: Have they enumerated which services they've gotten around to checking (rather than "all" or "most"), so that it can be determined by users (or Wikipedia readers) whether something has been overlooked before they authenticate to it or transfer other sensitive data that way? Before posting statements about "all" services being OK: Have we looked for other sources that already say that the organization forgot something? --Closeapple (talk) 16:25, 11 April 2014 (UTC)[reply]
I agree. This section ("Scanned") needs to be reworked. I've removed it: [4]. We definitely shouldn't be declaring an entire class of services "fixed" based on our own research. –xenotalk17:17, 11 April 2014 (UTC)[reply]
xkcd explains Heartbleed
I am soooo tempted to just WP:BOLDly add this to External Links, but I'm thinking it might be a controversial addition. So... Discussion?
It's an extremely layman-friendly illustration of the vulnerability. I'd never have made sense of the explanation in the article -- and I have some very basic programming experience -- but the XKCD strip made it very easy to understand. I recognize the undesirability of adding an external link to every XKCD strip that explains a difficult concept, but I'd support davidwr's idea in this one situation. 208.93.33.130 (talk) 19:44, 11 April 2014 (UTC)[reply]
If the article doesn't include a brief explanation of the bug in layman's terms, it'd seem better to write one than to link to a site that had one. Could even write up the comic in the article as "Randall Munroe explained the bug as..." if we considered him to be a sufficient authority for WP:SELFPUB. --McGeddon (talk) 22:08, 11 April 2014 (UTC)[reply]
Someone added their own stick figure comic, explaining it in layman's terms in unreadably small text. I added a description to the caption, but this was reverted on the grounds that it's not worth explaining the image at this point because it's unreadable as a thumbnail. Fair enough. But it isn't great if the only non-technical explanation of the bug requires the reader to know that they can click on a Wikipedia image to see it magnified. Should this just go into prose? Is there a good source for a layman's description out there? I've just thrown in a summary of XKCD's explanation for now. --McGeddon (talk) 23:09, 15 April 2014 (UTC)[reply]
I attempted to withdraw this nomination but I wasn't fast enough, so the nomination discussion will continue. See #Removing XKCD for another discussion related to the use of this comic in this article. davidwr/(talk)/(contribs) 18:52, 19 April 2014 (UTC)[reply]
Reference to the xkcd strip definitely needs to go in the article, not as a technical explanation, but to reflect the public reception of the incident. It´s likely the single most viewed publication refering to it. --129.13.72.198 (talk) 11:00, 22 April 2014 (UTC)[reply]
I imagine heartbleed.com reached a much wider audience. If you've got any sources that talk about the impact of the comic, though, go ahead. --McGeddon (talk) 11:11, 22 April 2014 (UTC)[reply]
Discoverer(s)
It is clear that Mehta reported the discovery first to the OpenSSL team. Both Codenomicon and Google/Mehta also acknowledge Codenomicon in some way. Codenomicon describes it as a straightforward independent discovery. Mehta does not go into detail, but does congratulate them on Twitter. Per NPOV, I think we should provide this information and let the reader draw their own conclusion. Thus, I've put back the text citing Heartbleed.com about this, and added Mehta's Twitter statement. Superm401 - Talk23:57, 11 April 2014 (UTC)[reply]
Proposed move to "Heartbleed bug"
The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.
The result of the move request was: No move. Supports and opposes were about evenly split. There were essentially two points of argument: whether "heartbleed bug" was the subject's common name over just "heartbleed", and whether the bug is the WP:PRIMARYTOPIC for "heartbleed" (and therefore, whether the dab page should be at "heartbleed"). Several editors suggested other articles or topics existed that challenged the bug's status as primary topic, but this largely was not in evidence. I detect a rough consensus against moving this article and replacing it with a dab page. Several editors who supported (or were amenable to) a move specifically felt "heartbleed" should remain a redirect. However, the level of support still did not reach consensus for a move. No other proposal garnered much support; as such I'm closing as "no move." Cúchullaint/c20:42, 24 April 2014 (UTC)[reply]
Heartbleed → Heartbleed bug – This is likely going to be a current events report that will pass from memory in a few months once all internet services have patched their latest version of OpenSSL, whereas "heartbleed" is a common term referring to any number of heart conditions and should have been left as a disambiguation page. Per Wikipedia:Article titles#Deciding on an article title criteria:
Recognizability: Everyone would know heartbleed in the software sense of the term, that is as a software bug, if it is moved to the new title. In the more persistent and long-term medical sense of the word, everyone would be more likely to know heartbleed as a problematic condition of the heart that occurs, well, when the heart bleeds.
Naturalness: A disambiguation would be more likely to point users to a number of terms they could choose from when searching through Wikipedia, and not always about the software sense of the term for a couple technical know-how nerds. As it is, we are giving undue weight and catering unnecessarily to the smaller technical community while obscuring with a hatnote what the more common use of this term should be in the worldwide community - the medical sense.
Precision: Should be self-evident.
Conciseness: Perhaps not as a concise, but definitely more precise.
Consistency: I am open to suggestions to make this more disambiguated, such as "Heartbleed (software)" or any number of article titles that would better serve our readers.
FYI I moved it here per a user's request here, which seemed reasonable - perhaps Hahnchen would like to elucidate their rationale. If the consensus is that the page is best named "Heartbleed bug", I have no issue with it being moved back. If that occurs, 'Heartbleed' should redirect to 'Heartbleed bug', at least for now. I do note that the Heartbleed disambiguation makes no mention of the medical heart bleeding conditions referenced in the original proposal. –xenotalk18:20, 12 April 2014 (UTC)[reply]
Proposition. Move page to 'Heartbleed (bug)' and leave 'Heartbleed' as a disambiguation page, as some heart conditions do warrant the name. Ging287 (talk) 18:47, 12 April 2014 (UTC)[reply]
I have no opinion either way regarding if the "bug" is better or worse here, but I have never once heard "heartbleed" being used to refer to any medical condition, and the searches hahnch linked reflect that. A regular google search for "heartbleed" refers entirely to the bug this article refers to. Cannolis (talk) 19:11, 12 April 2014 (UTC)[reply]
Until the heartbleed bug became world news, heartbleed was a red link. Anyone erroneously looking for medical conditions where the heart is bleeding who typed "heartbleed" was out of luck, and it's doubtful this is the term they would have used anyway, the term not having any basis in medicine. And now because you have some vague concern about recentism, you want to send our readers past a disambiguation page before they get to the article they are looking for. I disagree. And it should be noted that if this move finds consensus, there will still need to be a further discussion on whether "heartbleed" should redirect to the bug or the disambiguation page. –xenotalk16:06, 13 April 2014 (UTC)[reply]
For the near future, anyone typing "heartbleed" into the search box is looking for the bug. So heartbleed should lead to the bug, at least for a while; we should not force readers past a disambiguation page first. –xenotalk20:17, 12 April 2014 (UTC)[reply]
As I explained in my rationale, I'm afraid that there's a strong bias to point an article to a current event that primarily only serves the needs of the technical community, one that is oft-repeated in more reliable news sources than Wikipedia, and that is a short-term goal we ought to avoid. In general, I hope Wikipedia avoids its tendency to become a news station and focus on long-term goals. In fact, when I first hear the term "heartbleed" around an instant messaging site, I initially thought of a heart rupture until they pointed me to the heartbleed.com website where it was elaborated to be a software bug. Also, I am also fine with "Heartbleed (bug)" or any other article title as a good substitute suggestion, but for now the proposed move is toward "Heartbleed bug".
When you first heard "heartbleed", you thought it was some medical condition. You thought wrong. Heartbleed is the concise and precise name for this vulnerability. Heartbleed was a redlink before the bug turned up.Brainbleed is still a red link. Wikipedia has a strong bias towards being right, not towards whatever gut feelings a layman might have, or is that Gutfeel? - hahnchen03:28, 13 April 2014 (UTC)[reply]
If you truly think our readers are typing "heartbleed" and looking for something other than the bug, you would serve them well to go add whatever articles you think they are looking for to the heartbleed disambiguation page. A hatnote leads there. –xenotalk05:06, 13 April 2014 (UTC)[reply]
Note:FWIW, after cursory examination, currently wikipedia nomenclature demonstrates a lack of popularity for any title with the term "bug", not counting books or film
Historically Code Red of 2001 already had the alias "heart bleed"
Wetware apparently has the precedent implementing the parenthetical, like Velia (bug) -- this could be confusing of the two fields, biology versus computer, if you are setting or breaking a precedent for usage WurmWoodeT21:51, 12 April 2014 (UTC)[reply]
Oppose, due to the rationale given by the proposal. "Heartbleed" is not the common term of any heart condition, and the majority of google hits refer to the security bug, not any medical condition. Furthermore, if the chambers of the heart do rupture, death is guaranteed, so in practical terms you cannot have a medical "condition" called heartbleed. --benlisquareT•C•E05:13, 13 April 2014 (UTC)[reply]
If it is refuting the original points of the proposal, I think that would qualify as a regular oppose. I'm not sure why you would qualify it as "procedural" when you disagree with the medical connotations.
More to the point, what you have quoted me referring to as a medical "condition", is simply my explanation that the vernacular construction is often interpreted literally, i.e. the physical heart bleeds. Medical connotations simply follow from that construction; it is not, inherently speaking, "medical". TeleComNasSprVen (talk • contribs) 06:06, 13 April 2014 (UTC)[reply]
Weak support for changing the title to "Heartbleed bug"; oppose making Heartbleed a disambiguation page rather than redirecting to this article. As has been pointed out, Heartbleed was always a red link before this - it is very unlikely that anyone would be searching for any other topic under that name, so the proposal would merely make life more difficult for thousands of users (especially if the bug meaning is to be hidden away near the bottom of the disambiguation page, as someone has rather precipitously already done). I also checked out Google Books and Scholar (as I now see above someone else has also done) and there is absolutely nothing of relevance under "Heartbleed". The claim that it's some kind of medical term, vernacular or otherwise, is a pure red herring. It certainly could be used as such, but it isn't, so the possibility needn't concern us. I'm not sure these newly added medical conditions should even be on the disambiguation page at all (except possibly under "see also"). W. P. Uzer (talk) 08:07, 13 April 2014 (UTC)[reply]
How so? Information about the heartbeat bug is already on the top of the list for Google search hits, and we're mainly regurgitating news articles and other sources about something most (technical-minded) people would know about anyway. It'd stay at the top for a few years, and Wikipedia's article on it would not make a difference; after that, it'd fall off as old news and everyone will forget about it, and Wikipedia's article on it would still not make a difference. Either way, users would reach this article whether they feel like it or not, which is in my opinion a short-sighted goal. Wikipedia has been suffering from a rash of recentism lately. TeleComNasSprVen (talk • contribs) 08:32, 13 April 2014 (UTC)[reply]
Well that's interesting. I checked out Google Books and it seems the primary sense of the term is in a metaphorical sense or literary device. What does it mean though, and how does it relate to the bug? Is it popular enough a meaning? TeleComNasSprVen (talk • contribs) 08:40, 13 April 2014 (UTC)[reply]
Despite stating that heartbleed was a "common term" for a medical condition, and that use is "more persistent and long-term", you've only figured out a day later that its only use case is a typo when using the idiom, "my heart bleeds". You state above that Wikipedia relies on verifiability, on sources, yet you've offered none but your Gutfeel which is now bleeding out into the mainspace. - hahnchen17:37, 13 April 2014 (UTC)[reply]
No, it's just a rare word (or more commonly, a misspacing of "heart bleed", as in "makes my heart bleed"). Wikipedia is not a dictionary (and even Wiktionary doesn't list this word, nor do any of the print dictionaries I have to hand). The only encyclopedia topic for this term is the software bug (plus a couple of obscure songs). It's not a case of recentism at all, just that there is no other significant meaning whatever, so nothing to be gained for anyone, either now or in the future, as far as we can tell, by making thousands of users scan for and click additional links in order to get the page they want. W. P. Uzer (talk) 09:03, 13 April 2014 (UTC)[reply]
Support changing the title. I think TeleComNasSprVen expresses it well, and I agree with the user's interpretation of our titling criteria. (I would actually say that the conciseness criterion arguably supports "Heartbleed bug" as well, given that being concise does not simply mean being brief but rather being brief while conveying much... and the current title doesn't convey enough to be sufficiently clear.) ╠╣uw[talk]11:13, 13 April 2014 (UTC)[reply]
Oppose. The name of the bug is "Heartbleed", not "Heartbleed bug", so per WP:PRECISE and WP:CONCISE, "Heartbleed" should be the title of the article about the bug unless there is ambiguity AND the bug is not the WP:PRIMARYTOPIC. As others have mentioned, the supposed ambiguity is a red herring and there is no evidence that there's a medical condition that is also widely known as "heartbleed". But even if there is such a medical condition, I remain unconvinced that the bug is not the primary topic. —seav (talk) 17:12, 13 April 2014 (UTC)[reply]
Strong Oppose per User:Seav, User:hahnchen, User:Xeno, User: WurmWoode and others. Heartbleed is the most common name, and the term most will come here looking for. Bug is unnecessary, not part of the common name, and heartbleed is not a medical term, so there is no confusion. Also very little precedent for use of "bug" in titles. Per especially WP:COMMONNAME, as well as WP:PRIMARYTOPIC, WP:CONCISE, & WP:PRECISE. To move this article as suggested would be against policy. The semioffical website is Heartbleed.com, not HeartbleedBug.com — Becksguy (talk) 01:49, 14 April 2014 (UTC)[reply]
Oppose, strongly. Per many others above, the bug is known simply as heartbleed. There are also no medical conditions commonly referred to as heartbleed. Thus, there is no reason to move the bage. Calidum04:57, 14 April 2014 (UTC)[reply]
Oppose, strongly. Checking Google Books, use of the single word Heartbleed is extremely rare, it occurs only when a space is left out. Only use I see is for the name of a character "world's shyest white-hat hero, Heartbleed Haymeadow". Malaiya (talk)
No, they're saying that "heartbleed", without spaces, is not used often in Google books. Therefore, they conclude, "Heartbleed" was not used to refer to anything in conventional literature previously and most likely just refers to the bug in OpenSSL. – FenixFeather(talk)(Contribs)00:17, 17 April 2014 (UTC)[reply]
You have misunderstood. The term "heartbleed" isn't found in Google Books. Therefore, it only refers to the newly discovered bug, not to a medical condition. That means the page can be kept at Heartbleed, because there is no clash. Mahahahaneapneap (talk) 14:53, 19 April 2014 (UTC)[reply]
Strong oppose. "Heartbleed" is the concise title. If there ever exists an article on the medical term "Heartbleed", this issue can be looked at again, but until such an article exists? There's no reason at all to move this. SnowFire (talk) 16:49, 16 April 2014 (UTC)[reply]
Oppose. There is no medical condition commonly referred to as "heartbleed", so little to no chance of confusion. "Heartbleed" is a common (and probably the most common) name for the security vulnerability. Psychonaut (talk) 17:15, 16 April 2014 (UTC)[reply]
Can anyone provide any evidence, one way or the other, as to which of "Heartbleed" or "Heartbleed bug" (or possibly "Heartbleed Bug") is more common, rather than just making unsupported statements? This discussion has become rather confused, since there are effectively two questions being addressed. We have hopefully debunked now the suggestion that this might not be the primary topic for the term "Heartbleed", but even without that spurious claim, it might still be the case (on other grounds) that the word "bug" ought to be included in the title. W. P. Uzer (talk) 06:54, 17 April 2014 (UTC)[reply]
Support I only knew it as "that internet bug that means I have to change my passwords," so I looked up "security internet bug" on wikipedia to find out what it was. It might have been easier to locate from there if it had been labeled "Heartbleed butt"93.209.55.56 (talk) 14:58, 17 April 2014 (UTC)[reply]
True. Alright, I agree that my reasoning was silly, but I still support moving for reasons of clarity, to Heartbleed (bug) or Heartbleed bug. (same person different computer)93.209.55.56 (talk) 22:13, 17 April 2014 (UTC)[reply]
Oppose both "Heartbleed bug" and "Heartbleed (bug)". "Heartbleed bug" is very clearly against naming conventions. "Heartbleed (bug)" is slightly better, but until there is another especially notable article is named "Heartbleed" or it is shown that there is significant use of the term "Heartbleed" in the literature outside of discussions of the bug itself, there is no need to move the article. – FenixFeather(talk)(Contribs)20:35, 17 April 2014 (UTC)[reply]
As we've already been over, the results were overwhelmingly misprints, and they rarely referred to any physical bleeding. And there were so few results anyway that we can safely conclude from them that this is not a word that significant numbers of people would be using to seek information about bleeding hearts (and still less about any of the topics listed at Bleeding heart (disambiguation), which don't include anything about hearts actually bleeding either), compared with the number using it to find information about this bug, which for obvious reasons will not have found its way into any books as yet. Some common sense is required when drawing conclusions from Google... W. P. Uzer (talk) 17:55, 21 April 2014 (UTC)[reply]
I'm equally comfortable with the current and proposed titles. The current title is concise and a primary topic, but "Heartbleed bug" is essentially fine, as it's a commonly used phrase and doesn't add too much in terms of length. OpposeHeartbleed (bug) as unnecessary parenthetical disambiguation. If we determine "Heartbleed" is insufficient, we should use WP:NATURALdisambiguation. (Edit: I'm really only ok with "Heartbleed bug" as a phrase of its own. There is a primary topic, so disambiguation is not called for, natural or otherwise.) --BDD (talk) 22:43, 21 April 2014 (UTC)[reply]
Oppose. This move request and much of the support are based on the flat-out incorrect claim that "heartbleed" is "a common term referring to any number of heart conditions". As far as I can tell, this supposition was pulled out of thin air, as there's absolutely no evidence that the term commonly refers to anything (be it a medical condition or something else) other than this article's subject. The two obscure songs are listed on the disambiguation page, properly linked from this article via a hatnote. Titling an article in accordance with a term's only common use isn't "recentism", no matter how recently said usage arose. —David Levy01:57, 22 April 2014 (UTC)[reply]
Comment: Further argument against renaming is that actually the term bug applies to the software error in the coding, not what happened in internet security or the press or blogosphere as a result. Heartbleed is the exploit, not the bug. Bugs are coding or logic errors that may, or may not, lead to exploits, or be the means for an exploit, but they are not the same thing. An exploit is an attacker using an error or vulnerability (actually or potentially) to gain access to a system and cause harm or compromise it, or to exfiltrate data from a system that is of value, such as crypto keys, plaintext, or whatever. Suppose an owner uses their car to go shopping and forgets to take the ignition key, thus leaving the key in the ignition, which is a mistake or error. A potential criminal sees the key, and using that as a means to commit a crime, steals the car. Stealing the car is the exploit, by exploiting, or taking advantage of the error. Forgetting the key and stealing the car are not the same thing, neither is the software bug and the exploit called heartbleed the same thing. In both cases one is a means to commit the other (crime or exploit). Renaming would violate the policies I referenced before. — Becksguy (talk) 02:56, 22 April 2014 (UTC)[reply]
But "Heartbleed" is rather the name attached to the bug (as on the official site and many other reports). It might seem to us a little more logical for that word to refer to the exploit than to the error, but it's not up to us to decide what things ought and oughtn't to have been called. W. P. Uzer (talk) 06:57, 22 April 2014 (UTC)[reply]
I think what he's saying is that Heartbleed refers to the crisis in general, whereas Heartbleed bug refers to the bug that caused the crisis. So Heartbleed is a better way to describe the events. Sort of like how Watergate refers to the entire scandal, but the Watergate bug was the bug that was planted at Watergate hotel. – FenixFeather(talk)(Contribs)03:31, 24 April 2014 (UTC)[reply]
Oppose: No such medical condition in evidence. Nom appears to be confused at best. If there was already DAB page with entries on it that would be won thing, but ti is an obvious case where the primary, really only, topic is this bug, so the disambiguation isn't necessary (nor would it be necessary to use "(bug)" where the plain-Englsh "bug" will do fine, should it ever become necessary). — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 07:12, 24 April 2014 (UTC)[reply]
Oppose: When looking through sources listed as supporting saw several cases were after bug was mentioned once it was just referred to as heartbleed. I agree that there doesn't seem to be a disambiguation problem, so concise seems to be the way to go. As for the passage of time and Heartbleed by itself not being recognized as well.. that can wait til it is an issue. There is also the advantage of looking at the bug and the impact as separate but related things, and agree with the points above on the matter. PaleAqua (talk) 07:30, 24 April 2014 (UTC)[reply]
The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.
total length of a HeartbeatMessage: 2^14 or 16 KByte, not 64 KByte
That ignores the precept RFC 6066, wherein "max_fragment_length" may be negotiated to be larger (bending the rules), thus allowing the buffer overrun (breaking of the rule, maximally), retrieving 2^16 (64K), or whatever was successfully negotiated. The difference (RTFM) between a pro versus a newb? WurmWoodeT21:51, 12 April 2014 (UTC)[reply]
Speaking of RTFM, I don't see the possibility to increase the length in RFC 6066 ("The allowed values for this field are: 2^9, 2^10, 2^11, and 2^12."), nor any support for fragment length negotiation in OpenSSL 1.0.1f/g at all. --Matthäus Wander (talk) 19:59, 14 April 2014 (UTC)[reply]
Sentence: "LogMeIn claimed to have "updated many products and parts of our services that rely on OpenSSL"."
Locations: Section: Affected services:
subsection: Websites and web services, bottom of section
subsection: Software applications, bottom of section
The identical sentences are 5 list item/section titles apart, perfectly easy to see on one screen. I would leave the full quote in the first subsection, for informational purposes, with the second being reduced to "LogMeIn"<ref>. However, I do not know enough about LogMeIn to know if there is something more appropriate, such as website or software, not both? 71.234.215.133 (talk) 10:42, 13 April 2014 (UTC)[reply]
Dissertation of the Programmer
What strikes me is the fact that the programmer in his Ph.D. explicitely mentioned the possibility to exploit the payload mechanism which he himself had implemented just before:
"The HeartbeatResponse must contain the same payload as the request it answers, which allows the requesting peer to verify it. This is necessary to distinguish expected responses from delayed ones of previous requests, which can occur because of the unreliable transport. The padding, on the contrary, always has to be of random data and is not sent back. The length of the padding is arbitrary, but should always be 16 bytes or more for security reasons, to prevent statistical attacks in case the payload is predictable. This can be the case if an implementation only uses sequence numbers for the payload of its requests. Without additional random bytes this payload can be guessed easily, thus making it prone to a KnownPlaintext Attack (KPA) [94]." [5], p.67
I tried to find a formulation to express this striking coincidence which might lead to the impression that the programmer was well aware about what he was contributing, although of course there could be other explanations as well. My contribution apparently sounded to biased to User:Per_Olofsson and he removed it. Please help me to find a wording neutral and subtle enough for WP:en, so that either interpretaion about deliberate intensions would be possible. I am not a native speaker in English so I might fail here. --HV (talk) 14:06, 13 April 2014 (UTC)[reply]
Except that it is about the heartbeat feature he implemented, the quoted text has nothing to do with the bug. The discussed attacks are fundamentally different from the actual bug. No chance for conspiracy theories or original research.93.104.51.24 (talk) 21:32, 13 April 2014 (UTC)[reply]
But the excerpt shows at least that the developer being a security expert was very well concerned with the issue in which he himself had failed to be careful enough. How can this be explained? Serious lack of memory or concentration? Purpose? Other explanations? In any case it is an inevitable part of the whole scenario and thus should be mentioned in a reasonable and neutral fashion. --HV (talk) 21:43, 13 April 2014 (UTC)[reply]
Addition: neither conspiracy theory nor original research intended by me. Therefore I ask for collaboration. --HV (talk) 21:45, 13 April 2014 (UTC)[reply]
Explanation: He was blackmailed by the NSA but wanted give a secret hint about this in his dissertation by suggesting that he is a security expert worrying about security, since smart persons would know that such a person would never work on OpenSSL. Unfortunately, now since this section of his dissertation is public, the NSA will kill him before we can reveal details of this evil plot. Have a nice day! 93.104.42.169 (talk) 22:54, 13 April 2014 (UTC)[reply]
Even better explanation: he was forced by aliens to translate a portion of Nostradamus into code and a chapter of his dissertation... No, I don't want any speculation about inner or outer reasons for this coincidence, but rather a dry and short description of the fact, which might have a legion of possible reasons, including amnesia, simplemindedness and pure accident. It's the circumstances which matter here because they do give a perfect scenario for a potential social hack (regardless if it really happened or not). These circumstances are part of the story and of encyclopedic relevance. What will happen in the fantasy of our readers, even if some of them become paranoid, is none of our business. Did you get my point? --HV (talk) 05:16, 14 April 2014 (UTC)[reply]
As 93.104.51.24 notes, the passage you are quoting does not describe the actual bug at all. I am not sure what you think is suspicious about the quote, but it does not say anything about buffer overflows. Even if he did discuss buffer overflows in his thesis, I do not think it is appropriate to point out "coincidences" on Wikipedia like that. On the other hand, if you can find a reliable source that discusses this, then you could cite that source. Otherwise I think it constitutes original research. (And in this case I believe you are mistaken, but that is beside the point.) --Per Olofsson (talk) 09:51, 14 April 2014 (UTC)[reply]
I should also note, HV, that I do not think you are biased and I did not specifically object to the exact wording. I reverted your edit because I felt it constituted WP:OR, more specifically WP:SYNTH. If you can find a reliable source that discusses coincidences in the thesis regarding the Heartbleed bug, then I have no problem if you cite it on the page. However, in this case, I felt you were creating a synthesis by implying something that the source did not state. --Per Olofsson (talk) 10:18, 14 April 2014 (UTC)[reply]
I agree that this is irrelevant to the software bug. It is worth mentioning the padding requirement in the article about DTLS though, if that article gets expanded. 70.36.142.114 (talk) 15:26, 14 April 2014 (UTC)[reply]
Current version of the article has this entry in the list of vulnerable appications: "git 1.9.1 tested clone / push, leaks not much". Git uses multiple ways of communication [7]. The article should specify which of those are affected.Muelleum (talk) 21:57, 15 April 2014 (UTC)[reply]
I don't think Git has an embedded http/s server. You put your repo under a separate web server that might or might not have the heartbleed bug. 70.36.142.114 (talk) 11:09, 16 April 2014 (UTC)[reply]
Regrettably, I am removing the XKCD 1354 explanation of the bug. We really can't replace a suitably licensed drawing with non-free content and then claim that "no free equivalent is available, or could be created, that would serve the same encyclopedic purpose." as our policy WP:NFCC demands in criteria 1. Furthermore, the reduced resolution image that was uploaded isn't even legible. If it were up to me, I'd allow NC content and tag it so commercial users would be warned not to copy it, but it is not up to me and attempts to change the policy have failed in the past. Maybe the author could be persuaded to release this strip under a compatible license, but absent that it can't stay.--agr (talk) 10:17, 18 April 2014 (UTC)[reply]
That's insane. If we created a free equivalent of the XKCD comic, we would be ripping them off, thus violating their copyright. I would think that XKCD would want credit for their work, and that we not rip them off, which is apparently what you are saying.
Again, that's insane. I do not see that there is any way to replicate this comic without violating XKCD's copyright. Are we seriously suggesting that in order to protect XKCD's copyright, we must violate XKCD's copyright? If not, can someone please provide a free equivalent graphic that of the XKCD comic withhout violating their copyright? A Quest For Knowledge (talk) 19:34, 19 April 2014 (UTC)[reply]
Who said anything about replicating the comic? The point is that Heartbleed can be perfectly explained through just text, or with another sort of graphic, such as this one that does a great job of explaining the bug much more compactly than the XKCD comic. No one said anything about creating a duplicate version of the XKCD comic. ~SuperHamsterTalkContribs20:08, 19 April 2014 (UTC)[reply]
However, compact does not mean understandable by the non-technical user. That is the beauty of Randal Munroe's comic. It explains Heartbleed simply and elegantly to the non-technical user. With all due respect, File:Heartbleed bug explained.svg just does not do it for me nearly as well, & I have been working in I.T. for nearly a ¼ century.
Going back to another part of this discussion, I think the relevant guidelines can be found at WP:FAIRUSE & a section of that page, WP:Image resolution.
The strict interpretation of WP:IMAGERES is "At the low pixel count end of the range, most common pictorial needs can be met with an image containing no more than about 100,000 pixels (0.1 megapixels)." I attempted to do that at File:Xkcd - Heartbleed Explanation by Randall Munroe.png with a 216 × 460 (82 KB) image. While that was largely unreadable at that low resolution, my main intent was to drive traffic to the comic where it could be freely viewed as the creator, Randall Munroe, intended. However, a subsequent author removed it.
My real interest is to raise awareness about this vulnerability, including among non-technical audiences. Given WP:IMAGERES calls for "no more than about 100,000 pixels", & that going to that resolution leaves it illegible for nearly all, the best that I could hope for was to use the graphic to indicate "hey, there's is something worth looking at here." The comic is a simple & elegant non-technical explanation of the Heartbleed vulnerability & how it is exploited. Getting peiople to read it is in the public interest. WP:NOTPROMO would not even play into this if WP:IMAGERES allowed a readable image. Peaceray (talk) 23:13, 19 April 2014 (UTC)[reply]
Regardless, I still fail to see how the use of the comic meets non-free content criteria, particularly points 1 and 8. The free comic I linked to earlier does serve as a free equivalent, per OP. If it doesn't, well, a better one could certainly be created. Its presence may help with the understanding of the subject, but its omission is definitely not detrimental to the understanding of the subject, either, when free alternatives (or simply explaining the bug through text) will suffice. ~SuperHamsterTalkContribs21:47, 19 April 2014 (UTC)[reply]
I have seen no free alternatives that are nearly as simple & elegant an explanation for non-technical audience as the xkcd: Heartbleed Explanation comic. Many more people would quickly grasp what Heartbleed does than through the technical explanations in the article. The free content graphic File:Heartbleed_bug_explained.svg is not nearly as lucid.
You state that if the free comic that you linked to earlier does not serve well as a free equivalent, then a better one could certainly be created. Well, get at it!
Here's a rough draft of a simplified version of the graphic I've done so far, integrating the content of the original graphic with the conversation style of the xkcd comic. Let me know what you think.
Oops, yeah I think the svg version doesn't work well in browsers (it should look identical to the rasterized version). I'll have to flatten the layers before uploading, if we decide to use the picture. The server graphic might need some more detail too. – FenixFeather(talk)(Contribs)02:35, 20 April 2014 (UTC)[reply]
Would be good to have some text inside the server box, as in the XKCD cartoon, to illustrate where exactly this "secret server info" is coming from. Bigger text to make it more thumbnail-legible would help, too. But the current version is already much clearer than the existing user-made cartoon - I'll add it to the article. --McGeddon (talk) 10:32, 20 April 2014 (UTC)[reply]
It was worse than Heartbleed in some ways, it affected a heck of a lot of systems (not as many as Heartbleed but still a lot), but it didn't have the marketing campaign so nobody remembers it now. 70.36.142.114 (talk) 11:43, 18 April 2014 (UTC)[reply]
Lessons Learned by Internet users
I like the last paragraph that explains what providers (hardware and software) have learned from the Heartbleed stealth and evil attack. But there are also lessons that could be noted concerning what Internet users have learned. How can we be more vigil? What have we learned? A new concluding section could be added, or noted elsewhere in the article herein. — Charles Edwin Shipp (talk) 01:01, 20 April 2014 (UTC)[reply]
An example: Wikipedia is on the 'affected' list. What I've learned is to logout and disconnect my ethernet cable. The option upon logging in to Wikipedia, "Stay connected for 30 days" is not a good option, in my opinion. Charles Edwin Shipp (talk) 19:30, 21 April 2014 (UTC)[reply]
The concluding paragraph is bogus
The concluding paragraph is bogus. There are tons of bugs in proprietary software too.[9] OpenSSL is rather crufty though. The OpenBSD team is overhauling it, but who know if the extensive changes will introduce more bugs. Best practice is probably to use the "engine" feature to put the sensitive crypto operations into a separate process, and there's at least one big installation planning to move to that approach, but I don't have an RS for that yet. There may be some general security principles we can quote from, e.g. from Ross Anderson's book. [10]70.36.142.114 (talk) 03:04, 20 April 2014 (UTC)[reply]
I've reverted this good faith edit because the explanation ("does not actually test whether Heartbleed is present on a given site") doesn't apply to what the test does. Of course, it doesn't address whether Heartbleed isn't on any particular site. That's not what it does. Instead, it tests whether a browser checks whether an SSL certificate has been revoked. Heartbleed allows hackers to steal SSL certificates. Even if the website revokes the stolen certificate, if the browser doesn't check whether it was revoked, the browser will report the revoked certificate as legitimate. This test was specifically created because of the Heartbleed bug. According to Netcraft, only 30,000 of the 500,000+ SSL certificates affected by the Heartbleed bug have been reissued up until today, and even fewer certificates have been revoked.[11]A Quest For Knowledge (talk) 02:08, 20 April 2014 (UTC)[reply]
I do not consider this test as relevant in this article. However, if some people think it is, keep in mind it doesn't "test whether Heartbleed affects a given site", which is the reason why I am removing it. --Chealer (talk) 17:41, 20 April 2014 (UTC)[reply]
It's certainly wrong to call it a check for heartbleed. However, lots of heartbleed-affected sites have been replacing their certificates (and sometimes revoking the old ones), so mentioning something about that is relevant to the article, at which point it's reasonable to point to a CRL checking tool. 70.36.142.114 (talk) 18:15, 20 April 2014 (UTC)[reply]
@Chealer: It doesn't matter whether you personally think it's relevant to the article. Original reseach isn't allowed and even if it was, you would be wrong. The fact remains that a hacker can steal a web site's certificate using Heartbleed and this tests whether the web site's certificate has been revoked. If you don't understand how Heartbleed works, maybe you shouldn't be editing this article. A Quest For Knowledge (talk) 19:21, 20 April 2014 (UTC)[reply]
A Quest For Knowledge, I fail to see why you allude to OR. My edit simply removes material. In any case, as I wrote, the reason why I removed the material is because it made the section wrong, not because I consider it irrelevant. --Chealer (talk) 19:50, 20 April 2014 (UTC)[reply]
Wait, what are you guys arguing about? AQFN, what edit did you revert at the top of the section? I remember seeing a CRL checker mentioned in the section about heartbleed tests. I'd say a CRL checker is definitely not a heartbleed test and should not be described as one, but it's arguably relevant to the article anyway, so there is a case for including it as part of info about cert revocation. Cert revocation itself should be mentioned in the article (including whatever sourcing can be found about whether it's a good or bad idea) since it's being recommended by some as a response to Heartbleed. Actually, if anyone has a revoked certificate that they can still serve, it might be interesting to show a screen shot of a browser responding to an OCSP failure. 70.36.142.114 (talk) 19:41, 20 April 2014 (UTC)[reply]
Anyone wanting to add the above, please feel free. I may not get a chance to do it today, and I'll probably be offline for several days starting in a few hours. 70.36.142.114 (talk) 19:35, 20 April 2014 (UTC)[reply]
It would be interesting to include an approximation of the cost of Heartbleed. According to [13], "Even if there hasn’t been any malicious exploitation of the bug, the costs of people’s time will likely run into the hundreds of millions of dollars."
There aren't details on how that was computed. I wonder if this is realistic. --Chealer (talk) 20:07, 20 April 2014 (UTC)[reply]
That number is pretty speculative but not completely crazy imho. You could compute as 500k sites spending 2 hours each dealing with upgrades and cert replacement at $100 an hour = $100 million. More likely though, most of those sites will just do a standard update and not bother replacing their certs, and in most cases nothing will happen if they did it soon enough. Then there will be some unpatched sites that suffer actual cert theft, and a small fraction of those will have some sessions compromised through MITM attacks on (e.g.) public wifi networks, causing more hassles. I think large scale MITM attacks are less likely. Then there may also be client compromises from malicious servers (see "reverse heartbleed" above) etc. The article linked is reasonably good. 70.36.142.114 (talk) 20:48, 20 April 2014 (UTC)[reply]
Failing a better source, I've added a very rough estimation of 500 million USD from eWEEK. I'd love to see a real calculation replace that. --Chealer (talk) 02:02, 24 April 2014 (UTC)[reply]
I've removed this[14] for a number of reasons. First of all, it is original research to connect it to this article's topic. It doesn't even mention Heartbleed. See WP:SYN. Second, it is poorly sourced. Citing press releases is usually not a good idea. Instead we should rely on third-party reliable sources which have a reputation for accuracy and fact-checking. Third, it is out of date and was written before Heartbleed. A Quest For Knowledge (talk) 06:08, 21 April 2014 (UTC)[reply]
I think this should be a pretty noncontroversial removal. It seems quite obvious that the content was added as an originally researched counterargument to the preceding claim. – FenixFeather(talk)(Contribs)07:06, 21 April 2014 (UTC)[reply]
I'd be inclined to throw out the whole paragraph based on the article by Damien Choizit. Mr. Choizit's article seems to be a lot of platitudes but without much in the way of hard facts. And anyone who considers "open-source code" and "outsourced code" to be the same or similar doesn't know what he's talking about. RenniePet (talk) 13:52, 21 April 2014 (UTC)[reply]
He seems to conflate open source and nonproprietary too. In any case, I think the paragraph is a bit too long and redundant. It could be reduced to one sentence saying "It has also been suggested that because OpenSSL is developed by volunteers, it has not undergone the rigorous testing that proprietary software would undergo." or something. No need to mention this guy by name multiple times when we don't even know how he's connected or especially qualified to talk about the issue. – FenixFeather(talk)(Contribs)14:06, 21 April 2014 (UTC)[reply]
It may be possible to shorten the paragraph but the suggestion is inappropriate. The implication that proprietary software undergoes rigorous testing would have required sourcing. Furthermore, while we may not need multiples mentions of the author, I oppose to removing all mentions. The current formulation is a bit shorter but much vaguer, suggesting that many may have suggested that conclusion while we only know of one person who has. I prefer the previous version or no paragraph to that short form. I am going for no paragraph to avoid controversy, considering the source's limited reputation, the suggestion's weakness, and considering that the section already offers several other explanations. --Chealer (talk) 23:33, 21 April 2014 (UTC)[reply]
Coverity is a third-party source with regard to this article. The statement is not "out of date" just because it wasn't published this year, unless there are hints of an unlikely fast change in the area. The mention does not constitute original research. There is no need for everything in this article to be ulterior to Heartbleed's disclosure. Choizit's argument is a generalization from Heartbleed/OpenSSL to open-source is general. Such a generalization can be questioned and will inevitably be with the debate around this controversial topic (which we cover very briefly in [15]). This topic is old and has obviously been debated years before Heartbleed. Heartbleed's disclosure does not make all anterior material obsolete.
There is one issue with the statement's relevance - it is focused on C. While Heartbleed is written in C, proprietary equivalents could be written in safer languages, which would reduce the likeliness of equivalent vulnerabilities. I believe C is indeed overrepresented in free software, weakening the report's relevance, but I do not think this suffices to completely ignore the findings. --Chealer (talk) 23:33, 21 April 2014 (UTC)[reply]
QUOTE: “Security experts worldwide have deemed the so-called Heartbleed bug one of the most dangerous security flaws ever to crop up on the Web. While we don't know the full extent of Heartbleed's menace, the bug has the potential to cause catastrophic data breaches. When news of Heartbleed broke, Internet users were advised to change all their online passwords as a precaution, and enterprise IT security teams scrambled to neutralize the immediate threat by applying a patch. But like many serious conditions, the real danger posed by the Heartbleed bug is longer term and much more quiet than the initial hoopla might suggest. ” ["Patches are just band-aids. Heartbleed's long-term effects will force companies to reassess how they deploy and manage technology."] — Charles Edwin Shipp (talk) 14:24, 21 April 2014 (UTC) — PS: FYI for future editing.[reply]
Headine-2: Why Heartbleed May be more Troubling for Healthcare.gov in the Long Run
QUOTE: “Users of HealthCare.gov are being asked to change their passwords due to the federal exchange’s potential vulnerability to the Heartbleed security flaw, and the warning is troubling, analysts say, as medical information is hotter than ever for criminals looking to make a quick profit.” [Helathcare.gov and relating Obamacare websites and methodologies were never known for tight security!] — Charles Edwin Shipp (talk) 00:27, 23 April 2014 (UTC) — PS: FYI for future editing.[reply]
Headine-3: The U.S. Needs to Stop Running Internet Security Like a Wikipedia Volunteer Project
QUOTE: “ One lesson of the Heartbleed bug is that our government is paying to undermine Internet security, not to fix it.” [Comment-1: The left-handed compliment to Wikipedia is interesting; Comment-2: There is more to security than passwords—such as encrypted-transmission. Comment-3: This article is headlined for Google News; Comment-4: The last paragraph of the Article herein (WP) covers this aspect, to some extent.] — Charles Edwin Shipp (talk) 11:54, 23 April 2014 (UTC) — PS: FYI for future editing.[reply]
Resolved
Best, Mz7 (talk) 02:23, 10 April 2014 (UTC)
J744 (talk) 20:59, 12 April 2014 (UTC)
and 
. Mahahahaneapneap (talk) 12:35, 22 April 2014 (UTC)
