|
|
|
Removed: VWR-217 = What in the heck does that have to do with privacy?!
Haravikk: have a look at the linked Wiki page. The privacy issues in VWR-217 are related to RL privacy.
But the feature itself isn't related to improving privacy, and since it isn't implemented yet then there are no known security issues that it causes, only potential ones if the feature is not suitably revised before release (if it is even chosen for release).
This meta-issue is for improving privacy within the current game. Future features don't really count as LL aren't likely to implement them unless they think they have a safe way to do-so. Privacy concerns regarding individual future features should be posted in their comments to raise concerns I think. Haraviik, improving privacy in the current game also includes proactively preventing features that raise privacy concerns from getting implemented in a bad way. o.O
So we have to wait for Web Textures to get implemented and violate privacy before raising a concern in the privacy Meta-Issue? LOL I figured by linking the issue here it would at least let people know towards the top of the page that privacy concerns are a problem cuz a lot of people vote on an issue without scrolling down and reading all the comments first. No I'm not saying a feature should be implemented that reduces privacy, but the place for that really is in the comments for the feature itself. If you've a concern over its implementation then raise it in the feature itself, and the Lindens should then read your concerns and come up with a decision on what they're willing to sacrifice for a new feature, or if they'll refuse the feature on privacy grounds, or come up with an alternative/restricted way to implement it safely.
This meta-issue is for grouping bugs that reduce privacy, or new features intended to improve privacy. Vothing for the meta-issue itself serves as an indication that you want to improve privacy on the whole, and helps make it known just how many people want improved privacy. This may include having LL consider carefully the privacy issues of all future features, but should be related to specific issues as they are not yet implemented. "I figured by linking the issue here it would at least let people know towards the top of the page that privacy concerns are a problem cuz a lot of people vote on an issue without scrolling down and reading all the comments first." If they don't read the comments then their vote still indicates that the feature is one they'd like to have, it does not necessarily indicate that they want it in its raw form. Ultimately it's up to the Lindens, using feedback in the comments for an issue, to decide how something is implemented. Removed
Linked to WEB-192 Password Change with question 'home location' is unsecure. Although WEB-192 isn't directly an in-world privacy issue it covers a Web site issue that could compromise a Resident's password. I'd say a hacked account is an invasion of privacy since it reveals both SL info (friends and stuff) and RL info (billing details and real name). =.=
I think we need two separate privacy meta-issues.
1. in-world privacy: the ability to restrict client access to objects you have rezzed in-world, including your avatar. 2. Real-world privacy: the ability to play Second Life without exposing information that could be used to identify you to other players (and, yes, this does include your IP address). Added links to :
Split this SVC-241 meta-issue for security and privacy into two issues, one for security and one for privacy, as has been suggested by Argent Stonecutter and myself.
This one (SVC-241) is the privacy one. The security one is now at SVC-456. The reasons for the split are outlined there at SVC-456. Also, I've attached the original version of Haravikk's SVC-241 here, so that if people think the split is a bad idea they can reverse it. I'm sorry, but this issue has nothing to do with spying or security. This is intended PURELY to ensure residents can participate in SL undisturbed by other residents if they so wish, which ultimately encompasses land-based permissions issues. If someone is purposefully spying on you then IMO that's cause for an abuse report. If someone can overhear your private conversation or see what you're doing when you don't want others to however then there's no protection against that and there's really nothing you can do without a better permissions system.
Issues relating to real-life identity are to do with disclosure or data integrity, as with IP addresses and such-like.Think of it like this: Things like IP addresses should be kept private, but if for some reason they are not then that is a security issue. Similarly you mention that issues about "securing your home" are not privacy concerns. They are in fact privacy concerns as currently homes are very much public domain, and anyone wishing better access controls is actually interested in making something private, rather than secure, as the majority of homes at the moment are secure in the sense that no malicious user can do any harm to them. Ack, I'm sorry but I think the problem here stems from having the two the wrong way around, a ton of privacy issues are in the new security meta-issue, while all that seems to be left here are security issues. I don't have time to put things the right way around and edit things sufficiently to tidy this up, but as Argent mentioned, the original confusion is between in-world privacy (denying access to your home etc.) and real-world privacy (real-life info, IP address).
The former is what this privacy issue was intended for, perhaps it should be renamed "Improved in-world privacy" to clarify. The latter comes under either "Real life privacy" as Argent suggested, or Security. If someone has the time and is willing it would be great if the issues attached to these two metas could be switched and the descriptions changed to clarify the distinction between them along these lines: Privacy; Anything in-world that is currently available that you would like to make private, or through some bug has become publicly visible (but not vulnerable to malicious changes) Any in-world security issue comes under the category of an exploit and should be reported immediately using the in-world bug-reported under the tools menu and NOT described on the JIRA where it may be read by malicious parties. Added MISC-493 "Add Friend" in profile being abused to determine online status. Add "Ignore" button.
Reverted text of this issue, links may still require tidying-up, security issue SVC-456 requires re-wording and clean-up.
OK, it seems to me that :
They seem like two different ways of looking at the same issue. What to do? Well, I was going to suggest making the distinction clearer by using "privacy" or "anti-griefing", where "privacy" is protecting you from normal SLers and "anti-griefing" is where you protect yourself from people wishing to cause you harm or distress. But then again there are some issues that could be seen both ways, too. Maybe we should learn to live with the fact there will be overlap? I guess the point that I'm trying to make with SVC-456 is that griefing is too easy to do in Second Life. A single person can walk into a sim, use sound and particle spam to bring whatever event is going on to a standstill, then crash the sim (if it is buildable) when they are discovered. Then after they are banned they can come back and do it again on an alt. And repeat this process until LL gets around to taking action. And then even then they can use a proxy to get around LL's bans. I'm trying to create a place for feature requests that would help prevent griefing via the addition of new land tools and permissions. Examples include the ability for disable public build on all parcels in a sim at once, or ways of extending SLBanLink to work on a larger scale. I'm concerned about privacy too, but I still think splitting the issues is helpful as I think different people may vote for each. For example, people who use SL a lot for social stuff may vote for things to stop their friends seeing them as online without their permission, yet landowners may be more concerned with preventing alt abuse on their parcels/estates. I'll have a think about it and contact Haravikk to see if we can't come up with ideas about what to do here. Hmm, Griefing and Security really are two different entities, which just further confuses things. Privacy features (that allow you to restrict areas which are currently public) can be used to help with griefing, but there is a whole slew of other areas that can be investigated to try to make griefing more difficult. For example ways of limiting certain script calls. These are not privacy related at all, are /possibly/ security but are more along the lines of stability in most cases (crashing sims). I think ultimately griefing should have its own category as it can encompass too many areas to be covered neatly in one. I do like the idea of having an issue specifically for combating griefers though.
It's just the way I see it is:
I think a lot of users would quit complaining about various little issues, if LL and the open-sourcers sat down and just completed ONE Meta-issue at a time, rather than working on lots of different things in different areas. If we could see some major progress in one area at a time, people might not be so inclined to complain. I've voted for this issue because I do want more inworld privacy, but also because it is a Meta-Issue and should be treated as one large project.
Hmm, that is a valid point, however I'd like to note that a meta-issue is not a project as such. This meta-issue for example is to group issues and solutions to a common problem; privacy. Many of the issues may address the same privacy concerns in different ways, and it may be worth turning these in sub-tasks at some point, if a Linden has any idea of what would be the best way to organise such issues (different solutions, same problem) then it would be appreciated.
Understood about the "Meta-Issue" being mostly a means of organizing concepts. I've used them a few times myself. I still maintain that voting on a Meta-Issue will alert programmers as to which "family" of features/bugs is most important to users. Anyway, I'm OT so I'll hush now.
 Removed:
On the issues of limiting camera access to parcels, ie visually spying... Different solutions have been discussed and "promised" for many years but nothing ever happens on the subject, from LL's side. I can only assume they don't much care, becuase it doesn't mean money, or new flashy features (which inderectly mean money).
How hard would it really be to add some server code, and parcel options like this?
Emelie: that's a subset of the privacy zone suggestion. It's got the virtue of simplicity. I'm not sure why you have the same option twice, could you explain?
I still think that "parcel basements" would be the best solution:
A lightweight "private parcel" similar to the "construct" in the Matrix, or similar personal spaces in every other fictional VR that I can think of from True Names through Snow Crash to the present, is such an obvious feature that it's really surprising that Linden Labs hasn't implemented it. Formal proposal for a "skybox zone" just below the new building limit in SVC-2390.
Removed:
At this time I think it'd be good to get some attention back to these privacy issue now that the Lindens seem to be looking at the mainland again. I'd like to encourage watchers to get as many people as possible to vote on this meta-issue and to also look at the various issues attached to it. not sure if this issue has been dealt with elsewhere - there's just so much stuff about privacy. It seems that the idea of privacy in SL is exactly that - really only an idea, not a reality. For exaample, in the resident profile, there is a check box that will enable, or disable the profile from being visible in search. This is highlighted in the SL website knowledgebase, and gives the impression that privacy is a reality. however, I have found out, and it has been confirmed through my contact through the ticket submission system that if this box in the profile remains unchecked, then it is only in the 'search all' tab that the profile is hidden, however, it is still available through the 'search people' tab, which renders the facilty as useless. If a resident is having problems with a griefer and desires to hide all access to their profile, or simply, as in RL, just wants to grant restricted access to friends and groups, then why should that not be possible. And why should it be possible to hide a profile within the general search, and not within people search, after all, if you want to search for a person, where do you look? 'Search People' right? so how about real privacy for people who want to share Sl with friends without the hassle of just anyone being able to access our profiles in search, after all in Rl we have phone numbers, but we don't all have them listed. Its a matter of choice. Otherwise, lets not have facilities presented to us as if the do something they obviously dont, such as provide privacy from griefers.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Meta Issue
Open
Major
Meta-issue: Improved In-world Privacy
I'd like the ability to be asked if I want to allow a direct connection to a non-SL server. Like add an allow checkmark next to the play/stop button that allows me to choose the sims or parcels I trust and reject everything else.
So with that said is there any other case where the SL client makes a direct request to a non-SL server? I saw something about external image requests in another bug and that kind of scared me... o.O No way do I want to make random requests to non-SL servers ever! ^^