Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 61 reacties

Bij de introductie van de nieuwe Acrobat X-serie heeft Adobe de vaak belaagde Reader voorzien van een extra beveiligingslaag. De pdf-reader draait voortaan in een sandbox-omgeving, waardoor het risico op aanvallen zou worden verkleind.

Adobe Acrobat XDe Acrobat X-productserie, die 30 november voor zowel Windows als OS X op de markt moet komen, bestaat uit de authoringtool Acrobat X Standard, Acrobat X Pro en Acrobat X Suite. De Acrobat X Reader zal gratis te downloaden zijn en kent als belangrijkste vernieuwing dat de pdf-reader in een sandbox zal draaien. De zogenaamde 'protected mode' zal in zowel de stand-alone-versie als de browser-plug-in standaard geactiveerd zijn.

Met de protected mode worden embedded javascript-code, 3d-rendering en het renderen van graphics binnen de sandbox-omgeving gedraaid, waardoor malware geen kans meer zou maken om het besturingssysteem via de Reader aan te vallen. Adobe heeft bij de ontwikkeling van de beveiligingslaag samengewerkt met Microsoft en Google, die ervaring hebben met de techniek in respectievelijk Office 2010 en Chrome.

In de Acrobat X-suite zal het volgens Adobe eenvoudiger worden om binnen werkgroepen aan documenten te werken, mede dankzij ondersteuning voor Microsoft SharePoint. Ook de koppeling met Adobe Photoshop zou zijn verbeterd, terwijl Office-documenten gemakkelijker zijn om te zetten naar pdf-bestanden.

Adobe gaat ook online zijn aan Acrobat gerelateerde dienstverlening uitbreiden. Zo kunnen via SendNow grote bestanden worden uitgewisseld, terwijl CreatePDF het mogelijk maakt om bestanden via een webbrowser of Reader X naar pdf-formaat te converteren. Adobe laat ook weten dat het werkt aan een Reader-applicatie voor Windows Phone 7 en BlackBerry OS. Voor het Android-platform en de iPhone zijn al langer pdf-readers van Adobe verkrijgbaar.

Acrobat X Standard krijgt een adviesprijs van 349 euro exclusief btw, terwijl de Pro-uitvoering 559 euro exclusief btw moet opbrengen. De Acrobat X Suite, waarvan onder andere Photoshop CS5 deel uitmaakt, moet 1475 euro exclusief btw gaan kosten. De upgrade-prijzen liggen logischerwijs lager.

Moderatie-faq Wijzig weergave

Reacties (61)

Slimme aanpak, zou vaker moeten worden toegepast om alles wat veiliger te maken.

Raar eigenlijk, ik dacht dat een paar jaar geleden men al druk bezig was om kwetsbare software (browsers enz.) te voorzien van een virtuele machine zodat er bij inbraak (via bugs en dergelijke) nagenoeg geen schade gedaan kan worden. Dat is ongeveer hetzelfde als dit.

Hoe zit het daarmee? Bijna elke pc ondersteunt nu hardwarematige virtualisatie via de CPU, moet toch te doen zijn!
Slimme aanpak, zou vaker moeten worden toegepast om alles wat veiliger te maken.
Een sandbox maakt dingen niet veiliger. Het maakt de directe omgeving rondom de sandbox robuuster. Als er iets in de sandbox in stort zal dat minder snel nadelige effecten hebben op de directe omgeving van de sandbox. In het geval van een browser, als 1 window crasht, zal niet meteen je hele browser crashen.
Dus als in Adobe Reader X 1 pdf crasht, zal de reader nog overeind kunnen blijven staan.
Het voegt geen veiligheid toe.

De sandbox omgeving zoals die door sommige operating systems geleverd wordt (zoals Android) maar dingen wel wat veiliger daar dat volledige applicaties een eigen executie omgeving krijgen waar ze niet uit "kunnen" breken. Dus ze kunnen niet andere applicaties lastig vallen. Maar deze sandbox geeft geen beveiliging tegen code injection in de applicatie zelf (door het openen van een malformed document).

In principe was Adobe Reader altijd al een sandbox voor PDF documenten. Maar deze sandbox bleek zo lek als een mandje. Dus nu gaat Adobe nog een sandbox om de sandbox bouwen.
Een sandbox maakt dingen niet veiliger. Het maakt de directe omgeving rondom de sandbox robuuster. Als er iets in de sandbox in stort zal dat minder snel nadelige effecten hebben op de directe omgeving van de sandbox. In het geval van een browser, als 1 window crasht, zal niet meteen je hele browser crashen.
Cute, maar je hebt de kok horen fluiten maar geen idee waar z'n lepel hangt.

Wat jij beschrijft is gewoonweg het splitsen van een applicatie in meerdere processen, bijvoorbeeld per tab of per document, en dat er een hoofdproces is dat hetgene is dat mensen daadwerkelijk zien. Als er een tab of document op z'n bek gaat of iets doet wat niet hoort, dan crasht niet de hele applicatie.

Nou is het wel zo dat om een echt effectieve sandbox te krijgen dit een vereiste is, maar in het geval van Chrome (en ik denk ook Adobe Reader X) wil dat zeggen dat elk proces slechts de absolute minimum rechten krijgt om z'n taak uit te voeren, en niks meer. Een 'tab-proces' in Chrome kan bijvoorbeeld niet een op zich staand venster openen, of bestanden uit de My Documents directory van de user lezen. Die rechten heeft het niet. Sandboxing is alleen maar een veiligheidsmaatregel.

Jouw voorbeeld van code injection wordt hier inderdaad niet mee tegengegaan. Wat wel gebeurt is dat de rechten van het proces zo zijn ingesteld dat die code injection weinig nut heeft, aangezien er toch weinig mee kan worden bereikt.

[Reactie gewijzigd door Korben op 19 oktober 2010 10:12]

De pc van nu ondersteund het, wat dacht je van de gebruikers met een pc van 3 jaar en ouder :)

dan sluit je zo 60+ % uit van je klanten.

omdan 2 verschillende ontwikkel trajecten /versies er op na te houden is ook niet ideaal

[Reactie gewijzigd door Babipangang op 18 oktober 2010 17:29]

Maakt toch niet uit. Op een tv van 10jaar terug kan je ook geen HD kijken. Op je 486 moet je ook geen win7 of Ubuntu 10.10 draaien.

Je kijkt enkel of je kan ontwikkelen zodat je virtualisatie een extra functionaliteit is maar waar niet altijd van gebruik kan gemaakt worden.
Hoewel HW virtualisatie OT is bij dit onderwerp...
Bij Intel is het afhankelijk van het processor type of VT ondersteund wordt VB de E7x00 serie niet en de E8x00 serie wel, Q8X00 niet en Q9x00 wel.
Zie dit lijstje uit begin 2009 om een idee te geven. In tegenstelling wat daar bij staat is het vrij simpel vast te stellen of je processor VT heeft. Eeven CPU-Z starten :P
mijn laptop van 3,5 jaar oud ondersteund ook VT :P
true, al het amd werk met ddr2 geheuge ondersteund ook hw virt. en dat bestaat al weer een jaar of 4 a 5 .. de vraag is natuurlijk wat je er aan hebt volgens mij heb je er voor sandboxing niet zo veel aan omdat je uiteindelijk toch het zelfde OS aan spreekt..

hoe dat bij intel zit weet ik niet exact maar volgens mij was het dat het op s775 draaide als je cpu het ondersteunt, een een cpu + ram upgrade hoeft in de meeste gevallen niet zo moeilijk te zijn...
Het wordt al langer gedaan. IE8 draait op Vista en Windows 7 al in een soort sandbox, in de zin dat het programma op een OS security niveau lager dan de normale user draait. Wat dat betreft snap ik ook niet waarom de Tweakers redactie naar Office 2010 refereert....
Misschien is lezen een kunst.. Maar de redactie refereert naar Office 2010 omdat de mensen met wie Adobe samen heeft gewerkt ook hebben gewerkt aan vergelijkbare technieken in Office 2010 en in Chrome OS... Dus dat heeft niets met de tweakers redactie te maken..
Dat is toch een heel ander soort virtualisatie :)
mijn vraag is..
gaat dit niet ten koste van de performantie?
Als het goed wordt gedaan zal je het verschil niet merken; Chrome gebruikt bijvoorbeeld ook sandboxing technieken en dat is op dit moment 1 van de snelste browsers die er te vinden is.
Of Adobe capabel genoeg is om de nieuwe versie van hun Acrobat lijn snel te houden is punt 2; hun huidige versies zijn ook niet bepaald rap te noemen.
ze zeggen idd dat dat zo is maar in de practijk merk ik dat op de machines die IK heb getest er geen sprake is van chrome sneller dan firefox (windows en linux getest op: opteron 939 165 dual 1,8ghz (3gb ram) ubuntu server gui (met browser voor oa. webmin),
amd 939 4xxx 2,4ghz x2 2gb ram windows 7BH x32
amd am2+ 7750BE 3.0ghz 3gb ram windows 7BH x32

alleen op mijn laptop amd turion x1 mk38 2,2ghz 2gb ram (ubuntu lucid x32 xfce-edition ) lijkt chromium iets sneller te zijn dan firefox (en dan vooral met 10tabs of meer.. .

het zal in de praktijk dus vooral aan de hardware, het OS en de programma-code liggen.

wat ik wel storend vind is dat je onder windows dus nog steeds zelf verantwoordelijk bent om je potentieel gevaarlijke app in een vm te laten draaien, en dat er nog niet zoiets bestaat om dat door windows af te laten handelen. onder linux werkt dat allemaal wel iets makkelijker al is ook daar nog geen 'ass proof' manier voor gevonden ...
Er zitten twee van die mooie toetsen op je toetsenbord, Shift genaamd, waarmee je hoofdletters kunt maken. Try it.

On-topic, hoe heb je geconstateerd dat Chrome wel of niet sneller is dan Firefox? Benchmarks? Dan wil ik graag resultaten zien, want uit alle andere benchmarks blijkt dat Chrome substantieel veel sneller is dan Firefox, zeker onder Windows. Als je op het oog 'vindt' dat Chrome niet sneller loopt dan Firefox... dat kan, maar dat is ook niet wat er bedoeld wordt met 'sneller'. In dit geval wordt bedoeld dat qua ruwe performance Chrome op veel vlakken alle andere browsers outperformt.
zou vaker moeten worden toegepast om alles wat veiliger te maken
Dus als het je niet lukt de lekken te dichten doe je er een zandbak omheen? Lijkt me niet helemaal de meest wenselijke strategie.
niet helemaal de juiste manier om het te zeggen, elke software kan lek zijn, fouten gebeuren nou eenmaal, en op dit moment weet je niet wat er over 5 jaar allemaal voor mogenlijkheden zijn. het voordeel van de sandbox is juist dat je als je een fout over het hoofd hebt gezien, een kwaadwillende gebruiker er niks mee kan doen.

of bedoel jij dat je liever hebt dat je om de zoveel tijd gehacked wordt, dan dat de makers van software dit implementeren om ervoor te zorgen dat fouten niet altijd betekend dat je gehacked kan worden.
En nu de sandbox dichten :-)
Met hardware virtualisatie zou je een hele PC virtualiseren, beetje overkil om een complete Windows/Linux/OSX te starten voor je PDF lezertje. Een software sandbox is dan beduidend sneller.
Beter zou het natuurlijk zijn om gewoon de bugs op te lossen c.q. features te schrappen die per definitie niet veilig zijn (scripting engine in je PDF, get real). In plaats daarvan krijgen we een sandbox om de bugs te verhullen. Lijkt me eigenlijk geen vooruitgang maar een goedkoop lapmiddel.
(oeps, reactie op XanderDrake)

[Reactie gewijzigd door latka op 18 oktober 2010 17:27]

Wat een onzin. De noodzaak voor een sandbox staat volkomen los van bugs en features.

Een goed ontworpen systeem gaat van minimaal twee security lagen uit. De mogelijkheid tot exploits via bugs en features zal altijd bestaan, ongeacht hoe hard je daar aan werkt. Daarom wil je een ťxtra veiligheids laag inbouwen, zodat wanneer iets door de eerste laag breekt, het tegen de tweede laag botst.
Tijd zal het leren , maar sandbox is ook aanwezig bij java en daar gaat ook een en ander weleens mis
Ja en nee: standaard Java draait niet in een sandbox maar in een virtual machine. Deze kun je dichttimmeren met een Java2 security policy en dan spreek je van een sandbox. De policy bepaalt letterlijk welke files je wel en niet mag openen. Er zijn echter 2 problemen met deze aanpak:
1) Ontwikkelaars (zelfs gecerticifieerde) weten hier vaak niets van en willen er ook niets van weten. Ergo, software is nooit getest onder een sandbox en werkt dus niet
2) Policies schrijven letterlijk voor welke bestanden een applicatie mag openen. Dat is vrij beperkend voor een desktop-applicatie. Dus of je zet in de policy "c:\*.*" wat het nut van de sandbox wegneemt of de JavaVM doet een pop-up voor iedere file-access en je hebt een soort UAC gemaakt wat iedereen haat.

Sandboxes werken perfect voor applicaties die voorspelbaar zijn. Dit zijn meestal server-applicaties. GUI's en gebruikers zijn de schrik voor policy auteurs.
Klok en klepel.

In Java is geen sandbox aanwezig. De Java Virtual Machine (JVM) waarmee Java apps uitgevoerd worden *is* een sandbox.

Verder ben ik het met latka eens dat dit nergens over gaat.

AHBdV heeft gelijk dat in een goed systeem meerdere veiligheidslagen zitten, echter is het waanzin om in een programma een sandbox in te bouwen. Het feit dat Adobe Reader dit nodig heeft is een teken aan de wand imho. Als je de gevolgde redenering doortrekt zou *elke* applicatie in een eigen gebouwde sandbox moeten draaien. |:(
en juist DAT zou niet eens zo gek idee zijn, hoeveel macro- zut zijn we al niet tegen gekomen. juist die untrusted code in een sandbox laten draaien zou een hoop schelen, in office in acrobat in je berouwser (nee geen tikfout :P) (flash java jscript etc) dan hoeft de rest van het hele ding niet eens zo zeer streng beveiligd te zijn.

code die je logischerwijs niet vertrouwd moet je eigenlijk altijd in een sandbox draaien.
Alle internet software zou eigenlijk in een sandbox moeten draaien. Simpelweg omdat je daar continue met een gevaarlijke buitenwereld in contact staat. Bij lokale software is dat gevaar veel minder aanwezig, en kun je de sandbox achterwege laten. (Hoewel ook dan het logisch is in ieder geval de rechten te limiteren).
Helemaal mee eens. Tijd om notepad in een sandbox te zetten. Die filosofie van 1 laag is geen laag gaat niet echt op voor een desktop omgeving. Hiervoor heb je een multi-user omgeving die gebruikers onderling van elkaar afschermt. Zou wat zijn als al je apps in een sandbox draaien: kun je geen copy-paste meer doen van app A naar B zonder de sandbox te doorbreken (en daar begint het pas, wat als je ActiveX en of DDE zou willen). Probleem is dat security met sandboxes gewoonweg flawed is als je het je gebruiker probeert te verkopen of het is zo lek als een mandje.

De Chrome sandbox dient een heel ander doel: crashende plugins de browser niet laten meenemen en hiervoor gebruikt men: inderdaad de process-abstractie.

Punt blijft: een sandbox om je app is of flawed by-design als je gebruiker nog wat wil kunnen of niet te verkopen. Aangezien MS en Adobe samengewerkt hebben ben ik bang voor het 1e (history-repeats-itself).

Als je echt veilig wilt: gebruik de switch-user functionaliteit en gebruik een dedicated (non-admin) PDF lees account. Shortcut is Windows-L et-voila een gratis sandbox die goed afschermt (en copy-paste dus inderdaad verhinderd).
als je statement zou kloppen gaf ik je nu gelijk, maar het is helemaal niet waar dat copy past buiten een sandbox onmogelijk is, je kunt daar prima een api voor maken die gegevens door de 'sandwall' (rand van de zandbak) heen loodst, dergelijke data kun je zoals veel programmeer talen gebeurd prima strippen van mogelijk gevaarlijke zut, je kunt het eerst door je virusscanner laten checken en je kunt er tal van andere dingen mee doen. en uiteindelijk toch als data buiten je sandbox laten komen.
Door de sandwall heen? Dan loopt de zandbak leeg en heb je het eerste potentiŽle lek te pakken ;)
Je moet enkel een 'OS' maken dat pdf kan weergeven. Zo heb je op meerdere laptops ook een snelstartOS waarmee je enkel je mail kan checken bv. Dat start in 3seconden op omdat het zo'n kleine kernel kan hebben.
Het gaat hier natuurlijk niet om een VM als in VirtualBox of VMWare waarin een volledig OS wordt gesimuleerd, maar om een sandbox(bijv. Google Chrome). Ze hebben allebei een afgesloten omgeving, maar het doel is (waarschijnlijk) anders. Bij een sandbox is het doel het beveiligen van de rest van het systeem door het volledig af te bakenen. Bij VM is het doel om een OS in een OS te draaien.
Als ze de snelheid van de standaard reader eens zouden verbeteren...

#ontopic: is dit alles niet al geÔntegreerd in Google Chrome 7? Chrome draait sowieso al in een sandbox omgeving (elke tab apart), en heeft een pdf reader applicatie ingebakken.
Volgens mij is dat geen PDF reader, maar meer een tooltje wat PDF naar HTML omzet.

Zou misschien eens verstandig zijn om, net als Flash, de Adobe Reader in te bakken.
"Als ze de snelheid van de standaard reader eens zouden verbeteren... "

Kennelijk heb je een paar jaar onder een steen geleefd. Adobe wordt ondertussen modulair opgebouwd, dus alleen de nodige zaken worden opgestart. Gevolg: een veel snellere opstart.
Chrome draait niet in een sandbox hoor... wel starten ze voor elk tabje een eigen proces maar dat is echt niet hetzelfde.

En tijdperk? Ook in 2010 is de Adobe Reader nog zo traag als dikke str*nt een steile helling op hoor. En dat zal hiermee niet verbeteren... :+

En verder... Office 2010... Mmmm ik weet niet hoe verstandig het is om dat na te willen maken. Persoonlijk heb ik het idee dat als een readertje voor documentjes al niet veilig te maken valt zonder er een virtuele machine omheen te bouwen dat er dan serieus iets mis is. Dit voelt meer als een hele dikke pleister...
dan denk ik toch dat je de reden van de onveiligheid van PDF niet helemaal mee hebt gekregen. want pratte text in pdf is zo'n beetje net zo veilig als een papier in de brievenbus.

het gaat om de embedded meuk zoals scripts en forms die dingen die je normaal altijd in een sandbox hoort te laten draaien.
Chrome start voor elk tabje een proces, en dat proces draait in een zogenaamde sandbox-mode, wat wil zeggen dat het proces alleen de echt noodzakelijke rechten krijgt om het uitvoeren van een pagina mogelijk te maken, en niks meer.

Overigens, wie heeft het over een virtuele machine? Mensen horen sandbox en denken gelijk aan een VM. Sandboxing is het zonder VM een afgeschermde omgeving opbouwen.
Van welk tijdperk kom je? 2005? Adobe reader is tegenwoordig snel genoeg.
Reader is enkel sneller geworden en de alternatieven zijn bloated geworden. Resultaat in 2010 dat je beter Adobe Reader kan gebruiken... Wereld op z'n kop.
Foxit Reader is voor mij nog steeds het snelst. Als je op een quadcore of iets dergelijks werkt zul je het niet snel merken. Maar op een netbook zorgt het voor een aanzienlijk verschil en het is niet bloaded (let wel op tijdens de installatie). Tevens heeft het een beveiligde modus (standaard aan) om hacks tegen te gaan. Weet niet of dit hetzelfde als een sandbox is.
Nee, die beveiligde modus zal alleen bepaalde features uitschakelen die mogelijk vatbaar zouden kunnen zijn voor hacks.
qua snelheid heb je gelijk, maar die aanhoudende stroom lekken :X
Hmm...De huidige PDF reader is al 143MB...ben benieuwd hoeveel groter het programma wordt om het in een VM te draaien. Eigenlijk best vreemd dat je bijna 150 MB nodig hebt om een documentje te kunnen lezen / printen. Al die overige features zouden eigenlijk als plugin ingeladen moeten worden...
De huidige PDF reader waarmee je alleen documenten leest en print is 26,4MB (AdbeRdr940_nl_NL.exe). Net formaat voor pakket met een aantal lees modussen, browserplugins etc. Wat tegenwoordig bovendien erg snel is.

Edit: waarschijnlijk bedoel je de installatie map. Een derde daarvan is installatie/reparatie bestand. De helft zijn plugins voor lees opties, spellingcontrole en etc.

[Reactie gewijzigd door Malarky op 18 oktober 2010 20:12]

Dat is de gecomprimeerde omvang. Men is op een gegeven moment gebruik gaan maken van Nosso wat een commercieel pakket is wat zeer hard comprimeert (en zeer traag is...).. Download size != pakket omvang

Foxit is een stuk kleiner en dat zit niet alleen in de plugins.

Heb hier nog wat netbookjes en tablets die het niet kan schelen dat er irrelevante files inzitten: de disks/SSDs lopen toch erg hard vol met dit soort meuk.
Wat ik me nu afvraag; verandert er voor Mac OSX gebruikers nu iets? Standaard worden PDF'jes geopend in "preview", was dit onveilig en blijft dit zo of is dit een veilige manier van PDF'jes openen?
Preview heeft ongetwijfeld ook zo zijn eigen beveiligingslekken (de vorige jailbreak voor iOS 4.0.1 was bijvoorbeeld gebaseerd op een exploit in de PDF-reader op de iPhone). Het is moeilijk te zeggen welke van de twee veiliger is; wel denk ik dat er doordat Acrobat meer toevoegingen op PDF ondersteunt (o.a. scripting binnen een PDF) er veel meer ruimte is voor beveiligingsfouten. De 'sandbox' die Adobe nu introduceert zou de reader in theorie moeten kunnen beschermen tegen lekken die nog niet zijn ontdekt, maar natuurlijk moeten we nog maar zien of daar niet aan te ontsnappen valt :)
Het valt me op dat het nieuwsbericht an sich positief is, maar dat de Tweakers er overwegend negatief op reageren. Valt er dan niks goed over te zeggen?
Jawel, alleen valt uit de comments op te maken dat de helft van de commenters geen flauw idee is wat een sandbox is en wat het verschil is tussen virtualisatie en sandboxing. Persoonlijk vind ik het een erg goed idee, het werkt in ieder geval beter dan al je input proberen te valideren en whitelisten (waar toch wel een manier omheen te verzinnen is).
De prijzen zijn weer als van ouds van de pot gerukt en gelukkig dankzij de vele zeer goed werkende PDF printers totaal niet nodig. Wat betreft de verbeterde veiligheid laten we het zo zeggen eerst zien dan geloven tot noch toe is Adobe niet echt een van de beste bedrijven als het gaat om het schrijven van veilige software. Ook al hebben ze samen gewerkt met andere bedrijven die dit soort werk eerder gedaan hebben is er vast en zeker nog meer dan genoeg ruimte geweest voor de Adobe development groepen om er een zooitje van te maken.

Het is best jammer dat Adobe de zo goed bedoelde PDF standaard zo heeft weten kapot te maken. In plaats van de standaard aan te passen en voor voldoende veiligheid te zorgen voor de het systeem van de gebruiker hebben ze besloten om een software laag tussen het systeem en het onveilige bestandsformaat in te hangen. Dat lijkt misschien een goed idee maar het is niets anders dan een lap middel. Als Adobe het probleem had aangepakt in plaats van de symptomen dan zou het gebruik van PDF bestanden een heleboel veiliger zijn geworden voor iedereen. Het grote probleem is dat door deze oplossing de eindgebruikers niets anders kunnen dan de Adobe oplossing gebruiken, want een alternatieve oplossing die een zelfde virtuele omgeving gebruikt voor het veilig stellen van het systeem van de gebruikers is er op dit moment niet.
Met andere worden de vendor lock-in is alleen maar groter geworden en dus zullen mensen die een beetje weten wat ze doen al snel overstappen op een andere oplossing die een vergelijkbaar resultaat bied maar niet de gevaren van dit Adobe product met zich mee brengt. Wat laten we eerlijk zijn +300 euro voor een pakket dat niets anders doet dan een bestand omzetten naar een ander formaat en je dan de optie geeft wat basis tekst verwerkings opties to te passen op dat bestand dat is toch wel heel erg duidelijk misbruik maken van een lock-in situatie door de leverancier van deze software. Zeker als je daarbij weet dat het resulterende bestand alleen "veilig" terug te lezen is met een reader gemaakt door deze zelfde fabrikant.
De prijzen zijn inderdaad krankzinnig te noemen, vinden ze het gek dat er piraterij is.
Amerikaanse wanpraktijken zijn het. :(
Ik geef er 20 euro voor.

[Reactie gewijzigd door Soldaatje op 18 oktober 2010 18:55]

Jij geeft er geld voor, voor die rommel?

Persoonlijk blijf ik zo ver mogelijk van PDF vandaan en raak ik het alleen aan met een hele lange stok en ik heb er dus nog geen 20 cent voor over. Zoals gezegd er zijn gratis PDF printers die hetzelfde kunnen. (Waarom je PDF zou willen maken is beyond me, maar goed sommige mensen printen hun e-mail en dat snap ik ook niet dus er zal wel een reden voor zijn).
Als je er maar €20 voor over hebt gebruik je gewoon niet het volledige product. Jij bent waarschijnlijk al blij met een document op te slaan naar pdf, dat is al gratis mogelijk.
true maar het is natuurlijk wel tekenend dat er weinig pdftigs te krijgen is voor de consument.
naar mijn idee, ben je dan eigenlijk al snel veroordeeld tot libreOffice die een degelijke pdf conversie ondersteund ...
dat bijna elke pc hardwarematige virtualisatie via de CPU doet zou ik even willen bijstellen , denk dat momenteel niet de helft van de desktops (over laptops nog maar te zwijgen)
bv de core 2 reeks alleen de 6000 en 8000 reeks .... en laat de 4000 en 7000 reeks nu eenmaal het meerendeel van de huidige in bruik zijnde pc's zijn
Je mag aan 10% max denken. In de meeste OEM's voor consumenten zetten ze er met opzet geen cpu met hardmatige vt in om enkele euro's lagere prijzen te kunnen hebben.

Zelfs op de werkvloer ga je geen hoge cijfers zien.
aan de andere kant als je een veilig os wilt als MS zijnde en je zou hw virt gaan gebruiken in bijv win7 sp2 kun je prima al die klanten aanraden om hun pc te laten upgraden met een cpu die het wel ondersteunt, je hoeft daar immers neit eens voor te her-installeren.

overigens worden de cijfers wat mider als je amd mee gaat rekenen bijna alle amd cpu's ondersteunen het namelijk WEL, als sinds 2006 ...
Ik hoop dat het hierdoor niet veel trager wordt.
Er is toch nog wat fout gegaan in de vertaling:
New in Adobe Reader X Commenting is now available in Adobe Reader X, with Sticky Notes and Highlighter tools available to all users. Expands PDF access to mobile devices with free Adobe Reader X for Android, Windows(R) Phone 7 and Blackberry Tablet OS. Safer viewing of PDF files with new Protected Mode security capabilities in Reader X.

NB with free Adobe Reader X for Android, Windows(R) Phone 7 and Blackberry Tablet OS

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True