Diverse defekter Google Chrome, Google sessonshantering m.m.

10/13/2013

Rörande Google Chrome uppdaterade den sig nyligen. Också om den uppdateringen jämfört med tidigare märkte ut sig genom att introducera en mängd problem har den tycker jag en ny bra sak jag gissar kommer från Google's antar jag övergripande stöd för att hantera sina egna nät och resurser effektivt. Denna sak noterade jag när jag laddade ner från ett i tysk-mening mindre till (nedre) medelstora segmentet av universitet. Normalt kan man ha upp till ett mindre antal pågående nedladdningar som ej är del av en html-sida på flik. Universitet orkade dock i väldigt uppenbar mening inte nedladdningen även om deras webblösningen föredömligt klarade att hålla sessionerna i liv växlade den efter cirka 10 - 20 minuter mellan att ge 0 kb/s under minuter på cirka hälften av sessionerna (för Google Chromes max-antal vilket eventuellt är sex till åtta). När jag skulle ta nästa omgång av cirka åtta nedladdningar (samtliga ungefär 120 - 280 MB stora filer med träningsdata relaterat språkanalys jämförande engelska och tyska) tillät Chrome endast att en nedladdning startades i taget mot universitet (som den konvergerade med ett ev. mellan-steg startande två).


Befintlig begränsning och ibland problem med kö-system för nedladdning när man ligger på max-antal är att Chrome inte ger tillgång till kön utan kastar upp filnedlagringsfönster allt eftersom pågående nedladdningar går klart. Ibland när det tagit tid gör det att man sparar ner filer på fel plats och därför behöver ta ner dem igen efter att blandat samman dem.


Även om hade kunnat tro att jag skulle gilla en del av förändringar närmare hur jag använder Chrome är ju just därför praktiskt allt i dom nustartade tomma flikarna helt poänglöst för mig. Samtidigt är den funktion jag där uteslutande använde och lärt mig att nästan automatiskt använda: starta upp flikar jag dödat av misstag p.g.a. av felklick, dubbelklick, peka-grunk på laptop som tolkar handel fel m.m. Det finns i istället på meny-systemet som praktiskt tar väsentligt längre tid för mig. Så helt klart sämre. Samtidigt är jag trygg i att Google med alla sina programmerare säkert sitter och arbetar på att göra dom nya flikarna helt konfigurerbara med ett enkelt zero-human-learning-needed-drag-and-drop interface. Det kommer bli trevvligt.


Många felkodningar, defekter m.m. som dyker upp hos Google nämner jag aldrig även om det och av och till kan få dem korrigerade. Berör de mig tydligt eller dom är gamla och stör i alla fall lite brukar jag gör det medan jag annars gillar att notera dem på ett litet papper för att följa det föga korrekt i statistisk mening men ändå lite intressant för att få lite känsla kring en mekanism relaterat relativ-effektivitet mer huvud mellan små och stora organisationer och känsligheten när mindre växer sig stora.


Ett sådant äldre fel ligger i Google Web Search (där jag just nu totat följer cirka nio till 11) och hur den terminerar mig efter att ha klickat på vissa typer av sökresultat som är PDF-dokument. Felet är ett klassiskt datafel kommande från människans - inom allt data överrepresenterat vilja att både göra egna saker såväl som göra massor av var och en redundanta standardiseringar för att lösa det - och där ett av de äldsta: börjar vi räkna på noll eller ett? Noll är korrekt men en del renegans och heretics tänker fel och skapar programmeringsspråk, api:er m.m. där man börjar räkna på ett. Och därför blir detekter relaterat början och slut på serier man adresserar antingen börjande på noll eller ett vanliga.


Felet för Google som antingen ligger i hur de lagrar information om pdf:dokumenten relativt hur webbsökning vill utifrån vad jag sökt på placera mig i dokumentet eller senare hur de pratar med den pdf-tolkande komponenten i Chrome. Jag lutar åt att det kan vara det senare - ev. beroende vad nu just denna använder även om jag har för mig att samma problem finns på Ubuntu - därför att jag kan också få det när Google Chrome renderar pdf-dokument som ligger i ett delfönster med html runt-om-kring där det åtminstone för väldigt många journal-hus som gör det visas börjande på sida två i artikeln medan detta försvinner när jag klickar för att välja se dokumentet utan html-ramar. Samma fel relaterat webbsökningen är att denna placerar mig där jag borde (med all rimlighet från var sökord finns relaterat ex. rent av en-gång sista blanksidan före en sida med baksidan av en bok som sista sida). Att Chrome renderar egen osynlig html som del av hur den skapar och hanterar sidor verkar väl därför troligt och antagligen en ganska genomtänkt sund lösning genom att det återanvänder tolkningskod man redan gjort. Kanske därför relaterat dom knappar för att förstora, vrida på dokumentet eller något alltid osynligt för första sådan rendering. Men så klart svårt att veta.


Den allmänt mer uppmärksammade grupp av defekter noll och ett fel kan leda till är ju minnesfel där man läser fel-data i allokerat minne eller vandrar utanför det. Google Chrome vad jag minns har dock aldrig krashat relaterat ett pdf-dokument för mig. Däremot har min Microsoft Windows dödat Google Chrome sedan sista uppdateringen två gånger på minnesfel relaterat Flash. Vidare harsedan uppdateringen prestanda-problem relaterat Google Youtubes plugin blivit vanliga - oftast på långa sidor som arkiv-sidor här på bloggen med flera - men också tycks för mig när man har flera på en liten sida eller flera i flera flikar. De två minnesfelen gillade jag. Jag har alltid känt och tyckt längre tillbaka att format med en sådan enorm historia av enorma bl.a. säkerhetsproblem är tämligen vådligt att bara första se som inkapplingsbara samtidigt som de är också är oerhört feta i kostnad och därför är väldigt värde-donerande när hårt optimerade. Det kändes - helt säkert precis som obenägenhet att pröva nya saker en konsekvent att jag kanske lite i förtid speglande min personlighet börjar bli sur-gammal - trevligt att en av de mer seriösa inkapplingslösningarna i en webbklient här tycks falerat på att hålla det från minnesfel på nivå nöd-dödat av OS.


Ett till fel något besläktat konceptuellt är att om jag har två sessioner mot Google inloggade samtidigt från samma IP framför två datorer men korrekt givetvis identifierbara som unika maskiner på vanligt sätt utan något avvikande från normal användning gäller att när den ena av dessa sessioner bryter anslutning direkt (detta var från sista gången många månader sedan jag lät min utvecklingdator få internet-access en kortare tid där jag blev tvungen att direkt bryta anslutning via kabel därför att en del indikerade att odokumenterad gick in i tyst-loggningsfunktion mellan bredbandsgrunka och resp. dator: ev. till min lap-top men mycket möjligt riktat utvecklingsdator) klarar Google's lagringsfunktioner hos sig ej av att separera information från den session som bröt anslutning med den andra sessionen.


Resultatet praktiskt i vad som märks mycket tydligt blev att en lokal webbserver på utvecklingsdatorn som när utvecklingsdatorn varit utan internet besökts med Chrome synkroniserade denna historik med Google centralt. Och detta propagerade ner till min bärbara dator som aldrig på något sett ens skickat ett icmp-paket eller något annat till utvecklingsdatorn. Och vidare att ingen ny synknronisering tycks ske från din bärbara datorn innebärande att den alltid startar upp med två flikar försökande komma åt den endast lokalt på utvecklingsdatorn tillgängliga webbservern. Alltid.


Resultatet av detta publicerade jag bildumpar av direkt efter det inträffade (samma dag tror jag) på Hans Husman om Media därför att en till mer problematisk förklaring hade kunnat ha varit fallet men det kunde uteslutas senare samma dag eller dagen efter där samtidigt jag bedömde förklaringen jag gav här som den troliga (jag ser ingen annan möjlig förklaring jag inte redan kunnat avsluta genom att gå över trafiken som dumpas mellan internet-box och datorerna respektive oberoende varandra. Nedan har vi färska skärmdumpar gjorde efter jag började skriva på detta inlägg. För att avvika från normalt avslutande av Chrome resp. miljö starta upp för att se om det klarade att ställa om det hela att döda Chrome från Microsoft's processhanterare samt starta upp Chrome igen utan internet access. Detta gör dock ingen skillnad (också demonstrerande att historik från lagrat hos Google propagerar till lokalt lagrat på annan dator som aldrig besökt sidorna eller ens någonsin försökt referera eller ens pinga, skicka icmp-paket eller något annat till dator där sidorna vi ser i skärmdumpen finns).



Felet stör mig överhuvudtaget inte praktiskt. Jag bryr mig inte i vad Chrome startar upp med för flikar. Däremot så klart små-intressant i andra domäner relaterat hur Google hanterar sessionshantering av inloggade användare och hur det fungerar i kontext av klienternas lagring, lagring hos Google m.m. Om det presenterar något som visar på att enklare angrepp är möjliga när access till en dator kan emuleras eller brytas i anslutning vet jag inte. Jag ser inte webbsurfande som riktigt meningsfullt att reflektera runt säkerhet för egen del utan håller hellre prioriterade datorer borta från nätet. Men det verkar väl inte otroligt.

0 kommentarer

Kommentera