T

Text Machine

เครื่องมือข้อความทรงพลัง ในเบราว์เซอร์ของคุณ

ลบข้อมูลส่วนบุคคล

วางอะไรก็ได้ ไม่ว่าจะเป็นตั๋วซัพพอร์ต ล็อกไฟล์ หรือบทสนทนา แล้วลบข้อมูลส่วนบุคคลและคีย์ลับที่ซ่อนอยู่ข้างในออกก่อนแชร์ ทุกอย่างทำงานในเบราว์เซอร์ ข้อความจึงไม่เคยออกจากเครื่องของคุณ

ข้อความของคุณ

ตรวจจับ:

เครื่องมือนี้เป็นเพียงสคริปต์ที่ทำงานฝั่งผู้ใช้ ข้อความของคุณถูกประมวลผลในแท็บนี้เท่านั้น ไม่เคยถูกส่งไปยังเซิร์ฟเวอร์ และไม่ถูกเก็บหรือบันทึกไว้ที่ใด ปิดแท็บแล้วก็หายไป

วิธีใช้ ลบข้อมูลส่วนบุคคล

  1. 1

    วางข้อความของคุณ

    วางตั๋วซัพพอร์ต ล็อกการสนทนา ข้อความแสดงข้อผิดพลาด แถวในสเปรดชีต หรือเอกสารที่คุณกำลังจะแชร์ ไม่มีข้อจำกัดความยาวและไม่มีการอัปโหลด

  2. 2

    เลือกวิธีแทนที่

    แถบดำคงรูปทรงของต้นฉบับไว้ เหมาะกับภาพหน้าจอ [REDACTED] คือรูปแบบเอกสารที่คุ้นตาที่สุด ป้ายบอกประเภทอย่าง [EMAIL] บอกผู้อ่านว่าอะไรถูกลบไป ส่วนตัวแทนแบบมีหมายเลขอย่าง [EMAIL_1] ทำให้ค่าเดิมที่ปรากฏซ้ำยังเชื่อมโยงกันอยู่

  3. 3

    เปิดหรือปิดตัวตรวจจับ

    ตัวตรวจจับทั้งเก้าชนิดเปิดไว้เป็นค่าเริ่มต้น ปิดชนิดที่เก็บไว้ได้อย่างปลอดภัย เช่น คง URL ไว้ในรายงานบั๊กแต่ยังลบคีย์ API ที่อยู่ข้าง ๆ ออก

  4. 4

    ตรวจจำนวนแล้วคัดลอก

    แผงตัวเลขแสดงว่าแต่ละประเภทถูกลบไปกี่รายการ ตรวจว่าตรงกับที่คาดไว้แล้วจึงคัดลอกข้อความที่สะอาดแล้ว

ว่าด้วยการลบข้อมูลส่วนบุคคลและคีย์ลับออกจากข้อความ

ทำไมข้อความถึงถูกแชร์ก่อนที่ใครจะได้ตรวจ

การรั่วไหลของข้อมูลส่วนบุคคลโดยไม่ตั้งใจแทบทุกครั้งเริ่มจากการวางข้อความธรรมดาที่ไม่ได้มีเจตนาร้าย เจ้าหน้าที่ซัพพอร์ตคัดลอกข้อความของลูกค้าไปถามเพื่อนร่วมงานในแชทกลุ่ม นักพัฒนาโยน stack trace ลงในระบบติดตามปัญหา บางคนวางแถวจากสเปรดชีตลงหน้าต่างแชท หรือวางบางส่วนของล็อกให้ผู้ช่วย AI ดูแล้วถามว่าข้อผิดพลาดนี้แปลว่าอะไร ทุกกรณี ส่วนที่อ่อนไหว ไม่ว่าจะเป็นที่อยู่ เลขบัตร หรือคีย์เข้าถึง ไม่เคยเป็นประเด็นของข้อความนั้นเลย มันแค่ติดมาด้วย

ทางแก้ไม่ใช่การระวังให้มากขึ้น แต่คือขั้นตอนเดียวที่ใช้เวลาสองวินาที เครื่องมือนี้มีอยู่เพื่อเป็นขั้นตอนนั้น วางข้อความ มองจำนวนที่พบสักครู่ แล้วคัดลอกฉบับที่สะอาดแล้ว มันถูกทำให้เร็วพอโดยตั้งใจ เพื่อให้การใช้งานไม่รู้สึกเหมือนกฎที่ต้องคอยจำ

เครื่องมือมองหาอะไร

มีเก้าประเภทที่ถูกตรวจจับ ที่อยู่อีเมลและ URL ถูกจับจากโครงสร้าง ที่อยู่ IPv4 ถูกตรวจช่วงตัวเลขด้วย ดังนั้น 999.1.1.1 และสตริงเวอร์ชันที่มีห้าส่วนจึงไม่ถูกนับเป็นที่อยู่ เลขประกันสังคมสหรัฐถูกจับเฉพาะรูปแบบที่มีขีดคั่น เบอร์โทรต้องมีรหัสประเทศหรือตัวคั่นจริง บัตรและ IBAN ถูกตรวจด้วยเช็กซัม คีย์ API ถูกจับจากคำนำหน้าของผู้ให้บริการ ส่วน JWT ถูกจับจากโครงสร้าง base64 สามส่วน

รายการนี้เลือกมาจากสิ่งที่โผล่ในข้อความที่คนวางกันจริง ๆ ประเภทข้อมูลส่วนบุคคลแบบคลาสสิกดูแลฝั่งมนุษย์ ส่วนประเภทข้อมูลรับรองดูแลฝั่งเครื่อง ซึ่งในทางปฏิบัติคือจุดที่อุบัติเหตุแพงที่สุดเกิดขึ้น คีย์คลาวด์ที่รั่วออกไปหนึ่งอันมีราคาสูงกว่าเบอร์โทรที่รั่วออกไปหนึ่งเบอร์มาก

ความแม่นยำสำคัญกว่าความครอบคลุม

วิธีที่ชวนให้ทำที่สุดในการสร้างเครื่องมือแบบนี้คือจับให้กว้างไว้ก่อน ถือว่าตัวเลขยาว ๆ ทุกชุดคือบัตร และตัวเลขที่มีขีดทุกตัวคือเบอร์โทร ผลลัพธ์ดูน่าประทับใจตอนสาธิตแต่ทำลายเอกสารจริงอย่างเงียบ ๆ เลขคำสั่งซื้อกลายเป็นแถบดำ จำนวนแถวหายไป เลขเวอร์ชันกลายเป็น [PHONE] ที่แย่กว่านั้นคือความเสียหายมองไม่เห็น คุณคัดลอกผลลัพธ์ไปวาง แล้วมารู้ทีหลังว่าส่วนที่อีกฝ่ายต้องการจริง ๆ หายไปแล้ว

ตัวตรวจจับทุกตัวที่นี่จึงต้องชัดเจนเชิงโครงสร้างหรือไม่ก็ต้องผ่านเช็กซัม บัตรเครดิตต้องผ่านการตรวจ Luhn mod-10 ที่ทุกเครือข่ายบัตรใช้ นั่นหมายความว่าเลข 16 หลักที่สุ่มขึ้นมามีโอกาสผ่านราวหนึ่งในสิบ ไม่ใช่ผ่านแน่นอน IBAN ต้องผ่านการตรวจ mod-97 ตาม ISO 13616 ตัวเลขที่เรียงกันเฉย ๆ ไม่มีวันเป็นเบอร์โทร ผลคือจับได้น้อยลงเล็กน้อยแลกกับการแทบไม่เคยทำลายข้อความที่คุณตั้งใจเก็บไว้ ซึ่งเป็นการแลกที่ถูกต้องสำหรับเครื่องมือที่ผลลัพธ์ของมันกำลังจะถูกส่งต่อทันที

การเลือกรูปแบบการแทนที่

แถบดำคงน้ำหนักทางสายตาของต้นฉบับไว้ ซึ่งเป็นสิ่งที่คุณต้องการสำหรับภาพหน้าจอหรือเอกสารที่ยังต้องดูเหมือนเอกสาร [REDACTED] คือธรรมเนียมที่คุ้นเคยในวงการกฎหมายและการขอเปิดเผยข้อมูลราชการ และอ่านเข้าใจง่ายในข้อความล้วน ป้ายบอกประเภทอย่าง [EMAIL] และ [CREDIT_CARD] บอกว่าอะไรถูกลบไป ซึ่งสำคัญเมื่อชนิดของข้อมูลเป็นส่วนหนึ่งของคำอธิบาย รายงานบั๊กที่เขียนว่า [API_KEY] เล่าเรื่องต่างจากแถบดำไร้ชื่ออย่างสิ้นเชิง

ตัวแทนแบบมีหมายเลขมีประโยชน์ที่สุดและสังเกตได้ยากที่สุด ค่าเดิมที่ปรากฏซ้ำจะได้หมายเลขเดียวกัน กระทู้ที่พูดถึงลูกค้าคนหนึ่งสี่ครั้งจึงกลายเป็น [EMAIL_1] สี่ครั้ง แทนที่จะเป็นช่องว่างสี่ช่องที่แยกจากกันไม่ออก เอกสารจึงยังต่อเนื่องเป็นเรื่องเดียวกัน ทั้งคนอ่านและโมเดลภาษายังเห็นว่าเป็นคนเดิมที่ปรากฏตลอดทั้งฉบับ และคุณยังย้อนกลับไปหาค่าจริงได้ภายหลังหากเก็บต้นฉบับไว้

ทำความสะอาดข้อความก่อนส่งให้ AI

การวางล็อก ตั๋วซัพพอร์ต และเอกสารภายในลงในผู้ช่วยแชทกลายเป็นเรื่องปกติไปแล้ว และตอนนี้มันคือหนึ่งในเส้นทางที่พบบ่อยที่สุดที่ข้อมูลอ่อนไหวออกจากองค์กร ข้อความที่ส่งไปนั้นไปถึงบุคคลที่สาม อาจถูกเก็บไว้ และในบางการตั้งค่าอาจถูกมนุษย์ตรวจทานหรือถูกใช้ฝึกโมเดล ส่วนใหญ่แล้วไม่จำเป็นต้องเป็นแบบนั้นเลย เพราะสิ่งที่โมเดลต้องการคือรูปร่างของปัญหา ไม่ใช่ที่อยู่อีเมลจริงของลูกค้า

การให้ข้อความผ่านเครื่องมือลบข้อมูลก่อนช่วยเก็บส่วนที่มีประโยชน์ไว้และตัดส่วนที่เสี่ยงออก โหมดมีหมายเลขเหมาะที่สุดในกรณีนี้ โมเดลยังใช้เหตุผลได้ว่าใครทำอะไร เพราะตัวตนยังแยกจากกันและสอดคล้องกันตลอด ในขณะที่ค่าจริงไม่เคยปรากฏในข้อความที่ส่งเลยสักครั้ง ถ้าต้องนำคำตอบไปทำอะไรต่อ ก็แปลงตัวแทนกลับเป็นค่าจริงบนเครื่องของคุณเอง

ทำไมการปกปิดใน PDF และภาพจึงล้มเหลว

ประวัติของการปกปิดที่ไม่ได้ปกปิดอะไรเลยนั้นยาวและน่าอาย เอกสารที่ยื่นต่อศาล รายงานของรัฐ และเอกสารของบริษัท ล้วนเคยถูกเผยแพร่ทั้งที่เพียงวาดสี่เหลี่ยมสีดำทับข้อความในโปรแกรมอ่าน PDF ตัวอักษรเดิมยังอยู่ครบข้างใต้ เลือกได้ คัดลอกได้ และถูกกู้กลับมาภายในไม่กี่นาทีหลังเผยแพร่ เรื่องเดียวกันเกิดขึ้นเมื่อมีคนใช้แปรงสีดำระบายทับภาพหน้าจอแล้วบันทึกเป็นไฟล์รูปแบบที่ยังเก็บเลเยอร์หรือภาพย่อไว้

เหตุผลคือสี่เหลี่ยมสีดำเป็นคำสั่งวาด ไม่ใช่การลบ การทำงานกับข้อความล้วนกำจัดความล้มเหลวทั้งตระกูลนี้ออกไป เพราะตัวอักษรถูกแทนที่จริงในสตริง สิ่งที่คุณคัดลอกจึงคือทั้งหมดที่มีอยู่ หากจำเป็นต้องปกปิดข้อมูลใน PDF ให้ใช้เครื่องมือที่ลบข้อความข้างใต้ออกจริง แล้วตรวจสอบด้วยการลากเลือกทับแถบดำและนำไปวางที่อื่นเพื่อดูว่าได้อะไรออกมา

ข้อจำกัดที่เครื่องมือไม่มีทางรู้

ตัวระบุที่มีโครงสร้างถูกตรวจจับได้เพราะมันมีรูปทรง ชื่อคน ตำแหน่งงาน รายละเอียดทางการแพทย์ ชื่อรหัสโครงการภายใน และประโยคอย่าง "เธออยู่ห่างจากคลินิกไปสองหลัง" ไม่มีรูปทรงแบบนั้น และไม่มีการจับคู่รูปแบบใดหาเจอ เครื่องมือลบข้อมูลกำจัดข้อมูลอ่อนไหวประเภทที่เป็นกลไกได้เท่านั้น มันไม่ได้อ่านเอกสารแทนคุณ

ให้ถือว่าผลลัพธ์คือการกวาดรอบแรกที่เก็บของที่เห็นชัดได้อย่างน่าเชื่อถือ แล้วอ่านทวนอีกครั้งก่อนส่ง ตัวเลขที่บอกว่าลบอะไรไปบ้างมีไว้เพื่อช่วยเรื่องนี้โดยตรง ถ้าคุณคิดว่ามีที่อยู่อีเมลสองรายการแต่พบเพียงรายการเดียว ส่วนต่างนั้นควรค่าแก่การกลับไปดูอีกรอบ

คำถามที่พบบ่อย

ที่นี่นับอะไรเป็นข้อมูลส่วนบุคคลบ้าง
เก้าประเภท ได้แก่ ที่อยู่อีเมล เบอร์โทรศัพท์ เลขบัตรเครดิต เลขประกันสังคมสหรัฐ ที่อยู่ IPv4 URL คีย์และโทเคน API JWT และเลขบัญชี IBAN ห้าอย่างแรกคือข้อมูลระบุตัวบุคคลแบบคลาสสิก ส่วนที่เหลือคือความลับที่หากรั่วไหลก็เสียหายไม่แพ้กันและมักติดมากับการวางข้อความชุดเดียวกัน
ข้อความของฉันถูกส่งไปที่ไหนหรือไม่
ไม่ โค้ดตรวจจับและแทนที่เป็นโมดูล JavaScript ที่ทำงานในแท็บเบราว์เซอร์ของคุณ ไม่มีการอัปโหลด ไม่มีการเรียก API และไม่มีเหตุการณ์วิเคราะห์ใดที่พาเนื้อหาของคุณออกไป นี่คือเหตุผลทั้งหมดของเครื่องมือนี้ เพราะถ้าต้องส่งข้อความอ่อนไหวออกไปที่ไหนสักแห่งเพื่อทำความสะอาด ก็เท่ากับรั่วไปแล้ว คุณตรวจสอบเองได้โดยเปิดแผงเครือข่ายของเบราว์เซอร์แล้วดูว่ามันเงียบสนิทขณะที่คุณพิมพ์
มันจะทำลายตัวเลขธรรมดาในข้อความของฉันไหม
เครื่องมือนี้ถูกสร้างมาเพื่อเลี่ยงเรื่องนั้นโดยเฉพาะ บัตรเครดิตต้องผ่านเช็กซัม Luhn และ IBAN ต้องผ่านการตรวจ mod-97 ตามมาตรฐาน ISO 13616 ก่อนจึงจะถูกแตะต้อง เลขคำสั่งซื้อ หมายเลขพอร์ต จำนวนแถว หรือเลขเวอร์ชันจึงอยู่ครบ ตัวเลขที่เรียงกันเฉย ๆ ไม่เคยถูกนับเป็นเบอร์โทรศัพท์ จะนับก็ต่อเมื่อมีรหัสประเทศหรือมีตัวคั่นจริง ๆ เครื่องมือนี้เน้นความแม่นยำมากกว่าความครอบคลุม เพราะการตรวจผิดพลาดจะกินข้อความที่คุณอยากเก็บไว้อย่างเงียบ ๆ และคุณอาจรู้ตัวหลังจากส่งไปแล้ว
ใช้ก่อนวางลงใน ChatGPT หรือ AI ตัวอื่นได้ไหม
ได้ และนั่นคือหนึ่งในการใช้งานหลัก ถ้าให้ข้อความผ่านที่นี่ก่อน โมเดลจะยังเห็นโครงสร้างและความหมายของเอกสาร ในขณะที่ที่อยู่จริง เลขบัตรจริง และคีย์จริงหายไปแล้ว โหมดมีหมายเลขเหมาะที่สุดสำหรับงานนี้ เพราะการกล่าวถึงคนเดิมซ้ำ ๆ จะกลายเป็น [EMAIL_1] ตัวเดียวกัน โมเดลจึงยังตามได้ว่าใครเป็นใคร และคุณย้อนกลับไปหาค่าจริงภายหลังได้
รู้จักคีย์ API และโทเคนแบบใดบ้าง
ข้อมูลรับรองที่มีคำนำหน้าของผู้ให้บริการซึ่งมีรูปแบบชัดเจน ได้แก่ คีย์ sk- ของ OpenAI คีย์ live และ test ของ Stripe โทเคนเข้าถึงส่วนบุคคลของ GitHub รหัสคีย์เข้าถึงของ AWS คีย์ API ของ Google โทเคน Slack PAT ของ GitLab โทเคน npm และคีย์ SendGrid รวมถึง JWT ทุกแบบและโทเคนในเฮดเดอร์ Authorization: Bearer เครื่องมือจับเฉพาะรูปแบบที่มีคำนำหน้าเท่านั้น คำทั่วไปหรือแฮชสุ่มในข้อความจึงไม่ถูกเข้าใจผิดว่าเป็นข้อมูลรับรอง
การขีดดำข้อความใน PDF ลบข้อความจริงหรือไม่
ส่วนใหญ่ไม่ การวาดสี่เหลี่ยมสีดำทับข้อความในโปรแกรมอ่าน PDF ยังคงทิ้งตัวอักษรเดิมไว้ข้างใต้ ซึ่งยังเลือกและคัดลอกได้ ความล้มเหลวในการปกปิดข้อมูลที่โด่งดังหลายกรณีเกิดขึ้นแบบนี้ การทำงานกับข้อความล้วนตัดปัญหาทั้งกลุ่มนี้ออกไป เพราะตัวอักษรถูกแทนที่จริงในสตริง สิ่งที่คุณคัดลอกจึงคือทั้งหมดที่มีอยู่
ต่างจากเครื่องมือสร้างข้อความขีดดำอย่างไร
เครื่องมือสร้างข้อความขีดดำมีไว้เพื่อความสวยงาม มันปิดคำแบบสุ่มเพื่อให้ได้ลุคเอกสารลับสำหรับโพสต์และมีม เครื่องมือนี้ทำตรงกันข้าม มันหาส่วนที่อ่อนไหวจริง ๆ แล้วลบเฉพาะส่วนนั้น ปล่อยส่วนอื่นให้อ่านได้ เอกสารจึงยังทำหน้าที่ของมันต่อไปได้
กู้ค่าต้นฉบับกลับมาได้ไหม
จากผลลัพธ์ไม่ได้ การแทนที่เป็นทางเดียวและไม่มีการเก็บตารางเทียบค่าไว้ที่ใด ถ้าจำเป็นต้องใช้ ให้เก็บข้อความต้นฉบับไว้เอง หากต้องการเทียบตัวแทนกลับไปหาค่าด้วยมือในภายหลัง ให้ใช้โหมดมีหมายเลข ซึ่งให้หมายเลขคงที่กับค่าที่ต่างกันแต่ละค่าภายในเอกสารเดียวกัน

เครื่องมือที่เกี่ยวข้อง

ทำงานต่อด้วยเครื่องมือที่มีประโยชน์เหล่านี้

เครื่องสร้างข้อความเซ็นเซอร์

แปลงรูปแบบข้อความ

ค้นหาและแทนที่ข้อความ

การอ่านแบบไบโอนิก

ขึ้นต้นด้วยตัวพิมพ์ใหญ่

ทำให้อักษรแรกของแต่ละคำเป็นตัวพิมพ์ใหญ่