Aaron projects/CFAA - Revision history

66.31.46.165 at 01:59, 10 January 2014

2014-01-10T01:59:12Z

← Older revision		Revision as of 18:59, 9 January 2014
Line 3:		Line 3:
	Draft outline of replacement law underway</center>		Draft outline of replacement law underway</center>

	;Goal: Let's ~~prepare for~~ a full repeal of the CFAA[http://www.law.cornell.edu/uscode/text/18/1030] ~~and replacement with sane law~~.		;Goal: Let's decsribe what a full repeal & replacement of the CFAA[http://www.law.cornell.edu/uscode/text/18/1030] should look like.
	;Questions: How would we construct good law in these areas, from scratch?		;Questions: How would we construct good law in these areas, from scratch?
	: How do different areas of law, policy, and internet governance view the law and its impact?		: How do different areas of law, policy, and internet governance view the law and its impact?

66.31.46.165 at 00:17, 16 November 2013

2013-11-16T00:17:04Z

← Older revision		Revision as of 17:17, 15 November 2013
Line 120:		Line 120:
	: This tends to be pretty bad. It's clearly defeating the system, when it requires finding a subtle exploit		: This tends to be pretty bad. It's clearly defeating the system, when it requires finding a subtle exploit
	: Can be less bad when a system has an auth system but doesn't use it (e.g. it's never checked)		: Can be less bad when a system has an auth system but doesn't use it (e.g. it's never checked)


	; What's the ECTF doing? Who could provide oversight?		; What's the ECTF doing? Who could provide oversight?
	: (cf [http://www.technewsdaily.com/16445-fix-hacking-laws.html fix-hacking-laws essay] and Robert Graham's comment)		: (cf [http://www.technewsdaily.com/16445-fix-hacking-laws.html fix-hacking-laws essay] and Robert Graham's comment)

			; Do MIT and other tech institutions care?
			: See [http://swartz-review.mit.edu/node/284 this question] on MIT's Swartz Review site.

	== Active proposals ==		== Active proposals ==

199.188.193.111 at 23:05, 9 November 2013

2013-11-09T23:05:04Z

← Older revision		Revision as of 16:05, 9 November 2013
Line 3:		Line 3:
	Draft outline of replacement law underway</center>		Draft outline of replacement law underway</center>

	;Goal: Let's prepare for a full repeal of the CFAA and replacement with sane law.		;Goal: Let's prepare for a full repeal of the CFAA[http://www.law.cornell.edu/uscode/text/18/1030] and replacement with sane law.
	;Questions: How would we construct good law in these areas, from scratch?		;Questions: How would we construct good law in these areas, from scratch?
	: How do different areas of law, policy, and internet governance view the law and its impact?		: How do different areas of law, policy, and internet governance view the law and its impact?

Sj: /* Scenarios */

2013-11-09T22:49:20Z

Scenarios

← Older revision		Revision as of 15:49, 9 November 2013
Line 160:		Line 160:

	== Scenarios ==		== Scenarios ==
	: ''Add yours below''		: ''Add yours below:''

	* ''War Games'' scenario: someone breaks into a secured machine, accesses government secrets, and uses them to wreak havoc		* ''War Games'' scenario: someone breaks into a secured machine, accesses government secrets, and uses them to wreak havoc
Line 170:		Line 170:
	* Using Access to Perform Identity Theft: Nonaurtorized access & distribution of personal or financial information by authorized users exceeding their granted access rights.		* Using Access to Perform Identity Theft: Nonaurtorized access & distribution of personal or financial information by authorized users exceeding their granted access rights.
	* Worm introduction: Engineering or introducing code to enable access to unauthorized data via autoreplication & propagation.		* Worm introduction: Engineering or introducing code to enable access to unauthorized data via autoreplication & propagation.
			* ...

70.192.4.215: /* Scenarios */

2013-11-09T22:19:50Z

Scenarios

← Older revision		Revision as of 15:19, 9 November 2013
Line 169:		Line 169:
	* Pseudonym Use/Fake Persona: Creating one or more access accounts using pseudonyms/manufactured persona in breach of website or service EULA.		* Pseudonym Use/Fake Persona: Creating one or more access accounts using pseudonyms/manufactured persona in breach of website or service EULA.
	* Using Access to Perform Identity Theft: Nonaurtorized access & distribution of personal or financial information by authorized users exceeding their granted access rights.		* Using Access to Perform Identity Theft: Nonaurtorized access & distribution of personal or financial information by authorized users exceeding their granted access rights.
	* Worm introduction: Engineering or introducing code ~~that~~ enable access to unauthorized data via autoreplication & propagation.		* Worm introduction: Engineering or introducing code to enable access to unauthorized data via autoreplication & propagation.

70.192.4.215: /* Scenarios */

2013-11-09T22:19:16Z

Scenarios

← Older revision		Revision as of 15:19, 9 November 2013
Line 164:		Line 164:
	* ''War Games'' scenario: someone breaks into a secured machine, accesses government secrets, and uses them to wreak havoc		* ''War Games'' scenario: someone breaks into a secured machine, accesses government secrets, and uses them to wreak havoc
	* Rooting a box: Someone finds a way to log into a server, has a way to gain root on the server, and executes arbitrary code on it.		* Rooting a box: Someone finds a way to log into a server, has a way to gain root on the server, and executes arbitrary code on it.
	* DDOS: Someone finds a way to overload a server by using its public services very frequently, causing it to be ~~unavaiable~~ for days.		* DDOS: Someone finds a way to overload a server by using its public services very frequently, causing it to be unavailable for days.
	* ~~[Swartz case]~~		* Social Engineering: Someone gaining access to systems via confidence approach or subterfuge.
	* ~~[Morris case]~~		* Access Credential Sharing: Sharing commercially acquired user credentials with others (i.e. Netflix login).
	* ~~[Scenarios~~ of ~~other existing CFAA cases? Wikipedia lists "notable cases" here~~: ~~http~~:~~//en~~.~~wikipedia.org/wiki/Computer_Fraud_and_Abuse_Act#Notable_cases_and_decisions_referring_to_the_Act]~~		* Pseudonym Use/Fake Persona: Creating one or more access accounts using pseudonyms/manufactured persona in breach of website or service EULA.
			* Using Access to Perform Identity Theft: Nonaurtorized access & distribution of personal or financial information by authorized users exceeding their granted access rights.
			* Worm introduction: Engineering or introducing code that enable access to unauthorized data via autoreplication & propagation.

Sellars: /* What should be unlawful */

2013-11-09T21:56:37Z

What should be unlawful

← Older revision		Revision as of 14:56, 9 November 2013
Line 98:		Line 98:
	* '''Exploiting a code-based vulnerability to obtain information''' should be unlawful (leaving proportionality for another discussion). We are thinking of things like a SQL injection hack.		* '''Exploiting a code-based vulnerability to obtain information''' should be unlawful (leaving proportionality for another discussion). We are thinking of things like a SQL injection hack.

	* '''Knowingly deleting or impairing the integrity of the ~~work~~''' should be unlawful if done intentionally or recklessly. Moving down to negligence or strict liability at a certain damage threshold is harder to say.		* '''Knowingly deleting or impairing the integrity or availability of the data''' should be unlawful if done intentionally or recklessly. Moving down to negligence or strict liability at a certain damage threshold is harder to say.

	==== Uncertain areas ====		==== Uncertain areas ====

18.85.25.202: /* Scenarios */

2013-11-09T21:45:46Z

Scenarios

← Older revision		Revision as of 14:45, 9 November 2013
Line 167:		Line 167:
	* [Swartz case]		* [Swartz case]
	* [Morris case]		* [Morris case]
	* [~~List~~ of ~~all~~ CFAA cases?]		* [Scenarios of other existing CFAA cases? Wikipedia lists "notable cases" here: http://en.wikipedia.org/wiki/Computer_Fraud_and_Abuse_Act#Notable_cases_and_decisions_referring_to_the_Act]

Sj: /* Points of consensus */

2013-11-09T21:41:08Z

Points of consensus

← Older revision		Revision as of 14:41, 9 November 2013
Line 83:		Line 83:
	** we feel as though there is sufficient persistent identity in the community that even pseudonymous hackers care about their reputations.		** we feel as though there is sufficient persistent identity in the community that even pseudonymous hackers care about their reputations.

	* '''~~focus~~ on bad ''access'', leave ''use'' to other laws''' - laws on copyright, trade secret, identity theft, espionage, extortion, and fraud govern most of the "scary" use cases.		* '''Focus on bad ''access'', leave ''use'' to other laws''' - laws on copyright, trade secret, identity theft, espionage, extortion, and fraud govern most of the "scary" use cases.
	** In this way, we are leaving the "hats" (black/white/grey/green) discussion for the community norms or existing law.		** In this way, we are leaving the "hats" (black/white/grey/green) discussion for the community norms or existing law.

	* '''Consent should always be a defense''' - server owners ask members of the public to do some weird stuff against their systems, but as long as they ask for it, it should never be a crime to access one's computer in that way.		* '''Consent should always be a defense''' - server owners ask members of the public to do some weird stuff against their systems, but as long as they ask for it, it should never be a crime to access one's computer in that way.

	* ~~As to~~ code-based vulnerabilities and authentication measures, ~~'''some level of technical effectiveness should be considered.''' A~~ "reasonable" standard may not be appropriate~~, as~~ defining what is "reasonable" may lead to unnecessary confusion. But some consideration should be made to ensure that trivially-overcome measures are not ~~considered~~ within the scope.		* '''Consider technical effectiveness of site design''' for its intended use. For code-based vulnerabilities and authentication measures, a "reasonable" standard may not be appropriate: defining what is "reasonable" may lead to unnecessary confusion. But some consideration should be made to ensure that trivially-overcome measures are not within the scope.

	==== What should be unlawful ====		==== What should be unlawful ====
	* '''~~hold~~ the party intending to do the bad behavior culpable~~'''~~ - ~~don't track liability to a person whose computer was unwittingly used to commit the crime.~~		* '''Setting up and triggering an exploit''' - even if it was not done on that person's computer. Hold the party intending to do the bad behavior culpable. [ex: sharing a tinyurl that carries out a sql-injection]

	* '''Circumvention of a code-based authentication measure''' ~~should be unlawful (~~leaving proportionality for another discussion). This includes cracking, password guessing, or human-engineering password disclosure.		* '''Circumvention of a code-based authentication measure''' - leaving proportionality for another discussion. This includes cracking, password guessing, or human-engineering password disclosure.
			*: Once we get to this set of actions, we're in fraud-land. [this still shouldn't be penalized more than non-electronic fraud]

	* '''Exploiting a code-based vulnerability to obtain information''' should be unlawful (leaving proportionality for another discussion). We are thinking of things like a SQL injection hack.		* '''Exploiting a code-based vulnerability to obtain information''' should be unlawful (leaving proportionality for another discussion). We are thinking of things like a SQL injection hack.
Line 100:		Line 101:

	==== Uncertain areas ====		==== Uncertain areas ====
	* '''~~penetration~~ testing''' is squishy ~~- an~~ open call for bug bounties should be treated ~~like~~ consent to access the site (again, using laws govern bad uses)		* '''Penetration testing''' is squishy. An open call for bug bounties should be treated as consent to access the site (again, using other laws to govern bad uses)

	* '''"accidentally open" sites are squishy''' - e.g., sites that were supposed to be behind an authentication layer but are not. To a certain extent, it may be best to place the fault of this onto the coder of the site, with the comfort that certain uses by the obtainer of information may still be unlawful.

			* '''"Obtaining information from accidentally-open" sites''' is squishy. E.g., sites that were supposed to be behind an authentication layer but are not. To a certain extent, it may be best to place the fault of this onto the coder of the site, with the comfort that certain uses by the obtainer of information may still be unlawful.

	=== Open questions ===		=== Open questions ===

18.85.25.202: /* Scenarios */

2013-11-09T21:36:39Z

Scenarios

← Older revision		Revision as of 14:36, 9 November 2013
Line 165:		Line 165:
	* Rooting a box: Someone finds a way to log into a server, has a way to gain root on the server, and executes arbitrary code on it.		* Rooting a box: Someone finds a way to log into a server, has a way to gain root on the server, and executes arbitrary code on it.
	* DDOS: Someone finds a way to overload a server by using its public services very frequently, causing it to be unavaiable for days.		* DDOS: Someone finds a way to overload a server by using its public services very frequently, causing it to be unavaiable for days.
			* [Swartz case]
			* [Morris case]
			* [List of all CFAA cases?]