How Can Hosts Communicate Security Risks Without Creating Fear

How Can Hosts Communicate Security Risks Without Creating Fear? ![rw-book-cover](https://img.youtube.com/vi/lAa4s_23yqs/maxresdefault.jpg) 🔗 **Source:** [How Can Hosts Communicate Security Risks Without Creating Fear?](https://www.youtube.com/watch?v=lAa4s_23yqs) > [!note]+ Document Notes > tags: [wordpress-hosting-security, ai-powered-communication, user-security-education, dark-web-monitoring, trust-and-branding] > author: Jesse Friedman > source: Impressive Hosting > reference: https://www.youtube.com/watch?v=lAa4s_23yqs > date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} > > # 🏷️ Title: How Can Hosts Communicate Security Risks Without Creating Fear? (with Aaron Campbell) >  ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [Monarx](https://monarx.com) — the security vendor Aaron Campbell works for; powers malware detection and dark-web monitoring behind several major hosts and registrars. - [Have I Been Pwned](https://haveibeenpwned.com) — the breach-lookup service referenced as the kind of alert ("you've been pwned") that confuses non-technical users. - *Code for the People* — Automattic-produced documentary referenced regarding WordPress's low barrier to entry and its security tradeoffs. ## 📝 Summary - Aaron Campbell (VP of Product, Monarx) joins host Jesse Friedman to discuss where hosting-company responsibility for security ends and site-owner/agency responsibility begins. - Core argument: baseline security should mean a clean, well-maintained "neighborhood" (infrastructure); everything beyond that — throttling, monitoring, remediation — should be framed as an add-on service the host actively surfaces, not a bundled-in freebie nobody notices. - The deeper problem isn't a lack of security tooling, it's a communication gap: most site owners don't understand why an unremarkable small-business or portfolio site would ever be targeted, so warnings land as confusing or alarming rather than actionable. - AI's most promising near-term role isn't writing exploits or fixing vulnerabilities — it's translation: turning dense technical breach data into plain-language, concrete next steps, and potentially nudging risky admin decisions (like leaving a stranger's admin account active) in real time. - Key stakeholders: end users/site owners (low technical literacy, high anxiety when alerted), agencies (juggle multiple hosts, need vendor-agnostic trust), hosts (own the infrastructure and the primary customer relationship), and security vendors like Monarx (operate largely white-labeled, behind the host's brand). - Risk/tradeoff: white-labeling protects the host relationship but risks diffusing trust in the security vendor itself, especially for agencies working across multiple hosts who need to trust the underlying technology, not just the storefront. - Bottom line: fear doesn't drive remediation, specificity does — vague alerts paired with concrete, numbered actions convert anxiety into completed action, and hosts (not core WordPress) are best positioned to deliver that translation layer. ## 📖 Main Content - **The neighborhood/city metaphor.** Friedman extends an agency metaphor (site-as-house) outward: hosting infrastructure is the neighborhood/city, and the host functions like municipal policing — responsible for keeping shared infrastructure clean, but unable to stop a resident from leaving their own door unlocked (weak WordPress passwords, `admin/admin` logins). - **Baseline vs. add-on security.** Campbell's central claim is that not every site needs identical protection — an e-commerce store and a static portfolio have different risk profiles — so hosts shouldn't force an "everything bundle." Instead, hosts should keep their own infrastructure secure, then surface detection and risk information to the customer so the customer can decide what additional protection they want (e.g., login-attempt throttling). - **Reframing security as a value-add, not a base-level utility.** Historically, hosts treated security as included because technically sophisticated agencies/owners handled the extras themselves. As that technical sophistication has dropped (WordPress's lowered barrier to entry, referenced via Automattic's *Code for the People* documentary), hosts must reposition those same extras as visible, sellable, beneficial services — otherwise awareness never reaches the end user. - **Why users don't believe they're targets.** Drawing on his time at BruteProtect, Campbell notes most site owners assume small/unremarkable sites are safe from attack. The real dynamic is blanket, automated scanning of every new domain registration, usually targeting server *resources* rather than the site's content specifically — not a targeted human attacker picking on a mom-and-pop shop. - **The fear/education balance.** Campbell frames the central design tension as: help users understand real vulnerability without using fear as a sales tactic. Overstating risk erodes trust; understating it leaves people exposed. - **AI as a translation layer, not just a coding tool.** Both speakers converge on AI's underused strength: converting technical jargon (e.g., dark-web breach contents) into plain language a non-technical person can act on. Monarx already uses AI this way in its dark-web monitoring product to summarize what was found in a breach. - **A hypothetical in-admin AI assistant.** Campbell proposes a real-time assistant inside `wp-admin` that intervenes at risky moments — e.g., when a site owner creates a new admin account for a helper (a common WordCamp scenario), the assistant could ask whether that person needs full admin access or a lesser role, and could offer to remind the owner to remove access later. - **Calibrating certainty in alerts.** Because tools like dark-web monitoring often can't confirm whether a specific stored password is currently vulnerable, messaging has to hedge ("you *may* need to change your password") — but Campbell insists the *steps* offered should stay concrete even when the underlying certainty is fuzzy (e.g., "click here to change your password" rather than vague urgency alone). - **Trust and brand diffusion.** Monarx operates almost entirely white-labeled behind hosts (and some registrars), API-first, letting each host build its own customer-facing dashboard. Friedman raises the concern that this fragments security messaging across many host brands. Campbell's resolution: agencies working across multiple hosts benefit from trusting the underlying vendor (Monarx) directly, while retail end users who only ever interact with one host (e.g., Bluehost) neither need nor want to know a third-party vendor exists — they just need the host's promise of safety to be backed by real technology. ## 🗒️ Notes - Campbell: 15 years in hosting, ran his own agency before moving hosting-side; now VP of Product at Monarx, helping hosts fight malware and bad actors. - The "responsibility gradient" framed by Friedman: hosts owe a baseline (secure infrastructure/"neighborhood"), agencies/DIYers owe the rest (their own "deadbolt")—but Campbell pushes back that hosts now need to actively surface and sell that second layer too, since the historical assumption (agencies handle extras) no longer holds at WordPress's current scale of non-technical adoption. - Concrete host-side UX pattern described: dashboard messaging like "you've had this many failed login attempts, we could help throttle those if you'd like" — opt-in framing rather than forced bundling. - BruteProtect anecdote: the biggest early lesson was that most users didn't understand *why* they'd be attacked at all — attacks are blanket/automated against newly registered domains, not curated against specific "boring" sites. - WordCamp anecdote: helpers are frequently granted full admin access by well-meaning site owners who then forget the account exists — Campbell uses himself ("I find myself to be a trustworthy person, but that doesn't mean everyone is, or is for all time") as the cautionary example, not a bad actor. - Monarx's dark-web monitoring product uses AI specifically to translate breach jargon into plain language and to generate a "to-do list" per breach rather than one generic warning — differentiating by what type of data leaked (password vs. address/phone, which triggers credit-monitoring advice instead). - Design principle stated explicitly: when the underlying certainty is vague, keep the *action* concrete anyway — this is offered as the mechanism for reducing user stress without overpromising. - Business model clarified: Monarx powers security at "many of the big hosts" and some registrars, fully API-first; some hosts build fully custom dashboards on top, others use Monarx's supplied customer portal directly. - Friedman draws a parallel to his own employer's model (WP Cloud/Automattic): 100% API-based, fully managed WordPress with performance/security handled behind the host's brand — surfacing the same white-label trust tension from the buy side. - Segment closes with both guests confirming WordCamp US attendance, expecting a hot outdoor/cool-indoor dynamic pushing more attendees into expo-hall conversations. ## 📚 References - [Monarx](https://monarx.com) — security vendor discussed throughout; malware detection, dark-web monitoring, API-first host integrations. - [Have I Been Pwned](https://haveibeenpwned.com) — referenced as the archetypal breach-notice language ("you've been pwned") that confuses non-technical recipients. - *Code for the People* (Automattic documentary) — referenced re: WordPress's lowered technical barrier to entry and its security tradeoffs. ## 🗣️ Paraphrase - Hosts keep the shared infrastructure clean, but a site owner with a weak password is still the one leaving their own door unlocked — no amount of host-side hardening substitutes for basic account hygiene, and hosts can't be blamed for what happens past their own perimeter. - The industry's real gap isn't tooling, it's translation: most people who get hacked never understood they were a target in the first place, and a security alert that arrives in unfamiliar jargon triggers panic instead of action — so the fix is plain language paired with a short, concrete list of next steps, not a scarier warning. ## 📰 Newsletter Ever wonder why your "just a portfolio site" got hacked anyway? Aaron Campbell (VP of Product, Monarx) sits down with Jesse Friedman to unpack why hosts — not core WordPress — are the right layer to translate security risk into plain language, why fear-based messaging backfires, and how AI is quietly becoming less "write my exploit" and more "explain my breach notice like I'm a human." Bonus: a genuinely good idea for a `wp-admin` assistant that stops you from forgetting you handed someone full admin access at WordCamp. Worth a listen before WCUS. 🎧 [Watch on YouTube](https://www.youtube.com/watch?v=lAa4s_23yqs) ## ✅ Action Items #### DevRel - Education: build a short, plain-language explainer ("why would anyone attack *my* site?") aimed at non-technical WordPress owners — directly addresses the awareness gap Campbell describes from his BruteProtect days. #### OSPO - Security Management: for teams integrating third-party security vendors (Monarx-style), document a vuln/breach-intake and customer-notification policy that specifies plain-language + concrete-step messaging as a requirement, not a nice-to-have. #### WordPress - Support: review existing support-flow language for security notices (failed logins, breach alerts) against the "concrete step even when certainty is vague" principle. - Documentation: HelpHub/DevHub gap — no current beginner-facing doc explains *why* small sites get targeted (blanket/automated scanning vs. targeted attacks); worth drafting. ## 🧪 Hypotheses - **H1**: Hosts that reposition security as an opt-in, visibly-surfaced add-on (vs. a silent bundled default) see higher customer uptake of optional protections like login throttling. - **H2**: AI-translated, plain-language breach notifications increase the completion rate of recommended remediation steps compared to raw technical breach data. - **H3**: Alerts paired with concrete, numbered actions reduce reported user anxiety more than accurate-but-vague warnings, even when the vague warning is technically more honest about uncertainty. - **H4**: Retail end users' trust in a white-labeled security vendor is mediated almost entirely through the host brand, while agencies/resellers form independent trust in the vendor itself. - **H5**: A real-time `wp-admin` assistant that flags newly created admin accounts reduces the incidence of forgotten/abandoned admin accounts becoming compromise vectors. ### 📊 Methodology - H1/H3: A/B test two versions of a host dashboard (bundled-silent vs. surfaced-optional) or two alert copy variants (vague vs. vague+concrete-steps), measuring feature adoption or remediation completion rate. - H2: Compare completion/response rates between raw vendor breach data and an AI-summarized version, sent to matched user cohorts. - H4: Survey agencies vs. retail site owners on brand recall/trust for the security vendor powering their host, controlling for host brand. - H5: Track admin-account creation-to-removal intervals on sites with and without a nudging assistant enabled, over a fixed window (e.g., 90 days). ### ❓ Questions - At what point does "helping the customer understand what they need" tip into upsell pressure that itself erodes trust? - If AI increasingly writes the plain-language translation layer, who is accountable when the simplification omits something material? - Does white-labeling security vendors behind host brands create a single point of failure risk (one vendor, many hosts, one class of bug) that end users have no visibility into? ### 🔮 Future Research - Empirical measurement of "trust transfer" from host brand to underlying white-labeled security vendor, segmented by user sophistication (retail vs. agency vs. enterprise). - Longitudinal study of WordCamp-style ad hoc admin-account grants and their downstream compromise rate. - Comparative study of AI-generated vs. human-written breach notifications on completion rate and reported anxiety. ### 💡 Implications - **Practice**: Hosts should treat security messaging as a product-design problem (concrete steps, calibrated certainty) rather than a legal/CYA problem (maximal disclaimers). - **Security**: Blanket/automated attacks mean "I'm too small to be a target" is a persistently dangerous misconception worth actively correcting in onboarding flows. - **Education**: There's a real opening for WordPress-adjacent education content that explains attacker economics (resource-hijacking, not personal vendettas) to non-technical audiences. - **Funding/business models**: API-first, white-label security vendors depend on hosts choosing to surface (not bury) their findings — a vendor's growth is partly gated by its partners' UX choices, not just its own detection quality. ### 🧠 Learning Styles Assessment - Reading level estimate: Flesch–Kincaid Grade Level ≈ 8–9 (conversational spoken transcript, short clauses, frequent restarts/fillers typical of unscripted podcast speech — easier than the vocabulary alone would suggest because sentence structure stays simple). #### 👀 Visual learners - Present: none (audio-only source, no diagrams/screenshots in the transcript). - Improve: a simple diagram of the "neighborhood/city" metaphor (host infrastructure vs. individual site) would visually reinforce the episode's central framing device. #### 🔊 Aural learners - Present: this *is* the native format — full podcast audio/video. - Improve: none needed; format already serves this style directly. #### 🗣️ Verbal learners - Present: strong use of analogy (house/neighborhood/city; deadbolt vs. infrastructure) and concrete examples (WordCamp admin-account anecdote, father-in-law "you've been pwned" scenario). - Improve: a short glossary of terms used loosely in speech (e.g., "dark web monitoring," "throttling") would help verbal learners anchor definitions. #### 🧩 Kinesthetic learners - Present: minimal — no exercises or hands-on steps in the source itself. - Improve: a companion checklist ("review your `wp-admin` users list this week") would convert the discussion into a doable task. #### 🧠 Logical learners - Present: the responsibility-gradient argument (host vs. agency vs. owner) is structured causally, if informally. - Improve: a simple decision table (site type → recommended security tier) would make the "not every site needs the same bundle" argument more scannable. #### 🧑‍🤝‍🧑 Social learners - Present: the format itself is a dialogue, modeling how to talk through the fear/education tension collaboratively. - Improve: impressive.host is explicitly positioned as a discussion/comment hub — worth cross-referencing directly in show notes. #### 🧘‍♀️ Solitary learners - Present: none explicit. - Improve: a short self-audit prompt ("when did you last review your site's admin users?") would suit self-paced reflection. #### 🌿 Naturalistic learners - Present: the neighborhood/ecosystem metaphor for hosting infrastructure has a loose environmental-systems flavor. - Improve: could be extended explicitly (e.g., "invasive species" framing for automated bot attacks) if the metaphor were developed further. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: N/A at the source level (raw video); this note itself uses semantic headings throughout. - Improve: publishing platform should ensure the video page has proper heading structure and landmark regions around the transcript. #### Keyboard navigation - Present/Improve: not assessable from transcript content alone; depends on the hosting page's player controls. #### Contrast and readability - Present/Improve: not assessable from transcript content; applies to impressive.host's page design, not this content. #### Text resizing and reflow - N/A — text-based note reflows normally in Obsidian/markdown renderers. #### Media and captions - Present: a transcript exists (this document's source), which is the single largest accessibility win for this format. - Improve: no timestamps were present in the supplied transcript, which weakens deep-linkability; a timestamped, downloadable transcript with audio descriptions would raise this further. #### Forms and interactions - N/A — no interactive elements in this content type. #### Standards reference - Primary applicable WCAG 2.2 AA criterion: 1.2.2 (Captions, Prerecorded) — satisfied if the published video includes captions; this transcript alone doesn't confirm caption availability on the original upload. ### 🌍 DEIB Assessment #### Cultural breadth - Present: single US-based conversation (Oklahoma-based guest, unspecified host location); no international examples of hosting/security norms. - Improve: future episodes could include non-US hosting/regulatory context (e.g., GDPR-driven breach-notification norms differ meaningfully from US practice). #### Inclusive language - Present: plain, jargon-aware language when discussing non-technical users ("less security aware," not pejorative framing). - Improve: define "dark web monitoring," "throttling," and "admin" explicitly for a first-time listener. #### Neurodiversity support - Present: conversational chunking by topic (baseline security → AI → dark-web monitoring → trust/branding) gives some natural structure. - Improve: consistent segment markers/timestamps (absent in the supplied transcript) would materially help predictable navigation. #### Representation - Present: two male speakers; no other identities represented in this episode's content. - Improve: future guest slate diversity is a structural note for the show, not fixable within a single episode's content. #### Psychological safety - Present: both speakers explicitly reject fear-based tactics as a design principle, which is itself a psychologically safety-conscious stance toward the audience. - Improve: none — this is a strength of the source material. ### ✅ Logical Validity #### Strong reasoning - The neighborhood/city extension of the house metaphor (Friedman) is a clear, well-scoped analogical argument: it correctly separates infrastructure-level responsibility from account-level responsibility without overclaiming host liability for user password hygiene. - Campbell's causal explanation of *why* small sites get attacked (automated, resource-seeking, blanket scanning vs. targeted human attackers) is inductively grounded in direct field experience (BruteProtect user interviews) rather than assumption. #### Fallacies - Mild anecdotal generalization: Campbell's father-in-law example (used by Friedman) illustrates one user's reaction to a breach notice; it's used illustratively rather than as proof of a general pattern, so the risk is low, but it's worth flagging that no broader user-research data is cited alongside it. - No DARVO-adjacent or bad-faith argumentative patterns were present; this is a collaborative interview, not an adversarial exchange, so classic fallacies (straw man, false dichotomy, ad hominem) don't really arise. #### Tone of voice - Collegial, reflective, occasionally self-deprecating (Campbell on his own trustworthiness "for all time"); both speakers signal epistemic humility ("I wonder if," "maybe," "I don't know if") rather than overclaiming certainty — consistent with the episode's own thesis about avoiding fear-based overstatement. ### 🛡️ DARVO Analysis - Deny: not present — no accusation is being deflected in this conversation. - Attack: not present — no party's credibility is under attack. - Reverse victim/offender: not present. - This is a cooperative interview format; DARVO analysis doesn't meaningfully apply. Noted for completeness per template. ## 🎯 Conclusion - The episode's throughline: security failures at the WordPress-hosting layer are less often a tooling gap than a communication gap — users don't act on warnings they don't understand, and fear-based framing makes that worse, not better. - Practical next step for hosts/practitioners: audit existing security-alert copy for two things — plain language and at least one concrete, doable action — regardless of how uncertain the underlying detection is. - Practical next step for readers: review who currently holds admin access on your own WordPress site(s); the episode's WordCamp anecdote is a direct, low-effort self-audit prompt. ## 🔄 Refactor Appendix — How Can Hosts Communicate Security Risks Without Creating Fear? ### 📚 Literature Atoms (H3) #### Hosts owe security education proportional to the awareness gap > [!quote] > hosts have a responsibility to some extent to help their users who are by nature less security aware than the hosts themselves **Context & use**: - Early in the interview, framing Campbell's central thesis. - Grounds the whole episode's responsibility-gradient argument (host vs. agency vs. owner). **Tags**: #xref  #### Most attacked users never understood why they were targets > [!quote] > a lot of folks just didn't even understand why they would be attacked **Context & use**: - Drawn from Campbell's user-interview experience at BruteProtect. - Root cause behind why security alerts land as confusing rather than actionable — directly informs the episode's fear-vs-education framing. **Tags**: #xref #articleseed  #### Concrete steps matter more than certainty in risk messaging > [!quote] > make sure that at least the steps that they can do are concrete **Context & use**: - Campbell's design rule for Monarx's dark-web monitoring alerts, offered as the general fix when underlying detection is uncertain. - Directly reusable outside WordPress/hosting — a general risk-communication principle. **Tags**: #xref #aphorisms  ### 🧠 Permanent Candidates (H4) #### Concrete steps convert alert anxiety into action **Claim** (one sentence, Courtney's voice): When a risk message can't be fully certain, giving the recipient one concrete, doable action still lowers their anxiety more than a more "honest" but vague warning would. **Evidence pointer**: [[#Concrete steps matter more than certainty in risk messaging]] **Scope & conditions**: - Holds when: the recipient has genuine agency to act on the step offered (e.g., "click here to change your password"). - Breaks when: the concrete step is itself wrong, or the recipient has no real ability to act (false sense of control). **Links** (≥1 with annotation): - [[Risk communication]] — because applies-in security-breach and health-alert UX generally - [[Fear-based marketing]] — because contrasts on mechanism (this note's approach explicitly rejects fear as the lever)  ### ✏️ Fleeting Queue - [F1] Research how "trust transfer" from a host brand to a white-labeled security vendor could actually be measured (agency vs. retail split) — H4 above #xref - [F2] Cross-check Automattic's *Code for the People* documentary for the exact framing of WordPress's lowered barrier to entry vs. how Paulo phrases it here #xref ### → Things 3 (max 2 actions) - [ ] Review admin users on personal WordPress sites for stale/forgotten access — prompted by WordCamp anecdote #things --- ## Full Transcript [00:00] I do think that hosts have a [00:01] responsibility [music] to some extent to [00:05] help their users who are by nature less [00:11] security aware than the hosts themselves [00:14] um be able to stay secure online. [00:18] >> Now I I find myself to be a trustworthy [00:20] person but uh that doesn't mean that you [00:22] know everyone is and it doesn't mean [00:23] that everyone is for all time. What I [00:25] think is most important for hosts is [00:29] helping their customers understand what [00:32] it is that they need and why it is that [00:34] they need it. [music] [00:35] >> You know, in talking to users and going [00:37] out and reaching out and actually [00:38] talking to users, what we found is that [00:40] a lot of folks just didn't even [00:42] understand why they would be attacked. [00:51] Welcome to Impressive Hosting, a podcast [00:53] about the role hosting plays in shaping [00:54] the open web. I'm your host, Jesse [00:56] Freriedman. On this show, we go deeper [00:58] than uptimes, dashboard, and dashboards. [01:00] [music] [01:00] We talk about hosting as infrastructure, [01:02] about ownership, independence, and what [01:04] it takes to build ethical high-end [01:06] WordPress hosting that actually serves [01:08] creators, businesses, and [music] the [01:10] internet itself. Before we dive in, head [01:12] to impressive.host. That's where you can [01:14] comment on episodes, ask follow-up [01:16] questions, and help shape future [01:18] conversations. You'll also find links to [01:20] follow, like, and subscribe wherever you [01:22] listen. Today, I'm very happy to have [01:25] Aaron Campbell, VP of product at [01:27] Monarchs, joining us today to talk about [01:30] security. We're going to talk about Word [01:31] Camp US. [music] We're going to talk [01:33] about a variety of different things and [01:34] a little bit about AI, probably a lot [01:37] about AI and how it's uh shaping the [01:39] future of security and [music] how it's [01:40] affecting WordPress. Aaron, thanks for [01:42] joining. tell us a little about what [01:44] you're working on and where you're from [01:45] and all that. [01:47] >> Yeah, thanks for having me. Um, [01:50] well, I guess where I'm from. I'm I'm [01:53] I'm in the middle of nowhere in the [01:56] middle of the US. I I live in in [01:58] Oklahoma. Enjoy the the technical side [02:01] of work and the open um uh I guess [02:04] outdoor spaces in Oklahoma. Um, but [02:09] where I'm from professionally, I've been [02:11] through um a a lot of things here from [02:15] running my own agency and then moving [02:17] into the hosting space where I've pretty [02:20] much found myself digging in deep over [02:22] the last 15 years. Um, and now at [02:28] Monarchs, where we are help hosts fight [02:32] malware and bad actors and keep their [02:37] sites, their servers, and their users [02:40] um, safe and secure, which is a very [02:45] um, interesting and fun problem to be [02:49] solving in our modern AI powered days. [02:53] keeps me on my toes and uh gives me fun [02:56] problems to solve. [02:58] >> Yeah, it's interesting. I uh I [02:59] appreciate the fact that you went from [03:01] working with a host to now supporting [03:03] the host from a from an outside [03:05] perspective. Security is always [03:06] something that's really interesting to [03:08] me in the way in which we talk to [03:09] agencies and other end customers about [03:12] it. I think one thing that always comes [03:14] up with hosting companies is that um [03:17] there is, you know, a baseline level of [03:19] security that all hosts should be [03:21] expected to bring uh to the table. Then [03:24] there's the added layers of security [03:26] that uh hosts opt in to bring. Sometimes [03:29] they end up charging customers for it. [03:31] Um, but you know, it's an interesting [03:33] thing because I think most folks at [03:35] home, especially the the most novice of [03:38] us, think that everything is um fully [03:41] incorporated into every hosting plan [03:43] that they get. They they think that that [03:45] all the security that they're going to [03:46] need is uh already built in. So, you [03:50] know, from your perspective as someone [03:51] who used to work for a hosting company [03:53] and now is working for a security [03:54] company, where do you think you draw [03:56] that line? Where do you think um hosts [03:59] are, you know, responsible to to secure [04:01] things and where do you think the uh [04:04] agency or the um you know DIYer is [04:08] responsible to pick up the uh the slack [04:10] there? [04:12] >> Right into right into one of the biggest [04:14] questions that hosts have been [04:15] struggling, [04:15] >> right? We might as well just dive into [04:16] the deep end, right? Uh, so this is a [04:19] this is a great um question though, [04:22] Jesse, because I think that this is [04:27] shifting some in our in our modern day. [04:30] Um, but it's still a thing that hosts [04:33] struggle with lots. Now to be clear um I [04:36] do think that hosts have a [04:37] responsibility to some extent to help [04:41] their users who are by nature less [04:47] security aware than the hosts themselves [04:50] um be able to stay secure online. [04:54] However, not all users at any given host [04:58] need the same [05:00] types of security, level of security. [05:03] Um, people are running different kinds [05:06] of sites and applications. Some are [05:09] selling things, some are not. Um, and so [05:13] the host does not need to um include the [05:18] same everything bundle for everyone. [05:22] What I think is most important for hosts [05:25] is helping their customers understand [05:28] what it is that they need and why it is [05:31] that they need it. Um, so I think the [05:34] biggest thing that hosts need to be [05:36] doing is everything to keep their own [05:38] infrastructure secure so that the the [05:40] neighborhood if you will that the [05:43] customer is hosting in is generally [05:46] secure and clean. Um, and then all the [05:50] detection, all the awareness, um, and [05:54] raising that to the customer in a way [05:56] that lets the customer know exactly what [05:59] their risk is and what they can do to [06:00] solve it. And so that may look like, [06:03] hey, we don't block all these potential [06:07] attacks, but what we do um is we raise [06:12] this in your dashboard. you have had [06:15] this many failed login attempts, we [06:18] could help throttle those if you would [06:21] like. If that's not a thing you want, if [06:23] that's not important to you, you don't [06:25] need to upgrade to that service. Um, and [06:27] you can roll that general rule of thumb [06:30] out across the board. I really like [06:33] that. So, you know, when we when I was [06:35] working with agencies in the past, a lot [06:37] of times I'd watch as they would [06:40] describe the website building process as [06:44] designing a house. Um, the, you know, [06:47] the foundation, the framework of it, [06:49] very much like the CMS of your choice, [06:52] the aesthetics, the design of the house, [06:54] the colors, the fonts, and, you know, is [06:56] equivalent to the fonts and the and the [06:59] uh user interface and the user [07:00] experience that you choose for your [07:02] website. But I never really thought [07:03] about it that metaphor extending beyond [07:07] the house and into the neighborhood and [07:09] into the city. And that's very much the [07:11] way it works. The infrastructure itself [07:13] is the culde-sac or the the city [07:15] infrastructure provided by the hosting [07:17] company. And there is a layer of [07:20] policing we might say that is a [07:23] responsible uh the responsibility of the [07:26] city to to enforce and to make sure that [07:28] they are in fact um you know securing [07:31] the neighborhood and securing everyone [07:33] around you. But there's only so much [07:35] they can do when you start inviting [07:37] predator predatory people into your [07:40] home, right? And this is something that [07:42] we have always talked about too, right? [07:43] Like if you if you're running WordPress [07:46] and uh you know you have the most secure [07:48] infrastructure, the most insecure city, [07:51] uh but your you know passcode on your on [07:54] your digital uh bolt, your deadlock on [07:58] your on your home is 000000 or your [08:00] password to WordPress is you know admin [08:03] admin or something like that. There's [08:04] only so much a hosting company can do to [08:06] protect you at that point. So you do [08:08] have some level of uh responsibility to [08:11] to that. But, you know, it's interesting [08:13] because I think the [08:18] and this actually came up in the the [08:19] recent documentary that was released by [08:21] automatic, the code code for the people. [08:23] I remember Paulo talking about this that [08:25] there's um you know, one of the greatest [08:27] things that happened is that the barrier [08:29] of entry was removed and and lowered to [08:32] an extent where anyone at any level is [08:35] able to build a website. Uh but that [08:37] also means that they don't come getting [08:39] an education in security. they don't get [08:42] >> uh years of experience understanding how [08:44] to thwart uh attacks or block malicious [08:47] actors or um even just have the basic [08:50] knowledge of you know what what provides [08:53] uh vulnerabilities uh you know in their [08:55] space. So so how do we go about [08:57] educating people in security when it you [08:59] know for the most part people are bored [09:02] by it. They're not interested in it. [09:04] They're very focused on marketing or [09:05] getting their website up and running. [09:07] They're very focused on getting leads or [09:08] sales. security is usually a back seat. [09:11] So, how how do we get, you know, to a [09:13] place where we're [09:15] um, you know, accepting the fact that [09:18] the barrier of entry is super low, but [09:20] also, you know, understanding the fact [09:21] that these folks don't have that level [09:23] of education, they don't necessarily [09:24] want it. [09:27] >> Yeah. So I think that um I think that th [09:31] this is one of the places that hosts [09:35] really have to look at security as [09:40] a beneficial add-on service and not as a [09:45] bundled in included just like the [09:49] servers connected to the internet with a [09:51] really big pipe kind of base level [09:54] inclusion because by viewing [09:57] security as this add-on, this thing that [10:03] makes your hosting better, that can make [10:05] your package better, that can um do [10:08] these extra better things for you. [10:12] You then position it that way in all of [10:16] your customer interactions, and that's [10:19] what helps build customer awareness. For [10:22] the longest time, security has been a [10:27] base level thing included in hosting. [10:31] However, that was when all the added [10:34] security, all the extras that needed to [10:36] be done were done by the agency or the [10:40] site owner because there was that higher [10:43] level of technical understanding. Now is [10:46] that level of technical understanding [10:48] has lowered and the host has to become [10:51] the the expert there that to to help [10:54] guide um the even some agencies but it [10:57] defin definitely site owners um they [11:01] need to view those extra steps that were [11:04] being done by the end user before as [11:08] beneficial things and start bringing [11:09] them in. And that's that's where I'm [11:11] talking about in the same spot in your [11:13] dashboard where you say, "Hey, you know, [11:15] do X, Y, and Z or buy buy A, B, and C in [11:20] order to reach more customers." You [11:23] should also be saying, "Hey, these [11:26] things are things that have you at risk. [11:28] Hey, we checked, have I been pawned, and [11:31] your password is terrible, right? And uh [11:35] and it needs to be changed. These are [11:38] the risks." um we've we've seen these [11:42] kinds of of things trying to probe your [11:45] site. You should be updating some of [11:47] your plugins or whatever it is. Raising [11:50] that in a way that spins it as [11:54] we have these services that can take [11:56] these headaches off your plate and do [11:59] them for you to keep you secure or you [12:02] can do it yourself like like we've been [12:05] doing all along. Um, [12:08] and baking it in like that is going to [12:11] be the only way that I can see that [12:13] we're really going to raise the [12:15] awareness to the level that we need. I [12:16] mean, I can go around and talk on as [12:18] many stages as people will let me, but [12:20] I'm only reaching a tiny fraction of [12:22] what could be done if it was baked in in [12:24] this way. [12:26] >> Yeah. So when you say baked in, are you [12:27] saying that you think that that's at the [12:29] hosting level adding some kind of, you [12:32] know, mustuse plugin or or uh interface [12:35] or are you thinking that it should even [12:37] go into core that core should take on [12:39] some more of this? [12:42] I think it's at the hosting level. Um [12:44] core does a lot uh for for security, but [12:48] I think that what core is meant to give [12:50] you is a secure structure. Um, what [12:57] hosting is meant to give you is a secure [13:01] online presence and [13:05] the structure needs to stay secure. Core [13:07] needs to continue doing what it's doing. [13:09] Are there a few more things that could [13:10] maybe land there someday? Um, yeah, [13:14] maybe. But hosts [13:17] I think are the biggest place at the [13:19] moment um where they can go above and [13:23] beyond what they've been doing all along [13:26] and in the process [13:29] um bring awareness to their users of [13:32] what it is that they're addressing. Um [13:36] yeah and I think that's where the [13:37] biggest gap is at the moment. And I [13:40] think that's interesting because you [13:41] know there's multiple ways in which we [13:42] can talk about uh AI and the way in [13:45] which AI is being used in security. One [13:47] area though that I think is really [13:48] interesting is is the fact that [13:49] obviously it's an LLM, right? So it's a [13:52] it's a language model that allows for us [13:54] to talk to it in the way in which we [13:57] like to communicate which means it can [13:59] also talk back to us in the way in which [14:00] we communicate. And I think that's [14:02] something that has been missing from the [14:05] software space uh especially around [14:07] security for a very long time. When I [14:09] worked at brute protect you know one of [14:10] the things that uh you know we focused [14:12] on heavily was helping people to [14:14] understand [14:16] and man was it hard to find ourselves at [14:18] the intersection of you're vulnerable [14:20] and you can be attacked but also don't [14:23] be afraid to build a website and and be [14:26] scared. Uh you don't want to create fear [14:30] in folks. You don't want to use fear [14:32] tactics to get them to subscribe to [14:34] something or do something, but at the [14:37] same time, you want them to understand [14:38] that they're not just simply um, you [14:41] know, behind a giant uh wall and fully [14:45] protected because they're not. And so, [14:47] you know, one of the first things that [14:48] we needed to solve for was helping [14:49] people to understand why they were even [14:51] vulnerable because the, you know, in [14:53] talking to users and going out and [14:54] reaching out and actually talking to [14:56] users, what we found is that a lot of [14:58] folks just didn't even understand why [15:00] they would be attacked. I run a small [15:02] little mom and pop shop or I have a [15:04] brochure website or it's just my [15:06] personal portfolio. Like, why would [15:07] anyone want to attack that? And the [15:09] thing, you know, we had to help them [15:11] understand is that it's not it's not [15:13] necessarily um a targeted attack. It's [15:16] usually a blanket attack. It's it's a [15:18] flat out let me grab every single new [15:20] domain that gets registered out there [15:22] and see what I can do to penetrate that [15:24] and most of the time these botn nets are [15:26] looking to get to the resources behind [15:29] your ser you know your website not [15:31] necessarily into your actual website. [15:33] Um, and so, you know, I wonder if AI uh [15:37] could play a role in in education in [15:40] being a real time uh, you know, like [15:43] personal assistant inside of the WP [15:45] admin to assist you as you make [15:48] decisions throughout your website. So, [15:50] you know, the moment you install [15:51] WordPress as a core vanilla product, [15:54] it's highly secure, but then you start [15:57] adding extensions, you start changing [15:59] passwords, you start adding users, [16:01] right? And there's so many little things [16:03] that you don't necessarily think about. [16:04] Like for example, something we see so [16:06] commonly is like, "Hey, I would love [16:08] your help in fixing my website." This [16:11] happens at a word camp all the time. [16:12] Like I might sit down with someone and [16:14] try to help them and they're like, [16:15] "Okay, so I'll create a admin account [16:17] for you." And then they forget that [16:19] they've created an admin account for me. [16:21] Now, I I find myself to be a trustworthy [16:23] person, but uh that doesn't mean that, [16:25] you know, everyone is and it doesn't [16:26] mean that everyone is for all time. And [16:28] so, you know, that little action of [16:30] creating a new admin user is not [16:32] necessarily something that they think is [16:34] um scary or, you know, it creates a [16:37] vulnerability, but it does. So, maybe [16:39] having a little AI bot that's like, [16:41] "Hey, are you sure this person needs to [16:43] be an admin? Maybe they just need to be [16:45] an author." You know, something like [16:46] that might be uh a way to leverage AI to [16:49] help um secure a greater part of the [16:52] internet. [16:54] possibly something that um that even [16:58] helps convey what those risks are to [17:01] them in very normal words, right? Hey, [17:06] uh an admin can do absolutely anything [17:08] on your site. This this person will [17:11] continue to have access until you remove [17:12] this account. Um you know, m maybe um [17:17] maybe it says, "Would you like me to [17:20] remind you tomorrow to remove this [17:22] account?" or you know those kinds of [17:24] things that right [17:25] >> um could potentially be very helpful [17:29] because there's there is like general [17:32] good maintenance health that end users [17:34] should be doing and just it's not that [17:37] they won't they don't understand that [17:41] they need to or or why um and I do think [17:44] that there's a barrier I mean it's in [17:47] almost every company I've ever worked in [17:50] having been in tech for so [17:52] between sort of the the way that the [17:56] super technical people who build and [17:58] really understand all this stuff speak [18:00] and the way that sort of your your [18:02] average person that's using this at the [18:05] end of the day speaks. Um, and there can [18:08] be a translation error there. And to [18:10] your point, AI might be able to help [18:14] with that. We've certainly been playing [18:15] with that some here at at Monarchs [18:18] recently. And and uh good example of [18:21] that is in our our dark web um [18:24] monitoring product. We uh when we [18:28] surface uh a a breach um the jargon [18:33] around like what's included in it and [18:35] stuff tends to be very technical and we [18:37] use AI to really try to summarize that [18:41] in a way that an end user can understand [18:46] just a a normal person. what does this [18:48] mean to you and what was in this data? [18:51] Um, [18:53] and and I think that that's potentially [18:55] one of the more exciting ways that uh [18:58] that maybe people are kind of not super [19:00] excited about at the moment is [19:02] everybody's looking at AI for coding and [19:04] all these other big tasks. But I think [19:06] this translation could really be [19:09] massively useful going forward. [19:12] >> Yeah, I think so. I think something in [19:13] along the lines that like uh speaks at [19:16] your level, translates things not from [19:18] two different languages but from two [19:20] different uh levels of language. I think [19:23] uh might be actually really really [19:24] interesting. And it's funny because you [19:26] just talked about the dark web [19:27] monitoring. I would love to dive into [19:29] that because when I sit down with folks [19:31] who um get uh I I'll give you an example [19:34] like uh my father-in-law. He's um you [19:36] know he's in his 70s. He's uh um [19:40] you know he's a smart guy. He used to [19:42] work at a a major publishing company. Uh [19:45] but you know, this technological stuff [19:47] is a little bit um it's a little bit [19:49] hard to digest, a little bit hard to [19:50] understand. And when he gets a notice, [19:52] it's like, hey, you've been pawned. Uh [19:54] first of all, that's language that not [19:56] everyone immediately understands. And [19:58] second, you can feel the tension, right? [20:01] Immediately there's a little bit of [20:02] adrenaline. There's a little bit of [20:04] nervousness. Um, and uh, I think when [20:07] that happens, your brain starts to like [20:08] immediately constrict and the scope of [20:10] what you understand gets narrower and [20:12] then you have a harder time really [20:14] digesting what it is that's happening. [20:17] Um, and so, you know, it's really [20:18] interesting when you start to help [20:20] people understand that, hey, your your [20:22] website or your your username and [20:24] password that you use to here is now [20:26] public, so you should go change that [20:28] obviously. But it's not always like, [20:30] "Hey, wait a minute. Did I use that same [20:32] username and password in six other [20:34] places?" And how would they even know to [20:36] start doing that? Like they I think one [20:38] thing that they don't understand is the [20:39] the broad sweeping ability of like these [20:42] hackers to to test things 10 trillion [20:45] times, you know, like to to attack a [20:47] 100red million times until they get in [20:49] and like to just continually using [20:51] usernames and passwords over and over [20:53] and over again. or if there is a [20:55] targeted attack, right, to like be able [20:56] to go and search for your username [20:58] somewhere else. Um, and so, you know, I [21:01] think in that moment like being able to [21:03] help them understand how this actually [21:06] relates to your website is interesting. [21:09] Um, and it's tough too because the [21:11] language has to be designed in a way to [21:14] help them understand it. Like it also [21:16] doesn't have full access to everything. [21:17] like it wouldn't necessarily know that [21:20] your password [21:22] in that moment, the one that's [21:24] currently, you know, hashed and and [21:26] stored is vulnerable or not. So, it's [21:28] kind of a guessing game. And so, you [21:30] don't always give them the exact details [21:31] like you have to change your username [21:33] and password. It's more like you may [21:35] need to change your username and [21:36] password. So, how do you balance that uh [21:39] level of um urgency with uh sometimes [21:43] the vagger vagger comments and the [21:45] vagger statements? [21:48] But first you dig in as deep as you can [21:50] to get uh to to to clarify as much as [21:54] that of that vagueness as possible. [21:56] Right? So um the may need to change your [21:59] password. Maybe instead that alert comes [22:02] up on login where you have actually [22:06] checked the password and said this is in [22:09] fact one of those vulnerable passwords [22:11] because we checked it in flight not just [22:14] against our our database hash or [22:16] whatever it is. And um and you do need [22:20] to change your password because of XYZ. [22:24] Um maybe maybe that's not possible and [22:27] the may is all you can do. Um, maybe you [22:30] do know what breach that was tied to and [22:33] you can say, "Hey, um, your password [22:36] from your Nike account was compromised. [22:39] If you use the same password here, you [22:41] should change it." Um, the way that [22:43] we're doing it in um, in our dark web [22:47] monitoring is really giving um, kind of [22:50] like retodos for every breach that that [22:55] someone's seeing. So, so trying to give [22:57] them actionable things that they can do [23:02] um that help them think through [23:05] what's next. And so sometimes the data [23:08] isn't even a password, right? Maybe it [23:10] was my address and phone number and what [23:13] I need to do is, you know, um set up [23:17] some credit monitoring because that's [23:19] the, you know, someone's probably trying [23:21] to to take my identity, those kinds of [23:23] things. Um, but maybe it's, you know, go [23:26] everywhere that you use this password [23:28] and change it. Um, you know, maybe it's, [23:31] you know, make sure to cycle the [23:32] password on your email account because [23:35] that's, um, you know, that that's a [23:38] place that this is at risk. Whatever it [23:40] is, um, give them concrete steps. The [23:43] biggest thing, if if you have to be [23:45] vague with the message, make sure that [23:48] at least the steps that they can do are [23:52] concrete. So maybe you need, you know, [23:55] maybe your password was um uh [23:59] compromised, but to make sure you're [24:02] safe, click here to change your [24:05] password. Once that's done, uh you [24:08] you're good to go. Uh you know, don't [24:10] use a password you've used somewhere [24:12] else, right? Those um simple, solid, [24:17] exact steps can help to your point. Uh, [24:22] I don't know if it's is it is it calm a [24:23] person down, focus them back in, [24:27] whatever it is, uh, it can help reduce [24:29] that sort of stress that you were [24:31] talking about cuz they can just say, [24:33] "Oh, okay. There's a little bit of a [24:35] scary thing, but if I do this and that, [24:38] um, they say the scary things taken care [24:41] of. Done." [24:41] >> I think it goes back to empowerment, [24:43] right? you want to leverage that urgency [24:45] that they're feeling into something that [24:47] they can take action on so that they [24:49] feel empowered that they can actually [24:51] fix the problem um and and actually [24:53] address it. So, how does someone um [24:56] actually interact with Monarchs? Is it [24:57] something um I mean I'm familiar with [25:00] Monarchs, but for the folks at home who [25:01] may not necessarily be, is it uh an [25:04] interface that end users are interacting [25:06] with directly? Is it passing through the [25:09] hosting company? Do customers have a [25:11] direct relationship with Monarchs or is [25:12] it all through their hosts? How does [25:14] that work? [25:16] >> We we power the the security solutions [25:18] at hosts. So at many of the big hosts, [25:22] uh you are using monarchs whether you [25:26] realize it or not to help you know keep [25:29] your site clear of malware etc. [25:31] um at some of the registars you might be [25:35] using us for dark web monitoring um if [25:38] you've opted into that kind of thing. Um [25:41] we do have some direct interaction with [25:43] the the end users in that we supply [25:45] those hosts um with kind of a customer [25:50] portal that lets a customer see [25:54] the malware that was found and cleaned [25:56] and remediated on their site. than you [26:00] know attacks that were blocked, the um [26:04] monitorings that are in place, those [26:06] kinds of things. Um and in some cases, [26:12] you know, gives them the ability to um [26:16] find more details, take action on some [26:18] of those kinds of things, etc. Um we [26:22] also can like everything that we do is [26:25] fully API first. So, some hosts have [26:28] chosen to essentially build that [26:30] dashboard themselves into their [26:32] dashboard. Um, which is great as well as [26:37] long as the end user is able to uh to [26:40] see and know and understand. Um, [26:43] that's great. [26:45] >> Yeah. So, you know, it's funny because [26:47] with WP Cloud, we operate the same way. [26:49] It's 100% API based. the hosting [26:52] companies outsourcing their [26:53] infrastructure to us and fully managed [26:55] WordPress and we handle performance and [26:58] security for them as well. uh but that [27:00] puts the host brand up front uh which is [27:04] great I think uh for most part but there [27:06] is this added complexity which is that [27:09] especially around security I think the [27:12] security company's brand is important in [27:16] developing trust with the end user [27:18] because they don't only host with one [27:21] company right it's ignorant I think for [27:23] us to think that you know an agency or [27:25] someone else is is using one hosting [27:27] company and so if these messages me ages [27:29] are coming through multiple brands. Um [27:33] or some hosting companies are not [27:35] necessarily, you know, taking advantage [27:36] of the full security solutions that are [27:39] out there and some are. Um you know, I [27:42] wonder if that diffuses the message at [27:44] all and and whether or not it would [27:45] actually be better for the ecosystem if [27:48] there was um you know, a larger trusted [27:51] voice across the entire industry that [27:53] was was educating. Maybe there's an [27:55] opportunity for monarchs to live kind of [27:57] behind the scenes, but also maybe take a [27:59] a larger part in um like the WordPress [28:02] ecosystem education and and and [28:04] community and maybe other security [28:06] companies should be doing that as well. [28:09] >> Think we're trying to move that way. It [28:11] is an interesting balance. Um I I think [28:13] that for to your point of of like [28:16] agencies, I think you're 100% right. Um [28:19] an agency probably hosts at a number of [28:22] different hosts. Um, and being able to [28:25] know that, uh, this host or that host is [28:30] using um, uh, Monarchs and we trust [28:34] Monarchs, that's great. And so building [28:37] our Monarchs brand to those people as a [28:41] trusted security expert that um, when [28:46] they know that the host is using us, [28:47] they know that that that they're good to [28:49] go. I think that's important. But also [28:52] when you look at the huge number of just [28:56] end users that are hosting directly with [28:59] a host that just go to Bluehost and buy [29:02] hosting um [29:06] they only know the Blue Host name. [29:10] That's the only thing they've interacted [29:12] with. That's the only thing that they've [29:14] really built trust with. and they're not [29:17] aware of any kind of security companies [29:20] in the space and probably don't want to [29:23] be, you know, that they're a they're a [29:25] leather worker selling their leather [29:27] goods online that they make. You know, [29:29] they they've just decided they want to [29:30] own their own space instead of sit on [29:32] Etsy, right? Or whatever it is. And [29:34] since they trust Blue Host with that, [29:38] they should be able to buy, you know, [29:40] Blue Host complete security and that can [29:43] come with Monarchs and they never have [29:45] to know. Um, but they can still be safe [29:48] with the brand that they do trust. So, I [29:50] do think there's uh a balance there. [29:53] There's a number of customers that are [29:54] only ever going to know the host as the [29:56] brand they trust. Um, and for those that [29:59] make sense, I think it's important for [30:00] us to get out there and be talking to [30:04] agencies, hosts, etc. [30:06] um putting out a lot of of of [30:09] information, white papers and such, [30:10] which we've been doing recently to help [30:13] um [30:15] build that trust in in our brand. Yeah, [30:19] I think that's really interesting [30:20] because I think it kind of leans on the [30:21] fact that part of the responsibility of [30:23] a security company like Monarchs or WP [30:26] Cloud even or others is that maybe part [30:28] of our responsibility is around building [30:30] the narrative around security so that we [30:32] can help shape the way in which we're [30:34] educating folks and helping them to [30:35] understand things. We're almost at time [30:38] uh and I want to continue this [30:39] conversation and we have barely [30:40] scratched the surface of AI. But before [30:43] we uh before we part on this episode and [30:45] and start another one uh or come back [30:47] for another one. Um quick question. Are [30:50] you going to Word Camp US? And if so, [30:52] what are you excited about [30:55] going to Word Camp US? And I'm excited [30:57] about the same thing I'm always excited [31:00] about at Word Campus US, which is [31:02] getting together with all the people and [31:06] getting the chance to I don't know um [31:10] talk about all the things happening in [31:13] our industry at the moment. um [31:16] everything from what's affecting [31:19] hosting, what people are building with [31:21] the the product, what new things are are [31:23] out there, what um what exciting new [31:26] projects people have going on. Um that's [31:29] that's always been my favorite part. [31:32] It's what I'm looking forward to again. [31:34] >> Yeah. Very cool. [31:35] >> What about you? Are you going to be [31:36] there? [31:37] >> I'm going to be there. Very excited to [31:39] go. Um and I think uh I think the energy [31:43] is going to be great. I think we're [31:45] going to see a lot of people hanging out [31:47] inside the expo because it's going to be [31:49] sweltering outside, but I think inside [31:51] they know they know how to keep the the [31:53] ring cool. I think we're even going to [31:55] see people with sweatshirts. Uh but I [31:57] think that's great because what it means [31:58] is that there's going to be less um of a [32:01] typical venturing out and taking a break [32:02] and more of like, hey, I'm going to hang [32:04] out in the booths. I'm going to hang out [32:05] in the expo area. I'm going to hang out [32:07] with others. And um I think it's going [32:09] to make for a really great intimate but [32:12] large word camp. Um, on that note, we're [32:15] going to take a break and we'll come [32:16] back with Aaron for another episode uh [32:18] in the future. Thanks, Aaron. [music] [32:21] Thanks for having me. [32:23] Thanks for joining us on another episode [32:24] of Impressive Hosting, where we uncover [32:26] the core tenants of great WordPress [32:28] hosting. Do you have a follow-up [32:30] question for today's guest? Thought or [32:32] comment on anything we talked about, a [32:33] future guest suggestion, a hosting [32:35] horror story? What do you think makes [32:38] great WordPress [music] hosting? All [32:40] your comments shape this show. drop them [32:42] on impressive.host. [32:44] We also appreciate you following us on [32:46] social media and subscribing to the [32:48] podcast on your favorite platform. [32:50] Finally, do check out our list of open [32:52] source projects that need support at [32:54] impressive.host. Whether it's code, [32:56] community, or cash, you can make a [32:58] difference. See you next time.  📄 **Full text:** [[Full Document Contents/Articles/How Can Hosts Communicate Security Risks Without Creating Fear.md|How Can Hosts Communicate Security Risks Without Creating Fear? by YouTube]] ## Highlights - Um, but it's still a thing that hosts struggle with lots. Now to be clear um I do think that hosts have a responsibility to some extent to help their users who are by nature less security aware than the hosts themselves um be able to stay secure online. However, not all users at any given host need the same ([View Highlight](https://read.readwise.io/read/01kzrhp9j57vytqcpx5a6vrcv8)) - Note: Hosts have a responsibility to help less security-aware customers stay safe while securing shared infrastructure. - Tags: atom/literature/h1, wordpress-hosting-security - in folks. You don't want to use fear tactics to get them to subscribe to something or do something, but at the same time, you want them to understand that they're not just simply um, you know, behind a giant uh wall and fully protected because they're not. And so, you know, one of the first things that we needed to solve for was helping people to understand why they were even vulnerable because the, you know, in talking to users and going out and reaching out and actually talking to users, what we found is that a lot of folks just didn't even understand why ([View Highlight](https://read.readwise.io/read/01kzrhpag9b1744vm255djcet0)) - Note: Security communication should explain real risk without using fear as the conversion mechanism. - Tags: atom/literature/h2, user-security-education - around like what's included in it and stuff tends to be very technical and we use AI to really try to summarize that in a way that an end user can understand just a a normal person. what does this mean to you and what was in this data? Um, and and I think that that's potentially one of the more exciting ways that uh that maybe people are kind of not super ([View Highlight](https://read.readwise.io/read/01kzrhpctedep21b22q02exvbp)) - Note: AI can translate technical threat data into language ordinary site owners can act on. - Tags: ai-powered-communication, atom/literature/h2 - you know, make sure to cycle the password on your email account because that's, um, you know, that that's a place that this is at risk. Whatever it is, um, give them concrete steps. The biggest thing, if if you have to be vague with the message, make sure that at least the steps that they can do are concrete. So maybe you need, you know, maybe your password was um uh compromised, but to make sure you're ([View Highlight](https://read.readwise.io/read/01kzrhpbknjxs02ryb4x3z6w1s)) - Note: Security alerts become useful when they include concrete next steps tied to the exposed data. - Tags: atom/literature/h2, dark-web-monitoring