Jag har varit säker bra länge på att åtminstone kombinationen Google Chrome mot Youtube ej hanterar sessionerna korrekt som instruerat mot webbläsare och som förväntat av normalt beteende. Detta då jag för evigheter sedan råkade ut för exemplet här även om jag misstänkte att jag klickat fel fram eller bakåt. Sedan också bra länge sedan råkade jag ut för det en gång till.
Därefter har jag av och till försökt få tillbaka det igen när jag använder Youtube för att bekräfta. Vidare för metoden inkluderade viss manuell tidskostnad av och till (ej överdrivet) såg jag ett spekulativt kompenserande värde om beteendet ev. skulle visa sig resultera i att Youtube singulerar typ av annonsering till mig till uteslutande de som kan klickas bort efter 4 s (eller endast sidoannonsering).
Att kvalitetsfrågor relaterat Youtube är fallet i delar från rent programmerings-tekniska frågor kan jag förövrigt konstatera enkelt varje gång jag använder tjänsten och jämför prestandan jag får ut från den i relation till de brutal annonserings-stinna ofta bredbands-begränsade teve- och film-streanibgstjänster jag använder. Typiskt där med några sekunders vänte-tid även om något eller ett par extra fönster med rörlig reklam råkar smyga ut sig utan jag dödar dem klarar min tämligen gamla internetdator att utan några som helst problem (nära nog regelmässigt för alla jag använder regelbundet och nästan liga regelmässigt för alla tillfälliga jag använder sökande efter något de vanliga ej har). Youtube kan dock av och till (som jag vill minnas det och konstaterat idag men innan det utan att ha använt Youtube på aktuell kvalitesnivå regelmässigt ofta) medan Youtube på samma kvalitet ger kvalitetsproblem i hur deras lösnign för att visa film körd i Google Chrome fungerar (diskreta små hack i ljud eller mer ovanligt själva bildrutorna: det senare går att komma ifrån genom att av och till ge den tid att arbeta självständigt med filmen stannad medan det första ej så varande säkert en ren onödigt långsam logik helt ovanför själva nedladdningen). Sessionsproblematiken förvånar mig därför inte helt.
Hur konstaterade jag nu sessionsdefekten? Youtube förflyttat visning av film till annan sida nu visande reklam med samma url (vad nu dessa nya saker html och allt annat fyllts på med sedan HTML 1.0 kallas). Jag sätter mig och gör reload på sidan med tidigare tilläggs motivering och går igenom kanske 8 - 15 st filmvisningar.
Reload's förväntade beteende är att sessions-data ska vara bruten relaterat filmen som emellertid innan stod en bit in i det hela. Jag får också filmen visad från start minst två gånger efter passerad reklam. Men så efter några till reload (notera att Chrome ej har back-information om sida innan d.v.s. ingen risk för ńågot fel där).
Vad vi har ovan ska ej vara möjligt att komma tillbaka till. Var det ens fanns i minne eller hårddisk (troligen det första) är anmärkningsvärt i så mycket att fundera över på. Min känsla är att det ej var Youtube som försökte hjälpa mig rätt via någon kvalitetsfunktion också om jag ej vill utesluta detta och om så tror jag ett korrekt lite små imponerande beteende om det nu verkligen skulle fungera mer allmänt utan att ge mer problem än de löser (men jag tvivlar som starkt oerhört på att detta är aktuellt).
Anmärkningsvärt ty data som ej ska finnas som finns måste ha funnits någonstans. Generellt är en möjlighet att applikationen - här Google Chrome - adresserat minne som ej längre är allokerat eller åtminstone minne som ej längre är avsett för funktionen (men tänkbart fortfarande allokerad för applikationen: Programmerande C gör jag själv regelmässigt - ty all C-programmering jag någonsin gjorts är säkerhetsfunktioner och protokoll - egna allokeringsfunktioner för att garantera att inga minnesfel existerar vilket för motsvarande fel som här skulle innebära att minnet fortfarande ligger i applikationen om än åtminstone efter viss tid eller låg-belastning skrivits till noll).
Google Chrome har skapats utifrån målsättningen att visa stöd jämförbara med min allokerings-metodik men bredare berörande också logiken hindra säkerhetsproblem genom inkappsling i själva applikationen.
Det är nu långt ifrån självklart att felbeteendet vi har här har någon som helst säkerhetsrisk som kan realiseras via den eller ens någonsin visar sig under allt normalt surfbeteende.
Emellertid är den viktigaste motivationen för att göra en sådan säkerhetsprioritering aktuell för Google Chrome just filmklipp, musik m.m. data som är oerhört komplext att parsa och ofta inkluderar användning av programvara (kallas det insticksprogram fortfarande?) som kommer från många olika aktörer och som leverantören av webbläsaren ej nödvändigtvis har någon kontroll över. Och är satt vi nu just och reloade sådant data och med visningsstöd från aktören Google i sin realisering Youtube snarare än man kanske hade förväntat sig att se problem först för något för att visa en film man verkligen vill se och har svårt att hitta men anar bara är fylld med allt tänkbart som kan fungera för att få till autosurfande, reklamvisning m.m. dagarna i ända oavsett vad jag surfar på.
Appendix: Hur är det egentligen med det svenska elektroniska nationella ID-kortet?
Både det elektroniska nationella id-kortet, bankernas ID-tjänst, Verified by visa och några till finns ganska som jag vill minnas det tekniskt kompletta artiklar publicerade hos IDG (dåvarande Säkerhet & Sekretess resp. Nätverk och Kommunikation) jag skrev åt dem. Jag tror ett par finns publicerade som helgläsning också på nätet även om man lär få leta bakåt en bit. Mindre troligt just för dom artiklarna men kanske i annan artikel kan jag förövrigt diskuterat säkerhetsdefekter sessionshantering i webbtjänster (jag skulle gissa det: Själva mängden levererat dom åren gör att det mesta man kan diskutera rörande sådant som är tekniskt intressant d.v.s. mer high value som motiverar fler tecken och därmed mer betalt har skrivits och sessionshantering är nu något jag kunnat med början innan IDG så troligen finns någon 25 000 tecken artikel att hitta om det i IDG åtminstone tryckt).
Är verkligen tillstånden som genereras trygga i att vi ej genom vissa typer av kontinuerliga förfrågningar kan få till ett inloggat tillstånd samtidigt verkande med access till annars skyddade resurser? För typisk realisering tolkat från vanlig klientkod jag sett av och till genom åren och senast i dagarna när jag tittade lite på en receptutfärdande tjänst (oavsett vilket tvivlar jag dock på att man ej gör någon mer verifiering innan jag kan börja utfärda recept utnyttjande valfri läkares namn: Om jag nu alls anar rätt ty det kräver bra mycket mer verifiering och att man konkret prövar mot något vilket jag ej ids göra: Typiska aktörer här har budget nog att göra det själva eller betala för det om de är intresserade av det - Emellertid har jag sett liknande uttryck i motsvarande tillståndsmaskinen vi kan tänka oss ofta annars så jag skulle ej bli helt förvånad om vi har något möjligt här om än kanske praktiskt riktigt svårt för de flesta att klara bl.a. därför att det nu kommer inkludera tidshantering - kontinuerligt missbruk av race conditions - och konkurrerande vandring i vår förfalskade tillståndsmaskin vi vill ska bli som en riktig).
Så Youtube och Chrome kan trösta sig med (och Google centralt när de funderar över nästa års incitament-program för medarbetarna hos Youtube och Chrome eller vilka nu ansvariga) att sådant här är vanliga fel och de kan vara mycket värre än alls troligt för Youtube - Chrome kombinationen.
(Jag sätter också taggen kryptologi därför att det är möjligt att tids-dispergenserna om verkliga kanske kan utnyttjas lite bredare relaterat tidshanteringen i själva säkerhetsprotokollen för autentiseringen via id-kortet: Protokoll för sådant har tror jag för alla ej ovanliga någon gång under sin existens haft tänkbara problem här och vidare när det gäller hårdvara kan ju som mer välkänt och praktiskt mindre komplext att utnyttja problem från tidshantering - som troligare idag i alla fall jfr vad bitfel m.m. annars kan utnyttjas för -via introduktion av bitfel ibland vara möjligt som diskuterat bl.a. i klassiska Timing Attacks on Implementations of
Di e-Hellman, RSA, DSS, and Other Systems, Paul C. Kocher [Red. Sökande Kochers papper från 1996 noterade jag förövrigt att troligare / vanligae missbruk av bitfel idag troligen ej handlar om tidsdefekter då angreppsområdet gjorts större än de lösningar förr aktuella: Hardware Bit-Flipping Attac rörande minneskretsar och en säkerhetsdefekt Mark Seaborn och Thomas Dullie (åtminstone vid tiden medarbetare hos Google) upptäckte: Exploiting the DRAM rowhammer bug to gain kernel privileges. Rörande defekten ska vi minnas sedan länge good-practise att skriva över minneskrets data en gång tillräckligt länga medan vi bitflippar hårddisken och skillnaden jag först såg diskuterad av en finsk forskare kanske publicerad 1994 eller där runt är som jag vill minnas det trots förändring elektronik delvis i fysiken relaterad till vad som gör problemet med DRAM möjligt]).
Sessionshantering med enklare problem i tiden
Enklare tekniskt därför att det ej längre inkluderar att försöka kontinuerligt i "snabb-tid" utnyttja race conditions för att hålla ett falskt tillstånd som autentiserad. Men i princip i övrigt samma sak även om problem handlar om timmar eller dagar snarare än realiseras via ständiga requests.
Dock för rent ekonomiska defekter finns så klart värre än sådant relaterat identitet individer oavsett om det nationella id-kortet elektroniskt används eller inte. En mycket tänkbar variant är när budget finns och målet är att införskaffa väldigt mycket pengar finns att starta en finansiell aktör som ansluter sig till affärsbankernas kanaler för sådant rörande primärt och tillräckligt här bankomaternas uppdateringar av vad som hänt och vad de ska veta samt att diskreta batchar rörande transferering hos affärsbankerna "lokalt så att säga" snarare än via Swift eller liknande (vilket jag inte ens tror de är aktuella för). Där kan kanske logik fel finnas när arkitektur betraktas över mer än själva IT-delarna görande nära nog vad som helst möjligt under upp till en tidsgräns där tidsgräns indikerar tidigaste tidpunkt det hela kan detekteras (annat än genom ev. analys av underliga trafikmönster: Ex. vi gör operationer mot 1 miljon konton vilket något märker och varnar). Vad detta tidsfönster är idag (det var flera år sedan jag gjorde säkerhetsarkitektur rörande bank som integrerade bl.a. mot detta) vet jag ej och jag tror det kan ha reducerats mot förr för delar av själva "terminal-strukturen" (läs ex. bankomater) tre dagar (om jag inte helt missminner mig: Knappast mer dock och knappast en tid. Jag tror att just för bankomater är detta reducerat idag men gissningsvis ej perfekt hindrande problem bl.a. relaterat integration mot annat än affärsbankerna.
Jag tog väl mitt ansvar (innan noterande det här för vem som helst intresserad) kanske 2004 eller 2005 noterande något i telefon med någon hos dem om att de nog kanske skulle titta på risker att någon tömmer mängder av bankkonton relaterat tidslogik. Förutom någon teknisk fråga mer aktuell kring något från dem relaterat någon annan som köpt lite timmar av mig.
Jag skrev förändra bankkonton i rubriken därför i affärsbankernas gemensamma system skickar vi eller tar ut pengar ej så mycket som att förändra informationen på en definierad identitet varande just bankkontot. Detta i kontrast (kontrast är väl att ta i men viss kanske esoterisk skillnad finns) mot ex. Swift och Western Union som är mycket mer av att vi skickar pengar eller när transferering sker via bankkonton som kontrolleras av annan aktör (ex. din bank som har samarbete med en bank i något obyggdsland där de kan hjälpa dig att skicka pengar genom att föra över pengar på sitt eget bankkonto hos den införstådda - eller ibland i vilket fall det kan vara men ej behöver vara relaterat någon skum verksamhet ej införstådda - samarbetande banken. Möjligheten till divergens av verkligheten där flera potentiellt olika verkligheter kan samexistera tills kollapsande till en verklighet är en till sida som öppnar möjlighet till utnyttjande. Förr (jag tror ej så längre idag) kunde vanliga kunder märka en aspekt på divergerad verklighet bl.a. hos affärsbankerna när de tog ut pengar från bankomat hörande till annan affärsbank och sedan gick och tog ut pengar i bankomat från sin egen bank och noterade ett för högt saldo (ska vi kalla det The just before pay-out day extra social bank help service defect från att jag tror säkert många dagarna före att lån betalade ut ibland utnyttjade detta för att låna några tusen av banken på eget beslut). Men som sagt åtminstone inom affärsbankerna tvivlar jag på några divergenser tid från bankomat uttgag i dag (rörande andra bankomatsystem foreign eller säg sparbankerna om de fortfarande är en egen aktör och om så heter Sparbanker vet jag ej vad som typiskt gäller men förväntat är att sådant här ska minska som möjligt år från år i och med allt mer infrastruktur och prestanda nät och datorer görande mer till transaktion hela vägen ensam snarare än batch-köras tillsammans med andra transaktioner av och till).
Mer om tid
Mer om finansiella vapen
Och med egen rubrik för möjligheten att viss komik förutom realism peka på att ett låg-komplext med dyrt vapen mot hela världens finansiella system är att ge "rätt" amerikanska investment-banker en stor summa pengar och fria händer att försöka föränta den (ex. tydliggöra att 30% av all värderingsstegring är för er medarbetare att dela på). Sådant är ju välkänt vad som får nationell ekonomier på rad på fall i tillräcklig mängd att få nedbrytningen av ekonomierna självgående.
Jag är lätt förvånad över hur vissa amerikanska politiker en dag uttrycker prioritet nationell säkerhet via mer låg-komplexa frågor och nästa dag argumenterar mot säkerhetssystem rörande de finansiella riskerna. Man ska ej underskatta riskerna i denna domän eller vara trygg i att de inte är ordentligt värre än vad vi ännu haft exempel på om någon försöker utlösa dem medvetet snarare än att det är inkompetens och onaturlig girighet som utlöst problem som bakåt i tiden. Jag kände mig personligen ganska länge ej på något sätt säker på från vad som hade gjorts känt att the meltdown på lånemarknaden i USA inte skulle visa sig vara medvetet utlöst av någon aktör.
Egentligen hade nog taggen finansiell krigföring varit bättre än ekonomisk krigföring för en uppdelning där vi i det senare mer har sådant som sanktioner, bojkott m.m. Ekonomisk krigföring är dock taggen som fanns så jag sätter även denna.
