Talk:Object-capability languages - Revision history

Kosik at 09:14, 15 April 2011

Kosik — Fri, 15 Apr 2011 09:14:32 GMT

New page

Why do you think Erlang is "almost an object-capability language"? I think, it is an example of programming languages that is "not and far from being an object-capability language". Systems written in Erlang have all or nothing security. The whole system written in Erlang is as secure as its most malicious component. It is not possible to fix this straightforwardly. The language nature would have to change. Designations of processes are not capabilities (but guessable integers). Designations of functions are not capabilities (but atoms and you can freely convert between arbitrary strings and atoms. You can freely forge any atom). The permission to call a function are set by a poor module system. Erlang supports "hot code swapping" (or some similar term) which gives attacker (from untrusted subsystem) an authority to replace any code anywhere in the system. There are many holes in Erlang. I am skeptical. [[User:Kosik|Kosik]] 03:50, 2 April 2009 (CDT)

I did not dig deeper, but Scala might be also an object-capability programming language.
[[User:Kosik|Kosik]] 11:20, 14 April 2011 (CDT)

It might be also worthwhile analyze Lua and describe why it is or it is not an object-capability programming language.
[[User:Kosik|Kosik]] 04:14, 15 April 2011 (CDT)

Kosik at 16:20, 14 April 2011

Kosik — Thu, 14 Apr 2011 16:20:58 GMT

←Older revision		Revision as of 16:20, 14 April 2011
Line 1:		Line 1:
	Why do you think Erlang is "almost an object-capability language"? I think, it is an example of programming languages that is "not and far from being an object-capability language". Systems written in Erlang have all or nothing security. The whole system written in Erlang is as secure as its most malicious component. It is not possible to fix this straightforwardly. The language nature would have to change. Designations of processes are not capabilities (but guessable integers). Designations of functions are not capabilities (but atoms and you can freely convert between arbitrary strings and atoms. You can freely forge any atom). The permission to call a function are set by a poor module system. Erlang supports "hot code swapping" (or some similar term) which gives attacker (from untrusted subsystem) an authority to replace any code anywhere in the system. There are many holes in Erlang. I am skeptical. [[User:Kosik\|Kosik]] 03:50, 2 April 2009 (CDT)		Why do you think Erlang is "almost an object-capability language"? I think, it is an example of programming languages that is "not and far from being an object-capability language". Systems written in Erlang have all or nothing security. The whole system written in Erlang is as secure as its most malicious component. It is not possible to fix this straightforwardly. The language nature would have to change. Designations of processes are not capabilities (but guessable integers). Designations of functions are not capabilities (but atoms and you can freely convert between arbitrary strings and atoms. You can freely forge any atom). The permission to call a function are set by a poor module system. Erlang supports "hot code swapping" (or some similar term) which gives attacker (from untrusted subsystem) an authority to replace any code anywhere in the system. There are many holes in Erlang. I am skeptical. [[User:Kosik\|Kosik]] 03:50, 2 April 2009 (CDT)
		+
		+	I did not dig deeper, but Scala might be also an object-capability programming language.
		+	[[User:Kosik\|Kosik]] 11:20, 14 April 2011 (CDT)

Kosik at 16:05, 24 July 2009

Kosik — Fri, 24 Jul 2009 16:05:58 GMT

←Older revision		Revision as of 16:05, 24 July 2009
Line 1:		Line 1:
-	Why do you think Erlang is "almost an object-capability language"? I think, it is an example of programming languages that is "not and far from being an object-capability language". Systems written in Erlang have all or nothing security. The whole system written in Erlang is as secure as its most malicious component. It is not possible to fix this straightforwardly. The language nature would have to change. Designations of processes are not capabilities (but guessable integers). Designations of functions are not ~~integers~~ (but atoms and you can freely convert between arbitrary strings and atoms. You can freely ~~invent atoms~~). The permission to call a function are set by a poor module system. Erlang supports "hot code swapping" (or some similar term) which gives attacker (from untrusted subsystem) an authority to replace any code anywhere in the system. There are many holes in Erlang. I am skeptical. [[User:Kosik\|Kosik]] 03:50, 2 April 2009 (CDT)	+	Why do you think Erlang is "almost an object-capability language"? I think, it is an example of programming languages that is "not and far from being an object-capability language". Systems written in Erlang have all or nothing security. The whole system written in Erlang is as secure as its most malicious component. It is not possible to fix this straightforwardly. The language nature would have to change. Designations of processes are not capabilities (but guessable integers). Designations of functions are not capabilities (but atoms and you can freely convert between arbitrary strings and atoms. You can freely forge any atom). The permission to call a function are set by a poor module system. Erlang supports "hot code swapping" (or some similar term) which gives attacker (from untrusted subsystem) an authority to replace any code anywhere in the system. There are many holes in Erlang. I am skeptical. [[User:Kosik\|Kosik]] 03:50, 2 April 2009 (CDT)

Kosik at 08:54, 2 April 2009

Kosik — Thu, 02 Apr 2009 08:54:51 GMT

←Older revision		Revision as of 08:54, 2 April 2009
Line 1:		Line 1:
-	Why do you think Erlang is "almost an object-capability language"? I think, it is an example of programming languages that is "not and far from being an object-capability language". Systems written in Erlang have all or nothing security. The whole system written in Erlang is as secure as its most malicious component. It is not possible to fix this straightforwardly. The language nature would have to change. Designations of processes are not capabilities (but guessable integers). Designations of functions are not integers (but atoms and you can freely convert between arbitrary strings and atoms. You can freely invent atoms). The permission to call a function are set by a poor module system. Erlang supports "hot code ~~updates~~" which gives attacker (from untrusted subsystem) an authority to replace any code anywhere in the system. There are many holes in Erlang. I am skeptical. [[User:Kosik\|Kosik]] 03:50, 2 April 2009 (CDT)	+	Why do you think Erlang is "almost an object-capability language"? I think, it is an example of programming languages that is "not and far from being an object-capability language". Systems written in Erlang have all or nothing security. The whole system written in Erlang is as secure as its most malicious component. It is not possible to fix this straightforwardly. The language nature would have to change. Designations of processes are not capabilities (but guessable integers). Designations of functions are not integers (but atoms and you can freely convert between arbitrary strings and atoms. You can freely invent atoms). The permission to call a function are set by a poor module system. Erlang supports "hot code swapping" (or some similar term) which gives attacker (from untrusted subsystem) an authority to replace any code anywhere in the system. There are many holes in Erlang. I am skeptical. [[User:Kosik\|Kosik]] 03:50, 2 April 2009 (CDT)

Kosik at 08:51, 2 April 2009

Kosik — Thu, 02 Apr 2009 08:51:41 GMT

←Older revision		Revision as of 08:51, 2 April 2009
Line 1:		Line 1:
-	Why do you think Erlang is "almost an object-capability language"? I think, it is an example of programming languages that is "not and far from being an object-capability language". Systems written in Erlang have all or nothing security. The whole system written in Erlang is as secure as its most malicious component. It is not possible to fix this straightforwardly. The language nature would have to change. Designations of processes are not capabilities (but guessable integers). Designations of functions are not integers (but atoms and you can freely convert between arbitrary strings and atoms. You can freely invent atoms). The permission to call a function are set by a poor module system. There are many holes in Erlang. I am skeptical. [[User:Kosik\|Kosik]] 03:50, 2 April 2009 (CDT)	+	Why do you think Erlang is "almost an object-capability language"? I think, it is an example of programming languages that is "not and far from being an object-capability language". Systems written in Erlang have all or nothing security. The whole system written in Erlang is as secure as its most malicious component. It is not possible to fix this straightforwardly. The language nature would have to change. Designations of processes are not capabilities (but guessable integers). Designations of functions are not integers (but atoms and you can freely convert between arbitrary strings and atoms. You can freely invent atoms). The permission to call a function are set by a poor module system. Erlang supports "hot code updates" which gives attacker (from untrusted subsystem) an authority to replace any code anywhere in the system. There are many holes in Erlang. I am skeptical. [[User:Kosik\|Kosik]] 03:50, 2 April 2009 (CDT)

Kosik at 08:50, 2 April 2009

Kosik — Thu, 02 Apr 2009 08:50:23 GMT

←Older revision		Revision as of 08:50, 2 April 2009
Line 1:		Line 1:
-	Why do you think Erlang is "almost an object-capability language"? I think, it is an example of programming languages that is "not and far from being an object-capability language". Systems written in Erlang have all or nothing security. The whole system written in Erlang is as secure as its most malicious component. It is not possible to fix this straightforwardly. The language nature would have to change. Designations of processes are not capabilities (but guessable integers). Designations of functions are not ~~capabilities~~ (but atoms and you can freely convert between arbitrary strings and atoms. You can freely ~~forge any atom~~). The permission to call a function are set by a poor module ~~system. Erlang supports "hot code swapping" (or some similar term) which gives attacker (from untrusted subsystem) an authority to replace any code anywhere in the~~ system. There are many holes in Erlang. I am skeptical. [[User:Kosik\|Kosik]] 03:50, 2 April 2009 ~~(CDT)~~	+	Why do you think Erlang is "almost an object-capability language"? I think, it is an example of programming languages that is "not and far from being an object-capability language". Systems written in Erlang have all or nothing security. The whole system written in Erlang is as secure as its most malicious component. It is not possible to fix this straightforwardly. The language nature would have to change. Designations of processes are not capabilities (but guessable integers). Designations of functions are not integers (but atoms and you can freely convert between arbitrary strings and atoms. You can freely invent atoms). The permission to call a function are set by a poor module system. There are many holes in Erlang. I am skeptical. [[User:Kosik\|Kosik]] 03:50, 2 April 2009 (CDT)
-		+
-	~~I did not dig deeper, but Scala might be also an object-capability programming language.~~	+
-	~~[[User:Kosik\|Kosik]] 11:20, 14 April 2011 (CDT)~~	+
-		+
-	~~It might be also worthwhile analyze Lua and describe why it is or it is not an object-capability programming language.~~	+
-	~~[[User:Kosik\|Kosik]] 04:14, 15 April 2011~~ (CDT)	+