{"id":184,"date":"2014-07-01T10:56:01","date_gmt":"2014-07-01T15:56:01","guid":{"rendered":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/?p=184"},"modified":"2014-07-01T10:56:01","modified_gmt":"2014-07-01T15:56:01","slug":"how-did-heartbleed-remain-undiscovered-and-what-should-we-do-about-it","status":"publish","type":"post","link":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/2014\/07\/01\/how-did-heartbleed-remain-undiscovered-and-what-should-we-do-about-it\/","title":{"rendered":"How did Heartbleed remain undiscovered, and what should we do about it?"},"content":{"rendered":"

It was recently reported that the Heartbleed OpenSSL bug<\/a> has still not been patched on over 300,000 servers<\/a>. This is down from 600,000<\/a> that were discovered two months ago, when the bug was first publicized. Add to this delay the nearly two years that the bug went\u00a0undetected, and that’s a lot of exposure.<\/p>\n

In this blog post, I wonder about how programming languages and tools might have played a role in\u00a0finding Heartbleed before it got into production code. Then I explore possible approaches to improving this state of the affairs. I welcome your thoughts and ideas! <\/p>\n

Heartbleed<\/strong><\/p>\n

The Heartbleed bug, when exploited, allows an attacker to illicitly access certain contents in the memory of a\u00a0buggy server. (How the bug allows this is explained well by Matthew Green<\/a>.) The leaked\u00a0memory may contain things like secret keys and previously entered passwords, and so administrators of vulnerable servers\u00a0were advised to change\u00a0these keys (which creates its own problems) and users were\u00a0advised to change their passwords. The memory disclosed may also reveal the locations in memory of control-flow related data, which are useful in remote exploits, and would negate the protection conferred by\u00a0ASLR.<\/a>\u00a0As such, while the Heartbleed bug itself cannot be exploited to cause remote code execution, it could enable the\u00a0exploitation of another bug in the same server.<\/p>\n

It is particularly disturbing that so many hosts remain unpatched, because it would be hard to tell if Heartbleed is being exploited to acquire sensitive\u00a0information. Part of the difficulty is that\u00a0data\u00a0can\u00a0be exfiltrated\u00a0back to the attacking host as part of an encrypted connection and therefore invisible to packet monitoring software looking for evidence of exploitation. System administrators assuming that the bug is only being exploited using\u00a0packets transmitted “in the clear” rather than as part of an established secure connection have a false sense of security.<\/p>\n

Finding the Hearbleed\u00a0with static analysis<\/strong><\/p>\n

When this bug came out, colleagues asked me whether state-of-the-art static analysis tools (which analyze code for problems before that code\u00a0is run) should\u00a0have found Heartbleed\u00a0sooner. To paraphrase: You guys in programming languages have been working on tools to find bugs like this for a long time. I presume that companies\/developers should have been using these tools, and if so, they would have found the bug, right?<\/em><\/p>\n

Unfortunately, I suspect the answer is ‘no’. In particular, at least four commercial tools that perform static analysis on code — Coverity’s\u00a0Code Advisor<\/a>, Grammatech’s Code Sonar<\/a>, Klocwork’s Insight<\/a>, and Veracode’s code scanning services<\/a> — would not have found the bug. In fact, Coverity didn’t<\/em> find the bug: OpenSSL has been part of Coverity’s Open Scan project<\/a>\u00a0since 2006. The Scan\u00a0project uses Coverity tools to\u00a0analyze open source projects for free, and would have scanned OpenSSL after the Heartbleed bug was introduced in 2012. Only after the bug was publicly announced did Andy Chou of Coverity suggest, in a blog post, a (clever) way that Coverity’s\u00a0tool could be made to find the bug<\/a>. Grammatech and KlocWork quickly showed that their tools could play the same trick (here<\/a> and here<\/a>). My student, Andrew Ruef, wrote a Clang static analyzer plugin<\/a> that can find the bug in the same way.\u00a0Veracode simply hunts for the offending SSL code,<\/a> not for the root cause of the bug.<\/p>\n

Why couldn’t tools find the bug?<\/strong><\/p>\n

You would hope\/expect that these tools would have found the bug: A significant motivator for developing static analysis tools is to find critical bugs that testing, code reviews, and other methods would miss. This bug seems to be a perfect storm of challenging features, and a recent whitepaper<\/a> by James A. Kupsch and Barton P. Miller covers the details well. The basic explanation is that this bug involves a lot of complicated code and indirection through pointers, and as such\u00a0confounds the reasoning of most tools. (The fix that Andy Chou suggested was to circumvent these\u00a0complexities\u00a0with a heuristic that\u00a0identifies\u00a0likely “tainted”, or attacker-originating, input with an idiomatic code pattern.)<\/p>\n

A higher-level explanation of why tools couldn’t find the bug is that commercially viable\u00a0static analysis is\u00a0unsound,<\/em> with the goal of being more complete<\/em>. This is a technical way of saying that commercial tools deliberately choose to miss bugs so as to reduce the rate of false alarms<\/strong>.<\/p>\n

A sound<\/em> analysis is one that, if there exists an execution that manifests a bug at run-time, then the analysis will report the bug. Unfortunately, a sound analysis may also claim to find\u00a0bugs that do not actually manifest at run-time; these are called false alarms.<\/em> On the flip slide, a complete<\/em> analysis is one that, if it reports a bug, then that bug will surely manifest at run-time. Ideally, we would have an analysis that is both sound and complete, so that it reports all true bugs, and nothing else. Unfortunately, such an analysis is impossible for most properties of interest, such as whether a buffer is overrun (the root issue of Heartbleed). This impossibility is a consequence of\u00a0Rice’s theorem<\/a>,\u00a0which states that proving nontrivial properties of programs in Turing-complete languages is undecidable. So we will always be stuck dealing with either unsoundess or incompleteness.<\/p>\n

Having a high rate of false alarms is a tool killer. A rule of thumb I have heard is that users are willing to tolerate no more than 50% of the alarms being false. Bessey et al from Coverity wrote a great piece for Communications of the ACM<\/a> on their experience constructing a commercially viable static analysis tool. They report the toleration limit is 30%, not 50%, and in fact they aim for 20% for their “stable” checkers. They achieve\u00a0this rate by looking for the most simplistic bugs, and avoiding sophisticated analysis that, while it finds more bugs, yields more false alarms. One amazing (to me) line in the piece is<\/p>\n

the commercial Coverity product, despite its improvements, lags behind the research system in some ways because it had to drop checkers or techniques that demand too much sophistication on the part of the user.<\/p><\/blockquote>\n

In particular, users were labeling true bugs as false alarms, and had a harder time diagnosing false alarms, because the bugs being uncovered were very complicated and the error reports were hard to understand.<\/p>\n

Where does this leave research, and practitioners?<\/strong><\/p>\n

How can we balance both the need of better security and the expectations of software developers and their employers? Answers to this question are important for getting things done today, and for setting an agenda for impactful research.<\/p>\n

Of course we can and should develop better analysis algorithms, i.e., those that are closer to being sound while not having too many false alarms (and not being too slow). An important question is how we evaluate these\u00a0algorithms: beautiful theorems and simple benchmarks are not enough. We need realistic empirical assessments, both in terms of the power and precision of the tool in the hands of an expert, and in the hands of more ordinary developers. Assessing the latter may require studying real users, something the static analysis community rarely does.<\/p>\n

Fully sound\u00a0tools and processes may be appropriate for code that is security-critical, like OpenSSL, despite the greater demand and sophistication required of developers. For example, we could imagine applying\u00a0full formal verification<\/a><\/em>, the end result of which is a proof that the code will always behave\u00a0as it should. Such an approach is being increasingly viewed as viable. For example, DARPA’s HACMS program<\/a> has been pushing research to improve the\u00a0scalability, applicability and usability of formal verification. A recent research project has looked at formally verifying SSL.<\/a><\/p>\n

Another approach is simply to use type-safe languages, like Java and Haskell, which rule out pernicious bugs like buffer overruns\u00a0by construction. Rust<\/a> is a promising new language, since it aims to provide high performance by providing programmers low-level control like they have in C while retaining type safety. (I note that several\u00a0ideas in\u00a0Rust were inspired by the research language Cyclone<\/a>, which was\u00a0co-developed by\u00a0Trevor Jim<\/a>, Greg Morrisett<\/a>,\u00a0Dan Grossman<\/a>,\u00a0Nikhil Swamy<\/a>, and myself, among others.) I believe Google’s\u00a0Go<\/a> is also type-safe. That said, type safety does not rule out other important security-critical bugs, like information disclosures.<\/p>\n

Rather than try to (only) reduce the number of false alarms, we might imagine trying to reduce the time to triage an alarm, e.g., by making it easier to understand. Improved user interfaces, e.g., those that support a directed code review in response to an alarm, might provide some help, as one of prior study<\/a>\u00a0showed.<\/p>\n

But such tools require more sophisticated users who may need to understand better how a tool works, as the Coverity paper suggested. One approach is the business model of “static analysis as a service” as provided by Veracode. In this model, a user submits\u00a0their code for analysis, and engineers very familiar with the analysis triage its\u00a0warnings, providing a\u00a0report back the user. The issue here is that the static\u00a0analysis company’s engineers don’t understand the code. So the question is, what is more important for triaging: knowing the analyzed codebase, or knowing the analyzer itself?<\/p>\n

There must be a role for education, too, with the aim of fostering\u00a0more sophisticated users. By better\u00a0understanding what’s going on, such users can use static analysis or a sophisticated language as a tool<\/em>, rather than as a magic trick. It is my intuition that PL and static analysis courses that would help this understanding are becoming more common, even at the undergraduate level. This is a good thing.<\/p>\n

Stepping back: Heartbleed has raised our awareness that the importance of our software being free of errors is not just something that is nice to have, or a value-add for a business, but is necessary for maintaining a free and open society in which privacy and integrity are respected and maintained. We in the PL community\u00a0must continue to work\u00a0hard, building on many past successes, to\u00a0build better tools, techniques, languages, and methodologies that can\u00a0improve the quality of software. Where do you think we should go next?<\/p>\n","protected":false},"excerpt":{"rendered":"

It was recently reported that the Heartbleed OpenSSL bug has still not been patched on over 300,000 servers. This is down from 600,000 that were discovered two months ago, when the bug was first publicized. Add to this delay the … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[10,3],"tags":[],"class_list":["post-184","post","type-post","status-publish","format-standard","hentry","category-formal-verification","category-softsec"],"yoast_head":"\nHow did Heartbleed remain undiscovered, and what should we do about it? - The PL Enthusiast<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/2014\/07\/01\/how-did-heartbleed-remain-undiscovered-and-what-should-we-do-about-it\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"How did Heartbleed remain undiscovered, and what should we do about it? - The PL Enthusiast\" \/>\n<meta property=\"og:description\" content=\"It was recently reported that the Heartbleed OpenSSL bug has still not been patched on over 300,000 servers. This is down from 600,000 that were discovered two months ago, when the bug was first publicized. Add to this delay the … Continue reading →\" \/>\n<meta property=\"og:url\" content=\"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/2014\/07\/01\/how-did-heartbleed-remain-undiscovered-and-what-should-we-do-about-it\/\" \/>\n<meta property=\"og:site_name\" content=\"The Programming Languages Enthusiast\" \/>\n<meta property=\"article:published_time\" content=\"2014-07-01T15:56:01+00:00\" \/>\n<meta name=\"author\" content=\"Michael Hicks\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Michael Hicks\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"8 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/2014\\\/07\\\/01\\\/how-did-heartbleed-remain-undiscovered-and-what-should-we-do-about-it\\\/#article\",\"isPartOf\":{\"@id\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/2014\\\/07\\\/01\\\/how-did-heartbleed-remain-undiscovered-and-what-should-we-do-about-it\\\/\"},\"author\":{\"name\":\"Michael Hicks\",\"@id\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/#\\\/schema\\\/person\\\/7d875a015cb2e83e9cd476df91028d5d\"},\"headline\":\"How did Heartbleed remain undiscovered, and what should we do about it?\",\"datePublished\":\"2014-07-01T15:56:01+00:00\",\"mainEntityOfPage\":{\"@id\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/2014\\\/07\\\/01\\\/how-did-heartbleed-remain-undiscovered-and-what-should-we-do-about-it\\\/\"},\"wordCount\":1711,\"commentCount\":14,\"articleSection\":[\"Formal verification\",\"Software Security\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"http:\\\/\\\/www.pl-enthusiast.net\\\/2014\\\/07\\\/01\\\/how-did-heartbleed-remain-undiscovered-and-what-should-we-do-about-it\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/2014\\\/07\\\/01\\\/how-did-heartbleed-remain-undiscovered-and-what-should-we-do-about-it\\\/\",\"url\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/2014\\\/07\\\/01\\\/how-did-heartbleed-remain-undiscovered-and-what-should-we-do-about-it\\\/\",\"name\":\"How did Heartbleed remain undiscovered, and what should we do about it? - The PL Enthusiast\",\"isPartOf\":{\"@id\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/#website\"},\"datePublished\":\"2014-07-01T15:56:01+00:00\",\"author\":{\"@id\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/#\\\/schema\\\/person\\\/7d875a015cb2e83e9cd476df91028d5d\"},\"breadcrumb\":{\"@id\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/2014\\\/07\\\/01\\\/how-did-heartbleed-remain-undiscovered-and-what-should-we-do-about-it\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"http:\\\/\\\/www.pl-enthusiast.net\\\/2014\\\/07\\\/01\\\/how-did-heartbleed-remain-undiscovered-and-what-should-we-do-about-it\\\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/2014\\\/07\\\/01\\\/how-did-heartbleed-remain-undiscovered-and-what-should-we-do-about-it\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"How did Heartbleed remain undiscovered, and what should we do about it?\"}]},{\"@type\":\"WebSite\",\"@id\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/#website\",\"url\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/\",\"name\":\"The Programming Languages Enthusiast\",\"description\":\"Developments in PL, and why they matter\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/#\\\/schema\\\/person\\\/7d875a015cb2e83e9cd476df91028d5d\",\"name\":\"Michael Hicks\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/dd0371ad9a0cb821df683b5d6a6cccc911e6e2af1778f28b77e8c90b0c319d14?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/dd0371ad9a0cb821df683b5d6a6cccc911e6e2af1778f28b77e8c90b0c319d14?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/dd0371ad9a0cb821df683b5d6a6cccc911e6e2af1778f28b77e8c90b0c319d14?s=96&d=mm&r=g\",\"caption\":\"Michael Hicks\"},\"sameAs\":[\"http:\\\/\\\/www.cs.umd.edu\\\/~mwh\\\/\"],\"url\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/author\\\/mwh\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"How did Heartbleed remain undiscovered, and what should we do about it? - The PL Enthusiast","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/2014\/07\/01\/how-did-heartbleed-remain-undiscovered-and-what-should-we-do-about-it\/","og_locale":"en_US","og_type":"article","og_title":"How did Heartbleed remain undiscovered, and what should we do about it? - The PL Enthusiast","og_description":"It was recently reported that the Heartbleed OpenSSL bug has still not been patched on over 300,000 servers. This is down from 600,000 that were discovered two months ago, when the bug was first publicized. Add to this delay the … Continue reading →","og_url":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/2014\/07\/01\/how-did-heartbleed-remain-undiscovered-and-what-should-we-do-about-it\/","og_site_name":"The Programming Languages Enthusiast","article_published_time":"2014-07-01T15:56:01+00:00","author":"Michael Hicks","twitter_misc":{"Written by":"Michael Hicks","Est. reading time":"8 minutes"},"schema":{"@context":"https:\/\/fd.xuwubk.eu.org:443\/https\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/2014\/07\/01\/how-did-heartbleed-remain-undiscovered-and-what-should-we-do-about-it\/#article","isPartOf":{"@id":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/2014\/07\/01\/how-did-heartbleed-remain-undiscovered-and-what-should-we-do-about-it\/"},"author":{"name":"Michael Hicks","@id":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/#\/schema\/person\/7d875a015cb2e83e9cd476df91028d5d"},"headline":"How did Heartbleed remain undiscovered, and what should we do about it?","datePublished":"2014-07-01T15:56:01+00:00","mainEntityOfPage":{"@id":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/2014\/07\/01\/how-did-heartbleed-remain-undiscovered-and-what-should-we-do-about-it\/"},"wordCount":1711,"commentCount":14,"articleSection":["Formal verification","Software Security"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/2014\/07\/01\/how-did-heartbleed-remain-undiscovered-and-what-should-we-do-about-it\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/2014\/07\/01\/how-did-heartbleed-remain-undiscovered-and-what-should-we-do-about-it\/","url":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/2014\/07\/01\/how-did-heartbleed-remain-undiscovered-and-what-should-we-do-about-it\/","name":"How did Heartbleed remain undiscovered, and what should we do about it? - The PL Enthusiast","isPartOf":{"@id":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/#website"},"datePublished":"2014-07-01T15:56:01+00:00","author":{"@id":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/#\/schema\/person\/7d875a015cb2e83e9cd476df91028d5d"},"breadcrumb":{"@id":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/2014\/07\/01\/how-did-heartbleed-remain-undiscovered-and-what-should-we-do-about-it\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/2014\/07\/01\/how-did-heartbleed-remain-undiscovered-and-what-should-we-do-about-it\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/2014\/07\/01\/how-did-heartbleed-remain-undiscovered-and-what-should-we-do-about-it\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/"},{"@type":"ListItem","position":2,"name":"How did Heartbleed remain undiscovered, and what should we do about it?"}]},{"@type":"WebSite","@id":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/#website","url":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/","name":"The Programming Languages Enthusiast","description":"Developments in PL, and why they matter","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/#\/schema\/person\/7d875a015cb2e83e9cd476df91028d5d","name":"Michael Hicks","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/fd.xuwubk.eu.org:443\/https\/secure.gravatar.com\/avatar\/dd0371ad9a0cb821df683b5d6a6cccc911e6e2af1778f28b77e8c90b0c319d14?s=96&d=mm&r=g","url":"https:\/\/fd.xuwubk.eu.org:443\/https\/secure.gravatar.com\/avatar\/dd0371ad9a0cb821df683b5d6a6cccc911e6e2af1778f28b77e8c90b0c319d14?s=96&d=mm&r=g","contentUrl":"https:\/\/fd.xuwubk.eu.org:443\/https\/secure.gravatar.com\/avatar\/dd0371ad9a0cb821df683b5d6a6cccc911e6e2af1778f28b77e8c90b0c319d14?s=96&d=mm&r=g","caption":"Michael Hicks"},"sameAs":["https:\/\/fd.xuwubk.eu.org:443\/http\/www.cs.umd.edu\/~mwh\/"],"url":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/author\/mwh\/"}]}},"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/wp-json\/wp\/v2\/posts\/184","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/wp-json\/wp\/v2\/comments?post=184"}],"version-history":[{"count":11,"href":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/wp-json\/wp\/v2\/posts\/184\/revisions"}],"predecessor-version":[{"id":202,"href":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/wp-json\/wp\/v2\/posts\/184\/revisions\/202"}],"wp:attachment":[{"href":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/wp-json\/wp\/v2\/media?parent=184"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/wp-json\/wp\/v2\/categories?post=184"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/wp-json\/wp\/v2\/tags?post=184"}],"curies":[{"name":"wp","href":"https:\/\/fd.xuwubk.eu.org:443\/https\/api.w.org\/{rel}","templated":true}]}}