Once you renounce citizenship, I don't think the united states will let you back in, I'm not entirely sure but I believe that is the case.

You can still get a passport from your new home country you are a citizen of and get into the US to visit. Probably need to apply for a Visa if you want to stay more than X days, and need additional paperwork if you ever want to work there or reside for a longer period.

We need regulation....

Insurers aren't mandated to comply — though most do.

They should be required to pass their audit or pass an audit by a 3rd party auditor who is approved by the OIG.

Failure to comply should result in fines and bar them from writing or acquiring any more insurance policies, until they do.

Also, in the event of a breach at this juncture, there should be a financial penalty for their negligence.

Well... a software license is a type of contract. There's a principle in contract law; that if there are multiple ways which a condition can be interpreted, then it will be interpreted for purposes at time of adjuication in the manner that most favors the parties who did not produce the contract term / present the offer.

The same contract or license text can be interpreted in different ways for different cases.

You are mistaken in thinking they use the Linux kernel in ESXi. There is no Linux kernel anywhere in ESXi.

They have written their own operating system from scratch, and they did a complete rewrite of the kernel in the update from ESXi 3.5 to 4.0.

What they have done is copied a subset the interface API from the Linux kernel. Much how like the Wine Project has copied API details from Win32 without permission from Microsoft.

This allows existing driver source code that already works in Linux to be compiled using the VMware driver development kit into a binary that can be loaded as a driver in ESXi.

This means that hardware vendors can write the driver once, and then it could be built for either Linux or ESXi, so that seems beneficial for Linux users to have more drivers still being written for Linux.

This is considered a legacy framework, and VMware is already phasing this out... see details on the new native driver framework

This will be sad, as the native driver framework is proprietary, and it will likely no longer be possible to write your own drivers for ESXi, once vmklinux is gone, without purchasing the driver development tools at high $$$.

Also, major enterprises are running ESXi on much of their hardware, so the incentive may go away for many manufacturers to release information or develop Linux drivers; they can just produce their binary ESXi drivers and be done with it.

Well, having used VMware Workstation 8 and 9, I can was able to download and modify the Linux drivers provided by VMware, necessary to fix some kernel related bugs

I don't think the lawsuit is over vmware tools. VMware provides source code to most of the VMware tools components; often they are installed by building the source code.

The VMware hypervisor includes a special management Virtual Machine run by the vmkernel which uses Busybox.

They do not include the source code for Busybox. However, there is a written offer for customers to request source code on CD for the product you purchased, valid for 3 years after you purchased the software product from VMware, by sending a request to an address given of VMware General Counsel, Attn: Open Source Files Request.

Versions of ESXi prior to 5.5 supported an architecture for drivers called vmklinux; essentially, the VMware kernel supported a framework compatible with Linux drivers ---- you could compile Linux drivers from source code and load them into the vmklinux system. ESXi5.5 introduced a new thing called Native Drivers, but they still support the Linux kernel driver SDK. There is no Linux kernel code, other than drivers themselves, however, they have only copied the Kernel driver API interfaces.

What are you, in law enforcement? This is a story about warrantless collection of DNA in a rape case. Not everyone is a rapist.

That's true.... but if enough people are in the DNA database, then it is likely for many innocent people to wind up being accused.

If police have sampled armchair DNA from 10 million people over the years and built a database of 1 million entries.

If the confidence of a match in the DNA test is 99.99%.

Then that means the test is still wrong 0.01% of the time, so in such a large database, there could easily be 1000 bogus matches.

If police had decided to interrogate the guy; and decided there was probable cause, then I think it was in their rights to get a DNA sample, just like it was in their rights to fingerprint any suspect.

What I see as abusive is covertly securing information from people.

For DNA to be analyzed by law enforcement and attributed to a person: it should definitely be required to be secured in a more reliable manner than gathering from the environment.

Unless the environment is the actual scene of the violent crime being investigated; gathering DNA surreptitiously and in a manner where it would likely be subject to contamination should not be allowed.

Don't Kickstart something that seems like a good idea but has never been done before. If it's really a good idea then people have either tried and failed multiple times before

Why not? Sure it's a risk. But nothing good ever came out of not taking risks.

However.... It would probably be a good idea to not offer or promise 'donation rewards' that can only be delivered if the project is successful.

I do not see how some additional open source software and PCB designs being released is not a win for the community and the people who did the project. Sure, they did not have the success they hoped, and they effectively found their design wasn't viable to meet the objectives.

But just because the project didn't work out did not mean that the outcome was useless or not worth what went into it.

The law must be satisfied to the extent possible.

For starters: No deleting any e-mail in the personal account until the go'vt can review. Hand over the credentials for the "personal" accounts and allow all messages contained or archived to be copied to the federal servers and go into the public record; contact the email service provider with a court order to hand over all backups, have a police seizure of all digital media Mrs. Hillary had access to, and charge Mrs. Hillary the cost of compliance with the order for recovery of official messages resulting from non-compliance with the law.

Why just Illinois? This is a national laboratory funded by the US government. If there is a reduction in public services, then there should be a commesurate decrease in their funding by at least the value to the public of those services.

Unrestricted MS group policy push means all of TLS/SSL is a complete sham.

Correct me if I am wrong.... but group policy is downloaded over CIFS via SYSVOL, and there is no encryption or digital signing of the file being downloaded, so a MITM could insert an altered group policy of the attacker's choice, including bogus certificates to be installed... of the attacker's choice.

and if the OS can do it, so can any other software that has admin rights.

What would cause you to think that?

Administrator is a user privilege level inside the operating system. Nothing says that an admin level user can necessarily do everything. You can even make an operating system that has no such thing as admin rights, if you want.

You can certainly lockdown certain capabilities so they are available to the OS but not to 3rd party software.

One thing they could require you to do would be to visit a Microsoft website and go through a process that requires the end user to answer a captcha, login to an account, and supply a copy of the certificate, to receive a validation mark, before a local trust mark can be added, then the marked certificate can be downloaded and imported, before proceeding with a GUI-driven process.

Without the computer-specific Microsoft validation mark on the certificate, the 'Import' API calls will simply refuse to import the certificate to the trust database.

And when the cert is verified, the trust authorization validation chain's signature can be verified as well.

You want to be able to do this automatically at least in corporate environment, and manually for development tools.

We buy certs for corporate resources. It's not necessary to have an internal CA, and from a security standpoint it's probably not very safe, since the CA is more likely to be compromised than a public CA which has more carefully implemented and audited controls.

Woo, and now a company can't have its own internal CA deployed automatically.

Why not? Just make it so that upon joining to a domain a Volume licensed copy of Windows, a domain certificate trust mark will optionally be enabled, And certificates can be installed by group policy, but only to computers that are a member of the AD domain whose administrator digitally signed the policy, and only with Enterprise or Server edition of Windows installed on the workstation.

The browsers/OSes should harden by eliminating the ability for 3rd party software to automatically install a certificate or CA as trusted into the system database. They should also remove any functionality that allows a 'globally' wildcarded certifacte to be deployed to the browser

Basically, when the computer's hostname is assigned, or during user profile creation, the trusted certificate store should be reinitialized with only stock certificates approved by the OS maker or browser vendor.

A machine-specific keypair should be generated and used to stamp all the certificates with a local trust signature.

Any access to the machine keypair / stamp should be available only through an interactive approval process.

Sysprep'ing an image or changing the product key should invalidate the local trust mark and require manual re-approval of all certs not in the browser vendor's official trust list.

I'm not sure how easy it is to scan the internals of the metal.

Acoustic microscopy.

Also, since the identification info could be encoded in various formats... such as microscopic dimples in the metal, magnetic elements, digital circuit elements such as passive RFID, or other methods

It's possible that the criminal could be unable to know whether or not there is a serial number that is still readable which the criminal themselves cannot see, since mostly just law enforcement and gun shops would have both the scanning equipment and the know-how to operate it.

Each gun already imprints a unique microscopic signature on a bullet and casing. Just submit a scan of a fired bullet and cartridge to a central database for each new firearm sold

They already tried that in Maryland, and I understand it turned out very poorly, the government itself instead of the manufacturer wound up bearing huge costs; there were error-prone and labor-intensive steps involved in taking in test-fired casings submitted by manufacturer, photographing , logging to database.

But it was also noted California DOJ survey less than 70% of the casings of the same make as the fingerprinted device yielded the correct result anywhere in the top 15 matches of the database search, for the same type of ammunition. When a different type of ammunition was used, less than a 40% success rate.

Conclusion? Capturing the natural ballistics to a database is not the way to go, if you can do better.