[llRequestAgenData(uuid,DATA_ONLINE) changes resulting from Privacy Policy]

Login to post on a public forum is the normal thing, it helps keep spammers out.  Also one should not put things in them that one does not want everyone to see, since the point of public forums is to publicly discuss things.

Login to browse forums are usually very annoying to use since normal search does not work on them and their built in search is usually usless which makes finding something you need on it a long boreing process. 

[llRequestAgenData(uuid,DATA_ONLINE) changes resulting from Privacy Policy]

I doubt it has much to do with it except for maybe a general panic reaction to any government legislation involving the internet that could be warped into an unrecognizable monster by opposition cliques before it actually sees daylight as a law and bite the industry as a result.

Nothing about the function seems to be directly applicable to the legislation as it stands now, LL does not collect and save online data using it, especially not in a personally identifiable way.  While others could possibly use it to record avatars online hours it really is not very accurate in that role and it does not give any personal information about the person it is used on.  It is more like a cell phone, the towers know whether a person is in the network whether they choose to answer it or not, and it makes little difference whether the network tells the caller the other phone is not being answered or if it is not found on the network at the moment (which some of them do, or at least did).

The only way someone could use it for ferreting out RL data would be if they could somehow compare avatar online status with account login and logout times, and LL is not likely to give out account logs.  Even if someone could hack in and get them the delay of up to a half hour or so in the functions update would mean that tens of thousands of false positives would be generated by that method, rendering it unpractical if not completely useless.

In its role of increasing the chances that someone can receive an item or message without capping problems it is useful, as a precision tool for tracking online status for nefarious purposes like breaking personal security it is not.

[llRequestAgenData(uuid,DATA_ONLINE) changes resulting from Privacy Policy]

It is true that there is a delay with this function of up to a half hour for online status change to be detected, but it is usually much faster (mostly within five or ten minutes).  Even in the case of a half hour it is not a problem for delivery because most people do not seem to cap in the first half hour after they log out unless something is rapidly sending them things (like the test script) so the delivery should get there under the wire.  The delay is even a help when it comes to delivering things on login since it gives the customer a little time to start clearing messages before dumping more on them. 

In the case of the help person on duty thing (assuming that it is the typical setup) the problem is not with them starting the 'on duty' cycle since they usually touch the prim to start it, it is in making sure that they are still online afterwards in case they have to go offlline in a hurry or get dumped offline by connection problems or whatever.  For that it is not practical for the person to go back and go off duty at the prim itself.  I have also heard of systems where there is no touch start, the help person simply logs in and the script detects them (or an attachment sends the base script a message to put them on duty) so the person would not even be going to the online help kiosk or whatever to log in.  In both of those help desk duty tracking situations the logout detect delay is not much of a problem since the chances of someone hitting the help button in the small window are low enough, and the delay in detecting login can actually be a good thing in the second case because it gives the helper time to get organized before possible help requests start coming in.

Overall the delay in llRequestAgenData information update is not a problem for most legitimate uses so the function is not "made useless by the delay". 

I am not sure how that http method mentioned earlier in the thread is supposed to work, i have avoided anything that requires a private website to work so i have ignored the http functions in LSL, but if that function requires an offgrid database or other non-SL web site to work then it would not have a very high acceptance.  Many merchants in SL are artistic types not technical people and setting up external sites to work with LSL scripts is not something they want to deal with for a hobby, many do not even have any presence on the web at all except for maybe a facebook page or deviant art page or something like that much less a scriptable site somewhere.  I personally am very wary of things on the web, and something that requires registration on a private site offgrid somewhere is a definite no-go for me for example.

 

[llRequestAgenData(uuid,DATA_ONLINE) changes resulting from Privacy Policy]

If it was simply a matter of 'fixing' the function so it would read online status by the way it was set rather than by a persons true status then it would not be quite so bad, but official word is (do to the way SL is programmed) that is not an option; it is either leave it as is or break it entirely and completely. 

Leaving it be is far less disruptive than getting rid of it, there is a huge number of scripts that depend on it and there is no viable alternative to the function that does not require brute force methods with bots or outside servers to automate.  SL is getting laggier all the time without schemes to use saturation methods for deliveries and such; make them the only way for merchants to compete and SL will turn into a tarpit of lag.

When i am working a design or sculpt or anything else that requires concentration i usually just shut off my chat window and ignore the ping of incoming messages (if i even notice them thru the concentration) until i get to a point where i can take a break and glance at the message and notice counters and see who is talking to me.  My friends understand that that is just how i work and there is no snub intended (and in fact some of them work the same way).  I suppose there is someone out there that has an irresistible compulsion to drop everything and absolutely must answer every IM and chat immediately that will not allow them to work on anything if anyone knows he or she is on, but the rest of the people should not suffer because of a very few extremely vocal people with 'evil hand' type issues.

[llRequestAgenData(uuid,DATA_ONLINE) changes resulting from Privacy Policy]

Knowing if someone is online or not is irrelevent to security, the same information can be gotten by simply IMing the person and looking at the reply, if they are offline then the servers says so. Bots can do that just as well as human users and can track someones online status just fine without the LSL function.  Likewise removing features from ligitimate viewers has no effect on hardcore griefers since they do not use ligitimate viewers, they use ones with spying and attack tools that no legal viewers use and fool the server into thinking they are a ligitimate one. Bots can log on and check group lists of groups a victim is likely to be a member of (if anyone thinks the information is not processable by a weaponized viewer think again, if you can see it then code can get to it too), or can teleport around and look with ordinary radar functions for a person, it is not that hard to find someone like that if you know anything about them which a griefer hounding a particular person (like all the protests against online status checking insist it is used for) would know about their target.  People are creatures of habit after all.

On the other hand removing the llRepuestAgentData function from LSL severly breaks modern vendor scripts which are designed to work within the load guidlines set by LL.  Without the function the vendors will have to revert to the old method of blind sending and resends which means that a lot of items get lost which causes in turn many problems for the merchant and customer base in SL. 

It also means that network traffic will increase and degrade SL performance which hurts everyone.  In fact if the ability to check if someone is online to receive something is removed then capping becomes a severe problem which is normally solved by repeating the transmission at intervals during the day or even over the course of a week so that at least one copy gets thruough.  When that is nessessary the only way to deal with the throttling for messages and notices is to go outside the LL network and send items and messages from servers outside from different addresses so the throttling does not clamp the sender off before the message que is sent which (when hundreds or thousands of merchants are using a service to do that) can cause extreme network congestion.  And do not even bother trying to say that the merchants will not do that because some already do instead of using intelligent senders that look for someone to be online before sending them the message or notice or package, and inevitablly many more will do so if that is the only practical solution.

Is making everyone suffer more lag so a few users can have the false illusion that they can sneak around invisibly like a thief in the night worth it? Personally I would say no.

[llRequestAgenData(uuid,DATA_ONLINE) changes resulting from Privacy Policy]

This whole rediculous issue could be resolved with no coding at all, just a change to the EULA stating that SL is a social enviornment and to not expect to be able to creep around invisibly. The busy flag is enough to tell friends that someone is not able to chat at the moment, there is no need for angst-causing skulduggery like masking logins.

The Data_Online restriction will not hamper griefers at all and neither will restricting legitimate TPVs since persistant griefers usually use illegal rigs that are just masquerading as other viewers, especially ones that apperently track the person accross alternate accounts via yahoo like the jira that started this whole thing states is happening.  Doing something to keep IP addresses from being leaked into the general enviornment via the media functions would be far more useful against griefers than this bit of OCD nonsense.

[mesh upload registration]

Here it is, i did not think it would be there for so long intact like that instead of being changed to just a database entry somewhere   As you can see i did complete the mesh tutorial so the failure to list it in my dashboard as being done is definately a bug.

 

[mesh upload registration]

My account still says that billing information is ok but that i need to take the ip test which i took and passed quite a while ago.

[mesh upload registration]

I am also having the same problem, i passed the tutorial weeks ago but still it says i have to take it.