[qubes-users] Opening Bitcoin donations for Qubes Project

Ok, ok, so here it is -- Bitcoin donations for Qubes :slight_smile:

http://wiki.qubes-os.org/trac/wiki/Donations

Let's see how much this is worth at all...

For security reasons, let me repeat the bitcoin address here in this
message:

14zockMSKKp5MK6X2cHJ3mQwm9MwYsJ39j

This message should be accessible via Google Groups Web interface over
HTTPS for double verification. Hm, perhaps it is finally a good reason
for us to buy some SSL cert for the wiki...?

This message is also signed by my PGP key that can be found in many
places on the Web.

Cheers,
joanna.

Joanna Rutkowska:

Ok, ok, so here it is -- Bitcoin donations for Qubes :slight_smile:

http://wiki.qubes-os.org/trac/wiki/Donations

Let's see how much this is worth at all...

For security reasons, let me repeat the bitcoin address here in this
message:

14zockMSKKp5MK6X2cHJ3mQwm9MwYsJ39j

This message should be accessible via Google Groups Web interface over
HTTPS for double verification. Hm, perhaps it is finally a good reason
for us to buy some SSL cert for the wiki...?

This message is also signed by my PGP key that can be found in many
places on the Web.

Cheers,
joanna.

Sweet :slight_smile: I'm interested to see how this goes as well.

For those also interested this page should be of interest

~abel

Iā€™ve been waiting for this. Iā€™ll donate to keep this project going.

Thank you for finally opening up Bitcoin donations. Qubes is already quite good, and Iā€™m happy to chip in something to help fund the development, even if itā€™s only enough for ~1 man/woman-hour or so. Iā€™ll donate as soon as I can.

Iā€™d like to use this opportunity to do exactly what you said not to: a feature request :). One of my main problems with Qubes in its current state is how it handles device attachments. Right now, the Qubes VM Manager handles device attachment in a ā€˜VM-centricā€™ way: I have to look at each VMā€™s attached devices to find the one which has a specific device. But what I find is that I really need a ā€˜device-centricā€™ manager: I want to see each device in a list (preferably with an editable label, so I can name my USB controllers ā€˜rear leftā€™, ā€˜front rightā€™, etc., at least until proper USB VM support is added) with its attached VM. I should be able to detach a device from its current VM, switch it to a different VM, etc. This would simplify my life quite a bit, and I donā€™t think it would be too hard. In principle I would be fine to make these changes myself, but I just do not have the time, especially within the next month or so.

For me, the next step would be device-triggered VM attachments, though I imagine this would be a bit more difficult. I envision this working as follows: I plug in my smart card reader, some Dom0 daemon sees the device attachment, finds the reader USB VID/PID in my specified map file, attaches the corresponding USB controller to the map fileā€™s specified VM, then starts that VM. That would be really neat, even if it assumes all devices (or is only restricted to one device) on a controller map to the same VM.

And for what itā€™s worth, my next most desired feature request is split GPG. I would rather see this feature even without your ā€˜trueā€™ split idea, where no untrusted external input (public keys) must be imported into the GPG VMā€“thatā€™s nice and important in theory, but honestly (IMO) not as important in practice.

Thanks for all the good work!

I would like something like a ā€œfeature auctionā€. All planned features of the product should be listed, anyone should be able to add features and to vote for choosen feature by transferring bitcoins. Top voted features should be implemented.

I can understand why you find this idea appealing, but consider the drawbacks of implementing this kind of system in a *security-focused* OS project:

The vast majority of donors have much less security and technical expertise than the Qubes team. Therefore, well-intentioned donors who vote for certain features may be unwittingly working against their own interests simply because they do not realize the security implications of some feature they *think* they want. Likewise, they may be unwittingly working against their own interests in "down-voting" (de-prioritizing by not directing donations toward) some feature which they think they don't care about but which would actually be much more important to improving their security.

This system would effectively shift the direction of the Qubes project from the team's judgement to the voters' judgement. In other words, instead of the decisions being made by the Qubes team, the decisions would be made by those who donate the most.

OTOH, you might say, "Fine, then let's only do this for *optional* features, not for core/security-critical features, which we leave up to the Qubes team." OK, but this might still create a conflict, wherein some users who have donated (perhaps a lot) to the "winning" feature think that the Qubes team now has an obligation to implement it in a timely manner. This could detract from their efforts toward core/security-critical features (and hence create the above conflict where donors unwittingly protest against their own ultimate best interest). (Or maybe the Qubes team realizes that this is happening and ignores the winning optional features in order to focus on the important core/security-critical work, which makes the donors really unhappy because they were told that the top voted features would be implemented.) I suppose that the problem is a general one: The system effectively attaches _strings_ to the donations.