In the CFAA, what exactly do &quot;Intentionally accessed a protected computer without authorization&quot; and &quot;exceeding authorization&quot; mean? I originally looked at this for web scraping, but upon reading it more, it seems like it could be interpreted to include all types of common mistakes. Does this even include something like a customer who entered his/her personal credentials issued by representatives of the service just for him into the wrong URL on the website as an attempt to "intentionally access without authorization/exceed" even though he thought that was the correct URL, like with different pages of demo and live accounts? Can someone claim that the user intentionally tried to login regardless of good faith thinking it was the right place + right auth vs user clicks on a random button that lied and actually tried to log him in without authorization instead? Does the law anywhere says something like common day activities like this don't count? This law just seems really vague/broad in that it include a lot of reasonable mistakes.
A law has to be "broad" to include a lot of possible crimes and intent of criminals and account for the good faith of non-criminals. "Intentionally access without authorization/exceed" is actually fairly specific; "intent" is the keyword. Someone making a mistake may have intent to login, but no intent to commit a crime. Someone confused by "different pages of demo and live accounts" can easily defend their actions by pointing out that they were confused. It's up to the reasonableness of the pertinent law enforcement and prosecutors to take into account the evidence that reasonable mistakes were made by little old ladies and not charge them with a crime. And for the most part, 98% of the time, law enforcement and prosecutors are reasonable.
You are mistaken: they deny you on your act When you use Tor, your browser is not sending a lot of information. That makes Tor browsers hilariously easy to detect: nobody knows where the real browser is, but it is hilariously easy to block all Tor users for using Tor, or at least those that the server knows are Tor IPs. Using Tor is an action, not how you look. The closest Brick and mortar equivalent would be &quot;Show me your ID please&quot; and you show them a paper cutout of something that has Sample stamped over it. &quot;No shirt, no shoes, no service&quot; in the united-states Yes, most places can deny service based on how you dress or your state of hygine. These two would in most cases not extend to the protections under the Civil Rights Act, which protects some characteristics like race and sex, but not visual factors like &quot;being dressed&quot; or &quot;smelling of cow&quot;. There can be a fine line where religious dress code is concerned, but in general and broad strokes, the restaurant can deny you for wearing the wrong clothes. Actually, the slogan is much broader than it appears: as long as an establishment's dress code is not violating discrimination law (like the CRA), they can enforce it under their freedom to contract.
can it be construed as a violation of 66F clause 2 if we try to circumvent the rate limit even though the information is on public domain? No, unless the element of intent to threaten [...] or strike terror can be proved. I'm assuming that by &quot;clause 2&quot; you mean the excerpt you posted. Although circumventing the limit of API calls sounds in &quot;exceeding authorised access&quot; and might even lead to DOS, it does not imply an intent to threaten the security/sovereignty/etc. or strike terror. The statute is premised on such intent. The fact that the information(packets) is(are) on public domain is irrelevant. For instance, an intent to strike terror and/or actually causing a DOS can involve [targeting] a public domain.
Intentional sabotage of a TSA computer system is almost certainly a serious crime and would also almost surely give rise to civil liability, although you might avoid both if you warned the TSA that the phone was set up to intentionally break their system, in which case it might be confiscated as contraband. If the product had a "feature" unknown to you and that you had no reasonable reason to know of that caused the harm, you would ultimately have no criminal or civil liability, although the manufacturer might be strictly liable to the TSA under a product liability theory, and you would probably be detained as a witness to figure out what happened. If the product had a "feature" that broke the TSA computer that could be de-activated and that you meant to de-active but carelessly failed to, you would have negligence liability to the government and might or might not have criminal liability (I'm not enough of an expert in the relevant statutes to know). You might be liable for a strict liability Federal Communications Commission offense for having a device that is in violation of their regulations.
The GDPR gives controllers a lot of latitude. They must decide on the correct course of action taking into account the possible risks to data subjects. Specifically, no notification of the authority is necessary if “the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons.” In your scenario 1, you suggest that there is no breach because there is no evidence that the data was improperly accessed. This analysis is faulty: the controller is aware that the data was not properly secured, and cannot rule out that the data was improperly accessed. I would argue this fits the description of a “breach of security leading to the accidental or unlawful … unauthorised disclosure of … personal data” (compare the definition of a data breach in Art 4(12)). Thus, a data breach has happened. The question whether the supervisory authority has to be notified of that breach is more debatable. The controller must assess the likelihood of risks to the data subjects. Here, they can perhaps argue that the risk of disclosure is low. However, the nature of the breached data would also be relevant. If in doubt, the controller should make the notification. The goal of the GDPR is not to punish unlucky companies that suffer a breach, but to protect personal data. Thus, fixing mistakes and cooperating with the supervisory authorities is likely the best approach for most companies. In your second scenario, the data is sensitive – its disclosure has a high risk for data subjects. However, the risk of someone intercepting this data is debatable. Does the risk of interception balance out the sensitivity of the data? That's the data controller's call, but I don't think so. A notification would seem appropriate here. As a technical remark, simply offering HTTPS is not sufficient to prevent MitM attacks – users must be forced to use encrypted connections. If a controller sees MitM as a risk, they are required by Art 24 to take appropriate technical measures. Here HSTS and HSTS preload would prevent the connections from being downgraded to HTTP. Instead of offering insecure connections, the site would become inaccessible. A complementary strategy is to not serve content over HTTP, but have the HTTP server only issue a permanent redirect to the HTTPS URL.
It seems like some law must have been breached during the sharing of this information? Possibly, even probably. The scrutiny of your personal account in order to glean personal data (your IP address) and then using that personal data to match accounts may contravene Recital 50 of the GDPR: The processing of personal data for purposes other than those for which the personal data were initially collected should be allowed only where the processing is compatible with the purposes for which the personal data were initially collected. If the website terms which you agreed to don't include this data matching, then that processing is not lawful. The rest of Recital 50 is relevant and worth quoting in full: If the processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller, Union or Member State law may determine and specify the tasks and purposes for which the further processing should be regarded as compatible and lawful. Further processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes should be considered to be compatible lawful processing operations. The legal basis provided by Union or Member State law for the processing of personal data may also provide a legal basis for further processing. In order to ascertain whether a purpose of further processing is compatible with the purpose for which the personal data are initially collected, the controller, after having met all the requirements for the lawfulness of the original processing, should take into account, inter alia: any link between those purposes and the purposes of the intended further processing; the context in which the personal data have been collected, in particular the reasonable expectations of data subjects based on their relationship with the controller as to their further use; the nature of the personal data; the consequences of the intended further processing for data subjects; and the existence of appropriate safeguards in both the original and intended further processing operations. It seems to me that an anonymous account could reasonably expect that the &quot;further processing&quot; of data matching is not in the public interest, an exercise of official authority, scientific or historical research or statistical. There is no link between the data matching exercise and the purpose for which IP addresses are normally collected: the operation and physical security of the website. Now, it may well be that the website terms do allow this data matching to discover links between accounts, or in any case prohibit having two accounts and allow reasonable methods to discover such links. It's also possible that a court has ordered the processing (as Iñaki Viggers has mentioned. We don't have that information; but ostensibly one wouldn't normally expect a personal account to be examined in this way, and certainly wouldn't expect any link discovered to be relayed to a third party.
You violated Facebook's Terms of Service, and it's entirely within your contractual agreement with them for them to close your account. You agreed to abide by the contract you "clicked through" when you signed up and opened a Facebook account. They didn't break any laws when you broke your contract with them. You clearly broke the contract by violating the TOS. They are not breaking any laws by not restoring your account. What you see as the value of your personal or business data doesn't really mean anything; it was your choice to use Facebook in the first place, and your mistake to break the TOS. You could try hiring a lawyer to make a case that you see a difference between the personal data you want to retrieve and the business data that caused the violation, but that's up to you; Facebook is under no legal obligation (this could be different, according to your jurisdiction and national laws) to restore any or all access to your account or data, but it's possible they could be persuaded.
No. That is spelled out pretty clear in Article 11. In fact, if you want follow accepted data minimisation principles (and you should), you should not log anything about cookies at your or a third party's website.