My child&#39;s name is &quot;Robert&#39;); drop table *;--&quot; Is he in trouble? (Source: https://xkcd.com/327/) So with the upcoming birth of my first child, I suggested the name "Robert'); drop table *;--". While I was quickly told that wasn't going to happen, I have to wonder what could happen if he was actually named that. For the less technical, this name contains what is called a SQL injection attack. If the name is entered into a poorly designed SQL system, it could potentially execute a sql command and drop all tables (i.e. cause the organization's IT manager to have a somewhat bad day, depending on how good their backups are). So assuming I am able to get this name on his birth certificate and get his SSN assigned under that name (let us assume that the government has been able to build their system such that this name can be handled without issue), what would happen if his name fulfills its intended purpose when signing him up for day care? In that while signing little Bobby tables up for day care, his name wiped out all their data, and because of their lack of a good IT policy, they have no backups, causing no small amount of trouble for the day care. What would I be charged with or sued for in this case? I assume I am on the hook for some sort of malicious destruction of data or somehow liable for the loss of data. Would this being his name afford any sort of protection? Or would the fact that it was selected intentionally to cause damage be an issue? Jurisdiction: United States, pick any state you feel like.
Your kid is not in trouble; he's a minor. You're in trouble. A criminal case for the charges a prosecutor would bring, i.e. destruction of property (the data) or for a relevant cyber or computer crime (malware, etc.), and/or a civil case for damages due to the destruction of the data would both hinge on one point: the concept of intent. See intent - Wex Legal Information Institute and Civil Law vs. Criminal Law: The Differences | Rasmussen College. Did you knowingly intend to cause damage or data loss with the structure of the name? It's pretty clear you did. The structure of a name that can invoke an SQL command is not in any sense a standard name in spelling or format or punctuation. So how would you convince the jury or judge that you had no intent when you named your kid? The possible poor design of a data system that didn't sanitize inputs is no defense. Saying the door was unlocked so I assume the homeowners didn't care if I trashed their house will get you laughed into jail or on the hook for a stiff civil judgement.
In dealing with financial, medical, insurance and basically any other forms found in the U.S. do I have a legal responsibility to identify myself as Divorced? Or in other words, could identifying myself as Single as opposed to a divorcee incur any type of liability of which I should be aware? Since you specified the financial and medical contexts, yes, sometimes it is mandatory to disclose that you are divorced. Any time your signature is involved, be as accurate as the form allows. The worst consequence I can think of is actually pretty bad (&quot;penalty of perjury&quot; is no joke, and whether or not it should, divorce does impact a surprising number of especially financial considerations.) If possible, it would be better to simply not answer at all than to sign off on something other than the most accurate option available. In these contexts, the designation as having been divorced is often an archaic throwback predating no-fault. For example, divorce adversely impacts your credit (more than the loss of a partner's presumed earning power, the reasoning here is basically that marriage was a long-term commitment you entered into willingly that was not fulfilled.) Jobs or employment opportunities demanding a very high degree of personal integrity may be negatively impacted by having, or having had a divorce, by the same reasoning (the examples that pop to mind are officers the military, depending on the career field.) Divorce can be interpreted as an indication that the individual in question is currently not as stable in their personal life and affairs (moving, figuring out joint custody, jealous/vindictive ex, etc.) as a prospective lender or employer requires. As far as healthcare is concerned, it can have an impact on health care services and how providers interact with you, your ex, etc. (for example, your child's pediatrician.) Having had a divorce can be a flag to health care provider to screen for depression, anxiety, blood pressure, and so forth; likewise, insurance companies consider divorce a &quot;major life event&quot; that qualifies you to change your coverage out-of-season (I don't know, but wouldn't be surprised if divorce somehow impacted your rates because of statistical increased risk of specific ailments.) Furthermore, there can be far-reaching implications for others - how long you were married determines whether or not social security benefits are conferred to a surviving spouse, for example, or calculating your kid's FAFSA in five or ten or fifteen years.
My gut response without really analyzing it (which is honestly what a lot of these cases boil down to in the end) is that the proposed name would imply an affiliation with the company that does not exist. A case challenging that name could be expensive and come out either way. Instead, "The [Wife's Name] Toy Museum" with descriptive material in brochures and on a website saying that the exhibits were manufactured by "Toy Company", which is a nominative use that does not imply an affiliation with the Company would be a wiser move.
It is illegal to sell alcohol to a minor in Washington (RCW 66.44.270). The seller can get into various kinds of trouble, including losing their license, under liquor board regulations. However, as long as the establishment follows the rules for acceptable ID, they escape liability if in fact they sell alcohol to a minor: the license holder is legally allowed to accept an identification of the specific type. That is the sense in which this is required by law: the customer must have actually presented the identification, in order for the establishment to escape liability (RCW 66.20.210). Looking old enough is not the issue. It is legal to sell alcohol to a person who is over 21, and the law does not require presentation of identification as a condition for a sale. However, under RCW 66.20.180 a person is require to produce ID "upon request of any licensee, peace officer, or enforcement officer of the board". The legal risk attached to sales in an age-marginal situation is very high, and actual presentation of ID is required to escape liability by the establishment, so in that sense, it is "required by law". All requests to produce ID for liquor sales (at least in Washington, and leaving out deliveries which are governed by other laws) are driven by company policy. Typical policies are quite rational, being designed to protect the company's interest in not getting into a heap of trouble for an under-age sale. There is no law saying when you must ask, or when you are protected if you don't ask. Usually, store policy is to use "common sense" so that 90 year olds are not required to produce ID (they may be asked, jokingly). Non-compliance with RCW 66.20.180 carries no legal penalty, that is, there is nothing in the statute that says "if the customer doesn't...". The most obvious would be that the seller would refuse to sell, which the seller can arbitrarily do anyhow. There is no statutory penalty imposed on a licensee if they request ID of a person over 21 and the person fails / refuses to produce the ID. Obviously, the licensee cannot be punished if a customer fails to provide ID (and leaves), especially if they lost it. But the law "requires" them to provide an ID, with ne except "unless you leave / put the bottle back". Somewhat less obviously, if the legislature wants to, it can enact a provision that once a licensee requests ID, they are forbidden to sell alcohol to that customer until ID is provided. But there currently is no such law. "The law" also included regulations, such as WAC 314-17-105. This regulation is a chart, and the relevant entry is PERMIT: Failure to produce permit or identification upon request. See RCW 66.20.310 and 66.20.180. for which the 1st offense consequence is "5-day permit suspension OR $100 monetary option". This is a problematic regulation (potential lawsuit fodder), since it can be interpreted in a number of ways. The question is, of whom is the permit or identification predicated? Only the licensee has a permit, but customers and employees can both have identification. If we interpret this regulation as meaning "Failure by licensee or customer", then we arrive at the absurd conclusion that if a customer fails to produce ID on request, the establishment is fined. It is important to note that this regulation is under a chapter about server training, thus the regulation can only reasonably be interpreted as being about licensee providing identification.
See the answer to this question. It is remotely possible that it will show up, but the new S.C. law also says that an employer cannot use that information. On the other hand, that law is not yet effective (it becomes effective Dec. 27 2018), so for the rest of the year, the information could be used, if an employer obtains is. There is a law-enforcement exception that arrests can always be used against you if you apply for a law-enforcement related job. Under the current law (has been in effect for a while), the record is "under seal", so revealing the record in the course of a background check would be a violation of the relevant court order. The law specifies a punishment for illegal disclosure: A person who intentionally violates this subsection is guilty of a misdemeanor, and, upon conviction, must be fined not more than one hundred dollars or imprisoned not more than thirty days, or both. however, accidental disclosure is not a crime. You might think that you could at least sue them for accidental disclosure, but the law also says Unless there is an act of gross negligence or intentional misconduct, nothing in this section gives rise to a claim for damages against the State, a state employee, a political subdivision of the State, an employee of a political subdivision of the State, a public officer, or other persons. If the government person who releases the information intentionally does so, you can sue. Perhaps an accidental release could be found to be grossly negligent: that would depend on the circumstances.
I think haveibeenpwned would be legal in the EU because it carries out a task in the public interest (Art. 6(1)(e)), and it shares no more data then necessary, for example you can search for a password, but it would not show you the emailaddress which belongs to that password. It would also be legal for you to hold a copy of a leaked database, but only if you have a legitimate interest (Art. 6(1)(f)) to have it. Being a security company does not change that, but finding a legitimate interest might be easier. If you have a legitimate interest to hold a copy of a leaked database, it does not mean you can use it in any way you like. For example testing if the password still works, is very likely illegal everywhere in the EU. But I'm not familiar with the UK laws.
First of all, a contract is valid without a signature and even without being in writing; all that is needed is consent by the parties. Therefore, the signature is merely evidence of that consent and is only relevant if a dispute arises over the general consent or the particular terms that were consented to. A digital signature would make it harder for Bob to argue that those were not the terms he signed but if I have Bob's signature on them then the onus of proving he didn't sign rests with Bob, I don't have to prove he did. All of the methods you suggest are valid as would an email saying "Got the contract. I agree. Bob."
Term 1 isn't going to hold up, but that is not a GDPR matter. It's just a matter of basic consumer protection law in the EU. You can't offload responsibility for your mistakes. Looking at 2, Dale M. already pointer out that it's now how the GDPR works. You are the Data Controller. X,Y and Z are Data Processors. Article 28(1) of the GDPR is in direct conflict with your disclaimer. You accept zero responsibility, the GDPR says you are fully responsible. That's the exact opposite.