Door Korakies:
Dan wel even de gratis McAfee Security Scan Plus uitvinken, alvorens de player binnen te halen.

Door Anoniem, 13:34 uur:
Ik begrijp dat de installer 64bit installeert als hij (of is het een 'zij'?) een 64bit omgeving aantreft?

Door Anoniem, 14:55 uur:
Ik ga gewoon naar de systeem voorkeuren, kies daar onder 'Overige', Flash Player. Daar kun je de versie controleren, en sinds OSX 10.6 kun je ook direct vanuit dat menu de flash player voor het systeem waar je op werkt downloaden en installeren.
Dat is op een mac, maar ik zou verwachten dat ze op windows iets vergelijkbaars ingevoerd hebben.

Door zandubar:
Ok, die updater heb ik aanstaan, maar de filehippo update checker is er altijd sneller bij dan die updater.

Toch nog even over die 32bit versus 64 bit. De flashplayer voor andere browsers pakt de 32 bits versie. Logisch want Firefox, wat ik gebruik, is er alleen in die variant. Of denk ik nu verkeerd en gaat het niet om de browser, maar om het OS?

Echter, IE gebruik ik in 64 bit, maar de ActiveX installer lijkt toch ook steeds de 32bits versie te installeren. Tenminste: het installatiepad van de player is syswow64\macromed\flash. En het bestand heet FlashUtil32_11_5_502_146_ActiveX.exe.

Kan ik nog ergens aan mijn volledig bijgewerkte Windows 7 installatie laten weten dat ik standaard de IE 64 bit gebruik ipv de 32 bit variant?

Door zandubar:
ik denk als volgt: ik heb Firefox 32 bit geïnstalleerd. Die gebruikt daarom ook de 32bit versie van de Flashplayer. Klopt dit? Of pakt Firefox de 64bit versie van de flashplayer voor non-msie browsers omdat mijn OS 64bit is?

Dan de laatste kwestie: ik dacht dat ie 64 bit veiliger zou zijn, vandaar. Maar dat klopt niet?

Door Cantalibre:
Wat ik niet kan volgen, is het Offline installeren? Je moet het toch via het Internet binnenhalen?

Door Cantalibre:
Het ontgaat me waarom ik al die moeite zou doen?

Die Adobe kwam trouwens met een Update, terwijl die het anders Automatisch doet? Nu moest ik klikken op, wilt U deze Update binnenhalen enz enz.

Door Spiff:
Mocht iemand kennis hebben over factoren die ervoor zouden zorgen dat IE9 64-bit veiliger zou zijn dan IE9 32-bit, dan lees ik dat nog graag.

Door Spiff:
Mocht iemand kennis hebben over factoren die ervoor zouden zorgen dat IE9 64-bit veiliger zou zijn dan IE9 32-bit, dan lees ik dat nog graag.

Door Erwtensoep:
Waarschijnlijk wordt er op gedoeld dat ASLR op 64 bit veel moeilijker te bruteforcen is.

Door Spiff: Ah, dank je, Erwtensoep.
Als dat geldt voor IE9/10 64-bit, dan zou dat inderdaad een pluspunt zijn vergeleken met de 32-bit versie.
De vraag is dan vervolgens meer praktisch: is IE9/10 64-bit voldoende werkbaar voor je, zijn de add-ons die je wenst beschikbaar voor IE9/10 64-bit. Een jaar geleden was de beschikbaarheid van add-ons geschikt voor IE9 64-bit nog zeer beperkt, maar dat zou inmiddels veranderd kunnen zijn, dat weet ik niet.

64-bit security

Why does memory matter so much for browsers? There are two reasons. One is common to all browsers; the other is more specific to Firefox. The first reason, the universal reason, is a little thing called security. Security flaws in browsers are an unfortunate fact, so operating system and browser developers both implement various features to try to reduce the impact of these security flaws. For example, one could run the browser in a low privilege sandbox so that malicious exploits cannot easily write to the user's hard disk.

One of these protective measures is called Address Space Layout Randomization, ASLR, and it works by moving DLLs and application memory into unpredictable locations within the 4GB that each 32-bit application has available to it. This makes exploitation harder, but on 32-bit systems the protection is limited. With only 4GB of space, there aren't that many random locations to choose. DLLs, for example, still need to be packed relatively close together, to ensure that there are large tracts of free space open for applications to store their own data in.

This lack of randomness is compounded by the fact that these days, 4GB just isn't that much memory. Filling all the memory with data that the attacker controls is now feasible. In a process known as heap spraying, attackers fill the victim application's memory with large blocks of code that do nothing, followed by their exploit code. This gives attackers much greater flexibility: instead of having to work out the exact memory location of their exploit, they just have to be somewhere close. As long as they find a location in the "do nothing" block, their exploit will run correctly.

In the world of 64-bit, this all changes substantially. With 18 exabytes (theoretically; real processors impose tighter constraints) of memory, there's plenty of room to scatter DLLs liberally making them needles in an unimaginably large haystack. A new Windows 8 feature called "High Entropy ASLR" does precisely this. The vast amount of memory also prevents any realistic attempt at heap spraying—the amount of memory is too large, and the amount that an attacker can fill up is too small.

For many applications, the stronger security provided by HE-ASLR and 64-bit computing probably isn't hugely valuable. As a practical matter, most applications have little meaningful exposure to the kind of attack that ASLR and HE-ASLR are meant to hinder. But Web browsers are a huge exception to this: they're huge vectors for malware, because they're routinely used to connect to networked resources that are beyond the control of any end-user.

Browsers need all the security mechanisms that developers can throw at them, and by sticking with 32-bit code, Firefox is unable to take advantage of some of the security features that Windows 8 has on offer.