NCMEC Kaynaklı TCK 226/3 Dosyalarında En Kritik Savunma: Dijital İz mi, Bilinçli Depolama mı?
NCMEC/CyberTipline ihbarı ile başlayan TCK 226/3 müstehcenlik suçu dosyalarında savunmanın en stratejik noktası, dosyanın ilk bakışta oluşturduğu psikolojik ağırlığa teslim olmamaktır. İşbu yazı genel hatları ile bu hususa dair uzun yıllardır emek verdiğimiz; Gmail-Gooogle NCMEC ihbarlı TCK 226 suçlarına dair savunmalarımızdan esinlenerek kaleme alınmaktadır.
Bu dosyalarda çoğu zaman “bir hesapta”, “bir cihazda”, “bir bulut servisinde” veya “bir imaj raporunda” birtakım dijital izlerden söz edilir. Ancak ceza muhakemesinin sorması gereken asıl soru şudur: Bu dijital iz, sanığın bilerek, isteyerek ve muhafaza kastıyla gerçekleştirdiği bir depolama/bulundurma davranışını mı gösteriyor; yoksa sistemsel, geçici, otomatik veya üçüncü cihaz kaynaklı bir teknik görünüm mü?
Yani Asıl Mesele;
TCK 226/3, çocukların kullanıldığı müstehcen ürünleri “ülkeye sokma, çoğaltma, satışa arz etme, satma, nakletme, depolama, ihraç etme, bulundurma veya başkalarının kullanımına sunma” seçimlik hareketleriyle düzenler. Bu nedenle savunmada mesele yalnız “dosya var mı?” değildir; asıl mesele dosyanın faille, kastla, fiilî egemenlikle ve bilinçli dijital muhafaza iradesiyle bağlanıp bağlanmadığıdır. TCK 226/3’ün bu seçimlik hareket yapısı ve çocukların kullanıldığı müstehcen ürünler bakımından ikinci cümlede ayrı suç tipi kurduğu husus, kanun metni ve madde gerekçesinde açıkça görülmektedir.
1) Savunmanın Çekirdeği: “Dijital İz” ile “Bilinçli Depolama” Aynı Şey Değildir
1.1 Dijital ceza dosyasında ilk hata: teknik varlığı hukuki irade sanmak
TCK 226/3 kapsamında yürütülen çocuk müstehcenliği, NCMEC raporu, Google Drive, iCloud, WhatsApp Media, Telegram, torrent, cache veya cihaz imajı odaklı dosyalarda en büyük hata, dijital materyalin teknik olarak bir yerde görünmesini doğrudan “bilinçli bulundurma” kabul etmektir. Oysa dijital iz, çoğu zaman sadece bir sistemin çalışma sonucudur. Bilinçli depolama ise failin o içerik üzerinde bilgi, irade, erişim ve muhafaza kastıyla fiilî egemenlik kurmasıdır.
Bu ayrım ceza hukukunun merkezindedir. Çünkü TCK 226/3 bakımından taksirli bir suç tipi değil, kasten işlenebilen bir suç tipi tartışılır. Bu nedenle “cihazda çıktı”, “Drive’da görüldü”, “raporda eşleşti”, “hesapla bağlantılı” gibi ifadeler; tek başına müstehcenlik suçu mahkûmiyeti için yeterli değildir. Savunmanın görevi de tam olarak buradadır: teknik görüntü ile hukuki sonuç arasındaki mesafeyi açmak, mahkemeye “bu veri nasıl oluştu?” sorusunu sordurmaktır.
1.2 Cache, thumbnail, preview, temp ve sync artefact: Bunlar aktif bulundurma değildir
Bir dosyanın dijital sistemde farklı şekillerde iz bırakması mümkündür. İnternet tarayıcıları sayfaların hızlı açılması için cache/önbellek verileri oluşturabilir. Görsel ve videolar için thumbnail/önizleme kayıtları üretilebilir. Uygulamalar geçici çalışma alanlarında temp file bırakabilir. Bulut sistemleri ve cihazlar arasında sync artefact denilen eşitleme kalıntıları meydana gelebilir. İmaj alma yahut carving yöntemiyle silinmiş/parçalanmış veri parçaları geri getirilebilir.
Bunların tamamı, hukuken aynı değerde değildir. Bir materyalin:
- masaüstünde özel klasöre alınması,
- yeniden adlandırılması,
- arşivlenmesi,
- favoriye eklenmesi,
- paylaşım linki oluşturulması,
- tekrar tekrar açılması,
- farklı cihaza aktarılması,
- üçüncü kişiye gönderilmesi
gibi iradi kullanım izleri varsa başka; sadece sistemsel kalıntı, önbellek, geçici kopya veya otomatik senkron sonucu görünüyorsa bambaşka değerlendirilir. İzmir 35. Asliye Ceza Mahkemesi’nin 2023/20 E., 2024/513 K. sayılı beraat hükmünün aktarıldığı savunma setinde de, internet üzerinde izlenen videolara ait önbellek verilerinin geçici depolama alanı niteliğinde olduğu, sanığın bunları gönderme, depolama, nakletme veya yayınlama kastına dair kesin ve inandırıcı delil bulunmadığı değerlendirmesi özellikle öne çıkarılmıştır.
1.3 Fail-atfı yalnız hesap adıyla kurulmaz; dijital isnat zinciri gerekir
NCMEC/CyberTipline kaynaklı dosyalarda ihbar çoğu zaman bir hesap, e-posta, telefon numarası, IP adresi veya bulut bağlantısı üzerinden gelir. Ancak “hesap kimin?” sorusu ile “yükleme fiilini kim yaptı?” sorusu aynı değildir. Bir Google hesabı kişiye ait olabilir; fakat olay tarihindeki upload işlemi:
- üçüncü kişi oturumundan,
- ele geçirilmiş hesaptan,
- eski cihazdan,
- Drive for desktop istemcisinden,
- otomatik senkron klasöründen,
- başka cihazdaki açık oturumdan,
- yetkilendirilmiş uygulama / OAuth token üzerinden
tetiklenmiş olabilir.
Bu nedenle sağlıklı bir TCK 226 savunması için dosyada mutlaka şu zincir aranmalıdır: hash listesi + upload timestamp + UTC uyumu + login IP + upload IP + user-agent + device ID/device fingerprint + session token/OAuth kaydı + klasör yolu + erişim/yeniden adlandırma/paylaşım hareketleri. Bu zincir yoksa, hesap aidiyetinden kişisel fail-atfına sıçramak teknik olarak aceleci, hukuken eksik olur.
1.4 Yargıtay Ceza Genel Kurulu’nun çizgisi: fiilî egemenlik ve sistematik depolama
Yargıtay Ceza Genel Kurulu’nun 24.03.2015 tarihli, 2014/603 E., 2015/66 K. sayılı kararında TCK 226 bağlamında “bulundurma” tartışılırken; suç konusu ürün üzerinde fiilî egemenlik, uzun süre içerisinde ve kasten sistematik biçimde depolama/bulundurma gibi ölçütler üzerinde durulduğu görülmektedir. Bu karar, kişisel amaçla dahi olsa kasıtlı ve sistematik depolamanın suç oluşturabileceğini gösterdiği gibi, her teknik veri kalıntısının otomatik biçimde aynı kefeye konulamayacağını da savunma bakımından güçlü şekilde ortaya koyar.
Bu içtihadın savunmaya verdiği anahtar şudur: Sistematik arşiv yoksa, iradi klasörleme yoksa, tekrar erişim yoksa, paylaşım/yayma izi yoksa, sadece teknik varlık üzerinden “bilinçli depolama” sonucu kurulamaz. Özellikle tekil veri, geri çağırma/carving çıktısı, geçici dosya, senkron kalıntısı, ortak cihaz veya çoklu oturum ihtimali bulunan dosyalarda mahkemenin delil standardı yükseltilmelidir.
1.5 Uygulama tecrübesi: Teknik savunma mahkemeyi dosyanın gerçek merkezine çeker
İzmir, Muğla, Bursa, Aydın ve Samsun hattında görülen takip ettiğimiz benzer nitelikteki NCMEC, TCK 226/3, dijital delil ve bulut depolama dosyalarında en etkili sonuçlar, soyut inkârla değil; dosyanın teknik omurgasını hedef alan savunmalarla alınmıştır.
Mahkeme, “yasaklı içerik var mı?” sorusundan çıkarılıp “bu içerik hangi mekanizma ile, hangi IP’den, hangi cihazdan, hangi oturumla, hangi iradeyle oluştu?” sorusuna yöneltildiğinde dosyanın gerçek ispat problemi görünür hale gelir.
Bu nedenle güçlü bir bilişim suçları avukatı savunması, yalnızca “müvekkilim yapmadı” demez; dijital isnadın yapı taşlarını tek tek söker: CMK 134 imaj alma usulü, hash bütünlüğü, IP/port eşleştirmesi, Google güvenlik logları, NCMEC rapor tercümesi, senkron klasörleri, cache/thumbnail analizi ve adli bilişim bilirkişi raporu.

2) Google Drive: Otomatik Senkron mu, Otomatik Yedekleme mi, Üçüncü Cihaz mı?
2.1 Google Drive pasif klasör değildir; çoklu cihazlı bir senkronizasyon ekosistemidir
Google Drive, klasik anlamda sadece “kullanıcının dosya seçip yüklediği” pasif bir internet klasörü değildir. Google’ın resmi Drive for desktop açıklamalarına göre senkronizasyon, buluttaki dosyaların bilgisayara indirilmesi ve bilgisayardaki dosyaların buluta yüklenmesi sürecidir; bir konumdaki düzenleme, silme veya taşıma işlemi diğer konuma da yansıyabilir.
Google Workspace yöneticileri için açıklanan ayarlarda ise yerel klasörlerin Drive’a senkronize edilmesine, My Drive’ın mirror sync ile eşitlenmesine ve USB, kamera, telefon gibi harici medyadan dosya/klasör yedeklenmesine izin verilebildiği belirtilmektedir.
Bu teknik gerçek, savunma bakımından çok önemlidir. Çünkü bir dosyanın Google Drive’da görünmesi, onun mutlaka kullanıcı tarafından tek tek seçilip manuel olarak yüklendiği anlamına gelmez. Dosya;
- bilgisayardaki eşitlenen klasörden,
- eski telefondaki açık oturumdan,
- Drive for desktop istemcisinden,
- harici medya yedeklemesinden,
- Photos/Drive ilişkili yedekleme davranışından,
- üçüncü cihazdaki arka plan senkronundan,
- hesabı kullanan başka bir oturumdan
buluta düşmüş olabilir.
2.2 Login IP ile upload IP ayrımı: Savunmanın teknik kırılma noktası
NCMEC ihbarı veya Google Drive depolama iddiasında en kritik ayrımlardan biri login IP ile upload IP ayrımıdır. Hesaba bir IP’den giriş yapılmış olması, isnat konusu dosyanın aynı IP’den yüklendiğini göstermez. Upload işlemi başka bir cihazdan, başka bir oturumdan, başka bir ağdan veya otomatik senkronizasyon hizmetinden tetiklenmiş olabilir. Bu nedenle Google’dan yalnızca “hesaba giriş kayıtları” değil, özellikle şu kayıtlar istenmelidir:
- dosya bazlı upload event kayıtları,
- upload IP adresi,
- login IP adresleri,
- user-agent bilgisi,
- device list / trusted devices,
- session ID / token,
- OAuth yetkilendirilmiş uygulama bilgisi,
- last modified / created / timestamps,
- folder path,
- share/link activity,
- move/rename/delete history,
Bu kayıtlar gelmeden “Drive’da var = sanık yükledi” denilemez. Çünkü dijital delilde ispat, sonuca değil, olayın oluş mekanizmasına dayanır. İşin aslında işbu tipten savunmaları mahkeme nezdinde aktarmak da bir hayli zorludur. Teknik ibareler, uzman bilirkişi raporları olmadan genelde zayıf kalmaktadır.
2.3 Otomatik senkronizasyon ile bilinçli depolama birbirinden nasıl ayrılır?
Bir dosyanın bilinçli depolandığını gösteren tipik artefact’lar vardır. Örneğin dosyanın özel isimle yeniden adlandırılması, belirli bir klasöre taşınması, klasörlenmesi, sık kullanılanlara alınması, farklı diske kopyalanması, paylaşım linki üretilmesi, tekrar tekrar görüntülenmesi, aynı içeriklerin seri biçimde arşivlenmesi gibi bulgular, kullanıcı iradesini tartışmaya açabilir.
Buna karşılık şu bulgular otomatik senkronizasyon ihtimalini güçlendirir:
- dosyanın Downloads, DCIM, WhatsApp Media, Telegram, temp/cache gibi dizinlerden gelmesi,
- dosya adının sistemsel ve anlamsız olması,
- klasörleme veya yeniden adlandırma bulunmaması,
- görüntüleme/açma artefact’ı olmaması,
- aynı anda çok sayıda ilgisiz dosyanın buluta düşmesi,
- last modified ile upload timestamp arasında teknik uyumsuzluk,
- hesaba bağlı birden fazla cihaz bulunması,
- security event kayıtlarında olağandışı oturum görünmesi,
- Drive for desktop veya benzeri istemci üzerinden toplu senkron gerçekleşmesi.
Bizlerin bu tipten savunmalarda yoğun tecrübe edindiğimiz; işte bu yüzden mahkeme, Google Drive otomatik senkronizasyon, otomatik yedekleme, üçüncü cihaz, hesap ele geçirilmesi ve senkron klasörü ihtimallerini adli bilişim bilirkişisine incelettirmeden “bilinçli depolama” sonucuna varmamalıdır.
2.4 Üçüncü cihaz ve eski oturum ihtimali: Hesap aidiyetini zayıflatan teknik alan
Bulut dosyalarında sık görülen önemli bir ihtimal de, olay tarihindeki aktif işlemin sanığın fiilen kullandığı cihazdan değil, daha önce hesaba bağlanmış başka bir cihazdan kaynaklanmasıdır. Eski telefonlar, ikinci el cihazlar, aile bilgisayarları, ortak laptoplar, işyeri bilgisayarları, tabletler, Drive for desktop kurulu eski sistemler veya açık kalmış tarayıcı oturumları bu açıdan kritik önemdedir.
Bu nedenle bilirkişiye yalnızca “hesap sanığa ait mi?” sorusu sorulamaz. Doğru soru şudur: İsnat konusu dosya, olay tarihinde hangi cihazdan, hangi oturumla, hangi IP’den, hangi klasör yolundan ve hangi işlem tipiyle buluta düşmüştür?
Bu soru cevaplanmadığında, dosya bir ceza muhakemesi dosyası olmaktan çıkar; teknik varsayımlar üzerine kurulan bir kanaat dosyasına dönüşür. CMK 134’ün bilgisayar, program ve kütüklerinde arama-kopyalama-el koyma için özel güvenceler öngörmesi de tam olarak bu sebeple önemlidir; dijital delil, ancak izlenebilir, denetlenebilir ve savunmaya açık bir yöntemle anlam kazanır.
3) NCMEC Raporu Başlangıçtır; Google Logları ve Bilirkişi Raporu Tamamlayıcı İspat Alanıdır
3.1 NCMEC/CyberTipline ihbarı “kesin fail tespiti” değil, soruşturma başlangıcıdır
NCMEC/CyberTipline raporu, TCK 226/3 kapsamında yürütülen çocuk müstehcenliği soruşturmalarında çoğu zaman dosyanın ilk teknik dayanağı olarak karşımıza çıkar. Ancak bu raporun doğru konumlandırılması gerekir: NCMEC raporu, Türk ceza muhakemesi anlamında hükme esas alınabilecek nihai bilirkişi raporu değil; çoğunlukla servis sağlayıcı bildirimi üzerine oluşan teknik ihbar ve yönlendirme bilgisidir.
Bu nedenle savunmanın ilk cümlesi çok net olmalıdır: NCMEC bildirimi dosyayı başlatabilir; ancak tek başına “kim yükledi, hangi cihazdan yükledi, hangi IP ile yükledi, içeriği bilerek mi depoladı?” sorularını cevaplamaz.
TCK 226/3 gibi ağır sonuçlar doğuran bir suç isnadında mahkeme, yalnızca rapor numarası veya hesap bağlantısıyla yetinmemelidir. Çünkü ceza yargılamasında mesele “bir içerik var mı?” değil; o içeriğin sanıkla, kastla, bilinçli depolama iradesiyle ve hukuka uygun dijital delil zinciriyle ilişkilendirilip ilişkilendirilemediğidir.
3.2 Google logları olmadan “hesap aidiyeti” fail-atfına dönüşemez
Google Drive, Gmail, Google Photos veya Drive for desktop kaynaklı dosyalarda savunmanın temel hedefi, iddianın teknik omurgasını görünür hale getirmektir. Bir Google hesabının sanıkla ilişkilendirilmesi, o hesaptaki her yükleme işleminin sanık tarafından yapıldığını ispatlamaz. Bu noktada mahkemeye şu ayrım özellikle anlatılmalıdır:
- Account holder başka şeydir.
- User/session başka şeydir.
- Uploader başka şeydir.
- Manual upload yapan kişi başka şeydir.
- Otomatik senkronizasyonu tetikleyen cihaz başka şeydir.
Google’dan gelecek ham loglar olmadan bu kavramların tamamı birbirine karışır. Savcılık makamı çoğu zaman “hesap sanığa ait, o hâlde dosya da sanığın bilinçli depolamasıdır” şeklinde özet bir mantık kurabilir. Oysa bu mantık, özellikle NCMEC raporu, Google Drive senkronizasyonu, IP kayıtları, CGNAT, upload timestamp ve cihaz oturumu gibi alanlar araştırılmadan teknik olarak tamamlanmış sayılamaz.
3.3 Bilirkişi raporu savunmanın teknik tercümanıdır
Bu dosyalarda adli bilişim bilirkişisi yalnızca “cihazda ne var?” sorusuna cevap vermemelidir. Asıl bilirkişi incelemesi şunu çözmelidir:
Dosya, kullanıcı iradesiyle mi depolanmış; yoksa Google senkronizasyonu, otomatik yedekleme, üçüncü cihaz, eski oturum, cache/temp artefact veya hesap ele geçirilmesi ihtimaliyle mi oluşmuştur?
Bu nedenle alınacak bilirkişi raporu sıradan bir “imaj raporu” değil; olay zinciri raporu olmalıdır. Raporda özellikle şu alanlar ayrıştırılmalıdır:
- manual upload mı, auto-sync mi,
- login IP ile upload IP aynı mı,
- upload sırasında kullanılan user-agent nedir,
- cihaz listesinde hangi cihazlar vardır,
- OAuth/token üzerinden üçüncü uygulama erişimi var mıdır,
- dosyalar açılmış, izlenmiş, yeniden adlandırılmış veya paylaşılmış mıdır,
- hash değerleri NCMEC tipindeki dosyalarla birebir örtüşmekte midir,
- zaman damgalarında UTC/yerel saat uyumu var mıdır,
- IP public/statik/dinamik/CGNAT ayrımı yapılmış mıdır.
Bu düzeyde inceleme yapılmadan, dosyada yalnızca “bulutta göründü” veya “hesapla ilişkilendirildi” denilmesi mahkûmiyet standardına ulaşmaz.
3.4 Mahkemeye bu teknik meseleyi sunabilme kabiliyeti dosyanın seyrini değiştirir
NCMEC ve TCK 226/3 dosyalarında etkili savunma, yalnızca kanun maddesi zikretmekten ibaret değildir. Bu dosyalarda avukatın asıl fonksiyonu, teknik veriyi mahkemenin anlayabileceği açık bir ceza muhakemesi diline çevirmektir. İyi ve etkin hazırlanmış bir savunma, mahkemeye şu kabiliyeti sunar:
- NCMEC raporunun sınırlarını gösterir.
- Google loglarının neden zorunlu olduğunu anlatır.
- IP/port/timestamp zincirini sadeleştirir.
- CGNAT riskini somutlaştırır.
- CMK 134 kapsamında dijital delil zincirini denetlenebilir hale getirir.
- Bilirkişiye sorulacak soruları teknik ama anlaşılır şekilde kurar.
- “Dijital iz” ile “bilinçli depolama” arasındaki hukuki farkı mahkemenin önüne koyar.
İzmir, Muğla, Aydın, Bursa ve Samsun hattında takip ettiğimiz benzer dijital delil dosyalarında görülen temel gerçek şudur: Mahkeme, teknik meseleyi doğru formüle eden savunmayı dikkate alır. Çünkü iyi savunma, soyut inkâr üretmez; araştırılması gereken eksik halkaları tek tek gösterir.

4) Somut Savunma Dili: Mahkemeye Sorulacak Esas Sorular
4.1. NCMEC raporu gerçekten ne söylüyor?
Mahkemeye ilk sorulması gereken soru, NCMEC raporunun gerçekte hangi teknik iddiayı içerdiğidir. Çünkü bu raporlarda kullanılan her ifade, fail-atfı bakımından farklı anlam taşır.
Mahkemeye yöneltilecek sorular
- NCMEC raporunun tam nüshası dosyada mevcut mudur?
- Raporda yalnızca özet bilgi mi vardır, yoksa teknik ekler de dosyaya kazandırılmış mıdır?
- Rapora konu dosyaların hash değerleri nelerdir?
- Dosyaların isimleri, boyutları, formatları ve yükleme zamanları açıkça gösterilmiş midir?
- Raporda “uploaded” mı denilmektedir, yoksa “associated with account” gibi daha sınırlı bir ifade mi kullanılmaktadır?
- “Reported by provider” alanında hangi servis sağlayıcı hangi olayı bildirmiştir?
- Rapor, hesabın sahibini mi göstermektedir, yoksa yükleme yapan cihaz/oturumu mu?
- NCMEC raporunun hukukçu İngilizce tercümesi yapılmış mıdır?
- Tercümede “apparent”, “suspected”, “associated”, “user”, “account holder”, “upload” gibi teknik kelimeler doğru çevrilmiş midir?
Savunma açısından sonucu
NCMEC raporu tam olarak okunmadan, raporun teknik alanları Türkçe hukuk diline doğru çevrilmeden ve hash/dosya eşleşmesi yapılmadan, bu rapora “kesin suç delili” muamelesi yapılamaz.
4.2. Google’dan hangi loglar istenmiştir?
NCMEC kaynaklı Google Drive dosyalarında en kritik delil, çoğu zaman cihazda değil, Google sunucu tarafındaki loglarda saklıdır. Bu nedenle mahkemeye yalnızca mevcut cihaz incelemesine bakılmasının yetersiz olduğu anlatılmalıdır.
Mahkemeye yöneltilecek sorular
- Google’dan login logları istenmiş midir?
- Upload event kayıtları istenmiş midir?
- Dosya bazlı upload IP kayıtları dosyaya gelmiş midir?
- Login IP ile upload IP karşılaştırılmış mıdır?
- Hesapta olay tarihinde hangi cihazlar aktif görünmektedir?
- User-agent bilgileri dosyada var mıdır?
- Session ID, token veya OAuth erişim kayıtları incelenmiş midir?
- Hesapta yetkilendirilmiş üçüncü parti uygulama var mıdır?
- Dosyaların Drive’a hangi klasör yolundan düştüğü belirlenmiş midir?
- Dosyalar manuel olarak mı yüklenmiş, yoksa Drive for desktop / mobil senkron / otomatik yedekleme üzerinden mi sisteme girmiştir?
- Dosyalar daha sonra açılmış, görüntülenmiş, yeniden adlandırılmış, taşınmış veya paylaşılmış mıdır?
Savunma açısından sonucu
Google logları gelmeden, yalnızca hesabın adı veya telefon numarası üzerinden bilinçli depolama sonucu kurulamaz. Mahkûmiyet için “hesap ilişkisi” değil, dosya bazlı olay zinciri gerekir.
4.3. IP kaydı gerçekten kişiyi mi gösteriyor, yoksa sadece bağlantı noktasını mı?
IP verisi, dijital dosyalarda en çok yanlış yorumlanan delil türlerinden biridir. “IP çıktı” denilmesi, tek başına kişinin o eylemi yaptığı anlamına gelmez. Özellikle CGNAT, dinamik IP ve ortak ağ kullanımında IP kaydı mutlaka teknik olarak çözülmelidir.
Mahkemeye yöneltilecek sorular
- Tespit edilen IP statik IP midir?
- Dinamik IP ise olay tarih-saatinde kime tahsis edilmiştir?
- Public IP midir?
- CGNAT kullanımı var mıdır?
- CGNAT varsa port numarası dosyada mevcut mudur?
- Port numarası yoksa aynı public IP’yi aynı anda kaç abone kullanıyor olabilir?
- Timestamp UTC mi, Türkiye yerel saati mi?
- Servis sağlayıcı loglarıyla Google timestamp’leri arasında saat uyumu kurulmuş mudur?
- IP tahsis başlangıç ve bitiş zamanı dosyada mevcut mudur?
- Upload anındaki IP ile hesaba giriş IP’si aynı mıdır?
- Wi-Fi ortak kullanımı, aile bireyi, misafir erişimi, işyeri/açık ağ veya modem paylaşımı ihtimali araştırılmış mıdır?
Savunma açısından sonucu
Statik/dinamik/public/CGNAT ayrımı yapılmadan, port ve timestamp eşleştirmesi kurulmadan IP verisi kişi-atfı için yeterli kabul edilemez. Bu araştırma yapılmadan “IP sanığa çıktı” denilmesi teknik olarak eksik bir değerlendirmedir.
4.4. Dosya bilinçli olarak mı saklandı, yoksa otomatik senkronizasyon sonucu mu oluştu?
TCK 226/3 bakımından “bulundurma/depolama” iradi bir davranış gerektirir. Google Drive senkronizasyonu, otomatik yedekleme ve çoklu cihaz yapısı bu nedenle mutlaka incelenmelidir.
Mahkemeye yöneltilecek sorular
- Dosya manuel upload ile mi yüklenmiştir?
- Drive for desktop kurulu mudur?
- Drive hangi klasörleri senkronize etmektedir?
- Downloads, Desktop, DCIM, WhatsApp Media, Telegram veya benzeri klasörler senkron kapsamında mıdır?
- Dosya adı sistemsel midir, kullanıcı tarafından değiştirilmiş midir?
- Dosya bir klasöre özellikle yerleştirilmiş midir?
- Dosyanın açıldığına veya izlendiğine dair artefact var mıdır?
- Thumbnail, preview, cache veya temp file kalıntısı ihtimali değerlendirilmiş midir?
- Dosya aynı anda çok sayıda başka dosyayla birlikte mi yüklenmiştir?
- Upload zamanı ile dosyanın oluşturulma/değiştirilme zamanı uyumlu mudur?
- Eski cihaz veya üçüncü cihaz senkronu ihtimali incelenmiş midir?
- Hesap olay tarihinde başka bir cihazda açık mıdır?
Savunma açısından sonucu
Bilinçli depolama iddiası, dosyanın sadece bulutta görünmesiyle değil; kullanıcının o dosya üzerinde bilerek tasarruf ettiğini gösteren artefact’larla ispatlanmalıdır. Bu artefact’lar yoksa, otomatik senkronizasyon ihtimali çürütülmeden mahkûmiyet kurulamaz.
4.5. Hesap ele geçirilmesi ihtimali teknik olarak araştırılmış mıdır?
NCMEC raporu ve Google hesabı dosyalarında hesap ele geçirilmesi savunması, basit bir inkâr gibi görülmemelidir. Günümüzde hesaplar phishing, veri sızıntısı, zararlı yazılım, sahte giriş ekranı, güvensiz VPN, token hırsızlığı veya açık oturumlar yoluyla ele geçirilebilmektedir.
Mahkemeye yöneltilecek sorular
- Olay tarihinde olağandışı giriş uyarısı var mıdır?
- Hesapta şifre değiştirme veya şifre sıfırlama denemesi var mıdır?
- Recovery e-posta veya recovery telefon değişikliği olmuş mudur?
- Hesapta aile grubu, cihaz yetkilendirme veya güvenlik ayarı değişikliği var mıdır?
- Aynı tarihte hesabın askıya alınması veya devre dışı bırakılması söz konusu mudur?
- Farklı şehir/ülke/IP üzerinden erişim var mıdır?
- Hesapta tanınmayan cihaz oturumu görünmekte midir?
- Google security events dosyaya getirtilmiş midir?
- Hesap kurtarma başvuruları incelenmiş midir?
- Kullanıcı, olaydan hemen sonra hesaba erişim sorunu yaşamış mıdır?
Savunma açısından sonucu
Hesap güvenliği araştırılmadan, hesabın kontrolünün olay tarihinde kimde olduğu söylenemez. Hesap aidiyeti ile hesap üzerindeki fiilî kontrol birbirinden ayrılmadan fail-atfı kurulamaz.
4.6. CMK 134 kapsamında imaj alma ve inceleme usulü sağlıklı mıdır?
Dijital delil, ancak hukuka uygun yöntemle elde edilip denetlenebilir biçimde raporlandığında hükme esas alınabilir. Bu nedenle CMK 134 incelemesi şeklen değil, içerik ve yöntem bakımından sorgulanmalıdır.
Mahkemeye yöneltilecek sorular
- Dijital materyaller hangi karara dayanılarak incelenmiştir?
- İmaj alma yöntemi nedir: logical mı, file system mi, full physical mı?
- İmaj hash değeri alınmış mıdır?
- İnceleme öncesi ve sonrası hash doğrulaması yapılmış mıdır?
- Yedek kopya sanığa veya müdafie verilmiş midir?
- İnceleme raporu ham extraction loglarını içeriyor mu?
- Raporda yalnız sonuç mu var, yoksa analiz edilen artefact’lar ayrıntılı mı?
- Dosya carving yapıldıysa silinmiş/parçalı veriler ayrıştırılmış mıdır?
- Raporda çocuk içerikli dosyanın cihazda fiilen bulunduğu mu, yoksa yalnız hesap/hat bağlantısı mı tespit edilmiştir?
- Cihaz, hat, IMEI, hesap ve tutanak zinciri kesintisiz midir?
Etkin savunmanın sonucu: Teknik belirsizlik mahkûmiyet değil, araştırma sebebidir
Bu dosyalarda savunmanın ana cümlesi şu olmalıdır:
“Dijital sistemde görünen dosya ile sanığın bilinçli depolama kastı arasında; upload IP, oturum kaydı, cihaz kimliği, hash-zaman damgası uyumu, kullanıcı davranışı ve senkronizasyon mekanizmasıyla kurulmuş kesin bir bağ bulunmadıkça TCK 226/3 kapsamında mahkûmiyet standardı oluşmaz.”
İzmir, Muğla ve Samsun’da takip edilen benzer dijital delil dosyalarında görülen temel pratik şudur: Mahkeme, NCMEC raporunu veya bulut kaydını tek başına nihai delil gibi değil; ancak adli bilişim incelemesiyle doğrulanması gereken bir başlangıç verisi olarak ele aldığında savunma alanı genişler. Özellikle Google Drive senkronizasyonu, otomatik yedekleme, üçüncü cihaz ihtimali, IP/port/timestamp eşleştirmesi ve CMK 134 delil zinciri somutlaştırıldığında, dosyanın gerçek hukuki ağırlığı ortaya çıkar.
Bu nedenle iyi hazırlanmış bir savunma, yalnızca “içeriği kabul etmiyoruz” düzeyinde kalmamalıdır. Savunma; Google loglarını, NCMEC raporunun tercümesini, CMK 134 usulünü, IP kayıtlarını, CGNAT/port ayrımını, hash değerlerini, UTC uyumunu, senkron klasörlerini ve bilirkişi raporunu aynı anda masaya koymalıdır. Çünkü bu dosyalarda beraat veya mahkûmiyet arasındaki çizgi çoğu zaman tek bir cümlede saklıdır:
Ceza hukuku, dijital görünümü değil; kastla birleşmiş, kişiselleştirilmiş ve teknik olarak doğrulanmış fiili cezalandırır.
Avukat Önal’ın Benzer Mahiyette Yüzlerce Çalışmasından Çok Okunan Beşi
| Sıra | Yazı | Neden Çok Okunuyor? | Dava Açısından Kullanım |
|---|---|---|---|
| 1 | NCMEC: Instagram / Facebook / Telegram / X Kaynaklı Suçlar | Meta, Instagram, Facebook, Telegram, TCK 103, TCK 105, TCK 226 ve dijital delil başlıklarını tek yazıda topladığı için en geniş kapsama sahip yazılardan biri. | Yeni yazılarda “NCMEC + sosyal medya + suç vasfı + dijital delil” ana omurgasına ana iç bağlantı olarak kullanılmalı. (orhanonal.av.tr) |
| 2 | NCMEC İhbarı; Instagram-Facebook Çocukla Mesajlaştı İddiası | “Çocukla mesajlaştı” iddiasında TCK 105, yaş bilgisi, Meta login-log, IP, cihaz ve dijital isnat zinciri bakımından çok nokta atışı duruyor. | Ekran görüntüsü, hesap aidiyeti, mesajlaşmanın bağlamı ve yaş hatası başlıklarında mutlaka iç link verilmeli. (orhanonal.av.tr) |
| 3 | Siber Suçlarda CMK 134 İhlali: İmaj, Hash, Tutanak, Beraat | İmaj, hash, tutanak, hukuka aykırı delil ve beraat hattını doğrudan kurduğu için teknik savunma yazılarının omurgası olmaya çok uygun. | “İmaj, hash ve delil bütünlüğü” başlığının altına en güçlü teknik iç bağlantı olarak eklenmeli. (orhanonal.av.tr) |
| 4 | NCMEC Raporu ile TCK 105 Davasında Beraat Savunması | Çok güncel ve doğrudan “TCK 105 + NCMEC + beraat savunması” odağında. Okuyan kişide dosya özelinde hukuki yardım alma ihtiyacı doğurabilecek başlıklardan. | Cinsel taciz, çocukla mesajlaşma, dijital isnat ve mağdur beyanı eksenli içeriklerde öne çıkarılmalı. (orhanonal.av.tr) |
| 5 | NCMEC CyberTipline; Dijital Çağın En Kritik Delil Zinciri | CyberTipline, hash doğrulama, CGNAT, kişisel cihazların kötüye kullanımı ve NCMEC raporunun delil zinciri içindeki yerini anlattığı için ana “otorite yazı” gibi konumlandırılabilir. | “NCMEC raporu tek başına mahkûmiyet değildir” temasında güçlü ana referans olarak kullanılmalı. (orhanonal.av.tr) |

- 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 ve dijital cinsel suçlar* 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:00Cumartesi: 10:00 – 18:00Telefon: +90 532 282 25 23Gizlilik
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.
-

Leave A Comment