Principen bakom att ändra filhash
Typiska kryptografiska hashar är bland annat MD5, SHA-1/256 osv. Den centrala egenskapen i utformningen av kryptografiska hashfunktioner är "lavineffekten" – minsta lilla förändring i indata leder till en stor förändring i utdata. Det betyder att även om bara en enda byte ändras blir hela hashvärdet helt annorlunda. Till exempel: om du har skrivit ett dokument på 2000 ord och sparat det som en Word-fil, räcker det att ändra ett enda tecken, till exempel lägga till ett mellanslag, för att filens md5 ska förändras helt. Därför är kärnan i att “ändra en fils hash” att ändra själva filinnehållet, inte externa attribut som filnamnet. Denna egenskap gör det relativt enkelt att ändra hash på filnivå.
Olika system och format definierar “metadata” på olika sätt: om metadata är inbäddade i filens data (till exempel taggar i JPEG-/videobehållare) ändras hashen när de ändras; om metadata lagras i filsystemets externa dataströmmar eller attribut påverkar en ändring inte hashen som beräknas utifrån filinnehållet. Detta förklarar det vanliga fenomenet att “ändrat filnamn inte ändrar hashen, men ändrade inbäddade metadata gör det”.
Videoplattformars omkodning och “identifiering av om hashen har ändrats”
När en användare laddar upp en video till en videoplattform kommer plattformen att utföra följande på videon:
Ta emot originalfilen
Formatkontroll och validering
Omkodningsbehandling (formatkonvertering, justering av upplösning, komprimering)
Extrahering av nyckelbilder
Hashberäkning i flera lager
Detta är en omkodningspipeline med “demuxning → avkodning → bearbetning → omkodning → muxning” för att skapa flera versioner med olika bithastigheter/upplösningar för adaptiv uppspelning. Själva processen förändrar filens bytesekvens och alla kryptografiska hashar från före uppladdningen.
På filhashnivå: plattformen genererar om filen under omkodningen, vilket gör att den ursprungliga filhashen naturligt förändras. Därför saknar den filhash som användaren ändrat i förväg betydelse efter omkodningen. Plattformen kommer alltså inte att försöka identifiera om den här filens md5 eller liknande har ändrats, eftersom det inte har någon mening!
Steg för deduplicering/upphovsrättskontroll bygger inte på uppladdarens filhash, utan på att plattformen beräknar egna “ljud- och videofingeravtryck/perceptuella hashar” på det avkodade innehållet och jämför dem med referensfingeravtryck i databasen. Till exempel “fingeravtrycker” YouTubes Content ID uppladdat innehåll och matchar det mot referenser som rättighetsinnehavare har tillhandahållit.
Därför handlar det inte om att plattformen “identifierar att hashen har ändrats”, utan om att den “ignorerar uppladdningshashen, beräknar om innehållsfingeravtrycket och matchar det”. Det gör att det inte går att kringgå innehållsbaserad detektering enbart genom att ändra filens bytes eller behållarens metadata för att ändra MD5/SHA.
