mboost-dp1
unknown
Der var nogen på Slashdot der foreslog at det kunne være et check der skulle forhindre at man snød sig udenom Intel-begrænsningerne i Skype.
Disse begrænsninger:
http://slashdot.org/articles/06/02/13/2015236.shtm...
Disse begrænsninger:
http://slashdot.org/articles/06/02/13/2015236.shtm...
#4
Det vil vel være relavant at stille spørgsmålet "Hvad mere aflæser de, unden at fortælle det (og hvad med at spørge først!!!)?"
Skal man altid acceptere at blive skidt på, bare fordi det "kunne være værre"?
Det vil vel være relavant at stille spørgsmålet "Hvad mere aflæser de, unden at fortælle det (og hvad med at spørge først!!!)?"
Skal man altid acceptere at blive skidt på, bare fordi det "kunne være værre"?
#3 Ja, - og det blev vidst også tilbagevist at en der påstod han var BIOS programmør. Problemet var at det er forskelligt fra BIOS fabrikat til BIOS fabrikat hvordan du læser CPU type.
Mit personlige gæt er at det er for at få en cookie der er en del bedre end de normale. Altså, - hvor mange unikke brugere har vi. Hvilke Skype-idents må formodes at ejes af samme person etc.
Sidstnævnte er ikke helt simpelt. Bare det at to personer bruger den samme maskine er i hvert fald ikke nok.
Mit personlige gæt er at det er for at få en cookie der er en del bedre end de normale. Altså, - hvor mange unikke brugere har vi. Hvilke Skype-idents må formodes at ejes af samme person etc.
Sidstnævnte er ikke helt simpelt. Bare det at to personer bruger den samme maskine er i hvert fald ikke nok.
Måske det for at binde en bestemt computer til en bestemt samtale, og således have mulighed for at indikere at en evt. terrorist har snakket med en kollega omkring mål, hvis der er optaget sådanne samtaler. Mulighederne er mange, men jeg tvivler på at det er noget sundt. Generelt er vi jo god og grundigt påvej ind i et overvågningssamfund, det her er måske bare en lille bid.
Eller måske er det bare rester fra da de tjekkede om det var en AMD eller en Intel maskine.
#8 Hr.Jespersen, det burde ikke kunne gøres på andet end maskiner hvor skype afvikles som root, eller hvis man skal loade et kernel module for at kunne bruge skype. Dette gør sig gældende for linux.
Hvordan det ser ud med OS/2 skal jeg ikke overhovedet forsøge at gøre mig klog på.
Eller måske er det bare rester fra da de tjekkede om det var en AMD eller en Intel maskine.
#8 Hr.Jespersen, det burde ikke kunne gøres på andet end maskiner hvor skype afvikles som root, eller hvis man skal loade et kernel module for at kunne bruge skype. Dette gør sig gældende for linux.
Hvordan det ser ud med OS/2 skal jeg ikke overhovedet forsøge at gøre mig klog på.
Serienummer på motherboardet = de kan identificere dig.
Sikkert noget den amerikanske regering har krævet så de lettere kan spore og verificere om en computer har fortaget et skype opkald.
Men man skulle da tro der var lettere måder.
Sikkert noget den amerikanske regering har krævet så de lettere kan spore og verificere om en computer har fortaget et skype opkald.
Men man skulle da tro der var lettere måder.
Måske har det noget at gøre med efterforskning go aflytning.
man må kunne forbinde mange mønstre med sådanne oplysninger. USA regering er måske med i spillet :)
man må kunne forbinde mange mønstre med sådanne oplysninger. USA regering er måske med i spillet :)
Det siger noget om Windows sikkerhedsmodel, når et program uden videre kan aflæse BIOS. Men det er da rart at høre, at 64 bits udgaven ikke kan køre DOS programmer.
Sådan som arkitekturen er designet kan 8086 kode bare ikke køre i 64 bits mode, og man kunne lidt have frygtet, at Windows ville gøre nogle afsindigt grimme ting for at få det til at virke alligevel.
Men jeg ved egentlig ikke, hvordan det ser ud med de nye virtualiseringstiltag. Muligvis er det kun på maskiner uden virtualiseringsmuligheden, at man ikke kan køre 8086 kode i 64 bits mode.
Gad vide hvad der ville ske, hvis man udskiftede 1.com med et lille program, der ikke udskrev maskinens BIOS men i stedet udskrev nogle andre data af samme længde (evt. en BIOS fra en anden maskine).
Sådan som arkitekturen er designet kan 8086 kode bare ikke køre i 64 bits mode, og man kunne lidt have frygtet, at Windows ville gøre nogle afsindigt grimme ting for at få det til at virke alligevel.
Men jeg ved egentlig ikke, hvordan det ser ud med de nye virtualiseringstiltag. Muligvis er det kun på maskiner uden virtualiseringsmuligheden, at man ikke kan køre 8086 kode i 64 bits mode.
Gad vide hvad der ville ske, hvis man udskiftede 1.com med et lille program, der ikke udskrev maskinens BIOS men i stedet udskrev nogle andre data af samme længde (evt. en BIOS fra en anden maskine).
Nu inden vi får accelereret de vilde konspirationsteorier op i omdrejninger, så kan der faktisk være andre grunde end penge til at de gerne vil have bundkortsinformation. Det kan som nævnt være for at identificere CPU'en eller for at tilpasse Skype bedre til systemet.
For mig er det ikke noget problem at et program jeg har valgt at installere gør hvad den kan for at samle info om computeren for at forbedre sig selv. Det bliver dog lidt kritisk, hvis det vælger at videresende disse informationer.
Jeg ved ikke hvorfor Skype vil læse mit bundkortsinfo, men helt ærligt, så er det ikke definitivt ensbetydende med at de er onde.
Ved at man f.eks. kan generere tilpassede public/private krypteringsnøgler (eller symetriske for den sags skyld) ved at anvende info der er unikt for den maskine der skal bruge nøglen, og hvis det gøres hver gang programmet startes, kan det fint forklare hvorfor Skype skal rode med bundkortet (hvis keys udskiftes for hver session).
Men som skrevet; jeg ved ikke hvorfor, jeg vælger bare at starte med at gætte på lidt mindre end det værst tænkelige scenarie.
For mig er det ikke noget problem at et program jeg har valgt at installere gør hvad den kan for at samle info om computeren for at forbedre sig selv. Det bliver dog lidt kritisk, hvis det vælger at videresende disse informationer.
Jeg ved ikke hvorfor Skype vil læse mit bundkortsinfo, men helt ærligt, så er det ikke definitivt ensbetydende med at de er onde.
Ved at man f.eks. kan generere tilpassede public/private krypteringsnøgler (eller symetriske for den sags skyld) ved at anvende info der er unikt for den maskine der skal bruge nøglen, og hvis det gøres hver gang programmet startes, kan det fint forklare hvorfor Skype skal rode med bundkortet (hvis keys udskiftes for hver session).
Men som skrevet; jeg ved ikke hvorfor, jeg vælger bare at starte med at gætte på lidt mindre end det værst tænkelige scenarie.
#10 Absolut Hr Thomsen, men når vi skidtet installerer, kræver det så ikke rod-privilegier ?
#18 WengoPhone ??
Og nej med det nuværende security framework er OS/2-eCS et tagselvbord. Men Skype er ej heller porteret til denne platform, men hvem ved med Voyager (Bliver sandsynligvis baseret på et UNIX basissystem).
#18 WengoPhone ??
Og nej med det nuværende security framework er OS/2-eCS et tagselvbord. Men Skype er ej heller porteret til denne platform, men hvem ved med Voyager (Bliver sandsynligvis baseret på et UNIX basissystem).
Jeg er sikker på, at skype videresender de infomationen til deres hovedkvarter, hvor de så udvælger de hjem med de dyreste computere som de så lave et indbrug i :P
Hvis de vil opsamle informationer, så skal de da informere og spørge brugerne. Jeg har oplevet flere programmer og især spil, der under installationen spørger om de må sende oplysninger til producenten. For min skyld er det okay de gør det. Det er market research der i sidste ende kommer mig selv til gode, men det her er fandeme for frækt.
Har i læst deres End User License Agreement igennem om der evt. stod noget om det?
http://www.skype.com/company/legal/eula/
http://www.skype.com/company/legal/eula/
Hvis det ikke burde være muligt burde det vel fra CPU udvikleren side vel være spærret ... og ikke det software der ligger over det....
#29 .. intel har jo givet dem penge for at få deres progem til kun at virke på deres CPU'er
men det kan man jo komme uden om med 3. part software .. som også viser det ikke er et hardware problem.
At man nu har fundet det lille program, viser bare at det folk har sagt om skype er rigtigt ..
ps. bruger selv skype .. og er glad for det, men de kan ikke få betydning for mit valg af CPU ..
men det kan man jo komme uden om med 3. part software .. som også viser det ikke er et hardware problem.
At man nu har fundet det lille program, viser bare at det folk har sagt om skype er rigtigt ..
ps. bruger selv skype .. og er glad for det, men de kan ikke få betydning for mit valg af CPU ..
Mon dog de indsamler den information; det er trods alt ulovligt at indsamle personspecifik data (læs: data, som kan føres tilbage til én bestemt person) uden eksplicit samtykke, jf. Persondataloven.
OFFTOPIC/FYI: Al data, som indsamles om en, har man i øvrigt ret til at få udleveret (men ikke dermed slettet) når som helst.
OFFTOPIC/FYI: Al data, som indsamles om en, har man i øvrigt ret til at få udleveret (men ikke dermed slettet) når som helst.
#14
Men det er da rart at høre, at 64 bits udgaven ikke kan køre DOS programmer.Hvornår blev du født? Der er så ekstremt mange fede dos spil. bare syn at ms aldrig fik lavet en ordenlig dos emulator, de ikke engang kan finde ud af at emulerer deres eget os. Eller er dos stadig en så stor del af windows det ikke bliver rigtig emuleret?
Der jo i realiteten ikke nogle der siger at de sender koden nogle steder hen.
Det eneste der er bevist er at de læser den og bruger den i programmet.
Som nogle siger herinde er det måske bare for at lavet et rimeligt unikt id.
Eller til at lave en kryptering til samtalen.
Det eneste der er bevist er at de læser den og bruger den i programmet.
Som nogle siger herinde er det måske bare for at lavet et rimeligt unikt id.
Eller til at lave en kryptering til samtalen.
http://share.skype.com/sites/security/2007/02/skype_extras_plugin_manager.html
It is quite normal to look at indicators that uniquely identify the platform and there is nothing secret about reading hardware parameters from the BIOS.
It is quite normal to look at indicators that uniquely identify the platform and there is nothing secret about reading hardware parameters from the BIOS.
"We in EasyBits believe that privacy is one of the biggest issues of modern Internet era. Our privacy policy is probably one of the most strict that you ever met. We simply do NOT collect any personal information from you."
Taget fra http://www.easybits.com/skypito/company.htm
Hmm, jeg gider ikke mere. Den ene siger nej det gør vi ikke, den anden siger jo det gør i. Jeg tror vi skal vente på noget mere fra "Myria", eller lade den ligge.
Taget fra http://www.easybits.com/skypito/company.htm
Hmm, jeg gider ikke mere. Den ene siger nej det gør vi ikke, den anden siger jo det gør i. Jeg tror vi skal vente på noget mere fra "Myria", eller lade den ligge.
Serienummer på motherboardet = de kan identificere dig.Nej, der findes da ingen database over serinumre på motherboards og tilhørende ejere. Hvordan mener du at man skulle kunne identificere folk fra serienummeret. Højst kan man se om to opkald kommer fra samme computer (uden at det nødvendigvis betyder at det er den samme person...) hvis dette nummer sendes med opkaldet, men det er der jo ingen der ved.
Sikkert noget den amerikanske regering har krævet så de lettere kan spore og verificere om en computer har fortaget et skype opkald.For det første er Skype et europæisk foretagende (ja, det er købt af Ebay, men det er stadig europæisk) og for det andet så kan man ikke spore noget som helst på det nummer...
Såså folk, det kan jo være de har en legitim grund til det. Hvis argumentet er for at læse X kan vi performe bedere i Y. Og de i øvrigt ikke sender X nogen steder hen, så har jeg ikke noget problem.
“Since the EasyBits component produced errors on the 64-bit Windows, Sauer says the new version 3.0.0.216 of Skype has been modified so it no longer reads out BIOS data”
fra: http://www.heise-security.co.uk/news/85067
#42: "Problemet" eksisterer kun i Skype 3.0 .. det skyldes den 3. parts gallerikomponent der er tilføjet. Det skal dog siges, at jeg kører Windows XP x64 og jeg har altså ikke kunnet finde filen selvom den skulle blive kørt ved Skypes start.. omvendt har jeg ikke brugt gallerifunktionen endnu..
fra: http://www.heise-security.co.uk/news/85067
#42: "Problemet" eksisterer kun i Skype 3.0 .. det skyldes den 3. parts gallerikomponent der er tilføjet. Det skal dog siges, at jeg kører Windows XP x64 og jeg har altså ikke kunnet finde filen selvom den skulle blive kørt ved Skypes start.. omvendt har jeg ikke brugt gallerifunktionen endnu..
[url=#27]#27[/url] Louis
[url=#29]#29[/url] masterbrain
[url=#34]#34[/url] owrflow
Af den grund er det ikke nok at emulere DOS, man skal emulere DOS og alt den hardware, som programmerne kunne finde på at pille ved. Og vil man have mulighed for at udveksle data mellem programmer, kunne tilgå filsystemet som man ville gøre med en lokal harddisk og i øvrigt have mulighed for at bruge I/O redirection mellem DOS programmer og det omgivende system, så skal der gøres ekstremt grimme ting.
Den rigtige løsning for at køre DOS programmer under et moderne operativ system er at emulere en komplet PC og køre DOS på den. Et disk image kan fungere som drev 0x80, evt. implementeret som CoW. Vil man have adgang til det rigtige filsystem må DOS programmerne se det som et netværksfilsystem. Sådan har det aldrig fungeret når man har kørt DOS programmer under Windows.
I nogen udstrækning kan virtuel 86 mode hjælpe til at lave en emulator uden man selv behøver implementere en komplet CPU emulation. Det kører også hurtigere på den måde. Desværre er PC arkitekturen en lappeløsning som er svær at emulere præcist, og selv virtuel 86 mode er ikke rigtig virtualisering, for programmer kørende under virtuel 86 mode kan nemlig se at det er tilfældet.
Lad mig give et par eksempler, der er så vidt jeg husker fire forskellige måde at blokere tastatur interrupts. Og tastatur driveren under DOS gør brug af dem alle, og kan ikke fungere korrekt uden. Fra 286 og fremefter er der yderligere en lille grim detalje. Tidligere var der en udgang på tastatur controlleren, som ikke var i brug. Men fra 286 var der en indgang på memory controlleren men gerne ville have software styring over, det brugte man så udgangen fra tastatur controlleren til. Prøv lige at forestille dig den spagettikode, der skal til at emulere sådan en spagettiarkitektur. Man havde egentlig lyst til at droppe den feature, den eksisterede jo alligevel kun for at understøtte gamle fejlbehæftede programmer, som gjorde forkerte antagelser om segmenteret addressering. Men når HIMEM.SYS blev indlæst testede den faktisk om den linie på tastatur controlleren fungerede som den forventede, så man var tvunget til at emulere den for at få HIMEM.SYS til at virke. Og når man så derefter prøver at indlæse EMM386 viser det sig, at den kigger på et CPU statusregister, og når den opdager, at CPUen er i virtuel 86 mode, nægter den at indlæse. Heldigvis findes der erstatninger for EMM386, som er mere velegnet til en virtuel 86 mode baseret emulation. Og så er der de afskylige plannar/memory mapped I/O modes som EGA/VGA grafikkort har. De er næsten umulige at emulere. Tidligere Windows versioner løste det ved at kræve at man kørte dem i fuld skærm, og gav så programmet direkte adgang til hardwaren. Hvis man faktisk vil emulere dem er man nødt til at trappe enhver adgang til de hukommelsesområder og så selv emulere den instruktion som prøvede at tilgå grafik hukommelsen. Det vil sige, at man faktisk ikke kan emulere EGA/VGA grafik uden også at emulere hele CPUen. Godt nok kun for en enkelt instruktion, så dog koster det performance, men ikke lige så meget som en komplet emulation.
Intet under, at der i mange år ikke fandtes nogen perfekt PC emulation. På et tidspunkt var der selvfølgelig nogen, som kunne se at der var penge i at gøre det beskidte arbejde. Og løsningen involverede ting så som at på runtime parse alle instruktioner for at se om der var nogen, som det var nødvendigt at emulere. Så kunne en lettere modificeret udgave få lov at køre på den rigtige hardware, men med traps indsat på steder, hvor der blev brugt farlige instruktioner.
Lad os se om de nye virtualiseringstiltag snart gør det muligt at lave en emulation som kræver mindre arbejde at implementere og som kører med bedre performance. Det er nok det bedste håb der er for at opnå problemfri afvikling af DOS programmer på en 64 bits Windows. Det betyder muligvis ikke, at man bare vil kunne dobbeltklikke på en .COM fil og så kører den. Men faktisk kunne det måske alligevel i nogen udstrækning lade sig gøre at gøre noget i den retning. Jeg vil lige prøve at skitsere en løsning, som kunne virke...
Man har et disk image, som når det starter op vil tilgå host filsystemet som et netværksfilsystem. Det vil derfra afvikle en speciel .BAT fil, som skifter til et passende directory på netværksfilsystemet og starter den .COM eller .EXE fil, man har dobbeltklikket på. Det som så sker er at .BAT filen ikke i virkeligheden findes på host filsystemet, men dynamisk genereres af den del af host koden som står for at implementere netværksfilsystemsfunktionaliteten. Hvis man vil forbedre lidt på performance kan man tage et snapshot af den virtuelle maskines tilstand lige før den etablerer forbindelsen til netværksfilsystemet.
Jeg ser ikke noget grimt eller problematisk i den løsning (kun et pænt stykke arbejde i at implementere det). Og så ville man kunne afvikle sin .COM fil uden at den nogensinde ville se den fysiske hardware. Hvis den prøvede at aflæse BIOS ville den se en pæn BIOS, men det ville være den som den virtuelle maskine brugte, og den ville være identisk på alle computere med samme version af den virtuelle maskine.
Nogle der ved om Skype på Linux, BSD og Mac også aflæser ens bios eller er det kun Windows?På Linux kan det ikke lade sig gøre uden root permissions. Der er intet i den normale funktionalitet af skype, som ikke kan gøres uden root permissions. Så det er nok at undersøge, om programmet gør noget for at opnå root permissions. Hvis dele af koden kører med root permissions er det mistænkeligt. Hvordan bliver programmet installeret? Foregår det gennem det normale pakkesystem eller har de hacket deres egen installer sammen? Hvis det foregår gennem det normale pakkesystem er der fire ting man skal kigge efter: indeholder pakken nogle scripts der aktiveres som en del af installationen, indeholder pakken device inodes, indeholder pakken suid eller sgid executables, installerer pakken filer i directories hvorfra de automatisk bliver aktiveret. Hvis svarene på de fire spørgsmål er nej, så kan programmet ikke opnå root permissions. Hvis programmet har sin egen installer, så skal den bare køres uden root permissions, så er man på den sikre side.
[url=#29]#29[/url] masterbrain
Hvis det ikke burde være muligt burde det vel fra CPU udvikleren side vel være spærret ... og ikke det software der ligger over det....Nu var det jo Intel, der ville have spærret for funktionalitet på AMD CPUer. Det tror jeg ligesom ikke AMD ville hjælpe med.
[url=#34]#34[/url] owrflow
Der er så ekstremt mange fede dos spil.Ja naturligvis. Det er jo ikke fordi jeg synes det er fedt at miste muligheden for at køre dem. Men jeg synes det er bedre at muligheden mangler fremfor at den er lavet som et grimt hack i kernen, der potentielt kan kompromitere systemets stabilitet og sikkerhed.
Eller er dos stadig en så stor del af windows det ikke bliver rigtig emuleret?Nu var DOS ikke et operativ system udfra den gængse definition i dag. DOS varetog kun en del af de opgaver som der i dag forventes af et operativ system. Der var absolut ingen beskyttelse, og ethvert program havde uhindret adgang til al hardware, og i mange tilfælde, var det nødvendigt at udnytte dette, fordi det var den eneste måde at tilgå nogle hardware komponenter på.
Af den grund er det ikke nok at emulere DOS, man skal emulere DOS og alt den hardware, som programmerne kunne finde på at pille ved. Og vil man have mulighed for at udveksle data mellem programmer, kunne tilgå filsystemet som man ville gøre med en lokal harddisk og i øvrigt have mulighed for at bruge I/O redirection mellem DOS programmer og det omgivende system, så skal der gøres ekstremt grimme ting.
Den rigtige løsning for at køre DOS programmer under et moderne operativ system er at emulere en komplet PC og køre DOS på den. Et disk image kan fungere som drev 0x80, evt. implementeret som CoW. Vil man have adgang til det rigtige filsystem må DOS programmerne se det som et netværksfilsystem. Sådan har det aldrig fungeret når man har kørt DOS programmer under Windows.
I nogen udstrækning kan virtuel 86 mode hjælpe til at lave en emulator uden man selv behøver implementere en komplet CPU emulation. Det kører også hurtigere på den måde. Desværre er PC arkitekturen en lappeløsning som er svær at emulere præcist, og selv virtuel 86 mode er ikke rigtig virtualisering, for programmer kørende under virtuel 86 mode kan nemlig se at det er tilfældet.
Lad mig give et par eksempler, der er så vidt jeg husker fire forskellige måde at blokere tastatur interrupts. Og tastatur driveren under DOS gør brug af dem alle, og kan ikke fungere korrekt uden. Fra 286 og fremefter er der yderligere en lille grim detalje. Tidligere var der en udgang på tastatur controlleren, som ikke var i brug. Men fra 286 var der en indgang på memory controlleren men gerne ville have software styring over, det brugte man så udgangen fra tastatur controlleren til. Prøv lige at forestille dig den spagettikode, der skal til at emulere sådan en spagettiarkitektur. Man havde egentlig lyst til at droppe den feature, den eksisterede jo alligevel kun for at understøtte gamle fejlbehæftede programmer, som gjorde forkerte antagelser om segmenteret addressering. Men når HIMEM.SYS blev indlæst testede den faktisk om den linie på tastatur controlleren fungerede som den forventede, så man var tvunget til at emulere den for at få HIMEM.SYS til at virke. Og når man så derefter prøver at indlæse EMM386 viser det sig, at den kigger på et CPU statusregister, og når den opdager, at CPUen er i virtuel 86 mode, nægter den at indlæse. Heldigvis findes der erstatninger for EMM386, som er mere velegnet til en virtuel 86 mode baseret emulation. Og så er der de afskylige plannar/memory mapped I/O modes som EGA/VGA grafikkort har. De er næsten umulige at emulere. Tidligere Windows versioner løste det ved at kræve at man kørte dem i fuld skærm, og gav så programmet direkte adgang til hardwaren. Hvis man faktisk vil emulere dem er man nødt til at trappe enhver adgang til de hukommelsesområder og så selv emulere den instruktion som prøvede at tilgå grafik hukommelsen. Det vil sige, at man faktisk ikke kan emulere EGA/VGA grafik uden også at emulere hele CPUen. Godt nok kun for en enkelt instruktion, så dog koster det performance, men ikke lige så meget som en komplet emulation.
Intet under, at der i mange år ikke fandtes nogen perfekt PC emulation. På et tidspunkt var der selvfølgelig nogen, som kunne se at der var penge i at gøre det beskidte arbejde. Og løsningen involverede ting så som at på runtime parse alle instruktioner for at se om der var nogen, som det var nødvendigt at emulere. Så kunne en lettere modificeret udgave få lov at køre på den rigtige hardware, men med traps indsat på steder, hvor der blev brugt farlige instruktioner.
Lad os se om de nye virtualiseringstiltag snart gør det muligt at lave en emulation som kræver mindre arbejde at implementere og som kører med bedre performance. Det er nok det bedste håb der er for at opnå problemfri afvikling af DOS programmer på en 64 bits Windows. Det betyder muligvis ikke, at man bare vil kunne dobbeltklikke på en .COM fil og så kører den. Men faktisk kunne det måske alligevel i nogen udstrækning lade sig gøre at gøre noget i den retning. Jeg vil lige prøve at skitsere en løsning, som kunne virke...
Man har et disk image, som når det starter op vil tilgå host filsystemet som et netværksfilsystem. Det vil derfra afvikle en speciel .BAT fil, som skifter til et passende directory på netværksfilsystemet og starter den .COM eller .EXE fil, man har dobbeltklikket på. Det som så sker er at .BAT filen ikke i virkeligheden findes på host filsystemet, men dynamisk genereres af den del af host koden som står for at implementere netværksfilsystemsfunktionaliteten. Hvis man vil forbedre lidt på performance kan man tage et snapshot af den virtuelle maskines tilstand lige før den etablerer forbindelsen til netværksfilsystemet.
Jeg ser ikke noget grimt eller problematisk i den løsning (kun et pænt stykke arbejde i at implementere det). Og så ville man kunne afvikle sin .COM fil uden at den nogensinde ville se den fysiske hardware. Hvis den prøvede at aflæse BIOS ville den se en pæn BIOS, men det ville være den som den virtuelle maskine brugte, og den ville være identisk på alle computere med samme version af den virtuelle maskine.
Sådan! Rart at se, at der af og til er egentlige eksperter/kodere/folk med dybere viden om sagerne, der stikker hovedet frem og pipper om emnerne!
Tilbage til Skype-snakken: Det undrer mig virkelig, at der ikke er flere, der brokker sig over, at man ved installation af Skype accepterer, at ens internetforbindelse bliver delt til andres Skype-trafik, uden ydererligere begræsninger:
http://skype.com/company/legal/eula/ siger
"Article 4 Utilization of Your computer
4.1 Utilization of Your computer. You hereby acknowledge that the Skype Software may utilize the processor and bandwidth of the computer (or other applicable device) You are utilizing, for the limited purpose of facilitating the communication between Skype Software users."
Derfor har jeg aldrig lukket Skype indenfor. De skal ikke komme her og bruge min båndbredde, og da slet ikke min processor, til tilfældige menneskers gøren og laden via Skype!
Tilbage til Skype-snakken: Det undrer mig virkelig, at der ikke er flere, der brokker sig over, at man ved installation af Skype accepterer, at ens internetforbindelse bliver delt til andres Skype-trafik, uden ydererligere begræsninger:
http://skype.com/company/legal/eula/ siger
"Article 4 Utilization of Your computer
4.1 Utilization of Your computer. You hereby acknowledge that the Skype Software may utilize the processor and bandwidth of the computer (or other applicable device) You are utilizing, for the limited purpose of facilitating the communication between Skype Software users."
Derfor har jeg aldrig lukket Skype indenfor. De skal ikke komme her og bruge min båndbredde, og da slet ikke min processor, til tilfældige menneskers gøren og laden via Skype!
Tilbage til Skype-snakken: Det undrer mig virkelig, at der ikke er flere, der brokker sig over, at man ved installation af Skype accepterer, at ens internetforbindelse bliver delt til andres Skype-trafik, uden ydererligere begræsningerDet er lissom hele humlen ved P2P...
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund