I cannot confirm or deny the degree to which any particular power/entity does these things; but the steps to landmine responsibility are actually pretty clear:
1. Good mapping: So you want to do some area denial? Please be damned sure about exactly what area you are denying, and write it down. GPS fixes per mine are now technologically feasible, and are ideal; but accurate boundaries of minefields are the absolute baseline.
2. Intelligent fuzes/case breakdown designs: Your classic mine is a waterproof box with a mechanical or mechanical/chemical trigger. Lasts an unpredictable amount of time, often in the multiple decades, and sometimes gets touchier as it ages. At a minefield level, even 100 years of waiting may well not be enough. More advanced mines, either by means of an electronic fuze with a RTC or by means of a case and explosives design with more predictable degradation under field conditions, can be set to either detonate or disarm themselves after a period of time, placing a reasonably hard limit on the active lifetime of a given minefield.
Obviously, the world is hard and neither technique is perfect. Land shifts, erosion does its thing, electronics fail, etc.; but somebody doing the above will make post-conflict minesweeping easier, cheaper, and safer than will somebody not doing them.
In general, larger national military forces are probably more likely to be responsible than smaller or more irregular ones: They tend not to go to war planning to lose, so they keep maps because they will want to demine their conquests/holdings(The Faulkland islands, for instance, were mined pretty heavily; but the miners had no intention of losing them, so the maps are excellent...) They also have the money for fancy "smart mines" and the nosy journalists who can be shut up with techie-lust stories of a more bloodless smart mine. Irregular forces often don't exactly have a GIS corps, and are more likely to be relying on whatever semi-expired crates of surplus they can score on the grey/black market, so their mines are likely to be heterogeneous and highly unpredictable.
On the other hand, while they tend to be a bit more tasteful with mines, the big guys tend to have a much larger issue with "cluster submunitions"...
Multiple SIM support has been around for years(typically not on US carrier locked stuff; but weirdo Chinese cheapies and retail-unlocked jet-setter devices do it standard, in addition to the slightly shady "16-in-one-SIM" hack/consolidation kits.
The real trick(though I'm not sure that virtualization is a good answer) is getting the vastly increased amount of user state, some of it either personally or business sensitive, separated in some logical way...
I'm guessing that the "smartphone" market isn't for you. It is still deep in "iterate like crazy and see what sticks" territory. One of Nokia's classic candybars might be more your style...
While, obviously, virtualization is the technology that VMware is going to throw at any use case, since "when all you have is a hammer, etc." It seems like a really hackish approach.
Virtualization, in my server/workstation experience, has three major benefits: 1. Migration: Assuming a decent SAN setup and some fastish interconnects, your VM can float merrily from physical server to physical server with periods of unresponsiveness under.1 second. Allows you to skip some of the really expensive "zOMG this particular piece of hardware must never, ever, ever die even once in the next decade" add-ons without compromising uptime. 2. Near-perfect compatibility with legacy software: Barring really esoteric stuff that is depending on being right next to the metal of some specific archaic box, all the legacy crapware out there needs to know absolutely nothing about virtualization in order to virtualize. Virtualization aware OSes can make life a bit easier; but there is nothing stopping you from running almost any obsolete crap you need to run on a virtual machine that looks exactly like something from 1995, only with a 3 GHz processor and loads of RAM. 3. Isolation and rollback, particularly for workstations, being able to call up, experiment on, roll back, and delete OS instances makes doing potentially dangerous things safe.
However, all these things are either irrelevant to cellphones(unless your cellphone has SAN storage and a GB link to the redundant cellphone in your other pocket...) or artefacts of the fact that legacy software largely sucks at things like isolation and versioning. Virtualization, like the AMD64 instruction set, is massively popular because it allows the power of architectures that don't suck without giving up legacy software that runs on architectures that do. With something like Android, though, an almost-totally-new OS is being built from near-scratch to suit a new set of requirements. Virtualization seems very heavy handed compared to something like having isolated namespaces and URI "domains" into which programs can be confined...
Freedom isn't free and our laws are produced by a robust process of competitive bidding between plutocrats and corporations. Ergo, our laws make us perhaps the freest country ever!(and certainly Jesus' favorite...)
It remains to be seen how expansive Google's interpretation of "web app" is...
With their NaCl project, it could include entire native binaries, "installed" just by going to a web page, cached via HTML5 methods, sandboxed for security. Such a model wouldn't be very "web" of them; but it would mean that ChromeOS can do basically everything except run legacy applications not designed for it.
Rather more than that. Android is largely Dalvik VM with some native access to the underlying stock-but-pretty-spartan-linux. ChromeOS offers sandboxed web pages as a sort of "VM" with as yet unknown levels of native access via NaCl, and likely support for certain other applications(PDF reader, Flash, etc.) running natively on what is likely to be the underlying stock-but-pretty-spartan-linux.
The physical construction of the phone makes his scenario extremely unlikely as well.
The battery(basically the only source of energy sufficient to do any damage to the phone or its surroundings, none of the caps in that thing are other than tiny-size tantalum units,) is enclosed at the back of the phone only by a little plastic battery door. Were it to blow, it'd be totally plausible for that door to be melted/deformed/pop off and the user to suffer burns on their hand, wrist, possibly neck/shoulder, depending on the angle of the flames. On the other side of the battery, between it and the user's ear, is pretty much the entire damn phone. Toughened glass touchscreen, RF shielding, keyboard, logic board, etc. It would take an extraordinarily 'shaped' failure of the battery to cut through all that, rather than just exiting the battery compartment through the flimsy plastic door...
Batteries can and do burn, often pretty enthusiastically, and "explosion" isn't totally inaccurate if they are enclosed at the time; but they aren't exactly shaped charges here, just some flames and hot gasses that would tend to exit the easy way.
That Verizon's splashy "Android devices are death-robots from the future who can tear you to shreds with a single shot from their massive feature lists" campaign might have had something to do with that. And then you get into the fact that Apple has been producing devices with off-the-charts WAF for ages now...
Oh, one other thing (this one actually causes the most friction with the users): we in "IT" generally have to block streaming music sites. This one strikes people as arbitrary and draconian; but the logic is actually pretty clear: unlike streaming video, which is bandwidth intensive but only somebody heading for a pink slip will need more than a few minutes a day of, streaming audio can easily replace the radio.
Since our primary business is not internet related, we only have a nice-but-modest commercial connection setup(ie. multiple redundancies; but actually a bit under 100Mb/s down for over 1,000 users). Since user traffic is quite bursty, this is virtually never a problem. Most user downloads are remote host limited, and against fast remote hosts 1-2 megabytes a second are not uncommon. However, if we assume that "streaming audio" means "64-128Kb/s, per terminal", even a solid 100megabit line could only support 1600 concurrent 64Kb/s or 800 128Kb/s users, and that only if nothing else where going on, which isn't the case.
I suspect that other moderate to large sites are fairly similar: their pipes are faster, and almost definitely more redundant, than what comes to your house; but if evenly divided(instead of burstily divided) among all users across a site, they are actually pretty under-provisioned. Since real-world traffic is typically bursty, they'll run like a bat out of hell if you catch them at the right time; but if the entire accounting department is tuning in to 128Kb/s EZ-listening, that could easily eat 3/4 of the pipe...
These studies about (almost always public sector) workers and their terrible, terrible internet misuse seem like little more than ammunition for the handwringers, and maybe a couple of privatization zealouts.
Reality: Unless chained to an assembly line, under guard, most workers are going to spend some minutes a day doing some form of "nonwork". Particularly for people whose work involves a mixture of thinking and typing, it won't even be trivial to distinguish between work and nonwork, and for people whose work involves manual labor, one has to make the distinction between "rest" and "slacking off".
Given that the internet is a bottomless well of amusements, as well as an excellent way to check personal email, pay that credit card bill you just remembered to avoid a late fee, queue up a netflix item while you are still thinking about it from that conversation at lunch, etc. it seems pretty obvious that most of the white-collar nonwork is going to be internet related(and almost 100% of the visible kind is. If somebody spends 10 minutes 'cleaning their desk' in order to avoid work, nobody will ever know. If they spend 10 minutes on reddit, IT can know completely automatically.
Now, as "IT" for an institution myself, I can sympathize with IT trying to block certain sorts of extracurriculars: I don't want to get a BSA beatdown because you were on warez.ru. I don't want to spend my already overstretched time battling viruses because you just had to download free smilies and/or goat porn. If the institution's attorney's come to me and say "We are being sued for creating a hostile, porn infested work environment." I would like to be able to say "Well, we have measures in place that meet or exceed industry standards for professional content filtering; but, as no programmatic filter can be perfect, we do ultimately depend on HR's training and disciplinary procedures." rather than "Well, goodbye to my career..."
However, again in "IT"'s shoes, I don't give a fuck if you want to check your gmail, balance your checkbook, or do some online christmas shopping. If it doesn't mean legal exposure or substantial likelyhood of time consuming or costly network damage(thanks to 3rd party ad networks, virtually any site is a potential risk, but the known hives of scum and villainy are worse...) If your performance sucks, hopefully your performance reviews will reflect that and get you fired. If your performance doesn't suck, the cost of a few megabytes off our big fat institutional connection is A)sunk, we pay for the pipe whether we use it or not and B) probably less than your paperclip budget for the year. I. Don't. Care.
Worker productivity is not a problem that you can solve by dicing up their workday and micromanaging what happens during every second. Decide what performance you want, fire people who don't meet it, keep people who do, promote people who exceed it. Don't fuck around with meaningless(but easy to measure) minutia: that is practically the definition of "cargo cult management".
The best advice is probably "Get a real lawyer", which is generally economically unfeasible.
Speaking strictly as a 'neither a lawyer nor your lawyer' though, Bandai's DMCA notice sounds like bullshit. Your game may well amount to trademark infringement or even step on some kind of insane patent(apparatus and methods for inducing gamer to care about motile pie-chart); but DMCA notices deal only with copyright violations. Not trademarks, not patents, not defamation, not libel, etc.
Unless your game contains sprites/sounds etc. either ripped directly or falling into the category of "derivative work", a DMCA notice is just the cheapest way to get you offline, not a legally correct approach. In fact, not that this ever happens, Bandai may actually have exposed themselves to some sort of liability by bad-faith filing of one, not that that helps you much. Of course, Bandai could likely crush you like a bug with actual lawyers, this is just a low-cost first shot.
That would be the idea. The smartcard would be directly connected to the camera, and a required part of the image-saving processs(if crypto were desired, if you just wanted to happy snap, it would be irrelevant); but would be removable, and would be where all the cryptographic secrets live, and so could be easily subjected to whatever physical security measures suit the organization using it(unlike a mass-market camera, which is going to be physically avaiable to anybody with a few hundred or few thousand dollars and/or fast fingers...)
The camera would take the image, do a SHA1 or MD5(since, having the image in RAM would make it fast for the camera, even with a largish image) and then, if a smartcard is present, pass the image hash to the smartcard to be signed and returned and written to flash along with the image. The private key is never exposed to the camera, and the only "secret" you could learn from buying a camera of the same model is what ASIC they are using to do an off-the-shelf hashing algorithm on a low power budget. And, the moment Agent Smith removes his smartcard from the camera, there is absolutely nothing sensitive remaining in that camera body.
Really, cryptographic jiggery-pokery is a problem best solved outside the camera. Generating an MD5 or SHA1 onboard is fine(even if you don't care about the crypto, it's a nice check against memory card corruption, and most nicer cameras have the entire frame in memory at some point before writing it to the card so the hashing should be fast); but leaving the crypto to a removable, interchangeable, person/organization unique crypto smartcard would really be the way to go.
That way, you wouldn't need to trust the camera(other than to be not broken, calculating false MD5s would be useless and swiftly detected), plus you could easily swap out the high-value portion of the hardware so that multiple authorized users could share a camera, and their cards could be physically protected when not in use.
This graphic sums up, better than mere words, the quality of Symantec, and the general scumminess that so easily creeps into "protection" businesses...
To any students using the internet rather than a library to do their homework: I am lying in order to score "funny" mods. Also, "a guy who calls himself fuzzyfuzzyfungus told me" is not an acceptable citation format in any version of the MLA handbook.
The trouble is that Android is open; but most devices are(often incompetently) Tivoized good and hard...
People may love to bag on RMS and GPL3(and it is indeed quite possible that only the chance to Tivoize and "value add" is what got android onto as many carrier-blessed and subsidized handsets as it is now on); but the threat of having plenty of free software and nothing but x86 whiteboxes and hobbyist hackjobs in protoboxes to run it on is hardly pure paranoia...
To the best of my (layman's) knowledge, the area of what implies an "implied consent" or "implied contract" is often rather murky, and based on a mixture of precedent and judicial gut feeling, along with some patchy laws.
I would be pretty certain that EMI posting Song X to which they own the copyright to Rapidshare does not entitle me to (legally) redistribute it; but it seems like there might be a very good argument that it does entitle me to, legally, download it. If there is a location(a Freecycle depot or something) that operates under a large banner saying "Free stuff, take what you want, save it from the dump!" and I place a computer that I own in that location, I have to imagine that a reasonable man, in the legal sense, would conclude that I am thereby forfeiting ownership of that object(unless I can specifically prove that I was just carrying it, set it down for a moment to catch my breath, and somebody snatched it from beside my feet, or something similar).
Rapidshare, as its name would suggest, is basically an electronic analog of such a physical place. You put stuff there to distribute it(though, if memory serves, they might have some private distribution option for members). If a rightsholder knowingly and intentionally places material to which they own the rights in a place that explicitly operates as a medium for free dissemination, one would imagine that this amounts to an implied consent to, at least, free dissemination from that location. It doesn't clearly mean surrender of copyright, so it might not save those who re-disseminate it by other means; but it would seem to imply a licence to disseminate has been granted to rapidshare...
Obviously, IANAL; but I know that there are limits to what you can do without creating implicit, and binding, rights to for others. You can't mail somebody something without their consent and then invoice them for it, if you try, the thing that you mailed is a gift. If you put something on the curb, with a "free-take me" sign, you can't reasonably expect to charge the person who does with larceny...
One of the lesser-known sections of the code of Hammurabi reads "If a man shall falsely promise p3n1s 3xt3nsion and thereby cause public nuisance and distress, his own penis shall be stretched by one digit for each such false promise. If he spreads his false promises by means of another man's messenger, he shall be flogged."
They often skip this one in elementary history lessons on the matter; but it is arguably quite salient in today's interconnected world...
Local mounted backups are definitely suboptimal; but they do protect against single drive death and nonmalicious accidental deletion, which are two major categories of threat, at essentially nominal cost. Any idiot who thinks in some simple binary "safe"/"unsafe" terms has it coming when something nukes every local drive; but that is rather rarer than having a single drive catch a nasty case of being horribly dead.
In any case, unless Joe average wants to enter a password and/or RSA token code every few hours, off site backups are going to be accessible with either passwords or keys stored(probably in one of a small number of known locations, depending on the backup software in use) on Joe's machine. Against malice, any fully automated offline backup is, essentially, a local, always mounted, backup volume. Any offline backup that isn't fully automated will, within weeks or months, stop being used; because Joe is lazy.
Still nice in case of house fires, thefts, wanting to restore a fresh laptop when your old one falls under a bus while travelling, etc; but unless your remote backup requires manual authentication, it is essentially "mounted" for the purposes of an attacker...
Slashdot Mirror
I cannot confirm or deny the degree to which any particular power/entity does these things; but the steps to landmine responsibility are actually pretty clear:
1. Good mapping: So you want to do some area denial? Please be damned sure about exactly what area you are denying, and write it down. GPS fixes per mine are now technologically feasible, and are ideal; but accurate boundaries of minefields are the absolute baseline.
2. Intelligent fuzes/case breakdown designs: Your classic mine is a waterproof box with a mechanical or mechanical/chemical trigger. Lasts an unpredictable amount of time, often in the multiple decades, and sometimes gets touchier as it ages. At a minefield level, even 100 years of waiting may well not be enough. More advanced mines, either by means of an electronic fuze with a RTC or by means of a case and explosives design with more predictable degradation under field conditions, can be set to either detonate or disarm themselves after a period of time, placing a reasonably hard limit on the active lifetime of a given minefield.
Obviously, the world is hard and neither technique is perfect. Land shifts, erosion does its thing, electronics fail, etc.; but somebody doing the above will make post-conflict minesweeping easier, cheaper, and safer than will somebody not doing them.
In general, larger national military forces are probably more likely to be responsible than smaller or more irregular ones: They tend not to go to war planning to lose, so they keep maps because they will want to demine their conquests/holdings(The Faulkland islands, for instance, were mined pretty heavily; but the miners had no intention of losing them, so the maps are excellent...) They also have the money for fancy "smart mines" and the nosy journalists who can be shut up with techie-lust stories of a more bloodless smart mine. Irregular forces often don't exactly have a GIS corps, and are more likely to be relying on whatever semi-expired crates of surplus they can score on the grey/black market, so their mines are likely to be heterogeneous and highly unpredictable.
On the other hand, while they tend to be a bit more tasteful with mines, the big guys tend to have a much larger issue with "cluster submunitions"...
Presumably, the employer would be able to nuke the "work" VM from orbit at their pleasure; but would have no access to the "nonwork" VM...
Multiple SIM support has been around for years(typically not on US carrier locked stuff; but weirdo Chinese cheapies and retail-unlocked jet-setter devices do it standard, in addition to the slightly shady "16-in-one-SIM" hack/consolidation kits.
The real trick(though I'm not sure that virtualization is a good answer) is getting the vastly increased amount of user state, some of it either personally or business sensitive, separated in some logical way...
I'm guessing that the "smartphone" market isn't for you. It is still deep in "iterate like crazy and see what sticks" territory. One of Nokia's classic candybars might be more your style...
While, obviously, virtualization is the technology that VMware is going to throw at any use case, since "when all you have is a hammer, etc." It seems like a really hackish approach.
.1 second. Allows you to skip some of the really expensive "zOMG this particular piece of hardware must never, ever, ever die even once in the next decade" add-ons without compromising uptime. 2. Near-perfect compatibility with legacy software: Barring really esoteric stuff that is depending on being right next to the metal of some specific archaic box, all the legacy crapware out there needs to know absolutely nothing about virtualization in order to virtualize. Virtualization aware OSes can make life a bit easier; but there is nothing stopping you from running almost any obsolete crap you need to run on a virtual machine that looks exactly like something from 1995, only with a 3 GHz processor and loads of RAM. 3. Isolation and rollback, particularly for workstations, being able to call up, experiment on, roll back, and delete OS instances makes doing potentially dangerous things safe.
Virtualization, in my server/workstation experience, has three major benefits: 1. Migration: Assuming a decent SAN setup and some fastish interconnects, your VM can float merrily from physical server to physical server with periods of unresponsiveness under
However, all these things are either irrelevant to cellphones(unless your cellphone has SAN storage and a GB link to the redundant cellphone in your other pocket...) or artefacts of the fact that legacy software largely sucks at things like isolation and versioning. Virtualization, like the AMD64 instruction set, is massively popular because it allows the power of architectures that don't suck without giving up legacy software that runs on architectures that do. With something like Android, though, an almost-totally-new OS is being built from near-scratch to suit a new set of requirements. Virtualization seems very heavy handed compared to something like having isolated namespaces and URI "domains" into which programs can be confined...
The fact that my satirical post was not immediately recognizable by all as such, without a shadow of doubt, makes me very, very nervous...
Freedom isn't free and our laws are produced by a robust process of competitive bidding between plutocrats and corporations. Ergo, our laws make us perhaps the freest country ever!(and certainly Jesus' favorite...)
QED LIEberals!
Obviously, everybody should just obsessively tweet #heilwhale until the problem resolves itself.
Extra credit will, naturally, be awarded for terrifying photochops of the failwhale with Chertoff's skull-like face...
It remains to be seen how expansive Google's interpretation of "web app" is...
With their NaCl project, it could include entire native binaries, "installed" just by going to a web page, cached via HTML5 methods, sandboxed for security. Such a model wouldn't be very "web" of them; but it would mean that ChromeOS can do basically everything except run legacy applications not designed for it.
Rather more than that. Android is largely Dalvik VM with some native access to the underlying stock-but-pretty-spartan-linux. ChromeOS offers sandboxed web pages as a sort of "VM" with as yet unknown levels of native access via NaCl, and likely support for certain other applications(PDF reader, Flash, etc.) running natively on what is likely to be the underlying stock-but-pretty-spartan-linux.
Substantially more architectural difference.
The physical construction of the phone makes his scenario extremely unlikely as well.
The battery(basically the only source of energy sufficient to do any damage to the phone or its surroundings, none of the caps in that thing are other than tiny-size tantalum units,) is enclosed at the back of the phone only by a little plastic battery door. Were it to blow, it'd be totally plausible for that door to be melted/deformed/pop off and the user to suffer burns on their hand, wrist, possibly neck/shoulder, depending on the angle of the flames. On the other side of the battery, between it and the user's ear, is pretty much the entire damn phone. Toughened glass touchscreen, RF shielding, keyboard, logic board, etc. It would take an extraordinarily 'shaped' failure of the battery to cut through all that, rather than just exiting the battery compartment through the flimsy plastic door...
Batteries can and do burn, often pretty enthusiastically, and "explosion" isn't totally inaccurate if they are enclosed at the time; but they aren't exactly shaped charges here, just some flames and hot gasses that would tend to exit the easy way.
That Verizon's splashy "Android devices are death-robots from the future who can tear you to shreds with a single shot from their massive feature lists" campaign might have had something to do with that. And then you get into the fact that Apple has been producing devices with off-the-charts WAF for ages now...
Oh, one other thing (this one actually causes the most friction with the users): we in "IT" generally have to block streaming music sites. This one strikes people as arbitrary and draconian; but the logic is actually pretty clear: unlike streaming video, which is bandwidth intensive but only somebody heading for a pink slip will need more than a few minutes a day of, streaming audio can easily replace the radio.
Since our primary business is not internet related, we only have a nice-but-modest commercial connection setup(ie. multiple redundancies; but actually a bit under 100Mb/s down for over 1,000 users). Since user traffic is quite bursty, this is virtually never a problem. Most user downloads are remote host limited, and against fast remote hosts 1-2 megabytes a second are not uncommon. However, if we assume that "streaming audio" means "64-128Kb/s, per terminal", even a solid 100megabit line could only support 1600 concurrent 64Kb/s or 800 128Kb/s users, and that only if nothing else where going on, which isn't the case.
I suspect that other moderate to large sites are fairly similar: their pipes are faster, and almost definitely more redundant, than what comes to your house; but if evenly divided(instead of burstily divided) among all users across a site, they are actually pretty under-provisioned. Since real-world traffic is typically bursty, they'll run like a bat out of hell if you catch them at the right time; but if the entire accounting department is tuning in to 128Kb/s EZ-listening, that could easily eat 3/4 of the pipe...
These studies about (almost always public sector) workers and their terrible, terrible internet misuse seem like little more than ammunition for the handwringers, and maybe a couple of privatization zealouts.
Reality: Unless chained to an assembly line, under guard, most workers are going to spend some minutes a day doing some form of "nonwork". Particularly for people whose work involves a mixture of thinking and typing, it won't even be trivial to distinguish between work and nonwork, and for people whose work involves manual labor, one has to make the distinction between "rest" and "slacking off".
Given that the internet is a bottomless well of amusements, as well as an excellent way to check personal email, pay that credit card bill you just remembered to avoid a late fee, queue up a netflix item while you are still thinking about it from that conversation at lunch, etc. it seems pretty obvious that most of the white-collar nonwork is going to be internet related(and almost 100% of the visible kind is. If somebody spends 10 minutes 'cleaning their desk' in order to avoid work, nobody will ever know. If they spend 10 minutes on reddit, IT can know completely automatically.
Now, as "IT" for an institution myself, I can sympathize with IT trying to block certain sorts of extracurriculars: I don't want to get a BSA beatdown because you were on warez.ru. I don't want to spend my already overstretched time battling viruses because you just had to download free smilies and/or goat porn. If the institution's attorney's come to me and say "We are being sued for creating a hostile, porn infested work environment." I would like to be able to say "Well, we have measures in place that meet or exceed industry standards for professional content filtering; but, as no programmatic filter can be perfect, we do ultimately depend on HR's training and disciplinary procedures." rather than "Well, goodbye to my career..."
However, again in "IT"'s shoes, I don't give a fuck if you want to check your gmail, balance your checkbook, or do some online christmas shopping. If it doesn't mean legal exposure or substantial likelyhood of time consuming or costly network damage(thanks to 3rd party ad networks, virtually any site is a potential risk, but the known hives of scum and villainy are worse...) If your performance sucks, hopefully your performance reviews will reflect that and get you fired. If your performance doesn't suck, the cost of a few megabytes off our big fat institutional connection is A)sunk, we pay for the pipe whether we use it or not and B) probably less than your paperclip budget for the year. I. Don't. Care.
Worker productivity is not a problem that you can solve by dicing up their workday and micromanaging what happens during every second. Decide what performance you want, fire people who don't meet it, keep people who do, promote people who exceed it. Don't fuck around with meaningless(but easy to measure) minutia: that is practically the definition of "cargo cult management".
The best advice is probably "Get a real lawyer", which is generally economically unfeasible.
Speaking strictly as a 'neither a lawyer nor your lawyer' though, Bandai's DMCA notice sounds like bullshit. Your game may well amount to trademark infringement or even step on some kind of insane patent(apparatus and methods for inducing gamer to care about motile pie-chart); but DMCA notices deal only with copyright violations. Not trademarks, not patents, not defamation, not libel, etc.
Unless your game contains sprites/sounds etc. either ripped directly or falling into the category of "derivative work", a DMCA notice is just the cheapest way to get you offline, not a legally correct approach. In fact, not that this ever happens, Bandai may actually have exposed themselves to some sort of liability by bad-faith filing of one, not that that helps you much. Of course, Bandai could likely crush you like a bug with actual lawyers, this is just a low-cost first shot.
That would be the idea. The smartcard would be directly connected to the camera, and a required part of the image-saving processs(if crypto were desired, if you just wanted to happy snap, it would be irrelevant); but would be removable, and would be where all the cryptographic secrets live, and so could be easily subjected to whatever physical security measures suit the organization using it(unlike a mass-market camera, which is going to be physically avaiable to anybody with a few hundred or few thousand dollars and/or fast fingers...)
The camera would take the image, do a SHA1 or MD5(since, having the image in RAM would make it fast for the camera, even with a largish image) and then, if a smartcard is present, pass the image hash to the smartcard to be signed and returned and written to flash along with the image. The private key is never exposed to the camera, and the only "secret" you could learn from buying a camera of the same model is what ASIC they are using to do an off-the-shelf hashing algorithm on a low power budget. And, the moment Agent Smith removes his smartcard from the camera, there is absolutely nothing sensitive remaining in that camera body.
Really, cryptographic jiggery-pokery is a problem best solved outside the camera. Generating an MD5 or SHA1 onboard is fine(even if you don't care about the crypto, it's a nice check against memory card corruption, and most nicer cameras have the entire frame in memory at some point before writing it to the card so the hashing should be fast); but leaving the crypto to a removable, interchangeable, person/organization unique crypto smartcard would really be the way to go.
That way, you wouldn't need to trust the camera(other than to be not broken, calculating false MD5s would be useless and swiftly detected), plus you could easily swap out the high-value portion of the hardware so that multiple authorized users could share a camera, and their cards could be physically protected when not in use.
This graphic sums up, better than mere words, the quality of Symantec, and the general scumminess that so easily creeps into "protection" businesses...
Not to worry, there's a section on what happens "If a man lies about or defames This Code in the service of a crude penis joke"...
No, they are one of those "how the hell do you guys stay in business" free/subscription http file hosting sites. Entirely server -> client.
To any students using the internet rather than a library to do their homework: I am lying in order to score "funny" mods. Also, "a guy who calls himself fuzzyfuzzyfungus told me" is not an acceptable citation format in any version of the MLA handbook.
PSA Ends.
The trouble is that Android is open; but most devices are(often incompetently) Tivoized good and hard...
People may love to bag on RMS and GPL3(and it is indeed quite possible that only the chance to Tivoize and "value add" is what got android onto as many carrier-blessed and subsidized handsets as it is now on); but the threat of having plenty of free software and nothing but x86 whiteboxes and hobbyist hackjobs in protoboxes to run it on is hardly pure paranoia...
To the best of my (layman's) knowledge, the area of what implies an "implied consent" or "implied contract" is often rather murky, and based on a mixture of precedent and judicial gut feeling, along with some patchy laws.
I would be pretty certain that EMI posting Song X to which they own the copyright to Rapidshare does not entitle me to (legally) redistribute it; but it seems like there might be a very good argument that it does entitle me to, legally, download it. If there is a location(a Freecycle depot or something) that operates under a large banner saying "Free stuff, take what you want, save it from the dump!" and I place a computer that I own in that location, I have to imagine that a reasonable man, in the legal sense, would conclude that I am thereby forfeiting ownership of that object(unless I can specifically prove that I was just carrying it, set it down for a moment to catch my breath, and somebody snatched it from beside my feet, or something similar).
Rapidshare, as its name would suggest, is basically an electronic analog of such a physical place. You put stuff there to distribute it(though, if memory serves, they might have some private distribution option for members). If a rightsholder knowingly and intentionally places material to which they own the rights in a place that explicitly operates as a medium for free dissemination, one would imagine that this amounts to an implied consent to, at least, free dissemination from that location. It doesn't clearly mean surrender of copyright, so it might not save those who re-disseminate it by other means; but it would seem to imply a licence to disseminate has been granted to rapidshare...
Obviously, IANAL; but I know that there are limits to what you can do without creating implicit, and binding, rights to for others. You can't mail somebody something without their consent and then invoice them for it, if you try, the thing that you mailed is a gift. If you put something on the curb, with a "free-take me" sign, you can't reasonably expect to charge the person who does with larceny...
One of the lesser-known sections of the code of Hammurabi reads "If a man shall falsely promise p3n1s 3xt3nsion and thereby cause public nuisance and distress, his own penis shall be stretched by one digit for each such false promise. If he spreads his false promises by means of another man's messenger, he shall be flogged."
They often skip this one in elementary history lessons on the matter; but it is arguably quite salient in today's interconnected world...
Local mounted backups are definitely suboptimal; but they do protect against single drive death and nonmalicious accidental deletion, which are two major categories of threat, at essentially nominal cost. Any idiot who thinks in some simple binary "safe"/"unsafe" terms has it coming when something nukes every local drive; but that is rather rarer than having a single drive catch a nasty case of being horribly dead.
In any case, unless Joe average wants to enter a password and/or RSA token code every few hours, off site backups are going to be accessible with either passwords or keys stored(probably in one of a small number of known locations, depending on the backup software in use) on Joe's machine. Against malice, any fully automated offline backup is, essentially, a local, always mounted, backup volume. Any offline backup that isn't fully automated will, within weeks or months, stop being used; because Joe is lazy.
Still nice in case of house fires, thefts, wanting to restore a fresh laptop when your old one falls under a bus while travelling, etc; but unless your remote backup requires manual authentication, it is essentially "mounted" for the purposes of an attacker...