What you're looking for is xPUD; a distro with the tagline: "The shortest path to the cloud". It has a very fast boot time, its main component is an Internet browser, it has quite a small form factor and it can be installed from Windows.
Note that you can't (easily) use it for much beyond web browsing, though.
QEMU's built-in Samba service
The not-functioning -net user,smb option was caused by an incompatibility with newer Samba versions (>= 4). This is fixed in QEMU v2.2.0 and newer with these changes:
(Debian has backported the latter two patches to 2.1+dfsg-6 which is present in Jessie.)
Usage
You can export one folder as \\10.0.2.4\qemu when using User networking:
qemu-system-x86_64 \
-net user,smb=/absolute/path/to/folder \
-net nic,model=virtio \
...
When QEMU is successfully started with these options, a new /tmp/qemu-smb.*-*/ directory will be created containing a smb.conf. If you are fast enough, then this file could be modified to make paths read-only or export more folders.
Mode of operation
The samba daemon is executed whenever ports 139 or 445 get accessed over a "user" network. Communication happens via standard input/output/error of the smbd process. This is the reason why newer daemons failed, it would write its error message to the pipe instead of protocol messages.
Due to this method of operation, the daemon will not listen on host ports, and therefore will only be accessible to the guest. So other clients in the network and even local users cannot gain access to folders using this daemon.
Since QEMU v2.2.0 printer sharing is completely disabled through the samba configuration, so another worry is gone here.
The speed depends on the network adapter, so it is recommended to use the virtio netkvm driver under Windows.
Also note that the daemon is executed by its absolute path (typically /usr/sbin/smbd) as specified at compile time (using the --smbd option). Whenever you need to try a new binary or interpose smbd, you will need to modify the file at that path.
Other caveats
Executables (*.exe) must be executable on the host (chmod +x FILE) for the guest to have execute permissions. To allow execution of any file, add the acl allow execute always = True option to a share.
Example read-only smb.conf configuration which allows execution of any file (based on QEMU v2.2.0):
...
[qemu]
path=/home/peter/windows
read only=yes
guest ok=true
force user=peter
acl allow execute always = True
Best Answer
If you squint, VM security looks a lot like LAN host security. It's just another machine on the network, with the same sort of attendant risks. If you would willingly put a Windows 7 host on the LAN, you shouldn't be especially worried about putting a Windows 7 VM on the VM host.
It is possible to lock a VM down to the point where it is less dangerous to LAN hosts (including the VM host OS) than a separate box connected to the LAN. You can set up host-only networking, for example, so that the VM can only talk to network servers running on the host OS. Or, set it up without any networking at all. That is useful in test environments, where the VM doesn't need to access outside resources. This does make applying security patches harder, but if you only need the VM for testing software compatibility, it could be just the thing.
Desktop VM host systems like VirtualBox have increasing amounts of convenience features enabled by default, especially for Windows and OS X guests. They will do things like share the host user's Downloads, Desktop, and Documents folders with the VM. If you're concerned that the Windows 7 VM might get infected with a network-destructive virus, you should think about turning these features off, since they appear to the Windows guest as a network-shared drive.
Think through the risks. A shared Downloads folder may actually increase security if you keep it mostly empty, and use it instead of allowing the VM network access. You could download new software and security patches on the host to the Downloads folder, switch into the VM, install it, and delete the file.
Short of such automatic sharing, though, VMs are not especially worrisome tech from a security standpoint. If anything, they're a net positive.