The first 10 minutes of this video(05:00 to ~10:00 to be exact) gives a pretty good explanation of "cyber" as used here, I think..// sorry for double post - closing " missing in first:(
I thought I remember reading that encrypting an encrypted file can actually make it less secure than either encryption step alone.
Well, then I should be able to take your encrypted file, and then I'll encrypt it again and again until it's completely insecure and can be broken by my calculator! Who needs quantum computers or fancy graphics cards?
I look forward to knowledgeable people looking through the site and report what they find, and hopefully Mega fixing the problems found. Right now I trust them slightly more than for example Dropbox, for no other reason that they need a bit of effort to get your data (and probably in a way you can notice / avoid if you're vigilant), instead of it happening by accident. Also, their whole legal and business defense rides on them not being (trivially) able to do that, so it's in their own best interest to keep things working properly.
They're actually upfront about threats to the user's security.
Is my stored data absolutely secure?
All security is relative. The following attack vectors exist - they are not specific to MEGA, but we want you to know about the risks: Individual accounts are jeopardized by: - Spyware on your computer. A simple keylogger is enough, but session credentials and keys could also be extracted from memory or the filesystem. - Shoulder surfing. Do not type your password while someone could watch your keystrokes. - Password brute-forcing. Use strong passwords. - Phishing. Always confirm the security status of your connection (https://) and the correct domain name (mega.co.nz) before entering your password.
Large-scale attacks could be mounted through: - A "man in the middle" attack. Requires issuing a valid duplicate SSL certificate in combination with DNS forging and/or attacks on our BGP routes (a DigiNotar-style scenario). - Gaining access to the webservers hosting https://mega.co.nz/index.html and replacing that file with a forged version (this would not affect access through the installed app base). Note that manipulating content on our distributed static content CDN does not pose a security risk, as all active content loaded from index.html is subject to verification with a cryptographic hash (think of it as some kind of "secure boot" for websites). This type of attack requires sending malicious code to the client and is therefore detectable. - Gaining access to our core server infrastructure and creating forged key requests on existing shares. This type of attack only affects data in shared folders and is detectable on the client side as well.
What if I don't trust you? Is it still safe for me to use MEGA?
If you don't trust us, you cannot run any code provided by us, so opening our site in your browser and entering your password is off limits. If you still want to use MEGA, you have to do so through a client app that was written by someone you trust.
Doesn't that look pretty reasonable? What more do you want them to do? They created a pretty impressive webclient-driven easy-to-use file locker system, and they clearly spell out the problems with that approach.
Many of the article's points are pretty moot, btw. It does not use JS random function, they have extra verification for the 1024 bit SSL encrypted data, and the deduplication only works for shared files ("copy to my locker" functionality is mentioned - same data, same key, same place on the storage servers).
The part about mega.co.nz being able to send malicious code stealing your password is explicitly mentioned in their FAQ, and in a better way too. They even cover other attack vectors the article didn't.
They made a decent system, and they're upfront and honest about it's limitations. The article is at best FUD.
"Deduplication is done based on the entire encrypted file and only happens if you either upload the same file encrypted with the same key twice (unlikely) or if you copy or import an existing file in your file manager (more likely)."
I was saying something about wild assumptions... Yep..
Lemme see, SSL part. Well, main site use 2048 bits, and the JS on that page loads and verifies all other resources. And file upload / downloads are already encrypted before SSL even touches them. So that point is completely moot.
And the "Mega server could send bad code" is already covered in Mega's own FAQ - well,duh. I doubt it comes as a shock to anyone.
As for the deduplication, I don't know. But there are ways to do that (like using file content hash as encryption key, for example - no idea if they actually do this - or just try to dedup the actual encrypted content. There is a (well, small) chance that two encrypted files have same data in a block). We just don't know, and making wild assumptions from it is.. just wrong.
Also, Mega does in fact NOT use JS random function. It use time sampling from user generated events, with RC4 as mixing function.
The whole article is just stupid. It makes wild assumptions, doesn't understand how (parts of) the site works, repeat things the site already informs users about, and are just plain wrong on some parts.
Is this yet another troll article by some attention hungry ad pushers?
Update : Regarding the random source, this is the code they use, and it's from this project. It use mouse and keyboard events (not all, math.random is used to decide which ones), with rc4 as mixing function.
I wrote a comment about the crypto system yesterday, from a outsider amateur's point of view. Nothing in that article was even surprising.
It's actually pretty cool, they do point out more or less the exact things in their FAQ, which is surprisingly honest for such a site. Most would try to handwave it away or just outright ignore it.
As extra info to that comment I wrote earlier, I confirmed that they save a version of the RSA key on their server, and during login a blob of data is sent in (login user in cleartext, and probably hashed / crypted pw) to check if its a valid user before handling out the RSA key.
I can imagine sharing works like this : 1. find friend, 2. get pub key for friend, 3. decode file key with my private key, 4. encrypt it with friend's public key, 5. send to server
And sharing folders.. I guess each folder have an encrypted list of keys to files in it, and the key for the folder is encrypted with your key. So sharing a folder would then work much the same as sharing a file.
And regarding deduplication I saw an idea in a comment that could explain that. Every file is hashed locally, the hash being the actual AES key. Encrypt file, use pub RSA to encrypt hash, send both to server. Same file will be same file, dedup works, and everyone got their own key to it. That would also allow them to nuke all uploads of an illegal file, and keep "bad file" hash lists for child porn and similar.
Now, I haven't actually looked at the JS code for the service yet, so all of this guesstimate:)
Click create account, write info That's one. Then you get email, and click the link in the email. Then you get a page asking for password, again. That's two.
well, technically, they only have to break your hashed password (probably easiest attack vector). Then they can decrypt your private key, and then they have full access to all your files.
However, Mega should be able to identify files stored on their server if they have access to the original files. Consider if a Mega has access to a file called 'The_HoBBiT_Crazy_Delta_XxXDVDRip_firsTPost.avi' (e.g. they were provided the file by some company who wanted to check for compliance with licensing). They use the Mega client system to encrypt that file, producing an encrypted file and a file decryption key. They then check to see if any files on the server have an exact match to that encrypted file (e.g. first by hash, then by comparing length, then by an exact comparison of the encrypted bytes). It would then be possible to delete the file, check to see who has uploaded this particular file, and produce a list of people who also have access to that file.
So you're saying that every file is encrypted with the same key? Err no. What they could do would be to hash the file before upload, in the browser, and then send that hash in addition to the encrypted file (and encrypted key).
As far as I can tell, they're encrypting each file with an unique random key in the browser before uploading, using AES-128. I know they put an RSA key in local storage, so I guess that is then used to encrypt the key for the file and then the encrypted key and the file is uploaded.. And according to them, the RSA key is encrypted by your user password. Still not sure if the encrypted rsa is stored on the server or just client, but it would be pretty useless if you always had to use the same browser, and if local storage gets wiped in any way that would also kill all your files, so.. Probably stored on server.
So that means: Login password used to decrypt RSA key, which is then used to encrypt random 128bit data (for AES128 of new files), and decrypt relevant encrypted strings for downloading files.
I do know that the download shortcuts created have both file ID and a key attached after the # sign (meaning the server never sees it, only the client-running javascript).
So far, so good -- theoretically. As long as you trust them it's pretty solid, but it's fairly easy to include a small js snippet that would send the password you type into your browser to some server. Possibly their own, possibly encrypted (they already have full crypto running in browser, and there's a lot of background talk to and from server). If LEA really really wanted, they could force Mega to serve special JS to a suspected client that sent the user PW back to them, or just the entire decrypted RSA key.
So, while pretty safe (and as safe as you can make it in pure HTML5 / JS I think), and with their whole business riding on them not knowing what you're doing, I think we're decently protected from "for teh lulz" random grabs of passwords.. But to be truly secure, you'll need trusted code running on your local machine.. As they actually point out in their FAQ:)
I discovered the same password problem today, so you're not the only one. Pretty sure I did write the correct password though.
So there might be that some/several accounts got corrupted somehow, and are thus dead. Noticed the same problem you had, no way to reset or delete the account, so I had to use another of my ~30 standard emails... But yeah, looks like a real problem.
I use Intel's SRT and you know, it actually works pretty darn well.
VM's feel snappy, games load really fast, even steam itself doesn't act like it's running on a 386.
It's not always perfect, for example after downloading and installing a few new games on Steam (amounting to ~30gb being shuffled into it) GW2 was noticeably slower to launch.. For about the first two times. After that, smooth sailing. And after seeing it load on a friend's system with only spinning disk, it was still loads better even with the cache halfway decimated.
Got 20gb of my SSD configured for caching a 1tb slowpoke disk, and the rest of the 120gb set off to windows. Worked perfectly so far.
A friend of mine had an alarm clock for when he should go to bed. When forgetting to set that, he sat playing all night and got interrupted by the normal alarm clock instead, telling him it was time to go to school.
* Windows 8 isn't that bad. * Apple Maps isn't that bad. * The iPhone 4 antenna was not that bad. * That terrible patent you just heard about isn't that bad. * The internet always lies to you.
Where ever they get the idea that 'it just works' is quite beyond me.
Lots and lots of PR money. And IMHO a brilliant move. You see, computers are hard. Everyone knows computers are hard. And if something happens, you can't do anything, because everyone knows computers are hard.
But then comes something different. Something that is EASY. They say it everywhere. It just works, and is easy to use! So when something happens, it can't be that difficult to get it working, surely? This is after all easy.
The difference it makes is that in first scenario people give up at once, without even trying. In the second, they try their best because it's after all supposed to be easy.
And it turns out, that when you actually try to solve the problem, then it actually is easy to get it working again (compared to giving up at once and not even trying, at least).
It just works, and is easy because they tell people it is so. Pure genius:)
The thing is, you're not selling a product, you're selling an idea. An idea entombed in a product, but still an idea.
If someone made a chair, it's a definite product. I can touch it, sit in it, and sell it. If someone wants a chair like that, they can 1. buy the chair from me, at which point I'd have to make a new chair to be able to sell to a new customer. or 2. copy it, make a replica of it. With enough time, materials, equipment and skill, it can be done. They get their chair, and I still have mine to sit in and sell. They can also 3. Steal my chair, in which case they have a chair, and I have none. The time and materials I invested in it is gone. I'd have to make a new one from scratch.
The problem with an idea is that, at the core of it, it's just data. And computers are truly excellent at working with data. So with option 2 above skill, time and materials mostly disappear. The only thing left is equipment, and almost everyone got a computer. It's still not stealing, but it can be a devaluation of the product you are selling (I say can be, because there are cases where product value have increased as a result of rampart copying. Adobe products, Microsoft products and this story are examples of this).
If someone said "I've now made this chair, and shall now get paid for everyone sitting in it, until I've been dead for 75 years!" people would think it nuts. If however, he was offering a service (a place to rest, which included a chair) then it would be different, but just the chair, wherever it happens to end up? Hardly. Yet, "I've now written this book, and shall now get paid for everyone reading it, until I've been dead for 75 years!" is perfectly acceptable. Now, think a bit before you say something. The book is sold as a product. Yet, unlike other products, when bought it's not ours. I'm not free to for example publish pictures of it. I can't improve it and sell the better version (AFAIK). It is sold as a product, yet it is not. This is, I think, one of the core problems with copyright as it is now. Intellectual property (*cough*) is cherry-picking advantages both from the product side of things, and the service side of things, and it has allowed itself to grow too big. Into a completely new thing, which the world is still struggling to get a grip on. And thus you see where some of the completely crazy stuff happening are coming from.
All this goes double and triple when applied to music and software. And I'm producing software myself, so I see your point. I'm not saying copyright needs to go, I'm saying copyright in this age is something new and unbalanced. Before copyright, people lived by performing their ideas, whereas they were stories or music. They created books containing their ideas, before mass production was possible. Now, any idea can be replicated across the entire globe in a matter of hours, by more or less anyone, at little or no cost. And people expect to live off their (or someone else's idea) idea for the rest of their life - and then some. The times ahead will be.. interesting.
Why do people complain when the government limits the choice of Internet providers, but the pirates removing my ability to choose my own business model is somehow a good thing?
You forget that you're not free to choose just any business model. I'd like a business model where everyone owning a computer paid me $1 per year as license to my software, but I doubt that would fly (hell, I'd even stretch to $.5). Here it is not the government or the fat cats restricting your business model, but your customers. These who are copying your books are people who actually want to read your story. They are your target, your potential client. They have a different view of how to get your books than you have. Think why, and think if there's any way to move closer to wha
Slashdot Mirror
Look..
Could anyone break the Crackberry monopoly? Well yes, iPhone could, and quite spectacularly too.
Could anyone break the Symbian phone system, with all its apps? Yep, iPhone again.
Could anyone break the iPhone monopoly? Yes, Android did that.
You can't judge the future just by what is now, folks. People have tried that before:
"This 'telephone' has too many shortcomings to be seriously considered as a means of communication."
-- William Orton, president of Western Union, in 1876, when Alexander Graham Bell tried to sell the company his invention.
"There is no reason anyone would want a computer in their home."
-- Ken Olsen, founder of Digital Equipment, in 1977.
Alternatively, they just scraped this..
No need to overthink it.
The first 10 minutes of this video (05:00 to ~10:00 to be exact) gives a pretty good explanation of "cyber" as used here, I think.. // sorry for double post - closing " missing in first :(
The first 10 minutes of this video (05:00 to ~10:00 to be exact) gives a pretty good explanation of "cyber" as used here, I think..
I thought I remember reading that encrypting an encrypted file can actually make it less secure than either encryption step alone.
Well, then I should be able to take your encrypted file, and then I'll encrypt it again and again until it's completely insecure and can be broken by my calculator! Who needs quantum computers or fancy graphics cards?
This is similar to what I've said earlier (eerily similar, in fact..).
The issues the original article raise are either false or silly, and just glancing at the JS code could tell you that.
However, there are some other potential issues with the code I noticed, and at least one of them have proven to be a problem.
I look forward to knowledgeable people looking through the site and report what they find, and hopefully Mega fixing the problems found. Right now I trust them slightly more than for example Dropbox, for no other reason that they need a bit of effort to get your data (and probably in a way you can notice / avoid if you're vigilant), instead of it happening by accident. Also, their whole legal and business defense rides on them not being (trivially) able to do that, so it's in their own best interest to keep things working properly.
User's password is used for unlocking user's RSA key. File key is randomly generated (and encrypted with said RSA key before sent to server).
They cover the crypto in section 1.4 here, if you're interested.
You haven't read their own FAQ I take it?
They're actually upfront about threats to the user's security.
Is my stored data absolutely secure?
All security is relative. The following attack vectors exist - they are not specific to MEGA, but we want you to know about the risks:
Individual accounts are jeopardized by:
- Spyware on your computer. A simple keylogger is enough, but session credentials and keys could also be extracted from memory or the filesystem.
- Shoulder surfing. Do not type your password while someone could watch your keystrokes.
- Password brute-forcing. Use strong passwords.
- Phishing. Always confirm the security status of your connection (https://) and the correct domain name (mega.co.nz) before entering your password.
Large-scale attacks could be mounted through:
- A "man in the middle" attack. Requires issuing a valid duplicate SSL certificate in combination with DNS forging and/or attacks on our BGP routes (a DigiNotar-style scenario).
- Gaining access to the webservers hosting https://mega.co.nz/index.html and replacing that file with a forged version (this would not affect access through the installed app base). Note that manipulating content on our distributed static content CDN does not pose a security risk, as all active content loaded from index.html is subject to verification with a cryptographic hash (think of it as some kind of "secure boot" for websites). This type of attack requires sending malicious code to the client and is therefore detectable.
- Gaining access to our core server infrastructure and creating forged key requests on existing shares. This type of attack only affects data in shared folders and is detectable on the client side as well.
What if I don't trust you? Is it still safe for me to use MEGA?
If you don't trust us, you cannot run any code provided by us, so opening our site in your browser and entering your password is off limits. If you still want to use MEGA, you have to do so through a client app that was written by someone you trust.
Doesn't that look pretty reasonable? What more do you want them to do? They created a pretty impressive webclient-driven easy-to-use file locker system, and they clearly spell out the problems with that approach.
Many of the article's points are pretty moot, btw. It does not use JS random function, they have extra verification for the 1024 bit SSL encrypted data, and the deduplication only works for shared files ("copy to my locker" functionality is mentioned - same data, same key, same place on the storage servers).
The part about mega.co.nz being able to send malicious code stealing your password is explicitly mentioned in their FAQ, and in a better way too. They even cover other attack vectors the article didn't.
They made a decent system, and they're upfront and honest about it's limitations. The article is at best FUD.
Dedupe update:
"Deduplication is done based on the entire encrypted file and only happens if you either upload the same file encrypted with the same key twice (unlikely) or if you copy or import an existing file in your file manager (more likely)."
I was saying something about wild assumptions... Yep..
ALL of it is nitpicking, or just plain out wrong.
Lemme see, SSL part. Well, main site use 2048 bits, and the JS on that page loads and verifies all other resources. And file upload / downloads are already encrypted before SSL even touches them. So that point is completely moot.
And the "Mega server could send bad code" is already covered in Mega's own FAQ - well,duh. I doubt it comes as a shock to anyone.
As for the deduplication, I don't know. But there are ways to do that (like using file content hash as encryption key, for example - no idea if they actually do this - or just try to dedup the actual encrypted content. There is a (well, small) chance that two encrypted files have same data in a block). We just don't know, and making wild assumptions from it is .. just wrong.
Also, Mega does in fact NOT use JS random function. It use time sampling from user generated events, with RC4 as mixing function.
The whole article is just stupid. It makes wild assumptions, doesn't understand how (parts of) the site works, repeat things the site already informs users about, and are just plain wrong on some parts.
Is this yet another troll article by some attention hungry ad pushers?
Update : Regarding the random source, this is the code they use, and it's from this project. It use mouse and keyboard events (not all, math.random is used to decide which ones), with rc4 as mixing function.
And it seems to be running since page load (started in crypto0001,js) - AES function is from Stanford Javascript Crypto Library btw, and RSA code is from this project.
I wrote a comment about the crypto system yesterday, from a outsider amateur's point of view. Nothing in that article was even surprising.
It's actually pretty cool, they do point out more or less the exact things in their FAQ, which is surprisingly honest for such a site. Most would try to handwave it away or just outright ignore it.
As extra info to that comment I wrote earlier, I confirmed that they save a version of the RSA key on their server, and during login a blob of data is sent in (login user in cleartext, and probably hashed / crypted pw) to check if its a valid user before handling out the RSA key.
I can imagine sharing works like this : 1. find friend, 2. get pub key for friend, 3. decode file key with my private key, 4. encrypt it with friend's public key, 5. send to server
And sharing folders .. I guess each folder have an encrypted list of keys to files in it, and the key for the folder is encrypted with your key. So sharing a folder would then work much the same as sharing a file.
And regarding deduplication I saw an idea in a comment that could explain that. Every file is hashed locally, the hash being the actual AES key. Encrypt file, use pub RSA to encrypt hash, send both to server. Same file will be same file, dedup works, and everyone got their own key to it. That would also allow them to nuke all uploads of an illegal file, and keep "bad file" hash lists for child porn and similar.
Now, I haven't actually looked at the JS code for the service yet, so all of this guesstimate :)
Let us count:
Click create account, write info That's one. Then you get email, and click the link in the email. Then you get a page asking for password, again. That's two.
One and one makes two. We on same page?
well, technically, they only have to break your hashed password (probably easiest attack vector). Then they can decrypt your private key, and then they have full access to all your files.
However, Mega should be able to identify files stored on their server if they have access to the original files. Consider if a Mega has access to a file called 'The_HoBBiT_Crazy_Delta_XxXDVDRip_firsTPost.avi' (e.g. they were provided the file by some company who wanted to check for compliance with licensing). They use the Mega client system to encrypt that file, producing an encrypted file and a file decryption key. They then check to see if any files on the server have an exact match to that encrypted file (e.g. first by hash, then by comparing length, then by an exact comparison of the encrypted bytes). It would then be possible to delete the file, check to see who has uploaded this particular file, and produce a list of people who also have access to that file.
So you're saying that every file is encrypted with the same key? Err no. What they could do would be to hash the file before upload, in the browser, and then send that hash in addition to the encrypted file (and encrypted key).
As far as I can tell, they're encrypting each file with an unique random key in the browser before uploading, using AES-128. I know they put an RSA key in local storage, so I guess that is then used to encrypt the key for the file and then the encrypted key and the file is uploaded.. And according to them, the RSA key is encrypted by your user password. Still not sure if the encrypted rsa is stored on the server or just client, but it would be pretty useless if you always had to use the same browser, and if local storage gets wiped in any way that would also kill all your files, so.. Probably stored on server.
So that means:
Login password used to decrypt RSA key, which is then used to encrypt random 128bit data (for AES128 of new files), and decrypt relevant encrypted strings for downloading files.
I do know that the download shortcuts created have both file ID and a key attached after the # sign (meaning the server never sees it, only the client-running javascript).
So far, so good -- theoretically. As long as you trust them it's pretty solid, but it's fairly easy to include a small js snippet that would send the password you type into your browser to some server. Possibly their own, possibly encrypted (they already have full crypto running in browser, and there's a lot of background talk to and from server). If LEA really really wanted, they could force Mega to serve special JS to a suspected client that sent the user PW back to them, or just the entire decrypted RSA key.
So, while pretty safe (and as safe as you can make it in pure HTML5 / JS I think), and with their whole business riding on them not knowing what you're doing, I think we're decently protected from "for teh lulz" random grabs of passwords.. But to be truly secure, you'll need trusted code running on your local machine.. As they actually point out in their FAQ :)
I discovered the same password problem today, so you're not the only one. Pretty sure I did write the correct password though.
So there might be that some/several accounts got corrupted somehow, and are thus dead. Noticed the same problem you had, no way to reset or delete the account, so I had to use another of my ~30 standard emails... But yeah, looks like a real problem.
I use Intel's SRT and you know, it actually works pretty darn well.
VM's feel snappy, games load really fast, even steam itself doesn't act like it's running on a 386.
It's not always perfect, for example after downloading and installing a few new games on Steam (amounting to ~30gb being shuffled into it) GW2 was noticeably slower to launch.. For about the first two times. After that, smooth sailing. And after seeing it load on a friend's system with only spinning disk, it was still loads better even with the cache halfway decimated.
Got 20gb of my SSD configured for caching a 1tb slowpoke disk, and the rest of the 120gb set off to windows. Worked perfectly so far.
While they don't have ads, they often have huge "Give us money!!" banners, which are just as annoying, if not more annoying than normal ads.
Irony: What if his son is hardcore PvP'er and relish the new challenge? Or just curbstomps the assassins.
A friend of mine had an alarm clock for when he should go to bed. When forgetting to set that, he sat playing all night and got interrupted by the normal alarm clock instead, telling him it was time to go to school.
And yes, this was Starcraft, too.
* Windows 8 isn't that bad.
* Apple Maps isn't that bad.
* The iPhone 4 antenna was not that bad.
* That terrible patent you just heard about isn't that bad.
* The internet always lies to you.
* You read that list on the internet.
Where ever they get the idea that 'it just works' is quite beyond me.
Lots and lots of PR money. And IMHO a brilliant move. You see, computers are hard. Everyone knows computers are hard. And if something happens, you can't do anything, because everyone knows computers are hard.
But then comes something different. Something that is EASY. They say it everywhere. It just works, and is easy to use! So when something happens, it can't be that difficult to get it working, surely? This is after all easy.
The difference it makes is that in first scenario people give up at once, without even trying. In the second, they try their best because it's after all supposed to be easy.
And it turns out, that when you actually try to solve the problem, then it actually is easy to get it working again (compared to giving up at once and not even trying, at least).
It just works, and is easy because they tell people it is so. Pure genius :)
The thing is, the same problem will manifest any place you have a large energy potential. Just look at, say, simple and friendly water.
The thing is, you're not selling a product, you're selling an idea. An idea entombed in a product, but still an idea.
If someone made a chair, it's a definite product. I can touch it, sit in it, and sell it. If someone wants a chair like that, they can
1. buy the chair from me, at which point I'd have to make a new chair to be able to sell to a new customer. or
2. copy it, make a replica of it. With enough time, materials, equipment and skill, it can be done. They get their chair, and I still have mine to sit in and sell. They can also
3. Steal my chair, in which case they have a chair, and I have none. The time and materials I invested in it is gone. I'd have to make a new one from scratch.
The problem with an idea is that, at the core of it, it's just data. And computers are truly excellent at working with data. So with option 2 above skill, time and materials mostly disappear. The only thing left is equipment, and almost everyone got a computer. It's still not stealing, but it can be a devaluation of the product you are selling (I say can be, because there are cases where product value have increased as a result of rampart copying. Adobe products, Microsoft products and this story are examples of this).
If someone said "I've now made this chair, and shall now get paid for everyone sitting in it, until I've been dead for 75 years!" people would think it nuts. If however, he was offering a service (a place to rest, which included a chair) then it would be different, but just the chair, wherever it happens to end up? Hardly. Yet, "I've now written this book, and shall now get paid for everyone reading it, until I've been dead for 75 years!" is perfectly acceptable. Now, think a bit before you say something. The book is sold as a product. Yet, unlike other products, when bought it's not ours. I'm not free to for example publish pictures of it. I can't improve it and sell the better version (AFAIK). It is sold as a product, yet it is not. This is, I think, one of the core problems with copyright as it is now. Intellectual property (*cough*) is cherry-picking advantages both from the product side of things, and the service side of things, and it has allowed itself to grow too big. Into a completely new thing, which the world is still struggling to get a grip on. And thus you see where some of the completely crazy stuff happening are coming from.
All this goes double and triple when applied to music and software. And I'm producing software myself, so I see your point. I'm not saying copyright needs to go, I'm saying copyright in this age is something new and unbalanced. Before copyright, people lived by performing their ideas, whereas they were stories or music. They created books containing their ideas, before mass production was possible. Now, any idea can be replicated across the entire globe in a matter of hours, by more or less anyone, at little or no cost. And people expect to live off their (or someone else's idea) idea for the rest of their life - and then some. The times ahead will be .. interesting.
Why do people complain when the government limits the choice of Internet providers, but the pirates removing my ability to choose my own business model is somehow a good thing?
You forget that you're not free to choose just any business model. I'd like a business model where everyone owning a computer paid me $1 per year as license to my software, but I doubt that would fly (hell, I'd even stretch to $.5). Here it is not the government or the fat cats restricting your business model, but your customers. These who are copying your books are people who actually want to read your story. They are your target, your potential client. They have a different view of how to get your books than you have. Think why, and think if there's any way to move closer to wha