<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: SLcripted</title>
	<atom:link href="http://dzonatas.wordpress.com/slcripted/feed/" rel="self" type="application/rss+xml" />
	<link>http://dzonatas.wordpress.com</link>
	<description>Yes!</description>
	<lastBuildDate>Tue, 10 Oct 2006 23:11:19 +0000</lastBuildDate>
	<generator>http://wordpress.com/</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: dzonatas</title>
		<link>http://dzonatas.wordpress.com/slcripted/#comment-4</link>
		<dc:creator>dzonatas</dc:creator>
		<pubDate>Tue, 10 Oct 2006 23:11:19 +0000</pubDate>
		<guid isPermaLink="false">http://dzonatas.wordpress.com/grid-attacks/#comment-4</guid>
		<description>On the SL blog, there is news about trusted coders. This is an option to being able to code in SL without the need to worry about CC verification. The question now arises on how to trust coders. Some are still stuck on the CC verification.</description>
		<content:encoded><![CDATA[<p>On the SL blog, there is news about trusted coders. This is an option to being able to code in SL without the need to worry about CC verification. The question now arises on how to trust coders. Some are still stuck on the CC verification.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: dzonatas</title>
		<link>http://dzonatas.wordpress.com/slcripted/#comment-3</link>
		<dc:creator>dzonatas</dc:creator>
		<pubDate>Tue, 10 Oct 2006 23:04:50 +0000</pubDate>
		<guid isPermaLink="false">http://dzonatas.wordpress.com/grid-attacks/#comment-3</guid>
		<description>Here is the original post made on this page:

There is still so much talk about verified accounts. Not everybody in the world that has access to the internet and is able to use Second Life is also able to have access to credit on US terms, which the current payment info registration requires.

Another option is the e-mail verification. The step to not acknowledge verification from hotmail, yahoo, gmail, and any other anonymous e-mail provider is a plus. It doesn’t solve all but does cut out a lot of alt accounts.

The ability to allow such free entry while being able to defeat hostile grid attacks is a plus.

There are ways to validate accounts on a very strict basis. For example, you buy the key — one time fee. However, such key does limit free entry. Someone might not be so interested in SL if they know they have to go out and buy a key.

If the entry was strictly secure, there may be unknown risks with the world itself unable to handle some random or unintentional grid attack. Free entry has enabled, but not encouraged, grid attackers. The Lindens gain knowledge on better ways to deploy anti grid-attack measures on every hit. With strict entry security, such knowledge is only limited to unintentional events. Anotherwords, strict entry with complete validation still doesn’t stop someone from being able to attack the grid. (i.e. They probably don’t care if their real identity is known.)

I rather see better anti grid-attack measures over stricter validation, as strict validation gives a false sense of security that there would be no grid attackers.</description>
		<content:encoded><![CDATA[<p>Here is the original post made on this page:</p>
<p>There is still so much talk about verified accounts. Not everybody in the world that has access to the internet and is able to use Second Life is also able to have access to credit on US terms, which the current payment info registration requires.</p>
<p>Another option is the e-mail verification. The step to not acknowledge verification from hotmail, yahoo, gmail, and any other anonymous e-mail provider is a plus. It doesn’t solve all but does cut out a lot of alt accounts.</p>
<p>The ability to allow such free entry while being able to defeat hostile grid attacks is a plus.</p>
<p>There are ways to validate accounts on a very strict basis. For example, you buy the key — one time fee. However, such key does limit free entry. Someone might not be so interested in SL if they know they have to go out and buy a key.</p>
<p>If the entry was strictly secure, there may be unknown risks with the world itself unable to handle some random or unintentional grid attack. Free entry has enabled, but not encouraged, grid attackers. The Lindens gain knowledge on better ways to deploy anti grid-attack measures on every hit. With strict entry security, such knowledge is only limited to unintentional events. Anotherwords, strict entry with complete validation still doesn’t stop someone from being able to attack the grid. (i.e. They probably don’t care if their real identity is known.)</p>
<p>I rather see better anti grid-attack measures over stricter validation, as strict validation gives a false sense of security that there would be no grid attackers.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: dzonatas</title>
		<link>http://dzonatas.wordpress.com/slcripted/#comment-2</link>
		<dc:creator>dzonatas</dc:creator>
		<pubDate>Mon, 09 Oct 2006 14:56:07 +0000</pubDate>
		<guid isPermaLink="false">http://dzonatas.wordpress.com/grid-attacks/#comment-2</guid>
		<description>After some talk, there was more thought about this.

Linden Labs should not be responsible to verify accounts. This can be done with agencies besides Linden Labs that do the verification. Very simple process that could be implement in world right now.

An external server would hold a key database. The database would be similar to the process that Blizzard has done. Unique keys are acquired by a user. The user then submits the key for verification. The key must be already registered within the database, which help prevents falsely generated keys. The keys can not be duplicated. If one key is activated twice for any instance needed, it is a concern. Blizzard usually bans accounts under such circumstances as duplicate keys found.

Scripts within SL can contact the key server to verify the key on hand. The key server reports back the status of the key or other data likewise.

The easiest thing to do with such keys is to allow access to a group. That group can be tested for within scripts for access features. Like if a member is part of a group, than they are allowed entry into a sim or that are able to use an object with permissions. This group access has already been done by hand without scripts and keys.

What I don&#039;t explain here is how to associate a key owner to a registered key in the key server. Blizzard requires someone to go and buy a copy of theirs games, and each copy comes with a unique key. SL wouldn&#039;t require you to buy a copy of their client. However, agencies probably could be setup to require their CC info first (if the must so desire such status quo) or other forms of verification.

I&#039;d imagine their would be several agencies interested in being key servers. It could mean $$ for them.</description>
		<content:encoded><![CDATA[<p>After some talk, there was more thought about this.</p>
<p>Linden Labs should not be responsible to verify accounts. This can be done with agencies besides Linden Labs that do the verification. Very simple process that could be implement in world right now.</p>
<p>An external server would hold a key database. The database would be similar to the process that Blizzard has done. Unique keys are acquired by a user. The user then submits the key for verification. The key must be already registered within the database, which help prevents falsely generated keys. The keys can not be duplicated. If one key is activated twice for any instance needed, it is a concern. Blizzard usually bans accounts under such circumstances as duplicate keys found.</p>
<p>Scripts within SL can contact the key server to verify the key on hand. The key server reports back the status of the key or other data likewise.</p>
<p>The easiest thing to do with such keys is to allow access to a group. That group can be tested for within scripts for access features. Like if a member is part of a group, than they are allowed entry into a sim or that are able to use an object with permissions. This group access has already been done by hand without scripts and keys.</p>
<p>What I don&#8217;t explain here is how to associate a key owner to a registered key in the key server. Blizzard requires someone to go and buy a copy of theirs games, and each copy comes with a unique key. SL wouldn&#8217;t require you to buy a copy of their client. However, agencies probably could be setup to require their CC info first (if the must so desire such status quo) or other forms of verification.</p>
<p>I&#8217;d imagine their would be several agencies interested in being key servers. It could mean $$ for them.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
