Dobbel Kina-gevinst

Det ser ut til at Elkem blir solgt til kinesere. Når en virksomhet selges skjer det fordi den har større verdi for kjøperen enn for eieren. I dette tilfellet ser kan det være muligheten til å ”stjele” teknologi til Kina som gjør denne handelen fordelaktig for både kjøper og selger.

Kina har til nå i hovedsak fått overført teknologi gjennom utenlandske investeringer i Kina. Resultatet har vært en enorm velstandsutvikling. Minst like viktig er imidlertid Kinas bidrag til verdensøkonomien. Kinas voldsomme vekst har gitt seg utslag i billigere varer, og har sannsynligvis bidratt betydelig til den økonomiske veksten som vesten har hatt det siste tiåret, finanskrisen til tross.

Miraklet Kina illustrer det enorme potensialet i internasjonalt krysseierskap. Direkte utenlandske investeringer medfører overføring av teknologi og kompetanse mellom land. Land med liten teknologisk utvikling tjener på det ved at man kan produsere mer og billigere med samme arbeidskraft. Landene som eksporterer teknologien tjener på det i form av velferdsøkning ved at varer blir billigere. Dette gir ikke bare rom for økt privat forbruk, men også økt offentlig forbruk dersom myndighetene ønsker å prioritere det.

Teknologi er i det hele tatt et gode som ikke forringes av at man deler på det. Tvert i mot øker verdien av teknolog med utbredelse. De som utvikler teknologi må imidlertid ha betalt for arbeidet, hvis ikke vil utvikling stoppe opp. Derfor er det viktig at oppfinnerne får sin betaling. Når utviklingskostnadene er betalt er det imidlertid ingenting som er bedre enn at teknologien spres så vidt som mulig.

Det er derfor usedvanlig sneversynt å frykte kinesisk plyndring av Elkems teknologi. Det beste som kan skje er at denne teknologien tas med til kina og benyttes til å effektivisere silisiumproduksjonen der. Dette kan vi få tilbake mange ganger i form av lavere priser på elektrovarer.
Det er jo heller ikke slik at kineserne kan stjele teknologien. Teknologien er en del av prisen som betales. Om salget går igjennom vil altså kineserne eie teknologien, og det er som kjent vanskelig å stjele noe du selv eier.

Det er også naivt å tro at nasjonalt eierskap har avgjørende betydning for lokalisering av virksomhet. Når kostnadsforskjellene er små vil man kanskje foretrekke å ha produksjonen hjemme. Aksjonærene ville nok likevel ha protestert kraftig dersom styret hadde sløst bort halvparten av utbyttet på et prinsipp om nasjonal lokalisering. Kineserne har sag at de vil beholde eksisterende norsk industri så lenge det er lønnsomt og legge ny industri til Asia, hvilket vel er omtrent det samme som de nåværende eierne hadde tenkt.

Enkelte har likevel tatt til orde for et statlig næringsfond som kunne sørget for norsk eierskap i norske industribedrifter. Et slikt næringsfond vil riktig nok kunne hindret utflytting av industriarbeidsplasser, men det spørs om skattebetalerne vil være villige til å ta den regningen. Det har trolig aldri eksistert et statlig næringsfond i Norge som har gitt meravkastning, og det er vel ingen grunn til å tro at et fond med en filosofi om å stoppe utviklingen vil være noe unntak her.

Staten har en viktig rolle i utviklingen av næringslivet, men man bør kanskje flytte fokus fra arbeidsplassbevaring til jobbskaping. Den kanskje viktigste rollen er å legge til rette for kompetanse i norske bedrifter. Slik kompetanse kommer imidlertid ikke i form av patenter eller industrihemmeligheter, men i form av utdannelse.

Det er et faktum at norske lønninger er for høye for en del industrivirksomhet, selv om ikke alle norske arbeidsplasser kan klassifiseres som kunnskapsintensive. Dette bør vi være glad for, og det er kun mulig fordi vi er mer produktive enn andre land. Det skyldes i stor grad høyt utdannelsesnivå. Om man ønsker lav ledighet og økonomisk vekst må man derfor utdanne kandidater der utdannelsen kaster best av seg. Det vil si der produktiviteten og lønningene er høyest.

Announcing cross_fuzz, a potential 0-day in circulation, and more

I am happy to announce the availability of cross_fuzz - a surprisingly
effective but notoriously annoying cross-document DOM binding fuzzer that
helped identify about one hundred bugs in all browsers on the market - many of said bugs exploitable - and is still finding more.


The fuzzer owes much of its efficiency to dynamically generating extremely long-winding sequences of DOM operations across multiple documents, inspecting returned objects, recursing into them, and creating circular node references that stress-test garbage collection mechanisms.




This design can make it unexpectedly difficult to get clean, deterministic repros; to that effect, in the current versions of all the affected browsers, we are still seeing a collection of elusive problems when running the tool - and some not-so-elusive ones. I believe that at this point, a broader community involvement may be instrumental to tracking down and resolving these bugs.


I also believe that at least one of the vulnerabilities discovered by cross_fuzz may be known to third parties - which makes getting this tool out a priority.


The following summarizes notification and patch status for all the affected vendors:


  • Internet Explorer: MSRC notified in July 2010. Fuzzer known to trigger several clearly exploitable crashes (example stack trace for CVE-2011-0346) and security-relevant GUI corruption issues (XP-only, example, CVE-2011-0347). >Reproducible, exploitable faults still present in current versions of the browser. I have reasons to believe that one of these vulnerabilities is known to third parties.

    Comment: Vendor has acknowledged receiving the report in July (case 10205jr), but has not contacted me again until my final ping in December. Following that contact attempt, they were able to quickly reproduce multiple exploitable crashes, and asked for the release of this tool to be postponed indefinitely. Since they have not provided a compelling explanation as to why these issues could not have been investigated earlier, I refused; see this timeline for more.


  • All WebKit browsers: WebKit project notified in July 2010. About two dozen crashes identified and addressed in bug 42959 and related efforts by several volunteers. Relevant patches generally released with attribution in security bulletins. Some extremely hard-to-debug memory corruption problems still occurring on trunk.


  • Firefox: Mozilla notified in July 2010. Around 10 crashes addressed in bug 581539, with attribution in security bulletins where appropriate. Fuzzing approach subsequently rolled into Jesse Ruderman's fuzzing infrastructure under bug 594645 in September; from that point on, 50 additional bugs identified (generally with no specific attribution at patch time). Several elusive crashes still occurring on trunk. Bad read / write offset crashes in npswf32.dll can also be observed if the plugin is installed.


  • Opera: vendor notified in July 2010. Update provided in December states that Opera 11 fixed all the frequent crashes, and that a proper security advisory will be released at a later date (release notes list a placeholder statement: "fixed a high severity issue"). Several tricky crashes reportedly still waiting to be resolved.

    Note that with Opera, the fuzzer needs to be restarted frequently.


Well, that's it. To download the tool or see it in action, you can follow this link. The fuzzer may be trivially extended to work with any other DOM-compliant documents, plugin bindings, and so forth.