TCK 226/3 ve Bulut Depolama İddiası: NCMEC CyberTipline, Google Logları

A. NCMEC (CyberTipline) İhbarı ile Açılan TCK 226/3 Bulut/Drive Dosyalarında Savunma

A.1 NCMEC raporu tek başına mahkûmiyet delili değildir

NCMEC/CyberTipline bildirimi çoğu dosyada **soruşturmayı başlatan “işaret fişeği”dir. Ancak ceza muhakemesinde mesele “ihbar var mı?” değil; ihbarın sanığa nasıl ve hangi teknik zincirle bağlandığıdır. NCMEC raporu; çoğu zaman içerik “var” iddiasını taşır, fakat yükleme fiilinin faili, kast, oturum ve cihaz izi gibi kritik unsurları otomatik olarak ispatlamaz.

A.2 TCK 226/3’te “bulundurma / depolama” eşiği nasıl kurulur?

TCK 226/3 bakımından “bulundurma/depolama” salt teknik iz değildir. Ceza hukuku anlamında bulundurma; failin, içeriğin niteliğini bilerek ve onu muhafaza etmeye yönelik iradeyle hareket etmesini gerektirir. Bu nedenle “Drive’da görünmesi” veya “hesapta bulunması”, tek başına bilinçli depolama kastı sonucunu doğurmaz. Özellikle otomatik yedekleme, senkronizasyon, geçici kopya, arka plan aktarımı ihtimalleri araştırılmadan “kasten depolama” kabulü hatalı olur.

A.3 CMK 134 ve dijital delilde “zincir bütünlüğü”

NCMEC/Google kaynaklı TCK 226 dosyalarında mahkûmiyetin ana taşıyıcısı “dijital delil” olduğu için; CMK 134 kapsamında imaj alma, hash doğrulama, teslim-tesellüm, tutanak tutarlılığı kusursuz olmalıdır.

• Hangi cihazdan alındı?

• Hangi yöntemle alındı (logical / file system / full physical)?

• Hash doğrulaması yapıldı mı?

• Kopya müdafie verildi mi?

• Aynı dosya içinde kişi/cihaz/tutanak karışıklığı var mı?
  Bu sorular cevaplanmadan “delil bütünlüğü” konuşulamaz.

A.4 Fail-atfı: “Hesap aidiyeti” ile “yükleme fiili” aynı değildir

Bir e-posta hesabının sanığa ait görünmesi, o hesaptaki içeriğin sanık tarafından yüklendiğini tek başına ispatlamaz. Özellikle:

• hesap ele geçirilmesi,

• şifre sıfırlama / recovery,

• olağandışı oturum,

• başka cihazdan senkron,

• otomatik upload
  ihtimalleri varken; “hesap seninse yükleme de sensin” şeklindeki çıkarım, savunmada hedef alınması gereken bir “atlarım zinciri”dir.

B. Dijital Fail-Atfının Kalbi: IP Kayıtları, Oturum Logları ve Teknik Eşleştirme

B.1 Statik IP mi, dinamik IP mi, public IP mi? CGNAT var mı?

Bu dosya tipinde IP kaydı araştırılmadan kişi-atfı kurulamaz. IP’nin niteliği mutlaka netleştirilmelidir:

• Statik IP: Aboneye kalıcı tahsis; daha güçlü eşleştirme (yine de tek başına yeterli değildir).

• Dinamik IP: Süreli tahsis; mutlaka tarih-saat aralığı ile doğrulanır.

• Public IP: İnternete çıkış adresi; özellikle paylaşımlı ağlarda tek başına kişiyi göstermeyebilir.

• CGNAT (Carrier-Grade NAT): Aynı public IP’yi birden fazla abone paylaşabilir; bu durumda port + timestamp + zaman dilimi olmadan eşleştirme eksik kalır.

Port + Timestamp + UTC uyumu neden “altın standart”tır?

CGNAT/dinamik senaryolarda eşleştirme; public IP + port numarası + milisaniye seviyesinde zaman damgası + UTC/yerel saat uyumu ile yapılır. Bu üçlü yoksa IP, çoğu zaman yalnızca “şüphe” üretir, “kesin ispat” üretmez.

B.2 Login IP mi, Upload IP mi? İkisi ayrı ayrı istenmelidir

Savunma açısından kritik ayrım:

• Login IP: Hesaba giriş yapılan IP

• Upload IP: Dosyanın buluta düştüğü IP
  Bazen hesaba giriş bir cihazdan, upload başka cihazdan/senkron hizmetinden gelir. Bu nedenle “giriş var” delili, “yükleme de oradan yapıldı” anlamına gelmez.

B.3 ISS trafik verisi, NAT kayıtları, abonelik bilgisi celbi

IP kayıtları dinamik/CGNAT ise; internet servis sağlayıcıdan (ISS) şu veriler istenmeden kişi-atfı tamamlanmış sayılmaz:

• Abone bilgisi

• IP tahsis başlangıç-bitiş zamanı

• NAT/CGNAT eşleştirme kayıtları

• Port bilgisi

• Zaman damgası formatı ve saat dilimi
  Bu verilerle “sanığın interneti” ile “suç zamanı upload” aynı çizgide mi sorusu netleşir.

B.4 Hesap ele geçirilmesi (account takeover) göstergeleri araştırılmalı (İhtimalleri)

NCMEC/Google dosyalarında sık görülen savunma çizgisi: hesap kontrolden çıktı. Bunu “soyut savunma” saymak yerine, teknik göstergelerle test etmek gerekir:

• Olağandışı giriş uyarıları

• Şifre sıfırlama denemeleri

• Recovery e-posta/telefon değişikliği

• Oturum sonlandırma kayıtları

• Aile grubu/cihaz yetkilendirme değişimleri
  Bunlar gelmeden “savunma kurtulmaya yönelik” demek, dosyanın kalbini eksik bırakır.

B.5 NCMEC CyberTipline raporunun hukukçu İngilizce tercümesi zorunludur

NCMEC raporlarında tek bir kelime bile fail-atfını değiştirir:

• “uploaded” mı deniyor, “associated” mı?

• “account holder” mı, “user” mı?

• “apparent upload” / “suspected” gibi ifadeler hangi ağırlıkta?
  Bu yüzden tam rapor + ekler + alanların hukukî-terimsel tercümesi (hukukçu İngilizce) talep edilmelidir. Özet çeviri, çoğu kez savunma hakkını zedeler.

C. Google Drive Senkronizasyonu, Adobe Senkronizasyonu, Torrent Otomatik Yedekleme ve Muzır Kurul Raporu

NCMEC Davasında Etkin Savunma; Tevsii Tahkikat ve Strateji Şeması

Bu başlık, TCK 226/3 (bulundurma/depolama) dosyalarının “kader anı”dır. Çünkü mahkûmiyetin çoğu zaman dayandırıldığı şey, içeriğin bir yerde bulunması değil; o içeriğin sanık tarafından bilerek, isteyerek, muhafaza kastıyla depolandığının teknik zincirle ispatıdır. NCMEC/CyberTipline dosyalarında da kritik ayrım şudur:

“Dosya buluta düştü” ≠ “Sanık dosyayı bilerek depoladı.” Aradaki mesafe, ancak senkronizasyon mimarisi + oturum/IP eşleştirmesi + bilirkişi incelemesi + hash/zaman damgası doğrulaması ile kapatılabilir.

C.1) Savunmanın Çekirdeği: “Dijital İz” ile “Bilinçli Depolama” Aynı Şey Değildir

Bir dosyanın Google Drive’da görünmesi, teknik olarak en az dört ayrı yoldan gerçekleşebilir:

1. Manuel yükleme: Kullanıcı seçer, yükler (kast lehine tartışmaya açık tek kanal budur).

2. Otomatik senkronizasyon: Belirlenen klasörler arka planda eşitlenir.

3. Otomatik yedekleme: Fotoğraf/video, proje dosyası, sistem klasörleri arka planda taşınabilir.

4. Üçüncü taraf istemciler: Adobe gibi uygulamalar veya torrent istemcileri, indirme/proje klasörlerini “izleme” mantığıyla çalıştırabilir; dosyayı istemeden “buluta açık” hâle getirebilir.

Savunma stratejisi tam burada “şunu” kurar: Mahkeme, dosyanın görünmesini değil; görünme mekanizmasını ispat düzeyinde ortaya koymadan ‘bilinçli depolama’ sonucuna atlayamaz.

TCK 226/3 çizgisinde tartışma, çoğu zaman yanlış yerden başlatılır: “Dosya bulundu mu?” Oysa doğru soru şudur: Bu dosya, sanığın iradesiyle mi depolandı; yoksa sistemin ürettiği bir dijital yansıma mı? Ceza hukukunda “bulundurma/depolama” kavramı, salt bir teknik varlık değil; bilinç + kast + muhafaza iradesi gerektiren bir fiildir. Bu nedenle cache/temporary files, thumbnail/preview, sync artifacts, auto-backup çıktıları veya “buluta düşmüş” görünümler, tek başına “bilinçli depolama” sonucunu doğurmaz.

Fail-atfı bakımından “hesap aidiyeti” ile “yükleme fiilinin faili” ayrı ayrı ispatlanmalıdır; aksi hâlde iddianame, şüpheden ispat üretmeye çalışır. NCMEC/CyberTipline dosyalarında gerçek eşik; hash listesi + timestamp (UTC uyumu) + upload event + session/token + IP/port eşleştirmesi ile kurulur.

İzmir ve Muğla’da takip ettiğimiz benzer TCK 226 dosyalarında, sırf “Drive’da göründü” tezinin; senkronizasyon/oturum verileriyle çürütülmesiyle beraat çizgisine yaklaşan sonuçlar alındı; Samsun dosyalarımızda da teknik zincir kurulmadan yapılan atıfların mahkeme nezdinde değer kaybettiği görüldü.

C.2) Google Drive: Otomatik Senkron mu, Otomatik Yedekleme mi, Üçüncü Cihaz mı?

Google ekosisteminde en sık düşülen hata, Drive’ı “pasif klasör” gibi düşünmektir. Oysa pratikte Drive:

• bilgisayar tarafında klasör eşitleyebilir,

• mobilde farklı yedekleme davranışlarıyla çalışabilir,

• birden fazla cihazdan aynı hesaba “eş zamanlı” veri akıtabilir,

• geçmişte bağlı kalan bir cihazın senkronu günler sonra bile yeniden tetiklenebilir.

Bu nedenle bilirkişiye şu “çekirdek” sorular sorulmadan hüküm sağlıklı kurulmaz:

• Dosya Drive’a hangi cihazdan düştü?

• Upload anında login IP ile upload IP aynı mı?

• Hesapta aynı tarihte başka cihaz oturumu var mı?

• Dosya bir klasör senkronundan mı geldi, yoksa manuel mi yüklendi?

• Dosya Drive’da “klasörlenmiş / yeniden adlandırılmış / taşınmış” mı, yoksa “ham düşmüş” bir kayıt mı?

Bu sorular, kast tartışmasının omurgasıdır: Klasörleme–yeniden adlandırma–taşıma gibi “kullanıcı iradesi” izleri yoksa, “bulundurma/depolama kastı” iddiası teknik olarak zayıflar.

Özellikle çoklu cihaz (multi-device) ve arka plan senkronizasyonu ile çalışan bir ekosistemdir. Bu yüzden savunmanın ana ayrımı şudur: Login IP başka, upload IP başka olabilir; hatta upload, sanığın elindeki cihazdan değil, geçmişte bağlı bir masaüstü istemcisinden (Drive for desktop), eski bir telefondan ya da aynı hesaba tanımlı üçüncü bir cihazdan tetiklenebilir.

Yükleme “manuel” mi yoksa auto-sync / auto-backup mı; bunu belirleyen şey, hesaptaki dosyanın varlığı değil, olayın dijital izidir: session logs, device list, user-agent, OAuth token, “last modified”–“created” zaman damgaları, folder path, sync scope, link sharing events. Bir dosya gerçekten bilinçli depolanmışsa genelde yanında kullanıcı iradesini gösteren artefact bırakır: klasörleme/taşıma, yeniden adlandırma, paylaşım ayarı, tekrar erişim gibi. Bunlar yoksa, savcılığın “bulutta görünmesi = bilinçli depolama” varsayımı teknik olarak zayıflar.

Tam da bu nedenle, Mahkeme’de etkin savunmada; Google’dan security events + login/upload IP + port + timestamp + UTC uyumu ve cihaz/oturum kayıtlarının celbidir. İzmir–Muğla–Aydın-Balıkesir ve İstanbul hattındaki uygulamadaki davalarımızda gördüğümüz husus bu nevinden savunmaları etkin ve eksiksiz sunumu ile hakimlik beraate yaklaşabilmektedir.

C.3) Adobe Senkronizasyonu: “Bulut Belge / Otomatik Eşitleme” Mekanizması ve Yan Etkileri

Adobe Creative Cloud ekosistemi (özellikle “Cloud Documents”, eşitleme, otomatik kaydetme, proje klasörü düzeni) şu riskli tabloyu doğurabilir:

• Kullanıcı bir proje dosyasını Downloads / Desktop gibi senkrona açık bir dizinde tutuyorsa,

• Adobe uygulaması bu proje alanını otomatik eşitliyorsa,

• ya da “bulut belge” modunda çalışılıyorsa,
  o dizine düşen medya dosyaları kullanıcı her seferinde “yükle” demeden eşitleme kapsamına girebilir.

Savunma açısından kilit nokta şudur: Adobe/Creative Cloud senkronizasyonu, Google Drive senkronu ile çakıştığında, bir dosya “iki farklı otomasyon zinciri” ile kullanıcı iradesi dışında buluta taşınmış görünebilir.

Bu yüzden bilirkişiden ayrıca şu başlıkların incelenmesi istenir:

• Creative Cloud/Adobe hesabında bulut belge kullanımı var mı?

• Proje klasörleri hangi dizinlere bağlı? (Downloads/Desktop gibi riskli dizinler)

• Senkron ayarları, otomatik eşitleme ve “auto-save” logları ne söylüyor?

• Dosyanın oluşturulma/değiştirilme zamanı Adobe loglarıyla örtüşüyor mu?

C.4) Torrent ve “Otomatik Yedekleme” Gerçeği: Watch Folder, Parça Dosyalar ve İstem Dışı Kalıntılar

Torrent istemcileri (qBittorrent/uTorrent benzeri) teknik olarak iki kritik davranış doğurur:

• Watch Folder / otomatik ekleme: Belirli bir klasöre düşen .torrent dosyası, kullanıcı “bilerek başlatmasa bile” istemci tarafından kuyruğa alınabilir.

• Parça dosyalar / geçici kalıntılar: İndirme tamamlanmasa bile cihazda “parça parça” veri oluşabilir; bu veri daha sonra senkron kapsamındaki dizine taşınabilir veya yedekleme sistemleri tarafından kopyalanabilir.

Bu alan, ceza dosyalarında sıkça “niyet okuma”ya müsaittir. Savunma burada şunu ister:

• Torrent istemcisi yüklü mü?

• Kuruluysa indirilenler dizini neresi?

• Watch folder aktif mi?

• Loglar/resume verileri “ne zaman, hangi dosya, hangi klasör” diyor?

• İndirme tamamlanmış mı, yoksa parça kalıntı mı?

• Bu dizin, Google Drive/Adobe senkronuna açık bir dizinle çakışıyor mu?

Bunlar incelenmeden “dosya cihazda vardı → bilinçli depoladı” şeklinde bir atlama, savunma açısından en kolay kırılan mantık zinciridir.

C.5) Muzır Kurul Raporu: NCMEC İçeriğini “Hash-Dosya” Düzeyinde Bağlamıyorsa İddia Taşıyıcı Delil Olamaz

Buradaki en kritik cümle şudur: Muzır Kurul raporu, NCMEC/CyberTipline içeriğiyle hash/dosya listesi düzeyinde birebir eşleştirilmediği sürece “somut NCMEC materyalini” ispat etmez. Bu arada bu Türk yargı uygulaması için geçerlidir. Bu kurul raporu teşekkülü itibariyle bu hususta ne kadar uzmandır; o da ciddi manada tartışmalıdır.

Muzır Kurul değerlendirmesi “genel nitelik” konuşur; oysa NCMEC dosyası “somut dosya kümesi” konuşur. Eşleştirme yoksa:

• Hangi dosyadan bahsedildiği belirsizdir,

• Aynı içerik olup olmadığı belirsizdir,

• NCMEC tipindeki hash’lerle örtüşüp örtüşmediği belirsizdir,

• Dolayısıyla “NCMEC içeriği” bakımından ispata katkısı sınırlı/olmayan bir tartışmaya dönüşür.

Bu eksiklik, savunmada “iddianamenin ispat ayağı”na doğrudan temas eder: Somutlaştırılmamış içerikle kast kurulamaz.

D. Savunmada Tevsii Tahkikat Paketi: Kısa, Teknik

Aşağıdaki talepler, bu başlığın “mahkemelik omurgasıdır”:

1. Google/Drive oturum ve yükleme kayıtları: Login IP + Upload IP + user-agent + cihaz listesi + oturum zamanları (UTC uyumlu) + security events (şifre sıfırlama, olağandışı giriş).

2. IP’nin niteliği: Statik mi/dinamik mi? Public IP mi? CGNAT var mı? CGNAT ise port + timestamp olmadan kişi-atfı yapılamayacağı bilirkişice raporlansın.

3. Senkronizasyon analizi: Google Drive senkron ayarları, eşitlenen klasörler, çoklu cihaz senkronu, arka plan yedekleme ihtimali (manuel upload ile ayrıştırılsın).

4. Adobe/Creative Cloud incelemesi: Cloud documents/auto-save/senkron ayarları; proje klasörlerinin Drive ile çakışıp çakışmadığı; log ve zaman damgası uyumu.

5. Torrent istemcisi incelemesi: Kurulu istemci var mı? Watch folder açık mı? İndirme dizini neresi? Log/resume verileri ne diyor? Parça dosya kalıntıları var mı?

6. NCMEC raporunun tam nüshası + hukukçu İngilizce tercümesi: Tipin tamamı, ekleri, dosya listesi, hash’ler, event alanları; “uploaded/associated/apparent” gibi alanlar hukuki terimlerle doğru çevrilsin.

7. Muzır Kurul raporu varsa: NCMEC tipindeki dosyalarla hash/dosya listesi düzeyinde birebir eşleştirme yaptırılsın; eşleşme yoksa “NCMEC içeriği açısından veri taşımadığı” tespit edilsin. Bu Kurul ise bunu yapmaya ehil olmadığından; gelecek cevab-ı yazı ile zaten kendi kendine dayanakları çökecektir!

   • Burada ise en unutulmaması gereken husus; yargılamanın ağır bir psikoloji yönetimi yanı olması, yargısal adaba münhasır bir çizgide bunu müdafii olarak yönetmek ve etkin rol alma gerekliliğidir. İşbu sebeple telafisi imkansız hak kayıplarının önüne geçilmesi açısından mutlak surette avukatınıza danışmanızı öneriyoruz.

   • Muzır Neşriyat Kurulu Kesin Var Ceza Olur Anlayışı Da Yanlıştır, Okuyunuz;

   • “NCMEC & Müstehcenlik” Davasında Muzır Neşriyat Kurulu

Bu Dosyalar “Algoritmayı” Değil, “İradeyi” Yargılar; TCK 226/3 çizgisinde mahkeme, otomasyon sistemlerinin ürettiği izlere bakarak değil; iradeyi, kastı ve fail-atfını teknik doğrulama ile kurarak hüküm verir. Google Drive senkronizasyonu, Adobe senkronizasyonu ve torrent kaynaklı otomatik indirme/yedekleme ihtimalleri çürütülmeden, NCMEC/CyberTipline bildirimi “kanıtın kendisi” hâline getirilemez; en fazla “araştırma sebebi” olur.

Avukat Orhan ÖNAL’ın Bu Konuda Çok Sık Okunan Başka Yazıları;

• Avukat Orhan ÖNAL çizgisinde hazırlanan NCMEC Davaları & Soruşturmaları yazıları; tecrübeye dayalı genel bilgilendirme amaçlıdır; somut dosya stratejisi, evrak ve teknik rapor içeriğine göre ayrıca değerlendirilmelidir. Bu hususta ve benzeri nitelikte konularda ise uzun yıllardır üzerinde çalıştığımız ancak tamamlayamadığımız “NCMEC Uygulamaları Kitabında” da detaylıca yer verilmektedir.
• Teknik ve hukuk alanında tecrübe gerektiren bu konularda telafisi imkansız hak kayıplarına uğramamak için, mutlaka avukatınıza danışmanızı şiddetle önermekteyiz.
• Benzer NCMEC’den doğan ceza davalarından gördüğümüz; her nevinden NCMEC davalarında farklı savunma argümanları geliştirilerek hareket edilmesi gerekliliğinin unutulmamasını ve mutlaka avukatınızla hareket edilerek savunma yapılmasını unutmamanızı şiddetle tavsiye ederiz.
• Aradığınız dava türü veya hukuki ihtilaf hakkında *yazılar*  bölümüne veya *NCMEC DAVALARI için* tıklayarak ya da sağ üst köşeden arama yaparak onlarca davanız hakkında dilediğinizi okuyup, araştırabilirsiniz.

  • AVUKAT DESTEĞİ

    Randevu almak için çalışma saatleri içerisinde aşağıdaki telefon aracılığı ile ulaşabilir, whatsapp hattına yazabilir (tıkla) veya aşağıdaki adrese mail atabilirsiniz. 

    Hafta içi: 09:00 – 19:00
    Cumartesi: 10:00 – 18:00

    Telefon: +90 532 282 25 23

    Gizlilik

    Gizlilik, bir avukatın ve hukuk büromuzun en önemli etik ilkelerinden biridir; 1136 sayılı Kanunda tanımlanan gizlilik ve ifşa etmeme ilkesini çok dikkatli ve hassas bir şekilde uygular. Ancak büromuz, müvekkillerinin bilgi, belge ve bilgilerini gizlilik ve bilgi sorumluluğu sınırları içinde gizli tutar ve hiçbir şekilde ve hiçbir koşulda üçüncü kişi ve kurumlarla paylaşmaz.