MagicMirror Projesi: yerel işlem ve bulut arasında veri gizliliği

MagicMirror Projesi’nde arayüz, yerel komutlar, kalıcı hafıza ve dış hizmet isteklerini ayrı bileşenler halinde geliştirdik. Bu ayrım, her isteğin aynı veri yolunu kullanmasını önlemeyi ve hangi verinin nerede işlendiğini takip etmeyi amaçlıyor. Yazı sürümlü kaynak ve mimari kayıtlarını anlatır; kişisel profil, konuşma, ev görüntüsü veya gerçek cihaz adresi paylaşmaz.

Projede yaptığımız düzenleme

Yerel uyandırma ve kısa komut hattını, etkin görüşme ve dış bilgi isteklerinden ayırdık. Hava ve haber bilgisi için çalışan modüllerin bildirimlerinden alınan önbellekleri kullanan yollar ekledik. Böylece ekranda zaten bulunan veriyi cevaplamak için her seferinde yeni bir dış istek üretmek gerekmiyor. Bu, bütün asistan işlemlerinin çevrimdışı olduğu veya dış hizmete hiçbir veri gitmediği anlamına gelmiyor.

Hafızayı ayrı bir SQLite bileşeninde, görüntü işleme ve kamera isteklerini de ayrı yaşam döngüsünde topladık. Mimari kaydı yerel algılamayla talep üzerine görsel değerlendirmeyi ayırıyor. Kimlik öznitelikleri, anlık kare ve konuşma notunun farklı saklama sınırları bulunuyor; bunların özel içeriği bu seride gösterilmiyor. Aşağıdaki kontroller mevcut tasarımın incelenmesi için; yeni bir cihaz denetimi sonucu olarak sunulmuyor.

Bir özellik listesi yerine veri akışı çıkarın

Bir asistanın yerelde çalışabilen bileşenlere sahip olması bütün verinin cihazda kaldığı anlamına gelmez. Uyandırma girdisi, etkin görüşmenin sesi, konuşmadan çıkarılan not ve görüntü analizi isteği için ayrı satırlar açın. Her satırda üretici bileşen, işleme yeri, aktarım koşulu, alıcı hizmet ve saklama süresi bulunsun. Henüz doğrulanmamış alanları açıkça belirsiz olarak işaretleyin; ürün adından veya kullanılan kütüphaneden güvence çıkarmayın.

Örneğin lab.batuhanyazici.com yalnızca temsili bir hizmet adıdır. Bu adın yazıda kullanılması gerçek bir cihazın internete açık olduğunu göstermez. Yayınlanabilir mimari şemasında da gerçek ağ yolu, cihaz seri numarası ve hesap kimliği yerine işlev adlarını kullanın. Şemanın okura vermesi gereken bilgi, paketin hangi kişiye ait olduğu değil hangi sınırdan geçtiğidir.

1. Girdi türünü belirle
2. Yerel işlemi seç
3. Aktarım ihtiyacını sorgula
4. Gereken en az veriyi gönder
5. Saklama ve silmeyi doğrula

Yerel hafızayı bütün konuşmadan ayırın

Bir hatırlatıcıyı saklamak için bütün görüşmenin ham sesini tutmak gerekmeyebilir. Bu, veri azaltma için değerlendirilecek bir tasarım seçeneğidir; otomatik uygulanmış bir özellik olarak sunulmamalıdır. Hatırlatıcı metni, kaynağı, oluşturulma zamanı ve ilgili profil gibi alanların gerçekten gerekli olup olmadığını tek tek sorgulayın. Misafir kullanımında kalıcı profil oluşturulmasını ayrıca görünür ve anlaşılır bir seçime bağlayın.

Kişi ayrımı yapılan sistemde yanlış eşleşme, başka bir kullanıcının notunun sesli okunmasına dönüşebilir. Kimliği belirsiz oturum için güvenli davranışı baştan tanımlayın: kişisel hafıza sorgusunu durdurmak veya kimlik teyidi istemek gibi. Yüzün görünmesi ya da bir adın söylenmesi bütün hassas işlemler için yeterli yetkilendirme sayılmamalıdır. Paylaşılan ekran ve hoparlör de veri çıkış noktalarıdır.

Dış hizmete aktarımı görünür kılın

Bulut gerektiren işlem başladığında hangi veri türünün gönderileceği kullanıcı tarafından anlaşılabilsin. Genel bir dinleme animasyonu, görüntü aktarımı için açıklama yerine geçmez. Dış hizmetin saklama, kullanım ve hesap ayarları ayrıca incelenmelidir. Yalnızca HTTPS kullanılması aktarımın amacını, veri kapsamını veya alıcıdaki saklama davranışını açıklamaz. OWASP'ın şeffaflık yaklaşımı, verilen gizlilik sözlerinin gerçek uygulama davranışıyla uyumlu olmasını ister.

Kontrollü kabulde gerçek konuşmalar yerine zararsız işaretleyiciler kullanın. Yerel komut, kişisel hafıza isteği ve dış bilgi isteği için ayrı senaryo hazırlayın. Her senaryoda hangi bileşenin çalıştığını ve hangi aktarımın beklendiğini kaydedin. Ağ gözleminin kapsamı ve sınırları yazılı olsun; tek bir testte içerik görülmemesi bütün sistemin veri aktarmadığını kanıtlamaz.

Günlükler ve geri dönüş

Hata kaydında işlem türü, sonuç ve anonim bir ilişkilendirme kimliği çoğu tanılama için başlangıç olabilir. Ham ses, tam konuşma, görüntü, erişim anahtarı ve özel profil ayrıntılarını varsayılan günlük malzemesi yapmayın. OWASP günlükleme rehberi hassas alanların çıkarılmasını, kayıt erişiminin sınırlandırılmasını ve saklama politikasını birlikte ele alır. Maskelemenin yalnızca ekranda değil dosya ve dış izleme hattında da uygulanması gerekir.

Geri dönüş planında yeni dış aktarım özelliğini kapatmak ile önceden gönderilmiş veriyi silmek ayrı işlerdir. Eski yapılandırmayı geri almak karşı taraftaki kopyayı kendiliğinden kaldırmaz. Yerel hafıza, yedek ve hizmet kayıtlarının silme yollarını ayrı doğrulayın. Kabul kaydında doğrulanan sınırları, açık kalan soruları ve test tarihini belirtin; bu mimari anlatımı hukuki uygunluk veya eksiksiz anonimlik garantisine dönüştürmeyin.

Serinin bütün çalışmaları: MagicMirror Projesi.

Nasıl yapılır: ayrıntılı uygulama

Ortam ve ön koşullar: Yerel/bulut veri karar kaydı — Hangi veri sınıfının hangi hizmete gidebileceği kullanıcı tarafından belirlenmiş olmalı.

1. Veri yolunu gerçek modüllerle haritalayın
2. İzinli dış alan şemasını daraltın
3. Backend ve frontend config’ini ayırın
4. İzin, ret ve bağlantı kesintisini kabul edin
5. Saklama ve geri dönüşü doğrulayın

1. Veri yolunu gerçek modüllerle haritalayın

Mikrofon/kamera, yerel tanıma, hafıza, araç köprüsü ve dış servisleri ayrı satırlara ayırın. Her alan için amaç, hedef, saklama ve kullanıcı kararı yazın; her isteği aynı cloud payload’a göndermeyin.

2. İzinli dış alan şemasını daraltın

Aşağıdaki Node/JavaScript fonksiyonu yalnız izinli public intent ve dil alanını seçer; konuşma/kamera/hafıza alanlarını dışa kopyalamaz. Bu bir alan allowlist örneğidir, otomatik PII tespit motoru değildir.

function cloudPayload(input, permission) {
  if (permission !== true) throw new Error("Dış işleme izni yok");
  const allowed = new Set(["weather", "public_news"]);
  if (!input || !allowed.has(input.intent)) throw new Error("Yerel işlem gerekli");
  return { intent: input.intent, language: "tr" };
}
// Kamera, ham konuşma, özel hafıza ve hesap token'ı bu nesneye eklenmez.

3. Backend ve frontend config’ini ayırın

OAuth refresh token/API secret ve özel takvim URL’si backend’in private dosya/secret sağlayıcısında kalır. Tarayıcıya verilen module config ve Network isteklerinde sır bulunup bulunmadığını test hesabıyla inceleyin; ham trafik kaydını yayımlamayın.

4. İzin, ret ve bağlantı kesintisini kabul edin

Cloud izni yokken dış istek oluşmamalı; yerel intent mümkünse yerelde çalışmalı. Dış servis kapalıyken eski private veriyi fallback diye başka sağlayıcıya göndermeyin. Test için yalnız sentetik intent ve mock/veri izi kullanın.

5. Saklama ve geri dönüşü doğrulayın

Hangi log/cache/memory kaydının nerede tutulduğu ve silme yetkisi açık olmalı. Yeni data-route değişikliğini önceki onaylı şemaya dönün; daha önce dışa giden veriyi config geri alındı diye silinmiş saymayın.

Beklenen sonuç: Her veri akışının gerekçesi, izni ve durdurulma yolu bellidir.

Sonuç farklıysa: İzin iptal edildiğinde arka planda kalan aktarımı ayrı inceleyin.

Geri dönüş: Yeni aktarımı kapatıp önceki onaylı yerel akışa dönün.