- YouTube, reklam engelleyen kullanıcılarda reklam göstermek yerine video başlamadan önce sahte buffering gibi görünen bir gecikme uygulayan yöntemi A/B testi kapsamında deniyor
- Gecikme, SABR akışındaki backoff ile uygulanıyor ve InnerTube, ilk içerik
/videoplayback isteğine reklam süresinin %80'i kadar beklenmesi gerektiğini söyleyen bir yanıt veriyor
- Reklam engellemeyen kullanıcılarda reklam oynarken içerik yüklemesi sürdüğü için aynı backoff olsa bile gecikme neredeyse hissedilmiyor
isInlinePlaybackNoAd değeri true olarak ayarlanırsa InnerTube reklam sunmuyor; böylece GVS akışındaki backoff da ortadan kalkıyor ve ilgili atlatma yöntemi uBlock Origin'in varsayılan filtre listesine eklenmiş durumda- YouTube, bazı deneylerde
JSON.stringify gibi global nesneleri kilitleyen bir locker script ile filtre kancalarını engelliyor; Chromium'da ise Object.assign kancasıyla bu durum aşılabiliyor
Sahte buffering'in ortaya çıktığı nokta
- YouTube son birkaç aydır yeni reklam engelleyici karşıtı önlemleri A/B testiyle deniyor
- Gözlemlenen önlemlerden biri, yalnızca video başlangıcında görülen sahte buffering
- Videonun ortasında ortaya çıkmıyor
- Gecikme süresi, normalde izlenecek reklam süresinin %80'i kadar
- Reklam engelleyici kullanılsa da reklamın tamamını izlemekten yine de zaman kazandırıyor
- Örnekler şöyle
- 15 saniyelik reklam varsa 12 saniyelik backoff oluşuyor
- Atlanamayan 6 saniyelik reklam ile 15 saniyelik reklam birlikte varsa 16,8 saniyelik backoff oluşuyor
InnerTube, GVS ve SABR'ın rolleri
- InnerTube, YouTube web istemcisi ile mobil uygulamaların video bilgisi ve ayrıntılı verileri aldığı dahili API
- GVS, YouTube, Google Drive ve Google Photos için video akışı sağlayan Google Video Services
- GVS üzerinden video akışı yapmak için InnerTube veya Drive/Photos dahili API'sinden
/videoplayback URL'si alınması gerekiyor
- GVS URL'leri imzalı ve genellikle 6 saatlik son kullanma süresine sahip olduğu için doğrudan üretilemiyor
- ISP'ler, Google Global Cache sunucularını kendi altyapılarında barındırarak YouTube trafiğini ISP ağı dışına çıkarmadan sunabiliyor
- GGC yalnızca herkese açık veya kısmen herkese açık YouTube videolarını sunuyor; özel YouTube videoları ile Drive/Photos videoları ise her zaman Google veri merkezlerinden sunuluyor
- YouTube web istemcisi eskiden, gerekli video aralığını GVS URL'sinin sorgu parametreleriyle belirterek akış yapıyordu
- Sonrasında YouTube SABR kullanmaya başladı
- SABR, Server ABR yani sunucu taraflı uyarlanabilir bitrate için YouTube'a özgü ikili protokol
- MPEG-DASH gibi açık biçimlere kıyasla buffering'i daha iyi önleyecek şekilde tasarlandı
- Sunucu, istemciye video/ses verisi göndermek yerine belirli bir süre bekleyip yeniden denemesini söyleyen bir backoff gönderebiliyor
backoff, reklam engelleyici tespitinden bağımsız uygulanıyor
- Sahte buffering, InnerTube'un ilk içerik
/videoplayback isteğine reklam süresinin %80'ine karşılık gelen backoff içeren bir GVS akışı vermesiyle ortaya çıkıyor
- Hedef, reklam akışı değil içerik video akışı
- Reklam ve içerik akışları hâlâ ayrı
- Bu, sunucu taraflı reklam ekleme değil; YouTube'un sunucu taraflı reklam ekleme denemeleri ayrıca sürüyor
- “Experiencing interruptions” iletişim kutusu muhtemelen GVS'deki uzun backoff nedeniyle tetikleniyor
- Kullanıcı A/B test grubundaysa bu backoff, YouTube'un onu reklam engelleyici kullanıcısı olarak değerlendirip değerlendirmemesinden bağımsız olarak her zaman uygulanıyor
- Reklam engellenmiyorsa web istemcisi reklam oynarken içerik videosunu yüklüyor
- Kullanıcının hissettiği fark, içerik videosu buffering'inin reklam %80 ilerledikten sonra başlaması
- YouTube'un reklam engelleyen kullanıcılarda CPU kullanımını aniden artırarak bilgisayara zarar verdiği yönündeki çevrimiçi iddialar doğru değil
- backoff süresinin dolmasını beklerken YouTube CPU kullanmıyor
- Bekleme spinloop ile uygulanmış olsa bile 30 saniyeden kısa süre tek çekirdeği sonuna kadar kullanmak CPU'ya zarar vermez
isInlinePlaybackNoAd ile reklam sunumunu engelleme yöntemi
- backoff'tan kaçınmak için atlanamayan reklamın bitmesini beklemek yerine reklamın en baştan sunulmamasını sağlamak gerekiyor
- Player isteğindeki
playbackContext.contentPlaybackContext.isInlinePlaybackNoAd özelliği true yapılırsa InnerTube reklam sunmuyor
- Reklam sunulmazsa GVS akışında backoff da yer almıyor
- Web istemcisi sunucu isteği için JSON'u string'e çevirirken
"isInlinePlaybackNoAd":true ekleyen bir filtre kuralı oluşturulabiliyor
www.youtube.com##+js(trusted-replace-outbound-text, JSON.stringify, 'contentPlaybackContext":{', 'contentPlaybackContext":{"isInlinePlaybackNoAd":true,', condition, 'contentPlaybackContext')
isInlinePlaybackNoAd özelliğine frontend JavaScript içinde referans veriliyor- req2proto kullanılarak
/youtubei/v1/player çağrısında kullanılan protobuf tanımları çıkarılabiliyor ve ilgili özellik bulunabiliyor
- YouTube web istemcisi InnerTube ile JSON üzerinden iletişim kursa da bu JSON API, Protocol Buffers tanımlarından üretiliyor
Yalnızca warm navigation'da güvenilir olmasının sınırı
- Bu yöntem yalnızca YouTube tek sayfalık uygulaması zaten yüklendikten sonra içeride tıklanarak gidilen warm navigation durumunda çalışıyor
- İzleme sayfasına doğrudan girilen cold load durumunda YouTube backend'i player yanıtını
ytInitialPlayerResponse olarak doğrudan sayfaya gömüyor
- Player isteği backend'de oluşturulduğu için
isInlinePlaybackNoAd ayarlanamıyor
- cold load'u aşmanın bir yolu, ilk verileri kaldırıp denetlenebilir bir player isteğinin zorla oluşturulmasını sağlamak
www.youtube.com##+js(set, ytInitialData, undefined) ! kötü fikir, aşağıya bakın
www.youtube.com##+js(set, ytInitialPlayerResponse, undefined) ! kötü fikir!
- Bu yaklaşımın yan etkileri büyük olduğu için kullanımı zor
- Canlı yayınları tamamen bozuyor
- Test edilmemiş başka özellikler de bozulabiliyor
- Video oynatıcı kısa süreliğine göz kırpıyor
- Sayfa yükleme süresi yavaşlıyor
locker script ve Chromium atlatma yöntemi
- Filtre bir ölçüde çalışsa da bazen uBlock Origin
JSON.stringify fonksiyonuna kanca atamıyordu
- YouTube bazı A/B testlerinde frontend HTML'in
<head> etiketinin en başına bir locker script ekliyor
- Bu script,
Object.defineProperty ile fetch, JSON, JSON.stringify, JSON.parse, Array, Array.prototype.push, Array.prototype.forEach gibi öğeleri non-writable yapıyor
- Sonrasında gelen kodların
Proxy ile davranışı değiştirmesini engelliyor
- uBlock Origin ancak locker script'ten önce çalışırsa
JSON.stringify için proxy kurabiliyor
- Firefox'ta HTML filter ile sayfa parse edilmeden önce kaynak HTML'den ilgili script etiketi kaldırılabiliyor
- Chromium gerekli uzantı API'sini desteklemediği için aynı yöntem uygulanamıyor
- Mevcut atlatma yöntemi
JSON.stringify yerine Object.assign fonksiyonuna kanca atmak
Object.assign da fetch öncesinde istek gövdesini işleyen bir işlev- Bu, locker script'i etkisizleştirmekten çok onu dolanmak anlamına geliyor
- uBO scriptlet'i nesne anahtarlarında metin değiştirmeye izin vermediği için filtre listesi JavaScript enjekte ediyor
(() => {
const e = {
apply: (e, n, arguments) => {
let t = Reflect.apply(e, n, arguments);
return 3 === arguments.length && t?.body && "string" == typeof t.body && !t.body.includes(`"isInlinePlaybackNoAd":true`) && (t.body = t.body.replace(`"contentPlaybackContext":{`, `"contentPlaybackContext":{"isInlinePlaybackNoAd":true,`)), t
}
};
window.Object.assign = new Proxy(window.Object.assign, e)
})();
- Bu atlatma çalışmasında uAssets bakımcıları da yardımcı oldu
Referanslar
Henüz yorum yok.