|
History
| Log In
|
|
|
|
|
|
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. 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 :
* Spam control for groups : http://jira.secondlife.com/browse/MISC-65 * ban lists for non-invite-only groups : http://jira.secondlife.com/browse/MISC-67 * open source the sims so we can add our own security features : http://jira.secondlife.com/browse/MISC-258 * stop people easily bypassing the protection for media URLs : http://jira.secondlife.com/browse/MISC-378 * allow sim/parcel owners to ban by IP address : http://jira.secondlife.com/browse/MISC-420 * always allow estate owners/managers into sims, even when full (needed to respond to griefing at clubs) : http://jira.secondlife.com/browse/SVC-79 * fix nasty permissions bug letting anyone get full perms on anything : http://jira.secondlife.com/browse/SVC-273 * allow you to login as "invisible to everyone" : http://jira.secondlife.com/browse/VWR-468 * choose which groups to show in profile : http://jira.secondlife.com/browse/VWR-471 * fine-grained permissions for estate managers : http://jira.secondlife.com/browse/VWR-776 * stop people bypassing no-fly so easily : http://jira.secondlife.com/browse/VWR-1756 * web-management capabilities for estate managers : http://jira.secondlife.com/browse/WEB-240 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: Privacy is anything that people can currently see and/or hear that you don't want them to see or hear. ie a privacy issue is something that you WANT to be private Security is anything that is supposed to be private but isn't (or potentially isn't). Things like IP addresses should be kept private, but if for some reason they are not then that is a security issue. Whether or not I am online is something that I would like to be kept private, and therefore is a privacy 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) Security; Anything that presents real-world data-security concerns such as being able to find out real-name, credit card numbers or something. Typically these will be new features that might potentially cause issues (such as streaming HTML pages into the SL client and such as mentioned before). 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 :
* Haravikk Mistral considers it natural to split privacy/security as "privacy concerns SL stuff, security concerns RL stuff". * I considered it natural to split privacy/security as : "privacy concerns avatar-related stuff, security concerns stuff regarding land". 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. Example: say there was some flaw that exposed your RL name and address. You'd have a concerns about identity theft as well as concerns about your privacy. Hm. 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: - Privacy is anything that you would like to make private (or which was private but got broken in an update). Privacy really is just restricting things but which do not pose any major potential for exploitation. ie: currently my home is open to anyone but for a scripted scanner, I would LIKE to make it properly private, but not doing so will not pose any major risk as I've lived with it so far. Thus privacy is more to do with in-world things that do not involve money or content theft. - Security is concerned with things that SHOULD be private/secure, such as real-life information, credit-card details, IP addresses etc. Or with things that allow exploitation in world, such as a way of triggering multiple money() events in a script for a single transaction, or to copy no-copy items and similar. So anything in-world that can result in theft of content or money, or which puts real-life stuff at risk. - Griefing is just nasty no matter what you look at it, it sucks ass and it even annoys people just trying to categorise it! 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. :)
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? - Stream prim content to users outside parcel (Y/N) - Stream prim content to users outside parcel (Y/N) 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: * Any privacy zone (whether based on parcels or 3d volumes) in the existing sim volume would require sims to pass information about who is requesting information around, increasing inter-sim network traffic. Parcel basement information would only ever be sent to agents in the same parcel. * The Lindens have objected to any "phantom zone" style protection, where objects and avatars appear or vanish as you cross parcel boundaries, because they break the continuity of the world in a surprising way. I'm not convinced by the argument, but it's consistent with other proposals. 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.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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! ^^