PDF belgelerindeki hatalı redaksiyonları tespit eden Python kütüphanesi X-ray

 (github.com/freelawproject)
3 puan yazan GN⁺ 2025-12-24 | 1 yorum | WhatsApp'ta paylaş
  • PDF belgelerindeki uygunsuz redaksiyon işlemlerini otomatik olarak tespit eden bir Python kütüphanesidir; metnin yalnızca siyah bir dikdörtgenle kapatıldığı durumları belirler
  • Free Law Project tarafından, milyonlarca PDF toplarken karşılaşılan tekrar eden bir sorunu çözmek için geliştirildi
  • Komut satırından veya Python kodu içinden çalıştırılabilir ve sonuçları JSON ya da Python nesneleri olarak döndürür
  • Dahili olarak PyMuPDF kullanarak PDF içindeki dikdörtgen, metin ve renk bilgilerini analiz eder; böylece redaksiyonun gerçekten metni gizleyip gizlemediğini değerlendirir
  • Hukuki belgeler veya kamuya açık materyallerde kişisel verilerin ifşa edilmesini önlemeye yönelik otomatik bir doğrulama aracı olarak oldukça değerlidir

Genel Bakış

  • x-ray, PDF dosyalarındaki hatalı redaksiyonları tespit eden bir Python kütüphanesidir
    • Kullanıcı PDF yolunu verdiğinde, redaksiyonun düzgün yapılmadığı alanları bulur
    • Sonuçlar, sayfa bazında koordinatlar (bbox) ve ilgili alanın metnini (text) içeren JSON biçiminde çıktılanır

Geliştirme Arka Planı

  • Free Law Project, milyonlarca PDF toplarken redaksiyonu düzgün yapılmamış çok sayıda belge buldu
    • Bazı kullanıcılar metni silmek yerine siyah dikdörtgenler veya vurgu işaretleriyle kapatma yöntemini kullanıyordu
    • Bu durumda, dikdörtgenin altındaki metin seçildiğinde özgün metin olduğu gibi ortaya çıkıyordu
  • Bu sorunun ne kadar yaygın olduğunu anlamak için x-ray aracı geliştirildi

Kullanım

  • Kurulum
    • pip install x-ray veya uv add x-ray komutlarıyla kurulabilir
  • Komut satırından çalıştırma
    • xray path/to/file.pdf biçiminde çalıştırıldığında JSON sonuç üretir
    • URL girildiğinde uzak PDF indirilir ve ardından incelenir
    • Birden fazla URL’yi tek seferde incelemek için xargs -n 1 xray < urls.txt kullanılabilir
  • Python kodu içinde kullanım
    • xray.inspect("file.pdf") çağrıldığında sonuçlar Python nesnesi olarak döner
    • Girdi bir dizeyse yerel dosya, https:// ile başlıyorsa URL, bytes ise bellekteki PDF olarak işlenir
    • Dosya yolu bytes türünde verilirse çalışmaz

Çalışma Prensibi

  • Dahili olarak PDF’yi analiz etmek için PyMuPDF kullanır
    1. PDF içindeki dikdörtgenleri (rectangle) bulur
    2. Aynı konumdaki karakterleri (letter) bulur
    3. Dikdörtgeni görüntü olarak render eder
    4. Dikdörtgen tek bir renkle doldurulmuşsa bunu hatalı redaksiyon olarak değerlendirir
  • PDF yapısı karmaşık olduğundan kusursuz tespit zordur, ancak sürekli iyileştirme yapılmaktadır
  • Proje bağış ve sponsorluklarla sürdürülmektedir

Katkı ve Dağıtım

  • Desteklenmeyen örnekler veya iyileştirme talepleri GitHub’daki issues listesi üzerinden görülebilir
  • İlk katkıdan önce Katkıcı Lisans Sözleşmesi (CLA) imzalanması gerekir
  • Dağıtım GitHub Actions ile otomatikleştirilmiştir; manuel dağıtım için poetry publish --build komutu kullanılır

Lisans

  • BSD lisansı ile yayımlanmıştır ve diğer projelere serbestçe entegre edilebilir
  • Pull Request’ler ve özellik önerileri memnuniyetle karşılanır; GitHub web arayüzü üzerinden doğrudan düzenleme yapılabilir

İlgili okumalar

1 yorum

 
GN⁺ 2025-12-24
Hacker News yorumları

  • Free Law Project'te çalışırken yıllara yayılan pek çok karmaşık proje yaptım ama bu X-ray projesi en çok ses getiren örnek oldu
    CourtListener'daki milyonlarca belgeyi analiz etmek için X-ray'i geliştirdik ve amacımız insanları bu sorundan haberdar etmekti
    S3 batch job ile milyonlarca belgeyi birkaç dakika içinde analiz ettik ama sonuçları düzenleyip raporlamak gibi asıl zor kısım hâlâ duruyor

    • Argelius Labs'ın PDF güvenlik araştırmasına göre, siyah kutuyla kapatılan kısmın sadece uzunluğundan bile kelime uzunluğu tahmin edilebilen bir glyph spacing saldırısı mümkünmüş
      X-ray'in de bu tür yazı tipi metrik sızıntılarından yararlanıp yararlanmadığını merak ediyorum
    • Yazı tipinin kerning bilgisi ve piksel düzeyinde yeniden üretim mümkünse kelimeleri epey doğru tahmin etmek mümkün olabilir
      Örneğin oioioi ile oooiii, yazı tipine göre farklı genişliklere sahiptir

  • Bugün yayımlanan dosyaların yalnızca yaklaşık %10'una baktım ama örneğin EFTA00037069.pdf içinde bir /Prev pointer var; yani önceki sürüm PDF'in içinde gömülü duruyor
    Bu küçük bir değişiklik ama başka dosyalarda da bulunma ihtimali yüksek
    Bunu qpdf --show-object=trailer komutuyla doğrudan doğrulayabilirsiniz
    Bu kadar berbat bir düzenleme işinin hatadan çok kasıtlı olabileceğini düşünüyorum

    • Kendim kontrol ettim; o dosyadaki değişiklik geçmişi aslında sadece her sayfaya numara eklenmesinden ibaretti
      Orijinali zaten tamamen flatten edilmiş bir belgeydi
    • Bu işi yapan kişilerin en temel yönergeleri bile bilmiyor olması pek şaşırtıcı değil
    • Gerçekte muhtemelen rastgele insanlara redaction işi yaptırıyorlar; sorun da büyük ölçüde deneyimsizlik olabilir

  • Üzerine düşündükçe yazı tipindeki kerning bilgisi redaction için ciddi bir zayıflık gibi görünüyor
    Siyah kutunun çevresindeki metnin konumundan bile gizlenen kelimenin uzunluğu ve biçimi tahmin edilebilir
    Render algoritmasını biliyorsanız brute-force ile gerçek metni çıkarsamak bile mümkün olabilir gibi geliyor
    Bunu araştıran biri olup olmadığını merak ediyorum

    • Kerning'i otomatik olarak rastgele ayarlayan bir font olsa güzel olurdu
      Aynı kelimenin bile her belgede farklı aralıklarla görünmesini sağlayan bir yaklaşım
    • Son dönemde LLM'lerin şifreli sohbet oturumlarında bile paket boyutu ve zamanlama analizi ile bilgi çıkarılan örnekler vardı
      Bu da benzer türde bir yan kanal saldırısı
    • Bu, redaction'ın uzunluğuna ve ne kadar tahmin edilebilir olduğuna bağlı
      Kısa ve bağlam gereği “yes” ya da “no” ile sınırlıysa kolay tahmin edilir ama isimler veya uzun cümleler çok daha zordur

  • PDF'in, bir dijital belge formatı olarak bu kadar temel kusura hâlâ sahip olmasına rağmen yaygın biçimde kullanılmaya devam etmesi üzücü

  • Basit bir soru ama bu tür belge açıklamalarında redaction'ın amacı tam olarak nedir, merak ediyorum
    Neden anonimliğin korunması gerektiğini de ilk başta anlamamıştım
    (Düzenleme sonrası) Suçsuz kişilerin de işin içinde olabileceğini düşününce mantıklı geldi

    • Hukuken yalnızca mağdur kimliği, devam eden soruşturmalar, çocuk cinsel istismarı materyalleri ve ulusal güvenlikle ilgili bilgiler gizlenebilir
      İtibar zedelenmesi veya siyasi gerekçelerle gizleme yapmak yasaktır
      Ama pratikte yapılan redaction işlemlerinin bu ölçütlere uymadığına dair ciddi kaygılar var
    • WikiLeaks'in yaklaşımı, yalnızca kişilerin fiziksel zarar görmesine yol açabilecek bilgileri gizlemekti
      Örneğin GPS koordinatlarının açıklanmasının bombalama riski yaratabileceği durumlar gibi
    • Mağdurlar, eğer redaction failin korunması için yapılıyorsa bunu istemediklerini söylüyor
      Onlara göre asıl önemli olan hesap verilebilirlik
    • Amaç, mağdurların, tanıkların ve muhbirlerin kimliğini korumaktır
    • Uzun süreli soruşturma dosyalarında asılsız ihbarlar veya yanlış bilgiler çok olur; bu yüzden suçsuz insanların mahremiyetini korumak gerekir
      Ancak bu olay fazla önemli olduğu için yayımlanması kaçınılmaz hale gelmiş görünüyor

  • Redacted PDF yayımlarken siyah dikdörtgen çizip ardından belgeyi görüntü olarak rasterize etmek temel prosedür olmalı gibi geliyor 🤷

    • Ben anti-screenshot alanında bir iş yürütüyorum ve bu tür redaction hataları gerçekten çok yaygın
      Sadece siyah kutu kapatmak verinin yok olduğu anlamına gelmiyor
      Compliance tarafında bu tür yanlış anlamaları sık görüyorum
    • Ama bazı durumlarda belgenin aranabilir kalması gibi gereksinimler oluyor; bu yüzden görüntüye dönüştürmek her zaman mümkün olmayabiliyor

  • Adobe Pro doğru kullanıldığında PDF içeriğini kalıcı olarak silebilir (redact)
    Bu olay sadece PDF düzenleyicisini doğru kullanamayan birinin yaptığı amatörce bir hata
    Binlerce avukatın ve hukuk çalışanının onlarca yıldır kullandığı sürecin göz ardı edilmesinin sonucu
    Eskiden kağıt üzerine siyah çizgi çekip basılı çıktıyı nihai sürüm olarak kullanırlardı; muhtemelen hâlâ o dönemden kalma bir anlayışla hareket edildi

    • Muhtemelen PDF'e kağıtmış gibi davranıp sadece siyah kutu kapatmanın yeterli olduğunu düşündüler
      Metin seçimi engellendiği için gerçekten gizlendiğini sanmış olabilirler
      Ya da bunu bilerek bu şekilde yapıp sonra da hata gibi gösterme niyetinde olabilirler
    • ABD federal hükümetindeki avukatlar ve soruşturmacılar redaction eğitimi konusunda oldukça sıkı eğitim alır
      Bu yüzden birçok kişi bunun basit bir hata değil, kötü niyetli uyum (malicious compliance) olduğunu düşünüyor

  • Şaşırtıcı biçimde, tarayıcının PDF görüntüleyicisinde bile redacted bilgi görünüyor
    Brave (Linux) üzerinde bu belgeyi açıp 90. paragrafın ilk satırını kopyalarsanız, gizlenen metin aynen yapışıyor

    • Bu tür hatalı redaction örnekleri, X-ray'in tespit edebildiği tipik vakalardan biri

  • ediscovery (elektronik delil keşfi) kavramının artık genel kamuya da yayılmaya başladığını görmek ilginç

  • Teknoloji sektöründekiler, teknik olmayan alanlardaki insanların ne kadar teknoloji okuryazarlığından yoksun olduğunu görünce şaşırabilir
    Bu bana IT sorumlusunun şirkette her şeyi bilen, her şeye gücü yeten biri gibi görüldüğü eski günleri hatırlatıyor