If you think MS does not have to justify their use of a deprecated behaviour, fine. I guess this loss of connectivity is correct result then. They're both standard compliant, isn't that great? Good luck embracing and extending, but remember that vista isn't that popular yet.
I'm tired of feeding a troll.
PS: when dealing with dhcp, one does not assume anything, one reads rfc-951, rfc-2131 and its revisions and updates.
Then again, Vista does not agree with the "conservative with what you send" principle, considering they are using a flag they do not need to use to operate correctly and in fact is deprecated and should only be used in legacy clients.
Both vista and dhcpd would adhere to the standard if they can provide an explanation of their respective behaviours. However there appears to be no possible justification for MS' actions, while the dhcpd behaviour could be attributed to dropped support for now obsolete legacy clients (which must have been almost unneeded until vista appeared). Instead of bashing on dhcpd why don't you provide the necessary explanation that would make vista compliant?
Also, the standard declares that the correct solution is to modify clients in order to follow what is considered the correct behaviour (not to require broadcast answers). So, in this particular case, the burden's on the client, not the server.
See the DISCUSSION subitem in the quote I sent in my earlier post to see why dhcpd should not accept vista's requests.
Basically the whole thing is a small fuckup by dhcpd and a fucking huge one by vista (or plain malice, as I suspect).
No, they don't. Their non compliance is not due to technical factors, though.
From rfc-1542 that regulates the use of the broadcast flag:
3.1.1 The BROADCAST flag
Normally, BOOTP servers and relay agents attempt to deliver BOOTREPLY
messages directly to a client using unicast delivery. The IP
destination address (in the IP header) is set to the BOOTP 'yiaddr'
address and the link-layer destination address is set to the BOOTP
'chaddr' address. Unfortunately, some client implementations are
unable to receive such unicast IP datagrams until they know their own
IP address (thus we have a "chicken and egg" issue). Often, however,
they can receive broadcast IP datagrams (those with a valid IP
broadcast address as the IP destination and the link-layer broadcast
address as the link-layer destination).
If a client falls into this category, it SHOULD set (to 1) the
newly-defined BROADCAST flag in the 'flags' field of BOOTREPLY
messages it generates. This will provide a hint to BOOTP servers and
relay agents that they should attempt to broadcast their BOOTREPLY
messages to the client.
If a client does not have this limitation (i.e., it is perfectly able
to receive unicast BOOTREPLY messages), it SHOULD NOT set the
BROADCAST flag (i.e., it SHOULD clear the BROADCAST flag to 0).
DISCUSSION:
This addition to the protocol is a workaround for old host
implementations. Such implementations SHOULD be modified so
that they may receive unicast BOOTREPLY messages, thus making
use of this workaround unnecessary. In general, the use of
this mechanism is discouraged.
And from the same rfc, a section that defines certain terms, including SHOULD (also later defined in rfc-2119)
o "SHOULD"
This word or the adjective "RECOMMENDED" means that there
may exist valid reasons in particular circumstances to
ignore this item, but the full implications should be
understood and the case carefully weighed before choosing a
different course.
These two documents show that although the use of the BROADCAST flag is standard compliant (and we could argue that the DHCP server involved SHOULD try to answer them), the implementation of a modern DHCP client on a system capable of receiving unicast responses using the BROADCAST flag is not (at least without a very good reason to do so).
Considering that Microsoft has already made DHCP software capable of receiving unicast DHCP requests, and seeing that the fix proposed by Microsoft themselves is a simple change in a registry entry (meaning the software is in fact capable of receiving unicast responses), I'd say the software is not compliant.
I consider that behavior non compliant unless Microsoft had a very good explanation (the possibility of Vista running on a pc not capable of receiving unicast responses not a good one, since the flag should have been set the other way). It is at the very least gross imcompetence, if not outright malicious behaviour.
It appears that the list was compiled by searching out every single file that contained the word "Asimov" or "Silverberg" and assuming that these files necessarily infringed on Silverberg and Asimov's copyrights.
(...)
Even a naive user should know better -- and SFWA Vice President Andrew Burt (who got his position through an uncontested ballot) is a computer scientist and programmer with experience in this field.
Even though we've all seen these kind of programs a few times, I think it is a disgrace that a computer scientist could do something as unprofessional as using a simple substring match against two names in order to determine if a text is under copyright. Not only Mr. Burt should have known better, but he is also sending the message that his education in CS must have been useless, since he chose to ignore it completely. It might have been understandable for someone not formally trained to develop and/or deploy such a poorly designed system, but it is something unacceptable coming from a computer scientist.
With stunts like this one, it is no wonder that disciplines like software engineering are in the sorry state they currently are, with no chance of becoming a real engineering in the near future.
This thing pisses me off, not only because it's an abuse of the law and an insult to authors like Cory Doctorow, but because it's an insult to people (like me) who make an effort to do a good job in a computer related career only to find ten persons doing crap like this for every decent one.
It seems that NASA is implementing PIV-II. Those smart cards mentioned in TFA look like those mentioned in the FIPS-201 standard.
Basically, everyone getting a PIV card has to pass a background check. However, it seems that asking those scientists and engineers about all that data mentioned in TFA is a bit excessive. The standard has an informational appendix (appendix C) that specifies what sort of checks should be done. It even specifies two levels of checks for different security levels. Looks like someone got a little bit too anal when deciding what checks to do. The checks mentioned in FIPS-201 seem reasonable, though. Can anyone that knows about background checks explain what they are exactly?
The cards themselves seem pretty good. It is pretty clear that the designers of FIPS-201 cards do not trust the wireless interface, making all biometric/sensitive information available only on the wired interface, unlike those e-passports every government is promoting. Pretty interesting reading material.
You are not considering that PEX and DHT were both extensions of the protocol at that time, and it is possible to communicate with non-capable clients with no problems.
If the new bittorrent protocol is not compatible with the old one, people will probably stick with whatever works (meaning the old protocol, since most pirate BT trackers probably won't be switching).
If they add an extension, most clients not willing to license the SDK will probably ignore it, especially if it's not beneficial (imagine mainline clients doing DRM and everyone else not caring at all).
The only possible leverage they could get would be if they managed to invent something beneficial that cannot be copied. If it can be copied, unlicensed programmers will probably get together to make their own version (like they did with PE).
You should also remember the ruckus the announcement of the uTorrent purchase caused. What the uTorrent community feared seems to be happening right now, and they'll probably leave, or keep using older versions of uTorrent instead of upgrading (meaning more power to the old BT side). I know several people that kept copies of uTorrent 1.61 precisely for that reason.
In the end, if they try altering the protocol (tracker or P2P part) they will probably find themselves banned. The most important players in the BT field are the pirates (try convincing TPB to switch) and open source distributors (Debian won't touch that new licensing with a ten metre stick).
The only niche they might take is software upgrade for commercial applications. And unless they play their cards very well, it will only end in a bunch of fragmented networks. And if someone sends a copy of the old BT to the IETF or W3C (as some people said in this thread), it might be game over.
No it's not. To make a OTP you need a truly random pad, and you must use it only once.
A property of the OTP is that every possible plaintext has exactly the same probability of being the decryption of your ciphertext. That requires a random pad.
Your system is not a OTP simply because I can bruteforce your system by trying every jpeg image of a mountain. That property proves your system is not an OTP.
In fact, you could have used the output of a cryptographically secure pseudo random number generator and it would have not been a one time pad.
All of this even without considering what happens when you have more data bits to encrypt than pad bits, I bet you just repeat the pad, a big NO-NO when doing OTP. If that's the case, it would just be a vernam cipher.
Notwithstanding the fact that you would need a quantum source for a truly random pad
And that's precisely why almost nobody uses a OTP these days. Anyway, you could build your own source if you really wanted.
Why make your own cipher when AES is secure, fast and readily available anyway? Better use a reasonably secure algorithm than deceive yourself into thinking that you are using the best one (in theory).
This looks a lot like the space activity suit from the sixties. In fact, there's an edit in the wikipedia entry from january 2005 noting that the MIT is doing research that would lead to the suit we are seeing today.
Check the papers at the end of the wikipedia article, too.
Given that fact I will support any defensive efforts my Government makes to negate any Iranian missile threat aimed at the United States. And while I do not like a lot of things about Israel I would want to see us defend them against Iranian aggression.
In nuclear war, things are not as they seem to be. Those defensive missiles could be considered offensive weapons.
Suppose you deploy a missile defense system that can be used against Russia/Iran/Whoever. Although it seems a defensive action, it can be considered offensive, because after the system is installed, the USA can attack that country without fear of being nuked in response.
That's exactly the reason everyone starts getting itchy when someone mentions SDI or ABM. The nuclear deterrent is only effective if launching means suicide. If that was not the case, then the country with a "missile shield" would be better off launching a first strike.
Knowing that, you now know why Russia is angry. Either they think the system can be used against them, or they think it can be used against Iran, and Russia does not want the USA to invade Iran.
The only reason the USA could justify an ABM system pointed at Iran would be the Iranian leaders being insane (as in willing to launch a first strike). Keep in mind that North Korea is still sane under this assumption (talk as much as you like but don't launch). As the Iranian leaders seem to be, too.
These products are pure genius. Personally, I think the SD standard should be updated to increase supported capacity, so we can use a ubiquitous form factor long into the future. I don't know about the rest of you, but I have these worthless PCMCIA memory cards lying around, which I replaced with now worthless CF memory cards, which I've now replaced with SD. I don't want another change, and we don't need anything smaller than Micro-SD. So only bandwidth and capacity need to increase, which the SD standard can be modified to support (while maintaining backwards compatibility) as the technology improves.
According to TFA, this new card is an update to the Multimedia Card, the type of card the SD derives from. So, this move looks pretty much like what you're asking for.
The new readers should be able to read your old SD cards too (even if they have to use a legacy compatibility mode).
I would ditch the USB part, though. MMC (or SD) readers for USB are cheap and common, and adding the USB interface might make the card more fragile.
A software player, when compromised, simply gets a "security upgrade" and that's it. With the current quality of software, nobody would complain if their viewer "broke", provided it gets "fixed" with a simple update. Software breaks, shit happens, or at least that's what Joe Windows think.
With a hardware player matters are very different, something that Joe Windows might accept as natural on windows vista, he will not tolerate on his standalone player, and the impact will be harder to correct. The hardware player cannot easily get an upgrade, since it probably does not have a connection to the Internet. If a hardware player gets compromised, AACSLA has a tough choice: either keep the hole open and let everyone copy anything they want or close the hole and piss lots of users that have paid for a player and expect it to work, with no reason to "break".
Imagine if Sony facing a tough choice like that, it could either mean a big ass lawsuit from the customers if they close the hole, or a permanent crack if they don't. And saying it was AACSLA the entity that revoked the key will not help. For the regular Joe, "his Sony Blueray thingy broke, it sucks and wants his money back". They will certainly try to influence AACSLA in order to avoid that situation. Wouldn't you laugh too?
Windows WAS horrible, but face it.. right now, it's not THAT bad.
No doubt about that. I'd say that the main cause of problems in windows is the human factor. Mostly two things:
1.Microsoft adding unnecesary crap and making exceptions for themselves: things like IE running as privileged accounts and crap like activex and most of those stupid services that can be called from the most absurd APIs.
2.People using the administrator account and developers demanding administrator access for the most stupid reasons (like being lazy). Lots of programs require admin, either because they dump crap in system areas of because of copy protection. If a unix developer demanded root access for his/her program, he/she would be bitchslapped until he/she withdrew the request. Yet in windows it is considered normal. Maybe UAC will do something about this.
If both these points were taken seriously, windows security would be pretty decent. On the other hand, there would be no such thing like copy protection (like starforce, that concept is really alien in the unix world).
I don't know what made you think this thread was about taking control of the whole system or not, it was pretty much about OS design until you talked, but anyway......
Not allowing a malware to take control of the system is a crucial step in (at least) eliminating it. Without root privileges a malware could be able to wreck your home directory, but doing that would reveal its presence immediately, and without privileges it would be an easy prey for an alarmed superuser.
Consider that most malware DOES NOT do that, but really try to take control of the machine in order to make a botnet or similar nastyness. In that case, without root privileges it cannot hide itself effectively from the superuser, or even from the user itself (since the OS restricts the malware). That would make it a relatively easy target that can be found and destroyed at the first sign of trouble (or even during a routine inspection).
1. Rot-13 is an encryption device, assuming your comment is correct. 2. ROT-13 is a simple substitution cypher. Decryption is defined as subtracting 13 characters, wrapping at A, where ROT13 encryption is defined as adding 13 characters, wrapping at Z. 3. By extension, any substitution cypher is a DMCA-approved cypher.
The fact that a member of a class has a certain property (ROT-13 being a DMCA approved encryption device) does not mean that all the members of that class have the same property. I am a member of the animals' group, I can use a computer therefore all animals can use a computer..... I don't think so.
Nobody said that ROT-14 would be considered an encryption device by the DMCA.
Your best chance to prove ROT-26 is a DMCA approved encryption method would be to read the legalese and find the definition of "encrpytion" in the text and hope it is not a very good definition. Something like "a function INTENDED to prevent observation by an untrusted party" would be enough, especially if they do not mention keys. In that case, it doesn't have to work successfully to be an "encryption device".
If that is the case, I propose the identity function as the new DRM standard.
C0 88 56 63 C5 56 41 D8 5B E3 74 9D 02 11 F9 09 to everyone, and remember, Intel CPUs are little endian!
More like they paid for the information not to be distributed. The same information can be sold many times, it's not something that can be out of stock. There is always the chance of someone having the information and not wanting an "exclusive deal" with the US intelligence community.
The USA is the world's most progressive nation, in the sense that it is the first and best democracy...
Another poster addressed the "first" issue. I'm going to argue about the "best".
In what way is the US the "best" democracy? As I see it, you just have two political parties in practice, and they make sure the situation remains like that. Those two parties are almost the same.
Here in Argentina, we cover pretty much anything from left to right, in Spain it is pretty much the same, and governments regularily go from left to right and viceversa. In the US you've got right and extreme right, and frankly, it is getting harder to see the difference.
Your system is designed to make sure the minorities have no say in the government. At least in Argentina we have a couple of deputies for the minorities, and that sparks some debate in the house, so you can see how important it is for them to be there.
You have a government that spies on their own and sends people to Guantanamo prison without trial and just because they claim they're "terrorists", for fuck's sake!
I'd say the US is not the "best democracy", but something pretending to be that (and not doing a very good job).
Microsoft Research: The place where computer scientists produce cool ideas (and a stupid one that leaves you with 1/2 monitor as a console substitute) and innovations that never get into Microsoft products.
Let's see what happened after Napster, oh yeah music stopped being shared.
Except on Gnutella.
And Grokster. And Kazaa. And Edonkey, and Limewire, and Bearshare.
In fact, with bittorrent the whack-a-mole got even more interesting. Before BT, the MAFIAA would go against the whole networks, but in the case of bittorrent, they cannot do the same because it is used both for legal and illegal distribution. Anyone willing to set up a search site and tracker can participate in the whack-a-mole, instead of having to make a new network. Bittorrent is here to stay.
We can all thanks Bram Cohen for that. That deal he made with the MPAA has sealed bittorrent's fate, hahaha!
It seems that the discussion poster is mixing a few things. Being a CA is a full time job, not just the role of a program. Signing certificates and such is the easy part, the hard part is verifying the identity of the people asking for the certificates. Open source or close source is really an insignificant part, considering all CAs use open protocols.
If you wanted to get certificates for open source programs, it is very possible that the process would not be free (as in beer), or the process would not be trustworthy (because money is needed to make the investigation, possibly a global one). That does not mean that you should pay USD1000 for a thawte cert (that's armed robbery). But it means that an "Open source CA" is out of the question, unless someone with resources (EFF, FSF) steps in and does it.
The open source model is more adapted to a chain of trust organization. If I know someone I would certainly certify his identity, but if I did for any stranger, I would probably do a crappy job. Same applies with everyone else in the open source world.
Slashdot Mirror
They'll bully prq.se, the ISP owned by the TPB crew, you say?
Something tells me it's already been done, without much success.
Well, whatever.
If you think MS does not have to justify their use of a deprecated behaviour, fine. I guess this loss of connectivity is correct result then. They're both standard compliant, isn't that great? Good luck embracing and extending, but remember that vista isn't that popular yet.
I'm tired of feeding a troll.
PS: when dealing with dhcp, one does not assume anything, one reads rfc-951, rfc-2131 and its revisions and updates.
Then again, Vista does not agree with the "conservative with what you send" principle, considering they are using a flag they do not need to use to operate correctly and in fact is deprecated and should only be used in legacy clients.
Both vista and dhcpd would adhere to the standard if they can provide an explanation of their respective behaviours. However there appears to be no possible justification for MS' actions, while the dhcpd behaviour could be attributed to dropped support for now obsolete legacy clients (which must have been almost unneeded until vista appeared). Instead of bashing on dhcpd why don't you provide the necessary explanation that would make vista compliant?
Also, the standard declares that the correct solution is to modify clients in order to follow what is considered the correct behaviour (not to require broadcast answers). So, in this particular case, the burden's on the client, not the server.
See the DISCUSSION subitem in the quote I sent in my earlier post to see why dhcpd should not accept vista's requests.
Basically the whole thing is a small fuckup by dhcpd and a fucking huge one by vista (or plain malice, as I suspect).
From rfc-1542 that regulates the use of the broadcast flag:
And from the same rfc, a section that defines certain terms, including SHOULD
(also later defined in rfc-2119)
These two documents show that although the use of the BROADCAST flag is standard compliant (and we could argue that the DHCP server involved SHOULD try to answer them), the implementation of a modern DHCP client on a system capable of receiving unicast responses using the BROADCAST flag is not (at least without a very good reason to do so).
Considering that Microsoft has already made DHCP software capable of receiving unicast DHCP requests, and seeing that the fix proposed by Microsoft themselves is a simple change in a registry entry (meaning the software is in fact capable of receiving unicast responses), I'd say the software is not compliant.
I consider that behavior non compliant unless Microsoft had a very good explanation (the possibility of Vista running on a pc not capable of receiving unicast responses not a good one, since the flag should have been set the other way). It is at the very least gross imcompetence, if not outright malicious behaviour.
Even though we've all seen these kind of programs a few times, I think it is a disgrace that a computer scientist could do something as unprofessional as using a simple substring match against two names in order to determine if a text is under copyright. Not only Mr. Burt should have known better, but he is also sending the message that his education in CS must have been useless, since he chose to ignore it completely. It might have been understandable for someone not formally trained to develop and/or deploy such a poorly designed system, but it is something unacceptable coming from a computer scientist.
With stunts like this one, it is no wonder that disciplines like software engineering are in the sorry state they currently are, with no chance of becoming a real engineering in the near future.
This thing pisses me off, not only because it's an abuse of the law and an insult to authors like Cory Doctorow, but because it's an insult to people (like me) who make an effort to do a good job in a computer related career only to find ten persons doing crap like this for every decent one.
It seems that NASA is implementing PIV-II. Those smart cards mentioned in TFA look like those mentioned in the FIPS-201 standard.
Basically, everyone getting a PIV card has to pass a background check. However, it seems that asking those scientists and engineers about all that data mentioned in TFA is a bit excessive. The standard has an informational appendix (appendix C) that specifies what sort of checks should be done. It even specifies two levels of checks for different security levels. Looks like someone got a little bit too anal when deciding what checks to do. The checks mentioned in FIPS-201 seem reasonable, though. Can anyone that knows about background checks explain what they are exactly?
The cards themselves seem pretty good. It is pretty clear that the designers of FIPS-201 cards do not trust the wireless interface, making all biometric/sensitive information available only on the wired interface, unlike those e-passports every government is promoting. Pretty interesting reading material.
So, basically the GP poster was right: 1% goes to WGA.
You are not considering that PEX and DHT were both extensions of the protocol at that time, and it is possible to communicate with non-capable clients with no problems.
If the new bittorrent protocol is not compatible with the old one, people will probably stick with whatever works (meaning the old protocol, since most pirate BT trackers probably won't be switching).
If they add an extension, most clients not willing to license the SDK will probably ignore it, especially if it's not beneficial (imagine mainline clients doing DRM and everyone else not caring at all).
The only possible leverage they could get would be if they managed to invent something beneficial that cannot be copied. If it can be copied, unlicensed programmers will probably get together to make their own version (like they did with PE).
You should also remember the ruckus the announcement of the uTorrent purchase caused. What the uTorrent community feared seems to be happening right now, and they'll probably leave, or keep using older versions of uTorrent instead of upgrading (meaning more power to the old BT side). I know several people that kept copies of uTorrent 1.61 precisely for that reason.
In the end, if they try altering the protocol (tracker or P2P part) they will probably find themselves banned. The most important players in the BT field are the pirates (try convincing TPB to switch) and open source distributors (Debian won't touch that new licensing with a ten metre stick).
The only niche they might take is software upgrade for commercial applications. And unless they play their cards very well, it will only end in a bunch of fragmented networks. And if someone sends a copy of the old BT to the IETF or W3C (as some people said in this thread), it might be game over.
To make a OTP you need a truly random pad, and you must use it only once.
A property of the OTP is that every possible plaintext has exactly the same probability of being the decryption of your ciphertext. That requires a random pad.
Your system is not a OTP simply because I can bruteforce your system by trying every jpeg image of a mountain. That property proves your system is not an OTP.
In fact, you could have used the output of a cryptographically secure pseudo random number generator and it would have not been a one time pad.
All of this even without considering what happens when you have more data bits to encrypt than pad bits, I bet you just repeat the pad, a big NO-NO when doing OTP. If that's the case, it would just be a vernam cipher.
And that's precisely why almost nobody uses a OTP these days. Anyway, you could build your own source if you really wanted.
Why make your own cipher when AES is secure, fast and readily available anyway? Better use a reasonably secure algorithm than deceive yourself into thinking that you are using the best one (in theory).
This looks a lot like the space activity suit from the sixties. In fact, there's an edit in the wikipedia entry from january 2005 noting that the MIT is doing research that would lead to the suit we are seeing today.
Check the papers at the end of the wikipedia article, too.
Actually, there are a lot of them. The third counting upwards from the last one is definitely relevant, if adapted from word to powerpoint.
Well, not THAT tight.
That would be two real addresses and mailinator.
In nuclear war, things are not as they seem to be. Those defensive missiles could be considered offensive weapons.
Suppose you deploy a missile defense system that can be used against Russia/Iran/Whoever. Although it seems a defensive action, it can be considered offensive, because after the system is installed, the USA can attack that country without fear of being nuked in response.
That's exactly the reason everyone starts getting itchy when someone mentions SDI or ABM. The nuclear deterrent is only effective if launching means suicide. If that was not the case, then the country with a "missile shield" would be better off launching a first strike.
Knowing that, you now know why Russia is angry. Either they think the system can be used against them, or they think it can be used against Iran, and Russia does not want the USA to invade Iran.
The only reason the USA could justify an ABM system pointed at Iran would be the Iranian leaders being insane (as in willing to launch a first strike). Keep in mind that North Korea is still sane under this assumption (talk as much as you like but don't launch). As the Iranian leaders seem to be, too.
According to TFA, this new card is an update to the Multimedia Card, the type of card the SD derives from. So, this move looks pretty much like what you're asking for.
The new readers should be able to read your old SD cards too (even if they have to use a legacy compatibility mode).
I would ditch the USB part, though. MMC (or SD) readers for USB are cheap and common, and adding the USB interface might make the card more fragile.
A software player, when compromised, simply gets a "security upgrade" and that's it. With the current quality of software, nobody would complain if their viewer "broke", provided it gets "fixed" with a simple update. Software breaks, shit happens, or at least that's what Joe Windows think.
With a hardware player matters are very different, something that Joe Windows might accept as natural on windows vista, he will not tolerate on his standalone player, and the impact will be harder to correct. The hardware player cannot easily get an upgrade, since it probably does not have a connection to the Internet. If a hardware player gets compromised, AACSLA has a tough choice: either keep the hole open and let everyone copy anything they want or close the hole and piss lots of users that have paid for a player and expect it to work, with no reason to "break".
Imagine if Sony facing a tough choice like that, it could either mean a big ass lawsuit from the customers if they close the hole, or a permanent crack if they don't. And saying it was AACSLA the entity that revoked the key will not help. For the regular Joe, "his Sony Blueray thingy broke, it sucks and wants his money back". They will certainly try to influence AACSLA in order to avoid that situation. Wouldn't you laugh too?
You're not the first. Have you ever searched whois for "microsoft.com"?
No doubt about that. I'd say that the main cause of problems in windows is the human factor. Mostly two things:
1.Microsoft adding unnecesary crap and making exceptions for themselves: things like IE running as privileged accounts and crap like activex and most of those stupid services that can be called from the most absurd APIs.
2.People using the administrator account and developers demanding administrator access for the most stupid reasons (like being lazy). Lots of programs require admin, either because they dump crap in system areas of because of copy protection. If a unix developer demanded root access for his/her program, he/she would be bitchslapped until he/she withdrew the request. Yet in windows it is considered normal. Maybe UAC will do something about this.
If both these points were taken seriously, windows security would be pretty decent. On the other hand, there would be no such thing like copy protection (like starforce, that concept is really alien in the unix world).
I don't know what made you think this thread was about taking control of the whole system or not, it was pretty much about OS design until you talked, but anyway......
Not allowing a malware to take control of the system is a crucial step in (at least) eliminating it. Without root privileges a malware could be able to wreck your home directory, but doing that would reveal its presence immediately, and without privileges it would be an easy prey for an alarmed superuser.
Consider that most malware DOES NOT do that, but really try to take control of the machine in order to make a botnet or similar nastyness. In that case, without root privileges it cannot hide itself effectively from the superuser, or even from the user itself (since the OS restricts the malware). That would make it a relatively easy target that can be found and destroyed at the first sign of trouble (or even during a routine inspection).
Your logic is flawed.
The fact that a member of a class has a certain property (ROT-13 being a DMCA approved encryption device) does not mean that all the members of that class have the same property. I am a member of the animals' group, I can use a computer therefore all animals can use a computer..... I don't think so.
Nobody said that ROT-14 would be considered an encryption device by the DMCA.
Your best chance to prove ROT-26 is a DMCA approved encryption method would be to read the legalese and find the definition of "encrpytion" in the text and hope it is not a very good definition. Something like "a function INTENDED to prevent observation by an untrusted party" would be enough, especially if they do not mention keys. In that case, it doesn't have to work successfully to be an "encryption device".
If that is the case, I propose the identity function as the new DRM standard.
C0 88 56 63 C5 56 41 D8 5B E3 74 9D 02 11 F9 09 to everyone, and remember, Intel CPUs are little endian!
More like they paid for the information not to be distributed.
The same information can be sold many times, it's not something that can be out of stock.
There is always the chance of someone having the information and not wanting an "exclusive deal" with the US intelligence community.
Another poster addressed the "first" issue. I'm going to argue about the "best".
In what way is the US the "best" democracy?
As I see it, you just have two political parties in practice, and they make sure the situation remains like that. Those two parties are almost the same.
Here in Argentina, we cover pretty much anything from left to right, in Spain it is pretty much the same, and governments regularily go from left to right and viceversa. In the US you've got right and extreme right, and frankly, it is getting harder to see the difference.
Your system is designed to make sure the minorities have no say in the government. At least in Argentina we have a couple of deputies for the minorities, and that sparks some debate in the house, so you can see how important it is for them to be there.
You have a government that spies on their own and sends people to Guantanamo prison without trial and just because they claim they're "terrorists", for fuck's sake!
I'd say the US is not the "best democracy", but something pretending to be that (and not doing a very good job).
Microsoft Research: The place where computer scientists produce cool ideas (and a stupid one that leaves you with 1/2 monitor as a console substitute) and innovations that never get into Microsoft products.
There you go, I fixed it for you.
In fact, with bittorrent the whack-a-mole got even more interesting.
Before BT, the MAFIAA would go against the whole networks, but in the case of bittorrent, they cannot do the same because it is used both for legal and illegal distribution. Anyone willing to set up a search site and tracker can participate in the whack-a-mole, instead of having to make a new network. Bittorrent is here to stay.
We can all thanks Bram Cohen for that. That deal he made with the MPAA has sealed bittorrent's fate, hahaha!
It seems that the discussion poster is mixing a few things. Being a CA is a full time job, not just the role of a program. Signing certificates and such is the easy part, the hard part is verifying the identity of the people asking for the certificates. Open source or close source is really an insignificant part, considering all CAs use open protocols.
If you wanted to get certificates for open source programs, it is very possible that the process would not be free (as in beer), or the process would not be trustworthy (because money is needed to make the investigation, possibly a global one). That does not mean that you should pay USD1000 for a thawte cert (that's armed robbery). But it means that an "Open source CA" is out of the question, unless someone with resources (EFF, FSF) steps in and does it.
The open source model is more adapted to a chain of trust organization. If I know someone I would certainly certify his identity, but if I did for any stranger, I would probably do a crappy job. Same applies with everyone else in the open source world.