You make an excellent point. It is the predominant purpose that seems to affect the illegality of particular things. For example, weapons grade uranium is an illegal thing to possess, because it has few legitimate uses, iirc. The uses it does have are highly regulated and require substantial bureaucracy and traceability.
It is the same thing for a huge list of major chemicals. All industrial chemicals of potential misuse (including production of illicit drugs, a debatably harmful use, perhaps) are monitored by the FBI. If the FBI suspects illegitimate use of a thing, they often investigate.
I do not know the illegality of possession with intent to create something like a bomb or illicit drugs in the USA. It probably goes towards suspicion enough to warrant proper investigations. Nevertheless, there are some reverse onus crimes of possession of things, like uranium and illicit drugs themselves.
The Microsoft EULA was held as binding insofar as it stipulates that MS cannot be sued outside Washington state. A class action brought against MSN in Ontario, Canada was thrown out because it was necessary to sue, after agreeing to a click-through license stipulating jurisdiction. This was the first EULA case, I think, and it was upheld, for click-through licenses.
If the virus has a click-through EULA stipulating the consequences, then it would probably be a barrier to a successful lawsuit. A blanket waiver of liability would probably be insufficient (ie. author assumes no responsibility for damages), but a specific waiver (ie. author guarantees damages will result and user, by agreeing, accepts full liability for these damages) could potentially protect the author and associates.
If the user can avoid installing the virus by not accepting the agreement, then it becomes the users fault. This would spread liability from the author, presuming that the EULA is maintained, to all the accepting users, in theory. The validity of this license may be increased if the virus may have actual uses, such as in combination with other software, or it may be disabled.
The license can also probably include various 'do not reverse engineer' clauses.
X sues Y for copyright infringement, contributory negligence to X-Z, violation of license, etc. X sues Z for trade secrets, copyright infringement, etc. Y sues Z for trade secrets, copyright infringement, violation of license, etc. Feds indite Y for damages, if any result. X in negligence for creating a crappy software program similar to a virus (very, very weak; eg. Microsoft Outlook; CDC Backoriface). If anything arises regarding X's contributions to the virus, X sues in defamation.
Ugh. Quite right; that wasn't very well thought out. My original post, though sounding ok, is thoroughly incorrect and should be modded down.
Viruses are copyright their respective owners, automatically.
The only way one could be released without legal culpability to the author would be if it was stolen, I guess. Even then, the author, knowing potential consequences in damage flowing from its release, must show that s/he was not negligent in permitting its release, in addition to not having intended, nor been willfully blind to it. It may also be possible that it is necessary to justify its creation, in lieu of potential consequences.
The civil/criminal distinction is thin. In criminal court, you would be guilty only beyond reasonable doubt of innocence. In civil, it would probably be a balance of probabilities (ie. 50% of the jury). Accidental release may be covered under criminal (ie. gross?) negligence, if the damage, or potential damage of the virus, is high enough. Civil would most certainly have negligence as a cause of action.
It is possible that a virus, for example, designed to set off nuclear warheads through NORAD may induce criminal negligence for its mere creation, even absent any intention for use. Given the severe and precise consequences, the burden of proof would probably shift to the author to prove absence of intent. There is a grey area somewhere in the middle between intellectual/innocent virus creation & study, and precise malevolent virus creation, probably leading to the burden of proof shifting to the author to display a lack of intention.
Viruses are not copyright; if they were the author would be admitting to a felony, where 1. s/he cannot benefit, and 2. they cannot claim possession of something illegal, ala. controlled substances. Copyright is, in essence, a form of constructive possession. A virus is like child porn, in that sense. It's worse to claim you own it than to argue for your possessory rights.
FYI, if you're using Linux, you can just use software RAID. It's widely, albeit controversially, regarded as faster than hardware RAID, and is substantially more flexible.
You might've thought of that already, or not be able to use Linux, but nevertheless, thought I'd mention.
While the agreement - unlike the North American Free Trade Agreement - will not allow corporations to sue the government for breaches of the agreement
Incidentally, those actions, Chapter 11 breaches, arise to protect investors from expropriations. There are interesting cases where all 3 member states of NAFTA have opposed actions that nevertheless succeeded. It is, if I remember correctly, the first international treaty opening states up to rights of actions in arbitration by non-states.
My interpretation was that Valenti was miffed about how the out-sourced company came up with such a crappy system. There were many a million invested into this DVD protection scheme. To see a fellow write 6 lines of Perl to circumvent millions in copyright protection investment could well be 'un-fucking-believable' to the fellow vicariously footing the bill.
Kingston (where I am, too) has atrocious vagrancy problems, not totally unrelated to the centralization of federal prisons in the area, and lack of sustainable industry.
In the summer the tourist industry is focused around Princess and the downtown area, and I gather it's possible to do fairly well pan-handling, or playing music on the street. It is non-taxable income, so $5/hr is really equivalent to $8/hr working, and I'd think that'd be a low ballpark figure for the summer (albeit perhaps a bit high for winter).
#define EACH( I , C ) typeof((C).begin()) (I) = (C).begin();\
(I) != (C).end(); ++(I)
Nifty trick - it's dynamic, too, and works with non-STL containers (ie. pointers). It requires run-time type information, which slows (generally) everything down. Also, as a macro, it's not safe, and it may make copies (what if one of I or C is a function call? eg. EACH( I, some_foo()). Very bad! )
For just STL containers you could do something like:
template<typename iter, typename foo> void each(iter i, foo&f) { /* &f reference may not be 'good', but meh.
There are some const optimizations that you can make w/
partial specialization, but again, meh. You probably don't
want this.:)
*/
for (i = f.begin(); i < f.end(); ++i)
{ f(i); }/* functor */ }
Now you can see the obvious problem with this - it's very close to for_each, and yet very far from your for ( EACH(I,C) ) macro. What you probably really want are lambda functions, per the C++ BOOST library, where you can have lovely things (per their examples) likeso:
This is not a macro, so you don't lose the type safety, and it doesn't recreate (C) and (I) everytime they are called, and thinking ahead, doesn't store them in a temporary global variable so it's thread safe.
If you quit because you were doing something illegal in your job, you typically (but not always; it's state legislation) have whistleblower status. Sounds like he may have been racketeering.
Mind you, it isn't illegal to accuse people of doing something illegal or trespassing if you have suspicion that they indeed were. I'm really curious as to where the limits to the "use" of the law meet the "availability" of it.
When Big Business can win by costing too much to litigate against, you are deprived of the fundamental rule of law, by being unable to meet legal remedy.
Sorry; it didn't seem out of context to me. I took your whole comment to reflect on the holistic security of port-knocking, not just authentication.
No. Packets are packets, whether they're part of a connection or not. If you think portknocking is used, it's even easier to detect, because you can just throw out all the packets that are part of a connection (or query/response pairs from UDP protocols like DNS).
That's an O(n) problem for TCP; keeping track of connections requires a stack for every connection. On even a reasonably sized network: impossible. There are pseudo-connection stacks, but they are nevertheless O(n) and inherently incomplete.
There are packets that are 'impossible', but I don't remember what percentage of the flag-set they constitute, and you can look for them, but if it's being sniffed, you still need not know where it came from or what it is doing.
When you're sniffing you're anonymous by definition (unless your sniffing implementation gives you away to tools like anti-sniff). Not a feature of portknocking. And sniffing is relatively hard/risky.
Anonymous might not be the correct term - 'transparent' seems more appropriate. You do concur in the difficulty of sniffing, absent a span port on a router. If you control sophisticated routers, it is relatively easy, mind.
Port knocking is swell because it can totally disguise the fact that you're listening for incoming connections, and that's something ssh can't do.
And
Nothing other than coolness makes portknocking more secure than any other one-time-password scheme based on the same underlying password-generating technology (e.g. one-time-pad or a prng or whatever).
are in opposition, I think. The prior indicates a stenographic capacity: plausible deniability of even the existence of commands or access. Stenography, or on a policy level plausible deniability, is a form of security.
You are correct in asserting that a certain aspect of "security" is no greater, that being the actual breakability of the sequence down into its original command is no greater for knocking time-synchronized one-time pads than any other one-time pad. I would counter with the above, that "security" may include this plausibility deniability, which is enchanced over TCP/IP through this particular method, opposed to verifiable and traceable socket connections.
There are other values, as well. One is not requiring the establishment of a TCP connection itself, which presents the possiblity of untraceable packets, providing anonymity for the command sender. It also permits the listener to be anonymous if it is merely sniffing. (With the recent Cisco hacks, this is all the more deleterious) Thus there can be completely blind communication. Mind you, broadcasting TCP is tricky, often requiring "access" to a router, and the destination, or destination network is almost always visible, but the sender can certainly remain effectively anonymous.
The usable alphabet for a suicide TCP packet header is, I do believe, in bits: 16: dest. port 16: src port 32: seq id 6: flags 16: window 16: urgent 40: options That gives us an alphabet 2^142 ~= 5.6 * 10^42. Not to mention that a sequence of packets can be combined, extending the language. Indeed, its cardinality is a natural ordinal, so the same as any password, if not more, by virtue of passwords being limited by an input buffer.
Knocking need only finite state between packets, simply indicating a status of "last packet correct knock?"; successive knocking therein is in a cardinality greater than passwords. Knocking can happen over a period of months (as I have seen it), and be virtually undetectable for all but the most sophisticted (ie. expensive) means of detection.
In combination with a time-synchronized one-time pad, you can generate an unrepeatable, provably (in the mathematical sense) secure system of access or commands. For example, for the minute of 13:01 EST, there can be a specific TCP packet, or series of packets that unlocks the door or executes a command. At no other predictable time would this knock be useful. (Time synchronization here is an issue, but often this attack will be used on machines that do care about an atomic clock sync).
You can do the same thing with a password over SSH, but that's higher level, using more complex code, and inherently more likely to succumb to high-level assaults such as buffer overflows, as well as mathematical assaults on the encryption itself, both of which fundamentally compromise the system's security.
In short, time-synchronized knocking is safer, simpler, and smarter than passwords or encryption for a certain number of niche applications.
Why use port knocking. It is no more secure than plain-text passwords. Use authpf. authpf can be set as the shell so when a user logs in authpf just changes the firewall rules.
I'm not sure that authpf corresponds to port-knocking's subject-matter.
You can make port-knocking more "secure" than encryption; you can use a time-synchronized one-time pad to construct and vary the ports, flags, TCP options, sequence, etc., to come up with a system both unique and impossible to duplicate, absent the one-time pad.
As one-time pads are provably secure, you can create a system that bars or ignores all communication except the effectively random knock that unlocks the door.
This sort of clandestine type of communication has been known about in the security community for a long time - pretty much since the ARPA days. Some backdoors used specific sequences of TCP flags, with no practical TCP use other than opening a backdoor, but permitting anonymous communication or command broadcasting.
With access to a TCP stack and a link-layer sniffer, you can send and receive, respectively, commands to ghosts in working machines, transparent proxies or "harmony" devices. It is good to see this sort of thing coming to light, since it is extraordinarily powerful and not very well known.
An example of these probing commands are Xmas, Fin, and Null scans for Fyodor's nmap; note that other TCP flags (TCP options, in particular) can harbour substantially more information than the flags alone.
Unfortunately, in the modern age of macro viruses, it is hardly necessary to be skilled or even aware of such devices to write a devastatingly powerful virus.
There is a doctrine in law known as res ipsa loquitor, meaning "it flows from the facts", and permits construction of a "fact" where it is obvious from the context. It is essentially never sufficient for proof beyond a reasonable doubt to construct a fiction in fact or law that would make a criminal case.
Civil suits are a bit less stringent, typically having a lower burden of proof. Nevertheless it was up to the judge to say whether or not it was sufficient in this case to say "obviously" means "true and punishable".
There is a lot more case history on what inferences constitute various degrees of "proof", and modifying them has, in a common law system, drastic implications that transcend intellectual property law. It sets a precedent that has the potential to be abused in everything from insurance automobile cases through arson through sexual assault and murder. It is not a boundary lightly crossed.
I noted that all the recommended universities are in Ontario. Recently, most are suffering underfunding, unlike their Western counterparts.
I would strongly suggest investigating Western Canada for well funded engineering programs. The East coast universities are relatively poor, but are, typically, less ambitious and require less resources, and the cost of living is cheaper. And given the standard of engineering across Canada, your functionality is not detrimentally harmed by choosing any particular university, unless you have higher, post-graduate ambitions, IMHO.
IANAL, but I believe this comes from the quirk in Canadian law that you may make copies of something for yourself quite legally, just not for others. Since the people sharing aren't making the copies, it's legal.
I wouldn't call it a quirk. Every first world nation except the USA has the same provision and levy permitting non-infringement personal copying in the absence of permission.
Note however that Australia's Levy was struck down as unconstitutional in 1992/1993 though. That need not vitiate the non-infringement personal copying, however.
Well, had nuclear energy developed as expected, this would likely have been true. After all, 95% of the energy humanity produces in the western world is mobile, in vehicles, through the combustion of petroleum. Homes are piddly by comparison.
Everything mandrake does is gpl'd, so there's no reason that debian couldn't keep their crazy "hard" installer for traditionalists and setup the mandrake installer to install debian easy-like for newbies. why duplicate effort?
That would require porting the Mandrake installer to all the Debian ports. There are good x86 installers for Debian, from Progeny at least, but it, like Mandrake's, just isn't portable enough to be officially Debian.
Really, one person with the most potential, in my eyes, benefit from a good Linux platform is Sony. If the API for Linux were similar to the PS2/3, then 1. porting would be relatively cheap, 2. they get free consoles without the cost of manufacturing, and 3. they compete with Microsoft's model of doing exactly this with their Windows and Xbox API overlap.
Perhaps this applies equally well to Nintendo...;)
Slashdot Mirror
You make an excellent point. It is the predominant purpose that seems to affect the illegality of particular things. For example, weapons grade uranium is an illegal thing to possess, because it has few legitimate uses, iirc. The uses it does have are highly regulated and require substantial bureaucracy and traceability.
It is the same thing for a huge list of major chemicals. All industrial chemicals of potential misuse (including production of illicit drugs, a debatably harmful use, perhaps) are monitored by the FBI. If the FBI suspects illegitimate use of a thing, they often investigate.
I do not know the illegality of possession with intent to create something like a bomb or illicit drugs in the USA. It probably goes towards suspicion enough to warrant proper investigations. Nevertheless, there are some reverse onus crimes of possession of things, like uranium and illicit drugs themselves.
The Microsoft EULA was held as binding insofar as it stipulates that MS cannot be sued outside Washington state. A class action brought against MSN in Ontario, Canada was thrown out because it was necessary to sue, after agreeing to a click-through license stipulating jurisdiction. This was the first EULA case, I think, and it was upheld, for click-through licenses.
If the virus has a click-through EULA stipulating the consequences, then it would probably be a barrier to a successful lawsuit. A blanket waiver of liability would probably be insufficient (ie. author assumes no responsibility for damages), but a specific waiver (ie. author guarantees damages will result and user, by agreeing, accepts full liability for these damages) could potentially protect the author and associates.
If the user can avoid installing the virus by not accepting the agreement, then it becomes the users fault. This would spread liability from the author, presuming that the EULA is maintained, to all the accepting users, in theory. The validity of this license may be increased if the virus may have actual uses, such as in combination with other software, or it may be disabled.
The license can also probably include various 'do not reverse engineer' clauses.
Hrmm.
X sues Y for copyright infringement, contributory negligence to X-Z, violation of license, etc.
X sues Z for trade secrets, copyright infringement, etc.
Y sues Z for trade secrets, copyright infringement, violation of license, etc.
Feds indite Y for damages, if any result. X in negligence for creating a crappy software program similar to a virus (very, very weak; eg. Microsoft Outlook; CDC Backoriface).
If anything arises regarding X's contributions to the virus, X sues in defamation.
That could cover a bunch of it.
Who wins? Who knows.
Who benefits? The lawyers.
Ugh. Quite right; that wasn't very well thought out. My original post, though sounding ok, is thoroughly incorrect and should be modded down.
Viruses are copyright their respective owners, automatically.
The only way one could be released without legal culpability to the author would be if it was stolen, I guess. Even then, the author, knowing potential consequences in damage flowing from its release, must show that s/he was not negligent in permitting its release, in addition to not having intended, nor been willfully blind to it. It may also be possible that it is necessary to justify its creation, in lieu of potential consequences.
The civil/criminal distinction is thin. In criminal court, you would be guilty only beyond reasonable doubt of innocence. In civil, it would probably be a balance of probabilities (ie. 50% of the jury). Accidental release may be covered under criminal (ie. gross?) negligence, if the damage, or potential damage of the virus, is high enough. Civil would most certainly have negligence as a cause of action.
It is possible that a virus, for example, designed to set off nuclear warheads through NORAD may induce criminal negligence for its mere creation, even absent any intention for use. Given the severe and precise consequences, the burden of proof would probably shift to the author to prove absence of intent. There is a grey area somewhere in the middle between intellectual/innocent virus creation & study, and precise malevolent virus creation, probably leading to the burden of proof shifting to the author to display a lack of intention.
Apologies for the inaccurate post.
Viruses are not copyright; if they were the author would be admitting to a felony, where 1. s/he cannot benefit, and 2. they cannot claim possession of something illegal, ala. controlled substances. Copyright is, in essence, a form of constructive possession. A virus is like child porn, in that sense. It's worse to claim you own it than to argue for your possessory rights.
:)
Hope that makes sense.
FYI, if you're using Linux, you can just use software RAID. It's widely, albeit controversially, regarded as faster than hardware RAID, and is substantially more flexible.
You might've thought of that already, or not be able to use Linux, but nevertheless, thought I'd mention.
Cheers
While the agreement - unlike the North American Free Trade Agreement - will not allow corporations to sue the government for breaches of the agreement
Incidentally, those actions, Chapter 11 breaches, arise to protect investors from expropriations. There are interesting cases where all 3 member states of NAFTA have opposed actions that nevertheless succeeded. It is, if I remember correctly, the first international treaty opening states up to rights of actions in arbitration by non-states.
My interpretation was that Valenti was miffed about how the out-sourced company came up with such a crappy system. There were many a million invested into this DVD protection scheme. To see a fellow write 6 lines of Perl to circumvent millions in copyright protection investment could well be 'un-fucking-believable' to the fellow vicariously footing the bill.
Kingston (where I am, too) has atrocious vagrancy problems, not totally unrelated to the centralization of federal prisons in the area, and lack of sustainable industry.
In the summer the tourist industry is focused around Princess and the downtown area, and I gather it's possible to do fairly well pan-handling, or playing music on the street. It is non-taxable income, so $5/hr is really equivalent to $8/hr working, and I'd think that'd be a low ballpark figure for the summer (albeit perhaps a bit high for winter).
(I) != (C).end(); ++(I)
Nifty trick - it's dynamic, too, and works with non-STL containers (ie. pointers). It requires run-time type information, which slows (generally) everything down. Also, as a macro, it's not safe, and it may make copies (what if one of I or C is a function call? eg. EACH( I, some_foo()). Very bad! )
For just STL containers you could do something like:Now you can see the obvious problem with this - it's very close to for_each, and yet very far from your for ( EACH(I,C) ) macro. What you probably really want are lambda functions, per the C++ BOOST library, where you can have lovely things (per their examples) likeso:This is not a macro, so you don't lose the type safety, and it doesn't recreate (C) and (I) everytime they are called, and thinking ahead, doesn't store them in a temporary global variable so it's thread safe.
If you quit because you were doing something illegal in your job, you typically (but not always; it's state legislation) have whistleblower status. Sounds like he may have been racketeering.
Mind you, it isn't illegal to accuse people of doing something illegal or trespassing if you have suspicion that they indeed were. I'm really curious as to where the limits to the "use" of the law meet the "availability" of it.
When Big Business can win by costing too much to litigate against, you are deprived of the fundamental rule of law, by being unable to meet legal remedy.
Sorry; it didn't seem out of context to me. I took your whole comment to reflect on the holistic security of port-knocking, not just authentication.
No. Packets are packets, whether they're part of a connection or not. If you think portknocking is used, it's even easier to detect, because you can just throw out all the packets that are part of a connection (or query/response pairs from UDP protocols like DNS).
That's an O(n) problem for TCP; keeping track of connections requires a stack for every connection. On even a reasonably sized network: impossible. There are pseudo-connection stacks, but they are nevertheless O(n) and inherently incomplete.
There are packets that are 'impossible', but I don't remember what percentage of the flag-set they constitute, and you can look for them, but if it's being sniffed, you still need not know where it came from or what it is doing.
When you're sniffing you're anonymous by definition (unless your sniffing implementation gives you away to tools like anti-sniff). Not a feature of portknocking. And sniffing is relatively hard/risky.
Anonymous might not be the correct term - 'transparent' seems more appropriate. You do concur in the difficulty of sniffing, absent a span port on a router. If you control sophisticated routers, it is relatively easy, mind.
Port knocking is swell because it can totally disguise the fact that you're listening for incoming connections, and that's something ssh can't do.
And
Nothing other than coolness makes portknocking more secure than any other one-time-password scheme based on the same underlying password-generating technology (e.g. one-time-pad or a prng or whatever).
are in opposition, I think. The prior indicates a stenographic capacity: plausible deniability of even the existence of commands or access. Stenography, or on a policy level plausible deniability, is a form of security.
You are correct in asserting that a certain aspect of "security" is no greater, that being the actual breakability of the sequence down into its original command is no greater for knocking time-synchronized one-time pads than any other one-time pad. I would counter with the above, that "security" may include this plausibility deniability, which is enchanced over TCP/IP through this particular method, opposed to verifiable and traceable socket connections.
There are other values, as well. One is not requiring the establishment of a TCP connection itself, which presents the possiblity of untraceable packets, providing anonymity for the command sender. It also permits the listener to be anonymous if it is merely sniffing. (With the recent Cisco hacks, this is all the more deleterious) Thus there can be completely blind communication. Mind you, broadcasting TCP is tricky, often requiring "access" to a router, and the destination, or destination network is almost always visible, but the sender can certainly remain effectively anonymous.
The usable alphabet for a suicide TCP packet header is, I do believe, in bits:
16: dest. port
16: src port
32: seq id
6: flags
16: window
16: urgent
40: options
That gives us an alphabet 2^142 ~= 5.6 * 10^42. Not to mention that a sequence of packets can be combined, extending the language. Indeed, its cardinality is a natural ordinal, so the same as any password, if not more, by virtue of passwords being limited by an input buffer.
Knocking need only finite state between packets, simply indicating a status of "last packet correct knock?"; successive knocking therein is in a cardinality greater than passwords. Knocking can happen over a period of months (as I have seen it), and be virtually undetectable for all but the most sophisticted (ie. expensive) means of detection.
In combination with a time-synchronized one-time pad, you can generate an unrepeatable, provably (in the mathematical sense) secure system of access or commands. For example, for the minute of 13:01 EST, there can be a specific TCP packet, or series of packets that unlocks the door or executes a command. At no other predictable time would this knock be useful. (Time synchronization here is an issue, but often this attack will be used on machines that do care about an atomic clock sync).
You can do the same thing with a password over SSH, but that's higher level, using more complex code, and inherently more likely to succumb to high-level assaults such as buffer overflows, as well as mathematical assaults on the encryption itself, both of which fundamentally compromise the system's security.
In short, time-synchronized knocking is safer, simpler, and smarter than passwords or encryption for a certain number of niche applications.
Why use port knocking. It is no more secure than plain-text passwords. Use authpf. authpf can be set as the shell so when a user logs in authpf just changes the firewall rules.
I'm not sure that authpf corresponds to port-knocking's subject-matter.
You can make port-knocking more "secure" than encryption; you can use a time-synchronized one-time pad to construct and vary the ports, flags, TCP options, sequence, etc., to come up with a system both unique and impossible to duplicate, absent the one-time pad.
As one-time pads are provably secure, you can create a system that bars or ignores all communication except the effectively random knock that unlocks the door.
This sort of clandestine type of communication has been known about in the security community for a long time - pretty much since the ARPA days. Some backdoors used specific sequences of TCP flags, with no practical TCP use other than opening a backdoor, but permitting anonymous communication or command broadcasting.
With access to a TCP stack and a link-layer sniffer, you can send and receive, respectively, commands to ghosts in working machines, transparent proxies or "harmony" devices. It is good to see this sort of thing coming to light, since it is extraordinarily powerful and not very well known.
An example of these probing commands are Xmas, Fin, and Null scans for Fyodor's nmap; note that other TCP flags (TCP options, in particular) can harbour substantially more information than the flags alone.
Unfortunately, in the modern age of macro viruses, it is hardly necessary to be skilled or even aware of such devices to write a devastatingly powerful virus.
... to theatres, or to bittorrent?
There is a doctrine in law known as res ipsa loquitor, meaning "it flows from the facts", and permits construction of a "fact" where it is obvious from the context. It is essentially never sufficient for proof beyond a reasonable doubt to construct a fiction in fact or law that would make a criminal case.
Civil suits are a bit less stringent, typically having a lower burden of proof. Nevertheless it was up to the judge to say whether or not it was sufficient in this case to say "obviously" means "true and punishable".
There is a lot more case history on what inferences constitute various degrees of "proof", and modifying them has, in a common law system, drastic implications that transcend intellectual property law. It sets a precedent that has the potential to be abused in everything from insurance automobile cases through arson through sexual assault and murder. It is not a boundary lightly crossed.
Ignorance of the law should never be accepted as an excuse to break it.
Then why would we need lawyers?
Add to that:
- Forrestry (UBC, UNB)
- Marine (Memorial)
- Fuel Cells (Victoria, ie. Ballard)
I noted that all the recommended universities are in Ontario. Recently, most are suffering underfunding, unlike their Western counterparts.
I would strongly suggest investigating Western Canada for well funded engineering programs. The East coast universities are relatively poor, but are, typically, less ambitious and require less resources, and the cost of living is cheaper. And given the standard of engineering across Canada, your functionality is not detrimentally harmed by choosing any particular university, unless you have higher, post-graduate ambitions, IMHO.
IANAL, but I believe this comes from the quirk in Canadian law that you may make copies of something for yourself quite legally, just not for others. Since the people sharing aren't making the copies, it's legal.
I wouldn't call it a quirk. Every first world nation except the USA has the same provision and levy permitting non-infringement personal copying in the absence of permission.
Note however that Australia's Levy was struck down as unconstitutional in 1992/1993 though. That need not vitiate the non-infringement personal copying, however.
Well, had nuclear energy developed as expected, this would likely have been true. After all, 95% of the energy humanity produces in the western world is mobile, in vehicles, through the combustion of petroleum. Homes are piddly by comparison.
The Matrix, v0.1.
Everything mandrake does is gpl'd, so there's no reason that debian couldn't keep their crazy "hard" installer for traditionalists and setup the mandrake installer to install debian easy-like for newbies. why duplicate effort?
That would require porting the Mandrake installer to all the Debian ports. There are good x86 installers for Debian, from Progeny at least, but it, like Mandrake's, just isn't portable enough to be officially Debian.
Really, one person with the most potential, in my eyes, benefit from a good Linux platform is Sony. If the API for Linux were similar to the PS2/3, then 1. porting would be relatively cheap, 2. they get free consoles without the cost of manufacturing, and 3. they compete with Microsoft's model of doing exactly this with their Windows and Xbox API overlap.
... ;)
Perhaps this applies equally well to Nintendo