Talk:Distributed OS: Winter 2011 - Revision history

Mike Preston: /* End User Bandwidth Management */

2011-02-09T16:16:03Z

End User Bandwidth Management

← Older revision		Revision as of 16:16, 9 February 2011
Line 11:		Line 11:

	My idea (continuing the countries analogy) is that every piece of software would execute with a "passport" representing key information about the software executing. At this point, based on the "passport" information, domains can deny or limit the ability of software to interact. For example, if a user runs an application, then their "stamp", along with their domain "stamp" and system "stamp" would become a part of that application's passport. Any domain or system can reference the signature's origin and verify it's authenticity (think of public key encryption, but every domain/person/system has its own key server). If a part of the passport is fraudulent or unverifiable then the communication or work can be rejected. If one system becomes a source of malware, then that system, user, or domain passport "stamp" can be rejected. The more legitimate "stamps" a piece of software has, the more trusted the software may be. Every domain can decide which passport stamps to accept, and which to reject. Even if a portion of a passport is fraudulent, the fraud can be detected and the information regarding untrusted passport information can be circulated between trusted peer domains. This proposed system would inherently prevent malware from spreading, because after a piece of malware was discovered, it's passport could be rejected. A continued source of malware could also be rejected.		My idea (continuing the countries analogy) is that every piece of software would execute with a "passport" representing key information about the software executing. At this point, based on the "passport" information, domains can deny or limit the ability of software to interact. For example, if a user runs an application, then their "stamp", along with their domain "stamp" and system "stamp" would become a part of that application's passport. Any domain or system can reference the signature's origin and verify it's authenticity (think of public key encryption, but every domain/person/system has its own key server). If a part of the passport is fraudulent or unverifiable then the communication or work can be rejected. If one system becomes a source of malware, then that system, user, or domain passport "stamp" can be rejected. The more legitimate "stamps" a piece of software has, the more trusted the software may be. Every domain can decide which passport stamps to accept, and which to reject. Even if a portion of a passport is fraudulent, the fraud can be detected and the information regarding untrusted passport information can be circulated between trusted peer domains. This proposed system would inherently prevent malware from spreading, because after a piece of malware was discovered, it's passport could be rejected. A continued source of malware could also be rejected.

	~~== End User Bandwidth Management ==~~

	~~New Page~~

Mike Preston: /* End User Bandwidth Management */ new section

2011-02-09T16:15:47Z

End User Bandwidth Management: new section

← Older revision		Revision as of 16:15, 9 February 2011
Line 11:		Line 11:

	My idea (continuing the countries analogy) is that every piece of software would execute with a "passport" representing key information about the software executing. At this point, based on the "passport" information, domains can deny or limit the ability of software to interact. For example, if a user runs an application, then their "stamp", along with their domain "stamp" and system "stamp" would become a part of that application's passport. Any domain or system can reference the signature's origin and verify it's authenticity (think of public key encryption, but every domain/person/system has its own key server). If a part of the passport is fraudulent or unverifiable then the communication or work can be rejected. If one system becomes a source of malware, then that system, user, or domain passport "stamp" can be rejected. The more legitimate "stamps" a piece of software has, the more trusted the software may be. Every domain can decide which passport stamps to accept, and which to reject. Even if a portion of a passport is fraudulent, the fraud can be detected and the information regarding untrusted passport information can be circulated between trusted peer domains. This proposed system would inherently prevent malware from spreading, because after a piece of malware was discovered, it's passport could be rejected. A continued source of malware could also be rejected.		My idea (continuing the countries analogy) is that every piece of software would execute with a "passport" representing key information about the software executing. At this point, based on the "passport" information, domains can deny or limit the ability of software to interact. For example, if a user runs an application, then their "stamp", along with their domain "stamp" and system "stamp" would become a part of that application's passport. Any domain or system can reference the signature's origin and verify it's authenticity (think of public key encryption, but every domain/person/system has its own key server). If a part of the passport is fraudulent or unverifiable then the communication or work can be rejected. If one system becomes a source of malware, then that system, user, or domain passport "stamp" can be rejected. The more legitimate "stamps" a piece of software has, the more trusted the software may be. Every domain can decide which passport stamps to accept, and which to reject. Even if a portion of a passport is fraudulent, the fraud can be detected and the information regarding untrusted passport information can be circulated between trusted peer domains. This proposed system would inherently prevent malware from spreading, because after a piece of malware was discovered, it's passport could be rejected. A continued source of malware could also be rejected.

			== End User Bandwidth Management ==

			New Page

Dbarrera at 18:13, 20 January 2011

2011-01-20T18:13:46Z

← Older revision		Revision as of 18:13, 20 January 2011
Line 3:		Line 3:

	Ideas:		Ideas:
	*Multiple control/chokepoints where malware is looked for. This way, it's more difficult for attackers to take over several control points and for malware to remain unnoticed.
	*Heterogeneous systems help limit the spread of malware too. There's 2 points here. (1) If we're designing this system where we're all masters of our own domains, then we're likely to have different system configurations. However (2), if we want to communicate and interact with other domains, we need some standardized communication layer or mechanism. Standardization is very closely tied to homogeneous.
	*There should be consequences if you harbor malware or if malware originates from within your domain. This could be and incentive to help people be more proactive in terms of security.

Tgelowsk: /* 3: Limiting the spread of malware */

2011-01-20T13:07:08Z

3: Limiting the spread of malware

← Older revision		Revision as of 13:07, 20 January 2011
Line 8:		Line 8:


	System Proposal:		System Proposal (TG):

	In this case, what exactly do we look for? Malware is just another piece of software, especially in an internet-scale operating system. "Attackers" are just users with malicious intent.		In this case, what exactly do we look for? Malware is just another piece of software, especially in an internet-scale operating system. "Attackers" are just users with malicious intent.

	My idea (continuing the countries analogy) is that every piece of software would execute with a "passport" representing key information about the software executing. At this point, based on the "passport" information, domains can deny or limit the ability of software to interact. For example, if a user runs an application, then their "stamp", along with their domain "stamp" and system "stamp" would become a part of that application's passport. Any domain or system can reference the signature's origin and verify it's authenticity (think of public key encryption, but every domain/person/system has its own key server). If a part of the passport is fraudulent or unverifiable then the communication or work can be rejected. If one system becomes a source of malware, then that system, user, or domain passport "stamp" can be rejected. The more legitimate "stamps" a piece of software has, the more trusted the software may be. Every domain can decide which passport stamps to accept, and which to reject. Even if a portion of a passport is fraudulent, the fraud can be detected and the information regarding untrusted passport information can be circulated between trusted peer domains. This proposed system would inherently prevent malware from spreading, because after a piece of malware was discovered, it's passport could be rejected. A continued source of malware could also be rejected.		My idea (continuing the countries analogy) is that every piece of software would execute with a "passport" representing key information about the software executing. At this point, based on the "passport" information, domains can deny or limit the ability of software to interact. For example, if a user runs an application, then their "stamp", along with their domain "stamp" and system "stamp" would become a part of that application's passport. Any domain or system can reference the signature's origin and verify it's authenticity (think of public key encryption, but every domain/person/system has its own key server). If a part of the passport is fraudulent or unverifiable then the communication or work can be rejected. If one system becomes a source of malware, then that system, user, or domain passport "stamp" can be rejected. The more legitimate "stamps" a piece of software has, the more trusted the software may be. Every domain can decide which passport stamps to accept, and which to reject. Even if a portion of a passport is fraudulent, the fraud can be detected and the information regarding untrusted passport information can be circulated between trusted peer domains. This proposed system would inherently prevent malware from spreading, because after a piece of malware was discovered, it's passport could be rejected. A continued source of malware could also be rejected.

Tgelowsk: /* 3: Limiting the spread of malware */

2011-01-20T03:06:19Z

3: Limiting the spread of malware

← Older revision		Revision as of 03:06, 20 January 2011
Line 1:		Line 1:
	===3: Limiting the spread of malware===		===3: Limiting the spread of malware===
	Group members: keith, Andrew, David Barrera		Group members: keith, Andrew, David Barrera, Trevor Gelowsky

	Ideas:		Ideas:
Line 6:		Line 6:
	*Heterogeneous systems help limit the spread of malware too. There's 2 points here. (1) If we're designing this system where we're all masters of our own domains, then we're likely to have different system configurations. However (2), if we want to communicate and interact with other domains, we need some standardized communication layer or mechanism. Standardization is very closely tied to homogeneous.		*Heterogeneous systems help limit the spread of malware too. There's 2 points here. (1) If we're designing this system where we're all masters of our own domains, then we're likely to have different system configurations. However (2), if we want to communicate and interact with other domains, we need some standardized communication layer or mechanism. Standardization is very closely tied to homogeneous.
	*There should be consequences if you harbor malware or if malware originates from within your domain. This could be and incentive to help people be more proactive in terms of security.		*There should be consequences if you harbor malware or if malware originates from within your domain. This could be and incentive to help people be more proactive in terms of security.


			System Proposal:

			In this case, what exactly do we look for? Malware is just another piece of software, especially in an internet-scale operating system. "Attackers" are just users with malicious intent.

			My idea (continuing the countries analogy) is that every piece of software would execute with a "passport" representing key information about the software executing. At this point, based on the "passport" information, domains can deny or limit the ability of software to interact. For example, if a user runs an application, then their "stamp", along with their domain "stamp" and system "stamp" would become a part of that application's passport. Any domain or system can reference the signature's origin and verify it's authenticity (think of public key encryption, but every domain/person/system has its own key server). If a part of the passport is fraudulent or unverifiable then the communication or work can be rejected. If one system becomes a source of malware, then that system, user, or domain passport "stamp" can be rejected. The more legitimate "stamps" a piece of software has, the more trusted the software may be. Every domain can decide which passport stamps to accept, and which to reject. Even if a portion of a passport is fraudulent, the fraud can be detected and the information regarding untrusted passport information can be circulated between trusted peer domains. This proposed system would inherently prevent malware from spreading, because after a piece of malware was discovered, it's passport could be rejected. A continued source of malware could also be rejected.

Dbarrera: Created page with "===3: Limiting the spread of malware=== Group members: keith, Andrew, David Barrera Ideas: *Multiple control/chokepoints where malware is looked for. This way, it's more diffic…"

2011-01-19T18:49:23Z

Created page with "===3: Limiting the spread of malware=== Group members: keith, Andrew, David Barrera Ideas: *Multiple control/chokepoints where malware is looked for. This way, it's more diffic…"

New page

===3: Limiting the spread of malware===
Group members: keith, Andrew, David Barrera

Ideas:
*Multiple control/chokepoints where malware is looked for. This way, it's more difficult for attackers to take over several control points and for malware to remain unnoticed.
*Heterogeneous systems help limit the spread of malware too. There's 2 points here. (1) If we're designing this system where we're all masters of our own domains, then we're likely to have different system configurations. However (2), if we want to communicate and interact with other domains, we need some standardized communication layer or mechanism. Standardization is very closely tied to homogeneous.
*There should be consequences if you harbor malware or if malware originates from within your domain. This could be and incentive to help people be more proactive in terms of security.