Pop-up blocker? Manier waarop IE nieuwe tabs opent? EMET? Accountrechten?

Succes, ben benieuwd.

Compabiliteits modus?

Dankjewel voor je reactie,
Alleen IE11's eigen pop-up blocker.
Het uitschakelen ervan geeft geen verschil.

VTexplorer "Send URL to VirusTotal" opent normaal gesproken een nieuw venster, niet een nieuw tabblad.
Niettemin heb ik toch verschillende aanpassingen in IE's tabblad-settings getest, maar dat maakt jammer genoeg geen verschil voor de niet openende VirusTotal URL-scan pagina.

Ook bij niet geïnstalleerde EMET treed dit probleem op.

Het probleem bestaat ook in het administrator-account, dus de rechten zouden geen probleem moeten zijn.
(Of het anders is voor het standaard verborgen Administrator account zonder UAC, dat weet ik niet, maar dat is niet een account dat je normaal gesproken gebruikt.)


En zoals ik in mijn start-post aangaf, het probleem bestond niet in de eerdere/ voorgaande Windows 7 x64 installatie, terwijl de settings daarin volgens mij hetzelfde waren.
Zeer raadselachtig, en bijzonder irritant.

VTexplorer is gewoon compatible met Windows 7 x64.
Het installeren verliep zonder problemen.
En in Program Files (x86) zijn enkel de uninstaller, een icon en een html-document aanwezig. Hetzelfde als bij een wel correct functionerende VTexplorer. Niets waarvoor het nuttig is compabiliteitsmodus toe te passen.
In AppData en System32 en SysWOW64 heb ik nog geen VTexplorer elementen kunnen localiseren.
In het Register heb ik VTexplorer wel aangetroffen, maar volgens mij niet afwijkend van een correct functionerende installatie (vergeleken met m'n Vista x86 installatie).

Werkt dit nog wel naar behoren?

Niettemin heb ik toch het volgende nog geprobeerd:

VTexplorer addon uitgeschakeld in standaardgebruikersaccount en administrator-account,
reboot
VTexplorer geïnstalleerd in compabiliteitsmodus,
reboot,
VTexplorer addon ingeschakeld in administrator-account en standaardgebruikersaccount.

Resultaat: geen verandering.

Vervolgens ook nog een paar keer de VTexplorer addon uit- en weer ingeschakeld met tussentijds openen en sluiten van de browser, maar ook dat veranderde niets.

De hele procedure heb ik twee keer uitgevoerd, een keer in Windows Vista modus, en een keer in Windows 7 modus (voor het geval Windows 7 SP1 het probleem zou zijn).
Allebei de keren geen verandering.

Overigens -
Toepassen van VTexplorer "Send URL to VirusTotal" op een link in de browser lijkt wel iets te doen, de browser 'twinkelt' er even van, maar er opent geen VirusTotal URL-scan venster.

Het lijkt er wat op alsof het script vastloopt.
Voor mijn gevoel moet je misschien nog ergens iets voor virustotal whitelisten? Misschien voor Active-X-filtering?
i.v.m. http://www.sevenforums.com/tutorials/149053-internet-explorer-activex-filtering-turn-off.html
Of ergens anders?

Verder vroeg ik me af of die andere optie van VT-explorer om een website te testen (dus niet een link, maar de website
(zie https://www.virustotal.com/nl/documentation/browser-extensions/internet-explorer/), helemaal onderaan)
misschien toevallig wél werkt?

Jammer dat je het nog niet aan de praat hebt gekregen, nóg een ingeving Spiff, accepteer je cookies? Vooral die van Google zijn belangrijk voor VT!

Verder, ergens meldingen in je AV? En als je die tijdelijk uitschakelt?

Dan kan het ook nog een HOST-file zijn oid.

Of Policies, maar dan zou je die wel eerst zelf moeten hebben ingesteld, lijkt me.


Succes!

Gr anon 14:09


NB: http://blogs.msdn.com/b/ie/archive/2010/09/17/add-ons-staying-in-control-of-your-browsing-experience.aspx

Dat is in IE9 (IE10) en IE11 bij mijn weten nog nooit aanwezig geweest. Was het iets in IE8?
Het is ook nergens voor nodig.
Het gaat me niet om het scannen van de website die wordt weergegeven in het actieve browser venster,
maar om de scan-optie voor URL's via het rechtsklik-contextmenu.

Aanvulling:
Sorry, ik had even beter moeten kijken op die VTexplorer webpagina.
Onderaan op die pagina zie ik nu dat wat je aangaf.

Dat betrof een VTexplorer knop in de IE7/IE8 Opdrachtbalk.
Vanaf IE9 is die Opdrachtbalk standaard uitgeschakeld.
Bij het inschakelen van de Opdrachtbalk is daarop de VTexplorer knop toe te voegen.
Die blijkt op het betreffende systeem eveneens niet te functioneren zoals bedoeld is, het scannen van de website die wordt weergegeven in het actieve browser venster.

Dat is een nuttige constatering, ook dát werkt dus niet, maar buiten dat is die VTexplorer knop nergens voor nodig.
Zoals ik al aangaf, het gaat me niet om het scannen van de website die wordt weergegeven in het actieve browser venster, maar om de scan-optie voor URL's via het rechtsklik-contextmenu.

ActiveX filtering staat niet ingeschakeld.
Denk je aan nog een ander soort whitelisting?

Ah, dank je voor die verwijzing naar het onderste item van die pagina.
Dat was een VTexplorer knop in de IE7/IE8 Opdrachtbalk.
Vanaf IE9 is die Opdrachtbalk standaard uitgeschakeld.
Bij het inschakelen van de Opdrachtbalk is daarop de VTexplorer knop toe te voegen.
Die blijkt op het betreffende systeem eveneens niet te functioneren zoals bedoeld is, het scannen van de website die wordt weergegeven in het actieve browser venster.

Dat is een nuttige constatering, ook dát werkt dus niet, maar buiten dat is die VTexplorer knop nergens voor nodig.
Het gaat me niet om het scannen van de website die wordt weergegeven in het actieve browser venster,
maar om de scan-optie voor URL's via het rechtsklik-contextmenu.

Wel de directe cookies, niet de indirecte (3rd party) cookies.
Het accepteren van indirecte (3rd party) cookies geeft geen verschil.

Geen AV-meldingen.
Uitschakelen van de AV is nog nooit nodig geweest voor de VTexplorer browser extension, en dat ga ik op m'n vriendins schone systeem zekerheidshalve liever ook maar niet doen.

Niet zoiets ingesteld.

Dank je, mooi overzicht.
Maar niets dat ik nog niet kende, zo op het eerste gezicht.

Ok, ligt dus niet meteen in de lijn der verwachtingen dat het hier aan ligt.

Niet specifiek. Jij bent degene die het beste weet wat er allemaal op het systeem staat dat evt. scripting of internetcommunicatie zou kunnen blokkeren, en waar eventueel whitelisting nodig is (browser, AV of whatever).
Ik bedoelde het maar als mogelijkheid, en dat je het niet per ongeluk vergeet. Let bijv. ook op javascript.
Je kunt ook eens kijken of er misschien toch enig internetverkeer plaatsvindt als je op de knop drukt
door naar de ledjes van je router te kijken,
of een meer "sophisticated" methode door met Wireshark te sniffen, en of dit misschien naar conclusies wijst.
Is er geen internetverkeer, dan wordt het gestarte VT-script kennelijk ergens door geblokkeerd.
En wat bijv. ook nog kan, is dat een recente IE11-update roet in het eten gooit. (hoewel mij geen details bekend)

Conclusie is dat er iets aan de hand zou kunnen zijn waardoor zich geen nieuwe IE11 window opent, en dat we ons misschien extra moeten afvragen: zou er soms ergens een instelling bestaan of zou er soms iets aan de hand kunnen zijn waardoor het openen van het noodzakelijke extra IE11-window mislukt. (=één van de vele mogelijkheden)
Nogmaals: ik heb weet geen concrete oplossingen hiervoor, want ik heb geen soortgelijk systeem.
Maar probeer je met mijn algemene achtergrondervaring slechts op wat ideeën te brengen. Hopelijk vind je het euvel.

Dank je voor alle suggesties.
Het bizarre is dat er volgens mij geen andere instellingen zijn dan in de voorgaande installatie, buiten instellingen die niet gerelateerd zouden horen te zijn met het betreffende issue (zoals bijvoorbeeld een uitgeschakelde webcam, uitgeschakeld gadgets platform, uitgeschakelde Remote Registry en WebClient services, een paar andere instellingen in WMP, geïnstalleerde VLC media player, ook bij accugebruik actief koelbeleid voor processor en systeem om de HDD koeler te houden, helemaal niets waarvan enig effect op het correct functioneren van VTexplorer te verwachten zou kunnen zijn).

Dank je, dat zal ik straks (later vanmiddag) even doen.

Met Wireshark heb ik nog geen ervaring, ik denk dat dat jammer genoeg teveel gevraagd zal zijn om dat vandaag nog te gaan uitproberen, naast het andere werk dat ik vandaag nog moet doen.

Of het VT-script start om een andere reden niet?
Is er een manier om te onderzoeken of het VT-script wel of niet start?

Argh, ja, aan zoiets zat ik ook al te denken.
Een update die verhindert dat VTexplorer correct installeert, waardoor die niet functioneert.
Of een update in het anti-virus programma die verhindert dat VTexplorer correct installeert.
Geen AV-meldingen echter, dus ik vermoed dat dat laatste niet het geval is.

Ja, ik zal straks eens uitproberen of andere IE11 acties waarbij een nieuw venster hoort te openen wél correct een nieuw venster openen.
Uh.. heb je toevallig een voorbeeld voor me van een webpagina die via een bepaalde actie een nieuw venster opent? Dat zou me helpen, want ik weet zo gauw even nog niet zo'n pagina, en het zoeken daarnaar kost me ook weer extra tijd die ik vandaag eigenlijk niet beschikbaar heb als ik die vriendin morgen haar notebook zou willen kunnen leveren.


Dus straks (later vanmiddag) door mij in ieder geval te doen:
1.
VTexplorer context-menu optie "Send URL to VirusTotal" gebruiken en zien of op dat moment enig internetverkeer plaatsvindt, door naar de ledjes van de router te kijken. (Al sluit ik niet uit dat enkel al het uitvoeren van zo'n actie op een URL in de browser hoe dan ook internetverkeer genereert, maar ik kan het gedrag van de ledjes in ieder geval wel vergelijken met dat gegenereerd door middel van mijn Vista systeem, waarop VTexplorer wél correct functioneert.)
2.
Controleren of andere IE11 acties waarbij een nieuw venster hoort te openen wél correct een nieuw venster openen.
(Nogmaals, een voorbeeld zou zeer welkom zijn, om me wat tijd te besparen.)

En ook nog:
3.
VTexplorer addon opnieuw uitschakelen in standaardgebruikersaccount en administrator-account,
VTexplorer deïnstalleren,
reboot,
Program Files (x86) en het hele systeem en ook het register nakijken op (te vinden) achtergebleven VTexplorer vermeldingen en die verwijderen,
reboot,
netwerktoegang verbreken,
anti-virus programma even uitschakelen,
VTexplorer ïnstalleren,
anti-virus programma inschakelen,
reboot,
VTexplorer addon inschakelen in administrator-account en standaardgebruikersaccount.
Hopen op een wondertje.

Zodra ik dit alles heb uitgeprobeerd post ik even de resultaten.
In de tussentijd blijven antwoorden op de bovenstaande vragen over het starten van het VT-script, een voorbeeld van een webpagina die via een bepaalde actie een nieuw venster opent, en andere suggesties uiteraard zeer welkom.
Alvast heel hartelijk bedankt iedereen.

Inmiddels onderzocht.
Het gebruiken van de VTexplorer context-menu optie "Send URL to VirusTotal" genereert géén netwerkverkeer, afgaande op de ledjes van de router.
De VTexplorer context-menu optie "Send URL to VirusTotal" lijkt dus niets te doen.

De normale context-menu optie "Openen in nieuw venster" functioneert in ieder geval wel.
En het in webmail openen van een foto-bijlage, automatisch in een nieuw venster, dat functioneert eveneens.
Het testen van een (andere) link in een webpagina die de betreffende pagina automatisch opent in een nieuw venster, dat heb ik nog niet kunnen testen, omdat ik zo gauw geen pagina weet die dat doet, alles opent doorgaans in een nieuw tabblad of in hetzelfde tabblad, slechts zeer zelden opent een link een pagina in een nieuw venster. Mocht iemand een voorbeeld kunnen geven, dan kan ik dat nog testen. Maar ik denk dat het in webmail openen van een foto-bijlage, automatisch in een nieuw venster, voldoende test was.

Waarna momenteel alleen optie 3 die ik om 15:36 uur noemde nog overblijft,
een zo zorgvuldig mogelijke deïnstallatie, met verwijderen van alle eventuele resterende vermeldingen, en herinstallatie en hopen op een wondertje.

Reacties op mijn vragen van 15:36 uur over het starten van het VT-script,
reacties op déze post,
en andere suggesties,
blijven uiteraard zeer welkom.
Opnieuw alvast heel hartelijk bedankt iedereen.

@Spiff: Op een link drukken? (Of open je die dan op dezelfde pagina?)

Ik vind het kijken naar leds een beetje onbeholpen, gebruik dan op z'n minst taakbeheer (pakketten).
Wireshark zou ik nog even links laten liggen, akkoord, bij deze TCPview:
http://technet.microsoft.com/en-us/sysinternals/bb897437.aspx (Heb je gelijk een link om op te drukken!)

Verder zou ik toch even kijken, of het uitmaakt, of je AV aanstaat of niet.
Ik snap dat je geen risico's wil nemen, maar zolang je enkel een vertrouwd domein (microsoft.com) bezoekt, moet dat allemaal wel goed komen.

Dan zou het ook nog iets te maken kunnen hebben internet-zones?

En dan hebben we nog die funky IE-functie "do not save encrypted pages to disk."
Die staat standaard op "enabled," en aangezien VT HTTPS gebruikt... It's a long shot, but worth a try.

En IE10? Dus IE11 er af knallen en het in IE10 proberen?


Tot slot zou ik je zeker ook aan willen raden om VT zelf even te benaderen. Zeker nu je e.e.a. al hebt uitgesloten, maar pas KISS toe, lange mails worden maar zelden inhoudelijk beantwoord :(
contact@virustotal.com


Succes!

Ha :-)
Zoals ik 21:51 uur aangaf, alles opent doorgaans in een nieuw tabblad of in hetzelfde tabblad, slechts zeer zelden opent een link een pagina in een nieuw venster, waar het ons hier om gaat.
Onze posts van 21:51 uur en 21:56 uur hebben elkaar wellicht gekruist.
Zoals ik daar aangaf:
De normale context-menu optie "Openen in nieuw venster" functioneert in ieder geval wel.
En het in webmail openen van een foto-bijlage, automatisch in een nieuw venster, dat functioneert eveneens.
Het testen van een (andere) link in een webpagina die de betreffende pagina automatisch opent in een nieuw venster, dat heb ik nog niet kunnen testen, omdat ik zo gauw geen pagina weet die dat doet, alles opent doorgaans in een nieuw tabblad of in hetzelfde tabblad, slechts zeer zelden opent een link een pagina in een nieuw venster. Mocht iemand een voorbeeld kunnen geven, dan kan ik dat nog testen. Maar ik denk dat het in webmail openen van een foto-bijlage, automatisch in een nieuw venster, voldoende test was.

Ach! Je hebt uiteraard helemaal gelijk.
Ik had natuurlijk aan Taakbeheer moeten denken.
M'n enige excuus is dat ik erg moe ben - maar dan nog! Goed, ik was in ieder geval niet goed wakker ;-)
Wat bedoel je in dit verband trouwens met "pakketten"?

Ik zal het overwegen...

Gezien het feit dat ik daaraan niets heb aangepast en dit hetzelfde is als in de eerdere installatie, zie ik niet hoe.

Interessant.
Maar die staat standaard juist niet enabled.
Althans, in IE11 op Windows 7 x64 (en in IE9 op Windows Vista x86) die ik hier voor me heb.

Gezien het feit dat VTexplorer eerder perfect functioneerde in IE11 vind ik het nogal ver gaan om dan te gaan downgraden naar IE11. Had ik alle tijd, en een testsysteem, dan zou ik zoiets nog kunnen overwegen, maar in dit geval lijkt het scenario me te onwaarschijnlijk en ik wil graag vrijdag dat systeem kunnen afleveren, dus zie ik - met alle respect - liever af van een dergelijke poging.

Dank je, kom ik er vanavond niet uit, dan zal ik dat even moeten doen.
Krijg ik een vlotte reactie, dan kan ik daar hopelijk nog wat mee voordat ik vrijdag die notebook wil teruggeven aan die vriendin. En anders kan ik hopelijk later nog een aanpassing maken.


Momenteel heb ik het zo zorgvuldig mogelijk deïnstalleren achter de rug, zoals ik dat 15:36 uur beschreef van plan te zijn. Ik ga zo eens zien of herinstallatie nu misschien het gewenste wondertje oplevert.
Zo niet, dan mailen met VirusTotal, en zo nodig verder testen.

De 15:36 uur beschreven zo zorgvuldig mogelijke deïnstallatie en herinstallatie is inmiddels achter de rug en heeft geen wondertje opgeleverd.

En nu bekeken via Taakbeheer:
Het gebruiken van de VTexplorer context-menu optie "Send URL to VirusTotal" genereert géén netwerkverkeer, afgaande op de weergave in Taakbeheer.
Bij controle op mijn Windows Vista x86 systeem genereert het gebruik van de VTexplorer context-menu optie "Send URL to VirusTotal" wél een onmiskenbare netwerkpiek. Op het Windows 7 x64 systeem met de problematische VTexplorer blijft die netwerkpiek volledig uit.

Tijd om VirusTotal te e-mailen nu, en hopen op een snelle en nuttige reactie,
en dan morgen verder.

Bedankt weer, iedereen.

Inderdaad.

No prob, die ga je nooit meer vergeten ;)
Met pakketten doel ik op het feit dat je kunt zien of er pakketjes ontvangen & verzonden worden.
Overigens kun je daar ook de status v/d netwerkverbinding voor gebruiken.
En het eerder genoemde TCPview is zeker ook de moeite waard, maar dat verder terzijde, alle respect voor je deadline.

Duidelijk, even nalopen kan nooit kwaad.

My bad, heb om eerlijk te zijn sinds IE9 niet veel met IE meer gedaan, en daar was het wel enabled destijds, geloof ik althans. Wellicht is ook dat veranderd, of vergis ik me gewoon.

In dat geval zou ik VTx even laten liggen tot je alle andere zaken hebt afgerond.
Tenminste, ik kan me niet voorstellen dat de werking van een add-on de rest van het systeem negatief beïnvloed.
Daarbij wil ik wel melden dat je door het te proberen met IE10, MS-updates kan uitsluiten, vooral als je géén updates voor IE installeert.
Nogmaals, bij het louter bezoeken van microsoft.com, kan er (in feite) niets misgaan (dat anders ook niet zou misgaan). En als het wel misgaat, heb je het verhaal v/d eeuw!

Eigenlijk zou je MS ook moeten contacteren, maar zo'n advies kan ik niet met een goed geweten geven.
Zeker niet als je dat systeem a.s. vrijdag, werkend wil retourneren...

Als je VT mailt, vraag dan zeker ook even om een debugger(functie).
Ik zou geen flauw benul hebben van waar je dit in logs terug zou moeten kunnen vinden, ook dat is een mogelijke vraag voor VT.


Succes!


NB: Dat scheeps-GPS-gebeuren (VesselTracker) is natuurlijk fantastisch, maar maakt het Googlen van dit issue wel even iets lastiger ;)

Nog een kleine aanvulling op mijn vorige, nog niet goedgekeurde post, die de jouwe alweer kruiste.
Ik snap inmiddels dat ik niet met 3rd-party applicaties aan hoef aan te komen om e.e.a. te analyseren.
Daarbij zou ik zelf waarschijnlijk ook hulp nodig hebben trouwens, want ik ben niet echt bekend meer met IE.


Maar nu ga ik me even in jouw situatie verplaatsen & pragmatisch denken, dus.., "als ik jou was:"
- Alles (behalve VT) afwerken.
- Image maken
- Win7 er opnieuw op knallen = kaal, VT vervolgens proberen. Dus zonder updates, AV, etc. Risico = null, want image.

Werkt? Issue als gevolg van een update, AV, maatregel, applicatie, wat dan ook.
Die dan 1 voor 1 toepassen = kijken wanneer het niet meer werkt = oorzaak gevonden!

Werkt niet? Dan kan jij er ook niets aan doen...
Image er opnieuw op zetten en systeem inleveren zonder VT.


Laatste blind schot: UAC uitzetten.
Verder zijn mijn blinde schoten op, sorry.
(Ook al heb je niets gewijzigd in HOST / AV-FW / policies / zone's etc., toch even nalopen, ook applicaties kunnen soms wijzigingen aanbrengen namelijk.)

Vraagje nog, waar in het register heb je de sleutels voor VT teruggevonden?

Anoniem 00:26 en 00:51 uur,
Dankjewel weer voor je onderzoekssuggesties.

De beveiligingsinstellingen voor de internet-zones heb ik inmiddels even gecontroleerd - daarin niets afwijkends.
Host file - default.
Firewall policies - niets afwijkends.
UAC uitschakelen - geen verschil.

Waar in het register ik precies de VTexplorer sleutels vond en vind, dat zou ik opnieuw moeten nazoeken.
Ik heb simpelweg het register afgezocht met de zoekterm VTexplorer. Daarbij vond ik niet iets afwijkends.
De locaties opnieuw opzoeken en dan hier plakken dat kost me weer eventjes tijd, dat bewaar ik voor eventueel later.

Wat betreft je IE10 suggestie, dank je voor je uitleg, ik begrijp het.
Maar ook dat moet ik voor eventueel later bewaren, want dat zou me aardig wat tijd kosten.

Ook je suggestie na imaging de kale Windows uit te proberen met VTexplorer is een interessant idee.
Ik kan me niet voorstellen dat VTexplorer dan níet zou werken.
Echter, het vervolgens stapje voor stapje opnieuw de hele Windows en applicatie setup toepassen om te onderzoeken wanneer er (mogelijk) opnieuw een blokkade van VTexplorer optreedt, dat zou krankzinnig veel tijd kosten, want feitelijk doe ik dan de hele setup opnieuw met daarbij tevens steeds een controle van het functioneren van VTexplorer. Theoretisch is dat te doen, maar omdat het zóveel tijd gaat kosten is het feitelijk geen optie. Enkel wanneer ik de tijd en energie had om hier een week of meer extra tijd en energie in te steken zou het een werkbare optie zijn.
Het idee is uitstekend, dank je, maar tijd en energie om het uit te voeren ontbreken me.

Ik doe vandaag de laatste ditjes en datjes van de inrichting van het betreffende systeem, en nog een paar controles, en scans en defragmentatie, en dan maak ik vanavond images.
Hopelijk ontvang ik vandaag nog een bruikbare reactie van VirusTotal en weet ik het VTexplorer issue daarmee op te lossen. Zo niet, dan moet dat wachten tot later en dan is dat jammer genoeg niet anders.

Ook zeer waardevol zou uiteraard de bijdrage zijn van iemand die hier dit topic opmerkt, ooit hetzelfde probleem heeft gehad en dat heeft kunnen oplossen. Ik ben dan uiteraard érg benieuwd naar hoe.

Reactie van VirusTotal:
I haven't heard of this issue before.
Can you check if re-installing the Visual C++ Redistributable Packages helps?
Microsoft Visual C++ 2010 Redistributable Package (x86)
Visual C++ Redistributable Packages for Visual Studio 2013

Microsoft Visual C++ 2010 Redistributable Package (x86) was al aanwezig, en is nu 'gerepareerd' door het uitvoeren van de betreffende installer. Geen verandering in het probleem.
Visual C++ Redistributable Packages for Visual Studio 2013 was nog niet aanwezig. De vraag is of het nodig is, én de vraag is of ik daarvan de x86 of de x64 installer zou moeten installeren. Uitgaande van het feit dat VTexplorer x86 software is, heb ik gekozen voor de vcredist_x86 installer. Ook dit geeft geen verandering in het probleem.

Ik heb VirusTotal gevraagd of ik Microsoft Visual C++ 2010 Redistributable Package (x86) moet deïnstalleren en herinstalleren in plaats van uitvoeren ter 'reparatie', ik heb gevraagd of ik de x86 of de x64 Visual C++ Redistributable Packages for Visual Studio 2013 installer moest uitvoeren, en ik heb uiteraard gevraagd of ik nog wat anders kan proberen, en of er een debugger beschikbaar is.

Wordt vervolgd.

Ik heb VTexplorer geïnstalleerd op mijn PC (Windows 7 64 bits met IE11). Bij het klikken op "Send URL to VirusTotal" opent er bij mij ook geen venster. Wel de door Spiff omschreven "twinkeling" van de browser.

Echter bij het opnieuw uitproberen met op de achtergrond het F12-ontwikkelhulpprogramma's geopend krijg ik een venster met de foutmelding: 'fout op webpagina'. (in het venster staat een nadere omschrijving).

Ik vraag me af of deze foutmelding misschien in verband zou kunnen staan met het door Spiff omschreven probleem. (Ik heb verder geen ervaring met VTexplorer).

Geweldig, _kraai__!

Ook aan IE's F12-ontwikkelhulpprogramma's had ik zelf kunnen (moeten) denken, maar gezien het feit dat ik er niet aan gedacht had is het ronduit geweldig dat jij er aan dacht.
En inderdaad, de door F12-ontwikkelhulpprogramma's getoonde melding heeft betrekking op VTexplorer, zowel het programma als de ontwikkelaar worden genoemd.

Ik zal de betreffende F12-analyse aan VirusTotal toemailen.
Ik hoop dat het voldoende is ter diagnose en oplossing.

Jammer genoeg zal ik het euvel waarschijnlijk niet meer kunnen oplossen voordat ik morgen die notebook aflever, maar misschien dan een andere keer binnenkort.
Echter, wanneer VirusTotal geen kant en klare oplossing te bieden heeft, maar verdere analyse wil laten doen, dan gaat het lastig worden. Dat is altijd zo wanneer het iemand anders apparaat betreft dat je niet (meer) bij de hand hebt.

Maar gezien het feit dat hetzelfde probleem ook op jouw systeem optreedt, _kraai__, verwacht ik het binnenkort ook op m'n eigen systemen tegen te komen, wanneer ik m'n notebook Windows 7 x64 installatie verder afrond, en vervolgens bij de Windows 7 x64 installatie op m'n huidige Vista systeem.
Gelukkig, dan kan ik toch verder puzzelen, haha ;-)

Voor nu, ik zal zometeen een vervolg-mail aan VirusTotal sturen met die F12-analyse.

Nogmaals bedankt voor je initiatief en voor je heldere idee IE11's F12-ontwikkelhulpprogramma's toe te passen.

@Spiff 11-12-2014 18::56 uur.

Bedankt voor je terugkoppeling Spiff.


Oké bedankt


Oké hopelijk hou je me op de hoogte van de ontwikkelingen.


Verder analyse met de notebook van jouw vriendin gaat inderdaad lastig worden, maar hopelijk is het inderdaad wel mogelijk dat je kunt verder puzzelen op je eigen systeem.


Het F12-ontwikkelhulpprogramma's van IE dacht ik niet meteen aan, maar soms als ik de lamp boven mijn bureau aan maakt komt er wel eens een idee binnen wandelen ;-)

Ik ben benieuwd naar de reactie van VirusTotal en of de F12-analyse voldoende is voor analyse en een oplossing.

Beslist.

P.S.
Je had het misschien al begrepen -- ik ben érg blij dat jij hetzelfde issue hebt vastgesteld, _kraai__.
Daarmee is het probleem nog niet gediagnosticeerd en opgelost, maar het maakt een specifieke door mij aangebrachte setting onwaarschijnlijk als oorzaak van het probleem, en hopelijk draagt het aan VirusTotal toegestuurde F12 Developer Tools rapport bij aan het vinden van een oplossing.

In mijn mail van eerder vanavond aan VirusTotal heb ik, naast dat ik dat F12-rapport heb aangereikt, tevens vermeld dat er een tweede gebruiker is met hetzelfde issue. Dat geeft VirusTotal een indicatie dat het niet een probleem van slechts één gebruiker en één computer betreft, en daardoor wellicht een andere blik op het issue.
Ik heb ter onderbouwing verwezen naar deze thread en naar jouw post van 17:35 uur waarin je je melding maakte (misschien heeft VirusTotal wel een Nederlandstalige medewerker die het interessant vindt om even mee te kijken).

Anyhow, ik wacht VirusTotal's antwoord af.
Stel dat ze morgenochtend al een fix beschikbaar hebben, wie weet kan ik die dan nog eventjes toepassen voordat ik 's middags de notebook wegbreng.

@Spiff 11-12-2014 23:12 uur:

De kans is natuurlijk kleiner dat een specifieke door jouw aangebrachte setting de oorzaak van het probleem is, maar de kans is denk ik niet 0. het kan namelijk toch zo zijn dat ik die zelfde setting heb aangebracht? Verder ook bedankt voor jouw positieve reactie.

Voor alle zekerheid:
Verzeker jezelf ervan dat java-ActiveX up-to-date is, of maak alternatieve instellingen.
Zie http://blogs.msdn.com/b/ie/archive/2014/08/06/internet-explorer-begins-blocking-out-of-date-activex-controls.aspx

Je hebt uiteraard helemaal gelijk.
Ik schreef, het maakt een specifieke door mij aangebrachte setting onwaarschijnlijk als oorzaak van het probleem.
Ik had beter kunnen schrijven "minder waarschijnlijk".
Overigens nog geen vervolgreactie van VirusTotal, vandaag. Wellicht volgende week.

Beste Spiff en Kraai,

Het effect dat zich geen nieuw IE window opent, krijg je als er geen contact kan worden gemaakt met www.virustotal.com.
(WAN-aansluiting router hierbij losgekoppeld van internet) Ik heb dit kunnen reproduceren op mijn ouwe trouwe hobbyXP.
Daar zou dus misschien ergens de oorzaak van het probleem kunnen liggen?
Op de oude IE-browser kreeg ik daarbij de scriptfoutmelding: 'respons.0' is leeg of geen object.
Komt deze foutmelding overeen met die F12 van jou?

Als al je netwerkverbindingen verder in orde zijn,
dan zou ik www.virustotal.com eens in de "trusted zone" whitelisten. (scripting moet aan!)
Daar heb je namelijk geen last van wat ik noemde in het bericht van 15:54. Succes!

Mvg, cluc-cluc

Beste allemaal,

beschreven symptomen komen ook bij mij voor. Ben ik dan de derde?
Uit interesse vtexplorer installed op up2date ie11 win7 64 prof, ook bij mij "flits" er ff iets en verder nix. Bij debug zie ik idd ook beschreven foutmelding. Heb vt explorer weer deinstalled.
Ben benieuwd naa respons van VT.

Mvg.

De LAN-verbinding was gewoon correct.
Kan het dan desondanks zo zijn dat geen contact gemaakt kan worden met www.virustotal.com?

Ik heb de foutmelding ten behoeve van VirusTotal vertaald uit het Nederlands naar het Engels, het origineel heb ik stomheidshalve niet bewaard, en de betreffende notebook heb ik vanmiddag al bij m'n vriendin gebracht.
Wellicht kan _kraai__ de melding zo nodig nog reproduceren?
Aanvulling:
Inderdaad, zie:

Volledige melding,
maar zonder de correcte inspringingen, want daarvoor zou ik veel te lang moeten knutselen met Alt+255, non-breaking space:

Ik kan dat nu niet uitvoeren, omdat de betreffende notebook zoals gezegd al is weggebracht.
Misschien kan _kraai__ dat uitproberen?

Heel hartelijk bedankt.

Java is niet geïnstalleerd op het Windows 7 x64 systeem dat ik beschreef.
VTexplorer is niet Java-afhankelijk.

Ok. Dat vermoedde ik haast ook al wel, maar ook dit moesten we wel even zeker weten.

Ja, dat lijkt mij wel. Bijvoorbeeld wegens andersoortige blokkering van het netwerkverkeer naar/van www.virustotal.com.
Zoals door een Firewall of AV-software, of een script om contact te maken met www.virustotal.com dat vastloopt,
routers, hubs, DNS etc. Want één ding is 100% zeker: VTexplorer zal beslist contact zoeken met www.virustotal.com.
En als dat niet lukt, dan gaat het niet werken.

Ik zie verschil: in XP meldde mijn antieke testbrowser (IE8) regel 42, teken 5, maar dit was bij WAN stekker eruit.
Voorzichtige conclusie: bij jou gebeurt het probleem waarschijnlijk op een hele andere plaats, of misschien is het toch
een andersoortig probleem. (eventueel zouden ook processen in Win7 met IE11 iets anders kunnen lopen. I dontknow)

Dat weet ik zo net nog niet. Waarom staat er dan in de hierboven door jou opgegeven foutmelding:
???... Misschien dat ik morgen nog wat tijd over heb om desnoods ook nog eens te kijken wat er gebeurt als ik in mijn IE javascript uit zou zetten. (moet ik m'n testPC even opnieuw installeren)

Maar als Kraai nog even kan proberen om "www.virustotal.com" toe te voegen aan de "Trusted Zone" in Win7/IE11,
met als het ware "shields down" in de Trusted Zone (dus liefst lekker veel toestaan in de security settings,
of als Kraai dat niet aandurft dan op zijn minst javascript "aan" ; wie weet is dat al genoeg?...). En dan weten we het zo.
Voor wie de juiste configuratie heeft, misschien een kleinigheidje. En niet geschoten is altijd mis. ;-)
En we hoeven lijkt mij niet te verwachten dat een website als "www.virustotal.com" je computer gaat infecteren???
Dus ook dat lijkt me geen belemmering voor zo'n testje. (hoewel ik respecteer Kraai natuurlijk in wat hij er zelf van vindt)

Mvg, cluc-cluc

Ja, dan ben je blijkbaar de derde.

Um.. voor alle duidelijkheid,
Anoniem van vr.12-12, 15:54 uur, had het over de Java ActiveX. Java.
Daarop reageerde ik met aan te geven dat Java niet geïnstalleerd is op het Windows 7 x64 systeem dat ik beschreef.
Op mijn Vista systeem is het eveneens niet geïnstalleerd. VTexplorer werkt daarop echter prima. VTexplorer is niet Java-afhankelijk.

Jij hebt het over JavaScript.
JavaScript is niet hetzelfde als Java.
VTexplorer is (blijkbaar) JavaScript-afhankelijk.
JavaScript is echter niet uitgeschakeld op het Windows 7 x64 systeem dat ik beschreef, dus dat zou geen probleem moeten geven.

@Spiff, en Anoniem, cluc-cluc

Ik heb jullie reacties gelezen. Helaas heb ik vanmiddag geen tijd, dus kan ik pas vanavond jullie vragen beantwoorden. Ook zal ik "www.virustotal.com" toe te voegen aan de "Trusted Zone" in Windows 7 IE11. De resultaten zal ik dan uiteraard vanavond hier posten.

Excuses voor de wachttijd.

Uiteraard geen enkel excuus nodig voor vanmiddag geen tijd hebben. Geniet lekker van je weekend, _kraai__.
Ik vind het al lang geweldig dat jij hiermee aan de gang gaat, nu het systeem waar ik aan gewerkt heb al terug is naar mijn vriendin en ik mijn eigen Windows 7 x64 installaties nog niet af heb en daarop VTexplorer nog niet kan onderzoeken.
Dus neem je tijd, we zien je reacties tegemoet zodra je er tijd voor hebt.

N.B.
Anoniem van gisteren, vr.12-12, 21:45 uur, die aangaf als derde hetzelfde probleem te ervaren met VTexplorer - je bent uiteraard welkom om mee te onderzoeken op je eigen systeem, als je daar zin in hebt.

N.B. Aanvulling/ correctie za.13-12-2014:
Voor zover ik me herinner, heeft VTexplorer eerder correct gefunctioneerd, toen ik het in 2012(?) installeerde op dat systeem, maar ik weet niet of het recent ook nog werkte. M'n vriendin was uit het oog verloren dat ze VTexplorer tot haar beschikking had, en heeft het recent niet meer gebruikt, dus ze kon niet aangeven of het tot voor kort nog werkte.
Ik kan daardoor niet uitsluiten dat VTexplorer misschien al geruime tijd niet meer functioneert, misschien sinds een of andere update voor IE11, of misschien zelfs al sinds de update van IE10 naar IE11, of heel misschien zelfs al sinds de update van IE9 naar IE10, updates die geen betrekking hebben op IE9 op mijn eigen Windows Vista systeem.

Helaas werkt mijn PC even tegen dus een aantal vragen beantwoorden moet ik waarschijnlijk uitstellen tot morgen.

Wel kan ik de Nederlandstalige melding geven waar Spiff om vraagde:


De melding was als volgt:

SCRIPT5007: Kan de eigenschap createRange van een niet-gedefinieerde verwijzing of een verwijzing naar een lege waarde niet ophalen

Dank je, _kraai__.
Een vertaling naar het Engels was beter voor contact met VirusTotal,
maar voor de deskundigen hier is het origineel, zonder potentiële vertaalfouten, beter.
Ik plak jouw melding even in mijn post van gisteren 12-12-2014, 21:51 uur.
Nogmaals bedankt.

Je hebt helemaal gelijk met je bericht van 01:56 Spiff. Ik zat teveel met javascript in m'n hoofd.
Gelukkig zijn we allemaal mensen.
Inmiddels even VTexplorer getest met javascript uitgezet (max. security in internetzone), maar blijft functioneren.
Dus misschien was dit toch niet het juiste spoor.
(maar met de karige informatie die er is, moet men toch ergens beginnen, dus geen reden tot spijt)

Maar om het goed te maken: ik denk wel dat ik nu beter weet waar de fout in zit!
Als het goed is, dan worden er bij installatie van VTexplorer een aantal bestanden gekopieerd.
C:/Program Files (x86)/VTExplorer/VTExplorer.htm is één van die bestanden.
Dit bestand bevat precies het script dat ook bij de foutmelding wordt weergegeven.
Open het maar eens met Notepad of zo.

Op de elfde regel ("line 11", waar volgens de melding de fout plaatsvindt) staat:
Maar gelet op de voorafgaande var-declaraties staat daar eigenlijk:

Echter volgens http://msdn.microsoft.com/en-us/library/ie/ms535869(v=vs.85).aspx
moet je vanaf IE11 "selection" niet langer gebruiken. Dit artikel begint met:
[selection is no longer supported. Starting with Internet Explorer 11, use getSelection.]

http://msdn.microsoft.com/en-us/library/ie/bg182625(v=vs.85).aspx gaat over compatibility changes in IE11.
Hierin lezen we dat o.a "document.selection" is veranderd in: "window.getSelection"

Waarschijnlijk loopt het script in line 11 dus spaak, omdat dit niet compatible is met IE11.
En als het in regel 11 spaak loopt, dan komt het script nooit meer toe aan
en dan wordt er uiteraard geen nieuw window geopend (om de virustotal resultaten te tonen)...
Snappu?

Afijn, als we de eerder gevonden informatie om "IE11-compatible" te worden consequent doorzetten,
dan moet het uiteindelijke
het volgende gaan worden:

Dit wordt bereikt door het wijzigen (m.b.v. Notepad o.i.d.) van regels 9 en 10 van het script in
C:/Program Files (x86)/VTExplorer/VTExplorer.htm:
moet in C:/Program Files (x86)/VTExplorer/VTExplorer.htm worden gewijzigd in:

En als het boeren-cluc-cluc-verstand van clucje clucje niet in de steek heeft gelaten
dan aanschouwen we daarna misschien een klein wondertje? ;-)
(in ieder geval ben ik er behoorlijk van overtuigd dat we nu in de goede richting zitten met de oorzaak)

Mvg, cluc-cluc

Mee eens dat de originele melding hier beter zal zijn. Overigens heb ik een aantal schermafbeeldingen van de melding gemaakt, deze kan ik echter hier niet posten.

Overigens heb ik vandaag inderdaad van mijn weekend genoten, bedankt. Hopelijk geniet jij tussen de drukte door ook van je weekend.

Aangezien ik mijn PC (met Windows 7 64 bits)) even niet kan gebruiken, heb ik VTexplorer op mijn andere PC geinstalleerd (Windows 7 32 bits met IE11) op die PC treed het issue ook op. Bij klikken op "Send URL to VirusTotal" is er ook slecht een 'twinkeling' van de browser te zien en opent er geen nieuw venster waarin de VirusTotal URL-scan plaats vind. Ook met het F12-ontwikkelhulpprogramma's op de achtergrond geopend verschijn er een venster waarin staat 'fout op de webpagina' hetzelfde venster als ik in mijn post van 11-12-2014 17:35 omschreef.

Ik ga nu met mijn PC war Windows 7 32 bits op staat jullie reactie doorlopen, te beginnen met de tip van Anoniem, cluc-cluc om "www.virustotal.com" toe te voegen aan "Trusted zone".

Je kunt ze uploaden naar een image hoster (zoals bijvoorbeeld imgdumper.nl) en dan hier de URL's daarvan plaatsen.

Beslist.
Na twee weken waarin ik zo'n beetje elk vrij moment gebruikte voor achtereenvolgens diagnose, veiligstellen van data, en het vervolgens het vanaf niks tot in detail inrichten van die notebook, doe ik nu eventjes zo weinig mogelijk. Even lekker uitblazen. En ook wat dingen doen waar ik de afgelopen weken niet aan toegekomen ben.
Het vervolg van de inrichting van m'n eigen notebook en daarna mijn desktop, dat mag allebei maar even wachten.

O, wel heb ik daarnet nog een vervolg-mail aan VirusTotal gestuurd,
met de vermelding dat gisteren een derde persoon hetzelfde issue rapporteerde,
en tevens met de aanvulling/ correctie die ik hier za.13-12, 22:36 uur postte.

Ik heb op mijn PC met Windows 7 32 bits* "www.virustotal.com" toegevoegd aan de "Trusted Zone" in IE11. Helaas bij het toepassen van "Send URL to VirusTotal" op een link in de browser treed slechts de 'twinkeling' op van IE11 maar open er zich geen nieuw venster waarin de VirusTotal URL-scan plaats vind.

de instellingen voor "Trusted Zone" in Win7/IE11 heb ik gezet op laag.

*zie mijn reactie van 14-12-2014 00:10 uur waarin ik aangeef het zelfde issue met VTexplorer, dat door Spiff in zijn startpost is omschreven, ook vaststel op mijn PC met Windows 7 32 bits.

Oké, bedankt. Ik heb overigens jouw reactie van zaterdag 13-12-2014 22:36 uur gelezen.

Dankjewel, _kraai__.
Belangrijk om te weten dat het VTexplorer issue ook optreedt op Windows 7 32 bits.
En belangrijk om te weten dat het toevoegen van www.virustotal.com aan IE11 Trusted Zone het probleem niet verhelpt.

Misschien zijn er maar weinig VTexplorer gebruikers, anders had VirusTotal wellicht al eerder van het probleem vernomen, en wij hier misschien ook.
Ik ben benieuwd of hier nog iemand een oorzaak en mogelijk oplossing kan vinden, en vooral ook of VirusTotal (en daarvoor misschien oorspronkelijk ontwikkelaar Sergio de los Santos, toentertijd van Hispasec Sistemas) het probleem weet te diagnosticeren en op te lossen.

Geweldig, cluc-cluc!
Goeie vondst.

_kraai__ kan het wellicht uitproberen, vandaag, of binnenkort.
En eventueel ook Anoniem van vrijdag, 12-12, 21:45 uur, die aangaf als derde hetzelfde probleem te ervaren met VTexplorer.

Voor alle zekerheid misschien:
maak eerst even een kopie van het bestand VTExplorer.htm
hernoem vervolgens het origineel tot VTExplorer.bak (dus back-up bestand), of eventueel VTExplorer.old
bewerk de kopie zoals aangegeven door cluc-cluc,
en geef die kopie dan de correcte bestandsnaam VTExplorer.htm

Ik heb het zonet even uitgeprobeerd op m'n Windows Vista systeem met IE9.
Zoals verwacht werkt VTexplorer dan juist niet meer, want de door cluc-cluc vermelde wijziging geldt pas voor IE11, en nog niet voor IE9.
[18:27 uur, uitgevoerde correctie: "niet niet" gecorrigeerd naar "niet"]

Ik ben benieuwd naar de ervaring van _kraai__.

Als deze methode het probleem oplost, dan kan ik dat doorgeven aan VirusTotal.
Ik denk dat ik je tekst van za.13-12, 23:09 uur, daartoe wel even naar het Engels kan omzetten, maar als je wilt mag je dat ook zelf even doen, cluc-cluc.

Voor VirusTotal is er dan vervolgens wel de uitdaging om een installer te maken die een correcte installatie uitvoert voor zowel IE11, als voor eerdere IE-versies,
óf VirusTotal kan twee verschillende installers aanbieden, een voor IE11 (en later) en een voor eerdere IE-versies.


Nogmaals -
goeie vondst, cluc-cluc!

Voor de duidelijkheid: "niet niet" is "wel"... Maar dat bedoel je waarschijnlijk niet. (kleine revanche, Hihihi ;-)
Zoals gezegd: we zijn allemaal mensen... Maar voor de rest heel mooi en goed gesproken, Spiff. Thanks!!! :-)

Het wachten is op het resultaat van iemand met een Win7/IE11-systeem die regel 9 en 10 in bestand
C:/Program Files (x86)/VTExplorer/VTExplorer.htm heeft gewijzigd in:

Mocht dit niet werken, probeer dan ook eens:
(dus regel 9 in de oorspronkelijke toestand gelaten)

Daarna kun jij misschien de hele oplossing kort en zakelijk aan virustotal mailen (mijn hele bericht vertalen zou ik niet doen), of anders moeten we het laten bij alleen maar een hint, door te verwijzen naar de links over IE11-compatibility.
En dan moeten ze zich bij virustotal daar verder maar mee redden. Vind je niet?
Ik wil eventueel wel een voorstel in het engels op security.nl plaatsen.
Maar laten we eerst nog even afwachten of de voorgestelde oplossing(en) goed werken, zoals gehoopt.

Mvg, cluc-cluc

Ik wil niet lastig zijn maar toch een vraagje alvorens ik aan de slag ga, kan wel zomaar aanpassingen maken in C:/Program Files (x86)/VTExplorer/VTExplorer.htm? gaat dat niet in tegen licentie voorwaarden of zo iets? of maakt dit niets uit? (ik weet niet hoe dit precies bij VTexplorer in elkaar zit)

Och jee, ja ja :-)
Mijn tweede "niet" was er eentje teveel.
Dank je voor de scherpe blik en je correctie, cluc-cluc!

Heb je enig idee wat het meest in de lijn der verwachting ligt, en waarom?

Dat laatste spreekt uiteraard voor zich.

Wat het ná het toetsen van de voorgestelde oplossing(en) doormailen aan VirusTotal betreft,
de verwijzingen naar de bronnen van Microsoft geven me uiteraard geen problemen,
en de code-regels ook niet, en het meeste van je uitleg en beschrijving ook niet.
Eigenlijk was het enkel de term "var-declaraties" die me deed twijfelen of ik daarvoor wel de correcte Engelse term ken.
Is de Engelse term "var declarations", of mogelijk iets heel anders?
Die potentiële moeilijkheid kan ik overigens ontwijken wanneer ik die uiteenzetting vermijd, en slechts de verwijzing naar de Microsoft-bronnen aanreik, en onze bevinding van de aanpassing naar
of

VirusTotal's Terms of Service and Privacy Policy lijkt daar niet werkelijk wat over te zeggen.
https://www.virustotal.com/nl/about/terms-of-service/
Al kan een vage formulering misschien altijd wel uitgelegd worden als "je mag onze software niet aanpassen".
Maar gezien het feit dat we volkomen te goeder trouw zijn, niet iets willen kapotmaken maar willen assisteren bij het verhelpen van een probleem, en netjes van plan zijn te rapporteren aan VirusTotal, zie ik geen bezwaren.

Nee Spiff, dat heb ik niet direct. De reden is, dat ik weinig zin heb om me hier zover in te verdiepen, totdat ik er heel misschien wél een goed idee van heb. (met dus alle tijd die het kost, en met een risico dat er altijd twijfel zal blijven...)
En dat terwijl men beide opties binnen een paar minuten kan uitproberen. Dit laatste lijkt me dan wel zo efficiënt.
Ik vraag me tegelijk ook een beetje af waarom je dit eigenlijk vraagt?

Ja Spiff, ik denk inderdaad dat je al die details beter achterwege kunt laten.
Je kunt met verwijzing naar die twee links over IE11-compatibility direct met de oplossing komen. Bijvoorbeeld:
"With the knowledge of these IE11 compatibilty issues and with some failure information provided by the browser
we were able to find a workaround just by changing code in lines 9 and 10 of C:/Program Files (x86)/VTExplorer/VTExporer.htm in:
"
(of dus eventueel die ander optie, afhankelijk van welke optie mocht werken, er vanuit gaande dát er een optie werkt...)

Hier kun je het wel bij laten. Ervaren SW-experts van virustotal zien het dan heus wel.
En daarna bijv. meteen afsluiten met zoiets als:
"We provide you with this valuable information with the intention that it may assist you in speeding up
a permanent solution for this problem that currently is showing up with IE11 browsers."

Lijkt je dat wat?

Voor wat betreft terms en conditions van virustotal (waarvan Google uiteindelijk de eigenaar is) zie ik het als volgt:
Bij vtexplorer.exe zaten volgens mij geen voorwaarden (niets gezien bij downloaden of installeren in elk geval)
Dus gelden alleen hun algemene voorwaarden op het web: https://www.virustotal.com/nl/about/terms-of-service/
Die gaan erover dat je met hun produkten/services geen onwettige dingen mag doen, het niet misbruikt,
en dat je met hun produkten/services geen schade toebrengt aan virustotal of anderen.
Daar zijn wij helemaal niet mee bezig.
Wij zijn juist bezig IE11-gebruikers te helpen die graag VTExplorer willen gebruiken. Én tegelijk Virustotal te helpen,
door Virustotal de kans te geven om voor hun klanten een maximale "user experience" te creeëren.
Zou een bedrijf als virustotal dat onder Google staat daar op tegen zijn?...

Mvg, cluc-cluc

Omdat ik niet weet of _kraai__ mogelijk nog aan het testen is en vanavond laat (vannacht) nog rapporteert,
en ik het nuttig vind dat VirusTotal alvast op de hoogte is van onze (met name cluc-cluc's) bevindingen tot nu toe,
stuur ik nu alvast even een vervolg-mail in mijn correspondentie met VirusTotal, zodat ze daar morgenochtend alvast naar de VTExplorer.htm code en de Microsoft richtlijnen voor IE11 betreffend selection en getSelection kunnen kijken, en niet mogelijk onnodig aan de gang gaan met eerdere en misschien minder relevante bevindingen.
Wanneer er op een gegeven moment resultaat is van een test door _kraai__, dan stuur ik dat weer in een volgende vervolg-mail aan VirusTotal.

Dat is helemaal prima, uiteraard, cluc-cluc.
Het was beslist niet mijn intentie je aan te zetten je ten koste van extra tijd er extra in te verdiepen.
Het was door je kundige beschrijving dat ik dacht dat je er al zo veel kennis over had dat je mijn vraag mogelijk kon beantwoorden zonder verder verdiepen. Maar dat ik het je vroeg was een beetje dom van me - had je geweten welke van beide mogelijkheden het meest waarschijnlijk was, dan had je dat wel aangegeven. En zoals je zegt, beide opties even proberen is eenvoudig, dus een efficiënte aanpak.

Dat heb ik om 00:31 uur inderdaad zo gedaan.
Ik heb die beide Microsoft richtlijnen voor IE11 betreffend selection en getSelection aan VirusTotal aangereikt, en de beide mogelijke opties voor aanpassing van de code, en erbij aangegeven dat wij het nog niet hebben getest, maar dat ik de informatie alvast wilde aanreiken zodat VirusTotal ermee aan de gang kon, in plaats van met de eerder door mij aan VirusTotal aangereikte misschien minder relevante bevindingen.
Daarmee ging ik voorbij aan onze eerder uitgesproken intentie om te wachten met berichten aan VirusTotal tot we wisten welke oplossing(en) werkt of werken. Dit om te voorkomen dat VirusTotal misschien onnodig aan de gang zou gaan met eerdere en misschien minder relevante bevindingen. Ik hoop dat je daar begrip voor hebt.

VirusTotal antwoordde inmiddels,

Geen mens kan alles weten. En ja, boeren-cluc-cluc-verstand komt altijd heel kundig over he, en het mooie is: het klopt nog vaak ook! Ik hoop dat het deze keer ook zo is. Ik schat die kans hoog in.
Maar oud indiaans spreekwoord zegt: "beter één oplossing in de hand dan de lucht van tien". hehehe.

Daar was ik inderdaad wat sceptisch over vannacht, kort nadat ik bericht 00:10 had gepost maar dat was natuurlijk nog niet zichtbaar, omdat het eerst nog langs de moderator moest. Ik vroeg me af of jouw vervroegde actie wel winst zou opleveren.

Over het algemeen sta je bij een "officiële" melding sterker met een geverifieerde oplossing waar ze niet om heen kunnen,
en daar waren we al zo dichtbij. Het is ook wel zo efficiënt om alles in één mail te zetten. Vinden bedrijven wel fijn.
De pech is alleen dat wij allebei geen W7/IE11 systeem tot onze beschikking hebben. (nou ja: jij op verre afstand?)
En als zoals in dit geval de urgentie niet bijzonder groot is (bij wijze van spreken: de wereld vergaat toch niet als het een dag later wordt?) dan zou ik persoonlijk de voorkeur hebben gegeven aan "ff wachten nog".
Aan de andere kant heb ik er wel begrip voor dat je virustotal alvast op het juiste spoor wilt zetten.

Maar hoe dan ook Spiff: gelet op het antwoord van virustotal in je bericht van 12:29 lijkt het niet verkeerd te zijn geweest.
Het maakt in ieder geval duidelijk dat virustotal achter de missie staat, zodat duidelijk is dat niemand bang hoeft te zijn om die twee meest voor de hand liggende oplossingen eventjes snel uit te testen. Ik ben wel erg benieuwd.

Mvg, cluc-cluc

Het duurde eventjes voordat ik tijd had, maar ik ga nu testen :-)

Het duurde toch iets langer als een paar minuten. Ik meld alvast dat het probleem niet is verholpen. Ik aanvulling met nadere omschrijving volgt dadelijk.

aanvulling 15-12-2014 17:12 uur.

Bij het wijzigen van het bestand VTExplorer.htm op de twee manieren zoals Anoniem, cluc-cluc omschrijft
of


Word bij het klikken op "Send URL to VirusTotal" het issue van het niet openen van een nieuw venster waarin de VirusTotal URL-scan plaats vind niet opgelost.

Wel veranderd na de hierboven genoemde wijziging in VTExplorer.htm, de melding die het F12-ontwikkelhulpprogramma's van IE geeft wanneer deze op de achtergrond is geopend en "Send URL to VirusTotal" wordt geprobeerd.

De melding die wordt weergeven is niet langer

SCRIPT5007: Kan de eigenschap createRange van een niet-gedefinieerde verwijzing of een verwijzing naar een lege waarde niet ophalen

maar is nu

SCRIPT438: De eigenschap of methode CreateRange wordt niet ondersteund door dit object
VTExplorer.htm regel 11 teken 1

Overigens wel nog mijn complimenten voor Anoniem, cluc-cluc en Spiff voor het harde werken om het VTexplorer issue met IE11 op te lossen.

@ _kraai__, 16:56/17:16 uur,

Heel hartelijk bedankt voor het testen.
Jammer dat de aanpassing het probleem niet oplost. Maar dat is natuurlijk belangrijk om te weten.

Ik hoop dat iemand misschien nog vervolgsuggesties heeft om het probleem op te lossen.
Zo niet, dan hoop ik dat VirusTotal het issue zelf weet te diagnosticeren en op te lossen.
Ik heb geen idee of VirusTotal daarvoor de deskundigheid in huis heeft, of dat VirusTotal de oorspronkelijke VTexplorer ontwikkelaar Sergio de los Santos, toentertijd van Hispasec Sistemas, kan inschakelen om het probleem met VTexplorer op te lossen.

Geweldige bijdrage, _Kraai_! Maar spijtig genoeg zijn we er dus nog net niet helemaal... :(
En toch voel ik dat we "warm" zijn, om niet te zeggen "heet" met het vinden van de oplossing.

"With a little help of google": kunnen je hier misschien nog wat mee _Kraai_? (als je tijd hebt)
http://stackoverflow.com/questions/19748500/unable-to-get-property-createrange-of-undefined-or-null-reference

Eén geval is daar opgelost door het laatste stuk

te vervangen door

Je kunt dit in ons geval voor elkaar krijgen door in de originele VTExplorer.htm
regel 10 "var sel = doc.selection;" helemaal te verwijderen.
En in regel 11 (die nu dus regel 10 is geworden) "var rng = sel.createRange();" te vervangen door


Gebruik bij voorkeur copy-paste en vergeet de punt-komma aan het einde van de regel niet
(maar daar lette je waarschijnlijk al heel goed op)

Mvg, cluc-cluc

En daar zijn we weer met nieuwe resultaten :-), echter helaas is het probleem nog niet opgelost. :-(


Ik heb in VTExplorer.htm de wijzigingen aangebracht die jij beschreef, cluc-cluc. het resultaat is nu dat wanneer op "Send URL to VirusTotal" wordt geklikt er een venster verschijnt met het volgende bericht:

-----------------------------------------
Bericht van de webbpagina

Sorry some error happened...
----------------------------------------

Maar nu staat een stukje code volgens mij op de volgende plaats in VTExplorer beschreven wat voor het bovenstaande bericht van de webpagina bericht zorgt:


Nu vraag ik mij alleen af, wat gaat er fout waardoor dit bericht verschijnt?

Als ik het F12-ontwikkelhulpprogramma's op de achtergrond geopend heb en op "Send URL to VirusTotal" klik, verschijnt er geen venster meer met een foutmelding. (Wel gewoon het venster met "bericht van de webpagina").

Die melding "Sorry some error happened" verschijnt bij een 'normaal'/'correct' werkende VTexplorer een enkele keer bij sommige URL's en/of bij een tijdelijk probleem (de reden daarvoor heb ik nooit onderzocht en is me onbekend).
Dat 'hoort' dan zo.

Heb je het even later en met andere URL's opnieuw geprobeerd?

Blijft die melding "Sorry some error happened" ook even later en met andere URL's nog steeds verschijnen, dan is het probleem blijkbaar nog niet opgelost, maar dan lijken we er wel dichtbij te zitten.

Ik heb net even opnieuw geprobeerd of VTexplorer nu wel werkt zonder problemen, Spiff en ik heb ook andere URL's geprobeerd met "Send URL to VirusTotal" te scannen, maar helaas het probleem blijft zicht voordoen en er veschijnt gewoon weer een venster met "Sorry some error happened".


Of we dichtbij de oplossing zitten weet ik niet zo zeker. Ik denk namelijk dat het volgende het geval is (ik weet het niet zeker): IE loopt op regel 11 normaal vast. Die regel heb ik er nu eruit gehaald en vervangen door een ander stuk code welke betreft code waarschijnlijk goed is. Nu kan IE dus fijn verder gaan met het uitlezen van de code, alleen komt IE in eerste het stuk niets tegen waar het iets mee kan (een venster iopenen met de VirusTotal URL-scan), tot IE bij het stuk


uitkomt. Daar kan IE dus wel weer wat mee, namelijk het bericht van de webbpagina laten zien met "Sorry, some error happened" laten verschijnen :-)

Ik kan zelf namelijk ook even snel een html bestandje in elkaar zet, met de volgende code erin ;-)


En met vervolgens als resultaat als ik dat bestand open in IE, ik een venster te zien krijg met "sorry some error happened".

wijziging 16-12-2014 10:13 correctie typfouten.

In principe kon men regel 10 ook laten staan. Het is dan een loze regel geworden, want var "sel" wordt nergens meer gebruikt. Maar ik verwacht niet dat het iets uit zal maken. In de kern sluit ik wat je verder suggereert niet uit.

Het lijkt er in ieder geval op dat het script nu wel IE11-compatible is, want er verschijnt geen foutmelding meer met F12.
Da's mooi. Heel mooi. Maar nu moet het nog wel even goed gaan werken natuurlijk.

Als ik het zo "quick and dirty" bekijk, dan zou het bijv. kunnen dat www.virustotal.com geen respons of misschien een "lege" respons geeft. Of kan het zijn dat er iets mis is met de verzenddata (bijv. doordat vanwege de codewijziging er eerder in het script nu iets niet helemaal in de haak is???), wat dan weer zou kunnen leiden tot een ongewone reactie van www.virustotal.com.

Misschien nog even controleren of "www.virustotal.com" in je browser intikken wél een normale respons geeft?
Probeer VTExplorer ook voor de zekerheid nog even met Javascript in de browser aan/enabled (als dit nog niet aanstond...; ik vind het nog steeds wat raar dat bij mijn testje javascript niet nodig bleek, of ik moet me hebben verkeken)
Voor nu dank voor het fijne teamwork! Ik laat het even bezinken, en misschien een "spoedcursus javascript" volgen. ;-)

Mvg, cluc-cluc

Ik weet het ook niet zo zeker.
Misschien drukte ik me eerder te optimistisch uit ...
Ik hoop echter nog steeds dat iemand - jij, of cluc-cluc, of iemand anders - misschien nog vervolg-ideeën heeft om het probleem op te lossen. Zo niet, dan hoop ik dat VirusTotal het issue zelf weet op te lossen.

Net even een spoedcursus gedaan... (kleintje maar) ;-)....Wat wij afgaande op het geslaagde voorbeeld van http://stackoverflow.com/questions/19748500/unable-to-get-property-createrange-of-undefined-or-null-reference
nog zijn vergeten is "window"... Probeer daarom het blok:


eens te vervangen door:


Wat het VTExplorer.htm-script in feite doet, is de URL die jij aanklikt doorseinen naar www.virustotal.com,
waarop www.virustotal.com antwoordt met het resultaat dat door het script in een nieuw window wordt weergegeven.
De "sleutel" van de oplossing is dat we in IE11 niet meer "selection" mogen gebruiken, maar "getSelection".
Echter hoe één en ander nu precies aan elkaar moet worden geregen, is me nog steeds wat duister.

Maar we kunnen desnoods nog proberen om daar wat makkelijker achter te komen, door het script zo aan te passen
dat we de URL niet naar www.virustotal.com sturen, maar in een nieuw window op het beeldscherm laten verschijnen.
Dan kun je namelijk goed zien of er inderdaad netjes die aangeklikte URL in beeld komt of niet.
Zo niet, dan moeten we in het eerste blok de dingen dus anders aan elkaar rijgen. Net zolang totdat het keurig in beeld verschijnt, en dan weet je dat het goed zit, en dat het eerste blok van de code in orde is. Snappu?
Daarna plakken we de originele code die het naar www.virustotal.com moet sturen er weer aan vast, en dan is de kans alweer een stuk groter dat het werkt. En goed nieuws: "getSelection" zou ook al in IE9 zou moeten werken, dus Spiff kan ook meekijken/meetesten/mee-experimenteren! (helaas kom ik met m'n ouwe meuk niet verder dan IE8)
Maar probeer eerst bovenstaande suggestie eens als je wil?

Mvg, cluc-cluc.

@ cluc-cluc, 02:45 uur,

Dankjewel, ik heb zonet je suggestie van 02:45 uur getest met IE9.
Dat werkt nog niet, jammer genoeg.

Wel zie ik een merkwaardig verschil:
-
Checkte ik de URL die je 02:45 uur vermeldde of een andere URL hier op Security.nl, dan leverde dat een "Sorry some error happened" melding.
F12-ontwikkelhulpprogramma's (F12 Developer Tools) vindt geen fouten.
-
Checkte ik echter een URL in een lijst van favorieten etc. die ik bewaar in mijn webmail, dan volgde in het geheel geen reactie bij "Send URL to VirusTotal".
F12-ontwikkelhulpprogramma's (F12 Developer Tools) vermeldt nu:
SCRIPT438: De eigenschap of methode getSelection wordt niet ondersteund door dit object
VTExplorer.htm, regel 11 teken 1
-
Een merkwaardig verschil, waar ik nog geen verklaring voor zie.

En je schreef,
"En goed nieuws: "getSelection" zou ook al in IE9 zou moeten werken"
Hee, dat had ik eerder niet begrepen.
Als dat zo is, dan zou VirusTotal dus niet twee verschillende VTexplorer installers hoeven te gaan aanbieden, maar dan zou één aangepaste installer die een aangepaste variant van VTExplorer.htm biedt voldoende moeten zijn.
Maar dan moeten we natuurlijk eerst nog wel zien uit te vogelen wat er aangepast moet worden ...


Edit 13:04 uur: aangevuld met de F12 fout-informatie

@spiff en cluc-cluc Ik begrijp dus dat het niet nodig is dat ik het voorstel van 16-12-2014 02:45 uur ga testen?


Die melding kreeg ik bij een eerdere test (zie mijn reactie van 16-12-2014 16:56 uur.

correctie 17-12-2014 Ik doelde eigenlijk op mijn post van 15-12-2014 16:56, maar die had betrekking createRange en niet op getSelection. Excuses voor de eventuele verwarring die dit heeft veroorzaakt.

Bedoel je soms zoiets als het onderstaande, cluc-cluc?


Als ik een .html bestand maak met de bovenstaande code erin, en ik klik op de button, opent er netjes een nieuw tabblad waarin https://www.security.nl wordt geladen.

Ik weet het niet.
cluc-cluc gaf aan dat "getSelection" ook al in IE9 zou moeten werken.
Ik geloof dat graag, en in dat geval lijkt het me niet nodig dat jij hetzelfde ook nog in IE11 test.
Of het ook werkelijk correct is dat de code met "getSelection" ook al in IE9 werkt, dat weet ik niet. Ik weet niet of cluc-cluc zich daarbij kan vergissen.

Ik heb het even voor de zekerheid uitgeprobeerd, maar helaas bij mij ook geen resultaat.

Verder heb ik nog geprobeerd in VTExplorer.htm


vervangen door


zorgde er dan voor dat http://www.virustotal.com opent in een nieuw venster als op "Send URL to VirusTotal" wordt geklikt. Alleen wordt de URL niet automatisch meteen gescand, maar moet je die dus eerst nog een kopiëren en vervolgens plakken. Dit werkt dus ook niet, om een nieuw venster te openen waar de VirusTotal URL-scan in plaats vindt.

Goed bezig lui, om zo even te brainstormen! Ik ga nu (nog?) niet overal op in, anders wordt het zo lang.
Wel vind ik het belangrijk om zeker te weten dat IE9 compatible is met getSelection, zoals ik dacht op te maken
uit het grote "IE 9 icoon" bovenaan deze link: http://msdn.microsoft.com/en-us/library/ie/ff975169(v=vs.85).aspx
Dat betekent natuurlijk niet dat IE9 perfect werkt met onze aangepaste VTExplorer, maar dat je vergelijkbare resultaten mag verwachten met de test van IE11 zoals aangegeven in: Gisteren, 20:48 door _kraai__ - Bijgewerkt: Gisteren, 20:50
met die specifieke VTExplorer aanpassing. Is dat zo met IE9? Zo niet dan mogen we ons afvragen of het wel terecht is dat er een icoon van Internet Explorer 9 staat boven de genoemde informatiepage over "getSelect".

Ondertussen heb ik naar aanleiding van het onderzoek aan mijn kant het volgende verzoek:

@spiff:
Zou je misschien een testje met IE9 willen doen om wat specifieke info boven water te halen.
Ik wil onderzoeken of er misschien iets misgaat bij het bepalen van de zgn. "parameters".

Ik neem aan dat je al een backup van de originele VTExplorer.htm hebt. Zo niet dan even maken.
Wijzig twee dingen in de originele VTExplorer.htm:
1. Voeg direct boven de regel "http_request.open('POST', force_scan_url, false);" een nieuwe regel toe met:
2. voeg twee slashes toe aan het begin van de regel "http_request.send(parameters);" , dus dat wordt dan:

Sla deze wijzigingen in VTExplorer.htm op in de Program Files-enzovoorts-directory waar hij thuis hoort.
Test hierna via de rechtermuisknop "Send URL to Virustotal" deze link:
https://www.security.nl/posting/411290/VTexplorer+issue+IE11+x64

Als het goed is, opent zich een nieuw window. Het website Adres bovenin begint met:
De inhoud van de pagina (waarschijnlijk een fout) doet niet ter zake. Het gaat erom wat het volledige adres is.
(in URL-veld van de browser) Registreer en bewaar dat exacte volledige Adres (copy-paste), en noem het test A.
Negeer de foutmelding als deze slaat op de regel: "response = eval(http_request.responseText);".
Je mag het script gewoon afbreken. (eventuele andere foutmeldingen kunnen misschien nog wel interessant zijn)

Doe daarna hetzelfde uitgaande van een originele VTExplorer.htm, maar nu gemodificeerd volgens de aanwijzingen
van post "Gisteren, 18:40 door Anoniem" en gebruik weer exact dezelfde URL als bij test A om te testen.
Noem het resultaat test B.
Ik ben geïnteresseerd in eventuele verschillen, dus graag de resultaten even posten.
Als test A en test B exact gelijk zijn, dan kun je misschien ook nog eens dezelfde test doen met een originele
VTExplorer.htm die is aangepast volgens de post van "Vandaag, 02:45 door Anoniem", en noem die maar test C.

Verder ben ik benieuwd of VTExplorer ook werkt als je niet een embedded URL hebt, maar alleen de platte tekst.
Dus zo: https://www.security.nl/posting/411290/VTexplorer+issue+IE11+x64
Als je deze link highlight (linkermuisknop ingedrukt houden en dan muis over de URL-link slepen) en dan met de rechter
muisknop op de gehightlighte tekst klikt, heb je dan ook een optie voor "Send URL to Virustotal?"
En krijg je daarmee andere resultaten als je deze methode gebruikt bij de verschillende VTExemplaren die we tot nu toe hebben ontwikkeld? Ik ben weer erg benieuwd.

@_Kraai__:
Zie jij kans om hetzelfde te doen met IE11?

Mvg, cluc-cluc

@ Anoniem, cluc-cluc, 17:17 uur,


VTexplorer tests met IE9

Test o (nul)

Met ongemodificeerde VTExplorer.htm

Test met link in 17:17 uur bericht
https://www.security.nl/posting/411290/VTexplorer+issue+IE11+x64
openende VirusTotal pagina:
https://www.virustotal.com/nl/url/320f9c1ef4dfc32045218982f359299662646d5918fd27fd50a860383d3e5987/analysis/1418754118/

Idem met URL in platte tekst

Geen door F12-ontwikkelhulpprogramma's (F12 Developer Tools) gemelde fouten


Test A

Met VTExplorer.htm aanpassing di.16-12, 17:17 uur:

Uitgaand van originele VTExplorer.htm
1.
Voeg direct boven de regel "http_request.open('POST', force_scan_url, false);" een nieuwe regel toe met:
window.open(main_site+parameters,"_blank");
2.
voeg twee slashes toe aan het begin van de regel "http_request.send(parameters);" , dus dat wordt dan:
// http_request.send(parameters);

Test met link in 17:17 uur bericht
https://www.security.nl/posting/411290/VTexplorer+issue+IE11+x64
openende VirusTotal pagina:
http://www.virustotal.comforce=1&url=https//www.security.nl/posting/411290/VTexplorer+issue+IE11+x64

Idem met URL in platte tekst

Geen door F12-ontwikkelhulpprogramma's (F12 Developer Tools) gemelde fouten anders dan betreffend
response = eval(http_request.responseText);


Test B

Test B1

Met VTExplorer.htm aanpassing ma.15-12, 18:40 uur:

Uitgaand van originele VTExplorer.htm
1.
verwijder regel 10 "var sel = doc.selection;"
2.
in regel 11 (die nu dus regel 10 is geworden)
vervang "var rng = sel.createRange();" door:
var rng = doc.getSelection();

Test met link in 17:17 uur bericht
https://www.security.nl/posting/411290/VTexplorer+issue+IE11+x64
resultaat:
Sorry, some error happened...

Idem met URL in platte tekst


Test B2

Uitgaand van B1
met daarop tevens toegepast de bewerking van A

Test met link in 17:17 uur bericht
https://www.security.nl/posting/411290/VTexplorer+issue+IE11+x64
openende VirusTotal pagina:
http://www.virustotal.comforce=1&url=undefined/

Idem met URL in platte tekst


Test C

Test C1

Met VTExplorer.htm aanpassing di.16-12, 02:45 uur:

Uitgaand van originele VTExplorer.htm

<script language="JavaScript">
var main_site = "http://www.virustotal.com";
var force_scan_url = main_site + "/url-scan/was_url_analysed.json";
var parentwin = external.menuArguments;
var doc = parentwin.document;
var sel = doc.selection;
var rng = sel.createRange();
var str = new String(rng.text);
if (str.length <=0)

vervangen door:

<script language="JavaScript">
var main_site = "http://www.virustotal.com";
var force_scan_url = main_site + "/url-scan/was_url_analysed.json";
var parentwin = external.menuArguments;
var spiff = window.parentwin
var doc = spiff.document;
var rng = doc.getSelection();
var str = new String(rng.text);
if (str.length <=0)

Test met link in 17:17 uur bericht
https://www.security.nl/posting/411290/VTexplorer+issue+IE11+x64
resultaat:
Sorry, some error happened...

Idem met URL in platte tekst


Test C2

Uitgaand van C1
met daarop tevens toegepast de bewerking van A

Test met link in 17:17 uur bericht
https://www.security.nl/posting/411290/VTexplorer+issue+IE11+x64
openende VirusTotal pagina:
http://www.virustotal.comforce=1&url=undefined/

Idem met URL in platte tekst


[Edit 21:18 uur: aanpassing van de weergave van test-resultaten naar bold/vet]

@ spiff in reactie op [urlhttps://www.security.nl/posting/411290#posting412154[/url]

Dit is volgens mij hetzelfde verschijnsel als _Kraai__ rapporteerde met zijn IE11 browser in deze posting: https://www.security.nl/posting/411290#posting412055
Bij de allerlaatste VTExplorer modificatie (object "window" toevoegen) lijkt _Kraai__ aan te geven,
dat er eigenlijk niets is veranderd. Dus nog steeds "Sorry, some error happened..."
De IE9 browser reageert dan dus net zo als de IE11 browser, en zijn op dit punt vergelijkbaar.
Als IE9 niet kan omgaan met het nieuwe "getSelect", dan had je daar een specifieke error voor gekregen.

Dus inderdaad grote kans dat een VTExplorer.htm die weer functioneert met IE11, ook zal werken met IE9.
Dat je bij eerste modificatie nog wel een fout in IE9 had (het niet-niet verhaal) zal zijn gekomen doordat
ik getSelect toen nog niet op een behoorlijke manier in het script had weten te ïmplementeren.
Ook Kraaij had toen in de IE11 met die VTExplorer-versie zo'n fout.


Dat zal te maken hebben met de "object oriented struktuur", waarbij het kan voorkomen dat sommige objecten met hun specifieke eigenschappen en methoden niet goed kunnen samenwerken met andere objecten met weer andere eigenschappen en methoden. Dit kan een probleem zijn. In IE9 kun je misschien voor zoiets een "if-then" verzinnen
om zo'n object met een oude bekende ondersteunende struktuur te verbinden. ("selection" gebruiken?)
Want als ik het goed begrijp kan IE9 overweg met zowel methode "selection" als met methode "getSelection"
Maar bij IE11 kon dat wel eens lastig worden, want IE11 ondersteunt methode "selection" dus niet meer.
Dat is nu ook juist waarom we problemen hebben met VTExplorer, waarin dus de voor IE11 vereiste "getSelect" methode met eventueel omringende structuur (nog) niet is ingebakken... ;-)

Mvg, cluc-cluc

Hai cluc-cluc,
Bedankt voor je reactie van 20:47 uur.
Waarschijnlijk heeft die mijn reactie van 20:43 uur net gekruist.
Ik ben benieuwd wat je kunt afleiden uit mijn test-resultaten van 20:43 uur.

Alle kleine beetjes helpen, maar momenteel zou ik liever eerst snel boven water krijgen welke waarde "parameters" krijgt,
en welke invloed de verschillende versies van VTExplorer daarop hebben, voor een beter begrip of en hoe zaken precies
op elkaar inwerken. Zie: https://www.security.nl/posting/411290#posting412199
Als we door nauwkeurige waarneming dingen wat beter begrijpen, dan kunnen we ze ook gemakkelijker oplossen.

Nietes hoor ;-P
Het was 15-12-2014 16:56, en daar had de fout betrekking op createRange en niet op getSelection...

Kleine details kunnen groot verschil maken. Daar verkijkt men zich vaak op.
De horde van createRange hebben we al genomen. Die is fout nu weg. We zijn echt wel vooruitgekomen.
Maar het is niet de enige horde, en de zaken zijn complex.
Het neigt iets meer naar een verbouwing dan naar het ophangen van een schilderij.

Het punt is nu dat "Sorry, some error happened..." er op wijst dat (response[0] == 1) "false" is,
terwijl dat normaalgesproken "true" zou moeten zijn, zodat er een nieuw window wordt geopend.
Element response[0] acht ik afkomstig van de regel ervoor: "response = eval(http_request.responseText);"
hetgeen op zijn beurt weer een antwoord is van www.virustotal.com op de regel dáár weer voor,
te weten: "http_request.send(parameters);"

Nu luidt er een oud indiaans gezegde: "beroerde vraag, beroerd antwoord".
Daarom ben ik razend benieuwd of "parameters" in "http_request.send(parameters)" wel een zinnige waarde hebben.
Als de verstuurde informatie beroerd is, dan krijg je immers een beroerd antwoord terug dat tot de error leidt.
Zo kunnen we er achter komen in welk deel van het script we de fout wel of niet moeten zoeken.
Zoiets heet ook wel "troubleshooting". (of "troepschieten" voor ingewijden ;-)
Daarvoor heb ik dus het truukje van https://www.security.nl/posting/411290#posting412199 bedacht.
Want "parameters" verschijnt zodoende namelijk in de url balk onmiddellijk achter "http://www.virustotal.com"...
En dan hebben we goed zichtbaar gemaakt wat we maar beter goed zouden moeten weten.
Hopelijk om het daarna spoedig op te kunnen lossen, maar in ieder geval om weer een stap verder te komen.

Mvg, cluc-cluc.

Hee Spiff... Top! Heeft elkaar inderdaad gekruist, terwijl ik bezig was om nog iets te beantwoorden.
Ziet er op het eerste gezicht veelbelovend uit en lijkt iets van (veel van? alles van?!...) mijn vermoedens te bevestigen.
Ik ga z.s.m. analyseren en uitvogelen wat er precies aan de hand zou kunnen zijn, en hoop dat _Kraai__ ook nog zoiets
kan aanleveren uit zijn IE11 systeem ter vergelijking en verificatie.
Kan nog een behoorlijke uitzoekerij zijn, maar streef naar een eerste inhoudelijke reactie morgen later op de dag.
Het bericht wat er zonet ook nog uitging helpt jullie misschien al wat meer inzicht geven, en ook nog wat te overpeinzen. ;-)

Mvg, cluc-cluc

Uitstekend,
alvast bedankt weer.

Off topic PSje
Steeds al eens willen vragen -
is u ook familie van Klukkluk?
Aanvulling wo.17-12:
Excuus voor m'n domme of zelfs vervelende off topic vraag van 21:54 uur, of cluc-cluc familie is van Klukkluk.
Of de naam nou cluc-cluc is of Klukkluk - Klukkluk was de eerste indiaan in m'n leven en ik heb daar warme herinneringen aan, het was een lieve man. (Pipo daarentegen herinner ik me als een beetje eng, zoals alle clowns.) Inmiddels is Klukkluks typetje nogal uit de tijd, als cliché van een domme en onhandige indiaan (zoals Wikipedia dat omschrijft, en 'politiek incorrect'), maar toentertijd gold zoiets natuurlijk nog niet.
Je naam cluc-cluc herinnert me nog altijd aan de Klukkluk van toen, en daar ben ik zowel jou als Herbert Joeks dankbaar voor.

alsjeblieft, cluc-cluc de resultaten van de testen waar je om vroeg in je reactie van 16-12-2014.

Test A

VTExplorer.htm met daaraan gewijzigd boven de regel ""http_request.open('POST', force_scan_url, false); een nieuwe regel window.open(main_site+parameters,"_blank");

en twee slashes toegvoegd aan het begin van de regel "http_request.send(parameters);" en is nu dus
[/b]//http_request.send(parameters);[/b]

de resultaten zijn wanneer metde link https://www.security.nl/posting/411290/VTexplorer+issue+IE11+x64wordt getest:

alleen een twinkeling van IE11 er opent zich geen nieuw venster met daarin
Door F12-ontwikkkelhulpprogramma's wordt de fout: "SCRIPT5007: Kan de eigenschap createRange van een niet-gedefinieerde verwijzing of een verwijzing naar een lege waarde niet ophalen"

Test B1


VTExplorer.htm met daaraan gewijzigd
regel 10 "var sel = doc.selection;" verwijderd en regel 11 "var rng = selcreateRange();" vervangen door var rng = doc.getSelection();

+ de bewerkingen van A

de resultaten zijn wanneer met de link https://www.security.nl/posting/411290/VTexplorer+issue+IE11+x64wordt getest:

een nieuw venster werd geopend met in de adresbalk
http://www.virustotal.comforce=1&url=undefined/

Door F12-ontwikkkelhulpprogramma's wordt de volgende fout gemeld:

SCRIPT10: De gegevens die nodig zijn voor deze bewerking zijn nog niet beschikbaar.
VTExplorer.htm, regel 41 teken 5

Test B2

URL in platte tekst verder hetzelfde als in B1

resultaat:

een nieuw venster werd geopend met in de adresbalk
http://www.virustotal.comforce=1&url=undefined/

test C1

VTexplorer.htm met daaraan gewijzigd

<script language="JavaScript">
var main_site = "http://www.virustotal.com";
var force_scan_url = main_site + "/url-scan/was_url_analysed.json";
var parentwin = external.menuArguments;
var doc = parentwin.document;
var sel = doc.selection;
var rng = sel.createRange();
var str = new String(rng.text);
if (str.length <=0)

vervangen door

<script language="JavaScript">
var main_site = "http://www.virustotal.com";
var force_scan_url = main_site + "/url-scan/was_url_analysed.json";
var parentwin = external.menuArguments;
var spiff = window.parentwin
var doc = spiff.document;
var rng = doc.getSelection();
var str = new String(rng.text);
if (str.length <=0)

+ de bewerkingen van A

de resultaten zijn wanneer met de link https://www.security.nl/posting/411290/VTexplorer+issue+IE11+x64wordt getest:

een nieuw venster werd geopend met in de adresbalk
http://www.virustotal.comforce=1&url=undefined/

Door F12-ontwikkkelhulpprogramma's wordt de volgende fout gemeld:

SCRIPT10: De gegevens die nodig zijn voor deze bewerking zijn nog niet beschikbaar.
VTExplorer.htm, regel 42 teken 5

Test C2

URL in platte tekst verder hetzelfde als in C1.

resultaat:

een nieuw venster werd geopend met in de adresbalk
http://www.virustotal.comforce=1&url=undefined/

Oeps, excuses een slordig foutje van mij

aanvulling 17-12-2014 13:11 uur Ik heb mijn bijdragen van 15-12-2014 16:56 nog even voorzien van een correctie.

@ _kraai__, 08:00 uur,
Dankjewel voor het testen.
Ik hoop dat cluc-cluc met ons beider testverslagen weer een stapje verder komt.

@ cluc-cluc,
Excuus voor m'n domme of zelfs vervelende off topic vraag van gisteravond 21:54 uur, of cluc-cluc familie is van Klukkluk.
Of de naam nou cluc-cluc is of Klukkluk - Klukkluk was de eerste indiaan in m'n leven en ik heb daar warme herinneringen aan, het was een lieve man. (Pipo daarentegen herinner ik me als een beetje eng, zoals alle clowns.) Inmiddels is Klukkluks typetje nogal uit de tijd, als cliché van een domme en onhandige indiaan (zoals Wikipedia dat omschrijft, en 'politiek incorrect'), maar toentertijd gold zoiets natuurlijk nog niet.
Je naam cluc-cluc herinnert me nog altijd aan de Klukkluk van toen, en daar ben ik zowel jou als Herbert Joeks dankbaar voor.

@spiff en _Kraai__
Mij zijn u allen zeer van den dankerige voor het aanleveren van deze bijzonder interessante info! :-)

Het is mij nu wel duidelijk dat de implementatie van "getSelect" anders moet.
Het blijft een beetje een gok, maar zou je het volgende eens willen proberen
en evt. foutmeldingen doorgeven als het niet mocht werken:

Vervang in de originele VTExplorer.htm het hele blok met "var" (7 regels) eens door het volgende blok:


Mvg, cluc-cluc

Ook dat werkt nog niet, met IE9.
F12-ontwikkelhulpprogramma's (F12 Developer Tools) vermelding:

SCRIPT438: De eigenschap of methode getRangeAt wordt niet ondersteund door dit object
VTExplorer.htm, regel 11 teken 1
-->
var rng = sel.getRangeAt(0);

P.S.
cluc-cluc,
je gaf eerder aan slechts IE8 tot je beschikking te hebben.
VTexplorer werkt voor IE8 hetzelfde als voor IE9.
Je zou het dus zelf ook kunnen testen. Niet of het voor IE11 nu goed functioneert, maar wel of het tenminste werkt voor IE8 en IE9. Al vermoed ik dat je IE8 op een Windows XP installatie zult hebben. Ga je daarmee (wijselijk) niet meer het web op, dan kun je het functioneren van VTexplorer voor IE8 daarmee dus niet controleren. Uiteraard test ik je bedenksels graag voor je, dus dat is geen probleem.

Jammer... en een beetje onverwacht ook. Nog even afwachten of dit bij _Kraai__ met IE11 hetzelfde is.
Ik heb wel begrepen dat de ondersteuning van IE9 op sommige punten minder ver gaat dan in IE11, dus wie weet.

Uiteraard. Probleem is alleen dat "getSelect" pas vanaf IE9 wordt ondersteund... :-(
Mvg, cluc-cluc

Bij testen treed de 'twinkeling' op van IE11 als geprobeerd wordt een URL te scannen.

F12ontwikkelhulpprogramma's vermeld:

SCRIPT438: De eigenschap of methode getRangeAt wordt niet ondersteund door dit object
VTExplorer.htm, regel 11 teken 1

Dus ook bij IE11...
Maar ik denk dat ik intussen al weet waar dit door komt.
getSelect heeft nog een beetje "lijm" van het HTMLSelection object nodig.
Het hele "var-blok" (7 regels) moet dan vervangen worden door dit blok (8 regels):


Ik hoop dat het nu beter gaat.

@spiff: wat ik zei over die ietwat beperkte ondersteuning voor IE9 blijkt bijv. uit de "Remarks" die je hier kunt lezen:
http://msdn.microsoft.com/en-us/library/ie/ff975177(v=vs.85).aspx

Mvg, cluc-cluc

Ah, dank je, sorry, dat had ik over het hoofd gezien.

Ook dat werkt nog niet, met IE9.
F12-ontwikkelhulpprogramma's (F12 Developer Tools) vermelding:

SCRIPT5007: Kan de waarde van de eigenschap getRangeAt niet ophalen: het object is null of niet gedefinieerd
VTExplorer.htm, regel 12 teken 1
-->
var rng = glu.getRangeAt(0);

Ach, natuurlijk. Er moet immers eerst een range worden gecreëerd en niet opgehaald.
De oude methode gebruikte hiervoor "createRange()", maar dat is niet meer geldig.
Dat zal dan voor het HTMLSelection object waarschijnlijk "addRange()" zijn geworden.
Als je die hele ene regel waarin "getRangeAt(0)" staat nu eens vervangt door deze regel:


En dan nog eens probeert?

Mvg, cluc-cluc

plus

Ook dat werkt nog niet, met IE9.
F12-ontwikkelhulpprogramma's (F12 Developer Tools) vermelding:

SCRIPT5007: Kan de waarde van de eigenschap addRange niet ophalen: het object is null of niet gedefinieerd
VTExplorer.htm, regel 12 teken 1
-->
var rng = glu.addRange();

hmmmm... flauw hoor. Het zit niet echt mee geloof ik.
Maar de ideeënbus is nog niet leeg gelukkig.
Het kan haast niet anders of het zal ons gaan lukken!

Vervang in de originele VTExplorer.htm het hele "var" -blok (7 regels) eens door het volgende blok:


Mvg, cluc-cluc

P.S.: ik zet de champagne vast klaar. ;-)

Dat levert een interessant resultaat.

Bij het in IE9 toepassen van VTexplorer "Send URL to VirusTotal" op de link https://www.security.nl/posting/411290/VTexplorer+issue+IE11+x64 hier op deze pagina, leidt dat correct tot het openen van een VirusTotal URL-scan pagina:
https://www.virustotal.com/nl/url/320f9c1ef4dfc32045218982f359299662646d5918fd27fd50a860383d3e5987/analysis/1418900790/

Maar ... houd de champagne toch nog maar even dicht.
Want bij het toepassen van VTexplorer "Send URL to VirusTotal" op een URL zoals ik die heb staan in een opgeslagen 'mail' met een lijst van favorieten etc. in mijn webmail, is de reactie heel anders:

Bij het vanuit mijn webmail toepassen van VTexplorer "Send URL to VirusTotal" op bijvoorbeeld
https://www.ncsc.nl/rss/beveiligingsadviezen
of http://www.ghacks.net/
is het resultaat dat géén VirusTotal URL-scan pagina opent,
en de volgende F12-ontwikkelhulpprogramma's (F12 Developer Tools) vermelding wordt gegeven:

SCRIPT438: De eigenschap of methode getSelection wordt niet ondersteund door dit object
VTExplorer.htm, regel 10 teken 1
-->
var rng = doc.getSelection();

Daarnaast
is deze variant ook nog niet getest in IE11, dus is nog onbekend of het daarin wel werkt.


Verder/ P.S./ N.B. 1
Ik heb vandaag een drukke dag, en daardoor beperkt gelegenheid voor tests.
Nog eentje, of twee, dat lukt misschien wel, maar ik kom dan misschien pas laat op de dag met uitkomsten.

Verder/ P.S./ N.B. 2
De volgende dagen heb ik even helemaal niet de gelegenheid om mee te denken, laat staan te testen.
Wanneer ik een aantal dagen later weer de gelegenheid heb om mee te denken, dan zal ik even bijlezen in de ontwikkelingen in deze thread en me zo nodig melden voor nieuwe tests.

Warempel... Echt waar?... Hyperdepieperdepieperdepiep... Ooodzjiiieeeennn!
Hold on for one more day and It feels like magic... "Change has come!"... Finally
Ik heb goeie hoop dat het nu bij _Kraai__ in IE11 ook goed gaat.

Ja, daar heb ik al eens op geantwoord in: https://www.security.nl/posting/411290#posting412216
Dat los je misschien niet zomaar op. Vrijwel alles is uiteindelijk op te lossen, maar ik sluit niet uit dat het nog een hele klus kan worden, en dat we dan nog wel een tijd bezig zijn met het "try and error until succesful" zoals de laatste dagen. De vraag is of dat allemaal de moeite waard is als het met alle andere gebruikelijke dingen goed werkt?
En natuurlijk ook belangrijk: werkte deze optie met favorieten in webmail met de originele VTExplorer dan wel goed?

We kunnen bijv. ook afspreken: we proberen het op te lossen, maar als we het dit jaar niet weten op te lossen, dan kappen we ermee. (en het kan dan ook wel eens een dag stil liggen omdat iemand van ons andere dingen heeft te doen)
Wat jij en _Kraai__ willen. Mij maakt het niets uit. Zelf gebruik ik VTExplorer eigenlijk niet.
Ik help puur voor de sport, en om er zelf wat van op te steken.

Eerst maar even afwachten wat er bij _Kraai__ met IE11 nu wel en niet goed gaat met de laatste aanpassing?
_Kraai__, ben je bereid om de nieuwe VTEplorer uitvoerig te testen met IE11? (dus bijv. functioneert het behalve vanuit een HTML/web-pagina ook goed vanuit een .pdf of word-document etc. met zowel de "direct URL" methode als met het highlighten van tekst?)

Mvg, cluc-cluc

O ja, één ding twijfel ik nog wat aan:
of het uitmaakt en of het beter is om van regel 12 van de nieuwe code eventueel nog het volgende te maken:
var str = new String(rng.toString().text);
(dit zal naar verwachting niet het webmail probleem oplossen, maar wie weet komen er bij het testen nog andere dingen
aan het licht, en dan kun je even proberen of dit misschien nog wat uitmaakt)

Ik denk dat het wel verstandig is om ook dat op te lossen, omdat het wel zo netjes is dat VTexplorer ook functioneert met URL's in webmail e-mailtjes

Beslist.
Anders zou ik er niet over mekkeren.
Voor mij is het een aanwijzing dat het met al het puzzelen wellicht de goeie kant op gaat [N.B. even een test van _kraai__ met IE11 afwachten], maar dat de code nog niet zo is dat we die aan VirusTotal kunnen aanreiken. Daartoe zou het toch ook wel moeten functioneren in situaties zoals die webmail situatie die ik beschrijf.

Het beste zou het misschien zijn wanneer VirusTotal's software ontwikkelaars de tijd vinden om VTexplorer eens grondig onder de loep te nemen. Daar moeten ze dan echter wel eerst de tijd voor vinden. Zoals een paar dagen geleden bericht werd, "VirusTotal is a small team, and about half of the team here is on vacation so please be patient."
Ik heb in vervolg daarop ook gevraagd of de oorspronkelijke VTexplorer ontwikkelaar Sergio de los Santos (in 2011 bij Hispasec Sistemas) nog altijd ook voor VirusTotal werkt en beschikbaar is om een kijkje te nemen naar het VTexplorer en IE11 issue. Dat zou wellicht het allerbeste zijn. Daar heb ik echter nog geen antwoord op ontvangen.

Mooi, cluc-cluc, ik nam al aan dat je het alleen doet voor de sport en om er van te leren.
Ik waardeer dat zeer.
En VirusTotal vast ook, wanneer we op een gegeven moment een geslaagde oplossing weten aan te reiken.
Wanneer je op een gegeven moment wilt kappen met puzzelen, dan is dat volkomen terecht, en uiteraard aan jou om te beslissen (en ook aan _kraai__, en andere meedenkers).
De deadline 31 december is prima voor mij, we kunnen er immers niet maanden mee door blijven gaan.
Ik heb echter best hoop dat met ons testen, en hopelijk ook met onderzoek door de VirusTotal developers, voor die tijd een nette oplossing gereed kan zijn.

Dat is goed, dat zal ik later vandaag even testen.
Ik moet nu eens rennen, ik had eigenlijk al geen tijd voor deze reactie, oei ;-)

Tot later vandaag.

Um,
je bedoelt ter vervanging van
var str = new String(rng.toString());
denk ik?
Dat is niet regel 12 maar 11 van de code zoals volgens je suggestie van gisteravond 17-12, 21:29 uur.

Ik probeer het zo meteen gelijk nog even.
(Moet ik straks alleen nog wat harder rennen ;-)

plus

Bij het in IE9 toepassen van VTexplorer "Send URL to VirusTotal" op de link https://www.security.nl/posting/411290/VTexplorer+issue+IE11+x64 hier op deze pagina,
leidt dat tot de melding:

Sorry, some error happened...


Bij het vanuit mijn webmail toepassen van VTexplorer "Send URL to VirusTotal" op bijvoorbeeld
https://www.ncsc.nl/rss/beveiligingsadviezen
is het resultaat de volgende F12-ontwikkelhulpprogramma's (F12 Developer Tools) vermelding:

SCRIPT438: De eigenschap of methode getSelection wordt niet ondersteund door dit object
VTExplorer.htm, regel 10 teken 1
-->
var rng = doc.getSelection();


(Nu rennen, vliegen, etc. ;-)

Ehm... ja, dat klopt! (bij jou dan)
In mijn versie had ik al "een puntje op de i gezet" door een vierde commentaarregel bij te voegen met:
Even niet bij stilgestaan bij het tellen. ;-)

Aha! Lijkt me dat we op grond hiervan die optie dan bij voorbaat al helemaal kunnen laten vervallen.
Heeft dus hoogst waarschijnlijk geen zin om nog te proberen ".text" achter "toString()" te plakken als het zo mocht zijn
dat er bij _Kraai__ nog steeds iets niet helemaal naar behoren zou werken in IE11 met de VTExplorer versie volgens
https://www.security.nl/posting/411290/#posting412397
Dus ik hoop wel dat het allemaal direct normaal werkt in IE11 _Kraai__! ;-)

Dit was geheel naar verwachting. Hetzelfde als zonder die ".text". Zodra je weer online bent hoor ik wel of je het er
voor over hebt om er nog energie in te steken om te proberen die manier van gebruik ook nog op te lossen.
Ik denk wel dat het lastiger wordt dan wat we tot nu toe hebben gedaan, en een stuk waarschijnlijker dat het ons niet lukt.
Maar niet geschoten is altijd mis.
Om te beginnen zul je me dan moeten uitleggen wat je exact bedoelt, want dat kan ik zo niet zien
en ik ben nog van de rooksignalen, en niet van de mail.;-)
Over wat voor webmail heb je het precies, en waar klik je dan precies op met VTExplorer?
Gaat het over een URL-link in een email? Of iets uit een dropdown menu? Etc.
Schets me nauwkeurig het plaatje in welke omgeving het te testen object is ingebed en hoe het er uit ziet,
en welke acties je doet om er bij te komen (nee, inloggegevens hoef ik uiteraard niet ;)
het gaat er om dat ik een juist beeld krijg van wat voor een type object het "programmeertechnisch" zou moeten zijn.

Ben verder wel benieuwd of _Kraai__ eenzelfde soort webmail gebruikt, en of hij dit probleem met IE11 ook heeft.
En verder of het "op alle mogelijke manieren" testen van VTExplorer nu naar behoren functioneert in IE11.
(in de versie volgens https://www.security.nl/posting/411290/#posting412397, dus zonder die ".text" erachter)

Pas je wel op? Je bent geen vliegtuig. ;)

Mvg, cluc-cluc

Voor die situatie met links in webmail-mails,
ja, dat wil ik ook graag werkend zien te krijgen, om de redenen die ik 15:48 uur aangaf.
Maar jouw puzzelen daarvoor moet je uiteraard enkel doen zolang je dat leuk vindt.
Eigenlijk horen de VirusTotal ontwikkelaars dit op te lossen, natuurlijk. Krijgen wij het al voor elkaar dan is dat voor iedereen leuk, maar het moet beslist geen belasting voor je worden, je moet alleen blijven puzzelen zo lang je het leuk vind.

Het betreft DDS-webmail, en daarvan de 'oude' interface.
Niet gratis, maar wel eventueel op proef te proberen, om het te kunnen bekijken. Maar dat gaat nogal erg ver, als je het enkel even zou willen bekijken.

En waarop klik ik dan precies met VTexplorer?
Op URL's in de tekst in de body van de mail die opgeslagen staat in mijn webmail mappen.
Dat werkte dus nog niet met de aangepaste VTexplorer scripts.

Of de aangepaste VTexplorer misschien wel werkte bij het checken van een ándere URL in mijn webmail, buiten de body van een mailtje, bijvoorbeeld een van de DDS-URL's in de webmail-interface, dat heb ik eerder nog niet getest. Dat is iets om over een paar dagen eens te testen met een potentieel levensvatbaar VTexplorer script.

Ik sluit overigens niet uit dat hetzelfde fenomeen van links in e-mail die niet te checken zijn door middel van de gemodificeerde VTexplorer varianten ook kan optreden met andere webmail dan DDS-webmail, en misschien ook wel met links in bepaalde webpagina's, we hebben ons immers nog zeer beperkt door voornamelijk steeds die Security.nl URL te gebruiken.

Wanneer ik over een aantal dagen weer tijd heb, dan zal ik de te testen potentieel levensvatbare VTexplorer scripts eens moeten testen met URL's op diverse sites, in mijn webmail-mail, in mijn webmail-interface, en zo mogelijk ook nog eens in bijvoorbeeld een Yahoo mail-accountje. Maar dat dus allemaal pas over een aantal dagen, zeker niet vanavond nog.

Na de huidige tussenlanding vlieg ik straks weer een eind op ;-)

Ok Spiff. We zullen zien hoe ver we komen.
In ieder geval heb je zelf alvast een VTExplorer die voor jouw eigen situatie de klus al goed klaart.
Namelijk gewoon de originele VTExplorer. ;-)
Maar nu eerst even pas op de plaats.

Dat er dingen zijn die nog steeds niet werken, zoals met die webmail, heeft m.i. te maken met objecten
die niet compatible zijn met getSelect. Dit staat los van een al of niet juiste implementatie van getSelect.
Immers voor objecten die wél compatible zijn met getSelect werkt het nu!
Wijd het webmailprobleem dus niet teveel aan getSelect of aan de implementatie van getSelect,
maar eerder aan het gebrekkige object (de link in webmail) dat blijkbaar niet in staat is om met getSelect om te gaan.

Laten we ondertussen niet vergeten dat we het voor IE11 doen, en niet de vergissing maken om klakkeloos aan te nemen
dat een Vista/IE9 systeem op alle fronten exact hetzelfde zou reageren als een W7/IE11 systeem.
Want als dat zo zou zijn, dan zou je geen problemen hebben ondervonden met VTExplorer op het systeem van je vriendin.

Belangrijk is daarom dat we nu eerst feedback krijgen over hoe de wijziging zoals voorgesteld in
https://www.security.nl/posting/411290/#posting412397 uitwerkt in een echt W7/IE11 systeem.
Na 100 postings raken we misschien het overzicht wat kwijt over het hoe en waarom, maar neem van mij aan:
we moeten nu weten of we het bij het rechte eind hadden dat toepassen van "getSelect" (inmiddels op een juiste manier geïmplementeerd) in IE11 op zijn minst iets heeft opgelost.
Zo niet, dan heeft het geen enkele zin om verder te gaan, want dan zit het 'm niet in getSelect, en is alles van de baan.

(@_Kraai__? Ben je er nog? Help je de zaak uit de brand? Zie je misschien kans om dit op korte termijn uit te proberen of er nu op zijn minst iets werkt? Dat zou wel heel erg fijn zijn.
Welke manieren van gebruik werken er in IE11 wel, en wat werkt er nog niet in deze VTExplorer versie?
Dit kunnen we niet goed testen op het systeem van Spiff, en ook ik heb de juiste middelen niet)

Mvg, cluc-cluc

@Cluc-cluc 19-122014 10:25 uur:

Ik ben ben er nog ja, helaas had ik gisteren en de dagen daarvoor het best wel druk, dus om gisteren nog te testen pf een reactie te plaatsen, is me helaas niet gelukt. Maar ik wil jullie absoluut niet laten zitten. Vanmiddag heb ik tijd om te testen, de resultaten zal ik uiteraard hier posten.

verder moest ik eerst even weer de berichten die jullie gisteren hadden gepost lezen, om weer bij te zijn

Maar Hopelijk ben je alvast gerustgesteld cluc- cluc :-) ik hoop da VTexplorer nu werk met IE11, dan is het klaar zetten van die shampagne niet voor niets geweest.

@Spiff hopelijk heb je jezelf nog niet gelanceerd met al dat rennen en vliegen ;-)

Grote klasse _Kraai__!
Alle begrip voor, geen enkel probleem. Was gewoon een beetje ongerust, en zaten even vast.
Weet nu dat ons bericht je heeft bereikt, en we wachten geduldig af.
Neem rustig alle tijd, en alvast heel erg bedankt. :-)

Mvg, cluc-cluc

Daar ben ik weer met niet test resultaten. Wat zal het zijn

[spannende toon]en van zijn 1 2 3 4[/spannende toon]

Schiet de kurk maar van de champagne fles af cluc-cluc, VTexplorer werk nu ook met URL's op webpagina's met IE11.


De bovenstaande aanpassing in VTExplorer lost het probleem op, en wanneer nu op "Send URL to VirusTotal wordt" geklikt, opent een nieuw venster met de VirusTotal URL-scan.

Mijn complimenten cluc-cluc

Ik ga vanmiddag nog wat meer testen doen, Ik maak gebruik van een webmail want rooksignalen gaat het bij mij niet worden ;-) (lees lukken)

.
Ik vind het goed om nog een tijdje verder te gaan met testen zodat VTexplorer helemaal correct werkt.

Mochten we de deadline van 31 december niet halen kunnen we nog altijd als goede voornemen voor 2015 nemen om dan VTexplorer wel helemaal correct werkende te krijgen ;-) Maar nu eerst even verder gaan met testen.

wijziging 19-12-2014 22:45 uur: correctie typo's en kleine wijziging in de formulering.

Inmiddels wat meer testen uitgevoerd, voor de webmail die ik gebruik, werkt VTexplorer ook.


Ook die knop heb ik inmiddels kunnen vinden op de opdrachtenbalk, Spiff en de website wordt gescand als ik er op klik.

OEAAAAAAAAAAAN - HUNDERD - EN - EEEEEETIIIIIE! ;-)))

YES! Laat de kurken maar knallen! Proost! (goeie oefening voor de jaarwisseling alvast - hehehe)
In Win7/IE11 functioneert het nu dus. Machtig mooi!
Onze inspanningen werpen hun vruchten af. De spijker op zijn kop. De oplossing was inderdaad getSelect.
En de aangepaste VTExplorer-versie is in deze vorm prima bruikbaar met Win7/IE11 als ik het goed begrijp.

En werkt het dan zowel met direct klikken op een URL als met selecteren van een site in plaintekst en daar dan
via rechtermuisknop op klikken en "Send URL to VirusTotal"? En dat ook nog vanuit bijv. een .pdf of office document?
Dan trekken we nog een extra fles sjampie open. ;-)

Helemaal geweldig ook dat het bij jou werkt in de webmail _Kraai__! Daar wordt een mens blij van. :-)
Maar ook wel weer merkwaardig dat dit bij Spiff niet goed ging. Maar dat was dan ook met IE9 en Vista.
En we hebben het script in de eerste plaats ontworpen voor IE11, omdat IE11 niet meer werkte met VTExplorer.
De rest kan het oude, originele VTscript blijven gebruiken, en misschien moet de Virustotal installer het maar regelen
welke variant er op een bepaald systeem wordt geïnstalleerd. In dat geval hoeven wij niet meer te klooien.
En dan kan ik aan de gang gaan met mijn nieuwe boek, getiteld:
"Hoe word ik een Software-Engineer in drie dagen, en hoe kom ik er weer van af." ;-P hihihi

Wat ik me nog afvroeg: zou het verschil in gedrag misschien ook kunnen komen doordat jij _Kraai__ webmail in
HTML mode gebruikt, en Spiff niet, of andersom? Maar het kan ook best iets anders zijn.
Bijvoorbeeld OS of browserversie, geïnstalleerde versie van de scriptaal e.d.

Nu eerst even weekend vieren? Daarna lees ik wel weer of er toch nog vervelende afwijkingen aan het licht zijn gekomen
(of juist niet...). Geniet er van!

Mvg, cluc-cluc

Beste iedereen,
Ik ben er weer, en heb de bijdragen vanaf vrijdag 19-12-2014, 10:25 uur, doorgenomen.
Heeft de sjampie jullie goed gesmaakt?

Geweldig!

Nu zal ik nog moeten testen of het in IE11 ook werkt met mijn DDS-webmail.
Mijn Windows 7 installatie op m'n notebook is echter nog niet af, dat lag al een aantal weken stil door mijn werk aan de notebook van m'n vriendin, en vorige week kwam er ook weer een andersoortige klus bij, maar hopelijk lukt het me om eind deze week verder te gaan met mijn notebook en daarmee dan op een gegeven moment VTexplorer te testen met IE11 en mijn webmail.
Even geduld voor nu, ik ben net terug en nogal gaar, en de komende dagen moet mijn andersoortige klus prioriteit hebben, maar daarna wil ik zeker even mijn tests met IE11 en VTexplorer doen.

@ _kraai__,
Zoals ik al aangaf, ik moet beslist mijn eigen DDS-webmail nog testen met IE11,
maar mag ik vragen met welke webmail jij hebt getest? Díe specifieke webmail hoef ik dan in ieder geval níet meer te testen.

En hoe breed heb je getest met URL's in websites? Welk scala aan webpagina's heb je getest?
Heb je ook getest met Startpage, en met DuckDuckGo?
Andere zoekmachines nog?
(Met Google heeft testen van de klikbare URL met VTexplorer weinig zin, omdat je daarmee enkel de Google-URL test. Wel is in Google zoekresultaten de plain text URL's te markeren en dan te checken.)

Ja, beslist ook relevante test-vragen.

Wat betreft .pdf en office documenten,
en met de oorspronkelijke nog niet gemodificeerde VTexplorer,
URL's in niet web based .pdf- en .odt-documenten zijn hoe dan ook niet te checken met VTexplorer, het is immers een Internet Explorer addon.
Maar ook in web based .pdf-documenten zijn URL's niet te checken met VTexplorer (althans, niet in PDF-XChange Viewer).
Hoe het zit met web based office-documenten, dat weet ik niet, maar ik verwacht niet dat de URL's daarin te checken zijn met VTexplorer.

Ha, ook een interessante vraag.
Voor mij: DDS-webmail, daarvan de 'oude' interface, en mijn eigen mailtjes in plain text.
Ik kan het onder IE9 ook nog eens testen met een URL in een HTML-mailtje.

Verder,
een reactie van VirusTotal van afgelopen vrijdag:
Ik wacht even _kraai__'s reacties op de bovengenoemde vragen van cluc-cluc en mij af voordat ik de huidige stand van zaken aan VirusTotal doorgeef.
Liefst zou ik wachten tot ik zelf ook klaar ben met testen, maar dat duurt misschien nog wel een week, en een nog voorlopig maar reeds zeer positief resultaat is ook al mooi, mogelijk kunnen de VirusTotal developers dat 'nog voorlopige' resultaat alvast bekijken en checken.

Tot later weer.

Welkom terug Spiff, en dank je wel voor je reactie.

@Spiff en _Kraai__:

Nog "bruisend" van (ja... van wat eigenlijk??? ;-)) kon ik het niet laten,
en schudde opeens nog een VTExplorer versie uit de mouw. (PLOP...)
Hij werkt prima op IE8, zowel met "direct URL" als met "select plain text" methode.
(maar heb bijv. geen .pdf document via adobe plugin etc. getest)

Hoogst waarschijnlijk functioneert het ook goed op alle hogere IE versies.
Als het goed is, moet jouw probleem met webmail in Vista/IE9 hiermee zijn opgelost, Spiff,
want als er nu namelijk een error dreigt met getSelect, dan stapt deze versie automatisch over
op het script van de oude, originele VTExplorer. (dus het script zonder "getSelect")

Vervang hiertoe in de originele VTExplorer.htm dit blok:
==================================================
==================================================

...door het volgende blok:

==================================================
==================================================

(opmerking: helaas functioneert "alt-255" bij mij niet, en "alt-0160" ook al niet,
zodat helaas de inspringingen wegvallen. Maar dat zal de werking vast niet schaden)

Nadat deze "Release Candidate" ook door jullie, Spiff en _Kraai__, is getest en goedgekeurd,
kun je wat mij betreft deze oplossing wel doormailen naar Virustotal, Spiff.
(misschien is "de complete nieuwe VTexplorer.htm" even als attachment in de mail bijvoegen het gemakkelijkst?
Dan kan men eenvoudig het hele VTExplorer.htm bestand in zijn geheel vervangen door deze nieuwe)

enuh... misschien deze P.S. eraan toevoegen:
===========================================================================================
P.S.:
"We know Virustotal isn't obliged anything. However, just a suggestion:
if there's some budget available then please donate to ebola funding:
i.e. http://www.plan.ie/ebola/
We thought such would fit an AV-company named 'Virustotal' very well! Right?" ;-)
===========================================================================================

Mvg cluc-cluc

@ cluc-cluc, 22:47 uur,

Ja, dat werkt zo inderdaad ook netjes voor IE9 met de URL's in webmail-mailtjes.
Mooi bedacht, die fallback methode!
Zo zou het inderdaad kunnen werken met alle ondersteunde IE-versies.

Ook heb ik gelijk even een snelle test gedaan met Startpage en DuckDuckGo, en ook daarmee werkt het prima, maar door de fallback methode kan dat ook niet anders, zo lijkt me.

Eén belangrijk maar, echter.
Dat deze variant door fallback nu ook werkt voor m'n webmail (en wat dan ook) in IE9, dat betekent toch nog niet dat het ook werkt voor m'n webmail (of wat dan ook) in IE11?
Je schrijft,
Maar als dat optreedt met URL's in m'n webmail-mailtjes (of wat dan ook) in IE11, dan zal dat in IE11 met dat terugvallen op het script zonder getSelect wellicht juist niet werken in. Of zie ik iets over het hoofd?
Als ik het zo zie, dan zal ik het toch echt nog moeten testen met IE11 om te weten of het voor mijn webmail (en voor andere kritische pagina's, waar dan ook, of van wie dan ook) werkelijk wel werkt in IE11.

Via "Reageer met quote" komt je code mét de inspringingen beschikbaar, die dan vervolgens met die correcte inspringingen in VTExplorer.htm te plaatsen is.
Dat was dus geen enkel probleem :-)


Enne, um ...
hoe nu precies verder ...

Zou _kraai__ dat wat 20:03 uur opgesomd werd aan vragen nog kunnen beantwoorden voor IE11, dan weten we nog wat meer. Ik herhaal dat voor het gemak even:

@ _kraai__,
Door cluc-cluc:
En werkt het dan zowel met direct klikken op een URL als met selecteren van een site in plaintekst en daar dan
via rechtermuisknop op klikken en "Send URL to VirusTotal"?
En dat ook nog vanuit bijv. een .pdf of office document?

Door cluc-cluc:
Wat ik me nog afvroeg: zou het verschil in gedrag misschien ook kunnen komen doordat jij _Kraai__ webmail in
HTML mode gebruikt, en Spiff niet, of andersom?

Door Spiff:
Mag ik vragen met welke webmail jij hebt getest?
Díe specifieke webmail hoef ik dan in ieder geval níet meer te testen.

Door Spiff:
En hoe breed heb je getest met URL's in websites? Welk scala aan webpagina's heb je getest?
Heb je ook getest met Startpage, en met DuckDuckGo?
Andere zoekmachines nog?
(Met Google heeft testen van de klikbare URL met VTexplorer weinig zin, omdat je daarmee enkel de Google-URL test. Wel is in Google zoekresultaten de plain text URL's te markeren en dan te checken.)

Met ook dat nog allemaal duidelijk kan ik VirusTotal gerust jouw nieuwste variant aanbieden, cluc-cluc.
Maar dan nog steeds wel met het voorbehoud dat ik het over een week of wat nog moet testen met IE11 en mijn DDS-webmail, denk ik toch ...

Um ...

Gezien VirusTotal's vriendelijke reactie van afgelopen vrijdag, vond ik het prettig om ze toch alvast weer even de stand van zaken door te kunnen geven, ook al zijn een paar antwoorden van _kraai__ nog niet bekend, en ook al heb ik de nieuwste modificatie alleen nog pas op IE9 kunnen testen, en nog niet met IE11 en m'n 'kieskeurige' webmail (of met IE11 en andere 'kieskeurige' webpagina's).

Ik heb VirusTotal zonet een mail gestuurd met
- de eerder besproken relevante Microsoft informatie en de Stack Overflow pagina,
- en met cluc-cluc's meest recente VTExplorer.htm modificatie, zowel in tekst als tevens als VTExplorer.htm attachment,
- en met de testresultaten tot nu toe van de voorgaande en huidige gemodificeerde versie.

Dit alles met het voorbehoud dat er nog verder getest moet worden, met name met IE11 en mijn 'kieskeurige' webmail, om zo veel mogelijk zeker te stellen dat het tevens werkt met andere 'kieskeurige' webpagina's.
Ik heb aangegeven dat het wellicht nog wel een week of wat duurt voordat ik dat kan testen, maar dat in de tussentijd VirusTotal misschien zelf ook alvast naar die code kan kijken, en dat ik nieuwe testresultaten meld als die binnenkomen.

Je sympathieke P.S.-voorstel heb ik nog even niet genoemd, cluc-cluc, omdat ik zonder de genoemde laatste tests nog niet het idee heb dat het klaar is.
Zodra het voldoende klaar is, of VirusTotal het overneemt, zal ik beslist je P.S vermelden, cluc-cluc.
En daarop vooruitlopend, als VirusTotal jullie credit wil geven voor het goede werk, willen jullie dan genoemd worden als cluc-cluc en _kraai__, of willen jullie niet zoiets, en enkel die sympathieke P.S. aanreiken? Denk er maar even over na.

Goedemiddag Spiff en cluc-cluc.
Goed weekend gehad?

bedankt Spiff voor het lijstje dat je gemaakt hebt, dat scheel mij weer wat zoekwerk naar vragen.


Natuurlijk wil ik jullie vragen dan ook beantwoorden.


Ja in beide gevallen werkt het (getest volgens je aangedragen code van 17-12-2014 21:29 uur. Jouw nieuwe stukje code van 21-12-2014 22:47 uur is zo meteen aan de beurd om getest te worden. Wordt dat dus nog een extra fles sjampie :-)


Ik heb getest met de webmail van KPN. Ik weet niet zeker maar volgens mij moet je ook internet van KPN hebben om van hun webmail gebruik te kunnen maken, dus ik weet niet bij welke provider jij zit, anders heb je kans dat je hem misschien ook niet zou kunnen testen.


Ik heb getest met de URL's op een aantal websites. Ik heb niet getest met URL's gevonden via een zoekmachine.

Ik ga u de nieuwe variant testen die door cluc-cluc is aangedragen. De resultaten zullen uiteraard hier dan verschijnen na testen.

Inmiddels de nieuwe variant ook uitgetest


Werkt naar mijn idee ook prima. Ik heb met zo'n 3 websites getest, met de webmail en nn de vorm van plaintekst. selecteren. (die laatste heb ik alleen op security.nl getest omdat ik dat ik niet zo snel plain tekst tegen komt die naar een webpagina verwijst aangezien in veel gevallen dan wel gewoon een link is gemaakt.

De webmail die ik gebruik verzend als ik mij niet vergis, e-mail berichten in HTML, ik weet niet of dat dan ook betekent dat ik de webmail in HTML mode gebruik.

@ _kraai__, 13:33 en 14:07 uur,

Dankjewel voor je antwoorden en voor het testen.

Ik zal wanneer ik later tijd en energie heb nog even de eerdere versie met de modificatie zoals door cluc-cluc aangegeven op 17-12, 21.29 uur (de voorgaande door jou succesvol geteste versie, nog zonder het fallback mechanisme) testen met m'n DDS-webmail met een URL in de body van een HTML mailtje, om te zien of dat eveneens of mogelijk géén fout oplevert, om te bepalen of HTML anders uitpakt dan plain text dat ik standaard gebruik in e-mail.
N.B.
Geef me maar even een zetje als ik het zou vergeten, vandaag of morgen.

Daarnaast zal ik die eerdere versie dan ook gelijk nog even testen op andere pagina's zoals Startpage en DuckDuckGo en nog een assortiment webpagina's, om te zien of ik met die versie zonder fallback mechanisme mogelijk nog meer 'kieskeurige' webpagina's tegenkom. Zoals ik gisteren aangaf, dat was eerder nog niet onderzocht.

En daarnaast moet ik de nieuwste versie (en eventueel maar niet noodzakelijk ook die eerdere versie) tevens testen met IE11 en m'n DDS-webmail. Maar dat is zoals ik al aangaf pas op z'n vroegst over een week ...

Zo is het. Maar in elk geval gaat het bij _Kraai__ wel goed bij webmail in (zo te horen) HTML-mode.

Aha! Super. :-)

Kan... Jouw keuze, waar je denk ik vrij in moet blijven.

@_Kraai_: ik geloof dat ik weer naar de slijterij moet om de "sjampie"-voorraden aan te vullen! ;-)
Heel erg bedankt weer _Kraai_ voor het testen van de laatste code!!!
(of er misschien nog iets meer moet worden getest met die webmail laat ik even tussen jou en Spiff)

Mvg, cluc-cluc

Okee, dank je voor die verduidelijking.
Dan zal ik dat zekerheidshalve werkelijk moeten testen met IE11 en mijn DDS-webmail, wanneer ik binnenkort (volgende week, hoop ik) m'n Windows 7 notebook voldoende gereed heb.

Maar die had je toch al getest, Spiff? Dat was toch jouw bericht van 18-12-2014 12:59 uur? Ik was vrij laat met testen van die code dus kan het niet zijn dat je daardoor even over het hoofd ziet dat het dezelfde code is die jij ook al getest had, en denkt dat het een andere code betreft?


Mij maakt het niet heel veel uit, ik ben voor de sport aan het testen, net zoals jij ook al aangaf voor de sport te helpen. Ik maak al van een andere dienst gebruik om te kijken of een website geen virussen bevat. Maar als Spiff nog iets getest wil hebben met de webmail, ben ik daartoe natuurlijk bereid.

Succes met het vinden van smakelijke sjampie, cluc-cluc :-)

Dankjewel voor de bezorgdheid.
Je zou inderdaad bijna denken dat ik malende geraakt ben, hè, maar dat is geloof ik nog net niet zo :-)

Het is echter zo dat ik die eerdere code slechts beperkt getest had, enkel met die URL hier op de pagina en met twee URL's in een plain text mail in mijn webmail. Wat ik nu nog wil testen met die eerdere code, dat is of er wat anders gebeurt wanneer ik URL's in een HTML-mailtje in mijn webmail check, in plaats van URL's in een plain text mailtje zoals ik die normaal gesproken gebruik. Het is wegens cluc-clucs eerdere opmerking (of vraag, wat was het) dat ik dat nog wil testen.
Daarnaast wil ik met die eerdere code ook de search result links van StartPage en DuckDuckGo en tevens URL's op nog een verzameling websites checken, om te controleren of daarmee mogelijk ergens wat geks gebeurt. Dat was eerder allemaal niet getest met die eerdere code.

Met de laatste code pakt alles goed uit met IE9, maar door het fallback mechanisme geeft dat geen informatie over wat er zonder dat fallback mechanisme fout zou kunnen gaan. Daarom wil ik de vorige code variant nog even beproeven, met HTML-mail en met meer webpagina's.
Dat kan me dan alvast aanwijzingen geven over waar ik met de nieuwe code nog op moet letten met IE11 - m'n webmail met plain text, maar wel of niet ook met HTML? en bepaalde andere pagina's?
Ik wil dus met de vorige code alvast even wat voorbereidende informatie verzamelen voordat ik binnenkort de nieuwe code test met IE11.

Overigens, daarnet overwoog ik nog om vanavond even die extra tests met die vorige code te gaan doen, maar dat wordt pas morgen.

Ik ken er ook zo wat, maar geen die ik zo gemakkelijk even via het context menu kan gebruiken zoals VTexplorer (en z'n broertjes VTzilla en VTchromizer).
Wat gebruik jij? Iets dat je eveneens op die manier kunt gebruiken, of iets dat op een heel andere manier werkt?

Ah, bedankt voor de toelichting en gelukkig dat je niet malende bent geraakt, door de inmiddels al meer dan 100 reacties. Al zit dat nog natuurlijk wel verre weg van het aantal reacties in je Probleem met certificaten thread ;-)


Ik heb Sitecom Cloud Security ingeschakeld staan op mijn Sitecom router. Het werk op een andere maniet als VTexplorer, en is ook een abonnement, Maar het blokkeert onveilige websites en controleert downloads op virussen. (maar het heeft ook nog een aantal andere handige functies. Maar wat het precies inhoud kun je hier nalezen: https://www.sitecom.com/nl/sitecom-cloud-security/347

Ah, dank je.
Ik had er eerder wel eens over gelezen, naar aanleiding van een SurfRight persbericht van april 2011.
Leuk spul wel.

Inmiddels heb ik met IE9 de tests uitgevoerd die ik gisteren aangaf
https://www.security.nl/posting/411290#posting412908
https://www.security.nl/posting/411290#posting412965

met de VTexplorer variant zoals op 17-12, 21.29 uur aangereikt door cluc-cluc,
eerder al getest door Spiff en door _kraai__,
maar door Spiff nu uitgebreider getest om aanvullende informatie te verzamelen,

en vervolgens nog eens met de VTexplorer variant zoals op 21-12, 22.47 uur aangereikt door cluc-cluc,
eerder al getest door Spiff en door _kraai__,
maar door Spiff nu uitgebreider getest om eventuele aanvullende informatie te verzamelen.

Ik ben blij dat ik die tests heb uitgevoerd,
want het leverde interessante informatie.

Met de VTexplorer variant zoals op 17-12, 21.29 uur aangereikt door cluc-cluc
https://www.security.nl/posting/411290#posting412397

Aanvullende testresultaten met IE9:

DDS-webmail
Diverse e-mails in HTML,
de URL's in de bodies van die mails gecheckt d.m.v. VTexplorer, "Send URL to VirusTotal",
resultaat steeds:
SCRIPT438: De eigenschap of methode getSelection wordt niet ondersteund door dit object
VTExplorer.htm, regel 10 teken 1
var rng = doc.getSelection();

DDS-webmail
URL's in de DDS-webmail user interface gecheckt d.m.v. VTexplorer, "Send URL to VirusTotal",
resultaat steeds:
SCRIPT438: De eigenschap of methode getSelection wordt niet ondersteund door dit object
VTExplorer.htm, regel 10 teken 1
var rng = doc.getSelection();

Het bovenstaande laat dus zien dat dat issue niet beperkt is tot URL's in DDS-webmail mailtjes met plain text, maar ook optreedt met HTML-mail én met URL's in de DDS-webmail user interface.

Maar nu wordt het nog veel interessanter -
hetzelfde issue kom ik ook hier tegen:

https://www.ncsc.nl/rss/beveiligingsadviezen
Ga naar die pagina, en kies op die pagina een link,
URL-check d.m.v. VTexplorer, "Send URL to VirusTotal",
resultaat steeds:
SCRIPT438: De eigenschap of methode getSelection wordt niet ondersteund door dit object
VTExplorer.htm, regel 10 teken 1
var rng = doc.getSelection();

http://xkcd.com/rss.xml
Ga naar die pagina, en kies op die pagina een link,
URL-checks d.m.v. VTexplorer, "Send URL to VirusTotal",
resultaat steeds:
SCRIPT438: De eigenschap of methode getSelection wordt niet ondersteund door dit object
VTExplorer.htm, regel 10 teken 1
var rng = doc.getSelection();

http://what-if.xkcd.com/feed.atom
Ga naar die pagina, en kies op die pagina een link,
URL-checks d.m.v. VTexplorer, "Send URL to VirusTotal",
resultaat steeds:
SCRIPT438: De eigenschap of methode getSelection wordt niet ondersteund door dit object
VTExplorer.htm, regel 10 teken 1
var rng = doc.getSelection();

Het probleem dat ik tegenkom met die betreffende VTexplorer variant zoals op 17-12, 21.29 uur aangereikt door cluc-cluc, dat kom ik dus niet alleen tegen in DDS-webmail, maar ook op die drie bovenvermelde pagina's.

De vraag is nu uiteraard of datzelfde ook geldt voor de VTexplorer variant zoals op 21-12, 22.47 uur aangereikt door cluc-cluc
https://www.security.nl/posting/411290#posting412815

Met IE9 treden daarmee géén fouten op.
Maar dat valt in de lijn der verwachting, door het fallback mechanisme in die variant.

Héél interessant zou het nu zijn wanneer _kraai__ op deze pagina's
https://www.ncsc.nl/rss/beveiligingsadviezen
http://xkcd.com/rss.xml
http://what-if.xkcd.com/feed.atom
de URL's eens zou willen testen met IE11 en de VTexplorer variant zoals op 21-12, 22.47 uur aangereikt door cluc-cluc.

Treden de fouten die ik vind met IE9 en de VTexplorer variant zoals op 17-12, 21.29 uur aangereikt door cluc-cluc niet op bij testen met IE11 en de VTexplorer variant zoals op 21-12, 22.47 uur aangereikt door cluc-cluc, dan heb ik heel goede hoop dat ook met mijn DDS-webmail onder IE11 die fout niet zal optreden.

Al is the proof of the pudding in the eating, en heb ik dus pas absolute zekerheid wanneer ik het binnenkort zelf kan testen met IE11, maar nogmaals, wanneer die fouten niet optreden op die drie vermelde pagina's, dan heb ik goeie hoop dat dat ook voor DDS-webmail kan gelden.


-----
Ten slotte nog een volkomen ongerelateerde, maar niettemin interessante bevinding -
Ik ontdekte dat DuckDuckGo vergelijkbaar met Google search de URL's in de zoekresultaten niet intact laat, maar die vervangt door DuckDuckGo verwijzingen. Althans, bij scannen d.m.v. VTexplorer, "Send URL to VirusTotal", geeft de VirusTotal URL-check niet een beoordeling van de verwachte gecheckte URL, maar van de DuckDuckGo verwijzing.
Met Searchpage daarentegen is wél prettig elke URL in de zoekresulaten te checken door middel van VTexplorer.
Tot zover wat betreft deze bevinding.
-----

Bedankt voor de test resultaten Spiff. Ik ben ook weer aan de slag gegaan met testen.


Ik heb van alle drie de pagina's (het waren 3 feeds) een URL getest met de variant die cluc-cluc op 21-12-2014 22:47 uur beschreef. In alle drie gevallen word de URL gewoon gescand. Bij http://xkcd.com/rss.xml en
http://what-if.xkcd.com/feed.atom wordt het venster overigens wel meteen naar de achtergrond gedrukt.

----------------------------------------------------------------------------------------------------------------------------------------------
update 27-12-2014 14:56 uur.
Na een nieuwe test bleek bij het scannen van URL's op http://xkcd.com/rss.xml en http://what-if.xkcd.com/feed.atom nu wel het venster met de VirusTotal URL-scan op de voorgrond te openen.
---------------------------------------------------------------------------------------------------------------------------------------------

Ik heb wel het idee dat je een fan bent van tekenfiguurtjes, Spiff? :-)


Yummie, pudding :-)

Prachtig! En dankjewel voor het testen.
Dan heb ik goeie hoop dat ook DDS-webmail geen probleem zal zijn.

Bedoel je het venster van die pagina, of het openende VirusTotal venster?
Normaal is dat het openende VirusTotal venster de focus krijgt, dus dat dat opent over het al geopende venster.
Houdt het al geopende venster de focus, en opent het VirusTotal venster op de achtergrond, dan is dat afwijkend. Ik heb er zelf niet op gelet of dat optrad.

Ha, ja, Spaceman Spiff, en Randall Munroe's http://xkcd.com/ en http://what-if.xkcd.com/, en nog véél meer. Beslist :-)

Mmmm... inderdaad, yummie.
Ik heb vroeger veel toetjes-pudding verslonden, en bibber-Trixy, en ik herinner me ook een Christmas Pudding die ik gedurende een maand met whisky had doordrenkt en tenslotte geflambeerd met dezelfde whisky.
Flamberen doet me overigens weer aan m'n grote held Guust Flater denken - "Met mijn flensjes doe ik wat ik wil! Ik flambeer ze!" "WOEF!" "Nou moe!" :-)

PSje -
Mijn VTexplorer met IE11 en DDS-webmail pudding wil ik zoals eerder gezegd volgende week nog proeven,
maar vandaags heugelijke testresultaat heb ik alvast aan VirusTotal doorgegeven, omdat alle lichten nu toch wel op groen lijken te staan.
Ze zullen bij VirusTotal momenteel wellicht geen tijd hebben om een en ander nu te bekijken en te testen, maar mocht iemand zich daar willen onttrekken aan de kerstdrukte, dan kan die zich wellicht vermaken met die door ons nu toch best al redelijk beproefde VTexplorer versie.
Ik verwacht voorlopig even geen reactie van VirusTotal, maar ik wilde hier al wel even berichten dat ook ik nu zeker genoeg ben om de VTexplorer variant zoals op 21-12, 22.47 uur aangereikt door cluc-cluc nu min of meer als 'release candidate' te zien.
Als er verder niets bijzonders meer gebeurt, dan test ik 'm hopelijk volgende week voor alle zekerheid nog even met IE11 en DDS-webmail, en verder is het de reactie van VirusTotal af te wachten.

Thanks! Een blijde boodschap om er alvast even in te komen zo vlak voor de kerstdagen.
Een lekker toetje, daar wordt een mens blij van. ;-)

Viel me trouwens op dat de drie falende url's voor IE9 alle drie van webpagina's zijn die in XML zijn opgemaakt.
Mogelijk gaat de engine van IE9 (en sinds IE9 zit ook de javascript engine geïntegreerd in de browser...) wat onhandig
met XML om, zodat het in IE9 niet gekoppeld kan worden aan getSelect? Iedere browser heeft nu eenmaal zijn eigen specifieke eigenaardigheden. Is altijd al zo geweest. Maar wij vallen hier nu toevallig over.
IE11, waar een "fallback" niet meer zou werken, lijkt tot nu toe dus gelukkig goed te gaan.
IE11 is ook behoorlijk aangepast aan de laatste webstandaard, waarmee de meeste IE eigenaardigheden zijn verdwenen.
(het zo Microsoft-specifieke "msie" is dan ook uit de user-agent string verdwenen, en IE11 is nu "like Gecko";
zie ook: http://msdn.microsoft.com/en-us/library/ie/hh869301(v=vs.85).aspx)

Vrolijk kerstfeest!
Mvg, cluc-cluc

Ik zie het.
Dat is standaard voor feed pagina's, vermoed ik?

Ah, wie weet, ja.
Maar de code van m'n DDS-webmail is geen XML maar HTML.
Mocht je op basis daarvan benieuwd zijn naar specifieke andere stukjes code van DDS-webmail, geef dan zo mogelijk even aan wat voor stukjes.
Het hier plakken van de complete code is uiteraard geen optie.

Mooi.
Ik hoop dat dit dan ook geldt voor de omgang met de DDS-webmail code en voor eventuele vergelijkbare code op andere vergelijkbaar 'lastige' webpagina's die we met onze tests nog niet zijn tegengekomen.
Voor m'n DDS-webmail zou het niet vreselijk zijn wanneer de nieuwe VTexplorer daar nog niet mee zou kunnen omgaan, wil ik per se een URL uit een ontvangen mailtje checken dan kopieer en plak ik die wel naar VirusTotal's URL-check pagina, maar wanneer het issue ook zou optreden op (door ons tot op heden nog niet ontdekte) andere webpagina's, dan zou dat hinderlijk zijn voor andere VTexplorer-gebruikers.
Daarom, mocht je op basis van m'n bovenstaande hint van de DDS-webmail code nog aanvullende vragen hebben, vraag beslist en gerust.


Prettige dagen, iedereen.
(Al hoort zo'n wens natuurlijk voor alle dagen te gelden :-)

Ik bedoel het opende VirusTotal venster, die opent op de achtergrond. Het al geopende venster houdt de focus. De URL wordt overigens wel gewoon gescand ener veschijnen ook wel gewoon resultaten


Bedankt Spiff, En een smakelijk toetje :-)


Klopt viel mij ook op bij het testen, maar er opent wel gewoon een venster met de VirusTotal URL-scan bij IE11

verder ook:
fijne kerstdagen!

Dank je, _kraai__, duidelijk.

En gebeurde dat alleen met de URL's op die drie door mij aangereikte feed-pagina's?
Of ook met andere URL's via andere pagina's?

Ik heb geen idee of cluc-cluc een idee heeft over een mogelijke oorzaak ervan.

Maar ook al is het afwijkend dat het al geopende venster de focus houdt en het VirusTotal venster opent op de achtergrond, ikzelf vind dat eigenlijk wel zo prettig. Zo kan ik bij het door middel van VTexplorer checken van meerdere URL's in een StartPage zoekresultaten-weergave wellicht meerdere "Send URL to VirusTotal" opdrachten na elkaar geven, zonder dat ik steeds van de openende VirusTotal pagina weer terug moet naar de StartPage zoekresultaten.

Het is tijd om maar weer eens aan de slag te gaan met dit topic :-)
Fijne kerstdagen gehad?


Hmm, na vandaag nog een keer te hebben getest opent het venster met de VirusTotal URL-scan wel gewoon op de voorgrond. vreemd, maar ik hou het in de gaten en zal nog een paar keer testen deze week.

Ik heb het nog wel even vermeld in mijn post van 23-12-2014 19:23 uur een toevoeging gemaakt.


De code van jouw DDS-webmail lijkt mij eerder XHTML. (Als ik mij niet vergis, gewoon een soort mengsel van XML en HTML) Maar goed, tussen HTML en XHTML zitten een paar verschillen. (mocht je niet de verschillen weten, en geïnteresseerd zijn wat die verschillen zijn, zet ik ze wel even hier op een rijtje.
---------------------------------------------------------------------------------------------------------------------------
aanvulling 27-12-2014 15:14 uur
Op de volgende pagina, staat een beschrijving over de verschillen tussen HTML en XHTML.

http://www.w3schools.com/html/html_xhtml.asp
---------------------------------------------------------------------------------------------------------------------------

Ik heb die van de webmail die ik gebruik ook even bekeken.

HTML is in dit geval de code van de webmail.

@ _kraai__, 14:53 uur,
Dankjewel voor de informatie.

Wat betreft het door VTexplorer openen van een VirusTotal URL-scan venster,
misschien komt het zelfs met de originele VTexplorer versie af en toe voor dat soms het oorspronkelijke venster de focus houdt, in plaats van dat het openende venster de focus krijgt?
Ik weet het niet. Ik heb er nooit eerder op gelet. Juist omdat ik het zelf eigenlijk prettiger vind wanneer het oorspronkelijke venster de focus houdt, in plaats van dat het openende venster de focus krijgt, zal het me misschien juist niet opvallen wanneer het oorspronkelijke venster de focus houdt.
Mocht cluc-cluc een verklaring zien in de aangepaste code, dan kan die er misschien nog iets over zeggen.
Anders is het afwachten of VirusTotal binnenkort bij het testen van de aangepaste code opvallende dingen tegenkomt.

En wat betreft de code van DDS-webmail, ik had die regel geplaatst omdat cluc-cluc eerder benieuwd was naar die DDS-webmail, ik had er toen eerder niet aan gedacht een stukje code te bieden.
Zelf heb ik weinig kennis over code, en te weinig gelegenheid om me er uitgebreid in te verdiepen.
De informatie die je aanreikte, _kraai__, http://www.w3schools.com/html/html_xhtml.asp, dat geeft me echter al wel een klein beetje kijk op XHTML, dankjewel daarvoor. Onder meer dit:
- XHTML is stricter than HTML
- XHTML is HTML defined as an XML application
Dat IE9 met de VTexplorer variant zoals op 17-12, 21.29 uur aangereikt door cluc-cluc niet kon omgaan met zowel mijn DDS-webmail in XHTML en met links op pagina's in XML, dat was misschien wel door die XHTML en XMLverwantschap?
Dat IE11 in jouw tests met VTexplorer variant zoals op 21-12, 22.47 uur aangereikt door cluc-cluc geen moeite had met de links op pagina's in XML, dat was mooi, en geeft goede hoop voor mijn webmail in XHTML.
Over een paar dagen kom ik zelf toe aan dat testen met IE11.

Ik ben benieuwd naar het resultaat. Helaas ken ik zo niet echt een website waarbij gebruik is gemaakt van XHTML. Anders had ik ook alvast daarmee kunnen testen.

Het gaat inderdaad om xhtml. En wel om: "XHTML 1.0 Transitional".
Zie http://www.w3schools.com/tags/tag_doctype.asp. Wel verwarrend hè, die "html"-tag achter "!DOCTYPE"... ;-)
Maar er geldt hiervoor toch blijkbaar: "The markup must also be written as well-formed XML."
En daarom: XHTML gebruikt waarschijnlijk eveneens de nogal strikte XML-parser. Verder is ook XHTML nieuw in IE9:
http://answers.microsoft.com/en-us/ie/forum/ie9-windows_vista/ie9-beta-now-supports-xhtml-properly/89444720-aa9d-4cfc-81a8-c1328795d1ae
Voorlopig acht ik daarom een "kinderziekte" met getSelect in de XML-parser van IE9 het meest waarschijnlijk.

Dit verschijnsel zie ik ook met IE8. Volgens mij is dit normaal bij IE-browsers: het "child"-window verschijnt in de achtergrond, en de "parent"-window blijft op de voorgrond. Het is dus bijzonder wanneer de nieuwe window juist wél in de voorgrond verschijnt. Hoewel... bijzonder?... Misschien ook weer niet echt:
als bijv. de security settings zo staan ingesteld dat de browser waarschuwt met een melding dat communicatie over een beveiligde verbinding gaat plaatsvinden, dan springt het nieuwe window van Virustotal ook meteen mee naar de voorgrond.

Trouwens op de gebruikelijke methode van "focus()" toevoegen om daarmee de window naar de voorgrond te bewegen (dus zo: window.open(main_site+response[1],"_blank").focus()) reageert IE meestal ook erg eigenwijs. (werkt meestal niet) Of .focus() in de modernere IE11 nu misschien juist weer wél werkt, weet ik niet... Je kunt eens proberen.

Mvg, cluc-cluc.

Echter, gisteren gaf _kraai__ aan:
Het verschijnsel dat het VirusTotal "child"-window in de achtergrond verschijnt en de "parent"-window op de voorgrond blijft, dat was dus in ieder geval niet constant reproduceerbaar.

Wellicht is het verschil in het wel of niet verschuiven van de focus van de "parent"-window naar het VirusTotal "child"-window mogelijk afhankelijk zijn van wat cluc-cluc vervolgens aangaf?
Misschien zit het verschil er in of de "parent"-window al een pagina via https betrof, of een pagina via http? Dus zo:
"parent"-window is een pagina via http, VirusTotal "child"-window opent in de voorgrond,
"parent"-window is al een pagina via https, VirusTotal "child"-window opent niet in de voorgrond?
Of interpreteer ik cluc-clucs opmerking nu helemaal verkeerd?
Ik weet niet hoe het is voor IE11 met de VTexplorer variant zoals op 21-12, 22.47 uur aangereikt door cluc-cluc.
Met IE9 en de originele VTexplorer opent zowel bij het checken van een URL op een http als op een https pagina het VirusTotal-venster in de voorgrond. Ik sluit niet uit dat er gevallen zijn waarin het ánders is, maar bij een handvol zonet geteste http en https pagina's opent met IE9 en de originele VTexplorer het VirusTotal-venster steeds in de voorgrond.

Wat ik vermoed, is dat het "Virustotal resultaten window" (dat over https wordt ontvangen...) in IE8 de voorgrond krijgt
in geval er met dat nieuwe window iets aan de hand is dat door IE wordt gemeld. (dit kan wat mij betreft iedere kennisgeving, waarschuwing of error zijn, één en ander soms mede afhankelijk van je beveiligingsinstellingen.
Maar bij mij was dit toevallig de onschuldige kennisgeving van (even in mijn eigen woorden): "u gaat communiceren over een beveiligde verbinding. Is dat OK?" (want de Virustotal website wilde kennelijk https gebruiken in het nieuwe window)

Nadat ik m.b.t. die "kennisgeving/waarschuwing" over een beveiligde verbinding het hokje had aangekruist om deze melding voortaan niet meer weer te geven, verscheen het Virustotal resultaten window bij mij voortaan in de achtergrond,
en niet langer meer in de voorgrond.

Als je eens googelt op bijv. IE + focus + open.window, dan zie je dat het klachten regent over dit onderwerp. Dus ik zou me er niet al te druk over maken (behalve als het werkelijk heel erg storend zou zijn; iets wat ik me niet kan voorstellen).
Het is nu eenmaal zoals het is, en werkt niet in alle browsers even consistent.

Mvg, cluc-cluc

Aanvullend daarop:

Ik kwam zonet met IE9 en de originele VTexplorer nu een situatie tegen waarbij bij het checken van een URL op een pagina het VirusTotal-venster niet in de voorgrond opende, maar in de achtergrond.
Dat was bij het op deze pagina http://www.sciencepalooza.nl/2014/12/over-de-onlogica-van-treinkaartjes/ checken van de laatste link in die tekst (de link met deze URL: http://www.railsaver.co.uk/splittickets/) door middel van VTexplorer. Het VirusTotal-venster opende niet in de voorgrond, maar in de achtergrond. Bij opnieuw proberen hetzelfde.
Bij het checken van een andere link op die webpagina (de link met deze URL: http://www.thisismoney.co.uk/money/bills/article-1683955/How-split-ticketing-saves-a-fortune-in-rail-fares.html) trad datzelfde verschijnsel echter niet op. En bij het vervolgens opnieuw checken van de eerder gecheckte link (http://www.railsaver.co.uk/splittickets/) trad dat verschijnsel nu ook niet meer op, maar opende het VirusTotal-venster weer 'gewoon' in de voorgrond.
Ik zie nog geen verklaring voor het verschil in gedrag.
Maar dat dit verschil dus evengoed optreedt met de originele VTexplorer als met de aangepaste variant, dat doet sterk vermoeden dat het helemaal niets te maken heeft met de aanpassing van de code, en dat het een 'normaal' verschijnsel is, want immers ook al met de originele niet aangepaste VTexplorer.

Tot zover wat betreft dat openen van de VirusTotal-pagina in de voorgrond of in de achtergrond, denk ik.

Het wachten is vooral nog even op mijn test met IE11 en mijn webmail met de aangepaste VTexplorer variant (over een dag of wat), en op het oordeel van het VirusTotal team.

En daarbij wat ik eerder al noemde, VirusTotal gaf op 19 december aan "if you have a chance to fix it yourselves we would be happy to credit you and feature it on the site". Zoals ik eerder al vroeg - heeft dat jullie interesse, het genoemd worden op de VirusTotal site? Of houd ik het bij cluc-clucs suggestie aan VT, "if there's some budget available then please donate to ebola funding"?

Beslist niet :-)
En zoals ik om 14:08 uur ook aangaf, gezien het feit dat hetzelfde verschijnsel nu en dan ook optreedt met de originele VTexplorer, niet enkel met de aangepaste variant, doet dat sterk vermoeden dat het helemaal niets te maken heeft met de aanpassing van de code, en dat het een normaal verschijnsel is.

En PSje
Zie overigens de laatste alinea van mijn post van 14:08 uur niet over het hoofd,
ik ben benieuwd naar jullie wensen betreffend VirusTotal.

Verwarrend vind ik nog wel meevallen. Dat XHTML nieuw was in IE9 wist ik echter niet.


Inmiddels was ik er al achter dat het niet op de voorgrond verschijnen van het venster met daarin de VirusTotal URL-scan niet altijd optreed.

Verder was het ook gewoon een waarneming. Ik vindt het niet hinderlijk of zo


Ik vindt de suggestie van cluc-cluc sympathiek. Verder heeft ook cluc-cluc het probleem opgelost door een aangepaste code te schrijven, dus vindt ik het ook aan cluc-cluc om daarover te beslissen. (Ik heb tenslotte alleen de aangepaste code getest).

Cluc-clucs suggestie is inderdaad zéér sympathiek.
En inderdaad is het cluc-cluc die het probleem heeft opgelost door een aangepaste code te schrijven.
Ik geloof dat mensen wel eens voor minder een lintje krijgen :-)

Over een kwartiertje of een halfuurtje ben ik toe aan het testen van de aangepaste VTexplorer met IE11 op m'n Windows 7 x64 notebook. Wanneer dat helemaal succesvol is, ook met m'n XHTML DDS-webmail, dan kan ik weer een berichtje aan VirusTotal gaan sturen.
Van cluc-cluc hoor ik daarvoor dan graag nog even of je enkel wenst dat ik VirusTotal je suggestie aanreik,
of dat je het daarnaast misschien ook leuk zou vinden dat VirusTotal je vermeldt op de website,
als cluc-cluc, of anderszins.
Ik hoor het graag even van je.

Mijn test met de VTexplorer variant zoals op 21-12, 22.47 uur aangereikt door cluc-cluc, met IE11 op m'n Windows 7 x64 notebook, die is klaar.
Alles werkt perfect, óók met m'n XHTML DDS-webmail. Geweldig dus!
Ha, nu krijg ik ook wel zin in sjampie, zeg :-)

Dankjewel, cluc-cluc!
En zie niet per ongeluk m'n bericht van 22:48 uur over het hoofd, daar verneem ik graag nog je reactie op, cluc-cluc, voordat ik VirusTotal het goede nieuws doorgeef.

Een tevreden mens is een gelukkig mens, Spiff. Proost!
Clucje zijn ook zeer van de blijerige en dankerige dat alles zo goed mag werken Spiff en _Kraai_. :-))
Maar bedenk dat het zonder jullie inspiratie en testen niet gelukt zou zijn hé,
dus onzin om het allemaal op één naam te schrijven.
Mij vonden het een fijn en leerzaam avontuur, en dat is eigenlijk al genoeg.
Wat mij betreft volstaat daarom de "ebola-hint".
Maar mocht iemand het toch wel leuk vinden dat er ook "alias"-namen worden vermeld,
dan zullen dat onze drie namen moeten zijn, en niet slechts één naam.

En vergeet niet de:
Disclaimer: this modification to VTExplorer.htm to make it also work for IE11 is shared with you "as is",
meant to be offered as a free solution to IE-users of the Virustotal VTExplorer tool,
and the developers of this modification shall not be held responsible for any warranty or support
or liability or whatsoever.

Mvg, cluc-cluc

Dank je cluc-cluc.
Onze aliassen worden genoemd in mijn mail aan VirusTotal, maar ik geef aan dat we het niet nodig vinden die te vermelden op de website.
Je suggestie "if there's some budget available then please donate to ebola funding", die geef ik in z'n geheel aan zoals je die eerder geformuleerd hebt. Ik hoop dat ze het net als wij een sympathieke suggestie vinden.

Goed idee.
Ook dat zal ik zo vermelden in mijn mail aan VirusTotal.
Met daarbij nog:
"I think that should be self-evident, but it is a good thing to mention it.
Of course VirusTotal should have a look at the modified code, and do the necessary testing, before issuing the modified VTexplorer as the new version. But again, I think that is self-evident."

Ik ben benieuwd naar VirusTotal's reactie.
Maar gezien wat eerder aangegeven werd, "VirusTotal is a small team, and about half of the team here is on vacation so please be patient" en "this is low in our list of priorities right now", denk ik dat dat wel even kan duren.

Zodra ik een reactie krijg van VirusTotal zal ik dat hier melden.

Nogmaals hartelijk bedankt iedereen!

Mooi om te horen dat VTexplorer bij jou nu ook goed werkt Spiff. Geniet van de sjampie ;-)


Ook het toevoegen van de disclaimer zoals cluc-cluc die beschrijft + de aanvulling van Spiff vindt ik een goed idee.


Ik vind onze naar mij idee fijnen samenwerking, (en ik hoop dat jullie er ook zo over denken) al een genoegen. En voor die fijne samenwerking dank ik jullie ook voor.

Ik vind de "ebola-hint" dus genoeg. Het vermelden van "alias"-namen hoeft van mij niet.

Verder ben ik natuurlijk ook benieuwd naar de reactie van VirusTotal.

Ja, het was inderdaad een genoegen.
En .. we zijn keurig op tijd klaar, mooi voor de eerder voorgestelde deadline van 31 december :-)

Onze aliassen had ik eerder genoemd aan VirusTotal bij het enigszins aanduiden van wie we zijn ("Dutch Security.nl forum members") en het beschrijven van wat we deden en onze voorgang daarbij.
Maar in m'n mail van eind van de middag vandaag heb ik keurig aangegeven:
"There is no need to mention us on the VirusTotal site.
However, Dutch Security.nl forum member cluc-cluc had a kind suggestion."
En dan cluc-clucs eerdere formulering met de suggestie "if there's some budget available then please donate to ebola funding."

En daarnaast uiteraard nogmaals de aanpassing van de code in tekst vermeld, en tevens opnieuw de aangepaste VTExplorer.htm bijgevoegd als attachment.
En de disclaimer.
Dit alles ingebed in een mailtje met een samenvattende beschrijving.

Ik ben benieuwd wanneer het VirusTotal team tijd vindt om de boel te bekijken.
Ik reken erop dat dat wel een aantal weken kan duren.

De laatste reactie in topic is uit 2014 maar voor het nieuwe jaar testresultaten met de aangepaste code voor VTexplorer van cluc-cluc getest voor Windows 8.1 x64.

Ik been geen problemen tegen gekomen met testen. Er opend gewoon een venster met de VirusTotal URL-scan als op "Send URLto VirusTotal" wordt geklikt.

I heb de aangepaste versie gebruikt zoals door cluc-cluc's post van 21-12-201 22:17 https://www.security.nl/posting/411290#posting412815.

Al nieuwe sjampie ingekocht ;-)

Ha, dankjewel.
Ik had niet verwacht dat het onder Windows 8.1 anders zou reageren dan onder Windows 7, maar het is heel goed dat je het getest hebt.
Ikzelf heb overigens een paar dagen geleden het VirusTotal team zekerheidshalve even gevraagd of mijn eerdere bericht wel binnengekomen is, gezien het attachment met de aangepaste VTExplorer.htm. Het zou de eerste organisatie (of particulier) niet zijn waar overspannen filterregels een bericht met attachment (of zelfs zonder) tegenhouden.
Maar ik neem vooral aan dat door de feestdagen en vakanties een achterstand is ontstaan en een en ander simpelweg nog niet aan bod is gekomen. We wachten rustig verder af :-)

Ik ging er ook vanuit dat de code onder Windows 8.1 niet anders zou reageren als onder Windows 7. Maar goed nu weten we het zeker :-)


Bedankt voor het melden hoe het ermee voor staat, en inderdaad we wachten rustig verder af :-)

Keurig! En... nog één keer een feestje. ;-)

Was uitverkocht... :-(
Toen maar sjampo (scheelt maar één lettertje) geprobeerd.
Schuimt ook (gemengd met water), maar niet te zuipen! Heb het toen maar in mijn haar gesmeerd... ;-)
Gebak dan maar deze keer?

Ok, dank Spiff. Zal wel druk zijn zo na de "Christmas holidays",
en de verwerking van de "ebola-hint" zou tijd kunnen kosten omdat management daar natuurlijk over gaat?
Ben benieuwd.

Mvg, cluc-cluc

Hihihi lol :-) Misschien een andere smaak/ geur shampoo/sjampo uitproberen dan maar ;-)

Gebak? yummie.

Goed nieuws van VirusTotal:

Die nieuwe VTexplorer.exe installer heb ik zonet getest met Windows 7 IE11 en met Windows Vista IE9.
Ik heb die installatie uitgevoerd 'overheen' de installatie met de originele VTExplorer.htm (dus niet het aangepaste bestand).
De installatie verliep keurig en de nieuwe VTexplorer installatie werkt perfect, met zowel Windows 7 IE11 en met Windows Vista IE9, net zoals eerder met de aangepaste code die we als 'release candidate' beschouwden.

De VTexplorer.htm code in de nieuwe VTexplorer.htm is vrijwel identiek aan cluc-cluc's code, op een paar toegevoegde spaties na, én iets waarmee het VirusTotal team dacht goed te doen, maar dat ik er niet in wil hebben, de regel
gevolgd door mijn naam en e-mail adres.
Vriendelijk bedoeld, maar nee, dank je, zo heb ik het VirusTotal team inmiddels per e-mail nadrukkelijk aangegeven.

Vindt het VirusTotal team deze regel te beperkt
dan is mijn voorstel aan VirusTotal om dat uit te breiden naar

Daarnaast heb ik zekerheidshalve tevens cluc-cluc's eerdere suggestie opnieuw even vermeld.

Super!!!
Maar vind persoonlijk voor wat betreft de commentaarregel "// Slightly modified by the community to make it also work for IE11 - 2014." dit eigenlijk wel genoeg.
Kan overigens ook best leven met jouw uitbreiding. (als men van security.nl tenminste geen bezwaar heeft)

Mvg, cluc-cluc

Mooi bedank voor het melden en testen Spiff. Ik begrijp dat dus het installatie bestand via de mail naar jouw is verzonden en nog niet online staat.

Weer een feestje?

sjampie, shampoo of gebak? :-)

Klopt, via Dropbox was dat, dat het eerst even mij zo aangeboden werd. En daar ben ik blij om, omdat ik beslist m'n naam en mailadres nog uit die VTexplorer.htm file wil hebben voordat die online gaat. Kan nu gelukkig mooi nog voor de definitieve versie, pfoe.

De shampoo moet ik stukken minder van watertanden dan van de taart.
Doe mij maar een lekkere punt vega chocotaart.

Ja, ikzelf vind die regel ook genoeg.
Aan VirusTotal had ik dus geantwoord,
Inmiddels is er al weer antwoord van VirusTotal:
Ha, fijn. Eind goed, al goed, zo lijkt me :-)

Zodra de definitieve versie online gezet wordt door VirusTotal, zal ik dat hier uiteraard even melden.

Inmiddels is de definitieve nieuwe versie van VTexplorer online gezet door VirusTotal,
voor wie die wil gebruiken, of testen en bekijken, je vindt die hier:
https://www.virustotal.com/nl/documentation/browser-extensions/internet-explorer/

Ook deze nieuwe versie van de VTexplorer.exe installer heb ik zonet getest met Windows 7 IE11 en met Vista IE9.
Ik heb die installatie uitgevoerd 'overheen' de installatie van de testversie van gisteren.
De installatie verliep weer keurig en de nieuwe VTexplorer installatie werkt opnieuw perfect, met zowel Windows 7 IE11 en met Windows Vista IE9.

Opvallend is dat vtExplorer.exe nu een geheel vernieuwde VTExplorer.htm installeert. Het VirusTotal team heeft de VTExplorer.htm code helemaal herschreven, daarbij gebruikmakend van de modificaties zoals bedacht door cluc-cluc.
Leg ter vergelijking de nieuwste VTExplorer.htm code maar eens naast de code zoals we die eerder hebben getest.
Ikzelf ben niet thuis in die code, maar voor cluc-cluc en anderen zal het wellicht interessant zijn om te zien wat er aangepast is.

Op de suggestie "if there's some budget available then please donate to ebola funding" is overigens geen reactie gegeven door het VirusTotal team, maar dat sluit uiteraard niet uit dat we ze misschien toch op een idee kunnen hebben gebracht.

Tot zover voor nu.

Nog geen vega chocotaart om me aan te buiten te gaan, maar wel een lekker stukje goed pure bio faire trade chocolade.
Mmmm :-)

Geweldig Spiff! :-)


Ik heb hem zojuist ook getest met Windows 7 en IE11, en hij werkt inderdaad perfect.


Wat mij opvalt is

Een deel van de code staat zo te zien in een andere volgorde maar en zijn inderdaad ook nog een paar andere wijzigen te zien zoals mocht er een foutmelding verschijnen is het niet meer "Sorry, some error happened...", maar is nu "Unexpected error communicating with virustotal..."

Ook is me opgevallen dat het blok:


verhuist is in het VTexplorer.htm document. (het staat nu boven het stuk code met de modificaties van cluc-cluc).


Ik ben meer voor een heerlijk stukje kersenvlaai :-)

In reactie op berichten 14-01-2015 15:27 door Spiff en 14-01-2015 16:24 door _kraai__:

Nieuwe versie lijkt goed te gaan.
Er zijn zo te zien inderdaad nog enkele andere subtiele wijzigingen aangebracht in de opnieuw uitgegeven VTExplorer
(heet nu versie 0.2)
Zo heeft men nu eerst een functie "scanurl" gedeclareerd, die aan het einde van het programma wordt aangeroepen.
In het feitelijke programmaverloop is er dus niet werkelijk een heel blok code verplaatst.

Deze werkwijze zal tevens aanleiding hebben gegeven tot nog wat andere kleine wijzigingen/verplaatsingen.
Maar onze "ham"-code (die het eigenlijke probleem met IE11 heeft opgelost) is hetzelfde gebleven.

Ook de naam van de optie in het dropdown-menu is veranderd van "Send URL to Virustotal" naar "Check with virustotal".
Puntje van aandacht: als je de oude versie van VTExplorer nog geïnstalleerd had, dan deze eerst deïnstalleren met
C:\Program Files\VTExplorer\Uninstall.exe alvorens je de nieuwe versie van vtexplorer installeert.
(anders zit je opgescheept met beide entries van VTExplorer in je rechtermuisknop dropdown-menu...)

Misschien geneuzel in de marge, maar mijn smaak zou hier zijn geweest: "Check URL with virustotal".
Het woordke "URL" springt er duidelijk uit, en een slimme belg ziet onmiddellijk: ja, die moet ik hebben! Zeker en vast.
Wil je dit ook, of wil je nog een andere omschrijving, dan kun je het desnoods in je windows register aanpassen
door m.b.v. de zoekfunctie het windows register te doorzoeken op: "Check with virustotal".
Kies vervolgens in het dropdown menu "Naam wijzigen", en wurm er "URL" tussen. (of maak er de omschrijving van die jij wenst)

Slechts de coderegel if (candidate_url.indexOf('http') != 0) {alert('More information at www.virustotal.com');
lijkt me een extra toevoeging. Het is niet door mij/ons bedacht, en er zat niet zoiets in de oude VTExplorer.
Dit controleert volgens mij of de opgegeven URL met "http" begint. Zo niet dan krijg je nu die alertmelding.
Netjes hoor. Maar ik vraag me wel af of de melding niet beter zou kunnen zijn: 'Attention: URL should start with http'.
(en dan eventueel daar nog achteraan:'More information at www.virustotal.com', indien het daar tenminste nader wordt uitgelegd?)
Alle andere code komt in wezen op hetzelfde neer. Kortom: men heeft de code hoofdzakelijk enigszins gereorganiseerd
ten gunste van een wat betere overzichtelijkheid en structuur. (hoewel soms slechts een kwestie smaak)

Over smaak gesproken: klink ik nog wel een beetje professioneel na al die flessen champagne en mijn half vergeten spoedcursus javascript? ;-)
Anders nu wel: ik heb inmiddels een flinke appeltaart met een volle bus slagroom in de koelkast staan.
AANVALLUH! Dat wordt pas echt professioneel smullen. ;-P MMMMMMMMMM...lekke' hô'!
Eet smakelijk allemaal en/of dat het u wel moge bekomen! ;-)

Mvg, cluc-cluc

Dankjewel, cluc-cluc!
Op zowel m'n Windows 7 als m'n Windows Vista systeem had ik daar in m'n Administator-account overheen gekeken (ik was gespitst op "Send URL to Virustotal" en keek over "Check with virustotal" heen) en in m'n Standaardgebruiker-accounts was dat nieuwe "Check with virustotal" niet aanwezig, enkel het oude "Send URL to Virustotal".
Het niet verwijderen van de oude vermelding "Send URL to Virustotal" is blijkbaar een tekortkoming in de installer.
Het in Standaardgebruiker-accounts niet toevoegen van "Check with virustotal" is blijkbaar eveneens een tekortkoming in de installer, die ook al met de oorspronkelijke versie bestond. Ook met de oorspronkelijke installer zag ik een tijdje geleden dat na installatie "Send URL to Virustotal" nog ontbrak in het IE-contextmenu in het Standaardgebruiker-account. Pas na het nogmaals uitvoeren van de installer in het Standaardgebruiker-account en het opnieuw openen van IE was toen "Send URL to Virustotal" ook aanwezig in het IE-contextmenu in het Standaardgebruiker-account. Hetzelfde blijkt ook nu te gelden, ik heb het zonet getest.
Hmm.. twee punten dus om nog te corrigeren door het VirusTotal team.

Ik vind dat beslist geen geneuzel in de marge.
Ik vind dat je gelijk hebt.
Misschien was de overweging van het VirusTotal team dat niet iedereen de term "URL" kent?
Is het VirusTotal team bezorgd dat de term "URL" de eenvoudige gebruiker verwart?
"Check" is misschien inderdaad beter dan "Send", maar ook ik zou prefereren "Check URL with VirusTotal".
Of desnoods "Check link with VirusTotal", Als het VirusTotal team bezorgd is dat de term "URL" te moeilijk is?
En VirusTotal als "VirusTotal", met de hoofdletters, want dat is immers de schrijfwijze die ook op de eigen site wordt gebruikt.

Je hebt gelijk, die vermelding "More information at www.virustotal.com" is uiteraard niet bepaald informatief.
Jouw suggestie lijkt me uitstekend, 'Attention: URL should start with http', en dan eventueel daar nog achteraan: 'More information at www.virustotal.com', indien het daar tenminste nader wordt uitgelegd(?), wat ook mij niet duidelijk is.

Al het bovenstaande ga ik straks aan het VirusTotal team doorgeven.


Uiterst professioneel zelfs, zie al je bovengenoemde aandachtspunten, die niet alleen blijk geven van een professionele kijk maar tevens van een heldere blik.
Knap hoor, na al die sjampie en zelfs sjampo.

Gezellig, dat zegt m'n broer ook altijd.
Van dezelfde :-)

Inmiddels gedaan.

Inderdaad ik had ook de oude versie niet eerst verwijderd van mijn PC met C:\Program Files\VTExplorer\Uninstall.exe. Dus had ook beide entries van VTexplorer in het rechtermuisknop dropdown-menue.

De nieuwe C:\Program Files\VTExplorer\Uninstall.exe verwijderd deze niet meer dus maar even via vorige versies de oude C:\Program Files\VTExplorer\Uninstall.exe terughaalt en daarmee alsnog "Send URL to VirusTotal" in het rechtermuisknop dropdown-menue kunnen verwijderen. (mocht jij dit probleem ook hebben Spiff, kun je proberen of deze manier ook bij jouw werkt om de oude VTexplorer toch alsnog te verwijderen).



Laat de appeltaart, cluc-cluc, en de pure bio faire trade chocolade, Spiff smaken ;-)

Dank je voor die tip, _kraai__, om met "Vorige versies herstellen" de oude uninstaller terug te halen. Goeie tip, ik zou die mogelijkheid "Vorige versies herstellen" vergeten zijn.
Een andere mogelijkheid zal zijn het de-installeren van de huidige versie, daarna herinstalleren van de vorige versie, met de oude installer, dan daarvan de uninstaller uitvoeren, en vervolgens de nieuwe versie weer installeren. N.B. Dat is op die manier uiteraard alleen uit te voeren door wie de oude installer heeft bewaard.
Gezien het feit dat ik beide installers nog bezit, wacht ik voorlopig even de reactie van het VirusTotal team af, om te kunnen testen of een nieuwe installer gemaakt wordt die de diverse zaken nog fikst.
Kort:
1. Het niet verwijderen van de oude vermelding "Send URL to Virustotal",
2. het in Standaardgebruiker-accounts niet toevoegen van "Check with virustotal" bij installatie vanuit Administrator account,
3. aanpassen van de formulering "Check with virustotal" naar "Check URL with VirusTotal"(?)
4. aanpassen van "virustotal" naar "VirusTotal",
5. aanpassen van 'More information at www.virustotal.com' naar 'Attention: URL should start with http'
En dus ook:
6. Uninstaller die zowel de oude "Send URL to Virustotal" als de nieuwe "Check with virustotal" kan verwijderen.
Dat laatste zal ik zo meteen als PS doormailen aan het VirusTotal team.

Dankjewel voor het attenderen op het feit dat de nieuwe uninstaller de oude vermelding "Send URL to Virustotal" niet kan verwijderen, _kraai__!

Inmiddels ook gedaan.
Dat punt toegevoegd als 1b, als aanvulling op het eerder genoemde punt 1.

Mmm, misschien een beetje hinderlijk voor het VirusTotal team, dat we nu ineens zo 'lastig' worden, maar het is een direct gevolg van het na onze eerdere tests nog aanpassen van een en ander, denk ik.
Ik hoop dat ze onze inbreng meer waardevol dan hinderlijk vinden :-)

Tsja, nog een aandachtspunt,
zonet ook weer aangereikt aan het VirusTotal team:
Met dat wat gisteravond 21:07 / 21:45 uur werd toegevoegd als punt 1b, is dit nu dan punt 6 van het nog openstaande lijstje.

Reactie van VirusTotal:
Dat beantwoordt de punten 1 t/m 5, plus 1b, die ik gisteravond 21:07 / 21:45 uur opsomde.

De nieuwe installer verwijdert keurig de oude vermelding "Send URL to Virustotal".

Voor Standaardgebruikers-accounts blijft het nodig om daarin de installer nogmaals uit te voeren. Zie het tweede punt van het antwoord van VirusTotal.

Mijn laatste punt, punt 6, zoals ik dat hierboven om 11:59 uur neerzette, dat is echter niet beantwoord door VirusTotal.
Ik heb het zekerheidshalve nogmaals aangestipt:
Mocht daar nog een reactie op volgen, dan zal ik dat hier uiteraard nog vermelden.

Maakt VirusTotal geen aanpassing naar aanleiding van wat ik heb aangegeven, dan zouden gebruikers die VTexplorer erg graag ook met Google en DuckDuckGo willen kunnen gebruiken, wellicht zelf die twee dwarsliggende regels code kunnen verwijderen uit VTExplorer.htm.

Dat betrof de versie van 14-01-2015.
De nieuwe versie van vandaag is dan wellicht versie 0.3?
Maar hoe en waar vind jij dat versienummer, cluc-cluc?

Terug van "eventjes" weggeweest, maar er is weer heel wat gebeurt zie ik: nog enkele puntjes op de "i" gezet.
Lijkt me prima, en goed opgemerkt Spiff en _Kraai__. Vlotte reactie van virustotal ook prima en begrijpelijk. (hoewel sommige zaken blijven wat mij betreft een kwestie van smaak, en dat kan men als eenling een bedrijf niet opleggen)

Eigenlijk begrijp ik misschien niet helemaal wat je hier precies bedoelt???
Maar eens horen wat virustotal hierop antwoordt, maar ik twijfel of dit een reëel issue is.
De blauwe links van Google en DuckDuckGo waar je normaal op klikt, beginnen onderhuids wel degelijk met "http".
En bij DuckDuckGo valt het mij niet op dat ik dan niet rechtstreeks naar de gewenste URL zou gaan.

Maar al zou het "object under test" (dus de link die je aanwijst) niet rechtstreeks met de gewenste website zijn gelinkt
(zoals bij Google het geval is), zou in dat geval virustotal tijdens de URL-controle dan niet automatisch verder kijken,
en vervolgens ook die gewenste website meenemen in zijn controle? (iets dat de oude, oorspronkelijke vtexplorer -code net zo doet?). Want ook al staan dingen via een omweg wellicht min of meer onder controle van Google, toch leg je volgens mij uiteindelijk gewoon (ook) rechtstreekse contacten met de échte website die je wilde bezoeken.

Het lijkt me dat de oude versie van VTExplorer op dit punt niet anders werkt dan de nieuwe.
Behalve dan dat de oude versie dienst weigerde als het noodzakelijke beginnende "http" in de URL ontbrak,
terwijl de nieuwe versie nu netjes een foutmelding geeft(?)

Op het moment dat je vtexplorer installeert, krijg je een window met het installatieproces.
Onderaan in dit window staat o.a. het versienummer in vage grijze letters.

(P.S: het is even wat drukker met andere dingen, dus mijn reacties kunnen misschien iets langer duren.
Have a nice weekend!)

Mvg, cluc-cluc

Ai. Ik hoop dat het VirusTotal team me dan wél begrepen heeft, of me anders nog vraagt wat ik nou toch bedoelde

Ja, het zijn wel degelijk URL's, en ze brengen je wel degelijk naar de het getoonde adres, maar scan Google of DuckDuckGo zoekresultaat URL's maar eens met VTexplorer. Je ziet dan dat niet de verwachte URL gescand wordt, maar een Google dan wel DuckDuckGo URL, zoals dit:
http://www.google.nl/url?sa=t
https://duckduckgo.com/l/?kh=-1

Er is wat dat betreft geen verschil met de eerdere VTexplorer versie.
De resultaten zijn zoals dit:
https://www.virustotal.com/nl/url/d9f8aaed76ffb2f7a545e0824368806479ffef5fdfd5b508e40a8918966afa31/analysis/1421500876/
https://www.virustotal.com/nl/url/387268469a0db2377630d9c4eff7c79cf8b693d72038eed06dee79707dc03254/analysis/1421500907/
Geen informatie over de URL's die je wérkelijk wilde checken.
Ook met de eerdere VTexplorer versie was dit al het geval, maar toen bestond er nog de optie om in de Google of DuckDuckGo zoekresultaten de tekstueel getoonde URL-weergave te markeren en die weergave als gemarkeerde tekst te scannen door middel van VirusTotal. En die optie is nu komen te vervallen door die nieuwe code die checkt of het toch werkelijk wel een aanklikbare URL betreft. Het markeren en laten checken van bijvoorbeeld "nl.wikipedia.org/wiki/Bloem" leidt nu tot de melding "No website to check".

Jammer genoeg is er wel een verschil, zoals ik hierboven aangaf.
De mogelijkheid om (in het geval Google of DuckDuckGo zoekresultaten, waar het checken van de aanklikbare URL door middel van VirusTotal geen nut heeft) een tekstueel weergegeven URL met ontbrekende http (bijvoorbeeld "nl.wikipedia.org/wiki/Bloem") te markeren en vervolgens te checken, die optie is onbruikbaar geworden, want dat leidt nu nog slechts tot de melding "No website to check".

Ha, dank je, daar had ik overheen gekeken.
Ik vraag me dan wel af waar in het VTexplorer bestand dat versienummer bewaard wordt. Via bijvoorbeeld Windows Verkenner of 7-Zip is in de VTexplorer files (zowel in de installer als in de bestanden in Program Files) geen versienummer te vinden.

Dank je voor het melden, cluc-cluc.
Haast je niet voor deze thread. Ik neem je reacties en die van _kraai__, of anderen, altijd zoals ze komen.
Een goed weekend toegewenst, en sterkte -of juist veel plezier- met de aangegeven drukte.

Ik was iets te snel geweest en had de oude installer al verwijderd dus voor mij was het opnieuw installeren van de oude versie niet mogelijk.


Heb ook de nieuwe installer getest. Het is nu wel nodig om 2x toestemming geven via Gebruikers accountbeheer, al vind ik dat niet hinderlijk.

Klopt.
Ik heb echter verzuimd bij het uitvoeren van de update de details van de installatie te bekijken, ik weet niet of daarin werd/wordt aangegeven wat er de eerste en tweede keer precies werd/wordt uitgevoerd. Ik heb ook niet VirusTotal willen lastigvallen met een vraag daarover. Ik vermoed dat twee runs van de installer/uninstaller nodig zijn voor het verwijderen van de oude "Send URL to Virustotal" vermelding en het toepassen van de nieuwe vermelding.

Inmiddels is er weer een reactie van virustotal,
met daarin ten eerste,
Zie: https://www.virustotal.com/nl/documentation/browser-extensions/internet-explorer
waar nu vermeld wordt:
"Please note that you will need to install the extension under each user account with which you wish to enjoy the VirusTotal functionality."
Keurig hoor.

En ook antwoordt virustotal,
Let op:
En er is dus alweer een nieuwe VTexplorer versie (die overigens nog steeds 0.2 heet).
Fijn voor Google en DuckDuckGo gebruikers die daarmee nu de mogelijkheid terug hebben om in Google en DuckDuckGo zoekresultaten een tekstueel weergegeven URL met ontbrekende http (zoals bijvoorbeeld "nl.wikipedia.org/wiki/Bloem") te markeren en vervolgens te checken met virustotal.

Goh.
Ik had eerlijk gezegd niet verwacht dat virustotal die check om non http:// submissions te voorkomen zou laten vallen.
Fijn voor Google en DuckDuckGo gebruikers dat ze dat toch wel degelijk hebben gedaan.
Het virustotal team luistert echt naar gebruikers.
En blijkbaar was wat ik vrijdag 16 januari aangaf voor het virustotal team voldoende reden om die aanpassing te maken.
Nu is deze code gebruikt:
Ik hoop dat dat voor virustotal bijna(?) even goed is als de eerdere check om non http:// submissions te voorkomen.

Dank je wel voor je duidelijke toelichting van 17-01-2015, 14:50, Spiff.
Is me een stuk helderder nu. :-)

Was me er niet van bewust dat VTExplorer ook markeringen kon afhandelen die niet met "http" beginnen.
En dat kan handig zijn, als in de tekst van een webpagina een URL niet compleet met "http" staat vermeld.
Kennelijk waren ze dit bij virustotal ook vergeten?

Ze hebben denk ik bij virustotal willen bereiken dat je niet per ongeluk een incomplete of onzinnige URL
naar virustotal stuurt. Want bijvoorbeeld een klein foutje bij het markeren is zo gemaakt.
En dat is toch zonde van de servertijd en bandbreedte bij virustotal.
Nu hebben ze het script zo aangepast dat je in ieder geval niet meer een "lege" URL kan versturen,
of een "about:blank" URL.

Heb begrepen dat men bij virustotal je feedback inmiddels heeft gehonoreerd, Spiff.
Mooi zo! Ere wie ere toekomt, en... MIJN APPELTAART MOET NODIG OP!!! ;-))

Vind het nog wel steeds vreemd hoe men bij DuckDuckGo verzeild kan raken in "https://duckduckgo.com/l/?kh=-1?".
Maar dat is een ander onderwerp. Misschien ga ik het te zijner tijd nog eens nader onderzoeken.

Mvg, cluc-cluc

Bedankt voor het vermelden Spiff. Ook fijn dat URL's weergeven in gewone tekst zonder http weer gecontroleerd kunnen worden.

Ik weet niet of ze bij virustotal waren vergeten dat met de eerdere check om non http:// submissions te voorkomen ook in tekst weergegeven URL's met ontbrekende http niet meer te checken waren, of dat het wellicht een bewuste overweging was, omdat VTexplorer (en broertjes/zusjes VTzilla en VTchromizer) in essentie misschien enkel bedoeld waren om volledige URL's te kunnen checken, en niet voor in tekst weergegeven URL met ontbrekende http.
Ik vind het in ieder geval erg prettig dat ze dat nu weer gecorrigeerd hebben, zodat wat jij aangeeft weer mogelijk is, checken van een URL die niet compleet met http staat vermeld in tekst van een webpagina, en ook Google en DuckDuckGo gebruikers van datzelfde principe kunnen gebruikmaken.

Ik vind dat ook vreemd.
Ik wist dat Google vervelend doet met URL's, maar het verbaasde me nogal toen ik voor het eerst ontdekte dat ook DuckDuckGo blijkbaar wat merkwaardigs doet met URL's. Maar wat DuckDuckGo nou precies voor merkwaardigs doet, en waarom, dat is ook mij nog niet duidelijk.

Ja, beslist fijn.

Ik denk dat VTexplorer nu voorlopig af is.
Hoera!

En nu maar hopen dat Microsoft later niet opnieuw roet in het eten gooit met een verandering in IE12.

Nou, dooreten dan, cluc-cluc.
Je laat je toch niet op je kop zitten door een appeltaart, hè :-)