/* ==========================================================================
   Shield — article content
   Loads article body from a small in-file registry by ?id=...
   Keeping the data in JS so the template stays a single, reusable file.
   ========================================================================== */

(function () {
  'use strict';

  const ARTICLES = {
    'what-to-do': {
      meta: 'Guide · For individuals · 6 min read',
      title: 'What to do if intimate images are shared without consent',
      lede: 'A calm, step-by-step guide for the first 24 hours — what to document, what to avoid, who to contact, and what to do next.',
      body: `
        <p>The first 24 hours after you discover non-consensual intimate imagery (NCII) of yourself online are overwhelming. The order below isn't a rule — it's a way to keep yourself oriented when the to-do list feels endless. Take it at your own pace.</p>

        <h2>1. Take a breath. Then take a screenshot.</h2>
        <p>You don't need to do everything at once. But before a post is deleted or a profile changes, capture exactly what's online right now: the URL, the platform, the date, and the full post. <strong>Don't crop or edit</strong> — you want the timestamp, the context, the surrounding thread. Use a tool that creates a timestamped archive (MHTML or PDF) so the evidence has integrity later.</p>
        <ul>
          <li>Save the original URL — short links are easy to mis-attribute.</li>
          <li>Capture the uploader's profile name and ID if visible.</li>
          <li>Save a copy to a private, encrypted folder you control.</li>
        </ul>

        <h2>2. Decide who to tell first.</h2>
        <p>This is your call. Common first contacts:</p>
        <ul>
          <li><strong>A trusted person</strong> — not to "fix" it, just to be there.</li>
          <li><strong>A support organization</strong> — confidential, often 24/7. They will not pressure you into any particular path.</li>
          <li><strong>A legal professional</strong> — if you think you may want to take legal action or want advice on local laws.</li>
        </ul>

        <h2>3. Start the takedown process — but don't trust the first "no".</h2>
        <p>Most major platforms have a non-consensual intimate imagery reporting flow. Some are excellent; some are slow. Submit the report, keep the reference number, and follow up. If the platform removes the content, the next step is monitoring for re-uploads — that's where Shield is built to help.</p>

        <h2>4. Document everything in one place.</h2>
        <p>A spreadsheet is fine. A case in Shield is better — every screenshot, every report, every response goes into a single, auditable record. The point is: if you ever need to escalate, you shouldn't have to dig through your email to find what happened.</p>

        <h2>5. Be careful with what you share and with whom.</h2>
        <p>This is a sensitive situation. Services that promise "guaranteed removal in 24 hours" rarely deliver and sometimes re-victimize. Stick with organizations and tools that explain exactly what they do, what they don't, and how your data is handled. Read the privacy policy. Ask questions. There is no rush that justifies giving up control of your information.</p>

        <h2>What Shield is, and isn't, for</h2>
        <p>Shield doesn't remove anything for you. It gives you a workspace to document, request, and track removals across many cases and platforms — and to keep doing that work over time, since re-uploads are common. Use it as a tool, not a promise.</p>
      `,
    },
    'takedown-notices': {
      meta: 'Explainer · Platform &amp; policy · 5 min read',
      title: 'How takedown notices work',
      lede: 'What a takedown notice actually is, who responds to them, how long platforms typically take, and why follow-up matters.',
      body: `
        <p>A takedown notice is a formal request to a host, platform, or registry to remove specific content. It's a request, not an order — the final decision rests with whoever controls the system. Knowing how the process actually works helps you write notices that are harder to dismiss.</p>

        <h2>Anatomy of a takedown notice</h2>
        <p>Most well-formed notices include:</p>
        <ul>
          <li>The exact URL(s) of the content to be reviewed.</li>
          <li>A clear, factual description of why the content is non-consensual.</li>
          <li>Identification of the affected person and a way to verify the claim.</li>
          <li>A statement of good-faith belief that the claim is accurate.</li>
          <li>Your contact details and a signature (physical or electronic).</li>
        </ul>
        <p>The strongest notices are short, specific, and factual. They don't editorialize, and they don't threaten. Threats of legal action belong in a separate, more formal communication.</p>

        <h2>Who responds, and how long it takes</h2>
        <p>Most major platforms have a dedicated trust &amp; safety intake for NCII. Response times vary from hours to weeks, and re-uploads to the same platform are common. A first removal is rarely the last word — ongoing monitoring is part of doing this work properly.</p>

        <h2>Why follow-up matters</h2>
        <p>Notices get lost. Notices get filtered as spam. Notices get reviewed by people who are overloaded. A second, well-written follow-up — referencing the original ticket number and any new information — is often what actually moves things. Shield's link health checks and auto-escalation exist because of this reality.</p>

        <h2>Limits of takedown</h2>
        <p>Even a perfect notice doesn't guarantee removal. A platform can have policies that don't apply, can require additional evidence, or can be jurisdictional grey area. Honest tools don't promise what the system can't deliver. The work is: better notices, better follow-up, and better records.</p>
      `,
    },
    'preserving-evidence': {
      meta: 'Guide · Evidence · 7 min read',
      title: 'Preserving evidence safely',
      lede: 'What to save, how to save it, and what to avoid. MHTML snapshots, hash integrity, and why chain-of-custody matters.',
      body: `
        <p>Evidence is only useful if it's intact and attributable. A screenshot on someone's phone is better than nothing — but a timestamped, hash-verified archive is much stronger. This is true whether the evidence is for your own records, for a support organization, or for legal use.</p>

        <h2>What "good evidence" looks like</h2>
        <ul>
          <li><strong>Timestamped.</strong> The exact moment of capture, in a verifiable format.</li>
          <li><strong>Untouched.</strong> No cropping, no editing, no redaction — the original artifact is preserved as-is.</li>
          <li><strong>Identifiable.</strong> The URL, the platform, the uploader handle, the surrounding context.</li>
          <li><strong>Verifiable.</strong> A hash (SHA-256) lets you prove the file hasn't been modified later.</li>
        </ul>

        <h2>MHTML is your friend</h2>
        <p>MHTML archives the entire page — text, images, layout, timestamps — in a single file. It's a much better preservation format than screenshots, which lose context. Shield captures MHTML automatically for every archived finding.</p>

        <h2>What to avoid</h2>
        <ul>
          <li><strong>Don't crop</strong> the original — keep the full page even if parts are sensitive.</li>
          <li><strong>Don't upload evidence to random "removal services" you found via search ads.</strong></li>
          <li><strong>Don't share evidence by unsecured channels</strong> (regular email, public cloud folders).</li>
          <li><strong>Don't delete the originals</strong> even after removal. You may need them later.</li>
        </ul>

        <h2>Chain of custody</h2>
        <p>Chain of custody is the record of who had access to the evidence, when, and what they did with it. A clean chain of custody means the evidence is harder to challenge later. Shield's audit log captures this automatically — every view, every export, every modification is timestamped and tied to a user.</p>
      `,
    },
    'platform-responses': {
      meta: 'Explainer · Platform &amp; policy · 6 min read',
      title: 'How platforms respond to NCII reports',
      lede: 'A look at the policies, the timelines, and the variation across major platforms — and how to make your report harder to dismiss.',
      body: `
        <p>Most major platforms have written policies against non-consensual intimate imagery. The variation is in execution: how easy the report flow is to find, what evidence they require, how fast they respond, and how well they prevent re-uploads.</p>

        <h2>What good policies look like</h2>
        <p>Strong NCII policies share a few features:</p>
        <ul>
          <li>A clearly marked reporting flow — not buried in a generic "report abuse" form.</li>
          <li>No requirement that the affected person have an account on the platform.</li>
          <li>Hash-matching to prevent known re-uploads.</li>
          <li>A real human reviewer for ambiguous cases.</li>
          <li>Public reporting on response times and outcomes.</li>
        </ul>

        <h2>What to put in your report</h2>
        <p>Help the reviewer help you. Be specific, factual, and short:</p>
        <ul>
          <li>The exact URLs and a short description of each piece of content.</li>
          <li>A clear statement that the imagery was shared without consent.</li>
          <li>Any context that distinguishes this from consensual adult content.</li>
          <li>Whether you're the affected person, a representative, or a support organization.</li>
        </ul>

        <h2>If the first response is "no"</h2>
        <p>Read the rejection reason. It's often a missing piece of information. Re-submit with the missing detail, not with a longer complaint. If the second attempt also fails, escalate — many platforms have a trust &amp; safety appeals path or a dedicated abuse escalation channel for repeat issues.</p>
      `,
    },
    'support-orgs': {
      meta: 'Guide · For organizations · 8 min read',
      title: 'A guide for support organizations',
      lede: 'Setting up intake, training reviewers, choosing tools, and protecting both the people you serve and the people doing the work.',
      body: `
        <p>Support organizations carry a particular kind of load: high stakes, sensitive material, and finite capacity. The technology choices you make should reduce that load, not add to it. Here's a practical framework for setting up a sustainable NCII response operation.</p>

        <h2>Intake: keep it simple, keep it private</h2>
        <p>The first conversation is the one that sets the tone. Whatever tool you use for intake should be:</p>
        <ul>
          <li><strong>Confidential</strong> — not shared with other clients, not used for marketing, not retained longer than needed.</li>
          <li><strong>Specific</strong> — ask for what you actually need: the affected person's contact, the URLs, the date they became aware, any prior reports.</li>
          <li><strong>Trauma-informed</strong> — no requirement to re-tell the story, no judgment language, no false promises.</li>
        </ul>

        <h2>Reviewers: protect the people doing the work</h2>
        <p>Reviewing NCII material takes a toll. Plan for it: rotation, supervision, time off, and a clear path for escalating ambiguous or distressing cases. The platform should support role separation so reviewers see only what they need.</p>

        <h2>Tools: integrate, don't multiply</h2>
        <p>Every additional tool is a context switch and a privacy boundary. Choose a primary workspace — Shield is built for this — and use it consistently. Export to other systems only when the workflow requires it, and only with structured exports that preserve the audit trail.</p>

        <h2>Outcomes: track them honestly</h2>
        <p>Don't measure success by removal alone. Measure: time to first response, time to removal, re-upload rate, and the affected person's reported wellbeing at follow-up. Honest metrics make your service better — and protect your team from the trap of measuring the wrong thing.</p>
      `,
    },
    're-uploads': {
      meta: 'Explainer · Reality check · 5 min read',
      title: 'The reality of re-uploads',
      lede: 'Why content comes back, why it\'s not your fault, and how ongoing monitoring — not single-shot removal — is the realistic answer.',
      body: `
        <p>If you've experienced non-consensual intimate imagery, you may have had the disorienting experience of finding content you thought was removed, re-uploaded somewhere else. This is common. It's not a sign that the system failed, and it is absolutely not your fault.</p>

        <h2>Why re-uploads happen</h2>
        <ul>
          <li>Once content is downloaded by a third party, you can't un-download it.</li>
          <li>Mirrored copies persist on archive, cache, and forum sites.</li>
          <li>The same source can post to many platforms quickly.</li>
          <li>Detection and takedown is always behind upload.</li>
        </ul>

        <h2>What actually helps</h2>
        <p>The honest answer is ongoing monitoring, not a one-time fix. A workflow that:</p>
        <ul>
          <li>Watches for the same content across the open web.</li>
          <li>Generates platform-appropriate takedown notices quickly.</li>
          <li>Tracks response and re-probes links on a schedule.</li>
          <li>Escalates quickly when something old resurfaces.</li>
        </ul>
        <p>That's what Shield is for. It won't make the problem go away, but it makes the work of responding to it sustainable — and it gives you a documented record of every action, which matters more than people often realize.</p>

        <h2>What does not help</h2>
        <p>Services that promise "permanent removal" and charge high fees upfront, "reputation management" SEO services that target the wrong problem, or advice to ignore it. None of these match the reality of the situation, and some of them make it worse.</p>
      `,
    },
  };

  function getId() {
    const p = new URLSearchParams(location.search);
    if (p.get('id')) return p.get('id');
    // Optional: support /blog/article/<slug> form
    const m = location.pathname.match(/\/blog\/article\/?([^\/?#]+)/);
    if (m && m[1]) return decodeURIComponent(m[1]);
    return 'what-to-do';
  }

  function render() {
    const id = getId();
    const a = ARTICLES[id] || ARTICLES['what-to-do'];
    document.title = `${a.title} — Shield Resources`;
    const meta = document.getElementById('article-meta');
    const title = document.getElementById('article-title');
    const lede = document.getElementById('article-lede');
    const body = document.getElementById('article-body');
    if (meta) meta.innerHTML = a.meta;
    if (title) title.textContent = a.title;
    if (lede) lede.textContent = a.lede;
    if (body) body.innerHTML = a.body;
  }

  document.addEventListener('DOMContentLoaded', render);
})();
