Distributed Social Networking - Revision history

Adamcolton: /* Local VM */

2013-11-11T20:56:07Z

Local VM

← Older revision		Revision as of 20:56, 11 November 2013
Line 66:		Line 66:

	This can then be matched with "trust services" (something that will be required anyway) to establish how trust-worthy an application (and the server's it's going through) is.		This can then be matched with "trust services" (something that will be required anyway) to establish how trust-worthy an application (and the server's it's going through) is.

			For getting a prototype running, there are several "security sandbox" options. I want to focus on building a security sandbox

	== 5/3/2013 Notes ==		== 5/3/2013 Notes ==

Adamcolton at 16:22, 7 November 2013

2013-11-07T16:22:49Z

← Older revision		Revision as of 16:22, 7 November 2013
Line 61:		Line 61:
	== Advertising ==		== Advertising ==
	From a technical standpoint, this does not require it's own section, it will operate just like everything else. But because this is currently the dominant model (and what I want to break) I will address it directly. Advertisements are fine, but the consumer should know they're being advertised to and what they get in return. Ad models (and tracking models) should be opt-in.		From a technical standpoint, this does not require it's own section, it will operate just like everything else. But because this is currently the dominant model (and what I want to break) I will address it directly. Advertisements are fine, but the consumer should know they're being advertised to and what they get in return. Ad models (and tracking models) should be opt-in.

			== Local VM ==
			The web browser has kind of become a nightmare. I propose using a sort of VM (as in JVM). The application requests a VM based on a security model. So any application can get an ephemeral, limited instance because it would be difficult (hopefully impossible) to run an attack that way. An application can make specific security requests - sandbox local storage, clipboard, microphone, camera, open user specified files (through a dialog box), unfettered access to the hard drive (probably only for trusted applications).

			This can then be matched with "trust services" (something that will be required anyway) to establish how trust-worthy an application (and the server's it's going through) is.

	== 5/3/2013 Notes ==		== 5/3/2013 Notes ==

Adamcolton at 16:43, 19 August 2013

2013-08-19T16:43:38Z

← Older revision		Revision as of 16:43, 19 August 2013
Line 1:		Line 1:
	See [[Service ~~Orient~~ Network]]		See [[Service Oriented Network]]

	A protocol for social networking so that data can be decentralized.		A protocol for social networking so that data can be decentralized.

Adamcolton at 16:35, 19 August 2013

2013-08-19T16:35:11Z

← Older revision		Revision as of 16:35, 19 August 2013
Line 1:		Line 1:
			See [[Service Orient Network]]

	A protocol for social networking so that data can be decentralized.		A protocol for social networking so that data can be decentralized.

Adamcolton: /* Core Components */

2013-07-30T15:49:07Z

Core Components

← Older revision		Revision as of 15:49, 30 July 2013
Line 13:		Line 13:

	== Core Components ==		== Core Components ==
	* Servers: Represented by a ~~URL~~, data lives here		* Servers: Represented by a IPv6 address, data lives here
	* Users: This is the core representation of a user. A public/private key		* Users: This is the core representation of a user. A public/private key
	* User-Data: Data owned by the users. SERVERS DO NOT OWN DATA, they hold it		* User-Data: Data owned by the users. SERVERS DO NOT OWN DATA, they hold it

Adamcolton: /* Principles */

2013-07-30T15:48:27Z

Principles

← Older revision		Revision as of 15:48, 30 July 2013
Line 4:		Line 4:

	== Principles ==		== Principles ==
	* Al carte : Everyone pays for what they use. No ads, no subscriptions, no piracy.		* A la carte : Everyone pays for what they use. No ads, no subscriptions, no piracy.
	* Users control their data : Data does not reside with the application - it resides with the user. Services have to share data and users can take their data elsewhere if they're unhappy with a service - no hostages.		* Users control their data : Data does not reside with the application - it resides with the user. Services have to share data and users can take their data elsewhere if they're unhappy with a service - no hostages.
	* Security and privacy : You never have to disclose a real identity, you control who has access to what information. Systems use the correct level of encryption for the task at hand - the only time something is unencrypted is when it is meant for broadcast.		* Security and privacy : You never have to disclose a real identity, you control who has access to what information. Systems use the correct level of encryption for the task at hand - the only time something is unencrypted is when it is meant for broadcast.

Adamcolton at 15:47, 30 July 2013

2013-07-30T15:47:58Z

← Older revision		Revision as of 15:47, 30 July 2013
Line 75:		Line 75:

	Software is - fundamentally - a public good. We may be able to solve this with privileged groups, specifically, the application and database servers. Developers can setups "shops" that are funded by the application servers. The application servers make it publicly known when they are supporting a shop. The shops would have an implicit reputation based on the software they have developed. It may be that public pressure would keep the application and database servers funding the shops, but were that to collapse, it would be very difficult to re-establish.		Software is - fundamentally - a public good. We may be able to solve this with privileged groups, specifically, the application and database servers. Developers can setups "shops" that are funded by the application servers. The application servers make it publicly known when they are supporting a shop. The shops would have an implicit reputation based on the software they have developed. It may be that public pressure would keep the application and database servers funding the shops, but were that to collapse, it would be very difficult to re-establish.

			== Authentication and Key Management ==
			This would not be a part of the spec, but it is important to demonstrate that workable solutions exist within the space.

			There are a few problems that need to be addressed that arise out of naive users:
			# Multiple devices
			# Using a device you don't own
			# Losing a key file

			== Username Password Authentication ==
			This is of course the least secure and we can encourage people to not use it. But it is comfortable and familiar and better than nothing. Under this scheme, a private key file would entrusted to an identity server and you could gain access to it by giving the correct username and password.

			== Device Authentication ==
			A take on two factor authentication - a device that can be uniquely identified (most likely a phone) serves as a form of identification and you can only proceed using that device.

			== Local Authentication Server ==
			Using a phone or tablet with wifi or bluetooth, the device becomes the authentication server after establishing a connection to the non-owned device.

			== Social Network Backup ==
			A copy of a master key is encrypted with '''A''' producing file '''B'''. '''B''' is stored in an accessible place (storage server), and '''A''' is distributed among a social network. To recover the original master key, the individual must identify themselves to the members of the network (in person, over the phone, or some audio/visual IP method) who can authenticate their identity. When enough pieces are reconstituted, the key is recovered.


	== 5/14/2013 Notes ==		== 5/14/2013 Notes ==

Adamcolton at 13:38, 12 June 2013

2013-06-12T13:38:08Z

← Older revision		Revision as of 13:38, 12 June 2013
Line 4:		Line 4:

	== Principles ==		== Principles ==
	* ~~Mobility~~: ~~At any point you can change your server without losing data or connections~~, ~~much like the telephone network~~. ~~You should even be able to use different services from different servers~~		* Al carte : Everyone pays for what they use. No ads, no subscriptions, no piracy.
	* ~~Service as Pig~~: ~~"In any transaction, there are 3 parties~~ - the ~~farmer, the butcher~~ and ~~the pig. If you~~'re ~~not the farmer or the butcher...". Services are paid for by the consumer. See advertising~~.		* Users control their data : Data does not reside with the application - it resides with the user. Services have to share data and users can take their data elsewhere if they're unhappy with a service - no hostages.
	* Security: ~~All data will be secured. Security models will be explicit.~~		* Security and privacy : You never have to disclose a real identity, you control who has access to what information. Systems use the correct level of encryption for the task at hand - the only time something is unencrypted is when it is meant for broadcast.
	* Privacy: To the extent that it is possible. Once you share something with another party, you ~~cannot prevent them from sharing it further. But you will have absolute~~ control ~~over~~ who ~~can~~ access ~~your data~~.
	* Ownership: You own your data.

			=== Axioms ===
			* Most components are honest most of the time
			* Most components are naive most of the time

	== Core Components ==		== Core Components ==

Adamcolton: /* 5/14/2013 Notes */

2013-05-14T19:02:53Z

5/14/2013 Notes

← Older revision		Revision as of 19:02, 14 May 2013
Line 80:		Line 80:
	=== Rebuilding The Browser ===		=== Rebuilding The Browser ===
	One thing I keep waffling on is rebuilding the browser. It would increase the magnitude of the project significantly, but the current state of browsers kind of sucks. Rather than the current model, I was thinking of something far more of a sandbox model. One of the major barriers I see is the 'same origin' policy, which is just goofy at this point (and easily circumvented). I would also like to transition from the classic request model to a full socket model. It wouldn't invalidate the old way - a server could connect, deliver the necessary data and disconnect.		One thing I keep waffling on is rebuilding the browser. It would increase the magnitude of the project significantly, but the current state of browsers kind of sucks. Rather than the current model, I was thinking of something far more of a sandbox model. One of the major barriers I see is the 'same origin' policy, which is just goofy at this point (and easily circumvented). I would also like to transition from the classic request model to a full socket model. It wouldn't invalidate the old way - a server could connect, deliver the necessary data and disconnect.

			=== Copyright Enforcement ===
			One of the issues raised above is getting payment to app developers. There are two ways in which this can be violated. The first is an app-server running the application without paying dues. The other is someone taking the source and repackaging it as their own.

			To combat app-server piracy, app-servers would have reputation and theft would damage their reputation.

			To combat payment theft, apps would be registered with app servers (by hash). If someone were to perform this form of theft, it could be demonstrated that their repository was more recent than the one they stole. It would then be marked pirated, the origin would be referenced and their reputation would be damaged.

			The final problem, particularly difficult, is the combination of the two. An app-server (actually, the operator) could pirate a repository and pocket all the money. When called out, they shut down the repository and repeat with a new app. They can repeat this indefinitely.

	[[Category:Code]]		[[Category:Code]]

Adamcolton: /* 5/3/2013 Notes */

2013-05-14T18:30:01Z

5/3/2013 Notes

← Older revision		Revision as of 18:30, 14 May 2013
Line 74:		Line 74:

	Software is - fundamentally - a public good. We may be able to solve this with privileged groups, specifically, the application and database servers. Developers can setups "shops" that are funded by the application servers. The application servers make it publicly known when they are supporting a shop. The shops would have an implicit reputation based on the software they have developed. It may be that public pressure would keep the application and database servers funding the shops, but were that to collapse, it would be very difficult to re-establish.		Software is - fundamentally - a public good. We may be able to solve this with privileged groups, specifically, the application and database servers. Developers can setups "shops" that are funded by the application servers. The application servers make it publicly known when they are supporting a shop. The shops would have an implicit reputation based on the software they have developed. It may be that public pressure would keep the application and database servers funding the shops, but were that to collapse, it would be very difficult to re-establish.

			== 5/14/2013 Notes ==
			I was listening to Jaron Lanier and he raised some interesting points about where the current models are heading. I still feel like I'm close, but I'm missing my "Block Chain" breakthrough.

			=== Rebuilding The Browser ===
			One thing I keep waffling on is rebuilding the browser. It would increase the magnitude of the project significantly, but the current state of browsers kind of sucks. Rather than the current model, I was thinking of something far more of a sandbox model. One of the major barriers I see is the 'same origin' policy, which is just goofy at this point (and easily circumvented). I would also like to transition from the classic request model to a full socket model. It wouldn't invalidate the old way - a server could connect, deliver the necessary data and disconnect.

	[[Category:Code]]		[[Category:Code]]