Second Life Wiki - User contributions [en]

https://wiki.secondlife.com/w/api.php?action=feedcontributions&feedformat=atom&user=Matthew+Dowd Second Life Wiki - User contributions [en] 2026-07-28T06:00:35Z User contributions MediaWiki 1.42.1 https://wiki.secondlife.com/w/index.php?title=Bug_triage/2008-05-14&diff=67286 Bug triage/2008-05-14 2008-05-14T08:11:05Z

<p>Matthew Dowd: </p> <hr /> <div>{{Bug triage}}<br /> <br /> Next meeting: 2008-05-14 at 3pm PST at {{User|Bridie Linden}}'s house.<br /> <br /> == Import? ==<br /> (Bugs reported in 1.20 Release Candidate — consider for import?, sorted by votes)<br /> * {{jira|VWR-6328}} - Votes: 62 - Request for "Tools" menu to not auto-hide - {{User|Beezle Warburton}} [Added manually by {{User|Matthew Dowd}} on the basis that this is in the top 10 of open issues with 1.20 RC by vote, but apparently not triaged or otherwise acknowledged as an issue]<br /> * {{jira|VWR-6862}} - Votes: 7 - Flexi Prim's don't recognise attributes. - {{User|Soap Clawtooth}}<br /> * {{jira|VWR-6707}} - Votes: 5 - 1.20 - Crash on Login/Frequent Crashing - {{User|Lazure Ryba}} ((did we already discuss this?))<br /> * {{jira|VWR-6856}} - Votes: 4 - Anti-Aliasing AND shaders on makes SL completely useless on Intel iMac since 1.20 RC3 - {{User|Vala Vella}}<br /> * {{jira|VWR-6953}} - Votes: 4 - Flexi cylinders have strange, unnecessary twists in them - {{User|tenebrous pau}}<br /> * {{jira|VWR-6772}} - Votes: 3 - Identical sculpties stuck in different stages of loading. - {{User|Katarina Malthus}}<br /> * {{jira|VWR-6381}} - Votes: 3 - Client eats first character after new / if typed too soon - {{User|Feynt Mistral}}<br /> * {{jira|VWR-6912}} - Votes: 3 - Mac Pro / multicore - one core rises to 100% causing temporary freeze - {{User|Court Goodman}}<br /> * {{jira|VWR-6026}} - Votes: 2 - Colors. Light way to bright. Sunset/Sunrise turns everything orange - {{User|Lisa Lowe}}<br /> * {{jira|VWR-6260}} - Votes: 2 - Non-focussed windows do not pop in front of focussed window. - {{User|Argent Stonecutter}}<br /> * {{jira|VWR-6436}} - Votes: 2 - zoom and alt-cam not working - {{User|Barbidule McBride}}<br /> * {{jira|VWR-6484}} - Votes: 2 - Minimap height indicators all show "lower than me" if over the old 768 build ceiling - {{User|Buckaroo Mu}}<br /> * {{jira|VWR-6498}} - Votes: 2 - Checkmark missing when Slow Animations enabled - {{User|Whichway Janus}}<br /> * {{jira|VWR-6501}} - Votes: 2 - Objects rotate wildly in edit mode with 3dconnexion Space Navigator plugged in - {{User|Hypatia Callisto}}<br /> * {{jira|VWR-6579}} - Votes: 2 - Terribly incorrect culling of textures in 1.20 on macbook pro - {{User|Wood Fairey}}<br /> * {{jira|VWR-6597}} - Votes: 2 - Can't save texture memory size in preference-hardware - {{User|maverick offcourse}}<br /> * {{jira|VWR-6699}} - Votes: 2 - Shaders are disabled on supported video card - {{User|Deany Fall}}<br /> * {{jira|VWR-6740}} - Votes: 2 - SpaceNavigator input cross-talk to other apps - {{User|Whichway Janus}}<br /> * {{jira|VWR-6833}} - Votes: 2 - 1.20.3 Crash on Login/During Essential InWorld Activitys - {{User|Kitty Hirsch}}<br /> * {{jira|VWR-6889}} - Votes: 2 - Unable to leave group when role has no allowed abilities - {{User|Geraldine Giha}}<br /> * {{jira|VWR-6848}} - Votes: 2 - Space Navigator does not function when other game controller device is already known by Windows - {{User|Ronald Richez}}<br /> * {{jira|VWR-6984}} - Votes: 2 - Corrupt fonts - {{User|Michelle2 Zenovka}}<br /> * {{jira|VWR-7131}} - Votes: 2 - Special layers are not rendered through Windlight water. - {{User|Argent Stonecutter}}<br /> * {{jira|VWR-7174}} - Votes: 2 - Glow PROBLEM behind transparent surface - {{User|Naiman Broome}}<br /> * {{jira|VWR-6016}} - Votes: 1 - FMOD problem: update3dPosition error - {{User|Tayra Dagostino}}<br /> * {{jira|VWR-6246}} - Votes: 1 - All Menu items seem to be disabled, and right clicking anywhere in world causes a jump, not a Pie Menu. - {{User|Robin Sojourner}}<br /> * {{jira|VWR-6252}} - Votes: 1 - Alerts and Notifications on new UI need more contrast or color. - {{User|rena kuhn}}<br /> * {{jira|VWR-6300}} - Votes: 1 - RC outputs wrong value type when importing from settings.xml - {{User|Kitty Barnett}}<br /> * {{jira|VWR-6388}} - Votes: 1 - Corrupted Verticies - {{User|Zion Tristan}}<br /> * {{jira|VWR-6440}} - Votes: 1 - Distance to target not visible at some angles - {{User|BlueWall Slade}}<br /> * {{jira|VWR-6483}} - Votes: 1 - Changing Advanced->Rendering->Info Displays blanks all HUD llSetText. - {{User|Buckaroo Mu}}<br /> * {{jira|VWR-6481}} - Votes: 1 - Joystick Support: Moving camera around avatar with flycam turns avatar around when in mouselook - {{User|Domchi Underwood}}<br /> * {{jira|VWR-6499}} - Votes: 1 - Banlines now visible through prims - {{User|Aki Shichiroji}}<br /> * {{jira|VWR-6561}} - Votes: 1 - Wireless Mighty Mouse stops responding and freezes BlueTooth Keyboard too until turned off and on - {{User|anthea shilova}}<br /> * {{jira|VWR-6563}} - Votes: 1 - New Viewers 1.19 and 1.20 both regular client and First Look client have started TEXTURES FROM INVENTORY ON ITEMS IN WORLD FLUCTUATING - {{User|lauren weyland}}<br /> * {{jira|VWR-6586}} - Votes: 1 - Scale values in Avatar mode on 3DConnexion controller appear to do nothing - {{User|CodeWarrior Carling}}<br /> * {{jira|VWR-6587}} - Votes: 1 - Scale values in avatar column of joystick preferences always reset to '1.0' when you exit and restart - {{User|CodeWarrior Carling}}<br /> * {{jira|VWR-6626}} - Votes: 1 - Spacenavigator Not Recognised MacOS - {{User|Chance Unknown}}<br /> * {{jira|VWR-6623}} - Votes: 1 - After downloading 1.20.18 I can not install I get 30 "error can not open for writing" messages most are .dll or db2 files - {{User|Chandra Jun}}<br /> * {{jira|VWR-6697}} - Votes: 1 - RC 1.20.2 (85278): System freeze after login under linux - {{User|Suzan Littlething}}<br /> * {{jira|VWR-6653}} - Votes: 1 - Anti-ailiasing no longer visible on mac client - {{User|Court Goodman}}<br /> * {{jira|VWR-6683}} - Votes: 1 - 1.20RC2 - Immediate crash when clicking OK on blue pop-up window (MacOs) - {{User|samia bechir}}<br /> * {{jira|VWR-6788}} - Votes: 1 - Ctrl-Alt-LMouseclick on avatar zoomes camera out instead of focusing on avatar - {{User|Aryan Saphir}}<br /> * {{jira|VWR-6839}} - Votes: 1 - nvidia forceware 174 driver crashes with 1.19.1.4 and 1.20 RCs - {{User|Yuu Nakamichi}}<br /> * {{jira|VWR-6878}} - Votes: 1 - Existing inventory objects randomly and suddenly refuse to attach or rez in-world - {{User|Masha Eilde}}<br /> * {{jira|VWR-6930}} - Votes: 1 - 1.20.4 (85828) viewer crashes repeatedly - {{User|Frederich Courier}}<br /> * {{jira|VWR-6933}} - Votes: 1 - Disabling Ripple Water also disables glow - {{User|Nedrae Messmer}}<br /> * {{jira|VWR-6980}} - Votes: 1 - crash logger fails to keep "always send" setting - {{User|Shadow Pidgeon}}<br /> * {{jira|VWR-6989}} - Votes: 1 - joystick flycam - zoomlevel jumps - {{User|SirOb Voom}}<br /> * {{jira|VWR-7045}} - Votes: 1 - Copy Selection tool broken in 1.20 RC - {{User|Hypatia Callisto}}<br /> * {{jira|VWR-7119}} - Votes: 1 - When using Space Navigator, grid does not work, snaps do not work. - {{User|windyweather vanalten}}<br /> * {{jira|VWR-7116}} - Votes: 1 - Using SpaceNavigator jumps far away when leaving edit - {{User|windyweather vanalten}}<br /> * {{jira|VWR-7114}} - Votes: 1 - Cannot move Flycam in more than one axis at a time using the Space Navigator under RC 1.20 and OS X 10.5.2 - {{User|Rob danton}}<br /> * {{jira|VWR-7137}} - Votes: 1 - Viewer Crashes on Quit - Macintosh - {{User|Shawna Kelley}}<br /> * {{jira|VWR-7144}} - Votes: 1 - Camera behavior erratic in edit mode - {{User|Lindal Kidd}}<br /> * {{jira|VWR-7204}} - Votes: 1 - Loading time of sculpts - {{User|Naiman Broome}}<br /> * {{jira|VWR-6238}} - Votes: 0 - New viewer is auto logging in if password is saved without providing option to change account name.- - {{User|lenore contepomi}}<br /> * {{jira|VWR-6242}} - Votes: 0 - Dazzle client forced dl this evening, geometric shapes dissect avitars and prims when there is nothing in reality there, things like ocean waves/windows/glass features are red *and not the ctl alt T* option - {{User|tandee ashbourne}}<br /> * {{jira|VWR-7105}} - Votes: 0 - Crash logger Freezes, fails to come up, or actually crashes (yes the crash logger crashes) - {{User|Cummere Mayo}}<br /> * {{jira|VWR-6255}} - Votes: 0 - Randomly unreadably text, corrupted text, distorted text. - {{User|SuperMax Hax}}<br /> * {{jira|VWR-6258}} - Votes: 0 - L$ balance is shown in hard-to-read color. - {{User|Ephyu Reino}}<br /> * {{jira|VWR-6281}} - Votes: 0 - WL 1.20 Bugs and Feedback - {{User|Contessa Esposito}}<br /> * {{jira|VWR-6288}} - Votes: 0 - Childprim needs about 5 seconds to move if position is changed with spinEdit buttons from Object window - {{User|Aares Torok}}<br /> * {{jira|VWR-6289}} - Votes: 0 - Camera floats around in view on its own as if it is attached to a moving object when in public areas (i.e. clubs stores) - {{User|kaj qinan}}<br /> * {{jira|VWR-6292}} - Votes: 0 - Avatar Animations stop,start, malfunction in Release candidate 1.20.0 - {{User|rezit sideways}}<br /> * {{jira|VWR-6332}} - Votes: 0 - involuntary av movement, sticky camera, no groups, no eyes, frequent crashes - {{User|Alger Meads}}<br /> * {{jira|VWR-6333}} - Votes: 0 - Under Advanced, the Console button once clicked can't be disabled. - {{User|Mark Yue}}<br /> * {{jira|VWR-6336}} - Votes: 0 - World Map "Landmarks" dropdown doesn't work - {{User|Jeremy Ondricek}}<br /> * {{jira|VWR-6347}} - Votes: 0 - Selected texture still stays selected after changing to another edit mode. - {{User|gearsawe stonecutter}}<br /> * {{jira|VWR-6349}} - Votes: 0 - Dazzle-<RC0> Windows gaining an extera button - {{User|Daten Thielt}}<br /> * {{jira|VWR-6378}} - Votes: 0 - Second Life 1.20.0 (84432) Always show beacons Reactivates itself after each startup after being disabled. - {{User|Vengence Keon}}<br /> * {{jira|VWR-6366}} - Votes: 0 - Audio device autoselection inconsistency - {{User|Dusty Perl}}<br /> * {{jira|VWR-6374}} - Votes: 0 - Strange behaviour - {{User|Thasha Ansome}}<br /> * {{jira|VWR-6401}} - Votes: 0 - Grey people - {{User|Davec Horsforth}}<br /> * {{jira|VWR-6404}} - Votes: 0 - 1.20 RC does not handle damage control when browsing for cache file location - {{User|Whichway Janus}}<br /> * {{jira|VWR-6413}} - Votes: 0 - Text output: characters are jumping when scrolling in editors or moving windows - {{User|Tillie Ariantho}}<br /> * {{jira|VWR-6412}} - Votes: 0 - Scrolling in LSL Editor is bugged (parts left out) - {{User|Tillie Ariantho}}<br /> * {{jira|VWR-6418}} - Votes: 0 - Snapshot settings not remembered inbetween logins (when running SL from Disk Image) - {{User|Daedalus Young}}<br /> * {{jira|VWR-6423}} - Votes: 0 - Anti-Aliasing blurs every other Line in Dazzle. - {{User|ciaran flasheart}}<br /> * {{jira|VWR-6426}} - Votes: 0 - Constantly crashing when building over 768m. - {{User|Darek Deluca}}<br /> * {{jira|VWR-6438}} - Votes: 0 - Editing prim position while being sat on causes oscillations - {{User|BlueWall Slade}}<br /> * {{jira|VWR-6444}} - Votes: 0 - Command button labels are placed badly - {{User|Alissa Sabre}}<br /> * {{jira|VWR-6471}} - Votes: 0 - Mac client - preferences are not saved - {{User|Nad Gough}}<br /> * {{jira|VWR-6472}} - Votes: 0 - Mac client: Glow characteristic - {{User|Nad Gough}}<br /> * {{jira|VWR-6479}} - Votes: 0 - Joystick support: Roll Scale default is broken since 1.20 RC - {{User|Domchi Underwood}}<br /> * {{jira|VWR-6507}} - Votes: 0 - Menu does not respond to mouse-clicks in Mac version of viewer - {{User|Pyter Morgridge}}<br /> * {{jira|VWR-6516}} - Votes: 0 - Avatar baked textures wrong after crash or teleport - {{User|Whichway Janus}}<br /> * {{jira|VWR-6518}} - Votes: 0 - 'N' for North 'missing' on World Map - {{User|Daedalus Young}}<br /> * {{jira|VWR-6555}} - Votes: 0 - Viewer 1.20.0 freezes when viewing certain huge prims - {{User|Zyzzy Zarf}}<br /> * {{jira|VWR-6566}} - Votes: 0 - Recent Items "since logoff" random - {{User|Frank Skosh}}<br /> * {{jira|VWR-6567}} - Votes: 0 - Joystick Support: Settings scaled differently between Mac and PC - {{User|Aimee Trescothick}}<br /> * {{jira|VWR-6592}} - Votes: 0 - Joystick - simultaneous walking/flying and turning, turning is unresponsive - {{User|Jorgen Friis}}<br /> * {{jira|VWR-6599}} - Votes: 0 - Snap to grid feature problem - {{User|Cago Hax}}<br /> * {{jira|VWR-6628}} - Votes: 0 - Release Candidate 1.20.1 for Mac: Menu commands fail, camera fails to recenter, camera hair trigger snaps back to default with mouse clicks in inventory - {{User|Sky Hye}}<br /> * {{jira|VWR-6635}} - Votes: 0 - Ever since 1.20RC my graphics have been screwy. I use GeForce Go 7900 GS/PCI/SSE2 and never had a problem, but now, there are several visual issues. - {{User|Everett Streeter}}<br /> * {{jira|VWR-6638}} - Votes: 0 - Cannot log in - {{User|Aphrodite Tagore}}<br /> * {{jira|VWR-6647}} - Votes: 0 - Setting the joystick feathering above the default results in an undamped oscillation of the view with a SpaceNavigator - {{User|Ralph Doctorow}}<br /> * {{jira|VWR-6924}} - Votes: 0 - Map slows viewer to a crawl, induces camera/avatar rotation - {{User|Lindal Kidd}}<br /> * {{jira|VWR-6700}} - Votes: 0 - Windows Vista Reverts to Basic Colour Scheme - {{User|Tribal Toland}}<br /> * {{jira|VWR-6705}} - Votes: 0 - Unable to click / use HUD when in mouselook - {{User|ryder spearmann}}<br /> * {{jira|VWR-6723}} - Votes: 0 - Zooby's Rezzable Pets getting lost - {{User|Sahoni Tigerpaw}}<br /> * {{jira|VWR-6731}} - Votes: 0 - clothes are being retextured with screenshot - {{User|cardi dragonash}}<br /> * {{jira|VWR-6732}} - Votes: 0 - Viewer crashes on left-clicks on vendors, URL-givers etc. - {{User|moni duettmann}}<br /> * {{jira|VWR-6746}} - Votes: 0 - Health Percentage Unreadable - {{User|Frank Skosh}}<br /> * {{jira|VWR-6754}} - Votes: 0 - Error in floater_instant_message_group.xml - {{User|McCabe Maxsted}}<br /> * {{jira|VWR-6652}} - Votes: 0 - client crash/Script- brightness and denial of service - {{User|Heron Halberstadt}}<br /> * {{jira|VWR-6655}} - Votes: 0 - Glow appears at the lower hem of loose shirt-layer clothing in both the lastest RC viewer, and the regular 1.19 viewer. - {{User|Max Kleiber}}<br /> * {{jira|VWR-6758}} - Votes: 0 - Log message on console are bold. - {{User|Balp Allen}}<br /> * {{jira|VWR-6659}} - Votes: 0 - Second life renders graphics incorrectly during and after appearence modifications. - {{User|Navin Dawes}}<br /> * {{jira|VWR-6661}} - Votes: 0 - weird colours top 1/4 - 3/4 of screen - freezes comp - {{User|Garn Conover}}<br /> * {{jira|VWR-6664}} - Votes: 0 - avatar impostering fails in some locations. - {{User|Bubba Loring}}<br /> * {{jira|VWR-6663}} - Votes: 0 - 16x Antialias blurs UI and chat text - {{User|myf mcmahon}}<br /> * {{jira|VWR-6666}} - Votes: 0 - Enabling Basic Shaders Freezes Display on Mac - {{User|Sunn Thunders}}<br /> * {{jira|VWR-6681}} - Votes: 0 - Seeing gray instead of "MISSING IMAGE" - {{User|Day Oh}}<br /> * {{jira|VWR-6684}} - Votes: 0 - Must right-click "touch" scripted objects for them to work. - {{User|Spook Maroon}}<br /> * {{jira|VWR-6692}} - Votes: 0 - My screen is completely black with everything else working and being normal. - {{User|johnnie markova}}<br /> * {{jira|VWR-6799}} - Votes: 0 - Tool box showing up at random - {{User|Nedrae Messmer}}<br /> * {{jira|VWR-6801}} - Votes: 0 - Classic Clouds are pitch Black - {{User|WarKirby Magojiro}}<br /> * {{jira|VWR-6820}} - Votes: 0 - Cannot download RC 1.20.3 - {{User|gozo aya}}<br /> * {{jira|VWR-6825}} - Votes: 0 - Crash on Login with 1.20 RC3 - {{User|aaron23 decuir}}<br /> * {{jira|VWR-6830}} - Votes: 0 - newest Release Candidate 1.20 crashes upon launching - {{User|Julian2914 Hifeng}}<br /> * {{jira|VWR-6838}} - Votes: 0 - IM logging set to "off" in prefs, but IM window warns logging is taking place - {{User|surty slok}}<br /> * {{jira|VWR-6852}} - Votes: 0 - Render Axes renders at the Sim corner - {{User|Luke Poplin}}<br /> * {{jira|VWR-6859}} - Votes: 0 - When the browser of the default of PC is started from the built-in browser of viewer, the text editor of PC appears simultaneously - {{User|Rado Arado}}<br /> * {{jira|VWR-6866}} - Votes: 0 - Built in Web Browers - {{User|Cookie Lewis}}<br /> * {{jira|VWR-6864}} - Votes: 0 - Cannot fly in RC 1.20(4) Mac - {{User|Vivienne Schell}}<br /> * {{jira|VWR-6879}} - Votes: 0 - Edge of window Pie menu problems - {{User|JPT62089 Agnon}}<br /> * {{jira|VWR-6890}} - Votes: 0 - ampty avi after tp or start sl - {{User|Rick Alvarez}}<br /> * {{jira|VWR-6906}} - Votes: 0 - Graphic glithc at sea angles of the sim - {{User|Naiman Broome}}<br /> * {{jira|VWR-6917}} - Votes: 0 - scim exit causes crash of SL viewer on linux - {{User|Fred Huffhines}}<br /> * {{jira|VWR-6936}} - Votes: 0 - Texture console shows constant list of unloadable asset keys. - {{User|Allen Kerensky}}<br /> * {{jira|VWR-6961}} - Votes: 0 - clicking on http link in "blue box" crashes sl - {{User|Cummere Mayo}}<br /> * {{jira|VWR-6962}} - Votes: 0 - Screen saver causes all object to glow - {{User|Drathek Sassoon}}<br /> * {{jira|VWR-6963}} - Votes: 0 - avatars in the release viewer see avatar in the Release client floating - {{User|Elsbeth Clary}}<br /> * {{jira|VWR-6974}} - Votes: 0 - Crash logger seems to never send anything - {{User|Lanadriel Llewellyn}}<br /> * {{jira|VWR-6988}} - Votes: 0 - Doing a shift copy with Grid -> Show Cross Sections enabled floods the log with rendering warnings about LLVertexBuffer::setBuffer - {{User|Strife Onizuka}}<br /> * {{jira|VWR-6990}} - Votes: 0 - Tooltips disabled if ALT Clicking into the view window when not active - {{User|Zion Tristan}}<br /> * {{jira|VWR-6997}} - Votes: 0 - Crash on error dc getLLSD var TeleportFlags not found - {{User|Allen Kerensky}}<br /> * {{jira|VWR-6996}} - Votes: 0 - Mac: Can not remember VRAM over 64MB setting. - {{User|Capucchy Streeter}}<br /> * {{jira|VWR-7003}} - Votes: 0 - usedebugLogin no longer works - {{User|McCabe Maxsted}}<br /> * {{jira|VWR-7008}} - Votes: 0 - Improper application shutdown. (crash on exit) - {{User|Grindel Rossini}}<br /> * {{jira|VWR-7018}} - Votes: 0 - Space Navigator - Avatar jerky turning on spot since 1.20.5 - {{User|Mark Rosenbaum}}<br /> * {{jira|VWR-7020}} - Votes: 0 - SpaceNavigator cannot edit position of linked prims - {{User|Vilkacis Mason}}<br /> * {{jira|VWR-7023}} - Votes: 0 - Ejected from land, fell below world. - {{User|Jessica Kabumpo}}<br /> * {{jira|VWR-7030}} - Votes: 0 - Linux build terminates with an error unless an environment variable SSH_AUTH_SOCK is defined - {{User|Alissa Sabre}}<br /> * {{jira|VWR-7038}} - Votes: 0 - Rising sheets of colour that interfere with my view of the sl world. - {{User|Smokie Ember}}<br /> * {{jira|VWR-7050}} - Votes: 0 - 1.20 RC5, Graphics errors when building up the world or in animations - {{User|Teebone Aeon}}<br /> * {{jira|VWR-7059}} - Votes: 0 - The viewer "forgets" everything - even the login-password is not saved - {{User|Rita Munro}}<br /> * {{jira|VWR-7062}} - Votes: 0 - Script runtime errors aren't using DEBUG_CHANNEL any more - {{User|Vex Streeter}}<br /> * {{jira|VWR-7071}} - Votes: 0 - snapshots show spots, notably on sculpted prims - {{User|Melissa Yeuxdoux}}<br /> * {{jira|VWR-7080}} - Votes: 0 - Phantom Prims on land after attempted Take - {{User|LadyIsis Dagger}}<br /> * {{jira|VWR-7084}} - Votes: 0 - Viewer on MacBook Pro slows to crawl - hard crash - {{User|Shawna Kelley}}<br /> * {{jira|VWR-7087}} - Votes: 0 - Japanese version of "About..." includes a garbage due to an invalid UTF-8 byte sequence in floater_about.xml - {{User|Alissa Sabre}}<br /> * {{jira|VWR-7085}} - Votes: 0 - Taking Snapshot to Disk with 'Show Interface in Snapshot' *off* causes avatar nametags to vanish - {{User|Darien Caldwell}}<br /> * {{jira|VWR-7088}} - Votes: 0 - Attachments with invisiprims cause objects sat upon to become invisible - {{User|Lamorna Proctor}}<br /> * {{jira|VWR-7091}} - Votes: 0 - spacenavigator right button set to "escape" key causes avatar to jump. - {{User|Sharron Schuman}}<br /> * {{jira|VWR-7118}} - Votes: 0 - Grid snaps dont work when moving in 1D only - {{User|windyweather vanalten}}<br /> * {{jira|VWR-7097}} - Votes: 0 - Huds randomly come off or do not work - {{User|Syler Zhora}}<br /> * {{jira|VWR-7081}} - Votes: 0 - Renaming inventory item frequently causes viewer crash - {{User|Solomon Devoix}}<br /> * {{jira|VWR-7140}} - Votes: 0 - Unable to rez objects on land. This has happened two different times with the new viewer - on May 8 and May 9th. Have had to switch back to older version. There are no problems with "wearing" objects on avatar. - {{User|Eleanor Anderton}}<br /> * {{jira|VWR-7029}} - Votes: 0 - Viewer crashes when >16 profile windows are open and object (notecard) is dragged onto profile. - {{User|CaptainCrunch Hax}}<br /> * {{jira|VWR-7145}} - Votes: 0 - Camera panning fails to operate correctly - {{User|Ianto Kawanishi}}<br /> <br /> * {{jira|VWR-7156}} - Votes: 0 - Zoom doesn't work in Flycam mode - {{User|tenebrous pau}}<br /> * {{jira|VWR-7158}} - Votes: 0 - Camera freezes during first part of CTRL-ALT mouse movement - {{User|Steve Mahfouz}}<br /> * {{jira|VWR-7161}} - Votes: 0 - Atmospheric Shaders causes screen corruption. - {{User|Satori Taringa}}<br /> * {{jira|VWR-6212}} - Votes: 0 - Viewer eats typed text when using imput method in Linux - {{User|Yukinoroh Kamachi}}<br /> * {{jira|VWR-7011}} - Votes: 0 - Camera locks into top of head view - {{User|WarKirby Magojiro}}<br /> * {{jira|VWR-7184}} - Votes: 0 - Object contents cannot be viewed if TEMP environment variable is not set correctly - {{User|Phillip Vought}}<br /> * {{jira|VWR-7187}} - Votes: 0 - Invisible avatar bodies - {{User|Abra Miles}}<br /> * {{jira|VWR-7132}} - Votes: 0 - Voice Chat problems in RC .6 - {{User|Cummere Mayo}}<br /> * {{jira|VWR-7002}} - Votes: 0 - Audio turns itself on at will - {{User|Sovery Short}}<br /> * {{jira|VWR-7136}} - Votes: 0 - Glow applied on an object can be seen thru walls and other objects when Bump Mapping is applied - {{User|medhue simoni}}<br /> * {{jira|VWR-7178}} - Votes: 0 - Can no longer take full screen snapshot ... limited to square images - {{User|Neferon Nevadan}}<br /> * {{jira|VWR-7209}} - Votes: 0 - All black avatars at certain time of day. - {{User|Spook Maroon}}<br /> <br /> == Fast Track Import ==<br /> <br /> (Move bugs here that have solid repros, or valid patches that you have reviewed)<br /> <br /> == Hot by Vote ==<br /> <br /> [http://www.sljirastats.com/jira_search.php?search=33&output=wiki High Voted Bugs]<br /> <br /> == Patches ==<br /> [http://www.sljirastats.com/jira_search.php?search=34&output=wiki Patches]<br /> <br /> == Misc Pool ==<br /> [http://www.sljirastats.com/jira_search.php?search=35&output=wiki Misc Pool]<br /> <br /> == Pre-meeting activity ==<br /> <br /> Some issues will be resolved in the course of building this agenda. Rather than deleting them from the proposed agenda, move the issue and associated discussion into the appropriate section below.<br /> <br /> === Imported ===<br /> <br /> === Resolved ===<br /> <br /> == Transcript ==<br /> Transcript is/will be at [[{{PAGENAME}}/Transcript]]<br /> <br /> == Creating An Agenda ==<br /> {{Bug List Instructions}}</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Bug_triage/2008-04-30&diff=65489 Bug triage/2008-04-30 2008-04-29T18:06:47Z

<p>Matthew Dowd: Added VWR-6328</p> <hr /> <div>{{Bug triage}}<br /> <br /> Next meeting: 2008-04-30 at 3pm PST at {{User|Bridie Linden}}'s house, guest hosts: Aric and Alexa Linden <br /> <br /> == Import? ==<br /> (Bugs reported in 1.20 Release Candidate — consider for import?, sorted by votes)<br /> * {{jira|VWR-6328}} - Votes: 57 - Request for "Tools" menu to not auto-hide - {{User|Beezle Warburton}} [Added manually by {{User|Matthew Dowd}} on the basis that this is in the top 10 of open issues with 1.20 RC by vote, and yet the only one in about the top 20 issues for 1.20 RC by vote apparently not yet triaged]<br /> * {{jira|VWR-6784}} - Votes: 12 - Viewer issue with 1.20 viewer. No matter if using Secondlife Client 1.20 or open sourced, avatar's system eyelashes appear clotted. Alpha aspects not working; skin types/body shapes/ make no difference - {{User|Lilibeth Andree}}<br /> * {{jira|VWR-6604}} - Votes: 10 - Avatar shape changed proportions in RC version - {{User|Guilhermo Beck}}<br /> * {{jira|VWR-6897}} - Votes: 6 - 1.20 RC4, Mac Version: extremely high disk usage - {{User|Darko McMahon}}<br /> * {{jira|VWR-6847}} - Votes: 5 - Joystick Setup / Settings are not preserved between client sessions - {{User|Zorin Frobozz}}<br /> * {{jira|VWR-6226}} - Votes: 4 - Editting a single llinked prim and moving that prim, then undoing the move to that single prim will return the prim to its previous location but also move the entire linked set the same distance X, Y or Z - {{User|Tindallia Soothsayer}}<br /> * {{jira|VWR-6593}} - Votes: 4 - Voice problems Linux - Ubuntu Hardy 8.04 - {{User|Gregor Siemens}}<br /> * {{jira|VWR-4481}} - Votes: 3 - Clicking on build button to close build window also resets camera view and turns off joystick flycam - {{User|Domchi Underwood}}<br /> * {{jira|VWR-6658}} - Votes: 3 - X, Y, Z alignment lines when editing a prim no longer accurately display spacial position - {{User|Khashai Steinbeck}}<br /> * {{jira|VWR-6896}} - Votes: 3 - Crash when Advanced->Rendering->Info Displays->Lights selected (and other Info Displays) - {{User|Argent Stonecutter}}<br /> * {{jira|VWR-6026}} - Votes: 2 - Colors. Light way to bright. Sunset/Sunrise turns everything orange - {{User|Lisa Lowe}}<br /> * {{jira|VWR-6260}} - Votes: 2 - Non-focussed windows do not pop in front of focussed window. - {{User|Argent Stonecutter}}<br /> * {{jira|VWR-6381}} - Votes: 2 - Client eats first character after new / if typed too soon - {{User|Feynt Mistral}}<br /> * {{jira|VWR-6436}} - Votes: 2 - zoom and alt-cam not working - {{User|Barbidule McBride}}<br /> * {{jira|VWR-6484}} - Votes: 2 - Minimap height indicators all show "lower than me" if over the old 768 build ceiling - {{User|Buckaroo Mu}}<br /> * {{jira|VWR-6498}} - Votes: 2 - Checkmark missing when Slow Animations enabled - {{User|Whichway Janus}}<br /> * {{jira|VWR-6501}} - Votes: 2 - Objects rotate wildly in edit mode with 3dconnexion Space Navigator plugged in - {{User|Hypatia Callisto}}<br /> * {{jira|VWR-6707}} - Votes: 2 - 1.20 - Crash on Login/Frequent Crashing - {{User|Lazure Ryba}}<br /> * {{jira|VWR-6802}} - Votes: 2 - Enabling beacons instantly crashes viewer - {{User|Selkit Diller}}<br /> * {{jira|VWR-6833}} - Votes: 2 - 1.20.3 Crash on Login/During Essential InWorld Activitys - {{User|Kitty Hirsch}}<br /> * {{jira|VWR-6772}} - Votes: 2 - Identical sculpties stuck in different stages of loading. - {{User|Katarina Malthus}}<br /> * {{jira|VWR-6856}} - Votes: 2 - Anti-Aliasing AND shaders on makes SL completely useless on Intel iMac since 1.20 RC3 - {{User|Vala Vella}}<br /> * {{jira|VWR-6828}} - Votes: 2 - Character > Show Look At doesn't work - {{User|Hachiro Yokosuka}}<br /> * {{jira|VWR-6889}} - Votes: 2 - Unable to leave group when role has no allowed abilities - {{User|Geraldine Giha}}<br /> * {{jira|VWR-6699}} - Votes: 2 - Shaders are disabled on supported video card - {{User|Deany Fall}}<br /> * {{jira|VWR-6246}} - Votes: 1 - All Menu items seem to be disabled, and right clicking anywhere in world causes a jump, not a Pie Menu. - {{User|Robin Sojourner}}<br /> * {{jira|VWR-6252}} - Votes: 1 - Alerts and Notifications on new UI need more contrast or color. - {{User|rena kuhn}}<br /> * {{jira|VWR-6300}} - Votes: 1 - RC outputs wrong value type when importing from settings.xml - {{User|Kitty Barnett}}<br /> * {{jira|VWR-6733}} - Votes: 1 - Second Life Crashes the Nvidia driver - {{User|Wolf Seisenbacher}}<br /> * {{jira|VWR-6440}} - Votes: 1 - Distance to target not visible at some angles - {{User|BlueWall Slade}}<br /> * {{jira|VWR-6481}} - Votes: 1 - Joystick Support: Moving camera around avatar with flycam turns avatar around when in mouselook - {{User|Domchi Underwood}}<br /> * {{jira|VWR-6483}} - Votes: 1 - Changing Advanced->Rendering->Info Displays blanks all HUD llSetText. - {{User|Buckaroo Mu}}<br /> * {{jira|VWR-6499}} - Votes: 1 - Banlines now visible through prims - {{User|Aki Shichiroji}}<br /> * {{jira|VWR-6563}} - Votes: 1 - New Viewers 1.19 and 1.20 both regular client and First Look client have started TEXTURES FROM INVENTORY ON ITEMS IN WORLD FLUCTUATING - {{User|lauren weyland}}<br /> * {{jira|VWR-6586}} - Votes: 1 - Scale values in Avatar mode on 3DConnexion controller appear to do nothing - {{User|CodeWarrior Carling}}<br /> * {{jira|VWR-6587}} - Votes: 1 - Scale values in avatar column of joystick preferences always reset to '1.0' when you exit and restart - {{User|CodeWarrior Carling}}<br /> * {{jira|VWR-6623}} - Votes: 1 - After downloading 1.20.18 I can not install I get 30 "error can not open for writing" messages most are .dll or db2 files - {{User|Chandra Jun}}<br /> * {{jira|VWR-6626}} - Votes: 1 - Spacenavigator Not Recognised MacOS - {{User|Chance Unknown}}<br /> * {{jira|VWR-6697}} - Votes: 1 - RC 1.20.2 (85278): System freeze after login under linux - {{User|Suzan Littlething}}<br /> * {{jira|VWR-6653}} - Votes: 1 - Anti-ailiasing no longer visible on mac client - {{User|Court Goodman}}<br /> * {{jira|VWR-6683}} - Votes: 1 - 1.20RC2 - Immediate crash when clicking OK on blue pop-up window (MacOs) - {{User|samia bechir}}<br /> * {{jira|VWR-6788}} - Votes: 1 - Ctrl-Alt-LMouseclick on avatar zoomes camera out instead of focusing on avatar - {{User|Aryan Saphir}}<br /> * {{jira|VWR-6579}} - Votes: 1 - Terribly incorrect culling of textures in 1.20 on macbook pro - {{User|Wood Fairey}}<br /> * {{jira|VWR-6871}} - Votes: 1 - Immediate crash (100% of the time) when choosing menu: View / Land Owners - {{User|Master Quatro}}<br /> * {{jira|VWR-6848}} - Votes: 1 - Space Navigator does not function when other game controller device is already known by Windows - {{User|Ronald Richez}}<br /> * {{jira|VWR-6740}} - Votes: 1 - SpaceNavigator input cross-talk to other apps - {{User|Whichway Janus}}<br /> * {{jira|VWR-6865}} - Votes: 1 - Terrain texture not loading properly (only displaying high/4th ground texture) - {{User|Vixen Fairplay}}<br /> * {{jira|VWR-6912}} - Votes: 1 - Mac Pro / multicore - one core rises to 100% causing temporary freeze - {{User|Court Goodman}}<br /> * {{jira|VWR-6212}} - Votes: 0 - Viewer eats typed text when using imput method in Linux - {{User|Yukinoroh Kamachi}}<br /> * {{jira|VWR-6238}} - Votes: 0 - New viewer is auto logging in if password is saved without providing option to change account name.- - {{User|lenore contepomi}}<br /> * {{jira|VWR-6242}} - Votes: 0 - Dazzle client forced dl this evening, geometric shapes dissect avitars and prims when there is nothing in reality there, things like ocean waves/windows/glass features are red *and not the ctl alt T* option - {{User|tandee ashbourne}}<br /> * {{jira|VWR-6255}} - Votes: 0 - Randomly unreadably text, corrupted text, distorted text. - {{User|SuperMax Hax}}<br /> * {{jira|VWR-6258}} - Votes: 0 - L$ balance is shown in hard-to-read color. - {{User|Ephyu Reino}}<br /> * {{jira|VWR-6277}} - Votes: 0 - Viewer resets screen resolution to 1024 x 768 on startup - {{User|Prajna Vella}}<br /> * {{jira|VWR-6281}} - Votes: 0 - WL 1.20 Bugs and Feedback - {{User|Contessa Esposito}}<br /> * {{jira|VWR-6288}} - Votes: 0 - Childprim needs about 5 seconds to move if position is changed with spinEdit buttons from Object window - {{User|Aares Torok}}<br /> * {{jira|VWR-6289}} - Votes: 0 - Camera floats around in view on its own as if it is attached to a moving object when in public areas (i.e. clubs stores) - {{User|kaj qinan}}<br /> * {{jira|VWR-6292}} - Votes: 0 - Avatar Animations stop,start, malfunction in Release candidate 1.20.0 - {{User|rezit sideways}}<br /> * {{jira|VWR-6332}} - Votes: 0 - involuntary av movement, sticky camera, no groups, no eyes, frequent crashes - {{User|Alger Meads}}<br /> * {{jira|VWR-6336}} - Votes: 0 - World Map "Landmarks" dropdown doesn't work - {{User|Jeremy Ondricek}}<br /> * {{jira|VWR-6347}} - Votes: 0 - Selected texture still stays selected after changing to another edit mode. - {{User|gearsawe stonecutter}}<br /> * {{jira|VWR-6349}} - Votes: 0 - Dazzle-<RC0> Windows gaining an extera button - {{User|Daten Thielt}}<br /> * {{jira|VWR-6378}} - Votes: 0 - Second Life 1.20.0 (84432) Always show beacons Reactivates itself after each startup after being disabled. - {{User|Vengence Keon}}<br /> * {{jira|VWR-6366}} - Votes: 0 - Audio device autoselection inconsistency - {{User|Dusty Perl}}<br /> * {{jira|VWR-6374}} - Votes: 0 - Strange behaviour - {{User|Thasha Ansome}}<br /> * {{jira|VWR-6388}} - Votes: 0 - Corrupted Verticies - {{User|Zion Tristan}}<br /> * {{jira|VWR-6404}} - Votes: 0 - 1.20 RC does not handle damage control when browsing for cache file location - {{User|Whichway Janus}}<br /> * {{jira|VWR-6412}} - Votes: 0 - Scrolling in LSL Editor is bugged (parts left out) - {{User|Tillie Ariantho}}<br /> * {{jira|VWR-6413}} - Votes: 0 - Text output: characters are jumping when scrolling in editors or moving windows - {{User|Tillie Ariantho}}<br /> * {{jira|VWR-6423}} - Votes: 0 - Anti-Aliasing blurs every other Line in Dazzle. - {{User|ciaran flasheart}}<br /> * {{jira|VWR-6418}} - Votes: 0 - Snapshot settings not remembered inbetween logins (when running SL from Disk Image) - {{User|Daedalus Young}}<br /> * {{jira|VWR-6426}} - Votes: 0 - Constantly crashing when building over 768m. - {{User|Darek Deluca}}<br /> * {{jira|VWR-6438}} - Votes: 0 - Editing prim position while being sat on causes oscillations - {{User|BlueWall Slade}}<br /> * {{jira|VWR-6444}} - Votes: 0 - Command button labels are placed badly - {{User|Alissa Sabre}}<br /> * {{jira|VWR-6472}} - Votes: 0 - Mac client: Glow characteristic - {{User|Nad Gough}}<br /> * {{jira|VWR-6471}} - Votes: 0 - Mac client - preferences are not saved - {{User|Nad Gough}}<br /> * {{jira|VWR-6479}} - Votes: 0 - Joystick support: Roll Scale default is broken since 1.20 RC - {{User|Domchi Underwood}}<br /> * {{jira|VWR-6507}} - Votes: 0 - Menu does not respond to mouse-clicks in Mac version of viewer - {{User|Pyter Morgridge}}<br /> * {{jira|VWR-6516}} - Votes: 0 - Avatar baked textures wrong after crash or teleport - {{User|Whichway Janus}}<br /> * {{jira|VWR-6518}} - Votes: 0 - 'N' for North 'missing' on World Map - {{User|Daedalus Young}}<br /> * {{jira|VWR-6555}} - Votes: 0 - Viewer 1.20.0 freezes when viewing certain huge prims - {{User|Zyzzy Zarf}}<br /> * {{jira|VWR-6561}} - Votes: 0 - Wireless Mighty Mouse stops responding and freezes BlueTooth Keyboard too until turned off and on - {{User|anthea shilova}}<br /> * {{jira|VWR-6566}} - Votes: 0 - Recent Items "since logoff" random - {{User|Frank Skosh}}<br /> * {{jira|VWR-6567}} - Votes: 0 - Joystick Support: Settings scaled differently between Mac and PC - {{User|Aimee Trescothick}}<br /> * {{jira|VWR-6592}} - Votes: 0 - Joystick - simultaneous walking/flying and turning, turning is unresponsive - {{User|Jorgen Friis}}<br /> * {{jira|VWR-6597}} - Votes: 0 - Can't save texture memory size in preference-hardware - {{User|maverick offcourse}}<br /> * {{jira|VWR-6599}} - Votes: 0 - Snap to grid feature problem - {{User|Cago Hax}}<br /> * {{jira|VWR-6628}} - Votes: 0 - Release Candidate 1.20.1 for Mac: Menu commands fail, camera fails to recenter, camera hair trigger snaps back to default with mouse clicks in inventory - {{User|Sky Hye}}<br /> * {{jira|VWR-6635}} - Votes: 0 - Ever since 1.20RC my graphics have been screwy. I use GeForce Go 7900 GS/PCI/SSE2 and never had a problem, but now, there are several visual issues. - {{User|Everett Streeter}}<br /> * {{jira|VWR-6638}} - Votes: 0 - Cannot log in - {{User|Aphrodite Tagore}}<br /> * {{jira|VWR-6647}} - Votes: 0 - Setting the joystick feathering above the default results in an undamped oscillation of the view with a SpaceNavigator - {{User|Ralph Doctorow}}<br /> * {{jira|VWR-6700}} - Votes: 0 - Windows Vista Reverts to Basic Colour Scheme - {{User|Tribal Toland}}<br /> * {{jira|VWR-6705}} - Votes: 0 - Unable to click / use HUD when in mouselook - {{User|ryder spearmann}}<br /> * {{jira|VWR-6723}} - Votes: 0 - Zooby's Rezzable Pets getting lost - {{User|Sahoni Tigerpaw}}<br /> * {{jira|VWR-6731}} - Votes: 0 - clothes are being retextured with screenshot - {{User|cardi dragonash}}<br /> * {{jira|VWR-6732}} - Votes: 0 - Viewer crashes on left-clicks on vendors, URL-givers etc. - {{User|moni duettmann}}<br /> * {{jira|VWR-6749}} - Votes: 0 - Missing file in source code, ll_icon.png - {{User|Balp Allen}}<br /> * {{jira|VWR-6746}} - Votes: 0 - Health Percentage Unreadable - {{User|Frank Skosh}}<br /> * {{jira|VWR-6754}} - Votes: 0 - Error in floater_instant_message_group.xml - {{User|McCabe Maxsted}}<br /> * {{jira|VWR-6652}} - Votes: 0 - client crash/Script- brightness and denial of service - {{User|Heron Halberstadt}}<br /> * {{jira|VWR-6655}} - Votes: 0 - Glow appears at the lower hem of loose shirt-layer clothing in both the lastest RC viewer, and the regular 1.19 viewer. - {{User|Max Kleiber}}<br /> * {{jira|VWR-6758}} - Votes: 0 - Log message on console are bold. - {{User|Balp Allen}}<br /> * {{jira|VWR-6659}} - Votes: 0 - Second life renders graphics incorrectly during and after appearence modifications. - {{User|Navin Dawes}}<br /> * {{jira|VWR-6661}} - Votes: 0 - weird colours top 1/4 - 3/4 of screen - freezes comp - {{User|Garn Conover}}<br /> * {{jira|VWR-6663}} - Votes: 0 - 16x Antialias blurs UI and chat text - {{User|myf mcmahon}}<br /> * {{jira|VWR-6666}} - Votes: 0 - Enabling Basic Shaders Freezes Display on Mac - {{User|Sunn Thunders}}<br /> * {{jira|VWR-6664}} - Votes: 0 - avatar impostering fails in some locations. - {{User|Bubba Loring}}<br /> * {{jira|VWR-6681}} - Votes: 0 - Seeing gray instead of "MISSING IMAGE" - {{User|Day Oh}}<br /> * {{jira|VWR-6684}} - Votes: 0 - Must right-click "touch" scripted objects for them to work. - {{User|Spook Maroon}}<br /> * {{jira|VWR-6692}} - Votes: 0 - My screen is completely black with everything else working and being normal. - {{User|johnnie markova}}<br /> * {{jira|VWR-6799}} - Votes: 0 - Tool box showing up at random - {{User|Nedrae Messmer}}<br /> * {{jira|VWR-6801}} - Votes: 0 - Classic Clouds are pitch Black - {{User|WarKirby Magojiro}}<br /> * {{jira|VWR-6815}} - Votes: 0 - 1.20. rc3 can crash hard enough to disable windows security components in xp - {{User|Cummere Mayo}}<br /> * {{jira|VWR-6820}} - Votes: 0 - Cannot download RC 1.20.3 - {{User|gozo aya}}<br /> * {{jira|VWR-6825}} - Votes: 0 - Crash on Login with 1.20 RC3 - {{User|aaron23 decuir}}<br /> * {{jira|VWR-6830}} - Votes: 0 - newest Release Candidate 1.20 crashes upon launching - {{User|Julian2914 Hifeng}}<br /> * {{jira|VWR-6838}} - Votes: 0 - IM logging set to "off" in prefs, but IM window warns logging is taking place - {{User|surty slok}}<br /> * {{jira|VWR-6852}} - Votes: 0 - Render Axes renders at the Sim corner - {{User|Luke Poplin}}<br /> * {{jira|VWR-6854}} - Votes: 0 - Crash at startup, before login screen - {{User|Cris Fargis}}<br /> * {{jira|VWR-6859}} - Votes: 0 - When the browser of the default of PC is started from the built-in browser of viewer, the text editor of PC appears simultaneously - {{User|Rado Arado}}<br /> * {{jira|VWR-6861}} - Votes: 0 - Viewer Memory Grows without bound - {{User|tommy3141 wunderland}}<br /> * {{jira|VWR-6862}} - Votes: 0 - Flexi Prim's don't recognise attributes. - {{User|Soap Clawtooth}}<br /> * {{jira|VWR-6866}} - Votes: 0 - Built in Web Browers - {{User|Cookie Lewis}}<br /> * {{jira|VWR-6878}} - Votes: 0 - Existing inventory objects randomly and suddenly refuse to attach or rez in-world - {{User|Masha Eilde}}<br /> * {{jira|VWR-6879}} - Votes: 0 - Edge of window Pie menu problems - {{User|JPT62089 Agnon}}<br /> * {{jira|VWR-6864}} - Votes: 0 - Cannot fly in RC 1.20(4) Mac - {{User|Vivienne Schell}}<br /> * {{jira|VWR-6414}} - Votes: 0 - Crassoon after log in - {{User|Thasha Ansome}}<br /> * {{jira|VWR-6872}} - Votes: 0 - 1.20 RC4 - Crashes when swiveling using camera (ctrl-alt keys) - {{User|franke Lytton}}<br /> * {{jira|VWR-6885}} - Votes: 0 - Crash soon after logging into "last location" - {{User|Skinkie Winkler}}<br /> * {{jira|VWR-6890}} - Votes: 0 - ampty avi after tp or start sl - {{User|Rick Alvarez}}<br /> * {{jira|VWR-6401}} - Votes: 0 - Grey people - {{User|Davec Horsforth}}<br /> * {{jira|VWR-6460}} - Votes: 0 - UV-mapping error in sculpties viewed with lower LOD. - {{User|Moon Metty}}<br /> * {{jira|VWR-6868}} - Votes: 0 - Release Candidate crashes BEFORE login screen - {{User|Brenda Maculate}}<br /> * {{jira|VWR-6869}} - Votes: 0 - Constant frequent hangs of my system with spacenavigator - {{User|Spook Maroon}}<br /> * {{jira|VWR-6902}} - Votes: 0 - Cancel Button is Grayed Out In Install - {{User|Generic Latte}}<br /> * {{jira|VWR-6906}} - Votes: 0 - Graphic glithc at sea angles of the sim - {{User|Naiman Broome}}<br /> * {{jira|VWR-6901}} - Votes: 0 - Ability to Transfer NoTransfer Script Inside "Full Perm" Prim - {{User|Loella Lusch}}<br /> * {{jira|VWR-6924}} - Votes: 0 - Map slows viewer to a crawl, induces camera/avatar rotation - {{User|Lindal Kidd}}<br /> * {{jira|VWR-6929}} - Votes: 0 - Show in seach feature is not working properly - {{User|cricket mcmahon}}<br /> * {{jira|VWR-6930}} - Votes: 0 - 1.20.4 (85828) viewer crashes repeatedly - {{User|Frederich Courier}}<br /> * {{jira|VWR-6888}} - Votes: 0 - Selecting View => Land Owners generates a crash - {{User|Garmin Kawaguichi}}<br /> * {{jira|VWR-6933}} - Votes: 0 - Disabling Ripple Water also disables glow - {{User|Nedrae Messmer}}<br /> * {{jira|VWR-6936}} - Votes: 0 - Texture console shows constant list of unloadable asset keys. - {{User|Allen Kerensky}}<br /> * {{jira|VWR-6942}} - Votes: 0 - Avatar Renders Black when Anti Aliasing enabled in RC 1.20 - {{User|Vivienne Schell}}<br /> * {{jira|VWR-6943}} - Votes: 0 - New group chats do not open at the bottom of the session when the tab is clicked the first time - {{User|Kasey Kyger}}<br /> * {{jira|VWR-6937}} - Votes: 0 - Chatbar ignores position setting in panel_chat_bar.xml - {{User|McCabe Maxsted}}<br /> * {{jira|VWR-6917}} - Votes: 0 - scim exit causes crash of SL viewer on linux - {{User|Fred Huffhines}}<br /> * {{jira|VWR-6953}} - Votes: 0 - Flexi cylinders have strange, unnecessary twists in them - {{User|tenebrous pau}}<br /> * {{jira|VWR-6948}} - Votes: 0 - Flexi prims rendered differently - breaks products - {{User|Balpien Hammerer}}<br /> * {{jira|VWR-6959}} - Votes: 0 - sl harms my poor X... - {{User|01 Hifeng}}<br /> <br /> == Fast Track Import ==<br /> <br /> (Move bugs here that have solid repros, or valid patches that you have reviewed)<br /> <br /> == Hot by Vote ==<br /> <br /> [http://www.sljirastats.com/jira_search.php?search=33&output=wiki High Voted Bugs]<br /> <br /> == Patches ==<br /> [http://www.sljirastats.com/jira_search.php?search=34&output=wiki Patches]<br /> <br /> == Misc Pool ==<br /> [http://www.sljirastats.com/jira_search.php?search=35&output=wiki Misc Pool]<br /> <br /> == Pre-meeting activity ==<br /> <br /> Some issues will be resolved in the course of building this agenda. Rather than deleting them from the proposed agenda, move the issue and associated discussion into the appropriate section below.<br /> <br /> === Imported ===<br /> <br /> === Resolved ===<br /> * {{jira|VWR-6807}} - Votes: 8 - Glow not working in rc2/rc3 - {{User|dimentox travanti}}<br /> ** Resolved Fix Pending!<br /> * {{jira|VWR-6253}} - Votes: 3 - Capturing hi-res screenshots is impossible without distortion - {{User|Net Antwerp}}<br /> ** Dupe of VWR-4825<br /> * {{jira|VWR-6680}} - Votes: 4 - Tools > Show Hidden Selection has no effect - {{User|Nargus Asturias}}<br /> ** Resolved 'could not repro'<br /> <br /> <br /> == Transcript ==<br /> Transcript is/will be at [[{{PAGENAME}}/Transcript]]<br /> <br /> == Creating An Agenda ==<br /> {{Bug List Instructions}}</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Bug_triage/2007-11-19&diff=40939 Bug triage/2007-11-19 2007-11-19T18:52:15Z

<p>Matthew Dowd: /* Misc Pool */</p> <hr /> <div>{{Bug triage}}<br /> <br /> Next meeting: 2007-11-19 at Monday, 12pm PST at the [http://slurl.com/secondlife/Hippotropolis/239/28/24/?img=https%3A//wiki.secondlife.com/w/images/9/91/Opensource_meetings_at_Hippotropolis.jpg Hippotropolis Meeting area]<br /> <br /> == Features ==<br /> <br /> :This one isn't a top voted feature (yet), but between the bug and associated feature, it's near the top. [[User:Gigs Taggart|Gigs Taggart]]<br /> * {{jira|SVC-913}} - Votes: 69 - Allow LSL scripts to act as HTTP servers in order to replace XMLRPC with something scalable - {{User|Sean Linden}}<br /> * {{jira|SVC-29}} - Votes: 94 - XMLRPC sporadically (but usually) very slow - {{User|Apotheus Silverman}}<br /> <br /> <br /> * {{jira|WEB-382}} - Votes: 2 - Bugs and Proposals on the JIRA Cannot Be Closed or Moved Without Author Consent - {{User|Prokofy Neva}}<br /> * {{jira|VWR-3071}} - Votes: 1 - Objects Set for Sale should not default to "Show in Search" - {{User|Prokofy Neva}}<br /> <br /> Ping on {{jira|VWR-442}}<br /> <br /> == Fast Track Import ==<br /> <br /> (Move bugs here that have solid repros, or valid patches that you have reviewed)<br /> <br /> * {{jira|WEB-383}} - Votes: 0 - membership plans page is out of date - {{User|Gigs Taggart}}<br /> <br /> <br /> == Hot by Vote ==<br /> <br /> * {{jira|WEB-380}} - Votes: 11 - "Fixed Internally" should not appear as "Resolved" in JIRA; voting should continue - {{User|Ordinal Malaprop}}<br /> * {{jira|MISC-488}} - Votes: 12 - rez objects only works if i'm online - {{User|october brotherhood}}<br /> <br /> <br /> == Patches ==<br /> <br /> * {{jira|VWR-3272}} - Votes: 3 - Shader support removed in Windlight for some cards that work well (when it is re-enabled) - {{User|Abyssin Otoro}}<br /> * {{jira|VWR-3265}} - Votes: 0 - IM Tabs stack vertical rather than horizontal (Yet another solution to the communicate window) - {{User|Matthew Dowd}}<br /> * {{jira|VWR-3206}} - Votes: 0 - OpenJPEG svn478 causes slviewer to crash - {{User|Seg Baphomet}}<br /> * {{jira|VWR-3202}} - Votes: 0 - Make chat console background color customizable - {{User|Jacek Antonelli}}<br /> * {{jira|VWR-3093}} - Votes: 1 - Allow MU* (MUCK, MUSH, MUX, MUD) like "poses" (=IRC emotes) in chat and IMs. - {{User|Henri Beauchamp}}<br /> * {{jira|VWR-3087}} - Votes: 2 - Allow for hiding the "Release Keys" button and "Master Remote" volume control. - {{User|Henri Beauchamp}}<br /> * {{jira|VWR-3060}} - Votes: 0 - Add a setting to hide the IMs in the main chat. - {{User|Henri Beauchamp}}<br /> * {{jira|VWR-1917}} - Votes: 8 - Have Friends and Groups display in a seperate window when accessed via menus. Add short cut for Groups - {{User|Matthew Dowd}}<br /> * {{jira|VWR-1549}} - Votes: 7 - Move Friends and Groups tabs from left to bottom - {{User|Matthew Dowd}}<br /> <br /> <br /> == Misc Pool ==<br /> <br /> <br /> * {{jira|VWR-2051}} - Votes: 111 - Regular viewer freezes since update to Voice viewer - added to agenda by {{User|Matthew Dowd}}<br /> : Update needed - this is a CRITICAL issue which can render SL unusable and is affecting a large number of users. We need an update on what LL is doing to fix this, and the timescale for a fix. <br /> * {{jira|VWR-1793}} - Votes: 11 - Hand Poses Not Uploaded Correctly - {{User|cracker hax}}<br /> * {{jira|VWR-2394}} - Votes: 10 - SLRR Trains Keep Disappearing - {{User|Haravikk Mistral}}<br /> * {{jira|VWR-3125}} - Votes: 9 - Washed out textures on WindLight - {{User|babette sivocci}}<br /> * {{jira|VWR-1402}} - Votes: 9 - Avatar eye's turn Black - {{User|lucian overlord}}<br /> * {{jira|WEB-175}} - Votes: 9 - Credit card not going through (failure then not authorized) - {{User|Rylei Korhonen}}<br /> * {{jira|VWR-3128}} - Votes: 8 - Water disappearing on sims - {{User|ShadowHunter Brokken}}<br /> * {{jira|SVC-625}} - Votes: 8 - Unable to login: Login packet never received by login server - {{User|Larkin Llewellyn}}<br /> * {{jira|SVC-255}} - Votes: 8 - Solid, invisible ghost prims - {{User|WarKirby Magojiro}}<br /> * {{jira|MISC-686}} - Votes: 8 - Eliminate all script delays. - {{User|Deanfred Brandeis}}<br /> * {{jira|VWR-2330}} - Votes: 7 - Attachments rezz at the wrong place after TP - {{User|Joshua Philgarlic}}<br /> * {{jira|VWR-1549}} - Votes: 7 - Move Friends and Groups tabs from left to bottom - {{User|Matthew Dowd}}<br /> * {{jira|SVC-954}} - Votes: 7 - Deleted user's Objects cannot be removed in bulk using the Estate Manager window. - {{User|Miscellaneous Fluffy}}<br /> * {{jira|VWR-3133}} - Votes: 7 - Meta-Issue: WindLight: Bringing shiny on par with non-WindLight viewer (and beyond) - {{User|Elle Pollack}}<br /> * {{jira|VWR-954}} - Votes: 7 - Objects flash changing every texture I have....sometimes all trees, sometimes walls, sometimes avatars...never know what. - {{User|lauren weyland}}<br /> * {{jira|VWR-877}} - Votes: 7 - Receiving private IMs that appear to be group IMs from groups I am not a member of - {{User|Ann Otoole}}<br /> * {{jira|VWR-520}} - Votes: 4 - Mesa3D Software OpenGL fallback support in Windows clients {{User|Kamilion Schnook}}<br /> <br /> == Pre-meeting activity ==<br /> <br /> Some issues will be resolved in the course of building this agenda. Rather than deleting them from the proposed agenda, move the issue and associated discussion into the appropriate section below.<br /> <br /> === Imported ===<br /> <br /> === Resolved ===<br /> * {{jira|VWR-3004}} - Votes: 13 - random crashes on recent linux clients - {{User|tx Oh}}<br /> :A little vague, and original reporter and others have reported lower levels of crashing now [[User:Gigs Taggart|Gigs Taggart]]<br /> <br /> == Transcript ==<br /> Transcript is/will be at [[{{PAGENAME}}/Transcript]]<br /> <br /> == Creating An Agenda ==<br /> {{Bug List Instructions}}</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Viewer_Authentication_Critique&diff=34268 Viewer Authentication Critique 2007-10-03T18:13:10Z

<p>Matthew Dowd: /* Note */</p> <hr /> <div>This is a formal critique of [[Viewer Authentication]] that was [https://lists.secondlife.com/pipermail/sldev/2007-September/005403.html requested] by [[User:Rob Linden]] on the [[SLDev]] mailing list.<br /> <br /> For a branch of the discussion see [https://wiki.secondlife.com/wiki/Talk:Viewer_Authentication Talk page on the original proposal.]<br /> <br /> == Note ==<br /> <br /> It was not explicit in the original article what the motivations behind LL's proposed new authentication system are. The goals (Security, Flexibility, Persistence) and benefits listed here are what SLDev believe them to be based on the original description and e-mail discussions.<br /> <br /> == Summary ==<br /> <br /> There are currently no known password capturing third party viewers in the wild, and a third party viewer requires such a privilege level of access to an account anyway that if you don't trust it with your username and password, you shouldn't be running it anyway. The mechanism proposed, however, is more prone to phishing attacks in the it would acclimatise users to starting the viewer via a web page. At present most password compromises are probably due to weaknesses in the current protocol challenge response, due to allowing weak passwords, due to security compromises in the LL websites or due to the usual phishing e-mails (which are likely to be increased by the proposed method rather than decreased).<br /> <br /> Providing a single authentication mechanism for LL (and third party) websites would be an improvement to multiple backend copies of username and password, however this could be implemented without touching the viewer authentication method. Support for OpenID and other identity metasystems would increase the flexibility and offer features such as brokered identity verification. However, these would only be part of the solution, and although the proposed mechanism would provide a way for future support of these, there are other ways this could be achieved. Future support for OpenID is perhaps a topic for a seperate discussion and debate, but a open debate on this should happen.<br /> <br /> There seems to be no real demand to synchronise the authentication of the viewer with authentication on the SL web site (account, forums, etc.), and any benefits gained would be negated by the problems this would cause anyone running alts (e.g. for in world permissions testing etc.) or multiple viewers (e.g. main, test and firstlook). It also raises problems for those running OpenSim based Grids, and may also cause difficulties further down the line as regards the new architecture discussions. A relatively simpler mod to the web site could prevent the account details for a different alt displaying when the account menu options are selected in the client. There is an argument that the seperating the passwords and logon for the forums would actually improve security.<br /> <br /> The suggestion of provided an embedded way of displaying the web form within the viewer so that you will not have to always start the viewer from a web browser is a non-starter, not just because of problems with the current code in handling web proxies, but because it would be very easy for the embedded web form handling code to log the form data before POSTing to the web site thus undermining any benefits gained.<br /> <br /> Overall, the additional development time both with LL and for external developers doesn't seem to warrant the promoted benefits.<br /> <br /> It was also noted that consideration should be given when considering enhancements to the security/authentication models whether these should be optional - allowing users to make their own risk/convenience decisions.<br /> <br /> == Security ==<br /> <br /> === Benefits Stated By LL ===<br /> * To mitigate the danger of password capturing Trojans masquerading as third party viewers<br /> * Improve trust in third party viewers by providing a means of assurance to the user that the third party viewer could not be a Trojan capturing usernames and passwords.<br /> * To consolidate the authentication implementation in order to support back-end anti-fraud work<br /> <br /> === Pros ===<br /> * Viewer does not have to process (and "see") username and password<br /> <br /> === Cons ===<br /> * The main risk of running a third party viewer (or any other application not provided by Linden Labs) is not stealing passwords, it's direct attacks through the client... and the "official" client is not really any protection against that.<br /> ** Viewer can still be used in direct and indirect attacks even if it never sees the password (for example: salami slicing through cutout accounts, acting as a cutout account or an in-world botnet, faking a failed connection while giving an attacker access).<br /> ** NON-viewer applications (such as editors, 3d tools) designed for use by SL residents could use a keystroke logger and macro to perform any of these attacks, or could inject code into the viewer to do the same thing. Look at 'cheating' programs in combat MMORPGs for ideas.<br /> * But this is still not a large risk, unless people get the client through a mechanism that makes the creator anonymous. Historically, attempts to disseminate boobytrapped versions of applications have only worked in environments where it's routine for people to download applications from anonymous sources (file areas in the BBS era, for example). It's too easy to trace down the originator of any compromised client when you're getting them from their own website.<br /> <br><br /> * Bottom line here is that third party viewers stealing passwords are a very small risk for the user: the bigger risk is from the web browser!<br /> ** Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.<br /> *** This kind of attack is not theoretical, phishing websites are a criminal industry.<br /> *** It would be very easy to set up a temporary (i.e. hard to trace the real owner) phishing webpage which looks like the official SL logon, and send e-mails such as "You've received xxx in SL, Click here to logon" apparently from LL - with far less work than trying to create, and entice people to download a trojan viewer<br /> ** Relies on browser security, and uses a mechanism often disabled or filtered due to security concerns<br /> ** Too reliant on browser/OS implementations (proxies, firewalls, used browsers, etc.)<br /> * So using the browser to perform the authentication moves the authentication to a mechanism that has historically proven more likely to be compromised.<br /> <br><br /> * And the mechanism itself is relatively inflexible.<br /> ** Links to secondlife:// can only point to one instance (version, e.g. homebrew, release candidate official) of the program<br /> ** Links to secondlife:// can not pass parameters to the program<br /> *** In fact allowing that was a security flaw recently found and fixed in the SL client. :(<br /> ** It will raise problems for those running alternative (e.g. OpenSim) grids, and also have impact on the dicussions for a future open grid<br /> <br><br /> * It is suggested that the viewer will embed the web form within the viewer -<br /> ** This escalates the importance of addressing a number of current problems with llmozlib in the current viewer code:<br /> *** there are problems compiling llmozlib on the Linux platform<br /> *** proxies are not supported<br /> ** In any case, a modded client easily log the form data before submitting it to the webform, i.e. all the concerns about clients grabbing passwords would still apply!<br /> <br><br /> * Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)<br /> ** The issues raised in the next sections would mean that people would have an incentive to use this kind of client.<br /> <br /> === Alternatives ===<br /> * One time passwords (for copy paste into a non-secure viewer or to print and take with you to friends, internet cafes, public terminals, etc.)<br /> * lower perm passwords (pwds which put the account into a restricted state, disallowing "dangerous" transactions)<br /> * separate passwords for website account and being inworld<br /> * Account restrictions <br /> * Allow third party plug-ins in the viewer (these would allow the extra functionality which are sometimes the reason for running third party viewers, but would rely on the official viewer for validation)<br /> * For considation have a single backend web service which does the actual authentication - but which is fronted by GUI frontends (e.g. in the viewer) and web frontends (e.g. for accessing the web based account pages etc.)<br /> * Do nothing, keep everything as it is.<br /> ** Without a strong case for the status quo being a problem, this is certainly a viable alternative, particularly given the impact this will have on developers of third party tools and viewers<br /> ** It is arguable that most losses of assets and value are incurred due to SL bugs (inventory, classifieds search, etc.) and outtages rather than through account compromises<br /> <br><br /> * Log of successful or failed login attempts including ip address (or at least a notice of the last attempt)<br /> * Black, White or Greylist IP (specific or > network ranges)- This would allow someone with a static, or semi-static IP to prevent client logons to their account unless they appear on the Whitelist of approved IP's. Greylisting would allow one login attempt every 5-10 minutes and could be used when traveling. > IP's on the blacklist would not be able to log into the account at all<br /> ** Question: how many people have, or even know they have, static or semi static IPs?<br /> * Lock account if too many consecutive logon requests (to prevent automated dictionary attacks) - a user should be able to unlock an account via the website using additional validation such as CAPTCHA's and providing additional information on file such as date of birth.<br /> <br><br /> * This may be the wrong problem - password compromises are more likely to be through standard phishing attacks (logon here to update your account info) which is not addressed, or by weaknesses in the current authentication mechnism or just insecure passwords.<br /> ** CRAM-MD5 or a similar challenge-response type <br /> *** Note that the proposed authentication mechanism via a web form might prevent any attempt at implementing a challenge-response mechanism<br /> ** Dictionary check to reject insecure passwords<br /> <br /> == Flexibility ==<br /> <br /> === Benefits Stated By LL ===<br /> * Single Sign On - allowing multiple web applications (forums, support, account, jira, wiki etc.) and viewers to use the same username and password through a single point without duplicating usernames and passwords into multiple systems<br /> * Extension of this to allow non-LL applications and web sites to participate in this single sign on system.<br /> <br /> === Pros ===<br /> * Enables username/password authentication to work on third party sites without them having to "see" username and password<br /> <br /> === Cons ===<br /> * This is really an unrelated issue...<br /> ** The client doesn't need to depend on the website for this purpose, or this could be a command line option.<br /> ** The client could just as easily be the 'authentication source' as the website.<br /> *** Via a "go to website" link in the client that passed an equivalent token.<br /> <br><br /> * As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> <br /> === Alternatives ===<br /> * Use this mechanism for websites (including third party) only but not for viewers<br /> <br><br /> * Identity Metasystem - [http://en.wikipedia.org/wiki/Identity_Metasystem]<br /> ** OpenID - [http://openid.net/]<br /> ** CardSpace - [http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx]<br /> ** Shibboleth - [http://shibboleth.internet2.edu/]<br /> ** CAS - [http://www.ja-sig.org/products/cas/]<br /> *** These could be handled by the client poping up a window using the internal web browser to connect to a HTML logon. It may be difficult or impossible to determine if the client really is displaying the official HTML logon and not capturing key strokes so this would be a way of implementing the above for flexibility or other reasons (e.g. brokered identity verification [http://www.agimo.gov.au/publications/2004/05/egovt_challenges/privacy/identity/brokered]) not for security<br /> <br /> == Persistence ==<br /> <br /> === Benefits Stated By LL ===<br /> * To synchronise the various LL's systems (forums, support, jira, account, etc.) so that by logging onto one, you are automatically logged onto the others.<br /> <br /> === Pros ===<br /> * Selecting "Account History" or "Manage My Account" and similar menu items would open the web page for the account logged into SL, rather than the account logged into the web site, which currently can be different<br /> <br /> === Cons ===<br /> * As in the previous section, LL's objectives could be met without the viewer logging in via the same mechanism.<br /> * Inconvenient for those with alts or multiple clients<br /> ** Cumbersome to change alts and logon with multiple alts<br /> ** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL<br /> ** As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> * Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.<br /> * Staying online on secondlife.com (which many people seem to do) automatically means anyone with access to the computer/browser (family) can log in with the account inworld<br /> * starting SL from the web browser on a regular basis will most likely result in the web browser lingering in memory in the background when running the viewer, which based on the heavy memory requirement may impair viewer performance.<br /> * this would have an impact on the architecture discussions for a future open grid.<br /> <br /> === Alternatives ===<br /> * As regards menu items such as "Account History", send the account name on the URL, and have the web page check if that is the currently logged on account. If not prompt the user to log on with the same account as being used in the viewer (for security reasons the viewer should not automatically log the account on to the web site in such cases).<br /> * Is this really needed or desirable (''for the client'')? SL is not an extension of the web, it's a different kind of interface... one that has the potential of becoming a "3d web".<br /> * There is an argument that the forum logon should be seperated from the SL account logon<br /> ** This would fit the practice of those using alts, when they only use one account on the forums but would need to check the account details of various alts.<br /> ** Having seperate passwords would isolate security compromises in the forums software from compromising the SL account itself.<br /> <br /> == Signatories ==<br /> <br /> Please sign this below with "<nowiki>~~~~</nowiki>" if you agree with the version of this document you are reading. The date will indicate which version of the document you read and agree with. <br /> <br /> * [[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)<br /> * [[User:Argent Stonecutter|Argent Stonecutter]] 13:53, 29 September 2007 (PDT)<br /> * [[User:Dale Glass|Dale Glass]] 14:28, 29 September 2007 (PDT)<br /> * [[User:Tillie Ariantho|Tillie Ariantho]] 03:48, 30 September 2007 (PDT)<br /> * [[User:Jesse Barnett|Jesse Barnett]] 9:53, 30 September 2007 (PDT)<br /> * [[User:Winter Ventura|Winter Ventura]] 19:42, 29 September 2007 (PDT)<br /> * [[User:Balp Allen|Balp Allen]] 01:33, 30 September 2007 (PDT)<br /> * [[User:Michelle2 Zenovka|Michelle2 Zenovka]] 02:52, 30 September 2007 (PDT)<br /> * [[User:Nicholaz Beresford|Nicholaz]] 03:42, 30 September 2007 (PDT)<br /> * [[User:Dzonatas Sol|Dzonatas Sol]] 06:54, 30 September 2007 (PDT) (Please see my notes: [https://lists.secondlife.com/pipermail/sldev/2007-October/005605.html] [https://lists.secondlife.com/pipermail/sldev/2007-October/005615.html])<br /> * [[User:Eloise Pasteur|Eloise Pasteur]] 06:57, 30 September 2007 (PDT)<br /> * [[User:Becky Tardis|Becky Tardis]] 08:34, 30 September 2007 (PDT)<br /> * [[User:Peter Newell|Peter Newell]] 14:14, 30 September 2007 (PDT)<br /> * [[User:Dr Scofield|Dr Scofield]] 00:45, 1 October 2007 (PDT)<br /> * [[User:Jabath Steuart|Jabath Steuart]] 04:03, 1 October 2007 (PDT)<br /> * [[User:Nik Woodget|Nik Woodget]] 05:19, 1 October 2007 (PDT)<br /> * [[User:Whoops Babii|Whoops Babii]] 05:29, 1 October 2007 (PDT)<br /> * [[User:Feep Larsson|Feep Larsson]] 06:29, 1 October 2007 (PDT)<br /> * [[User:Gibson Willis|Gibson Willis]] 07:11, 1 October 2007 (PDT)<br /> * [[User:Grazer Kline|Grazer Kline]] 10:34, 1 October 2007 (PDT)<br /> * [[User:Odysseus Fairymeadow|Odysseus Fairymeadow]] 13:58, 1 October 2007 (PDT)<br /> * [[User:Melanie Milland|Melanie Milland]] 16:23, 2 October 2007 (PDT)</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Viewer_Authentication_Critique&diff=34255 Viewer Authentication Critique 2007-10-03T11:22:18Z

<p>Matthew Dowd: /* Note */</p> <hr /> <div>This is a formal critique of [[Viewer Authentication]] that was [https://lists.secondlife.com/pipermail/sldev/2007-September/005403.html requested] by [[User:Rob Linden]] on the [[SLDev]] mailing list.<br /> <br /> For a branch of the discussion see [https://wiki.secondlife.com/wiki/Talk:Viewer_Authentication Talk page on the original proposal.]<br /> <br /> == Note ==<br /> <br /> It was not explicitn in the original article what the motivations behind LL's proposed new authentication system are. The goals (Security, Flexibility, Persistence) and benefits listed here are what SLDev believe them to be based on the original description and e-mail discussions.<br /> <br /> == Summary ==<br /> <br /> There are currently no known password capturing third party viewers in the wild, and a third party viewer requires such a privilege level of access to an account anyway that if you don't trust it with your username and password, you shouldn't be running it anyway. The mechanism proposed, however, is more prone to phishing attacks in the it would acclimatise users to starting the viewer via a web page. At present most password compromises are probably due to weaknesses in the current protocol challenge response, due to allowing weak passwords, due to security compromises in the LL websites or due to the usual phishing e-mails (which are likely to be increased by the proposed method rather than decreased).<br /> <br /> Providing a single authentication mechanism for LL (and third party) websites would be an improvement to multiple backend copies of username and password, however this could be implemented without touching the viewer authentication method. Support for OpenID and other identity metasystems would increase the flexibility and offer features such as brokered identity verification. However, these would only be part of the solution, and although the proposed mechanism would provide a way for future support of these, there are other ways this could be achieved. Future support for OpenID is perhaps a topic for a seperate discussion and debate, but a open debate on this should happen.<br /> <br /> There seems to be no real demand to synchronise the authentication of the viewer with authentication on the SL web site (account, forums, etc.), and any benefits gained would be negated by the problems this would cause anyone running alts (e.g. for in world permissions testing etc.) or multiple viewers (e.g. main, test and firstlook). It also raises problems for those running OpenSim based Grids, and may also cause difficulties further down the line as regards the new architecture discussions. A relatively simpler mod to the web site could prevent the account details for a different alt displaying when the account menu options are selected in the client. There is an argument that the seperating the passwords and logon for the forums would actually improve security.<br /> <br /> The suggestion of provided an embedded way of displaying the web form within the viewer so that you will not have to always start the viewer from a web browser is a non-starter, not just because of problems with the current code in handling web proxies, but because it would be very easy for the embedded web form handling code to log the form data before POSTing to the web site thus undermining any benefits gained.<br /> <br /> Overall, the additional development time both with LL and for external developers doesn't seem to warrant the promoted benefits.<br /> <br /> It was also noted that consideration should be given when considering enhancements to the security/authentication models whether these should be optional - allowing users to make their own risk/convenience decisions.<br /> <br /> == Security ==<br /> <br /> === Benefits Stated By LL ===<br /> * To mitigate the danger of password capturing Trojans masquerading as third party viewers<br /> * Improve trust in third party viewers by providing a means of assurance to the user that the third party viewer could not be a Trojan capturing usernames and passwords.<br /> * To consolidate the authentication implementation in order to support back-end anti-fraud work<br /> <br /> === Pros ===<br /> * Viewer does not have to process (and "see") username and password<br /> <br /> === Cons ===<br /> * The main risk of running a third party viewer (or any other application not provided by Linden Labs) is not stealing passwords, it's direct attacks through the client... and the "official" client is not really any protection against that.<br /> ** Viewer can still be used in direct and indirect attacks even if it never sees the password (for example: salami slicing through cutout accounts, acting as a cutout account or an in-world botnet, faking a failed connection while giving an attacker access).<br /> ** NON-viewer applications (such as editors, 3d tools) designed for use by SL residents could use a keystroke logger and macro to perform any of these attacks, or could inject code into the viewer to do the same thing. Look at 'cheating' programs in combat MMORPGs for ideas.<br /> * But this is still not a large risk, unless people get the client through a mechanism that makes the creator anonymous. Historically, attempts to disseminate boobytrapped versions of applications have only worked in environments where it's routine for people to download applications from anonymous sources (file areas in the BBS era, for example). It's too easy to trace down the originator of any compromised client when you're getting them from their own website.<br /> <br><br /> * Bottom line here is that third party viewers stealing passwords are a very small risk for the user: the bigger risk is from the web browser!<br /> ** Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.<br /> *** This kind of attack is not theoretical, phishing websites are a criminal industry.<br /> *** It would be very easy to set up a temporary (i.e. hard to trace the real owner) phishing webpage which looks like the official SL logon, and send e-mails such as "You've received xxx in SL, Click here to logon" apparently from LL - with far less work than trying to create, and entice people to download a trojan viewer<br /> ** Relies on browser security, and uses a mechanism often disabled or filtered due to security concerns<br /> ** Too reliant on browser/OS implementations (proxies, firewalls, used browsers, etc.)<br /> * So using the browser to perform the authentication moves the authentication to a mechanism that has historically proven more likely to be compromised.<br /> <br><br /> * And the mechanism itself is relatively inflexible.<br /> ** Links to secondlife:// can only point to one instance (version, e.g. homebrew, release candidate official) of the program<br /> ** Links to secondlife:// can not pass parameters to the program<br /> *** In fact allowing that was a security flaw recently found and fixed in the SL client. :(<br /> ** It will raise problems for those running alternative (e.g. OpenSim) grids, and also have impact on the dicussions for a future open grid<br /> <br><br /> * It is suggested that the viewer will embed the web form within the viewer -<br /> ** This escalates the importance of addressing a number of current problems with llmozlib in the current viewer code:<br /> *** there are problems compiling llmozlib on the Linux platform<br /> *** proxies are not supported<br /> ** In any case, a modded client easily log the form data before submitting it to the webform, i.e. all the concerns about clients grabbing passwords would still apply!<br /> <br><br /> * Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)<br /> ** The issues raised in the next sections would mean that people would have an incentive to use this kind of client.<br /> <br /> === Alternatives ===<br /> * One time passwords (for copy paste into a non-secure viewer or to print and take with you to friends, internet cafes, public terminals, etc.)<br /> * lower perm passwords (pwds which put the account into a restricted state, disallowing "dangerous" transactions)<br /> * separate passwords for website account and being inworld<br /> * Account restrictions <br /> * Allow third party plug-ins in the viewer (these would allow the extra functionality which are sometimes the reason for running third party viewers, but would rely on the official viewer for validation)<br /> * For considation have a single backend web service which does the actual authentication - but which is fronted by GUI frontends (e.g. in the viewer) and web frontends (e.g. for accessing the web based account pages etc.)<br /> * Do nothing, keep everything as it is.<br /> ** Without a strong case for the status quo being a problem, this is certainly a viable alternative, particularly given the impact this will have on developers of third party tools and viewers<br /> ** It is arguable that most losses of assets and value are incurred due to SL bugs (inventory, classifieds search, etc.) and outtages rather than through account compromises<br /> <br><br /> * Log of successful or failed login attempts including ip address (or at least a notice of the last attempt)<br /> * Black, White or Greylist IP (specific or > network ranges)- This would allow someone with a static, or semi-static IP to prevent client logons to their account unless they appear on the Whitelist of approved IP's. Greylisting would allow one login attempt every 5-10 minutes and could be used when traveling. > IP's on the blacklist would not be able to log into the account at all<br /> ** Question: how many people have, or even know they have, static or semi static IPs?<br /> * Lock account if too many consecutive logon requests (to prevent automated dictionary attacks) - a user should be able to unlock an account via the website using additional validation such as CAPTCHA's and providing additional information on file such as date of birth.<br /> <br><br /> * This may be the wrong problem - password compromises are more likely to be through standard phishing attacks (logon here to update your account info) which is not addressed, or by weaknesses in the current authentication mechnism or just insecure passwords.<br /> ** CRAM-MD5 or a similar challenge-response type <br /> *** Note that the proposed authentication mechanism via a web form might prevent any attempt at implementing a challenge-response mechanism<br /> ** Dictionary check to reject insecure passwords<br /> <br /> == Flexibility ==<br /> <br /> === Benefits Stated By LL ===<br /> * Single Sign On - allowing multiple web applications (forums, support, account, jira, wiki etc.) and viewers to use the same username and password through a single point without duplicating usernames and passwords into multiple systems<br /> * Extension of this to allow non-LL applications and web sites to participate in this single sign on system.<br /> <br /> === Pros ===<br /> * Enables username/password authentication to work on third party sites without them having to "see" username and password<br /> <br /> === Cons ===<br /> * This is really an unrelated issue...<br /> ** The client doesn't need to depend on the website for this purpose, or this could be a command line option.<br /> ** The client could just as easily be the 'authentication source' as the website.<br /> *** Via a "go to website" link in the client that passed an equivalent token.<br /> <br><br /> * As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> <br /> === Alternatives ===<br /> * Use this mechanism for websites (including third party) only but not for viewers<br /> <br><br /> * Identity Metasystem - [http://en.wikipedia.org/wiki/Identity_Metasystem]<br /> ** OpenID - [http://openid.net/]<br /> ** CardSpace - [http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx]<br /> ** Shibboleth - [http://shibboleth.internet2.edu/]<br /> ** CAS - [http://www.ja-sig.org/products/cas/]<br /> *** These could be handled by the client poping up a window using the internal web browser to connect to a HTML logon. It may be difficult or impossible to determine if the client really is displaying the official HTML logon and not capturing key strokes so this would be a way of implementing the above for flexibility or other reasons (e.g. brokered identity verification [http://www.agimo.gov.au/publications/2004/05/egovt_challenges/privacy/identity/brokered]) not for security<br /> <br /> == Persistence ==<br /> <br /> === Benefits Stated By LL ===<br /> * To synchronise the various LL's systems (forums, support, jira, account, etc.) so that by logging onto one, you are automatically logged onto the others.<br /> <br /> === Pros ===<br /> * Selecting "Account History" or "Manage My Account" and similar menu items would open the web page for the account logged into SL, rather than the account logged into the web site, which currently can be different<br /> <br /> === Cons ===<br /> * As in the previous section, LL's objectives could be met without the viewer logging in via the same mechanism.<br /> * Inconvenient for those with alts or multiple clients<br /> ** Cumbersome to change alts and logon with multiple alts<br /> ** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL<br /> ** As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> * Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.<br /> * Staying online on secondlife.com (which many people seem to do) automatically means anyone with access to the computer/browser (family) can log in with the account inworld<br /> * starting SL from the web browser on a regular basis will most likely result in the web browser lingering in memory in the background when running the viewer, which based on the heavy memory requirement may impair viewer performance.<br /> * this would have an impact on the architecture discussions for a future open grid.<br /> <br /> === Alternatives ===<br /> * As regards menu items such as "Account History", send the account name on the URL, and have the web page check if that is the currently logged on account. If not prompt the user to log on with the same account as being used in the viewer (for security reasons the viewer should not automatically log the account on to the web site in such cases).<br /> * Is this really needed or desirable (''for the client'')? SL is not an extension of the web, it's a different kind of interface... one that has the potential of becoming a "3d web".<br /> * There is an argument that the forum logon should be seperated from the SL account logon<br /> ** This would fit the practice of those using alts, when they only use one account on the forums but would need to check the account details of various alts.<br /> ** Having seperate passwords would isolate security compromises in the forums software from compromising the SL account itself.<br /> <br /> == Signatories ==<br /> <br /> Please sign this below with "<nowiki>~~~~</nowiki>" if you agree with the version of this document you are reading. The date will indicate which version of the document you read and agree with. <br /> <br /> * [[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)<br /> * [[User:Argent Stonecutter|Argent Stonecutter]] 13:53, 29 September 2007 (PDT)<br /> * [[User:Dale Glass|Dale Glass]] 14:28, 29 September 2007 (PDT)<br /> * [[User:Tillie Ariantho|Tillie Ariantho]] 03:48, 30 September 2007 (PDT)<br /> * [[User:Jesse Barnett|Jesse Barnett]] 9:53, 30 September 2007 (PDT)<br /> * [[User:Winter Ventura|Winter Ventura]] 19:42, 29 September 2007 (PDT)<br /> * [[User:Balp Allen|Balp Allen]] 01:33, 30 September 2007 (PDT)<br /> * [[User:Michelle2 Zenovka|Michelle2 Zenovka]] 02:52, 30 September 2007 (PDT)<br /> * [[User:Nicholaz Beresford|Nicholaz]] 03:42, 30 September 2007 (PDT)<br /> * [[User:Dzonatas Sol|Dzonatas Sol]] 06:54, 30 September 2007 (PDT) (Please see my notes: [https://lists.secondlife.com/pipermail/sldev/2007-October/005605.html] [https://lists.secondlife.com/pipermail/sldev/2007-October/005615.html])<br /> * [[User:Eloise Pasteur|Eloise Pasteur]] 06:57, 30 September 2007 (PDT)<br /> * [[User:Becky Tardis|Becky Tardis]] 08:34, 30 September 2007 (PDT)<br /> * [[User:Peter Newell|Peter Newell]] 14:14, 30 September 2007 (PDT)<br /> * [[User:Dr Scofield|Dr Scofield]] 00:45, 1 October 2007 (PDT)<br /> * [[User:Jabath Steuart|Jabath Steuart]] 04:03, 1 October 2007 (PDT)<br /> * [[User:Nik Woodget|Nik Woodget]] 05:19, 1 October 2007 (PDT)<br /> * [[User:Whoops Babii|Whoops Babii]] 05:29, 1 October 2007 (PDT)<br /> * [[User:Feep Larsson|Feep Larsson]] 06:29, 1 October 2007 (PDT)<br /> * [[User:Gibson Willis|Gibson Willis]] 07:11, 1 October 2007 (PDT)<br /> * [[User:Grazer Kline|Grazer Kline]] 10:34, 1 October 2007 (PDT)<br /> * [[User:Odysseus Fairymeadow|Odysseus Fairymeadow]] 13:58, 1 October 2007 (PDT)<br /> * [[User:Melanie Milland|Melanie Milland]] 16:23, 2 October 2007 (PDT)</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Viewer_Authentication_Critique&diff=34254 Viewer Authentication Critique 2007-10-03T11:18:36Z

<p>Matthew Dowd: Changed Objectives to Benefits.</p> <hr /> <div>This is a formal critique of [[Viewer Authentication]] that was [https://lists.secondlife.com/pipermail/sldev/2007-September/005403.html requested] by [[User:Rob Linden]] on the [[SLDev]] mailing list.<br /> <br /> For a branch of the discussion see [https://wiki.secondlife.com/wiki/Talk:Viewer_Authentication Talk page on the original proposal.]<br /> <br /> == Note ==<br /> <br /> It was not explicit what the goals behind LL's proposed new authentication system are. The goals (Security, Flexibility, Persistence) and beneifits listed here are what SLDev believe them to be based on the original description and e-mail discussions.<br /> <br /> == Summary ==<br /> <br /> There are currently no known password capturing third party viewers in the wild, and a third party viewer requires such a privilege level of access to an account anyway that if you don't trust it with your username and password, you shouldn't be running it anyway. The mechanism proposed, however, is more prone to phishing attacks in the it would acclimatise users to starting the viewer via a web page. At present most password compromises are probably due to weaknesses in the current protocol challenge response, due to allowing weak passwords, due to security compromises in the LL websites or due to the usual phishing e-mails (which are likely to be increased by the proposed method rather than decreased).<br /> <br /> Providing a single authentication mechanism for LL (and third party) websites would be an improvement to multiple backend copies of username and password, however this could be implemented without touching the viewer authentication method. Support for OpenID and other identity metasystems would increase the flexibility and offer features such as brokered identity verification. However, these would only be part of the solution, and although the proposed mechanism would provide a way for future support of these, there are other ways this could be achieved. Future support for OpenID is perhaps a topic for a seperate discussion and debate, but a open debate on this should happen.<br /> <br /> There seems to be no real demand to synchronise the authentication of the viewer with authentication on the SL web site (account, forums, etc.), and any benefits gained would be negated by the problems this would cause anyone running alts (e.g. for in world permissions testing etc.) or multiple viewers (e.g. main, test and firstlook). It also raises problems for those running OpenSim based Grids, and may also cause difficulties further down the line as regards the new architecture discussions. A relatively simpler mod to the web site could prevent the account details for a different alt displaying when the account menu options are selected in the client. There is an argument that the seperating the passwords and logon for the forums would actually improve security.<br /> <br /> The suggestion of provided an embedded way of displaying the web form within the viewer so that you will not have to always start the viewer from a web browser is a non-starter, not just because of problems with the current code in handling web proxies, but because it would be very easy for the embedded web form handling code to log the form data before POSTing to the web site thus undermining any benefits gained.<br /> <br /> Overall, the additional development time both with LL and for external developers doesn't seem to warrant the promoted benefits.<br /> <br /> It was also noted that consideration should be given when considering enhancements to the security/authentication models whether these should be optional - allowing users to make their own risk/convenience decisions.<br /> <br /> == Security ==<br /> <br /> === Benefits Stated By LL ===<br /> * To mitigate the danger of password capturing Trojans masquerading as third party viewers<br /> * Improve trust in third party viewers by providing a means of assurance to the user that the third party viewer could not be a Trojan capturing usernames and passwords.<br /> * To consolidate the authentication implementation in order to support back-end anti-fraud work<br /> <br /> === Pros ===<br /> * Viewer does not have to process (and "see") username and password<br /> <br /> === Cons ===<br /> * The main risk of running a third party viewer (or any other application not provided by Linden Labs) is not stealing passwords, it's direct attacks through the client... and the "official" client is not really any protection against that.<br /> ** Viewer can still be used in direct and indirect attacks even if it never sees the password (for example: salami slicing through cutout accounts, acting as a cutout account or an in-world botnet, faking a failed connection while giving an attacker access).<br /> ** NON-viewer applications (such as editors, 3d tools) designed for use by SL residents could use a keystroke logger and macro to perform any of these attacks, or could inject code into the viewer to do the same thing. Look at 'cheating' programs in combat MMORPGs for ideas.<br /> * But this is still not a large risk, unless people get the client through a mechanism that makes the creator anonymous. Historically, attempts to disseminate boobytrapped versions of applications have only worked in environments where it's routine for people to download applications from anonymous sources (file areas in the BBS era, for example). It's too easy to trace down the originator of any compromised client when you're getting them from their own website.<br /> <br><br /> * Bottom line here is that third party viewers stealing passwords are a very small risk for the user: the bigger risk is from the web browser!<br /> ** Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.<br /> *** This kind of attack is not theoretical, phishing websites are a criminal industry.<br /> *** It would be very easy to set up a temporary (i.e. hard to trace the real owner) phishing webpage which looks like the official SL logon, and send e-mails such as "You've received xxx in SL, Click here to logon" apparently from LL - with far less work than trying to create, and entice people to download a trojan viewer<br /> ** Relies on browser security, and uses a mechanism often disabled or filtered due to security concerns<br /> ** Too reliant on browser/OS implementations (proxies, firewalls, used browsers, etc.)<br /> * So using the browser to perform the authentication moves the authentication to a mechanism that has historically proven more likely to be compromised.<br /> <br><br /> * And the mechanism itself is relatively inflexible.<br /> ** Links to secondlife:// can only point to one instance (version, e.g. homebrew, release candidate official) of the program<br /> ** Links to secondlife:// can not pass parameters to the program<br /> *** In fact allowing that was a security flaw recently found and fixed in the SL client. :(<br /> ** It will raise problems for those running alternative (e.g. OpenSim) grids, and also have impact on the dicussions for a future open grid<br /> <br><br /> * It is suggested that the viewer will embed the web form within the viewer -<br /> ** This escalates the importance of addressing a number of current problems with llmozlib in the current viewer code:<br /> *** there are problems compiling llmozlib on the Linux platform<br /> *** proxies are not supported<br /> ** In any case, a modded client easily log the form data before submitting it to the webform, i.e. all the concerns about clients grabbing passwords would still apply!<br /> <br><br /> * Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)<br /> ** The issues raised in the next sections would mean that people would have an incentive to use this kind of client.<br /> <br /> === Alternatives ===<br /> * One time passwords (for copy paste into a non-secure viewer or to print and take with you to friends, internet cafes, public terminals, etc.)<br /> * lower perm passwords (pwds which put the account into a restricted state, disallowing "dangerous" transactions)<br /> * separate passwords for website account and being inworld<br /> * Account restrictions <br /> * Allow third party plug-ins in the viewer (these would allow the extra functionality which are sometimes the reason for running third party viewers, but would rely on the official viewer for validation)<br /> * For considation have a single backend web service which does the actual authentication - but which is fronted by GUI frontends (e.g. in the viewer) and web frontends (e.g. for accessing the web based account pages etc.)<br /> * Do nothing, keep everything as it is.<br /> ** Without a strong case for the status quo being a problem, this is certainly a viable alternative, particularly given the impact this will have on developers of third party tools and viewers<br /> ** It is arguable that most losses of assets and value are incurred due to SL bugs (inventory, classifieds search, etc.) and outtages rather than through account compromises<br /> <br><br /> * Log of successful or failed login attempts including ip address (or at least a notice of the last attempt)<br /> * Black, White or Greylist IP (specific or > network ranges)- This would allow someone with a static, or semi-static IP to prevent client logons to their account unless they appear on the Whitelist of approved IP's. Greylisting would allow one login attempt every 5-10 minutes and could be used when traveling. > IP's on the blacklist would not be able to log into the account at all<br /> ** Question: how many people have, or even know they have, static or semi static IPs?<br /> * Lock account if too many consecutive logon requests (to prevent automated dictionary attacks) - a user should be able to unlock an account via the website using additional validation such as CAPTCHA's and providing additional information on file such as date of birth.<br /> <br><br /> * This may be the wrong problem - password compromises are more likely to be through standard phishing attacks (logon here to update your account info) which is not addressed, or by weaknesses in the current authentication mechnism or just insecure passwords.<br /> ** CRAM-MD5 or a similar challenge-response type <br /> *** Note that the proposed authentication mechanism via a web form might prevent any attempt at implementing a challenge-response mechanism<br /> ** Dictionary check to reject insecure passwords<br /> <br /> == Flexibility ==<br /> <br /> === Benefits Stated By LL ===<br /> * Single Sign On - allowing multiple web applications (forums, support, account, jira, wiki etc.) and viewers to use the same username and password through a single point without duplicating usernames and passwords into multiple systems<br /> * Extension of this to allow non-LL applications and web sites to participate in this single sign on system.<br /> <br /> === Pros ===<br /> * Enables username/password authentication to work on third party sites without them having to "see" username and password<br /> <br /> === Cons ===<br /> * This is really an unrelated issue...<br /> ** The client doesn't need to depend on the website for this purpose, or this could be a command line option.<br /> ** The client could just as easily be the 'authentication source' as the website.<br /> *** Via a "go to website" link in the client that passed an equivalent token.<br /> <br><br /> * As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> <br /> === Alternatives ===<br /> * Use this mechanism for websites (including third party) only but not for viewers<br /> <br><br /> * Identity Metasystem - [http://en.wikipedia.org/wiki/Identity_Metasystem]<br /> ** OpenID - [http://openid.net/]<br /> ** CardSpace - [http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx]<br /> ** Shibboleth - [http://shibboleth.internet2.edu/]<br /> ** CAS - [http://www.ja-sig.org/products/cas/]<br /> *** These could be handled by the client poping up a window using the internal web browser to connect to a HTML logon. It may be difficult or impossible to determine if the client really is displaying the official HTML logon and not capturing key strokes so this would be a way of implementing the above for flexibility or other reasons (e.g. brokered identity verification [http://www.agimo.gov.au/publications/2004/05/egovt_challenges/privacy/identity/brokered]) not for security<br /> <br /> == Persistence ==<br /> <br /> === Benefits Stated By LL ===<br /> * To synchronise the various LL's systems (forums, support, jira, account, etc.) so that by logging onto one, you are automatically logged onto the others.<br /> <br /> === Pros ===<br /> * Selecting "Account History" or "Manage My Account" and similar menu items would open the web page for the account logged into SL, rather than the account logged into the web site, which currently can be different<br /> <br /> === Cons ===<br /> * As in the previous section, LL's objectives could be met without the viewer logging in via the same mechanism.<br /> * Inconvenient for those with alts or multiple clients<br /> ** Cumbersome to change alts and logon with multiple alts<br /> ** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL<br /> ** As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> * Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.<br /> * Staying online on secondlife.com (which many people seem to do) automatically means anyone with access to the computer/browser (family) can log in with the account inworld<br /> * starting SL from the web browser on a regular basis will most likely result in the web browser lingering in memory in the background when running the viewer, which based on the heavy memory requirement may impair viewer performance.<br /> * this would have an impact on the architecture discussions for a future open grid.<br /> <br /> === Alternatives ===<br /> * As regards menu items such as "Account History", send the account name on the URL, and have the web page check if that is the currently logged on account. If not prompt the user to log on with the same account as being used in the viewer (for security reasons the viewer should not automatically log the account on to the web site in such cases).<br /> * Is this really needed or desirable (''for the client'')? SL is not an extension of the web, it's a different kind of interface... one that has the potential of becoming a "3d web".<br /> * There is an argument that the forum logon should be seperated from the SL account logon<br /> ** This would fit the practice of those using alts, when they only use one account on the forums but would need to check the account details of various alts.<br /> ** Having seperate passwords would isolate security compromises in the forums software from compromising the SL account itself.<br /> <br /> == Signatories ==<br /> <br /> Please sign this below with "<nowiki>~~~~</nowiki>" if you agree with the version of this document you are reading. The date will indicate which version of the document you read and agree with. <br /> <br /> * [[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)<br /> * [[User:Argent Stonecutter|Argent Stonecutter]] 13:53, 29 September 2007 (PDT)<br /> * [[User:Dale Glass|Dale Glass]] 14:28, 29 September 2007 (PDT)<br /> * [[User:Tillie Ariantho|Tillie Ariantho]] 03:48, 30 September 2007 (PDT)<br /> * [[User:Jesse Barnett|Jesse Barnett]] 9:53, 30 September 2007 (PDT)<br /> * [[User:Winter Ventura|Winter Ventura]] 19:42, 29 September 2007 (PDT)<br /> * [[User:Balp Allen|Balp Allen]] 01:33, 30 September 2007 (PDT)<br /> * [[User:Michelle2 Zenovka|Michelle2 Zenovka]] 02:52, 30 September 2007 (PDT)<br /> * [[User:Nicholaz Beresford|Nicholaz]] 03:42, 30 September 2007 (PDT)<br /> * [[User:Dzonatas Sol|Dzonatas Sol]] 06:54, 30 September 2007 (PDT) (Please see my notes: [https://lists.secondlife.com/pipermail/sldev/2007-October/005605.html] [https://lists.secondlife.com/pipermail/sldev/2007-October/005615.html])<br /> * [[User:Eloise Pasteur|Eloise Pasteur]] 06:57, 30 September 2007 (PDT)<br /> * [[User:Becky Tardis|Becky Tardis]] 08:34, 30 September 2007 (PDT)<br /> * [[User:Peter Newell|Peter Newell]] 14:14, 30 September 2007 (PDT)<br /> * [[User:Dr Scofield|Dr Scofield]] 00:45, 1 October 2007 (PDT)<br /> * [[User:Jabath Steuart|Jabath Steuart]] 04:03, 1 October 2007 (PDT)<br /> * [[User:Nik Woodget|Nik Woodget]] 05:19, 1 October 2007 (PDT)<br /> * [[User:Whoops Babii|Whoops Babii]] 05:29, 1 October 2007 (PDT)<br /> * [[User:Feep Larsson|Feep Larsson]] 06:29, 1 October 2007 (PDT)<br /> * [[User:Gibson Willis|Gibson Willis]] 07:11, 1 October 2007 (PDT)<br /> * [[User:Grazer Kline|Grazer Kline]] 10:34, 1 October 2007 (PDT)<br /> * [[User:Odysseus Fairymeadow|Odysseus Fairymeadow]] 13:58, 1 October 2007 (PDT)<br /> * [[User:Melanie Milland|Melanie Milland]] 16:23, 2 October 2007 (PDT)</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Viewer_Authentication_Critique&diff=34253 Viewer Authentication Critique 2007-10-03T11:14:33Z

<p>Matthew Dowd: /* Alternatives */</p> <hr /> <div>This is a formal critique of [[Viewer Authentication]] that was [https://lists.secondlife.com/pipermail/sldev/2007-September/005403.html requested] by [[User:Rob Linden]] on the [[SLDev]] mailing list.<br /> <br /> For a branch of the discussion see [https://wiki.secondlife.com/wiki/Talk:Viewer_Authentication Talk page on the original proposal.]<br /> <br /> == Note ==<br /> <br /> It was not explicit what the goals behind LL's proposed new authentication system are. The goals (Security, Flexibility, Persistence) and Objectives listed here are what SLDev believe them to be based on the original description and e-mail discussions.<br /> <br /> == Summary ==<br /> <br /> There are currently no known password capturing third party viewers in the wild, and a third party viewer requires such a privilege level of access to an account anyway that if you don't trust it with your username and password, you shouldn't be running it anyway. The mechanism proposed, however, is more prone to phishing attacks in the it would acclimatise users to starting the viewer via a web page. At present most password compromises are probably due to weaknesses in the current protocol challenge response, due to allowing weak passwords, due to security compromises in the LL websites or due to the usual phishing e-mails (which are likely to be increased by the proposed method rather than decreased).<br /> <br /> Providing a single authentication mechanism for LL (and third party) websites would be an improvement to multiple backend copies of username and password, however this could be implemented without touching the viewer authentication method. Support for OpenID and other identity metasystems would increase the flexibility and offer features such as brokered identity verification. However, these would only be part of the solution, and although the proposed mechanism would provide a way for future support of these, there are other ways this could be achieved. Future support for OpenID is perhaps a topic for a seperate discussion and debate, but a open debate on this should happen.<br /> <br /> There seems to be no real demand to synchronise the authentication of the viewer with authentication on the SL web site (account, forums, etc.), and any benefits gained would be negated by the problems this would cause anyone running alts (e.g. for in world permissions testing etc.) or multiple viewers (e.g. main, test and firstlook). It also raises problems for those running OpenSim based Grids, and may also cause difficulties further down the line as regards the new architecture discussions. A relatively simpler mod to the web site could prevent the account details for a different alt displaying when the account menu options are selected in the client. There is an argument that the seperating the passwords and logon for the forums would actually improve security.<br /> <br /> The suggestion of provided an embedded way of displaying the web form within the viewer so that you will not have to always start the viewer from a web browser is a non-starter, not just because of problems with the current code in handling web proxies, but because it would be very easy for the embedded web form handling code to log the form data before POSTing to the web site thus undermining any benefits gained.<br /> <br /> Overall, the additional development time both with LL and for external developers doesn't seem to warrant the promoted benefits.<br /> <br /> It was also noted that consideration should be given when considering enhancements to the security/authentication models whether these should be optional - allowing users to make their own risk/convenience decisions.<br /> <br /> == Security ==<br /> <br /> === LL's Objectives ===<br /> * To mitigate the danger of password capturing Trojans masquerading as third party viewers<br /> * Improve trust in third party viewers by providing a means of assurance to the user that the third party viewer could not be a Trojan capturing usernames and passwords.<br /> * To consolidate the authentication implementation in order to support back-end anti-fraud work<br /> <br /> === Pros ===<br /> * Viewer does not have to process (and "see") username and password<br /> <br /> === Cons ===<br /> * The main risk of running a third party viewer (or any other application not provided by Linden Labs) is not stealing passwords, it's direct attacks through the client... and the "official" client is not really any protection against that.<br /> ** Viewer can still be used in direct and indirect attacks even if it never sees the password (for example: salami slicing through cutout accounts, acting as a cutout account or an in-world botnet, faking a failed connection while giving an attacker access).<br /> ** NON-viewer applications (such as editors, 3d tools) designed for use by SL residents could use a keystroke logger and macro to perform any of these attacks, or could inject code into the viewer to do the same thing. Look at 'cheating' programs in combat MMORPGs for ideas.<br /> * But this is still not a large risk, unless people get the client through a mechanism that makes the creator anonymous. Historically, attempts to disseminate boobytrapped versions of applications have only worked in environments where it's routine for people to download applications from anonymous sources (file areas in the BBS era, for example). It's too easy to trace down the originator of any compromised client when you're getting them from their own website.<br /> <br><br /> * Bottom line here is that third party viewers stealing passwords are a very small risk for the user: the bigger risk is from the web browser!<br /> ** Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.<br /> *** This kind of attack is not theoretical, phishing websites are a criminal industry.<br /> *** It would be very easy to set up a temporary (i.e. hard to trace the real owner) phishing webpage which looks like the official SL logon, and send e-mails such as "You've received xxx in SL, Click here to logon" apparently from LL - with far less work than trying to create, and entice people to download a trojan viewer<br /> ** Relies on browser security, and uses a mechanism often disabled or filtered due to security concerns<br /> ** Too reliant on browser/OS implementations (proxies, firewalls, used browsers, etc.)<br /> * So using the browser to perform the authentication moves the authentication to a mechanism that has historically proven more likely to be compromised.<br /> <br><br /> * And the mechanism itself is relatively inflexible.<br /> ** Links to secondlife:// can only point to one instance (version, e.g. homebrew, release candidate official) of the program<br /> ** Links to secondlife:// can not pass parameters to the program<br /> *** In fact allowing that was a security flaw recently found and fixed in the SL client. :(<br /> ** It will raise problems for those running alternative (e.g. OpenSim) grids, and also have impact on the dicussions for a future open grid<br /> <br><br /> * It is suggested that the viewer will embed the web form within the viewer -<br /> ** This escalates the importance of addressing a number of current problems with llmozlib in the current viewer code:<br /> *** there are problems compiling llmozlib on the Linux platform<br /> *** proxies are not supported<br /> ** In any case, a modded client easily log the form data before submitting it to the webform, i.e. all the concerns about clients grabbing passwords would still apply!<br /> <br><br /> * Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)<br /> ** The issues raised in the next sections would mean that people would have an incentive to use this kind of client.<br /> <br /> === Alternatives ===<br /> * One time passwords (for copy paste into a non-secure viewer or to print and take with you to friends, internet cafes, public terminals, etc.)<br /> * lower perm passwords (pwds which put the account into a restricted state, disallowing "dangerous" transactions)<br /> * separate passwords for website account and being inworld<br /> * Account restrictions <br /> * Allow third party plug-ins in the viewer (these would allow the extra functionality which are sometimes the reason for running third party viewers, but would rely on the official viewer for validation)<br /> * For considation have a single backend web service which does the actual authentication - but which is fronted by GUI frontends (e.g. in the viewer) and web frontends (e.g. for accessing the web based account pages etc.)<br /> * Do nothing, keep everything as it is.<br /> ** Without a strong case for the status quo being a problem, this is certainly a viable alternative, particularly given the impact this will have on developers of third party tools and viewers<br /> ** It is arguable that most losses of assets and value are incurred due to SL bugs (inventory, classifieds search, etc.) and outtages rather than through account compromises<br /> <br><br /> * Log of successful or failed login attempts including ip address (or at least a notice of the last attempt)<br /> * Black, White or Greylist IP (specific or > network ranges)- This would allow someone with a static, or semi-static IP to prevent client logons to their account unless they appear on the Whitelist of approved IP's. Greylisting would allow one login attempt every 5-10 minutes and could be used when traveling. > IP's on the blacklist would not be able to log into the account at all<br /> ** Question: how many people have, or even know they have, static or semi static IPs?<br /> * Lock account if too many consecutive logon requests (to prevent automated dictionary attacks) - a user should be able to unlock an account via the website using additional validation such as CAPTCHA's and providing additional information on file such as date of birth.<br /> <br><br /> * This may be the wrong problem - password compromises are more likely to be through standard phishing attacks (logon here to update your account info) which is not addressed, or by weaknesses in the current authentication mechnism or just insecure passwords.<br /> ** CRAM-MD5 or a similar challenge-response type <br /> *** Note that the proposed authentication mechanism via a web form might prevent any attempt at implementing a challenge-response mechanism<br /> ** Dictionary check to reject insecure passwords<br /> <br /> == Flexibility ==<br /> <br /> === LL's Objectives ===<br /> * Single Sign On - allowing multiple web applications (forums, support, account, jira, wiki etc.) and viewers to use the same username and password through a single point without duplicating usernames and passwords into multiple systems<br /> * Extension of this to allow non-LL applications and web sites to participate in this single sign on system.<br /> <br /> === Pros ===<br /> * Enables username/password authentication to work on third party sites without them having to "see" username and password<br /> <br /> === Cons ===<br /> * This is really an unrelated issue...<br /> ** The client doesn't need to depend on the website for this purpose, or this could be a command line option.<br /> ** The client could just as easily be the 'authentication source' as the website.<br /> *** Via a "go to website" link in the client that passed an equivalent token.<br /> <br><br /> * As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> <br /> === Alternatives ===<br /> * Use this mechanism for websites (including third party) only but not for viewers<br /> <br><br /> * Identity Metasystem - [http://en.wikipedia.org/wiki/Identity_Metasystem]<br /> ** OpenID - [http://openid.net/]<br /> ** CardSpace - [http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx]<br /> ** Shibboleth - [http://shibboleth.internet2.edu/]<br /> ** CAS - [http://www.ja-sig.org/products/cas/]<br /> *** These could be handled by the client poping up a window using the internal web browser to connect to a HTML logon. It may be difficult or impossible to determine if the client really is displaying the official HTML logon and not capturing key strokes so this would be a way of implementing the above for flexibility or other reasons (e.g. brokered identity verification [http://www.agimo.gov.au/publications/2004/05/egovt_challenges/privacy/identity/brokered]) not for security<br /> <br /> == Persistence ==<br /> <br /> === LL's Objectives ===<br /> * To synchronise the various LL's systems (forums, support, jira, account, etc.) so that by logging onto one, you are automatically logged onto the others.<br /> <br /> === Pros ===<br /> * Selecting "Account History" or "Manage My Account" and similar menu items would open the web page for the account logged into SL, rather than the account logged into the web site, which currently can be different<br /> <br /> === Cons ===<br /> * As in the previous section, LL's objectives could be met without the viewer logging in via the same mechanism.<br /> * Inconvenient for those with alts or multiple clients<br /> ** Cumbersome to change alts and logon with multiple alts<br /> ** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL<br /> ** As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> * Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.<br /> * Staying online on secondlife.com (which many people seem to do) automatically means anyone with access to the computer/browser (family) can log in with the account inworld<br /> * starting SL from the web browser on a regular basis will most likely result in the web browser lingering in memory in the background when running the viewer, which based on the heavy memory requirement may impair viewer performance.<br /> * this would have an impact on the architecture discussions for a future open grid.<br /> <br /> === Alternatives ===<br /> * As regards menu items such as "Account History", send the account name on the URL, and have the web page check if that is the currently logged on account. If not prompt the user to log on with the same account as being used in the viewer (for security reasons the viewer should not automatically log the account on to the web site in such cases).<br /> * Is this really needed or desirable (''for the client'')? SL is not an extension of the web, it's a different kind of interface... one that has the potential of becoming a "3d web".<br /> * There is an argument that the forum logon should be seperated from the SL account logon<br /> ** This would fit the practice of those using alts, when they only use one account on the forums but would need to check the account details of various alts.<br /> ** Having seperate passwords would isolate security compromises in the forums software from compromising the SL account itself.<br /> <br /> == Signatories ==<br /> <br /> Please sign this below with "<nowiki>~~~~</nowiki>" if you agree with the version of this document you are reading. The date will indicate which version of the document you read and agree with. <br /> <br /> * [[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)<br /> * [[User:Argent Stonecutter|Argent Stonecutter]] 13:53, 29 September 2007 (PDT)<br /> * [[User:Dale Glass|Dale Glass]] 14:28, 29 September 2007 (PDT)<br /> * [[User:Tillie Ariantho|Tillie Ariantho]] 03:48, 30 September 2007 (PDT)<br /> * [[User:Jesse Barnett|Jesse Barnett]] 9:53, 30 September 2007 (PDT)<br /> * [[User:Winter Ventura|Winter Ventura]] 19:42, 29 September 2007 (PDT)<br /> * [[User:Balp Allen|Balp Allen]] 01:33, 30 September 2007 (PDT)<br /> * [[User:Michelle2 Zenovka|Michelle2 Zenovka]] 02:52, 30 September 2007 (PDT)<br /> * [[User:Nicholaz Beresford|Nicholaz]] 03:42, 30 September 2007 (PDT)<br /> * [[User:Dzonatas Sol|Dzonatas Sol]] 06:54, 30 September 2007 (PDT) (Please see my notes: [https://lists.secondlife.com/pipermail/sldev/2007-October/005605.html] [https://lists.secondlife.com/pipermail/sldev/2007-October/005615.html])<br /> * [[User:Eloise Pasteur|Eloise Pasteur]] 06:57, 30 September 2007 (PDT)<br /> * [[User:Becky Tardis|Becky Tardis]] 08:34, 30 September 2007 (PDT)<br /> * [[User:Peter Newell|Peter Newell]] 14:14, 30 September 2007 (PDT)<br /> * [[User:Dr Scofield|Dr Scofield]] 00:45, 1 October 2007 (PDT)<br /> * [[User:Jabath Steuart|Jabath Steuart]] 04:03, 1 October 2007 (PDT)<br /> * [[User:Nik Woodget|Nik Woodget]] 05:19, 1 October 2007 (PDT)<br /> * [[User:Whoops Babii|Whoops Babii]] 05:29, 1 October 2007 (PDT)<br /> * [[User:Feep Larsson|Feep Larsson]] 06:29, 1 October 2007 (PDT)<br /> * [[User:Gibson Willis|Gibson Willis]] 07:11, 1 October 2007 (PDT)<br /> * [[User:Grazer Kline|Grazer Kline]] 10:34, 1 October 2007 (PDT)<br /> * [[User:Odysseus Fairymeadow|Odysseus Fairymeadow]] 13:58, 1 October 2007 (PDT)<br /> * [[User:Melanie Milland|Melanie Milland]] 16:23, 2 October 2007 (PDT)</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Talk:Viewer_Authentication_FAQ&diff=34242 Talk:Viewer Authentication FAQ 2007-10-03T08:48:26Z

<p>Matthew Dowd: </p> <hr /> <div>{{Talk}}<br /> <br /> == New questions to add ==<br /> <br /> Please add new questions, and sign them using "<nowiki>~~~~</nowiki>":<br /> <br /> * Is the Second Life hand logo teal or aqua?<br /> ** Good Q: [[User:Rob Linden|Rob Linden]] 15:18, 2 October 2007 (PDT)<br /> ** Good Q: [[User:Foo Tester|Foo Tester]] 15:18, 2 October 2007 (PDT)<br /> ** Bad Q: [[User:WorkingOnIt Linden|WorkingOnIt Linden]] 15:18, 2 October 2007 (PDT)<br /> ** Good Q: [[User:Foo Bar|Foo Bar]] 15:18, 2 October 2007 (PDT)<br /> * Who/Where is the public task team to organize OpenID?<br /> ** Good Q: [[User:Dzonatas Sol|Dzonatas Sol]] 18:57, 2 October 2007 (PDT)<br /> * Is the intent to add a CAPTCHA within the viewer logon to prevent automated dictionary password attacks? If so, couldn't this be implemented by locking the account for in world logons after say 3 incorrect attempts in a row, and if the account is so locked direct the user to the web site account pages to unlock the account (unlocking the acoount could involve a CAPTCHA and other validation steps such as checking date of birth etc.)?<br /> ** Good Q: [[User:Matthew Dowd|Matthew Dowd]] 01:48, 3 October 2007 (PDT)<br /> <br /> <br /> Please, no inline discussion above. Use the space below for discussion of any of the points above. -- [[User:Rob Linden|Rob Linden]] 15:22, 2 October 2007 (PDT)</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Viewer_Authentication_Critique&diff=34179 Viewer Authentication Critique 2007-10-02T19:14:42Z

<p>Matthew Dowd: Added seperating forum and SL account logins</p> <hr /> <div>This is a formal critique of [[Viewer Authentication]] that was [https://lists.secondlife.com/pipermail/sldev/2007-September/005403.html requested] by [[User:Rob Linden]] on the [[SLDev]] mailing list.<br /> <br /> For a branch of the discussion see [https://wiki.secondlife.com/wiki/Talk:Viewer_Authentication Talk page on the original proposal.]<br /> <br /> == Note ==<br /> <br /> It was not explicit what the goals behind LL's proposed new authentication system are. The goals (Security, Flexibility, Persistence) and Objectives listed here are what SLDev believe them to be based on the original description and e-mail discussions.<br /> <br /> == Summary ==<br /> <br /> There are currently no known password capturing third party viewers in the wild, and a third party viewer requires such a privilege level of access to an account anyway that if you don't trust it with your username and password, you shouldn't be running it anyway. The mechanism proposed, however, is more prone to phishing attacks in the it would acclimatise users to starting the viewer via a web page. At present most password compromises are probably due to weaknesses in the current protocol challenge response, due to allowing weak passwords, due to security compromises in the LL websites or due to the usual phishing e-mails (which are likely to be increased by the proposed method rather than decreased).<br /> <br /> Providing a single authentication mechanism for LL (and third party) websites would be an improvement to multiple backend copies of username and password, however this could be implemented without touching the viewer authentication method. Support for OpenID and other identity metasystems would increase the flexibility and offer features such as brokered identity verification. However, these would only be part of the solution, and although the proposed mechanism would provide a way for future support of these, there are other ways this could be achieved. Future support for OpenID is perhaps a topic for a seperate discussion and debate, but a open debate on this should happen.<br /> <br /> There seems to be no real demand to synchronise the authentication of the viewer with authentication on the SL web site (account, forums, etc.), and any benefits gained would be negated by the problems this would cause anyone running alts (e.g. for in world permissions testing etc.) or multiple viewers (e.g. main, test and firstlook). It also raises problems for those running OpenSim based Grids, and may also cause difficulties further down the line as regards the new architecture discussions. A relatively simpler mod to the web site could prevent the account details for a different alt displaying when the account menu options are selected in the client. There is an argument that the seperating the passwords and logon for the forums would actually improve security.<br /> <br /> The suggestion of provided an embedded way of displaying the web form within the viewer so that you will not have to always start the viewer from a web browser is a non-starter, not just because of problems with the current code in handling web proxies, but because it would be very easy for the embedded web form handling code to log the form data before POSTing to the web site thus undermining any benefits gained.<br /> <br /> Overall, the additional development time both with LL and for external developers doesn't seem to warrant the promoted benefits.<br /> <br /> It was also noted that consideration should be given when considering enhancements to the security/authentication models whether these should be optional - allowing users to make their own risk/convenience decisions.<br /> <br /> == Security ==<br /> <br /> === LL's Objectives ===<br /> * To mitigate the danger of password capturing Trojans masquerading as third party viewers<br /> * Improve trust in third party viewers by providing a means of assurance to the user that the third party viewer could not be a Trojan capturing usernames and passwords.<br /> * To consolidate the authentication implementation in order to support back-end anti-fraud work<br /> <br /> === Pros ===<br /> * Viewer does not have to process (and "see") username and password<br /> <br /> === Cons ===<br /> * The main risk of running a third party viewer (or any other application not provided by Linden Labs) is not stealing passwords, it's direct attacks through the client... and the "official" client is not really any protection against that.<br /> ** Viewer can still be used in direct and indirect attacks even if it never sees the password (for example: salami slicing through cutout accounts, acting as a cutout account or an in-world botnet, faking a failed connection while giving an attacker access).<br /> ** NON-viewer applications (such as editors, 3d tools) designed for use by SL residents could use a keystroke logger and macro to perform any of these attacks, or could inject code into the viewer to do the same thing. Look at 'cheating' programs in combat MMORPGs for ideas.<br /> * But this is still not a large risk, unless people get the client through a mechanism that makes the creator anonymous. Historically, attempts to disseminate boobytrapped versions of applications have only worked in environments where it's routine for people to download applications from anonymous sources (file areas in the BBS era, for example). It's too easy to trace down the originator of any compromised client when you're getting them from their own website.<br /> <br><br /> * Bottom line here is that third party viewers stealing passwords are a very small risk for the user: the bigger risk is from the web browser!<br /> ** Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.<br /> *** This kind of attack is not theoretical, phishing websites are a criminal industry.<br /> *** It would be very easy to set up a temporary (i.e. hard to trace the real owner) phishing webpage which looks like the official SL logon, and send e-mails such as "You've received xxx in SL, Click here to logon" apparently from LL - with far less work than trying to create, and entice people to download a trojan viewer<br /> ** Relies on browser security, and uses a mechanism often disabled or filtered due to security concerns<br /> ** Too reliant on browser/OS implementations (proxies, firewalls, used browsers, etc.)<br /> * So using the browser to perform the authentication moves the authentication to a mechanism that has historically proven more likely to be compromised.<br /> <br><br /> * And the mechanism itself is relatively inflexible.<br /> ** Links to secondlife:// can only point to one instance (version, e.g. homebrew, release candidate official) of the program<br /> ** Links to secondlife:// can not pass parameters to the program<br /> *** In fact allowing that was a security flaw recently found and fixed in the SL client. :(<br /> ** It will raise problems for those running alternative (e.g. OpenSim) grids, and also have impact on the dicussions for a future open grid<br /> <br><br /> * It is suggested that the viewer will embed the web form within the viewer -<br /> ** This escalates the importance of addressing a number of current problems with llmozlib in the current viewer code:<br /> *** there are problems compiling llmozlib on the Linux platform<br /> *** proxies are not supported<br /> ** In any case, a modded client easily log the form data before submitting it to the webform, i.e. all the concerns about clients grabbing passwords would still apply!<br /> <br><br /> * Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)<br /> ** The issues raised in the next sections would mean that people would have an incentive to use this kind of client.<br /> <br /> === Alternatives ===<br /> * One time passwords (for copy paste into a non-secure viewer or to print and take with you to friends, internet cafes, public terminals, etc.)<br /> * lower perm passwords (pwds which put the account into a restricted state, disallowing "dangerous" transactions)<br /> * separate passwords for website account and being inworld<br /> * Account restrictions <br /> * Allow third party plug-ins in the viewer (these would allow the extra functionality which are sometimes the reason for running third party viewers, but would rely on the official viewer for validation)<br /> * For considation have a single backend web service which does the actual authentication - but which is fronted by GUI frontends (e.g. in the viewer) and web frontends (e.g. for accessing the web based account pages etc.)<br /> * Do nothing, keep everything as it is.<br /> ** Without a strong case for the status quo being a problem, this is certainly a viable alternative, particularly given the impact this will have on developers of third party tools and viewers<br /> ** It is arguable that most losses of assets and value are incurred due to SL bugs (inventory, classifieds search, etc.) and outtages rather than through account compromises<br /> <br><br /> * Log of successful or failed login attempts including ip address (or at least a notice of the last attempt)<br /> * Black, White or Greylist IP (specific or > network ranges)- This would allow someone with a static, or semi-static IP to prevent client logons to their account unless they appear on the Whitelist of approved IP's. Greylisting would allow one login attempt every 5-10 minutes and could be used when traveling. > IP's on the blacklist would not be able to log into the account at all<br /> ** Question: how many people have, or even know they have, static or semi static IPs?<br /> <br><br /> * This may be the wrong problem - password compromises are more likely to be through standard phishing attacks (logon here to update your account info) which is not addressed, or by weaknesses in the current authentication mechnism or just insecure passwords.<br /> ** CRAM-MD5 or a similar challenge-response type <br /> ** Dictionary check to reject insecure passwords<br /> <br /> == Flexibility ==<br /> <br /> === LL's Objectives ===<br /> * Single Sign On - allowing multiple web applications (forums, support, account, jira, wiki etc.) and viewers to use the same username and password through a single point without duplicating usernames and passwords into multiple systems<br /> * Extension of this to allow non-LL applications and web sites to participate in this single sign on system.<br /> <br /> === Pros ===<br /> * Enables username/password authentication to work on third party sites without them having to "see" username and password<br /> <br /> === Cons ===<br /> * This is really an unrelated issue...<br /> ** The client doesn't need to depend on the website for this purpose, or this could be a command line option.<br /> ** The client could just as easily be the 'authentication source' as the website.<br /> *** Via a "go to website" link in the client that passed an equivalent token.<br /> <br><br /> * As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> <br /> === Alternatives ===<br /> * Use this mechanism for websites (including third party) only but not for viewers<br /> <br><br /> * Identity Metasystem - [http://en.wikipedia.org/wiki/Identity_Metasystem]<br /> ** OpenID - [http://openid.net/]<br /> ** CardSpace - [http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx]<br /> ** Shibboleth - [http://shibboleth.internet2.edu/]<br /> ** CAS - [http://www.ja-sig.org/products/cas/]<br /> *** These could be handled by the client poping up a window using the internal web browser to connect to a HTML logon. It may be difficult or impossible to determine if the client really is displaying the official HTML logon and not capturing key strokes so this would be a way of implementing the above for flexibility or other reasons (e.g. brokered identity verification [http://www.agimo.gov.au/publications/2004/05/egovt_challenges/privacy/identity/brokered]) not for security<br /> <br /> == Persistence ==<br /> <br /> === LL's Objectives ===<br /> * To synchronise the various LL's systems (forums, support, jira, account, etc.) so that by logging onto one, you are automatically logged onto the others.<br /> <br /> === Pros ===<br /> * Selecting "Account History" or "Manage My Account" and similar menu items would open the web page for the account logged into SL, rather than the account logged into the web site, which currently can be different<br /> <br /> === Cons ===<br /> * As in the previous section, LL's objectives could be met without the viewer logging in via the same mechanism.<br /> * Inconvenient for those with alts or multiple clients<br /> ** Cumbersome to change alts and logon with multiple alts<br /> ** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL<br /> ** As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> * Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.<br /> * Staying online on secondlife.com (which many people seem to do) automatically means anyone with access to the computer/browser (family) can log in with the account inworld<br /> * starting SL from the web browser on a regular basis will most likely result in the web browser lingering in memory in the background when running the viewer, which based on the heavy memory requirement may impair viewer performance.<br /> * this would have an impact on the architecture discussions for a future open grid.<br /> <br /> === Alternatives ===<br /> * As regards menu items such as "Account History", send the account name on the URL, and have the web page check if that is the currently logged on account. If not prompt the user to log on with the same account as being used in the viewer (for security reasons the viewer should not automatically log the account on to the web site in such cases).<br /> * Is this really needed or desirable (''for the client'')? SL is not an extension of the web, it's a different kind of interface... one that has the potential of becoming a "3d web".<br /> * There is an argument that the forum logon should be seperated from the SL account logon<br /> ** This would fit the practice of those using alts, when they only use one account on the forums but would need to check the account details of various alts.<br /> ** Having seperate passwords would isolate security compromises in the forums software from compromising the SL account itself.<br /> <br /> == Signatories ==<br /> <br /> Please sign this below with "<nowiki>~~~~</nowiki>" if you agree with the version of this document you are reading. The date will indicate which version of the document you read and agree with. <br /> <br /> * [[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)<br /> * [[User:Argent Stonecutter|Argent Stonecutter]] 13:53, 29 September 2007 (PDT)<br /> * [[User:Dale Glass|Dale Glass]] 14:28, 29 September 2007 (PDT)<br /> * [[User:Tillie Ariantho|Tillie Ariantho]] 03:48, 30 September 2007 (PDT)<br /> * [[User:Jesse Barnett|Jesse Barnett]] 9:53, 30 September 2007 (PDT)<br /> * [[User:Winter Ventura|Winter Ventura]] 19:42, 29 September 2007 (PDT)<br /> * [[User:Balp Allen|Balp Allen]] 01:33, 30 September 2007 (PDT)<br /> * [[User:Michelle2 Zenovka|Michelle2 Zenovka]] 02:52, 30 September 2007 (PDT)<br /> * [[User:Nicholaz Beresford|Nicholaz]] 03:42, 30 September 2007 (PDT)<br /> * [[User:Dzonatas Sol|Dzonatas Sol]] 06:54, 30 September 2007 (PDT) (Please see my notes: [https://lists.secondlife.com/pipermail/sldev/2007-October/005605.html] [https://lists.secondlife.com/pipermail/sldev/2007-October/005615.html])<br /> * [[User:Eloise Pasteur|Eloise Pasteur]] 06:57, 30 September 2007 (PDT)<br /> * [[User:Becky Tardis|Becky Tardis]] 08:34, 30 September 2007 (PDT)<br /> * [[User:Peter Newell|Peter Newell]] 14:14, 30 September 2007 (PDT)<br /> * [[User:Dr Scofield|Dr Scofield]] 00:45, 1 October 2007 (PDT)<br /> * [[User:Jabath Steuart|Jabath Steuart]] 04:03, 1 October 2007 (PDT)<br /> * [[User:Nik Woodget|Nik Woodget]] 05:19, 1 October 2007 (PDT)<br /> * [[User:Whoops Babii|Whoops Babii]] 05:29, 1 October 2007 (PDT)<br /> * [[User:Feep Larsson|Feep Larsson]] 06:29, 1 October 2007 (PDT)<br /> * [[User:Gibson Willis|Gibson Willis]] 07:11, 1 October 2007 (PDT)<br /> * [[User:Grazer Kline|Grazer Kline]] 10:34, 1 October 2007 (PDT)<br /> * [[User:Odysseus Fairymeadow|Odysseus Fairymeadow]] 13:58, 1 October 2007 (PDT)</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Viewer_Authentication_Critique&diff=34178 Viewer Authentication Critique 2007-10-02T19:12:39Z

<p>Matthew Dowd: /* Summary */</p> <hr /> <div>This is a formal critique of [[Viewer Authentication]] that was [https://lists.secondlife.com/pipermail/sldev/2007-September/005403.html requested] by [[User:Rob Linden]] on the [[SLDev]] mailing list.<br /> <br /> For a branch of the discussion see [https://wiki.secondlife.com/wiki/Talk:Viewer_Authentication Talk page on the original proposal.]<br /> <br /> == Note ==<br /> <br /> It was not explicit what the goals behind LL's proposed new authentication system are. The goals (Security, Flexibility, Persistence) and Objectives listed here are what SLDev believe them to be based on the original description and e-mail discussions.<br /> <br /> == Summary ==<br /> <br /> There are currently no known password capturing third party viewers in the wild, and a third party viewer requires such a privilege level of access to an account anyway that if you don't trust it with your username and password, you shouldn't be running it anyway. The mechanism proposed, however, is more prone to phishing attacks in the it would acclimatise users to starting the viewer via a web page. At present most password compromises are probably due to weaknesses in the current protocol challenge response, due to allowing weak passwords, due to security compromises in the LL websites or due to the usual phishing e-mails (which are likely to be increased by the proposed method rather than decreased).<br /> <br /> Providing a single authentication mechanism for LL (and third party) websites would be an improvement to multiple backend copies of username and password, however this could be implemented without touching the viewer authentication method. Support for OpenID and other identity metasystems would increase the flexibility and offer features such as brokered identity verification. However, these would only be part of the solution, and although the proposed mechanism would provide a way for future support of these, there are other ways this could be achieved. Future support for OpenID is perhaps a topic for a seperate discussion and debate, but a open debate on this should happen.<br /> <br /> There seems to be no real demand to synchronise the authentication of the viewer with authentication on the SL web site (account, forums, etc.), and any benefits gained would be negated by the problems this would cause anyone running alts (e.g. for in world permissions testing etc.) or multiple viewers (e.g. main, test and firstlook). It also raises problems for those running OpenSim based Grids, and may also cause difficulties further down the line as regards the new architecture discussions. A relatively simpler mod to the web site could prevent the account details for a different alt displaying when the account menu options are selected in the client. There is an argument that the seperating the passwords and logon for the forums would actually improve security.<br /> <br /> The suggestion of provided an embedded way of displaying the web form within the viewer so that you will not have to always start the viewer from a web browser is a non-starter, not just because of problems with the current code in handling web proxies, but because it would be very easy for the embedded web form handling code to log the form data before POSTing to the web site thus undermining any benefits gained.<br /> <br /> Overall, the additional development time both with LL and for external developers doesn't seem to warrant the promoted benefits.<br /> <br /> It was also noted that consideration should be given when considering enhancements to the security/authentication models whether these should be optional - allowing users to make their own risk/convenience decisions.<br /> <br /> == Security ==<br /> <br /> === LL's Objectives ===<br /> * To mitigate the danger of password capturing Trojans masquerading as third party viewers<br /> * Improve trust in third party viewers by providing a means of assurance to the user that the third party viewer could not be a Trojan capturing usernames and passwords.<br /> * To consolidate the authentication implementation in order to support back-end anti-fraud work<br /> <br /> === Pros ===<br /> * Viewer does not have to process (and "see") username and password<br /> <br /> === Cons ===<br /> * The main risk of running a third party viewer (or any other application not provided by Linden Labs) is not stealing passwords, it's direct attacks through the client... and the "official" client is not really any protection against that.<br /> ** Viewer can still be used in direct and indirect attacks even if it never sees the password (for example: salami slicing through cutout accounts, acting as a cutout account or an in-world botnet, faking a failed connection while giving an attacker access).<br /> ** NON-viewer applications (such as editors, 3d tools) designed for use by SL residents could use a keystroke logger and macro to perform any of these attacks, or could inject code into the viewer to do the same thing. Look at 'cheating' programs in combat MMORPGs for ideas.<br /> * But this is still not a large risk, unless people get the client through a mechanism that makes the creator anonymous. Historically, attempts to disseminate boobytrapped versions of applications have only worked in environments where it's routine for people to download applications from anonymous sources (file areas in the BBS era, for example). It's too easy to trace down the originator of any compromised client when you're getting them from their own website.<br /> <br><br /> * Bottom line here is that third party viewers stealing passwords are a very small risk for the user: the bigger risk is from the web browser!<br /> ** Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.<br /> *** This kind of attack is not theoretical, phishing websites are a criminal industry.<br /> *** It would be very easy to set up a temporary (i.e. hard to trace the real owner) phishing webpage which looks like the official SL logon, and send e-mails such as "You've received xxx in SL, Click here to logon" apparently from LL - with far less work than trying to create, and entice people to download a trojan viewer<br /> ** Relies on browser security, and uses a mechanism often disabled or filtered due to security concerns<br /> ** Too reliant on browser/OS implementations (proxies, firewalls, used browsers, etc.)<br /> * So using the browser to perform the authentication moves the authentication to a mechanism that has historically proven more likely to be compromised.<br /> <br><br /> * And the mechanism itself is relatively inflexible.<br /> ** Links to secondlife:// can only point to one instance (version, e.g. homebrew, release candidate official) of the program<br /> ** Links to secondlife:// can not pass parameters to the program<br /> *** In fact allowing that was a security flaw recently found and fixed in the SL client. :(<br /> ** It will raise problems for those running alternative (e.g. OpenSim) grids, and also have impact on the dicussions for a future open grid<br /> <br><br /> * It is suggested that the viewer will embed the web form within the viewer -<br /> ** This escalates the importance of addressing a number of current problems with llmozlib in the current viewer code:<br /> *** there are problems compiling llmozlib on the Linux platform<br /> *** proxies are not supported<br /> ** In any case, a modded client easily log the form data before submitting it to the webform, i.e. all the concerns about clients grabbing passwords would still apply!<br /> <br><br /> * Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)<br /> ** The issues raised in the next sections would mean that people would have an incentive to use this kind of client.<br /> <br /> === Alternatives ===<br /> * One time passwords (for copy paste into a non-secure viewer or to print and take with you to friends, internet cafes, public terminals, etc.)<br /> * lower perm passwords (pwds which put the account into a restricted state, disallowing "dangerous" transactions)<br /> * separate passwords for website account and being inworld<br /> * Account restrictions <br /> * Allow third party plug-ins in the viewer (these would allow the extra functionality which are sometimes the reason for running third party viewers, but would rely on the official viewer for validation)<br /> * For considation have a single backend web service which does the actual authentication - but which is fronted by GUI frontends (e.g. in the viewer) and web frontends (e.g. for accessing the web based account pages etc.)<br /> * Do nothing, keep everything as it is.<br /> ** Without a strong case for the status quo being a problem, this is certainly a viable alternative, particularly given the impact this will have on developers of third party tools and viewers<br /> ** It is arguable that most losses of assets and value are incurred due to SL bugs (inventory, classifieds search, etc.) and outtages rather than through account compromises<br /> <br><br /> * Log of successful or failed login attempts including ip address (or at least a notice of the last attempt)<br /> * Black, White or Greylist IP (specific or > network ranges)- This would allow someone with a static, or semi-static IP to prevent client logons to their account unless they appear on the Whitelist of approved IP's. Greylisting would allow one login attempt every 5-10 minutes and could be used when traveling. > IP's on the blacklist would not be able to log into the account at all<br /> ** Question: how many people have, or even know they have, static or semi static IPs?<br /> <br><br /> * This may be the wrong problem - password compromises are more likely to be through standard phishing attacks (logon here to update your account info) which is not addressed, or by weaknesses in the current authentication mechnism or just insecure passwords.<br /> ** CRAM-MD5 or a similar challenge-response type <br /> ** Dictionary check to reject insecure passwords<br /> <br /> == Flexibility ==<br /> <br /> === LL's Objectives ===<br /> * Single Sign On - allowing multiple web applications (forums, support, account, jira, wiki etc.) and viewers to use the same username and password through a single point without duplicating usernames and passwords into multiple systems<br /> * Extension of this to allow non-LL applications and web sites to participate in this single sign on system.<br /> <br /> === Pros ===<br /> * Enables username/password authentication to work on third party sites without them having to "see" username and password<br /> <br /> === Cons ===<br /> * This is really an unrelated issue...<br /> ** The client doesn't need to depend on the website for this purpose, or this could be a command line option.<br /> ** The client could just as easily be the 'authentication source' as the website.<br /> *** Via a "go to website" link in the client that passed an equivalent token.<br /> <br><br /> * As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> <br /> === Alternatives ===<br /> * Use this mechanism for websites (including third party) only but not for viewers<br /> <br><br /> * Identity Metasystem - [http://en.wikipedia.org/wiki/Identity_Metasystem]<br /> ** OpenID - [http://openid.net/]<br /> ** CardSpace - [http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx]<br /> ** Shibboleth - [http://shibboleth.internet2.edu/]<br /> ** CAS - [http://www.ja-sig.org/products/cas/]<br /> *** These could be handled by the client poping up a window using the internal web browser to connect to a HTML logon. It may be difficult or impossible to determine if the client really is displaying the official HTML logon and not capturing key strokes so this would be a way of implementing the above for flexibility or other reasons (e.g. brokered identity verification [http://www.agimo.gov.au/publications/2004/05/egovt_challenges/privacy/identity/brokered]) not for security<br /> <br /> == Persistence ==<br /> <br /> === LL's Objectives ===<br /> * To synchronise the various LL's systems (forums, support, jira, account, etc.) so that by logging onto one, you are automatically logged onto the others.<br /> <br /> === Pros ===<br /> * Selecting "Account History" or "Manage My Account" and similar menu items would open the web page for the account logged into SL, rather than the account logged into the web site, which currently can be different<br /> <br /> === Cons ===<br /> * As in the previous section, LL's objectives could be met without the viewer logging in via the same mechanism.<br /> * Inconvenient for those with alts or multiple clients<br /> ** Cumbersome to change alts and logon with multiple alts<br /> ** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL<br /> ** As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> * Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.<br /> * Staying online on secondlife.com (which many people seem to do) automatically means anyone with access to the computer/browser (family) can log in with the account inworld<br /> * starting SL from the web browser on a regular basis will most likely result in the web browser lingering in memory in the background when running the viewer, which based on the heavy memory requirement may impair viewer performance.<br /> * this would have an impact on the architecture discussions for a future open grid.<br /> <br /> === Alternatives ===<br /> * As regards menu items such as "Account History", send the account name on the URL, and have the web page check if that is the currently logged on account. If not prompt the user to log on with the same account as being used in the viewer (for security reasons the viewer should not automatically log the account on to the web site in such cases).<br /> * Is this really needed or desirable (''for the client'')? SL is not an extension of the web, it's a different kind of interface... one that has the potential of becoming a "3d web".<br /> <br /> == Signatories ==<br /> <br /> Please sign this below with "<nowiki>~~~~</nowiki>" if you agree with the version of this document you are reading. The date will indicate which version of the document you read and agree with. <br /> <br /> * [[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)<br /> * [[User:Argent Stonecutter|Argent Stonecutter]] 13:53, 29 September 2007 (PDT)<br /> * [[User:Dale Glass|Dale Glass]] 14:28, 29 September 2007 (PDT)<br /> * [[User:Tillie Ariantho|Tillie Ariantho]] 03:48, 30 September 2007 (PDT)<br /> * [[User:Jesse Barnett|Jesse Barnett]] 9:53, 30 September 2007 (PDT)<br /> * [[User:Winter Ventura|Winter Ventura]] 19:42, 29 September 2007 (PDT)<br /> * [[User:Balp Allen|Balp Allen]] 01:33, 30 September 2007 (PDT)<br /> * [[User:Michelle2 Zenovka|Michelle2 Zenovka]] 02:52, 30 September 2007 (PDT)<br /> * [[User:Nicholaz Beresford|Nicholaz]] 03:42, 30 September 2007 (PDT)<br /> * [[User:Dzonatas Sol|Dzonatas Sol]] 06:54, 30 September 2007 (PDT) (Please see my notes: [https://lists.secondlife.com/pipermail/sldev/2007-October/005605.html] [https://lists.secondlife.com/pipermail/sldev/2007-October/005615.html])<br /> * [[User:Eloise Pasteur|Eloise Pasteur]] 06:57, 30 September 2007 (PDT)<br /> * [[User:Becky Tardis|Becky Tardis]] 08:34, 30 September 2007 (PDT)<br /> * [[User:Peter Newell|Peter Newell]] 14:14, 30 September 2007 (PDT)<br /> * [[User:Dr Scofield|Dr Scofield]] 00:45, 1 October 2007 (PDT)<br /> * [[User:Jabath Steuart|Jabath Steuart]] 04:03, 1 October 2007 (PDT)<br /> * [[User:Nik Woodget|Nik Woodget]] 05:19, 1 October 2007 (PDT)<br /> * [[User:Whoops Babii|Whoops Babii]] 05:29, 1 October 2007 (PDT)<br /> * [[User:Feep Larsson|Feep Larsson]] 06:29, 1 October 2007 (PDT)<br /> * [[User:Gibson Willis|Gibson Willis]] 07:11, 1 October 2007 (PDT)<br /> * [[User:Grazer Kline|Grazer Kline]] 10:34, 1 October 2007 (PDT)<br /> * [[User:Odysseus Fairymeadow|Odysseus Fairymeadow]] 13:58, 1 October 2007 (PDT)</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Viewer_Authentication_Critique&diff=34176 Viewer Authentication Critique 2007-10-02T19:02:29Z

<p>Matthew Dowd: Added the fact that embedding the authentication web page into the viewer would undermine any security benefits</p> <hr /> <div>This is a formal critique of [[Viewer Authentication]] that was [https://lists.secondlife.com/pipermail/sldev/2007-September/005403.html requested] by [[User:Rob Linden]] on the [[SLDev]] mailing list.<br /> <br /> For a branch of the discussion see [https://wiki.secondlife.com/wiki/Talk:Viewer_Authentication Talk page on the original proposal.]<br /> <br /> == Note ==<br /> <br /> It was not explicit what the goals behind LL's proposed new authentication system are. The goals (Security, Flexibility, Persistence) and Objectives listed here are what SLDev believe them to be based on the original description and e-mail discussions.<br /> <br /> == Summary ==<br /> <br /> The new authentication method proposed by LL seems to be an attempt to solve a perceived but non-existent problem. <br /> <br /> There are currently no known password capturing third party viewers in the wild, and a third party viewer requires such a privilege level of access to an account anyway that if you don't trust it with your username and password, you shouldn't be running it anyway. The mechanism proposed, however, is more prone to phishing attacks. Most password compromises are probably due to weaknesses in the current protocol challenge response, due to allowing weak passwords or due to the usual phishing e-mails (which are likely to be increased by the proposed method rather than decreased).<br /> <br /> Providing a single authentication mechanism for LL (and third party) websites would be an improvement to multiple backend copies of username and password, however this could be implemented without touching the viewer authentication method. Support for OpenID and other identity metasystems would increase the flexibility and offer features such as brokered identity verification. However, these would only be part of the solution, and although the proposed mechanism would provide a way for future support of these, there are other ways this could be achieved. Future support for OpenID is perhaps a topic for a seperate discussion and debate, but a open debate on this should happen.<br /> <br /> There seems to be no real demand to synchronise the authentication of the viewer with authentication on the SL web site (account, forums, etc.), and any benefits gained would be negated by the problems this would cause anyone running alts (e.g. for in world permissions testing etc.) or multiple viewers (e.g. main, test and firstlook). It also raises problems for those running OpenSim based Grids, and may also cause difficulties further down the line as regards the new architecture discussions. A relatively simpler mod to the web site could prevent the account details for a different alt displaying when the account menu options are selected in the client.<br /> <br /> Overall, the additional development time both with LL and for external developers doesn't seem to warrant the promoted benefits.<br /> <br /> It was also noted that consideration should be given when considering enhancements to the security/authentication models whether these should be optional - allowing users to make their own risk/convenience decisions.<br /> <br /> == Security ==<br /> <br /> === LL's Objectives ===<br /> * To mitigate the danger of password capturing Trojans masquerading as third party viewers<br /> * Improve trust in third party viewers by providing a means of assurance to the user that the third party viewer could not be a Trojan capturing usernames and passwords.<br /> * To consolidate the authentication implementation in order to support back-end anti-fraud work<br /> <br /> === Pros ===<br /> * Viewer does not have to process (and "see") username and password<br /> <br /> === Cons ===<br /> * The main risk of running a third party viewer (or any other application not provided by Linden Labs) is not stealing passwords, it's direct attacks through the client... and the "official" client is not really any protection against that.<br /> ** Viewer can still be used in direct and indirect attacks even if it never sees the password (for example: salami slicing through cutout accounts, acting as a cutout account or an in-world botnet, faking a failed connection while giving an attacker access).<br /> ** NON-viewer applications (such as editors, 3d tools) designed for use by SL residents could use a keystroke logger and macro to perform any of these attacks, or could inject code into the viewer to do the same thing. Look at 'cheating' programs in combat MMORPGs for ideas.<br /> * But this is still not a large risk, unless people get the client through a mechanism that makes the creator anonymous. Historically, attempts to disseminate boobytrapped versions of applications have only worked in environments where it's routine for people to download applications from anonymous sources (file areas in the BBS era, for example). It's too easy to trace down the originator of any compromised client when you're getting them from their own website.<br /> <br><br /> * Bottom line here is that third party viewers stealing passwords are a very small risk for the user: the bigger risk is from the web browser!<br /> ** Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.<br /> *** This kind of attack is not theoretical, phishing websites are a criminal industry.<br /> *** It would be very easy to set up a temporary (i.e. hard to trace the real owner) phishing webpage which looks like the official SL logon, and send e-mails such as "You've received xxx in SL, Click here to logon" apparently from LL - with far less work than trying to create, and entice people to download a trojan viewer<br /> ** Relies on browser security, and uses a mechanism often disabled or filtered due to security concerns<br /> ** Too reliant on browser/OS implementations (proxies, firewalls, used browsers, etc.)<br /> * So using the browser to perform the authentication moves the authentication to a mechanism that has historically proven more likely to be compromised.<br /> <br><br /> * And the mechanism itself is relatively inflexible.<br /> ** Links to secondlife:// can only point to one instance (version, e.g. homebrew, release candidate official) of the program<br /> ** Links to secondlife:// can not pass parameters to the program<br /> *** In fact allowing that was a security flaw recently found and fixed in the SL client. :(<br /> ** It will raise problems for those running alternative (e.g. OpenSim) grids, and also have impact on the dicussions for a future open grid<br /> <br><br /> * It is suggested that the viewer will embed the web form within the viewer -<br /> ** This escalates the importance of addressing a number of current problems with llmozlib in the current viewer code:<br /> *** there are problems compiling llmozlib on the Linux platform<br /> *** proxies are not supported<br /> ** In any case, a modded client easily log the form data before submitting it to the webform, i.e. all the concerns about clients grabbing passwords would still apply!<br /> <br><br /> * Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)<br /> ** The issues raised in the next sections would mean that people would have an incentive to use this kind of client.<br /> <br /> === Alternatives ===<br /> * One time passwords (for copy paste into a non-secure viewer or to print and take with you to friends, internet cafes, public terminals, etc.)<br /> * lower perm passwords (pwds which put the account into a restricted state, disallowing "dangerous" transactions)<br /> * separate passwords for website account and being inworld<br /> * Account restrictions <br /> * Allow third party plug-ins in the viewer (these would allow the extra functionality which are sometimes the reason for running third party viewers, but would rely on the official viewer for validation)<br /> * For considation have a single backend web service which does the actual authentication - but which is fronted by GUI frontends (e.g. in the viewer) and web frontends (e.g. for accessing the web based account pages etc.)<br /> * Do nothing, keep everything as it is.<br /> ** Without a strong case for the status quo being a problem, this is certainly a viable alternative, particularly given the impact this will have on developers of third party tools and viewers<br /> ** It is arguable that most losses of assets and value are incurred due to SL bugs (inventory, classifieds search, etc.) and outtages rather than through account compromises<br /> <br><br /> * Log of successful or failed login attempts including ip address (or at least a notice of the last attempt)<br /> * Black, White or Greylist IP (specific or > network ranges)- This would allow someone with a static, or semi-static IP to prevent client logons to their account unless they appear on the Whitelist of approved IP's. Greylisting would allow one login attempt every 5-10 minutes and could be used when traveling. > IP's on the blacklist would not be able to log into the account at all<br /> ** Question: how many people have, or even know they have, static or semi static IPs?<br /> <br><br /> * This may be the wrong problem - password compromises are more likely to be through standard phishing attacks (logon here to update your account info) which is not addressed, or by weaknesses in the current authentication mechnism or just insecure passwords.<br /> ** CRAM-MD5 or a similar challenge-response type <br /> ** Dictionary check to reject insecure passwords<br /> <br /> == Flexibility ==<br /> <br /> === LL's Objectives ===<br /> * Single Sign On - allowing multiple web applications (forums, support, account, jira, wiki etc.) and viewers to use the same username and password through a single point without duplicating usernames and passwords into multiple systems<br /> * Extension of this to allow non-LL applications and web sites to participate in this single sign on system.<br /> <br /> === Pros ===<br /> * Enables username/password authentication to work on third party sites without them having to "see" username and password<br /> <br /> === Cons ===<br /> * This is really an unrelated issue...<br /> ** The client doesn't need to depend on the website for this purpose, or this could be a command line option.<br /> ** The client could just as easily be the 'authentication source' as the website.<br /> *** Via a "go to website" link in the client that passed an equivalent token.<br /> <br><br /> * As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> <br /> === Alternatives ===<br /> * Use this mechanism for websites (including third party) only but not for viewers<br /> <br><br /> * Identity Metasystem - [http://en.wikipedia.org/wiki/Identity_Metasystem]<br /> ** OpenID - [http://openid.net/]<br /> ** CardSpace - [http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx]<br /> ** Shibboleth - [http://shibboleth.internet2.edu/]<br /> ** CAS - [http://www.ja-sig.org/products/cas/]<br /> *** These could be handled by the client poping up a window using the internal web browser to connect to a HTML logon. It may be difficult or impossible to determine if the client really is displaying the official HTML logon and not capturing key strokes so this would be a way of implementing the above for flexibility or other reasons (e.g. brokered identity verification [http://www.agimo.gov.au/publications/2004/05/egovt_challenges/privacy/identity/brokered]) not for security<br /> <br /> == Persistence ==<br /> <br /> === LL's Objectives ===<br /> * To synchronise the various LL's systems (forums, support, jira, account, etc.) so that by logging onto one, you are automatically logged onto the others.<br /> <br /> === Pros ===<br /> * Selecting "Account History" or "Manage My Account" and similar menu items would open the web page for the account logged into SL, rather than the account logged into the web site, which currently can be different<br /> <br /> === Cons ===<br /> * As in the previous section, LL's objectives could be met without the viewer logging in via the same mechanism.<br /> * Inconvenient for those with alts or multiple clients<br /> ** Cumbersome to change alts and logon with multiple alts<br /> ** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL<br /> ** As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> * Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.<br /> * Staying online on secondlife.com (which many people seem to do) automatically means anyone with access to the computer/browser (family) can log in with the account inworld<br /> * starting SL from the web browser on a regular basis will most likely result in the web browser lingering in memory in the background when running the viewer, which based on the heavy memory requirement may impair viewer performance.<br /> * this would have an impact on the architecture discussions for a future open grid.<br /> <br /> === Alternatives ===<br /> * As regards menu items such as "Account History", send the account name on the URL, and have the web page check if that is the currently logged on account. If not prompt the user to log on with the same account as being used in the viewer (for security reasons the viewer should not automatically log the account on to the web site in such cases).<br /> * Is this really needed or desirable (''for the client'')? SL is not an extension of the web, it's a different kind of interface... one that has the potential of becoming a "3d web".<br /> <br /> == Signatories ==<br /> <br /> Please sign this below with "<nowiki>~~~~</nowiki>" if you agree with the version of this document you are reading. The date will indicate which version of the document you read and agree with. <br /> <br /> * [[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)<br /> * [[User:Argent Stonecutter|Argent Stonecutter]] 13:53, 29 September 2007 (PDT)<br /> * [[User:Dale Glass|Dale Glass]] 14:28, 29 September 2007 (PDT)<br /> * [[User:Tillie Ariantho|Tillie Ariantho]] 03:48, 30 September 2007 (PDT)<br /> * [[User:Jesse Barnett|Jesse Barnett]] 9:53, 30 September 2007 (PDT)<br /> * [[User:Winter Ventura|Winter Ventura]] 19:42, 29 September 2007 (PDT)<br /> * [[User:Balp Allen|Balp Allen]] 01:33, 30 September 2007 (PDT)<br /> * [[User:Michelle2 Zenovka|Michelle2 Zenovka]] 02:52, 30 September 2007 (PDT)<br /> * [[User:Nicholaz Beresford|Nicholaz]] 03:42, 30 September 2007 (PDT)<br /> * [[User:Dzonatas Sol|Dzonatas Sol]] 06:54, 30 September 2007 (PDT) (Please see my notes: [https://lists.secondlife.com/pipermail/sldev/2007-October/005605.html] [https://lists.secondlife.com/pipermail/sldev/2007-October/005615.html])<br /> * [[User:Eloise Pasteur|Eloise Pasteur]] 06:57, 30 September 2007 (PDT)<br /> * [[User:Becky Tardis|Becky Tardis]] 08:34, 30 September 2007 (PDT)<br /> * [[User:Peter Newell|Peter Newell]] 14:14, 30 September 2007 (PDT)<br /> * [[User:Dr Scofield|Dr Scofield]] 00:45, 1 October 2007 (PDT)<br /> * [[User:Jabath Steuart|Jabath Steuart]] 04:03, 1 October 2007 (PDT)<br /> * [[User:Nik Woodget|Nik Woodget]] 05:19, 1 October 2007 (PDT)<br /> * [[User:Whoops Babii|Whoops Babii]] 05:29, 1 October 2007 (PDT)<br /> * [[User:Feep Larsson|Feep Larsson]] 06:29, 1 October 2007 (PDT)<br /> * [[User:Gibson Willis|Gibson Willis]] 07:11, 1 October 2007 (PDT)<br /> * [[User:Grazer Kline|Grazer Kline]] 10:34, 1 October 2007 (PDT)<br /> * [[User:Odysseus Fairymeadow|Odysseus Fairymeadow]] 13:58, 1 October 2007 (PDT)</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Viewer_Authentication_Critique&diff=34068 Viewer Authentication Critique 2007-10-02T08:48:09Z

<p>Matthew Dowd: /* Alternatives */</p> <hr /> <div>This is a formal critique of [[Viewer Authentication]] that was [https://lists.secondlife.com/pipermail/sldev/2007-September/005403.html requested] by [[User:Rob Linden]] on the [[SLDev]] mailing list.<br /> <br /> For a branch of the discussion see [https://wiki.secondlife.com/wiki/Talk:Viewer_Authentication Talk page on the original proposal.]<br /> <br /> == Note ==<br /> <br /> It was not explicit what the goals behind LL's proposed new authentication system are. The goals (Security, Flexibility, Persistence) and Objectives listed here are what SLDev believe them to be based on the original description and e-mail discussions.<br /> <br /> == Summary ==<br /> <br /> The new authentication method proposed by LL seems to be an attempt to solve a perceived but non-existent problem. <br /> <br /> There are currently no known password capturing third party viewers in the wild, and a third party viewer requires such a privilege level of access to an account anyway that if you don't trust it with your username and password, you shouldn't be running it anyway. The mechanism proposed, however, is more prone to phishing attacks. Most password compromises are probably due to weaknesses in the current protocol challenge response, due to allowing weak passwords or due to the usual phishing e-mails (which are likely to be increased by the proposed method rather than decreased).<br /> <br /> Providing a single authentication mechanism for LL (and third party) websites would be an improvement to multiple backend copies of username and password, however this could be implemented without touching the viewer authentication method. Support for OpenID and other identity metasystems would increase the flexibility and offer features such as brokered identity verification. However, these would only be part of the solution, and although the proposed mechanism would provide a way for future support of these, there are other ways this could be achieved. Future support for OpenID is perhaps a topic for a seperate discussion and debate, but a open debate on this should happen.<br /> <br /> There seems to be no real demand to synchronise the authentication of the viewer with authentication on the SL web site (account, forums, etc.), and any benefits gained would be negated by the problems this would cause anyone running alts (e.g. for in world permissions testing etc.) or multiple viewers (e.g. main, test and firstlook). It also raises problems for those running OpenSim based Grids, and may also cause difficulties further down the line as regards the new architecture discussions. A relatively simpler mod to the web site could prevent the account details for a different alt displaying when the account menu options are selected in the client.<br /> <br /> Overall, the additional development time both with LL and for external developers doesn't seem to warrant the promoted benefits.<br /> <br /> It was also noted that consideration should be given when considering enhancements to the security/authentication models whether these should be optional - allowing users to make their own risk/convenience decisions.<br /> <br /> == Security ==<br /> <br /> === LL's Objectives ===<br /> * To mitigate the danger of password capturing Trojans masquerading as third party viewers<br /> * Improve trust in third party viewers by providing a means of assurance to the user that the third party viewer could not be a Trojan capturing usernames and passwords.<br /> * To consolidate the authentication implementation in order to support back-end anti-fraud work<br /> <br /> === Pros ===<br /> * Viewer does not have to process (and "see") username and password<br /> <br /> === Cons ===<br /> * The main risk of running a third party viewer (or any other application not provided by Linden Labs) is not stealing passwords, it's direct attacks through the client... and the "official" client is not really any protection against that.<br /> ** Viewer can still be used in direct and indirect attacks even if it never sees the password (for example: salami slicing through cutout accounts, acting as a cutout account or an in-world botnet, faking a failed connection while giving an attacker access).<br /> ** NON-viewer applications (such as editors, 3d tools) designed for use by SL residents could use a keystroke logger and macro to perform any of these attacks, or could inject code into the viewer to do the same thing. Look at 'cheating' programs in combat MMORPGs for ideas.<br /> * But this is still not a large risk, unless people get the client through a mechanism that makes the creator anonymous. Historically, attempts to disseminate boobytrapped versions of applications have only worked in environments where it's routine for people to download applications from anonymous sources (file areas in the BBS era, for example). It's too easy to trace down the originator of any compromised client when you're getting them from their own website.<br /> <br><br /> * Bottom line here is that third party viewers stealing passwords are a very small risk for the user: the bigger risk is from the web browser!<br /> ** Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.<br /> *** This kind of attack is not theoretical, phishing websites are a criminal industry.<br /> *** It would be very easy to set up a temporary (i.e. hard to trace the real owner) phishing webpage which looks like the official SL logon, and send e-mails such as "You've received xxx in SL, Click here to logon" apparently from LL - with far less work than trying to create, and entice people to download a trojan viewer<br /> ** Relies on browser security, and uses a mechanism often disabled or filtered due to security concerns<br /> ** Too reliant on browser/OS implementations (proxies, firewalls, used browsers, etc.)<br /> * So using the browser to perform the authentication moves the authentication to a mechanism that has historically proven more likely to be compromised.<br /> <br><br /> * And the mechanism itself is relatively inflexible.<br /> ** Links to secondlife:// can only point to one instance (version, e.g. homebrew, release candidate official) of the program<br /> ** Links to secondlife:// can not pass parameters to the program<br /> *** In fact allowing that was a security flaw recently found and fixed in the SL client. :(<br /> ** It will raise problems for those running alternative (e.g. OpenSim) grids, and also have impact on the dicussions for a future open grid.<br /> ** If the viewer provides the webpage inline, this escalates the importance of addressing a number of current problems with llmozlib in the current viewer code<br /> *** there are problems compiling llmozlib on the Linux platform<br /> *** proxies are not supported<br /> <br><br /> * Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)<br /> ** The issues raised in the next sections would mean that people would have an incentive to use this kind of client.<br /> <br /> === Alternatives ===<br /> * One time passwords (for copy paste into a non-secure viewer or to print and take with you to friends, internet cafes, public terminals, etc.)<br /> * lower perm passwords (pwds which put the account into a restricted state, disallowing "dangerous" transactions)<br /> * separate passwords for website account and being inworld<br /> * Account restrictions <br /> * Allow third party plug-ins in the viewer (these would allow the extra functionality which are sometimes the reason for running third party viewers, but would rely on the official viewer for validation)<br /> * For considation have a single backend web service which does the actual authentication - but which is fronted by GUI frontends (e.g. in the viewer) and web frontends (e.g. for accessing the web based account pages etc.)<br /> * Do nothing, keep everything as it is.<br /> ** Without a strong case for the status quo being a problem, this is certainly a viable alternative, particularly given the impact this will have on developers of third party tools and viewers<br /> ** It is arguable that most losses of assets and value are incurred due to SL bugs (inventory, classifieds search, etc.) and outtages rather than through account compromises<br /> <br><br /> * Log of successful or failed login attempts including ip address (or at least a notice of the last attempt)<br /> * Black, White or Greylist IP (specific or > network ranges)- This would allow someone with a static, or semi-static IP to prevent client logons to their account unless they appear on the Whitelist of approved IP's. Greylisting would allow one login attempt every 5-10 minutes and could be used when traveling. > IP's on the blacklist would not be able to log into the account at all<br /> ** Question: how many people have, or even know they have, static or semi static IPs?<br /> <br><br /> * This may be the wrong problem - password compromises are more likely to be through standard phishing attacks (logon here to update your account info) which is not addressed, or by weaknesses in the current authentication mechnism or just insecure passwords.<br /> ** CRAM-MD5 or a similar challenge-response type <br /> ** Dictionary check to reject insecure passwords<br /> <br /> == Flexibility ==<br /> <br /> === LL's Objectives ===<br /> * Single Sign On - allowing multiple web applications (forums, support, account, jira, wiki etc.) and viewers to use the same username and password through a single point without duplicating usernames and passwords into multiple systems<br /> * Extension of this to allow non-LL applications and web sites to participate in this single sign on system.<br /> <br /> === Pros ===<br /> * Enables username/password authentication to work on third party sites without them having to "see" username and password<br /> <br /> === Cons ===<br /> * This is really an unrelated issue...<br /> ** The client doesn't need to depend on the website for this purpose, or this could be a command line option.<br /> ** The client could just as easily be the 'authentication source' as the website.<br /> *** Via a "go to website" link in the client that passed an equivalent token.<br /> <br><br /> * As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> <br /> === Alternatives ===<br /> * Use this mechanism for websites (including third party) only but not for viewers<br /> <br><br /> * Identity Metasystem - [http://en.wikipedia.org/wiki/Identity_Metasystem]<br /> ** OpenID - [http://openid.net/]<br /> ** CardSpace - [http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx]<br /> ** Shibboleth - [http://shibboleth.internet2.edu/]<br /> ** CAS - [http://www.ja-sig.org/products/cas/]<br /> *** These could be handled by the client poping up a window using the internal web browser to connect to a HTML logon. It may be difficult or impossible to determine if the client really is displaying the official HTML logon and not capturing key strokes so this would be a way of implementing the above for flexibility or other reasons (e.g. brokered identity verification [http://www.agimo.gov.au/publications/2004/05/egovt_challenges/privacy/identity/brokered]) not for security<br /> <br /> == Persistence ==<br /> <br /> === LL's Objectives ===<br /> * To synchronise the various LL's systems (forums, support, jira, account, etc.) so that by logging onto one, you are automatically logged onto the others.<br /> <br /> === Pros ===<br /> * Selecting "Account History" or "Manage My Account" and similar menu items would open the web page for the account logged into SL, rather than the account logged into the web site, which currently can be different<br /> <br /> === Cons ===<br /> * As in the previous section, LL's objectives could be met without the viewer logging in via the same mechanism.<br /> * Inconvenient for those with alts or multiple clients<br /> ** Cumbersome to change alts and logon with multiple alts<br /> ** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL<br /> ** As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> * Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.<br /> * Staying online on secondlife.com (which many people seem to do) automatically means anyone with access to the computer/browser (family) can log in with the account inworld<br /> * starting SL from the web browser on a regular basis will most likely result in the web browser lingering in memory in the background when running the viewer, which based on the heavy memory requirement may impair viewer performance.<br /> * this would have an impact on the architecture discussions for a future open grid.<br /> <br /> === Alternatives ===<br /> * As regards menu items such as "Account History", send the account name on the URL, and have the web page check if that is the currently logged on account. If not prompt the user to log on with the same account as being used in the viewer (for security reasons the viewer should not automatically log the account on to the web site in such cases).<br /> * Is this really needed or desirable (''for the client'')? SL is not an extension of the web, it's a different kind of interface... one that has the potential of becoming a "3d web".<br /> <br /> == Signatories ==<br /> <br /> Please sign this below with "<nowiki>~~~~</nowiki>" if you agree with the version of this document you are reading. The date will indicate which version of the document you read and agree with. <br /> <br /> * [[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)<br /> * [[User:Argent Stonecutter|Argent Stonecutter]] 13:53, 29 September 2007 (PDT)<br /> * [[User:Dale Glass|Dale Glass]] 14:28, 29 September 2007 (PDT)<br /> * [[User:Tillie Ariantho|Tillie Ariantho]] 03:48, 30 September 2007 (PDT)<br /> * [[User:Jesse Barnett|Jesse Barnett]] 9:53, 30 September 2007 (PDT)<br /> * [[User:Winter Ventura|Winter Ventura]] 19:42, 29 September 2007 (PDT)<br /> * [[User:Balp Allen|Balp Allen]] 01:33, 30 September 2007 (PDT)<br /> * [[User:Michelle2 Zenovka|Michelle2 Zenovka]] 02:52, 30 September 2007 (PDT)<br /> * [[User:Nicholaz Beresford|Nicholaz]] 03:42, 30 September 2007 (PDT)<br /> * [[User:Dzonatas Sol|Dzonatas Sol]] 06:54, 30 September 2007 (PDT)<br /> * [[User:Eloise Pasteur|Eloise Pasteur]] 06:57, 30 September 2007 (PDT)<br /> * [[User:Becky Tardis|Becky Tardis]] 08:34, 30 September 2007 (PDT)<br /> * [[User:Peter Newell|Peter Newell]] 14:14, 30 September 2007 (PDT)<br /> * [[User:Dr Scofield|Dr Scofield]] 00:45, 1 October 2007 (PDT)<br /> * [[User:Jabath Steuart|Jabath Steuart]] 04:03, 1 October 2007 (PDT)<br /> * [[User:Nik Woodget|Nik Woodget]] 05:19, 1 October 2007 (PDT)<br /> * [[User:Whoops Babii|Whoops Babii]] 05:29, 1 October 2007 (PDT)<br /> * [[User:Feep Larsson|Feep Larsson]] 06:29, 1 October 2007 (PDT)<br /> * [[User:Gibson Willis|Gibson Willis]] 07:11, 1 October 2007 (PDT)<br /> * [[User:Grazer Kline|Grazer Kline]] 10:34, 1 October 2007 (PDT)<br /> * [[User:Odysseus Fairymeadow|Odysseus Fairymeadow]] 13:58, 1 October 2007 (PDT)</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Viewer_Authentication_Critique&diff=34067 Viewer Authentication Critique 2007-10-02T08:44:35Z

<p>Matthew Dowd: </p> <hr /> <div>This is a formal critique of [[Viewer Authentication]] that was [https://lists.secondlife.com/pipermail/sldev/2007-September/005403.html requested] by [[User:Rob Linden]] on the [[SLDev]] mailing list.<br /> <br /> For a branch of the discussion see [https://wiki.secondlife.com/wiki/Talk:Viewer_Authentication Talk page on the original proposal.]<br /> <br /> == Note ==<br /> <br /> It was not explicit what the goals behind LL's proposed new authentication system are. The goals (Security, Flexibility, Persistence) and Objectives listed here are what SLDev believe them to be based on the original description and e-mail discussions.<br /> <br /> == Summary ==<br /> <br /> The new authentication method proposed by LL seems to be an attempt to solve a perceived but non-existent problem. <br /> <br /> There are currently no known password capturing third party viewers in the wild, and a third party viewer requires such a privilege level of access to an account anyway that if you don't trust it with your username and password, you shouldn't be running it anyway. The mechanism proposed, however, is more prone to phishing attacks. Most password compromises are probably due to weaknesses in the current protocol challenge response, due to allowing weak passwords or due to the usual phishing e-mails (which are likely to be increased by the proposed method rather than decreased).<br /> <br /> Providing a single authentication mechanism for LL (and third party) websites would be an improvement to multiple backend copies of username and password, however this could be implemented without touching the viewer authentication method. Support for OpenID and other identity metasystems would increase the flexibility and offer features such as brokered identity verification. However, these would only be part of the solution, and although the proposed mechanism would provide a way for future support of these, there are other ways this could be achieved. Future support for OpenID is perhaps a topic for a seperate discussion and debate, but a open debate on this should happen.<br /> <br /> There seems to be no real demand to synchronise the authentication of the viewer with authentication on the SL web site (account, forums, etc.), and any benefits gained would be negated by the problems this would cause anyone running alts (e.g. for in world permissions testing etc.) or multiple viewers (e.g. main, test and firstlook). It also raises problems for those running OpenSim based Grids, and may also cause difficulties further down the line as regards the new architecture discussions. A relatively simpler mod to the web site could prevent the account details for a different alt displaying when the account menu options are selected in the client.<br /> <br /> Overall, the additional development time both with LL and for external developers doesn't seem to warrant the promoted benefits.<br /> <br /> It was also noted that consideration should be given when considering enhancements to the security/authentication models whether these should be optional - allowing users to make their own risk/convenience decisions.<br /> <br /> == Security ==<br /> <br /> === LL's Objectives ===<br /> * To mitigate the danger of password capturing Trojans masquerading as third party viewers<br /> * Improve trust in third party viewers by providing a means of assurance to the user that the third party viewer could not be a Trojan capturing usernames and passwords.<br /> * To consolidate the authentication implementation in order to support back-end anti-fraud work<br /> <br /> === Pros ===<br /> * Viewer does not have to process (and "see") username and password<br /> <br /> === Cons ===<br /> * The main risk of running a third party viewer (or any other application not provided by Linden Labs) is not stealing passwords, it's direct attacks through the client... and the "official" client is not really any protection against that.<br /> ** Viewer can still be used in direct and indirect attacks even if it never sees the password (for example: salami slicing through cutout accounts, acting as a cutout account or an in-world botnet, faking a failed connection while giving an attacker access).<br /> ** NON-viewer applications (such as editors, 3d tools) designed for use by SL residents could use a keystroke logger and macro to perform any of these attacks, or could inject code into the viewer to do the same thing. Look at 'cheating' programs in combat MMORPGs for ideas.<br /> * But this is still not a large risk, unless people get the client through a mechanism that makes the creator anonymous. Historically, attempts to disseminate boobytrapped versions of applications have only worked in environments where it's routine for people to download applications from anonymous sources (file areas in the BBS era, for example). It's too easy to trace down the originator of any compromised client when you're getting them from their own website.<br /> <br><br /> * Bottom line here is that third party viewers stealing passwords are a very small risk for the user: the bigger risk is from the web browser!<br /> ** Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.<br /> *** This kind of attack is not theoretical, phishing websites are a criminal industry.<br /> *** It would be very easy to set up a temporary (i.e. hard to trace the real owner) phishing webpage which looks like the official SL logon, and send e-mails such as "You've received xxx in SL, Click here to logon" apparently from LL - with far less work than trying to create, and entice people to download a trojan viewer<br /> ** Relies on browser security, and uses a mechanism often disabled or filtered due to security concerns<br /> ** Too reliant on browser/OS implementations (proxies, firewalls, used browsers, etc.)<br /> * So using the browser to perform the authentication moves the authentication to a mechanism that has historically proven more likely to be compromised.<br /> <br><br /> * And the mechanism itself is relatively inflexible.<br /> ** Links to secondlife:// can only point to one instance (version, e.g. homebrew, release candidate official) of the program<br /> ** Links to secondlife:// can not pass parameters to the program<br /> *** In fact allowing that was a security flaw recently found and fixed in the SL client. :(<br /> ** It will raise problems for those running alternative (e.g. OpenSim) grids, and also have impact on the dicussions for a future open grid.<br /> ** If the viewer provides the webpage inline, this escalates the importance of addressing a number of current problems with llmozlib in the current viewer code<br /> *** there are problems compiling llmozlib on the Linux platform<br /> *** proxies are not supported<br /> <br><br /> * Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)<br /> ** The issues raised in the next sections would mean that people would have an incentive to use this kind of client.<br /> <br /> === Alternatives ===<br /> * One time passwords (for copy paste into a non-secure viewer or to print and take with you to friends, internet cafes, public terminals, etc.)<br /> * lower perm passwords (pwds which put the account into a restricted state, disallowing "dangerous" transactions)<br /> * separate passwords for website account and being inworld<br /> * Account restrictions <br /> * Allow third party plug-ins in the viewer (these would allow the extra functionality which are sometimes the reason for running third party viewers, but would rely on the official viewer for validation)<br /> * Do nothing, keep everything as it is.<br /> ** Without a strong case for the status quo being a problem, this is certainly a viable alternative, particularly given the impact this will have on developers of third party tools and viewers<br /> ** It is arguable that most losses of assets and value are incurred due to SL bugs (inventory, classifieds search, etc.) and outtages rather than through account compromises<br /> <br><br /> * Log of successful or failed login attempts including ip address (or at least a notice of the last attempt)<br /> * Black, White or Greylist IP (specific or > network ranges)- This would allow someone with a static, or semi-static IP to prevent client logons to their account unless they appear on the Whitelist of approved IP's. Greylisting would allow one login attempt every 5-10 minutes and could be used when traveling. > IP's on the blacklist would not be able to log into the account at all<br /> ** Question: how many people have, or even know they have, static or semi static IPs?<br /> <br><br /> * This may be the wrong problem - password compromises are more likely to be through standard phishing attacks (logon here to update your account info) which is not addressed, or by weaknesses in the current authentication mechnism or just insecure passwords.<br /> ** CRAM-MD5 or a similar challenge-response type <br /> ** Dictionary check to reject insecure passwords<br /> <br /> == Flexibility ==<br /> <br /> === LL's Objectives ===<br /> * Single Sign On - allowing multiple web applications (forums, support, account, jira, wiki etc.) and viewers to use the same username and password through a single point without duplicating usernames and passwords into multiple systems<br /> * Extension of this to allow non-LL applications and web sites to participate in this single sign on system.<br /> <br /> === Pros ===<br /> * Enables username/password authentication to work on third party sites without them having to "see" username and password<br /> <br /> === Cons ===<br /> * This is really an unrelated issue...<br /> ** The client doesn't need to depend on the website for this purpose, or this could be a command line option.<br /> ** The client could just as easily be the 'authentication source' as the website.<br /> *** Via a "go to website" link in the client that passed an equivalent token.<br /> <br><br /> * As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> <br /> === Alternatives ===<br /> * Use this mechanism for websites (including third party) only but not for viewers<br /> <br><br /> * Identity Metasystem - [http://en.wikipedia.org/wiki/Identity_Metasystem]<br /> ** OpenID - [http://openid.net/]<br /> ** CardSpace - [http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx]<br /> ** Shibboleth - [http://shibboleth.internet2.edu/]<br /> ** CAS - [http://www.ja-sig.org/products/cas/]<br /> *** These could be handled by the client poping up a window using the internal web browser to connect to a HTML logon. It may be difficult or impossible to determine if the client really is displaying the official HTML logon and not capturing key strokes so this would be a way of implementing the above for flexibility or other reasons (e.g. brokered identity verification [http://www.agimo.gov.au/publications/2004/05/egovt_challenges/privacy/identity/brokered]) not for security<br /> <br /> == Persistence ==<br /> <br /> === LL's Objectives ===<br /> * To synchronise the various LL's systems (forums, support, jira, account, etc.) so that by logging onto one, you are automatically logged onto the others.<br /> <br /> === Pros ===<br /> * Selecting "Account History" or "Manage My Account" and similar menu items would open the web page for the account logged into SL, rather than the account logged into the web site, which currently can be different<br /> <br /> === Cons ===<br /> * As in the previous section, LL's objectives could be met without the viewer logging in via the same mechanism.<br /> * Inconvenient for those with alts or multiple clients<br /> ** Cumbersome to change alts and logon with multiple alts<br /> ** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL<br /> ** As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> * Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.<br /> * Staying online on secondlife.com (which many people seem to do) automatically means anyone with access to the computer/browser (family) can log in with the account inworld<br /> * starting SL from the web browser on a regular basis will most likely result in the web browser lingering in memory in the background when running the viewer, which based on the heavy memory requirement may impair viewer performance.<br /> * this would have an impact on the architecture discussions for a future open grid.<br /> <br /> === Alternatives ===<br /> * As regards menu items such as "Account History", send the account name on the URL, and have the web page check if that is the currently logged on account. If not prompt the user to log on with the same account as being used in the viewer (for security reasons the viewer should not automatically log the account on to the web site in such cases).<br /> * Is this really needed or desirable (''for the client'')? SL is not an extension of the web, it's a different kind of interface... one that has the potential of becoming a "3d web".<br /> <br /> == Signatories ==<br /> <br /> Please sign this below with "<nowiki>~~~~</nowiki>" if you agree with the version of this document you are reading. The date will indicate which version of the document you read and agree with. <br /> <br /> * [[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)<br /> * [[User:Argent Stonecutter|Argent Stonecutter]] 13:53, 29 September 2007 (PDT)<br /> * [[User:Dale Glass|Dale Glass]] 14:28, 29 September 2007 (PDT)<br /> * [[User:Tillie Ariantho|Tillie Ariantho]] 03:48, 30 September 2007 (PDT)<br /> * [[User:Jesse Barnett|Jesse Barnett]] 9:53, 30 September 2007 (PDT)<br /> * [[User:Winter Ventura|Winter Ventura]] 19:42, 29 September 2007 (PDT)<br /> * [[User:Balp Allen|Balp Allen]] 01:33, 30 September 2007 (PDT)<br /> * [[User:Michelle2 Zenovka|Michelle2 Zenovka]] 02:52, 30 September 2007 (PDT)<br /> * [[User:Nicholaz Beresford|Nicholaz]] 03:42, 30 September 2007 (PDT)<br /> * [[User:Dzonatas Sol|Dzonatas Sol]] 06:54, 30 September 2007 (PDT)<br /> * [[User:Eloise Pasteur|Eloise Pasteur]] 06:57, 30 September 2007 (PDT)<br /> * [[User:Becky Tardis|Becky Tardis]] 08:34, 30 September 2007 (PDT)<br /> * [[User:Peter Newell|Peter Newell]] 14:14, 30 September 2007 (PDT)<br /> * [[User:Dr Scofield|Dr Scofield]] 00:45, 1 October 2007 (PDT)<br /> * [[User:Jabath Steuart|Jabath Steuart]] 04:03, 1 October 2007 (PDT)<br /> * [[User:Nik Woodget|Nik Woodget]] 05:19, 1 October 2007 (PDT)<br /> * [[User:Whoops Babii|Whoops Babii]] 05:29, 1 October 2007 (PDT)<br /> * [[User:Feep Larsson|Feep Larsson]] 06:29, 1 October 2007 (PDT)<br /> * [[User:Gibson Willis|Gibson Willis]] 07:11, 1 October 2007 (PDT)<br /> * [[User:Grazer Kline|Grazer Kline]] 10:34, 1 October 2007 (PDT)<br /> * [[User:Odysseus Fairymeadow|Odysseus Fairymeadow]] 13:58, 1 October 2007 (PDT)</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Talk:Viewer_Authentication_Critique&diff=33918 Talk:Viewer Authentication Critique 2007-10-01T16:14:02Z

<p>Matthew Dowd: </p> <hr /> <div>{{Talk}}<br /> <br /> == Process for editing the critique ==<br /> <br /> By virtue of jumping first, I think [[User:Matthew Dowd|Matthew Dowd]] should be the working group chair for editing this document. What I think that means is this:<br /> * Anyone can still make no-brainer edits to the article<br /> * Matthew will be arbiter for dispute resolution, should that be necessary.<br /> * If there are points that Matthew is unclear about, he should delete them from the document, and move them to the talk page.<br /> * If there are points that others are unclear about, they should bring them up on the talk page, and then later delete them from the main page if a question/concern goes unanswered on the talk page (with "see talk page" in the comment of the edit).<br /> * If, for whatever reason, it becomes necessary to fork this document, it's best to move all critiques into the user space of the working group chair. So, for example, Matthew's version would move to [[User:Matthew Dowd/Viewer Authentication Critique]], and other critiques could also be done the same way. This page would become a list of critiques.<br /> <br /> Sound like a reasonable process? I think this is lightweight enough that a pretty good document can evolve pretty quickly. -- [[User:Rob Linden|Rob Linden]] 12:56, 29 September 2007 (PDT)<br /> <br /> == Third party viewers/code ==<br /> <br /> What's the substantive difference between these two points?<br /> # Viewer still involves running trusted code on the computer and could initiate other attacks e.g.<br /> # Most of these attacks could be performed by any third-party software designed for use with SL <br /> Both have many subpoints. Could they be consolidated into a single point? -- [[User:Rob Linden|Rob Linden]] 20:10, 29 September 2007 (PDT)<br /> <br /> The first point is that keeping the client from seeing the password doesn't remove the danger of a modified client.<br /> <br /> The second point is that *any* ancillary software (such as animation editors, sculpt editors, sculpt texture plugins) could be used in an attack, even if they don't actually connect to SL, since they would be used by SL residents.<br /> <br /> -- [[User:Argent Stonecutter|Argent Stonecutter]] 21:00, 29 September 2007 (PDT)<br /> <br /> Is this better, Rob? -- [[User:Argent Stonecutter|Argent Stonecutter]] 21:11, 29 September 2007 (PDT)<br /> <br /> :Yes, that is. Thanks for the clarification! -- [[User:Rob Linden|Rob Linden]] 21:44, 29 September 2007 (PDT)<br /> <br /> <br /> == No balance ==<br /> <br /> This article is pretty awful, its just an attack. For real critique you have to explore the alternatives and discuss the pros and cons for each.<br /> Even if this form of log in has these disadvantages it could still be an improvement over what we currently have.<br /> We need a common point of reference to discuss if this is an improvement and what alternatives exist. [[User:Ahab Schmo|Ahab Schmo]] 12:31, 30 September 2007 (PDT)<br /> <br /> <br /> == Nicholaz's Summary to SLDev ==<br /> <br /> I think (and would be surprised otherwise) there currently consensus<br /> among those who replied here on the list that ...<br /> <br /> 1) the new auth mechanism does nothing to significantly increase security<br /> in terms of protecting user assets from malicious viewers (once the<br /> viewer is logged in, you're at the mercy of the viewer, no matter how> you logged in)<br /> <br /> 2) the new auth mechanism makes login to SL cumbersome and breaks many<br /> ways in which people are currently using SL (alts, switching between<br /> viewers, etc.)<br /> <br /> 3) the new auth mechanism will make it impossible for some environment<br /> to log in from at all (proxies, firewalls, security software, ...)<br /> or prevent specific forms of viewers (lean viewers, mobile systems,<br /> viewer on a memory stick, ...)<br /> <br /> 4) the new auth mechanism will break existing applications (bots, libsl,<br /> etc.) and these will have to work around these.<br /> <br /> 5) Allowing these (4) to work around it, means that 3rd party viewers can<br /> also work around it, meaning that you'll end up with 3rd party viewers<br /> which are a lot more convenient than the official viewer, essentially> driving people away from the official viewer.<br /> <br /> 6) other mechanisms exist, which a) actually increase security and which<br /> b) do not break existing use and c) are less cumbersome<br /> <br /> 7) (this is my personal addition but I'd be amazed if anyone disagreed)<br /> people are losing a lot more assets and value through Linden<br /> malfunctions (lost inventory, search & classifieds being not seen<br /> because of outages, etc.) than have ever been lost through spoofing<br /> or malicious viewers.<br /> <br /> 8) __whatever mechanism is implemented, should be a *choice* with the__<br /> __existing mechanisms remaining in place__<br /> <br /> 9) (see (8) )<br /> <br /> 10) (see (9) )<br /> <br /> Bottom line is that the new auth mechanism is something that offers neglectible<br /> improvement in security and will cause countless problems or developer<br /> hours on both sides.</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Viewer_Authentication_Critique&diff=33917 Viewer Authentication Critique 2007-10-01T16:13:26Z

<p>Matthew Dowd: /* Summary */</p> <hr /> <div>This is a formal critique of [[Viewer Authentication]] that was [https://lists.secondlife.com/pipermail/sldev/2007-September/005403.html requested] by [[User:Rob Linden]] on the [[SLDev]] mailing list.<br /> <br /> For a branch of the discussion see [https://wiki.secondlife.com/wiki/Talk:Viewer_Authentication Talk page on the original proposal.]<br /> <br /> == Summary ==<br /> <br /> The new authentication method proposed by LL seems to be an attempt to solve a perceived but non-existent problem. <br /> <br /> There are currently no known password capturing third party viewers in the wild, and a third party viewer requires such a privilege level of access to an account anyway that if you don't trust it with your username and password, you shouldn't be running it anyway. The mechanism proposed, however, is more prone to phishing attacks. Most password compromises are probably due to weaknesses in the current protocol challenge response, due to allowing weak passwords or due to the usual phishing e-mails (which are likely to be increased by the proposed method rather than decreased).<br /> <br /> Providing a single authentication mechanism for LL (and third party) websites would be an improvement to multiple backend copies of username and password, however this could be implemented without touching the viewer authentication method. Support for OpenID and other identity metasystems would increase the flexibility and offer features such as brokered identity verification. However, these would only be part of the solution, and although the proposed mechanism would provide a way for future support of these, there are other ways this could be achieved. Future support for OpenID is perhaps a topic for a seperate discussion and debate, but a open debate on this should happen.<br /> <br /> There seems to be no real demand to synchronise the authentication of the viewer with authentication on the SL web site (account, forums, etc.), and any benefits gained would be negated by the problems this would cause anyone running alts (e.g. for in world permissions testing etc.) or multiple viewers (e.g. main, test and firstlook). It also raises problems for those running OpenSim based Grids, and may also cause difficulties further down the line as regards the new architecture discussions. A relatively simpler mod to the web site could prevent the account details for a different alt displaying when the account menu options are selected in the client.<br /> <br /> Overall, the additional development time both with LL and for external developers doesn't seem to warrant the promoted benefits.<br /> <br /> It was also noted that consideration should be given when considering enhancements to the security/authentication models whether these should be optional - allowing users to make their own risk/convenience decisions.<br /> <br /> == Security ==<br /> <br /> === LL's Objectives ===<br /> * To mitigate the danger of password capturing Trojans masquerading as third party viewers<br /> * Improve trust in third party viewers by providing a means of assurance to the user that the third party viewer could not be a Trojan capturing usernames and passwords.<br /> <br /> === Pros ===<br /> * Viewer does not have to process (and "see") username and password<br /> <br /> === Cons ===<br /> * The main risk of running a third party viewer (or any other application not provided by Linden Labs) is not stealing passwords, it's direct attacks through the client... and the "official" client is not really any protection against that.<br /> ** Viewer can still be used in direct and indirect attacks even if it never sees the password (for example: salami slicing through cutout accounts, acting as a cutout account or an in-world botnet, faking a failed connection while giving an attacker access).<br /> ** NON-viewer applications (such as editors, 3d tools) designed for use by SL residents could use a keystroke logger and macro to perform any of these attacks, or could inject code into the viewer to do the same thing. Look at 'cheating' programs in combat MMORPGs for ideas.<br /> * But this is still not a large risk, unless people get the client through a mechanism that makes the creator anonymous. Historically, attempts to disseminate boobytrapped versions of applications have only worked in environments where it's routine for people to download applications from anonymous sources (file areas in the BBS era, for example). It's too easy to trace down the originator of any compromised client when you're getting them from their own website.<br /> <br><br /> * Bottom line here is that third party viewers stealing passwords are a very small risk for the user: the bigger risk is from the web browser!<br /> ** Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.<br /> *** This kind of attack is not theoretical, phishing websites are a criminal industry.<br /> *** It would be very easy to set up a temporary (i.e. hard to trace the real owner) phishing webpage which looks like the official SL logon, and send e-mails such as "You've received xxx in SL, Click here to logon" apparently from LL - with far less work than trying to create, and entice people to download a trojan viewer<br /> ** Relies on browser security, and uses a mechanism often disabled or filtered due to security concerns<br /> ** Too reliant on browser/OS implementations (proxies, firewalls, used browsers, etc.)<br /> * So using the browser to perform the authentication moves the authentication to a mechanism that has historically proven more likely to be compromised.<br /> <br><br /> * And the mechanism itself is relatively inflexible.<br /> ** Links to secondlife:// can only point to one instance (version, e.g. homebrew, release candidate official) of the program<br /> ** Links to secondlife:// can not pass parameters to the program<br /> *** In fact allowing that was a security flaw recently found and fixed in the SL client. :(<br /> ** It will raise problems for those running alternative (e.g. OpenSim) grids, and also have impact on the dicussions for a future open grid.<br /> <br><br /> * Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)<br /> ** The issues raised in the next sections would mean that people would have an incentive to use this kind of client.<br /> <br /> === Alternatives ===<br /> * One time passwords (for copy paste into a non-secure viewer or to print and take with you to friends, internet cafes, public terminals, etc.)<br /> * lower perm passwords (pwds which put the account into a restricted state, disallowing "dangerous" transactions)<br /> * separate passwords for website account and being inworld<br /> * Account restrictions <br /> * Allow third party plug-ins in the viewer (these would allow the extra functionality which are sometimes the reason for running third party viewers, but would rely on the official viewer for validation)<br /> * Do nothing, keep everything as it is.<br /> ** Without a strong case for the status quo being a problem, this is certainly a viable alternative, particularly given the impact this will have on developers of third party tools and viewers<br /> ** It is arguable that most losses of assets and value are incurred due to SL bugs (inventory, classifieds search, etc.) and outtages rather than through account compromises<br /> <br><br /> * This may be the wrong problem - password compromises are more likely to be through standard phishing attacks (logon here to update your account info) which is not addressed, or by weaknesses in the current authentication mechnism or just insecure passwords.<br /> ** CRAM-MD5 or a similar challenge-response type <br /> ** Dictionary check to reject insecure passwords<br /> <br /> == Flexibility ==<br /> <br /> === LL's Objectives ===<br /> * Single Sign On - allowing multiple web applications (forums, support, account, jira, wiki etc.) and viewers to use the same username and password through a single point without duplicating usernames and passwords into multiple systems<br /> * Extension of this to allow non-LL applications and web sites to participate in this single sign on system.<br /> <br /> === Pros ===<br /> * Enables username/password authentication to work on third party sites without them having to "see" username and password<br /> <br /> === Cons ===<br /> * This is really an unrelated issue...<br /> ** The client doesn't need to depend on the website for this purpose, or this could be a command line option.<br /> ** The client could just as easily be the 'authentication source' as the website.<br /> *** Via a "go to website" link in the client that passed an equivalent token.<br /> <br><br /> * As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> <br /> === Alternatives ===<br /> * Use this mechanism for websites (including third party) only but not for viewers<br /> <br><br /> * Identity Metasystem - [http://en.wikipedia.org/wiki/Identity_Metasystem]<br /> ** OpenID - [http://openid.net/]<br /> ** CardSpace - [http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx]<br /> ** Shibboleth - [http://shibboleth.internet2.edu/]<br /> ** CAS - [http://www.ja-sig.org/products/cas/]<br /> *** These could be handled by the client poping up a window using the internal web browser to connect to a HTML logon. It may be difficult or impossible to determine if the client really is displaying the official HTML logon and not capturing key strokes so this would be a way of implementing the above for flexibility or other reasons (e.g. brokered identity verification [http://www.agimo.gov.au/publications/2004/05/egovt_challenges/privacy/identity/brokered]) not for security<br /> <br /> == Persistence ==<br /> <br /> === LL's Objectives ===<br /> * To synchronise the various LL's systems (forums, support, jira, account, etc.) so that by logging onto one, you are automatically logged onto the others.<br /> <br /> === Pros ===<br /> * Selecting "Account History" or "Manage My Account" and similar menu items would open the web page for the account logged into SL, rather than the account logged into the web site, which currently can be different<br /> <br /> === Cons ===<br /> * As in the previous section, LL's objectives could be met without the viewer logging in via the same mechanism.<br /> * Inconvenient for those with alts or multiple clients<br /> ** Cumbersome to change alts and logon with multiple alts<br /> ** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL<br /> ** As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> * Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.<br /> * Staying online on secondlife.com (which many people seem to do) automatically means anyone with access to the computer/browser (family) can log in with the account inworld<br /> * starting SL from the web browser on a regular basis will most likely result in the web browser lingering in memory in the background when running the viewer, which based on the heavy memory requirement may impair viewer performance.<br /> * this would have an impact on the architecture discussions for a future open grid.<br /> <br /> === Alternatives ===<br /> * As regards menu items such as "Account History", send the account name on the URL, and have the web page check if that is the currently logged on account. If not prompt the user to log on with the same account as being used in the viewer (for security reasons the viewer should not automatically log the account on to the web site in such cases).<br /> * Is this really needed or desirable (''for the client'')? SL is not an extension of the web, it's a different kind of interface... one that has the potential of becoming a "3d web".<br /> <br /> == Signatories ==<br /> <br /> Please sign this below with "<nowiki>~~~~</nowiki>" if you agree with the version of this document you are reading. The date will indicate which version of the document you read and agree with. <br /> <br /> * [[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)<br /> * [[User:Argent Stonecutter|Argent Stonecutter]] 13:53, 29 September 2007 (PDT)<br /> * [[User:Dale Glass|Dale Glass]] 14:28, 29 September 2007 (PDT)<br /> * [[User:Tillie Ariantho|Tillie Ariantho]] 03:48, 30 September 2007 (PDT)<br /> * [[User:Jesse Barnett|Jesse Barnett]] 9:53, 30 September 2007 (PDT)<br /> * [[User:Winter Ventura|Winter Ventura]] 19:42, 29 September 2007 (PDT)<br /> * [[User:Balp Allen|Balp Allen]] 01:33, 30 September 2007 (PDT)<br /> * [[User:Michelle2 Zenovka|Michelle2 Zenovka]] 02:52, 30 September 2007 (PDT)<br /> * [[User:Nicholaz Beresford|Nicholaz]] 03:42, 30 September 2007 (PDT)<br /> * [[User:Dzonatas Sol|Dzonatas Sol]] 06:54, 30 September 2007 (PDT)<br /> * [[User:Eloise Pasteur|Eloise Pasteur]] 06:57, 30 September 2007 (PDT)<br /> * [[User:Becky Tardis|Becky Tardis]] 08:34, 30 September 2007 (PDT)<br /> * [[User:Peter Newell|Peter Newell]] 14:14, 30 September 2007 (PDT)<br /> * [[User:Dr Scofield|Dr Scofield]] 00:45, 1 October 2007 (PDT)<br /> * [[User:Jabath Steuart|Jabath Steuart]] 04:03, 1 October 2007 (PDT)<br /> * [[User:Nik Woodget|Nik Woodget]] 05:19, 1 October 2007 (PDT)<br /> * [[User:Whoops Babii|Whoops Babii]] 05:29, 1 October 2007 (PDT)<br /> * [[User:Feep Larsson|Feep Larsson]] 06:29, 1 October 2007 (PDT)<br /> * [[User:Gibson Willis|Gibson Willis]] 07:11, 1 October 2007 (PDT)<br /> * [[User:Grazer Kline|Grazer Kline]] 10:34, 1 October 2007 (PDT)</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Viewer_Authentication_Critique&diff=33891 Viewer Authentication Critique 2007-10-01T10:23:33Z

<p>Matthew Dowd: /* Alternatives */</p> <hr /> <div>This is a formal critique of [[Viewer Authentication]] that was [https://lists.secondlife.com/pipermail/sldev/2007-September/005403.html requested] by [[User:Rob Linden]] on the [[SLDev]] mailing list.<br /> <br /> For a branch of the discussion see [https://wiki.secondlife.com/wiki/Talk:Viewer_Authentication Talk page on the original proposal.]<br /> <br /> == Summary ==<br /> <br /> The new authentication method proposed by LL seems to be an attempt to solve a perceived but non-existent problem. <br /> <br /> There are currently no known password capturing third party viewers in the wild, and a third party viewer requires such a privilege level of access to an account anyway that if you don't trust it with your username and password, you shouldn't be running it anyway. The mechanism proposed, however, is more prone to phishing attacks. Most password compromises are probably due to weaknesses in the current protocol challenge response, due to allowing weak passwords or due to the usual phishing e-mails (which are likely to be increased by the proposed method rather than decreased).<br /> <br /> Providing a single authentication mechanism for LL (and third party) websites would be an improvement to multiple backend copies of username and password, however this could be implemented without touching the viewer authentication method. Support for OpenID and other identity metasystems would increase the flexibility and offer features such as brokered identity verification. However, these would only be part of the solution, and although the proposed mechanism would provide a way for future support of these, there are other ways this could be achieved. Future support for OpenID is perhaps a topic for a seperate discussion and debate, but a open debate on this should happen.<br /> <br /> There seems to be no real demand to synchronise the authentication of the viewer with authentication on the SL web site (account, forums, etc.), and any benefits gained would be negated by the problems this would cause anyone running alts (e.g. for in world permissions testing etc.) or multiple viewers (e.g. main, test and firstlook). It also raises problems for those running OpenSim based Grids, and may also cause difficulties further down the line as regards the new architecture discussions.<br /> <br /> Overall, the additional development time both with LL and for external developers doesn't seem to warrant the promoted benefits.<br /> <br /> It was also noted that consideration should be given when considering enhancements to the security/authentication models whether these should be optional - allowing users to make their own risk/convenience decisions.<br /> <br /> == Security ==<br /> <br /> === LL's Objectives ===<br /> * To mitigate the danger of password capturing Trojans masquerading as third party viewers<br /> * Improve trust in third party viewers by providing a means of assurance to the user that the third party viewer could not be a Trojan capturing usernames and passwords.<br /> <br /> === Pros ===<br /> * Viewer does not have to process (and "see") username and password<br /> <br /> === Cons ===<br /> * The main risk of running a third party viewer (or any other application not provided by Linden Labs) is not stealing passwords, it's direct attacks through the client... and the "official" client is not really any protection against that.<br /> ** Viewer can still be used in direct and indirect attacks even if it never sees the password (for example: salami slicing through cutout accounts, acting as a cutout account or an in-world botnet, faking a failed connection while giving an attacker access).<br /> ** NON-viewer applications (such as editors, 3d tools) designed for use by SL residents could use a keystroke logger and macro to perform any of these attacks, or could inject code into the viewer to do the same thing. Look at 'cheating' programs in combat MMORPGs for ideas.<br /> * But this is still not a large risk, unless people get the client through a mechanism that makes the creator anonymous. Historically, attempts to disseminate boobytrapped versions of applications have only worked in environments where it's routine for people to download applications from anonymous sources (file areas in the BBS era, for example). It's too easy to trace down the originator of any compromised client when you're getting them from their own website.<br /> <br><br /> * Bottom line here is that third party viewers stealing passwords are a very small risk for the user: the bigger risk is from the web browser!<br /> ** Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.<br /> *** This kind of attack is not theoretical, phishing websites are a criminal industry.<br /> *** It would be very easy to set up a temporary (i.e. hard to trace the real owner) phishing webpage which looks like the official SL logon, and send e-mails such as "You've received xxx in SL, Click here to logon" apparently from LL - with far less work than trying to create, and entice people to download a trojan viewer<br /> ** Relies on browser security, and uses a mechanism often disabled or filtered due to security concerns<br /> ** Too reliant on browser/OS implementations (proxies, firewalls, used browsers, etc.)<br /> * So using the browser to perform the authentication moves the authentication to a mechanism that has historically proven more likely to be compromised.<br /> <br><br /> * And the mechanism itself is relatively inflexible.<br /> ** Links to secondlife:// can only point to one instance (version, e.g. homebrew, release candidate official) of the program<br /> ** Links to secondlife:// can not pass parameters to the program<br /> *** In fact allowing that was a security flaw recently found and fixed in the SL client. :(<br /> ** It will raise problems for those running alternative (e.g. OpenSim) grids, and also have impact on the dicussions for a future open grid.<br /> <br><br /> * Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)<br /> ** The issues raised in the next sections would mean that people would have an incentive to use this kind of client.<br /> <br /> === Alternatives ===<br /> * One time passwords (for copy paste into a non-secure viewer or to print and take with you to friends, internet cafes, public terminals, etc.)<br /> * lower perm passwords (pwds which put the account into a restricted state, disallowing "dangerous" transactions)<br /> * separate passwords for website account and being inworld<br /> * Account restrictions <br /> * Allow third party plug-ins in the viewer (these would allow the extra functionality which are sometimes the reason for running third party viewers, but would rely on the official viewer for validation)<br /> * Do nothing, keep everything as it is.<br /> ** Without a strong case for the status quo being a problem, this is certainly a viable alternative, particularly given the impact this will have on developers of third party tools and viewers<br /> ** It is arguable that most losses of assets and value are incurred due to SL bugs (inventory, classifieds search, etc.) and outtages rather than through account compromises<br /> <br><br /> * This may be the wrong problem - password compromises are more likely to be through standard phishing attacks (logon here to update your account info) which is not addressed, or by weaknesses in the current authentication mechnism or just insecure passwords.<br /> ** CRAM-MD5 or a similar challenge-response type <br /> ** Dictionary check to reject insecure passwords<br /> <br /> == Flexibility ==<br /> <br /> === LL's Objectives ===<br /> * Single Sign On - allowing multiple web applications (forums, support, account, jira, wiki etc.) and viewers to use the same username and password through a single point without duplicating usernames and passwords into multiple systems<br /> * Extension of this to allow non-LL applications and web sites to participate in this single sign on system.<br /> <br /> === Pros ===<br /> * Enables username/password authentication to work on third party sites without them having to "see" username and password<br /> <br /> === Cons ===<br /> * This is really an unrelated issue...<br /> ** The client doesn't need to depend on the website for this purpose, or this could be a command line option.<br /> ** The client could just as easily be the 'authentication source' as the website.<br /> *** Via a "go to website" link in the client that passed an equivalent token.<br /> <br><br /> * As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> <br /> === Alternatives ===<br /> * Use this mechanism for websites (including third party) only but not for viewers<br /> <br><br /> * Identity Metasystem - [http://en.wikipedia.org/wiki/Identity_Metasystem]<br /> ** OpenID - [http://openid.net/]<br /> ** CardSpace - [http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx]<br /> ** Shibboleth - [http://shibboleth.internet2.edu/]<br /> ** CAS - [http://www.ja-sig.org/products/cas/]<br /> *** These could be handled by the client poping up a window using the internal web browser to connect to a HTML logon. It may be difficult or impossible to determine if the client really is displaying the official HTML logon and not capturing key strokes so this would be a way of implementing the above for flexibility or other reasons (e.g. brokered identity verification [http://www.agimo.gov.au/publications/2004/05/egovt_challenges/privacy/identity/brokered]) not for security<br /> <br /> == Persistence ==<br /> <br /> === LL's Objectives ===<br /> * To synchronise the various LL's systems (forums, support, jira, account, etc.) so that by logging onto one, you are automatically logged onto the others.<br /> <br /> === Pros ===<br /> * Selecting "Account History" or "Manage My Account" and similar menu items would open the web page for the account logged into SL, rather than the account logged into the web site, which currently can be different<br /> <br /> === Cons ===<br /> * As in the previous section, LL's objectives could be met without the viewer logging in via the same mechanism.<br /> * Inconvenient for those with alts or multiple clients<br /> ** Cumbersome to change alts and logon with multiple alts<br /> ** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL<br /> ** As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> * Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.<br /> * Staying online on secondlife.com (which many people seem to do) automatically means anyone with access to the computer/browser (family) can log in with the account inworld<br /> * starting SL from the web browser on a regular basis will most likely result in the web browser lingering in memory in the background when running the viewer, which based on the heavy memory requirement may impair viewer performance.<br /> * this would have an impact on the architecture discussions for a future open grid.<br /> <br /> === Alternatives ===<br /> * As regards menu items such as "Account History", send the account name on the URL, and have the web page check if that is the currently logged on account. If not prompt the user to log on with the same account as being used in the viewer (for security reasons the viewer should not automatically log the account on to the web site in such cases).<br /> * Is this really needed or desirable (''for the client'')? SL is not an extension of the web, it's a different kind of interface... one that has the potential of becoming a "3d web".<br /> <br /> == Signatories ==<br /> <br /> Please sign this below with "<nowiki>~~~~</nowiki>" if you agree with the version of this document you are reading. The date will indicate which version of the document you read and agree with. <br /> <br /> * [[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)<br /> * [[User:Argent Stonecutter|Argent Stonecutter]] 13:53, 29 September 2007 (PDT)<br /> * [[User:Dale Glass|Dale Glass]] 14:28, 29 September 2007 (PDT)<br /> * [[User:Tillie Ariantho|Tillie Ariantho]] 03:48, 30 September 2007 (PDT)<br /> * [[User:Jesse Barnett|Jesse Barnett]] 9:53, 30 September 2007 (PDT)<br /> * [[User:Winter Ventura|Winter Ventura]] 19:42, 29 September 2007 (PDT)<br /> * [[User:Balp Allen|Balp Allen]] 01:33, 30 September 2007 (PDT)<br /> * [[User:Michelle2 Zenovka|Michelle2 Zenovka]] 02:52, 30 September 2007 (PDT)<br /> * [[User:Nicholaz Beresford|Nicholaz]] 03:42, 30 September 2007 (PDT)<br /> * [[User:Dzonatas Sol|Dzonatas Sol]] 06:54, 30 September 2007 (PDT)<br /> * [[User:Eloise Pasteur|Eloise Pasteur]] 06:57, 30 September 2007 (PDT)<br /> * [[User:Becky Tardis|Becky Tardis]] 08:34, 30 September 2007 (PDT)<br /> * [[User:Peter Newell|Peter Newell]] 14:14, 30 September 2007 (PDT)<br /> * [[User:Dr Scofield|Dr Scofield]] 00:45, 1 October 2007 (PDT)</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Viewer_Authentication_Critique&diff=33890 Viewer Authentication Critique 2007-10-01T10:22:41Z

<p>Matthew Dowd: /* Summary */</p> <hr /> <div>This is a formal critique of [[Viewer Authentication]] that was [https://lists.secondlife.com/pipermail/sldev/2007-September/005403.html requested] by [[User:Rob Linden]] on the [[SLDev]] mailing list.<br /> <br /> For a branch of the discussion see [https://wiki.secondlife.com/wiki/Talk:Viewer_Authentication Talk page on the original proposal.]<br /> <br /> == Summary ==<br /> <br /> The new authentication method proposed by LL seems to be an attempt to solve a perceived but non-existent problem. <br /> <br /> There are currently no known password capturing third party viewers in the wild, and a third party viewer requires such a privilege level of access to an account anyway that if you don't trust it with your username and password, you shouldn't be running it anyway. The mechanism proposed, however, is more prone to phishing attacks. Most password compromises are probably due to weaknesses in the current protocol challenge response, due to allowing weak passwords or due to the usual phishing e-mails (which are likely to be increased by the proposed method rather than decreased).<br /> <br /> Providing a single authentication mechanism for LL (and third party) websites would be an improvement to multiple backend copies of username and password, however this could be implemented without touching the viewer authentication method. Support for OpenID and other identity metasystems would increase the flexibility and offer features such as brokered identity verification. However, these would only be part of the solution, and although the proposed mechanism would provide a way for future support of these, there are other ways this could be achieved. Future support for OpenID is perhaps a topic for a seperate discussion and debate, but a open debate on this should happen.<br /> <br /> There seems to be no real demand to synchronise the authentication of the viewer with authentication on the SL web site (account, forums, etc.), and any benefits gained would be negated by the problems this would cause anyone running alts (e.g. for in world permissions testing etc.) or multiple viewers (e.g. main, test and firstlook). It also raises problems for those running OpenSim based Grids, and may also cause difficulties further down the line as regards the new architecture discussions.<br /> <br /> Overall, the additional development time both with LL and for external developers doesn't seem to warrant the promoted benefits.<br /> <br /> It was also noted that consideration should be given when considering enhancements to the security/authentication models whether these should be optional - allowing users to make their own risk/convenience decisions.<br /> <br /> == Security ==<br /> <br /> === LL's Objectives ===<br /> * To mitigate the danger of password capturing Trojans masquerading as third party viewers<br /> * Improve trust in third party viewers by providing a means of assurance to the user that the third party viewer could not be a Trojan capturing usernames and passwords.<br /> <br /> === Pros ===<br /> * Viewer does not have to process (and "see") username and password<br /> <br /> === Cons ===<br /> * The main risk of running a third party viewer (or any other application not provided by Linden Labs) is not stealing passwords, it's direct attacks through the client... and the "official" client is not really any protection against that.<br /> ** Viewer can still be used in direct and indirect attacks even if it never sees the password (for example: salami slicing through cutout accounts, acting as a cutout account or an in-world botnet, faking a failed connection while giving an attacker access).<br /> ** NON-viewer applications (such as editors, 3d tools) designed for use by SL residents could use a keystroke logger and macro to perform any of these attacks, or could inject code into the viewer to do the same thing. Look at 'cheating' programs in combat MMORPGs for ideas.<br /> * But this is still not a large risk, unless people get the client through a mechanism that makes the creator anonymous. Historically, attempts to disseminate boobytrapped versions of applications have only worked in environments where it's routine for people to download applications from anonymous sources (file areas in the BBS era, for example). It's too easy to trace down the originator of any compromised client when you're getting them from their own website.<br /> <br><br /> * Bottom line here is that third party viewers stealing passwords are a very small risk for the user: the bigger risk is from the web browser!<br /> ** Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.<br /> *** This kind of attack is not theoretical, phishing websites are a criminal industry.<br /> *** It would be very easy to set up a temporary (i.e. hard to trace the real owner) phishing webpage which looks like the official SL logon, and send e-mails such as "You've received xxx in SL, Click here to logon" apparently from LL - with far less work than trying to create, and entice people to download a trojan viewer<br /> ** Relies on browser security, and uses a mechanism often disabled or filtered due to security concerns<br /> ** Too reliant on browser/OS implementations (proxies, firewalls, used browsers, etc.)<br /> * So using the browser to perform the authentication moves the authentication to a mechanism that has historically proven more likely to be compromised.<br /> <br><br /> * And the mechanism itself is relatively inflexible.<br /> ** Links to secondlife:// can only point to one instance (version, e.g. homebrew, release candidate official) of the program<br /> ** Links to secondlife:// can not pass parameters to the program<br /> *** In fact allowing that was a security flaw recently found and fixed in the SL client. :(<br /> ** It will raise problems for those running alternative (e.g. OpenSim) grids, and also have impact on the dicussions for a future open grid.<br /> <br><br /> * Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)<br /> ** The issues raised in the next sections would mean that people would have an incentive to use this kind of client.<br /> <br /> === Alternatives ===<br /> * One time passwords (for copy paste into a non-secure viewer or to print and take with you to friends, internet cafes, public terminals, etc.)<br /> * lower perm passwords (pwds which put the account into a restricted state, disallowing "dangerous" transactions)<br /> * separate passwords for website account and being inworld<br /> * Account restrictions <br /> * Allow third party plug-ins in the viewer (these would allow the extra functionality which are sometimes the reason for running third party viewers, but would rely on the official viewer for validation)<br /> * Do nothing, keep everything as it is.<br /> ** Without a strong case for the status quo being a problem, this is certainly a viable alternative, particularly given the impact this will have on developers of third party tools and viewers<br /> ** It is arguable that most losses of L$ and inventory are incurred due to SL bugs than through account compromises<br /> <br><br /> * This may be the wrong problem - password compromises are more likely to be through standard phishing attacks (logon here to update your account info) which is not addressed, or by weaknesses in the current authentication mechnism or just insecure passwords.<br /> ** CRAM-MD5 or a similar challenge-response type <br /> ** Dictionary check to reject insecure passwords<br /> <br /> == Flexibility ==<br /> <br /> === LL's Objectives ===<br /> * Single Sign On - allowing multiple web applications (forums, support, account, jira, wiki etc.) and viewers to use the same username and password through a single point without duplicating usernames and passwords into multiple systems<br /> * Extension of this to allow non-LL applications and web sites to participate in this single sign on system.<br /> <br /> === Pros ===<br /> * Enables username/password authentication to work on third party sites without them having to "see" username and password<br /> <br /> === Cons ===<br /> * This is really an unrelated issue...<br /> ** The client doesn't need to depend on the website for this purpose, or this could be a command line option.<br /> ** The client could just as easily be the 'authentication source' as the website.<br /> *** Via a "go to website" link in the client that passed an equivalent token.<br /> <br><br /> * As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> <br /> === Alternatives ===<br /> * Use this mechanism for websites (including third party) only but not for viewers<br /> <br><br /> * Identity Metasystem - [http://en.wikipedia.org/wiki/Identity_Metasystem]<br /> ** OpenID - [http://openid.net/]<br /> ** CardSpace - [http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx]<br /> ** Shibboleth - [http://shibboleth.internet2.edu/]<br /> ** CAS - [http://www.ja-sig.org/products/cas/]<br /> *** These could be handled by the client poping up a window using the internal web browser to connect to a HTML logon. It may be difficult or impossible to determine if the client really is displaying the official HTML logon and not capturing key strokes so this would be a way of implementing the above for flexibility or other reasons (e.g. brokered identity verification [http://www.agimo.gov.au/publications/2004/05/egovt_challenges/privacy/identity/brokered]) not for security<br /> <br /> == Persistence ==<br /> <br /> === LL's Objectives ===<br /> * To synchronise the various LL's systems (forums, support, jira, account, etc.) so that by logging onto one, you are automatically logged onto the others.<br /> <br /> === Pros ===<br /> * Selecting "Account History" or "Manage My Account" and similar menu items would open the web page for the account logged into SL, rather than the account logged into the web site, which currently can be different<br /> <br /> === Cons ===<br /> * As in the previous section, LL's objectives could be met without the viewer logging in via the same mechanism.<br /> * Inconvenient for those with alts or multiple clients<br /> ** Cumbersome to change alts and logon with multiple alts<br /> ** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL<br /> ** As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> * Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.<br /> * Staying online on secondlife.com (which many people seem to do) automatically means anyone with access to the computer/browser (family) can log in with the account inworld<br /> * starting SL from the web browser on a regular basis will most likely result in the web browser lingering in memory in the background when running the viewer, which based on the heavy memory requirement may impair viewer performance.<br /> * this would have an impact on the architecture discussions for a future open grid.<br /> <br /> === Alternatives ===<br /> * As regards menu items such as "Account History", send the account name on the URL, and have the web page check if that is the currently logged on account. If not prompt the user to log on with the same account as being used in the viewer (for security reasons the viewer should not automatically log the account on to the web site in such cases).<br /> * Is this really needed or desirable (''for the client'')? SL is not an extension of the web, it's a different kind of interface... one that has the potential of becoming a "3d web".<br /> <br /> == Signatories ==<br /> <br /> Please sign this below with "<nowiki>~~~~</nowiki>" if you agree with the version of this document you are reading. The date will indicate which version of the document you read and agree with. <br /> <br /> * [[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)<br /> * [[User:Argent Stonecutter|Argent Stonecutter]] 13:53, 29 September 2007 (PDT)<br /> * [[User:Dale Glass|Dale Glass]] 14:28, 29 September 2007 (PDT)<br /> * [[User:Tillie Ariantho|Tillie Ariantho]] 03:48, 30 September 2007 (PDT)<br /> * [[User:Jesse Barnett|Jesse Barnett]] 9:53, 30 September 2007 (PDT)<br /> * [[User:Winter Ventura|Winter Ventura]] 19:42, 29 September 2007 (PDT)<br /> * [[User:Balp Allen|Balp Allen]] 01:33, 30 September 2007 (PDT)<br /> * [[User:Michelle2 Zenovka|Michelle2 Zenovka]] 02:52, 30 September 2007 (PDT)<br /> * [[User:Nicholaz Beresford|Nicholaz]] 03:42, 30 September 2007 (PDT)<br /> * [[User:Dzonatas Sol|Dzonatas Sol]] 06:54, 30 September 2007 (PDT)<br /> * [[User:Eloise Pasteur|Eloise Pasteur]] 06:57, 30 September 2007 (PDT)<br /> * [[User:Becky Tardis|Becky Tardis]] 08:34, 30 September 2007 (PDT)<br /> * [[User:Peter Newell|Peter Newell]] 14:14, 30 September 2007 (PDT)<br /> * [[User:Dr Scofield|Dr Scofield]] 00:45, 1 October 2007 (PDT)</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Talk:Viewer_Authentication_Critique&diff=33889 Talk:Viewer Authentication Critique 2007-10-01T10:19:03Z

<p>Matthew Dowd: </p> <hr /> <div>{{Talk}}<br /> <br /> == Process for editing the critique ==<br /> <br /> By virtue of jumping first, I think [[User:Matthew Dowd|Matthew Dowd]] should be the working group chair for editing this document. What I think that means is this:<br /> * Anyone can still make no-brainer edits to the article<br /> * Matthew will be arbiter for dispute resolution, should that be necessary.<br /> * If there are points that Matthew is unclear about, he should delete them from the document, and move them to the talk page.<br /> * If there are points that others are unclear about, they should bring them up on the talk page, and then later delete them from the main page if a question/concern goes unanswered on the talk page (with "see talk page" in the comment of the edit).<br /> * If, for whatever reason, it becomes necessary to fork this document, it's best to move all critiques into the user space of the working group chair. So, for example, Matthew's version would move to [[User:Matthew Dowd/Viewer Authentication Critique]], and other critiques could also be done the same way. This page would become a list of critiques.<br /> <br /> Sound like a reasonable process? I think this is lightweight enough that a pretty good document can evolve pretty quickly. -- [[User:Rob Linden|Rob Linden]] 12:56, 29 September 2007 (PDT)<br /> <br /> == Third party viewers/code ==<br /> <br /> What's the substantive difference between these two points?<br /> # Viewer still involves running trusted code on the computer and could initiate other attacks e.g.<br /> # Most of these attacks could be performed by any third-party software designed for use with SL <br /> Both have many subpoints. Could they be consolidated into a single point? -- [[User:Rob Linden|Rob Linden]] 20:10, 29 September 2007 (PDT)<br /> <br /> The first point is that keeping the client from seeing the password doesn't remove the danger of a modified client.<br /> <br /> The second point is that *any* ancillary software (such as animation editors, sculpt editors, sculpt texture plugins) could be used in an attack, even if they don't actually connect to SL, since they would be used by SL residents.<br /> <br /> -- [[User:Argent Stonecutter|Argent Stonecutter]] 21:00, 29 September 2007 (PDT)<br /> <br /> Is this better, Rob? -- [[User:Argent Stonecutter|Argent Stonecutter]] 21:11, 29 September 2007 (PDT)<br /> <br /> :Yes, that is. Thanks for the clarification! -- [[User:Rob Linden|Rob Linden]] 21:44, 29 September 2007 (PDT)<br /> <br /> <br /> == No balance ==<br /> <br /> This article is pretty awful, its just an attack. For real critique you have to explore the alternatives and discuss the pros and cons for each.<br /> Even if this form of log in has these disadvantages it could still be an improvement over what we currently have.<br /> We need a common point of reference to discuss if this is an improvement and what alternatives exist. [[User:Ahab Schmo|Ahab Schmo]] 12:31, 30 September 2007 (PDT)<br /> <br /> == Nicholaz's Summary to SLDev ==<br /> <br /> I think (and would be surprised otherwise) there currently consensus<br /> among those who replied here on the list that ...<br /> <br /> 1) the new auth mechanism does nothing to significantly increase security<br /> in terms of protecting user assets from malicious viewers (once the<br /> viewer is logged in, you're at the mercy of the viewer, no matter how> you logged in)<br /> <br /> 2) the new auth mechanism makes login to SL cumbersome and breaks many<br /> ways in which people are currently using SL (alts, switching between<br /> viewers, etc.)<br /> <br /> 3) the new auth mechanism will make it impossible for some environment<br /> to log in from at all (proxies, firewalls, security software, ...)<br /> or prevent specific forms of viewers (lean viewers, mobile systems,<br /> viewer on a memory stick, ...)<br /> <br /> 4) the new auth mechanism will break existing applications (bots, libsl,<br /> etc.) and these will have to work around these.<br /> <br /> 5) Allowing these (4) to work around it, means that 3rd party viewers can<br /> also work around it, meaning that you'll end up with 3rd party viewers<br /> which are a lot more convenient than the official viewer, essentially> driving people away from the official viewer.<br /> <br /> 6) other mechanisms exist, which a) actually increase security and which<br /> b) do not break existing use and c) are less cumbersome<br /> <br /> 7) (this is my personal addition but I'd be amazed if anyone disagreed)<br /> people are losing a lot more assets and value through Linden<br /> malfunctions (lost inventory, search & classifieds being not seen<br /> because of outages, etc.) than have ever been lost through spoofing<br /> or malicious viewers.<br /> <br /> 8) __whatever mechanism is implemented, should be a *choice* with the__<br /> __existing mechanisms remaining in place__<br /> <br /> 9) (see (8) )<br /> <br /> 10) (see (9) )<br /> <br /> Bottom line is that the new auth mechanism is something that offers> neglectible<br /> improvement in security and will cause countless problems or developer<br /> hours on both sides.</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Viewer_Authentication_Critique&diff=33887 Viewer Authentication Critique 2007-10-01T10:13:41Z

<p>Matthew Dowd: /* Alternatives */</p> <hr /> <div>This is a formal critique of [[Viewer Authentication]] that was [https://lists.secondlife.com/pipermail/sldev/2007-September/005403.html requested] by [[User:Rob Linden]] on the [[SLDev]] mailing list.<br /> <br /> For a branch of the discussion see [https://wiki.secondlife.com/wiki/Talk:Viewer_Authentication Talk page on the original proposal.]<br /> <br /> == Summary ==<br /> <br /> The new authentication method proposed by LL seems to be an attempt to solve a perceived but non-existent problem. <br /> <br /> There are currently no known password capturing third party viewers in the wild, and a third party viewer requires such a privilege level of access to an account anyway that if you don't trust it with your username and password, you shouldn't be running it anyway. The mechanism proposed, however, is more prone to phishing attacks. Most password compromises are probably due to weaknesses in the current protocol challenge response, due to allowing weak passwords or due to the usual phishing e-mails (which are likely to be increased by the proposed method rather than decreased).<br /> <br /> Providing a single authentication mechanism for LL (and third party) websites would be an improvement to multiple backend copies of username and password, however this could be implemented without touching the viewer authentication method. Support for OpenID and other identity metasystems would increase the flexibility and offer features such as brokered identity verification. However, these would only be part of the solution, and although the proposed mechanism would provide a way for future support of these, there are other ways this could be achieved. Future support for OpenID is perhaps a topic for a seperate discussion and debate, but a open debate on this should happen.<br /> <br /> There seems to be no real demand to synchronise the authentication of the viewer with authentication on the SL web site (account, forums, etc.), and any benefits gained would be negated by the problems this would cause anyone running alts (e.g. for in world permissions testing etc.) or multiple viewers (e.g. main, test and firstlook). It also raises problems for those running OpenSim based Grids, and may also cause difficulties further down the line as regards the new architecture discussions.<br /> <br /> It was also noted that consideration should be given when considering enhancements to the security/authentication models whether these should be optional - allowing users to make their own risk/convenience decisions.<br /> <br /> == Security ==<br /> <br /> === LL's Objectives ===<br /> * To mitigate the danger of password capturing Trojans masquerading as third party viewers<br /> * Improve trust in third party viewers by providing a means of assurance to the user that the third party viewer could not be a Trojan capturing usernames and passwords.<br /> <br /> === Pros ===<br /> * Viewer does not have to process (and "see") username and password<br /> <br /> === Cons ===<br /> * The main risk of running a third party viewer (or any other application not provided by Linden Labs) is not stealing passwords, it's direct attacks through the client... and the "official" client is not really any protection against that.<br /> ** Viewer can still be used in direct and indirect attacks even if it never sees the password (for example: salami slicing through cutout accounts, acting as a cutout account or an in-world botnet, faking a failed connection while giving an attacker access).<br /> ** NON-viewer applications (such as editors, 3d tools) designed for use by SL residents could use a keystroke logger and macro to perform any of these attacks, or could inject code into the viewer to do the same thing. Look at 'cheating' programs in combat MMORPGs for ideas.<br /> * But this is still not a large risk, unless people get the client through a mechanism that makes the creator anonymous. Historically, attempts to disseminate boobytrapped versions of applications have only worked in environments where it's routine for people to download applications from anonymous sources (file areas in the BBS era, for example). It's too easy to trace down the originator of any compromised client when you're getting them from their own website.<br /> <br><br /> * Bottom line here is that third party viewers stealing passwords are a very small risk for the user: the bigger risk is from the web browser!<br /> ** Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.<br /> *** This kind of attack is not theoretical, phishing websites are a criminal industry.<br /> *** It would be very easy to set up a temporary (i.e. hard to trace the real owner) phishing webpage which looks like the official SL logon, and send e-mails such as "You've received xxx in SL, Click here to logon" apparently from LL - with far less work than trying to create, and entice people to download a trojan viewer<br /> ** Relies on browser security, and uses a mechanism often disabled or filtered due to security concerns<br /> ** Too reliant on browser/OS implementations (proxies, firewalls, used browsers, etc.)<br /> * So using the browser to perform the authentication moves the authentication to a mechanism that has historically proven more likely to be compromised.<br /> <br><br /> * And the mechanism itself is relatively inflexible.<br /> ** Links to secondlife:// can only point to one instance (version, e.g. homebrew, release candidate official) of the program<br /> ** Links to secondlife:// can not pass parameters to the program<br /> *** In fact allowing that was a security flaw recently found and fixed in the SL client. :(<br /> ** It will raise problems for those running alternative (e.g. OpenSim) grids, and also have impact on the dicussions for a future open grid.<br /> <br><br /> * Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)<br /> ** The issues raised in the next sections would mean that people would have an incentive to use this kind of client.<br /> <br /> === Alternatives ===<br /> * One time passwords (for copy paste into a non-secure viewer or to print and take with you to friends, internet cafes, public terminals, etc.)<br /> * lower perm passwords (pwds which put the account into a restricted state, disallowing "dangerous" transactions)<br /> * separate passwords for website account and being inworld<br /> * Account restrictions <br /> * Allow third party plug-ins in the viewer (these would allow the extra functionality which are sometimes the reason for running third party viewers, but would rely on the official viewer for validation)<br /> * Do nothing, keep everything as it is.<br /> ** Without a strong case for the status quo being a problem, this is certainly a viable alternative, particularly given the impact this will have on developers of third party tools and viewers<br /> ** It is arguable that most losses of L$ and inventory are incurred due to SL bugs than through account compromises<br /> <br><br /> * This may be the wrong problem - password compromises are more likely to be through standard phishing attacks (logon here to update your account info) which is not addressed, or by weaknesses in the current authentication mechnism or just insecure passwords.<br /> ** CRAM-MD5 or a similar challenge-response type <br /> ** Dictionary check to reject insecure passwords<br /> <br /> == Flexibility ==<br /> <br /> === LL's Objectives ===<br /> * Single Sign On - allowing multiple web applications (forums, support, account, jira, wiki etc.) and viewers to use the same username and password through a single point without duplicating usernames and passwords into multiple systems<br /> * Extension of this to allow non-LL applications and web sites to participate in this single sign on system.<br /> <br /> === Pros ===<br /> * Enables username/password authentication to work on third party sites without them having to "see" username and password<br /> <br /> === Cons ===<br /> * This is really an unrelated issue...<br /> ** The client doesn't need to depend on the website for this purpose, or this could be a command line option.<br /> ** The client could just as easily be the 'authentication source' as the website.<br /> *** Via a "go to website" link in the client that passed an equivalent token.<br /> <br><br /> * As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> <br /> === Alternatives ===<br /> * Use this mechanism for websites (including third party) only but not for viewers<br /> <br><br /> * Identity Metasystem - [http://en.wikipedia.org/wiki/Identity_Metasystem]<br /> ** OpenID - [http://openid.net/]<br /> ** CardSpace - [http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx]<br /> ** Shibboleth - [http://shibboleth.internet2.edu/]<br /> ** CAS - [http://www.ja-sig.org/products/cas/]<br /> *** These could be handled by the client poping up a window using the internal web browser to connect to a HTML logon. It may be difficult or impossible to determine if the client really is displaying the official HTML logon and not capturing key strokes so this would be a way of implementing the above for flexibility or other reasons (e.g. brokered identity verification [http://www.agimo.gov.au/publications/2004/05/egovt_challenges/privacy/identity/brokered]) not for security<br /> <br /> == Persistence ==<br /> <br /> === LL's Objectives ===<br /> * To synchronise the various LL's systems (forums, support, jira, account, etc.) so that by logging onto one, you are automatically logged onto the others.<br /> <br /> === Pros ===<br /> * Selecting "Account History" or "Manage My Account" and similar menu items would open the web page for the account logged into SL, rather than the account logged into the web site, which currently can be different<br /> <br /> === Cons ===<br /> * As in the previous section, LL's objectives could be met without the viewer logging in via the same mechanism.<br /> * Inconvenient for those with alts or multiple clients<br /> ** Cumbersome to change alts and logon with multiple alts<br /> ** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL<br /> ** As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> * Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.<br /> * Staying online on secondlife.com (which many people seem to do) automatically means anyone with access to the computer/browser (family) can log in with the account inworld<br /> * starting SL from the web browser on a regular basis will most likely result in the web browser lingering in memory in the background when running the viewer, which based on the heavy memory requirement may impair viewer performance.<br /> * this would have an impact on the architecture discussions for a future open grid.<br /> <br /> === Alternatives ===<br /> * As regards menu items such as "Account History", send the account name on the URL, and have the web page check if that is the currently logged on account. If not prompt the user to log on with the same account as being used in the viewer (for security reasons the viewer should not automatically log the account on to the web site in such cases).<br /> * Is this really needed or desirable (''for the client'')? SL is not an extension of the web, it's a different kind of interface... one that has the potential of becoming a "3d web".<br /> <br /> == Signatories ==<br /> <br /> Please sign this below with "<nowiki>~~~~</nowiki>" if you agree with the version of this document you are reading. The date will indicate which version of the document you read and agree with. <br /> <br /> * [[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)<br /> * [[User:Argent Stonecutter|Argent Stonecutter]] 13:53, 29 September 2007 (PDT)<br /> * [[User:Dale Glass|Dale Glass]] 14:28, 29 September 2007 (PDT)<br /> * [[User:Tillie Ariantho|Tillie Ariantho]] 03:48, 30 September 2007 (PDT)<br /> * [[User:Jesse Barnett|Jesse Barnett]] 9:53, 30 September 2007 (PDT)<br /> * [[User:Winter Ventura|Winter Ventura]] 19:42, 29 September 2007 (PDT)<br /> * [[User:Balp Allen|Balp Allen]] 01:33, 30 September 2007 (PDT)<br /> * [[User:Michelle2 Zenovka|Michelle2 Zenovka]] 02:52, 30 September 2007 (PDT)<br /> * [[User:Nicholaz Beresford|Nicholaz]] 03:42, 30 September 2007 (PDT)<br /> * [[User:Dzonatas Sol|Dzonatas Sol]] 06:54, 30 September 2007 (PDT)<br /> * [[User:Eloise Pasteur|Eloise Pasteur]] 06:57, 30 September 2007 (PDT)<br /> * [[User:Becky Tardis|Becky Tardis]] 08:34, 30 September 2007 (PDT)<br /> * [[User:Peter Newell|Peter Newell]] 14:14, 30 September 2007 (PDT)<br /> * [[User:Dr Scofield|Dr Scofield]] 00:45, 1 October 2007 (PDT)</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Viewer_Authentication_Critique&diff=33886 Viewer Authentication Critique 2007-10-01T10:12:29Z

<p>Matthew Dowd: /* Summary */</p> <hr /> <div>This is a formal critique of [[Viewer Authentication]] that was [https://lists.secondlife.com/pipermail/sldev/2007-September/005403.html requested] by [[User:Rob Linden]] on the [[SLDev]] mailing list.<br /> <br /> For a branch of the discussion see [https://wiki.secondlife.com/wiki/Talk:Viewer_Authentication Talk page on the original proposal.]<br /> <br /> == Summary ==<br /> <br /> The new authentication method proposed by LL seems to be an attempt to solve a perceived but non-existent problem. <br /> <br /> There are currently no known password capturing third party viewers in the wild, and a third party viewer requires such a privilege level of access to an account anyway that if you don't trust it with your username and password, you shouldn't be running it anyway. The mechanism proposed, however, is more prone to phishing attacks. Most password compromises are probably due to weaknesses in the current protocol challenge response, due to allowing weak passwords or due to the usual phishing e-mails (which are likely to be increased by the proposed method rather than decreased).<br /> <br /> Providing a single authentication mechanism for LL (and third party) websites would be an improvement to multiple backend copies of username and password, however this could be implemented without touching the viewer authentication method. Support for OpenID and other identity metasystems would increase the flexibility and offer features such as brokered identity verification. However, these would only be part of the solution, and although the proposed mechanism would provide a way for future support of these, there are other ways this could be achieved. Future support for OpenID is perhaps a topic for a seperate discussion and debate, but a open debate on this should happen.<br /> <br /> There seems to be no real demand to synchronise the authentication of the viewer with authentication on the SL web site (account, forums, etc.), and any benefits gained would be negated by the problems this would cause anyone running alts (e.g. for in world permissions testing etc.) or multiple viewers (e.g. main, test and firstlook). It also raises problems for those running OpenSim based Grids, and may also cause difficulties further down the line as regards the new architecture discussions.<br /> <br /> It was also noted that consideration should be given when considering enhancements to the security/authentication models whether these should be optional - allowing users to make their own risk/convenience decisions.<br /> <br /> == Security ==<br /> <br /> === LL's Objectives ===<br /> * To mitigate the danger of password capturing Trojans masquerading as third party viewers<br /> * Improve trust in third party viewers by providing a means of assurance to the user that the third party viewer could not be a Trojan capturing usernames and passwords.<br /> <br /> === Pros ===<br /> * Viewer does not have to process (and "see") username and password<br /> <br /> === Cons ===<br /> * The main risk of running a third party viewer (or any other application not provided by Linden Labs) is not stealing passwords, it's direct attacks through the client... and the "official" client is not really any protection against that.<br /> ** Viewer can still be used in direct and indirect attacks even if it never sees the password (for example: salami slicing through cutout accounts, acting as a cutout account or an in-world botnet, faking a failed connection while giving an attacker access).<br /> ** NON-viewer applications (such as editors, 3d tools) designed for use by SL residents could use a keystroke logger and macro to perform any of these attacks, or could inject code into the viewer to do the same thing. Look at 'cheating' programs in combat MMORPGs for ideas.<br /> * But this is still not a large risk, unless people get the client through a mechanism that makes the creator anonymous. Historically, attempts to disseminate boobytrapped versions of applications have only worked in environments where it's routine for people to download applications from anonymous sources (file areas in the BBS era, for example). It's too easy to trace down the originator of any compromised client when you're getting them from their own website.<br /> <br><br /> * Bottom line here is that third party viewers stealing passwords are a very small risk for the user: the bigger risk is from the web browser!<br /> ** Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.<br /> *** This kind of attack is not theoretical, phishing websites are a criminal industry.<br /> *** It would be very easy to set up a temporary (i.e. hard to trace the real owner) phishing webpage which looks like the official SL logon, and send e-mails such as "You've received xxx in SL, Click here to logon" apparently from LL - with far less work than trying to create, and entice people to download a trojan viewer<br /> ** Relies on browser security, and uses a mechanism often disabled or filtered due to security concerns<br /> ** Too reliant on browser/OS implementations (proxies, firewalls, used browsers, etc.)<br /> * So using the browser to perform the authentication moves the authentication to a mechanism that has historically proven more likely to be compromised.<br /> <br><br /> * And the mechanism itself is relatively inflexible.<br /> ** Links to secondlife:// can only point to one instance (version, e.g. homebrew, release candidate official) of the program<br /> ** Links to secondlife:// can not pass parameters to the program<br /> *** In fact allowing that was a security flaw recently found and fixed in the SL client. :(<br /> ** It will raise problems for those running alternative (e.g. OpenSim) grids, and also have impact on the dicussions for a future open grid.<br /> <br><br /> * Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)<br /> ** The issues raised in the next sections would mean that people would have an incentive to use this kind of client.<br /> <br /> === Alternatives ===<br /> * One time passwords (for copy paste into a non-secure viewer or to print and take with you to friends, internet cafes, public terminals, etc.)<br /> * lower perm passwords (pwds which put the account into a restricted state, disallowing "dangerous" transactions)<br /> * separate passwords for website account and being inworld<br /> * Account restrictions <br /> * Allow third party plug-ins in the viewer (these would allow the extra functionality which are sometimes the reason for running third party viewers, but would rely on the official viewer for validation)<br /> * Do nothing, keep everything as it is.<br /> ** Without a strong case for the status quo being a problem, this is certainly a viable alternative.<br /> <br><br /> * This may be the wrong problem - password compromises are more likely to be through standard phishing attacks (logon here to update your account info) which is not addressed, or by weaknesses in the current authentication mechnism or just insecure passwords.<br /> ** CRAM-MD5 or a similar challenge-response type <br /> ** Dictionary check to reject insecure passwords<br /> <br /> == Flexibility ==<br /> <br /> === LL's Objectives ===<br /> * Single Sign On - allowing multiple web applications (forums, support, account, jira, wiki etc.) and viewers to use the same username and password through a single point without duplicating usernames and passwords into multiple systems<br /> * Extension of this to allow non-LL applications and web sites to participate in this single sign on system.<br /> <br /> === Pros ===<br /> * Enables username/password authentication to work on third party sites without them having to "see" username and password<br /> <br /> === Cons ===<br /> * This is really an unrelated issue...<br /> ** The client doesn't need to depend on the website for this purpose, or this could be a command line option.<br /> ** The client could just as easily be the 'authentication source' as the website.<br /> *** Via a "go to website" link in the client that passed an equivalent token.<br /> <br><br /> * As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> <br /> === Alternatives ===<br /> * Use this mechanism for websites (including third party) only but not for viewers<br /> <br><br /> * Identity Metasystem - [http://en.wikipedia.org/wiki/Identity_Metasystem]<br /> ** OpenID - [http://openid.net/]<br /> ** CardSpace - [http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx]<br /> ** Shibboleth - [http://shibboleth.internet2.edu/]<br /> ** CAS - [http://www.ja-sig.org/products/cas/]<br /> *** These could be handled by the client poping up a window using the internal web browser to connect to a HTML logon. It may be difficult or impossible to determine if the client really is displaying the official HTML logon and not capturing key strokes so this would be a way of implementing the above for flexibility or other reasons (e.g. brokered identity verification [http://www.agimo.gov.au/publications/2004/05/egovt_challenges/privacy/identity/brokered]) not for security<br /> <br /> == Persistence ==<br /> <br /> === LL's Objectives ===<br /> * To synchronise the various LL's systems (forums, support, jira, account, etc.) so that by logging onto one, you are automatically logged onto the others.<br /> <br /> === Pros ===<br /> * Selecting "Account History" or "Manage My Account" and similar menu items would open the web page for the account logged into SL, rather than the account logged into the web site, which currently can be different<br /> <br /> === Cons ===<br /> * As in the previous section, LL's objectives could be met without the viewer logging in via the same mechanism.<br /> * Inconvenient for those with alts or multiple clients<br /> ** Cumbersome to change alts and logon with multiple alts<br /> ** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL<br /> ** As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> * Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.<br /> * Staying online on secondlife.com (which many people seem to do) automatically means anyone with access to the computer/browser (family) can log in with the account inworld<br /> * starting SL from the web browser on a regular basis will most likely result in the web browser lingering in memory in the background when running the viewer, which based on the heavy memory requirement may impair viewer performance.<br /> * this would have an impact on the architecture discussions for a future open grid.<br /> <br /> === Alternatives ===<br /> * As regards menu items such as "Account History", send the account name on the URL, and have the web page check if that is the currently logged on account. If not prompt the user to log on with the same account as being used in the viewer (for security reasons the viewer should not automatically log the account on to the web site in such cases).<br /> * Is this really needed or desirable (''for the client'')? SL is not an extension of the web, it's a different kind of interface... one that has the potential of becoming a "3d web".<br /> <br /> == Signatories ==<br /> <br /> Please sign this below with "<nowiki>~~~~</nowiki>" if you agree with the version of this document you are reading. The date will indicate which version of the document you read and agree with. <br /> <br /> * [[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)<br /> * [[User:Argent Stonecutter|Argent Stonecutter]] 13:53, 29 September 2007 (PDT)<br /> * [[User:Dale Glass|Dale Glass]] 14:28, 29 September 2007 (PDT)<br /> * [[User:Tillie Ariantho|Tillie Ariantho]] 03:48, 30 September 2007 (PDT)<br /> * [[User:Jesse Barnett|Jesse Barnett]] 9:53, 30 September 2007 (PDT)<br /> * [[User:Winter Ventura|Winter Ventura]] 19:42, 29 September 2007 (PDT)<br /> * [[User:Balp Allen|Balp Allen]] 01:33, 30 September 2007 (PDT)<br /> * [[User:Michelle2 Zenovka|Michelle2 Zenovka]] 02:52, 30 September 2007 (PDT)<br /> * [[User:Nicholaz Beresford|Nicholaz]] 03:42, 30 September 2007 (PDT)<br /> * [[User:Dzonatas Sol|Dzonatas Sol]] 06:54, 30 September 2007 (PDT)<br /> * [[User:Eloise Pasteur|Eloise Pasteur]] 06:57, 30 September 2007 (PDT)<br /> * [[User:Becky Tardis|Becky Tardis]] 08:34, 30 September 2007 (PDT)<br /> * [[User:Peter Newell|Peter Newell]] 14:14, 30 September 2007 (PDT)<br /> * [[User:Dr Scofield|Dr Scofield]] 00:45, 1 October 2007 (PDT)</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Viewer_Authentication_Critique&diff=33885 Viewer Authentication Critique 2007-10-01T10:07:54Z

<p>Matthew Dowd: Added a pro for persistence</p> <hr /> <div>This is a formal critique of [[Viewer Authentication]] that was [https://lists.secondlife.com/pipermail/sldev/2007-September/005403.html requested] by [[User:Rob Linden]] on the [[SLDev]] mailing list.<br /> <br /> For a branch of the discussion see [https://wiki.secondlife.com/wiki/Talk:Viewer_Authentication Talk page on the original proposal.]<br /> <br /> == Summary ==<br /> <br /> The new authentication method proposed by LL seems to be an attempt to solve a perceived but non-existent problem. <br /> <br /> There are no known password capturing third party viewers in the wild, and a third party viewer requires such a privilege level of access to an account anyway that if you don't trust it with your username and password, you shouldn't be running it anyway. The mechanism proposed, however, is more prone to phishing attacks. Most password compromises are probably due to weaknesses in the current protocol challenge response or due to allowing weak passwords. <br /> <br /> Providing a single authentication mechanism for LL (and third party) websites would be an improvement to multiple backend copies of username and password, however this could be implemented without touching the viewer authentication method. Support for OpenID and other identity metasystems would increase the flexibility and offer features such as brokered identity verification. However, these would only be part of the solution, and although the proposed mechanism would provide a way for future support of these, there are other ways this could be achieved. Future support for OpenID is perhaps a topic for a seperate discussion and debate, but a open debate on this should happen.<br /> <br /> There seems to be no demand to synchronise the authentication of the viewer with authentication on the SL web site (account, forums, etc.), and any benefits gained would be negated by the problems this would cause anyone running alts (e.g. for in world permissions testing etc.) or multiple viewers (e.g. main, test and firstlook). It also raises problems for those running OpenSim based Grids, and may also cause difficulties further down the line as regards the new architecture discussions.<br /> <br /> It was also noted that consideration should be given when considering enhancements to the security/authentication models whether these should be optional - allowing users to make their own risk/convenience decisions.<br /> <br /> == Security ==<br /> <br /> === LL's Objectives ===<br /> * To mitigate the danger of password capturing Trojans masquerading as third party viewers<br /> * Improve trust in third party viewers by providing a means of assurance to the user that the third party viewer could not be a Trojan capturing usernames and passwords.<br /> <br /> === Pros ===<br /> * Viewer does not have to process (and "see") username and password<br /> <br /> === Cons ===<br /> * The main risk of running a third party viewer (or any other application not provided by Linden Labs) is not stealing passwords, it's direct attacks through the client... and the "official" client is not really any protection against that.<br /> ** Viewer can still be used in direct and indirect attacks even if it never sees the password (for example: salami slicing through cutout accounts, acting as a cutout account or an in-world botnet, faking a failed connection while giving an attacker access).<br /> ** NON-viewer applications (such as editors, 3d tools) designed for use by SL residents could use a keystroke logger and macro to perform any of these attacks, or could inject code into the viewer to do the same thing. Look at 'cheating' programs in combat MMORPGs for ideas.<br /> * But this is still not a large risk, unless people get the client through a mechanism that makes the creator anonymous. Historically, attempts to disseminate boobytrapped versions of applications have only worked in environments where it's routine for people to download applications from anonymous sources (file areas in the BBS era, for example). It's too easy to trace down the originator of any compromised client when you're getting them from their own website.<br /> <br><br /> * Bottom line here is that third party viewers stealing passwords are a very small risk for the user: the bigger risk is from the web browser!<br /> ** Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.<br /> *** This kind of attack is not theoretical, phishing websites are a criminal industry.<br /> *** It would be very easy to set up a temporary (i.e. hard to trace the real owner) phishing webpage which looks like the official SL logon, and send e-mails such as "You've received xxx in SL, Click here to logon" apparently from LL - with far less work than trying to create, and entice people to download a trojan viewer<br /> ** Relies on browser security, and uses a mechanism often disabled or filtered due to security concerns<br /> ** Too reliant on browser/OS implementations (proxies, firewalls, used browsers, etc.)<br /> * So using the browser to perform the authentication moves the authentication to a mechanism that has historically proven more likely to be compromised.<br /> <br><br /> * And the mechanism itself is relatively inflexible.<br /> ** Links to secondlife:// can only point to one instance (version, e.g. homebrew, release candidate official) of the program<br /> ** Links to secondlife:// can not pass parameters to the program<br /> *** In fact allowing that was a security flaw recently found and fixed in the SL client. :(<br /> ** It will raise problems for those running alternative (e.g. OpenSim) grids, and also have impact on the dicussions for a future open grid.<br /> <br><br /> * Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)<br /> ** The issues raised in the next sections would mean that people would have an incentive to use this kind of client.<br /> <br /> === Alternatives ===<br /> * One time passwords (for copy paste into a non-secure viewer or to print and take with you to friends, internet cafes, public terminals, etc.)<br /> * lower perm passwords (pwds which put the account into a restricted state, disallowing "dangerous" transactions)<br /> * separate passwords for website account and being inworld<br /> * Account restrictions <br /> * Allow third party plug-ins in the viewer (these would allow the extra functionality which are sometimes the reason for running third party viewers, but would rely on the official viewer for validation)<br /> * Do nothing, keep everything as it is.<br /> ** Without a strong case for the status quo being a problem, this is certainly a viable alternative.<br /> <br><br /> * This may be the wrong problem - password compromises are more likely to be through standard phishing attacks (logon here to update your account info) which is not addressed, or by weaknesses in the current authentication mechnism or just insecure passwords.<br /> ** CRAM-MD5 or a similar challenge-response type <br /> ** Dictionary check to reject insecure passwords<br /> <br /> == Flexibility ==<br /> <br /> === LL's Objectives ===<br /> * Single Sign On - allowing multiple web applications (forums, support, account, jira, wiki etc.) and viewers to use the same username and password through a single point without duplicating usernames and passwords into multiple systems<br /> * Extension of this to allow non-LL applications and web sites to participate in this single sign on system.<br /> <br /> === Pros ===<br /> * Enables username/password authentication to work on third party sites without them having to "see" username and password<br /> <br /> === Cons ===<br /> * This is really an unrelated issue...<br /> ** The client doesn't need to depend on the website for this purpose, or this could be a command line option.<br /> ** The client could just as easily be the 'authentication source' as the website.<br /> *** Via a "go to website" link in the client that passed an equivalent token.<br /> <br><br /> * As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> <br /> === Alternatives ===<br /> * Use this mechanism for websites (including third party) only but not for viewers<br /> <br><br /> * Identity Metasystem - [http://en.wikipedia.org/wiki/Identity_Metasystem]<br /> ** OpenID - [http://openid.net/]<br /> ** CardSpace - [http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx]<br /> ** Shibboleth - [http://shibboleth.internet2.edu/]<br /> ** CAS - [http://www.ja-sig.org/products/cas/]<br /> *** These could be handled by the client poping up a window using the internal web browser to connect to a HTML logon. It may be difficult or impossible to determine if the client really is displaying the official HTML logon and not capturing key strokes so this would be a way of implementing the above for flexibility or other reasons (e.g. brokered identity verification [http://www.agimo.gov.au/publications/2004/05/egovt_challenges/privacy/identity/brokered]) not for security<br /> <br /> == Persistence ==<br /> <br /> === LL's Objectives ===<br /> * To synchronise the various LL's systems (forums, support, jira, account, etc.) so that by logging onto one, you are automatically logged onto the others.<br /> <br /> === Pros ===<br /> * Selecting "Account History" or "Manage My Account" and similar menu items would open the web page for the account logged into SL, rather than the account logged into the web site, which currently can be different<br /> <br /> === Cons ===<br /> * As in the previous section, LL's objectives could be met without the viewer logging in via the same mechanism.<br /> * Inconvenient for those with alts or multiple clients<br /> ** Cumbersome to change alts and logon with multiple alts<br /> ** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL<br /> ** As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> * Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.<br /> * Staying online on secondlife.com (which many people seem to do) automatically means anyone with access to the computer/browser (family) can log in with the account inworld<br /> * starting SL from the web browser on a regular basis will most likely result in the web browser lingering in memory in the background when running the viewer, which based on the heavy memory requirement may impair viewer performance.<br /> * this would have an impact on the architecture discussions for a future open grid.<br /> <br /> === Alternatives ===<br /> * As regards menu items such as "Account History", send the account name on the URL, and have the web page check if that is the currently logged on account. If not prompt the user to log on with the same account as being used in the viewer (for security reasons the viewer should not automatically log the account on to the web site in such cases).<br /> * Is this really needed or desirable (''for the client'')? SL is not an extension of the web, it's a different kind of interface... one that has the potential of becoming a "3d web".<br /> <br /> == Signatories ==<br /> <br /> Please sign this below with "<nowiki>~~~~</nowiki>" if you agree with the version of this document you are reading. The date will indicate which version of the document you read and agree with. <br /> <br /> * [[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)<br /> * [[User:Argent Stonecutter|Argent Stonecutter]] 13:53, 29 September 2007 (PDT)<br /> * [[User:Dale Glass|Dale Glass]] 14:28, 29 September 2007 (PDT)<br /> * [[User:Tillie Ariantho|Tillie Ariantho]] 03:48, 30 September 2007 (PDT)<br /> * [[User:Jesse Barnett|Jesse Barnett]] 9:53, 30 September 2007 (PDT)<br /> * [[User:Winter Ventura|Winter Ventura]] 19:42, 29 September 2007 (PDT)<br /> * [[User:Balp Allen|Balp Allen]] 01:33, 30 September 2007 (PDT)<br /> * [[User:Michelle2 Zenovka|Michelle2 Zenovka]] 02:52, 30 September 2007 (PDT)<br /> * [[User:Nicholaz Beresford|Nicholaz]] 03:42, 30 September 2007 (PDT)<br /> * [[User:Dzonatas Sol|Dzonatas Sol]] 06:54, 30 September 2007 (PDT)<br /> * [[User:Eloise Pasteur|Eloise Pasteur]] 06:57, 30 September 2007 (PDT)<br /> * [[User:Becky Tardis|Becky Tardis]] 08:34, 30 September 2007 (PDT)<br /> * [[User:Peter Newell|Peter Newell]] 14:14, 30 September 2007 (PDT)<br /> * [[User:Dr Scofield|Dr Scofield]] 00:45, 1 October 2007 (PDT)</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Viewer_Authentication_Critique&diff=33854 Viewer Authentication Critique 2007-09-30T17:02:48Z

<p>Matthew Dowd: </p> <hr /> <div>This is a formal critique of [[Viewer Authentication]] that was [https://lists.secondlife.com/pipermail/sldev/2007-September/005403.html requested] by [[User:Rob Linden]] on the [[SLDev]] mailing list.<br /> <br /> For a branch of the discussion see [https://wiki.secondlife.com/wiki/Talk:Viewer_Authentication Talk page on the original proposal.]<br /> <br /> == Summary ==<br /> <br /> The new authentication method proposed by LL seems to be an attempt to solve a perceived but non-existent problem. <br /> <br /> There are no known password capturing third party viewers in the wild, and a third party viewer requires such a privilege level of access to an account anyway that if you don't trust it with your username and password, you shouldn't be running it anyway. The mechanism proposed, however, is more prone to phishing attacks. Most password compromises are probably due to weaknesses in the current protocol challenge response or due to allowing weak passwords. <br /> <br /> Providing a single authentication mechanism for LL (and third party) websites would be an improvement to multiple backend copies of username and password, however this could be implemented without touching the viewer authentication method. Support for OpenID and other identity metasystems would increase the flexibility and offer features such as brokered identity verification. However, these would only be part of the solution, and although the proposed mechanism would provide a way for future support of these, there are other ways this could be achieved. Future support for OpenID is perhaps a topic for a seperate discussion and debate, but a open debate on this should happen.<br /> <br /> There seems to be no demand to synchronise the authentication of the viewer with authentication on the SL web site (account, forums, etc.), and any benefits gained would be negated by the problems this would cause anyone running alts (e.g. for in world permissions testing etc.) or multiple viewers (e.g. main, test and firstlook). It also raises problems for those running OpenSim based Grids, and may also cause difficulties further down the line as regards the new architecture discussions.<br /> <br /> It was also noted that consideration should be given when considering enhancements to the security/authentication models whether these should be optional - allowing users to make their own risk/convenience decisions.<br /> <br /> == Security ==<br /> <br /> === LL's Objectives ===<br /> * To mitigate the danger of password capturing Trojans masquerading as third party viewers<br /> * Improve trust in third party viewers by providing a means of assurance to the user that the third party viewer could not be a Trojan capturing usernames and passwords.<br /> <br /> === Pros ===<br /> * Viewer does not have to process (and "see") username and password<br /> <br /> === Cons ===<br /> * The main risk of running a third party viewer (or any other application not provided by Linden Labs) is not stealing passwords, it's direct attacks through the client... and the "official" client is not really any protection against that.<br /> ** Viewer can still be used in direct and indirect attacks even if it never sees the password (for example: salami slicing through cutout accounts, acting as a cutout account or an in-world botnet, faking a failed connection while giving an attacker access).<br /> ** NON-viewer applications (such as editors, 3d tools) designed for use by SL residents could use a keystroke logger and macro to perform any of these attacks, or could inject code into the viewer to do the same thing. Look at 'cheating' programs in combat MMORPGs for ideas.<br /> * But this is still not a large risk, unless people get the client through a mechanism that makes the creator anonymous. Historically, attempts to disseminate boobytrapped versions of applications have only worked in environments where it's routine for people to download applications from anonymous sources (file areas in the BBS era, for example). It's too easy to trace down the originator of any compromised client when you're getting them from their own website.<br /> <br><br /> * Bottom line here is that third party viewers stealing passwords are a very small risk for the user: the bigger risk is from the web browser!<br /> ** Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.<br /> *** This kind of attack is not theoretical, phishing websites are a criminal industry.<br /> *** It would be very easy to set up a temporary (i.e. hard to trace the real owner) phishing webpage which looks like the official SL logon, and send e-mails such as "You've received xxx in SL, Click here to logon" apparently from LL - with far less work than trying to create, and entice people to download a trojan viewer<br /> ** Relies on browser security, and uses a mechanism often disabled or filtered due to security concerns<br /> ** Too reliant on browser/OS implementations (proxies, firewalls, used browsers, etc.)<br /> * So using the browser to perform the authentication moves the authentication to a mechanism that has historically proven more likely to be compromised.<br /> <br><br /> * And the mechanism itself is relatively inflexible.<br /> ** Links to secondlife:// can only point to one instance (version, e.g. homebrew, release candidate official) of the program<br /> ** Links to secondlife:// can not pass parameters to the program<br /> *** In fact allowing that was a security flaw recently found and fixed in the SL client. :(<br /> ** It will raise problems for those running alternative (e.g. OpenSim) grids, and also have impact on the dicussions for a future open grid.<br /> <br><br /> * Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)<br /> ** The issues raised in the next sections would mean that people would have an incentive to use this kind of client.<br /> <br /> === Alternatives ===<br /> * One time passwords (for copy paste into a non-secure viewer or to print and take with you to friends, internet cafes, public terminals, etc.)<br /> * lower perm passwords (pwds which put the account into a restricted state, disallowing "dangerous" transactions)<br /> * separate passwords for website account and being inworld<br /> * Account restrictions <br /> * Allow third party plug-ins in the viewer (these would allow the extra functionality which are sometimes the reason for running third party viewers, but would rely on the official viewer for validation)<br /> * Do nothing, keep everything as it is.<br /> ** Without a strong case for the status quo being a problem, this is certainly a viable alternative.<br /> <br><br /> * This may be the wrong problem - password compromises are more likely to be through standard phishing attacks (logon here to update your account info) which is not addressed, or by weaknesses in the current authentication mechnism or just insecure passwords.<br /> ** CRAM-MD5 or a similar challenge-response type <br /> ** Dictionary check to reject insecure passwords<br /> <br /> == Flexibility ==<br /> <br /> === LL's Objectives ===<br /> * Single Sign On - allowing multiple web applications (forums, support, account, jira, wiki etc.) and viewers to use the same username and password through a single point without duplicating usernames and passwords into multiple systems<br /> * Extension of this to allow non-LL applications and web sites to participate in this single sign on system.<br /> <br /> === Pros ===<br /> * Enables username/password authentication to work on third party sites without them having to "see" username and password<br /> <br /> === Cons ===<br /> * This is really an unrelated issue...<br /> ** The client doesn't need to depend on the website for this purpose, or this could be a command line option.<br /> ** The client could just as easily be the 'authentication source' as the website.<br /> *** Via a "go to website" link in the client that passed an equivalent token.<br /> <br><br /> * As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> <br /> === Alternatives ===<br /> * Use this mechanism for websites (including third party) only but not for viewers<br /> <br><br /> * Identity Metasystem - [http://en.wikipedia.org/wiki/Identity_Metasystem]<br /> ** OpenID - [http://openid.net/]<br /> ** CardSpace - [http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx]<br /> ** Shibboleth - [http://shibboleth.internet2.edu/]<br /> ** CAS - [http://www.ja-sig.org/products/cas/]<br /> *** These could be handled by the client poping up a window using the internal web browser to connect to a HTML logon. It may be difficult or impossible to determine if the client really is displaying the official HTML logon and not capturing key strokes so this would be a way of implementing the above for flexibility or other reasons (e.g. brokered identity verification [http://www.agimo.gov.au/publications/2004/05/egovt_challenges/privacy/identity/brokered]) not for security<br /> <br /> == Persistence ==<br /> <br /> === LL's Objectives ===<br /> * To synchronise the various LL's systems (forums, support, jira, account, etc.) so that by logging onto one, you are automatically logged onto the others.<br /> <br /> === Pros ===<br /> * None offered!<br /> ** Is this really needed or desirable (''for the client'')? SL is not an extension of the web, it's a different kind of interface... one that has the potential of becoming a "3d web". <br /> <br /> === Cons ===<br /> * As in the previous section, LL's objectives could be met without the viewer logging in via the same mechanism.<br /> * Inconvenient for those with alts or multiple clients<br /> ** Cumbersome to change alts and logon with multiple alts<br /> ** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL<br /> ** As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> * Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.<br /> * Staying online on secondlife.com (which many people seem to do) automatically means anyone with access to the computer/browser (family) can log in with the account inworld<br /> * starting SL from the web browser on a regular basis will most likely result in the web browser lingering in memory in the background when running the viewer, which based on the heavy memory requirement may impair viewer performance.<br /> * this would make things harder for independent grids to use the official client, and have impact on the architecture discussions for a future open grid. <br /> <br /> === Alternatives ===<br /> * Not really felt to be an issue needing any resolution!<br /> == Signatories ==<br /> <br /> Please sign this below with "<nowiki>~~~~</nowiki>" if you agree with the version of this document you are reading. The date will indicate which version of the document you read and agree with. <br /> <br /> * [[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)<br /> * [[User:Argent Stonecutter|Argent Stonecutter]] 13:53, 29 September 2007 (PDT)<br /> * [[User:Dale Glass|Dale Glass]] 14:28, 29 September 2007 (PDT)<br /> * [[User:Tillie Ariantho|Tillie Ariantho]] 03:48, 30 September 2007 (PDT)<br /> * [[User:Jesse Barnett|Jesse Barnett]] 9:53, 30 September 2007 (PDT)<br /> * [[User:Winter Ventura|Winter Ventura]] 19:42, 29 September 2007 (PDT)<br /> * [[User:Balp Allen|Balp Allen]] 01:33, 30 September 2007 (PDT)<br /> * [[User:Michelle2 Zenovka|Michelle2 Zenovka]] 02:52, 30 September 2007 (PDT)<br /> * [[User:Nicholaz Beresford|Nicholaz]] 03:42, 30 September 2007 (PDT)<br /> * [[User:Dzonatas Sol|Dzonatas Sol]] 06:54, 30 September 2007 (PDT)<br /> * [[User:Eloise Pasteur|Eloise Pasteur]] 06:57, 30 September 2007 (PDT)<br /> * [[User:Becky Tardis|Becky Tardis]] 08:34, 30 September 2007 (PDT)</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Talk:Viewer_Authentication_Critique&diff=33795 Talk:Viewer Authentication Critique 2007-09-30T09:13:34Z

<p>Matthew Dowd: </p> <hr /> <div>{{Talk}}<br /> <br /> == Process for editing the critique ==<br /> <br /> By virtue of jumping first, I think [[User:Matthew Dowd|Matthew Dowd]] should be the working group chair for editing this document. What I think that means is this:<br /> * Anyone can still make no-brainer edits to the article<br /> * Matthew will be arbiter for dispute resolution, should that be necessary.<br /> * If there are points that Matthew is unclear about, he should delete them from the document, and move them to the talk page.<br /> * If there are points that others are unclear about, they should bring them up on the talk page, and then later delete them from the main page if a question/concern goes unanswered on the talk page (with "see talk page" in the comment of the edit).<br /> * If, for whatever reason, it becomes necessary to fork this document, it's best to move all critiques into the user space of the working group chair. So, for example, Matthew's version would move to [[User:Matthew Dowd/Viewer Authentication Critique]], and other critiques could also be done the same way. This page would become a list of critiques.<br /> <br /> Sound like a reasonable process? I think this is lightweight enough that a pretty good document can evolve pretty quickly. -- [[User:Rob Linden|Rob Linden]] 12:56, 29 September 2007 (PDT)<br /> <br /> == Third party viewers/code ==<br /> <br /> What's the substantive difference between these two points?<br /> # Viewer still involves running trusted code on the computer and could initiate other attacks e.g.<br /> # Most of these attacks could be performed by any third-party software designed for use with SL <br /> Both have many subpoints. Could they be consolidated into a single point? -- [[User:Rob Linden|Rob Linden]] 20:10, 29 September 2007 (PDT)<br /> <br /> The first point is that keeping the client from seeing the password doesn't remove the danger of a modified client.<br /> <br /> The second point is that *any* ancillary software (such as animation editors, sculpt editors, sculpt texture plugins) could be used in an attack, even if they don't actually connect to SL, since they would be used by SL residents.<br /> <br /> -- [[User:Argent Stonecutter|Argent Stonecutter]] 21:00, 29 September 2007 (PDT)<br /> <br /> Is this better, Rob? -- [[User:Argent Stonecutter|Argent Stonecutter]] 21:11, 29 September 2007 (PDT)<br /> <br /> :Yes, that is. Thanks for the clarification! -- [[User:Rob Linden|Rob Linden]] 21:44, 29 September 2007 (PDT)<br /> <br /> <br /> == No balance ==<br /> <br /> This article is pretty awful, its just an attack. For real critique you have to explore the alternatives and discuss the pros and cons for each.<br /> Even if this form of log in has these disadvantages it could still be an improvement over what we currently have.<br /> We need a common point of reference to discuss if this is an improvement and what alternatives exist.<br /> <br /> * I've tried to keep it balanced by seperating it into the three concerns, having Pros and Cons (these are really for the approach rather than the concerns), and a list of alternative options (although this is more of a jumping off point for further discussions of the alternatives than a considered response at this stage). It is somewhat negative, as to be honest, all the responses on the SLDev list were against the proposal. It does need some input now from LL - to check the objectives are correct, and perhaps indicate what they think the pros are! --[[User:Matthew Dowd|Matthew Dowd]] 02:13, 30 September 2007 (PDT)<br /> <br /> Having studied the original idea, each time and deeper I'm now convinced there is 0 gain on the security point, I also see many many big security risks with it. I hope this will be the first issue in the last time that actually the Lindens start to listen to criticism about the proposal. I think not there have so far been one mail in favor of the idea on the developer list. All the other issues that just ignores the users, to that extent that i have put off all investment in SL. The day an alternative comes out, Lindens and in really danger for how they handle there users. So far they have a product that is one of a kind. But the completion gain all the time. The company that did everything they could to screw there user base will loose. <br /> --[[User:Balp Allen|Balp Allen]] 01:44, 30 September 2007 (PDT)</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Viewer_Authentication_Critique&diff=33793 Viewer Authentication Critique 2007-09-30T08:47:17Z

<p>Matthew Dowd: </p> <hr /> <div>This is a formal critique of [[Viewer Authentication]] that was [https://lists.secondlife.com/pipermail/sldev/2007-September/005403.html requested] by [[User:Rob Linden]] on the [[SLDev]] mailing list.<br /> <br /> For a branch of the discussion see [https://wiki.secondlife.com/wiki/Talk:Viewer_Authentication Talk page on the original proposal.]<br /> <br /> == Summary ==<br /> <br /> The new authentication method proposed by LL seems to be an attempt to solve a perceived but non-existent problem. <br /> <br /> There are no known password capturing third party viewers in the wild, and a third party viewer requires such a privilege level of access to an account anyway that if you don't trust it with your username and password, you shouldn't be running it anyway. The mechanism proposed, however, is more prone to phishing attacks. Most password compromises are probably due to weaknesses in the current protocol challenge response or due to allowing weak passwords. <br /> <br /> Providing a single authentication mechanism for LL (and third party) websites would be an improvement to multiple backend copies of username and password, however this could be implemented without touching the viewer authentication method.<br /> <br /> There seems to be no demand to synchronise the authentication of the viewer with authentication on the SL web site (account, forums, etc.), and any benefits gained would be negated by the problems this would cause anyone running alts (e.g. for in world permissions testing etc.) or multiple viewers (e.g. main, test and firstlook). It also raises problems for those running OpenSim based Grids, and may also cause difficulties further down the line as regards the new architecture discussions.<br /> <br /> It was also noted that consideration should be given when considering enhancements to the security/authentication models whether these should be optional - allowing users to make their own risk/convenience decisions.<br /> <br /> == Security ==<br /> <br /> === LL's Objectives ===<br /> * To mitigate the danger of password capturing Trojans masquerading as third party viewers<br /> * Improve trust in third party viewers by providing a means of assurance to the user that the third party viewer could not be a Trojan capturing usernames and passwords.<br /> <br /> === Pros ===<br /> * Viewer does not have to process (and "see") username and password<br /> <br /> === Cons ===<br /> * The main risk of running a third party viewer (or any other application not provided by Linden Labs) is not stealing passwords, it's direct attacks through the client... and the "official" client is not really any protection against that.<br /> ** Viewer can still be used in direct and indirect attacks even if it never sees the password (for example: salami slicing through cutout accounts, acting as a cutout account or an in-world botnet, faking a failed connection while giving an attacker access).<br /> ** NON-viewer applications (such as editors, 3d tools) designed for use by SL residents could use a keystroke logger and macro to perform any of these attacks, or could inject code into the viewer to do the same thing. Look at 'cheating' programs in combat MMORPGs for ideas.<br /> * But this is still not a large risk, unless people get the client through a mechanism that makes the creator anonymous. Historically, attempts to disseminate boobytrapped versions of applications have only worked in environments where it's routine for people to download applications from anonymous sources (file areas in the BBS era, for example). It's too easy to trace down the originator of any compromised client when you're getting them from their own website.<br /> <br><br /> * Bottom line here is that third party viewers stealing passwords are a very small risk for the user: the bigger risk is from the web browser!<br /> ** Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.<br /> *** This kind of attack is not theoretical, phishing websites are a criminal industry.<br /> *** It would be very easy to set up a temporary (i.e. hard to trace the real owner) phishing webpage which looks like the official SL logon, and send e-mails such as "You've received xxx in SL, Click here to logon" apparently from LL - with far less work than trying to create, and entice people to download a trojan viewer<br /> ** Relies on browser security, and uses a mechanism often disabled or filtered due to security concerns<br /> ** Too reliant on browser/OS implementations (proxies, firewalls, used browsers, etc.)<br /> * So using the browser to perform the authentication moves the authentication to a mechanism that has historically proven more likely to be compromised.<br /> <br><br /> * And the mechanism itself is relatively inflexible.<br /> ** Links to secondlife:// can only point to one instance (version, e.g. homebrew, release candidate official) of the program<br /> ** Links to secondlife:// can not pass parameters to the program<br /> *** In fact allowing that was a security flaw recently found and fixed in the SL client. :(<br /> ** It will raise problems for those running alternative (e.g. OpenSim) grids, and also have impact on the dicussions for a future open grid.<br /> <br><br /> * Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)<br /> ** The issues raised in the next sections would mean that people would have an incentive to use this kind of client.<br /> <br /> === Alternatives ===<br /> * One time passwords (for copy paste into a non-secure viewer or to print and take with you to friends, internet cafes, public terminals, etc.)<br /> * lower perm passwords (pwds which put the account into a restricted state, disallowing "dangerous" transactions)<br /> * separate passwords for website account and being inworld<br /> * Account restrictions <br /> * Allow third party plug-ins in the viewer (these would allow the extra functionality which are sometimes the reason for running third party viewers, but would rely on the official viewer for validation)<br /> <br><br /> * This may be the wrong problem - password compromises are more likely to be through standard phishing attacks (logon here to update your account info) which is not addressed, or by weaknesses in the current authentication mechnism or just insecure passwords.<br /> ** CRAM-MD5 or a similar challenge-response type <br /> ** Dictionary check to reject insecure passwords<br /> <br /> == Flexibility ==<br /> <br /> === LL's Objectives ===<br /> * Single Sign On - allowing multiple web applications (forums, support, account, jira, wiki etc.) and viewers to use the same username and password through a single point without duplicating usernames and passwords into multiple systems<br /> * Extension of this to allow non-LL applications and web sites to participate in this single sign on system.<br /> <br /> === Pros ===<br /> * Enables username/password authentication to work on third party sites without them having to "see" username and password<br /> <br /> === Cons ===<br /> * This is really an unrelated issue...<br /> ** The client doesn't need to depend on the website for this purpose, or this could be a command line option.<br /> ** The client could just as easily be the 'authentication source' as the website.<br /> *** Via a "go to website" link in the client that passed an equivalent token.<br /> <br><br /> * As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> <br /> === Alternatives ===<br /> * Use this mechanism for websites (including third party) only but not for viewers<br /> <br><br /> * Identity Metasystem - [http://en.wikipedia.org/wiki/Identity_Metasystem]<br /> ** OpenID - [http://openid.net/]<br /> ** CardSpace - [http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx]<br /> ** Shibboleth - [http://shibboleth.internet2.edu/]<br /> ** CAS - [http://www.ja-sig.org/products/cas/]<br /> *** These could be handled by the client poping up a window using the internal web browser to connect to a HTML logon. It may be difficult or impossible to determine if the client really is displaying the official HTML logon and not capturing key strokes so this would be a way of implementing the above for flexibility or other reasons (e.g. brokered identity verification [http://www.agimo.gov.au/publications/2004/05/egovt_challenges/privacy/identity/brokered]) not for security<br /> <br /> == Persistence ==<br /> <br /> === LL's Objectives ===<br /> * To integrate the various LL's systems (forums, support, jira, account, etc.) so that by logging onto one, you are automatically logged onto the others.<br /> <br /> === Pros ===<br /> * None offered!<br /> ** Is this really needed or desirable (''for the client'')? SL is not an extension of the web, it's a different kind of interface... one that has the potential of becoming a "3d web". <br /> <br /> === Cons ===<br /> * As in the previous section, LL's objectives could be met without the viewer logging in via the same mechanism.<br /> * Inconvenient for those with alts or multiple clients<br /> ** Cumbersome to change alts and logon with multiple alts<br /> ** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL<br /> ** As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> * Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.<br /> * Staying online on secondlife.com (which many people seem to do) automatically means anyone with access to the computer/browser (family) can log in with the account inworld<br /> * starting SL from the web browser on a regular basis will most likely result in the web browser lingering in memory in the background when running the viewer, which based on the heavy memory requirement may impair viewer performance.<br /> * this would make things harder for independent grids to use the official client, and have impact on the architecture discussions for a future open grid. <br /> <br /> === Alternatives ===<br /> * Not really felt to be an issue needing any resolution!<br /> == Signatories ==<br /> <br /> Please sign this below with "<nowiki>~~~~</nowiki>" if you agree with the version of this document you are reading. The date will indicate which version of the document you read and agree with. <br /> <br /> * [[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)<br /> * [[User:Argent Stonecutter|Argent Stonecutter]] 13:53, 29 September 2007 (PDT)<br /> * [[User:Dale Glass|Dale Glass]] 14:28, 29 September 2007 (PDT)<br /> * [[User:Tillie Ariantho|Tillie Ariantho]] 14:53, 29 September 2007 (PDT)<br /> * [[User:Nicholaz Beresford|Nicholaz]] 15:38, 29 September 2007 (PDT)<br /> * [[User:Jesse Barnett|Jesse Barnett]] 20:59, 29 September 2007 (PDT)<br /> * [[User:Winter Ventura|Winter Ventura]] 19:42, 29 September 2007 (PDT)<br /> * [[User:Balp Allen|Balp Allen]] 01:33, 30 September 2007 (PDT)</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Viewer_Authentication_Critique&diff=33794 Viewer Authentication Critique 2007-09-30T08:44:59Z

<p>Matthew Dowd: </p> <hr /> <div>This is a formal critique of [[Viewer Authentication]] that was [https://lists.secondlife.com/pipermail/sldev/2007-September/005403.html requested] by [[User:Rob Linden]] on the [[SLDev]] mailing list.<br /> <br /> For a branch of the discussion see [https://wiki.secondlife.com/wiki/Talk:Viewer_Authentication Talk page on the original proposal.]<br /> <br /> == Summary ==<br /> <br /> The new authentication method proposed by LL seems to be an attempt to solve a perceived but non-existent problem. <br /> <br /> There are no known password capturing third party viewers in the wild, and a third party viewer requires such a privilege level of access to an account anyway that if you don't trust it with your username and password, you shouldn't be running it anyway. The mechanism proposed, however, is more prone to phishing attacks. Most password compromises are probably due to weaknesses in the current protocol challenge response or due to allowing weak passwords. <br /> <br /> Providing a single authentication mechanism for LL (and third party) websites would be an improvement to multiple backend copies of username and password, however this could be implemented without touching the viewer authentication method.<br /> <br /> There seems to be no demand to synchronise the authentication of the viewer with authentication on the SL web site (account, forums, etc.), and any benefits gained would be negated by the problems this would cause anyone running alts (e.g. for in world permissions testing etc.) or multiple viewers (e.g. main, test and firstlook). It also raises problems for those running OpenSim based Grids, and may also cause difficulties further down the line as regards the new architecture discussions.<br /> <br /> It was also noted that consideration should be given when considering enhancements to the security/authentication models whether these should be optional - allowing users to make their own risk/convenience decisions.<br /> <br /> == Security ==<br /> <br /> === LL's Objectives ===<br /> * To mitigate the danger of password capturing Trojans masquerading as third party viewers<br /> * Improve trust in third party viewers by providing a means of assurance to the user that the third party viewer could not be a Trojan capturing usernames and passwords.<br /> <br /> === Pros ===<br /> * Viewer does not have to process (and "see") username and password<br /> <br /> === Cons ===<br /> * The main risk of running a third party viewer (or any other application not provided by Linden Labs) is not stealing passwords, it's direct attacks through the client... and the "official" client is not really any protection against that.<br /> ** Viewer can still be used in direct and indirect attacks even if it never sees the password (for example: salami slicing through cutout accounts, acting as a cutout account or an in-world botnet, faking a failed connection while giving an attacker access).<br /> ** NON-viewer applications (such as editors, 3d tools) designed for use by SL residents could use a keystroke logger and macro to perform any of these attacks, or could inject code into the viewer to do the same thing. Look at 'cheating' programs in combat MMORPGs for ideas.<br /> * But this is still not a large risk, unless people get the client through a mechanism that makes the creator anonymous. Historically, attempts to disseminate boobytrapped versions of applications have only worked in environments where it's routine for people to download applications from anonymous sources (file areas in the BBS era, for example). It's too easy to trace down the originator of any compromised client when you're getting them from their own website.<br /> <br><br /> * Bottom line here is that third party viewers stealing passwords are a very small risk for the user: the bigger risk is from the web browser!<br /> ** Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.<br /> *** This kind of attack is not theoretical, phishing websites are a criminal industry.<br /> *** It would be very easy to set up a temporary (i.e. hard to trace the real owner) phishing webpage which looks like the official SL logon, and send e-mails such as "You've received xxx in SL, Click here to logon" apparently from LL - with far less work than trying to create, and entice people to download a trojan viewer<br /> ** Relies on browser security, and uses a mechanism often disabled or filtered due to security concerns<br /> ** Too reliant on browser/OS implementations (proxies, firewalls, used browsers, etc.)<br /> * So using the browser to perform the authentication moves the authentication to a mechanism that has historically proven more likely to be compromised.<br /> <br><br /> * And the mechanism itself is relatively inflexible.<br /> ** Links to secondlife:// can only point to one instance (version, e.g. homebrew, release candidate official) of the program<br /> ** Links to secondlife:// can not pass parameters to the program<br /> *** In fact allowing that was a security flaw recently found and fixed in the SL client. :(<br /> ** It will raise problems for those running alternative (e.g. OpenSim) grids, and also have impact on the dicussions for a future open grid.<br /> <br><br /> * Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)<br /> ** The issues raised in the next sections would mean that people would have an incentive to use this kind of client.<br /> <br /> === Alternatives ===<br /> * One time passwords (for copy paste into a non-secure viewer or to print and take with you to friends, internet cafes, public terminals, etc.)<br /> * lower perm passwords (pwds which put the account into a restricted state, disallowing "dangerous" transactions)<br /> * separate passwords for website account and being inworld<br /> * Account restrictions <br /> * Allow third party plug-ins in the viewer (these would allow the extra functionality which are sometimes the reason for running third party viewers, but would rely on the official viewer for validation)<br /> <br><br /> * This may be the wrong problem - password compromises are more likely to be through standard phishing attacks (logon here to update your account info) which is not addressed, or by weaknesses in the current authentication mechnism or just insecure passwords.<br /> ** CRAM-MD5 or a similar challenge-response type <br /> ** Dictionary check to reject insecure passwords<br /> <br /> == Flexibility ==<br /> <br /> === LL's Objectives ===<br /> * Single Sign On - allowing multiple web applications (forums, support, account, jira, wiki etc.) and viewers to use the same username and password through a single point without duplicating usernames and passwords into multiple systems<br /> * Extension of this to allow non-LL applications and web sites to participate in this single sign on system.<br /> <br /> === Pros ===<br /> * Enables username/password authentication to work on third party sites without them having to "see" username and password<br /> <br /> === Cons ===<br /> * This is really an unrelated issue...<br /> ** The client doesn't need to depend on the website for this purpose, or this could be a command line option.<br /> ** The client could just as easily be the 'authentication source' as the website.<br /> *** Via a "go to website" link in the client that passed an equivalent token.<br /> <br><br /> * As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> <br /> === Alternatives ===<br /> * Use this mechanism for websites (including third party) only but not for viewers<br /> <br><br /> * Identity Metasystem - [http://en.wikipedia.org/wiki/Identity_Metasystem]<br /> ** OpenID - [http://openid.net/]<br /> ** CardSpace - [http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx]<br /> ** Shibboleth - [http://shibboleth.internet2.edu/]<br /> ** CAS - [http://www.ja-sig.org/products/cas/]<br /> *** These could be handled by the client poping up a window using the internal web browser to connect to a HTML logon. It may be difficult or impossible to determine if the client really is displaying the official HTML logon and not capturing key strokes so this would be a way of implementing the above for flexibility or other reasons (e.g. brokered identity verification [http://www.agimo.gov.au/publications/2004/05/egovt_challenges/privacy/identity/brokered]) not for security<br /> <br /> == Persistence ==<br /> <br /> === LL's Objectives ===<br /> * To synchronise the various LL's systems (forums, support, jira, account, etc.) so that by logging onto one, you are automatically logged onto the others.<br /> <br /> === Pros ===<br /> * None offered!<br /> ** Is this really needed or desirable (''for the client'')? SL is not an extension of the web, it's a different kind of interface... one that has the potential of becoming a "3d web". <br /> <br /> === Cons ===<br /> * As in the previous section, LL's objectives could be met without the viewer logging in via the same mechanism.<br /> * Inconvenient for those with alts or multiple clients<br /> ** Cumbersome to change alts and logon with multiple alts<br /> ** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL<br /> ** As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> * Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.<br /> * Staying online on secondlife.com (which many people seem to do) automatically means anyone with access to the computer/browser (family) can log in with the account inworld<br /> * starting SL from the web browser on a regular basis will most likely result in the web browser lingering in memory in the background when running the viewer, which based on the heavy memory requirement may impair viewer performance.<br /> * this would make things harder for independent grids to use the official client, and have impact on the architecture discussions for a future open grid. <br /> <br /> === Alternatives ===<br /> * Not really felt to be an issue needing any resolution!<br /> == Signatories ==<br /> <br /> Please sign this below with "<nowiki>~~~~</nowiki>" if you agree with the version of this document you are reading. The date will indicate which version of the document you read and agree with. <br /> <br /> * [[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)<br /> * [[User:Argent Stonecutter|Argent Stonecutter]] 13:53, 29 September 2007 (PDT)<br /> * [[User:Dale Glass|Dale Glass]] 14:28, 29 September 2007 (PDT)<br /> * [[User:Tillie Ariantho|Tillie Ariantho]] 14:53, 29 September 2007 (PDT)<br /> * [[User:Nicholaz Beresford|Nicholaz]] 15:38, 29 September 2007 (PDT)<br /> * [[User:Jesse Barnett|Jesse Barnett]] 20:59, 29 September 2007 (PDT)<br /> * [[User:Winter Ventura|Winter Ventura]] 19:42, 29 September 2007 (PDT)<br /> * [[User:Balp Allen|Balp Allen]] 01:33, 30 September 2007 (PDT)</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Viewer_Authentication_Critique&diff=33791 Viewer Authentication Critique 2007-09-30T08:43:28Z

<p>Matthew Dowd: Editorial pass. Added summary</p> <hr /> <div>This is a formal critique of [[Viewer Authentication]] that was [https://lists.secondlife.com/pipermail/sldev/2007-September/005403.html requested] by [[User:Rob Linden]] on the [[SLDev]] mailing list.<br /> <br /> For a branch of the discussion see [https://wiki.secondlife.com/wiki/Talk:Viewer_Authentication Talk page on the original proposal.]<br /> <br /> == Summary ==<br /> <br /> The new authentication method proposed by LL seems to be an attempt to solve a perceived but non-existent problem. <br /> <br /> There are no known password capturing third party viewers in the wild, and a third party viewer requires such a privilege level of access to an account anyway that if you don't trust it with your username and password, you shouldn't be running it anyway. The mechanism proposed, however, is more prone to phishing attacks. Most password compromises are probably due to weaknesses in the current protocol challenge response or due to allowing weak passwords. <br /> <br /> Providing a single authentication mechanism for LL (and third party) websites would be an improvement to multiple backend copies of username and password, however this could be implemented without touching the viewer authentication method.<br /> <br /> There seems to be no demand to synchronise the authentication of the viewer with authentication on the SL web site (account, forums, etc.), and any benefits gained would be negated by the problems this would cause anyone running alts (e.g. for in world permissions testing etc.) or multiple viewers (e.g. main, test and firstlook). It also raises problems for those running OpenSim based Grids, and may also cause difficulties further down the line as regards the new architecture discussions.<br /> <br /> It was also noted that consideration should be given when considering enhancements to the security/authentication models whether these should be optional - allowing users to make their own risk/convenience decisions.<br /> <br /> == Security ==<br /> <br /> === LL's Objectives ===<br /> * To mitigate the danger of password capturing Trojans masquerading as third party viewers<br /> * Improve trust in third party viewers by providing a means of assurance to the user that the third party viewer could not be a Trojan capturing usernames and passwords.<br /> <br /> === Pros ===<br /> * Viewer does not have to process (and "see") username and password<br /> <br /> === Cons ===<br /> * The main risk of running a third party viewer (or any other application not provided by Linden Labs) is not stealing passwords, it's direct attacks through the client... and the "official" client is not really any protection against that.<br /> ** Viewer can still be used in direct and indirect attacks even if it never sees the password (for example: salami slicing through cutout accounts, acting as a cutout account or an in-world botnet, faking a failed connection while giving an attacker access).<br /> ** NON-viewer applications (such as editors, 3d tools) designed for use by SL residents could use a keystroke logger and macro to perform any of these attacks, or could inject code into the viewer to do the same thing. Look at 'cheating' programs in combat MMORPGs for ideas.<br /> * But this is still not a large risk, unless people get the client through a mechanism that makes the creator anonymous. Historically, attempts to disseminate boobytrapped versions of applications have only worked in environments where it's routine for people to download applications from anonymous sources (file areas in the BBS era, for example). It's too easy to trace down the originator of any compromised client when you're getting them from their own website.<br /> <br><br /> * Bottom line here is that third party viewers stealing passwords are a very small risk for the user: the bigger risk is from the web browser!<br /> ** Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.<br /> *** This kind of attack is not theoretical, phishing websites are a criminal industry.<br /> *** It would be very easy to set up a temporary (i.e. hard to trace the real owner) phishing webpage which looks like the official SL logon, and send e-mails such as "You've received xxx in SL, Click here to logon" apparently from LL - with far less work than trying to create, and entice people to download a trojan viewer<br /> ** Relies on browser security, and uses a mechanism often disabled or filtered due to security concerns<br /> ** Too reliant on browser/OS implementations (proxies, firewalls, used browsers, etc.)<br /> * So using the browser to perform the authentication moves the authentication to a mechanism that has historically proven more likely to be compromised.<br /> <br><br /> * And the mechanism itself is relatively inflexible.<br /> ** Links to secondlife:// can only point to one instance (version, e.g. homebrew, release candidate official) of the program<br /> ** Links to secondlife:// can not pass parameters to the program<br /> *** In fact allowing that was a security flaw recently found and fixed in the SL client. :(<br /> ** It will raise problems for those running alternative (e.g. OpenSim) grids, and also have impact on the dicussions for a future open grid.<br /> <br><br /> * Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)<br /> ** The issues raised in the next sections would mean that people would have an incentive to use this kind of client.<br /> <br /> === Alternatives ===<br /> * One time passwords (for copy paste into a non-secure viewer or to print and take with you to friends, internet cafes, public terminals, etc.)<br /> * lower perm passwords (pwds which put the account into a restricted state, disallowing "dangerous" transactions)<br /> * separate passwords for website account and being inworld<br /> * Account restrictions <br /> * Allow third party plug-ins in the viewere (these would allow the extra functionality which are sometimes the reason for running third party viewers, but would rely on the official viewer for validation)<br /> * This may be the wrong problem - password compromises are more likely to be through standard phishing attacks (logon here to update your account info) which is not addressed, or by weaknesses in the current authentication mechnism or just insecure passwords.<br /> ** CRAM-MD5 or a similar challenge-response type <br /> ** Dictionary check to reject insecure passwords<br /> <br /> == Flexibility ==<br /> <br /> === LL's Objectives ===<br /> * Single Sign On - allowing multiple web applications (forums, support, account, jira, wiki etc.) and viewers to use the same username and password through a single point without duplicating usernames and passwords into multiple systems<br /> * Extension of this to allow non-LL applications and web sites to participate in this single sign on system.<br /> <br /> === Pros ===<br /> * Enables username/password authentication to work on third party sites without them having to "see" username and password<br /> <br /> === Cons ===<br /> * This is really an unrelated issue...<br /> ** The client doesn't need to depend on the website for this purpose, or this could be a command line option.<br /> ** The client could just as easily be the 'authentication source' as the website.<br /> *** Via a "go to website" link in the client that passed an equivalent token.<br /> <br><br /> * As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> <br /> === Alternatives ===<br /> * Use this mechanism for websites (including third party) only but not for viewers<br /> * Identity Metasystem - [http://en.wikipedia.org/wiki/Identity_Metasystem]<br /> ** OpenID - [http://openid.net/]<br /> ** CardSpace - [http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx]<br /> ** Shibboleth - [http://shibboleth.internet2.edu/]<br /> ** CAS - [http://www.ja-sig.org/products/cas/]<br /> *** These could be handled by the client poping up a window using the internal web browser to connect to a HTML logon. It may be difficult or impossible to determine if the client really is displaying the official HTML logon and not capturing key strokes so this would be a way of implementing the above for flexibility or other reasons (e.g. brokered identity verification [http://www.agimo.gov.au/publications/2004/05/egovt_challenges/privacy/identity/brokered]) not for security<br /> <br /> == Persistence ==<br /> <br /> === LL's Objectives ===<br /> * To integrate the various LL's systems (forums, support, jira, account, etc.) so that by logging onto one, you are automatically logged onto the others.<br /> <br /> === Pros ===<br /> * <br /> * Is this really needed or desirable (''for the client'')? SL is not an extension of the web, it's a different kind of interface... one that has the potential of becoming a "3d web". <br /> <br /> === Cons ===<br /> * As in the previous section, LL's objectives could be met without the browser logging in via the same mechanism.<br /> * Inconvenient for those with alts or multiple clients<br /> ** Cumbersome to change alts and logon with multiple alts<br /> ** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL<br /> ** As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes<br /> * Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.<br /> * Staying online on secondlife.com (which many people seem to do) automatically means anyone with access to the computer/browser (family) can log in with the account inworld<br /> * starting SL from the web browser on a regular basis will most likely result in the web browser lingering in memory in the background when running the viewer, which based on the heavy memory requirement may impair viewer performance.<br /> * this would make things harder for independent grids to use the official client, and have impact on the architecture discussions for a future open grid. <br /> <br /> === Alternatives ===<br /> <br /> == Signatories ==<br /> <br /> Please sign this below with "<nowiki>~~~~</nowiki>" if you agree with the version of this document you are reading. The date will indicate which version of the document you read and agree with. <br /> <br /> * [[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)<br /> * [[User:Argent Stonecutter|Argent Stonecutter]] 13:53, 29 September 2007 (PDT)<br /> * [[User:Dale Glass|Dale Glass]] 14:28, 29 September 2007 (PDT)<br /> * [[User:Tillie Ariantho|Tillie Ariantho]] 14:53, 29 September 2007 (PDT)<br /> * [[User:Nicholaz Beresford|Nicholaz]] 15:38, 29 September 2007 (PDT)<br /> * [[User:Jesse Barnett|Jesse Barnett]] 20:59, 29 September 2007 (PDT)<br /> * [[User:Winter Ventura|Winter Ventura]] 19:42, 29 September 2007 (PDT)<br /> * [[User:Balp Allen|Balp Allen]] 01:33, 30 September 2007 (PDT)</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Viewer_Authentication_Critique&diff=33720 Viewer Authentication Critique 2007-09-29T20:40:14Z

<p>Matthew Dowd: </p> <hr /> <div>This is a formal critique of [[Viewer Authentication]] that was [https://lists.secondlife.com/pipermail/sldev/2007-September/005403.html requested] by [[User:Rob Linden]] on the [[SLDev]] mailing list.<br /> <br /> For a branch of the discussion see [https://wiki.secondlife.com/wiki/Talk:Viewer_Authentication Talk page on the original proposal.]<br /> <br /> == Security ==<br /> <br /> === LL's Objectives ===<br /> * To mitigate the danger of password capturing Trojans masquerading as third party viewers<br /> * Improve trust in third party viewers by providing a means of assurance to the user that the third party viewer could not be a Trojan capturing usernames and passwords.<br /> <br /> === Pros ===<br /> * Viewer does not have to process (and "see") username and password<br /> <br /> === Cons ===<br /> * Viewer still involves running trusted code on the computer and could initiate other attacks e.g.<br /> ** Silently buy L$ and pass onto another account<br /> ** Pass token onto bot, and drop the users connection<br /> ** Install key logger to monitor the next website login<br /> ** Salami slicing - make additional small or duplicate payments to cutout when user purchases or pays in game.<br /> * Potential for naive user to believe this reduces all risks in using a third party viewer.<br /> * Most of these attacks could be performed by any third-party software designed for use with SL<br /> ** A local support program could install a keylogger.<br /> ** A local support program could inject code into the client.<br /> ** Look at 'cheating' tools in MMORPGs for possible approaches.<br /> * Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.<br /> ** This kind of attack is not theoretical, phishing websites are a criminal industry.<br /> * Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)<br /> * Too reliant on browser/OS implementations (proxies, firewalls, used browsers, etc.)<br /> * Relies on browser security, and uses a mechanism often disabled or filtered due to security concerns<br /> * Links to secondlife:// can only point to one instance (version, e.g. homebrew, release candidate official) of the program<br /> * Links to secondlife:// can not pass parameters to the program<br /> <br /> === Alternatives ===<br /> * One time passwords (for copy paste into a non-secure viewer or to print and take with you to friends, internet cafes, public terminals, etc.)<br /> * lower perm passwords (pwds which put the account into a restricted state, disallowing "dangerous" transactions)<br /> * separate passwords for website account and being inworld<br /> * Account restrictions <br /> * CRAM-MD5 or a similar challenge-response type <br /> * Dictionary check to reject insecure passwords<br /> <br/><br /> * The main existing vulnerability involving the viewer and passwords is that the viewer does not use a cryptographically secure mechanism to pass the password to the server, <b>not</b> that the viewer may be stealing the password.<br /> <br/><br /> <br/><br /> <br /> == Flexibility ==<br /> <br /> === LL's Objectives ===<br /> * Single Sign On - allowing multiple web applications (forums, support, account, jira, wiki etc.) and viewers to use the same username and password through a single point without duplicating usernames and passwords into multiple systems<br /> * Extension of this to allow non-LL applications and web sites to participate in this single sign on system.<br /> <br /> === Pros ===<br /> * Enables username/password authentication to work on third party sites without them having to "see" username and password<br /> <br /> === Cons ===<br /> * This is really an unrelated issue...<br /> ** The client doesn't need to depend on the website for this purpose, or this could be a command line option.<br /> ** The client could just as easily be the 'authentication source' as the website.<br /> <br /> === Alternatives ===<br /> * Use this mechanism for websites (including third party) only but not for viewers<br /> * Identity Metasystem - [http://en.wikipedia.org/wiki/Identity_Metasystem]<br /> ** OpenID - [http://openid.net/]<br /> ** CardSpace - [http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx]<br /> ** CAS - [http://www.ja-sig.org/products/cas/]<br /> <br/><br /> <br/><br /> <br/><br /> == Persistence ==<br /> <br /> === LL's Objectives ===<br /> * To integrate the various LL's systems (forums, support, jira, account, etc.) so that by logging onto one, you are automatically logged onto the others.<br /> <br /> === Pros ===<br /> <br /> === Cons ===<br /> * Inconvenient for those with alts<br /> ** Cumbersome to change alts and logon with multiple alts<br /> ** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL<br /> * Inconvenient for those with multiple clients<br /> * Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.<br /> * Staying online on secondlife.com (which many people seem to do) automatically means anyone with access to the computer/browser (family) can log in with the account inworld<br /> <br /> === Alternatives ===<br /> * Is this really needed? <br /> <br/><br /> <br/><br /> <br/><br /> == Misc ==<br /> <br /> * this should be an option for those who have increased security needs, users should be able to make their own risk/convenience decisions<br /> * the feature especially forces those into an extra login step, who use an official viewer (homebrews will most likely quickly implement a way around this for convenience)<br /> * starting SL from the web browser on a regular basis will most likely result in the web browser lingering in memory in the background when running the viewer, which based on the heavy memory requirement may impair viewer performance.<br /> <br /> <br /> == Signatories ==<br /> <br /> Please sign this below with "<nowiki>~~~~</nowiki>" if you agree with the version of this document you are reading. The date will indicate which version of the document you read and agree with. <br /> <br /> * [[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Viewer_Authentication_Critique&diff=33718 Viewer Authentication Critique 2007-09-29T20:37:34Z

<p>Matthew Dowd: Added what the LL Objectives are believed to be</p> <hr /> <div>This is a formal critique of [[Viewer Authentication]] that was [https://lists.secondlife.com/pipermail/sldev/2007-September/005403.html requested] by [[User:Rob Linden]] on the [[SLDev]] mailing list.<br /> <br /> For a branch of the discussion see [https://wiki.secondlife.com/wiki/Talk:Viewer_Authentication Talk page on the original proposal.]<br /> <br /> == Security ==<br /> <br /> LL's Objectives: To mitigate the danger of password capturing Trojans masquerading as third party viewers; improve trust in third party viewers by providing a means of assurance to the user that the third party viewer could not be a Trojan capturing usernames and passwords.<br /> <br /> === Pros ===<br /> * Viewer does not have to process (and "see") username and password<br /> <br /> === Cons ===<br /> * Viewer still involves running trusted code on the computer and could initiate other attacks e.g.<br /> ** Silently buy L$ and pass onto another account<br /> ** Pass token onto bot, and drop the users connection<br /> ** Install key logger to monitor the next website login<br /> ** Salami slicing - make additional small or duplicate payments to cutout when user purchases or pays in game.<br /> * Potential for naive user to believe this reduces all risks in using a third party viewer.<br /> * Most of these attacks could be performed by any third-party software designed for use with SL<br /> ** A local support program could install a keylogger.<br /> ** A local support program could inject code into the client.<br /> ** Look at 'cheating' tools in MMORPGs for possible approaches.<br /> * Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.<br /> ** This kind of attack is not theoretical, phishing websites are a criminal industry.<br /> * Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)<br /> * Too reliant on browser/OS implementations (proxies, firewalls, used browsers, etc.)<br /> * Relies on browser security, and uses a mechanism often disabled or filtered due to security concerns<br /> * Links to secondlife:// can only point to one instance (version, e.g. homebrew, release candidate official) of the program<br /> * Links to secondlife:// can not pass parameters to the program<br /> <br /> === Alternatives ===<br /> * One time passwords (for copy paste into a non-secure viewer or to print and take with you to friends, internet cafes, public terminals, etc.)<br /> * lower perm passwords (pwds which put the account into a restricted state, disallowing "dangerous" transactions)<br /> * separate passwords for website account and being inworld<br /> * Account restrictions <br /> * CRAM-MD5 or a similar challenge-response type <br /> * Dictionary check to reject insecure passwords<br /> <br/><br /> <br/><br /> <br/><br /> == Flexibility ==<br /> <br /> LL's Objectives: Single Sign On - allowing multiple web applications (forums, support, account, jira, wiki etc.) and viewers to use the same username and password through a single point without duplicating usernames and passwords into multiple systems. Extension of this to allow non-LL applications and web sites to participate in this single sign on system.<br /> <br /> === Pros ===<br /> * Enables username/password authentication to work on third party sites without them having to "see" username and password<br /> <br /> === Cons ===<br /> * This is really an unrelated issue...<br /> ** The client doesn't need to depend on the website for this purpose, or this could be a command line option.<br /> ** The client could just as easily be the 'authentication source' as the website.<br /> <br /> === Alternatives ===<br /> * Use this mechanism for websites (including third party) only but not for viewers<br /> * Identity Metasystem - [http://en.wikipedia.org/wiki/Identity_Metasystem]<br /> ** OpenID - [http://openid.net/]<br /> ** CardSpace - [http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx]<br /> ** CAS - [http://www.ja-sig.org/products/cas/]<br /> <br/><br /> <br/><br /> <br/><br /> == Persistence ==<br /> <br /> LL's Objectives: To integrate the various LL's systems (forums, support, jira, account, etc.) so that by logging onto one, you are automatically logged onto the others.<br /> <br /> === Pros ===<br /> <br /> === Cons ===<br /> * Inconvenient for those with alts<br /> ** Cumbersome to change alts and logon with multiple alts<br /> ** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL<br /> * Inconvenient for those with multiple clients<br /> * Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.<br /> * Staying online on secondlife.com (which many people seem to do) automatically means anyone with access to the computer/browser (family) can log in with the account inworld<br /> <br /> === Alternatives ===<br /> * Is this really needed? <br /> <br/><br /> <br/><br /> <br/><br /> == Misc ==<br /> <br /> * this should be an option for those who have increased security needs, users should be able to make their own risk/convenience decisions<br /> * the feature especially forces those into an extra login step, who use an official viewer (homebrews will most likely quickly implement a way around this for convenience)<br /> * starting SL from the web browser on a regular basis will most likely result in the web browser lingering in memory in the background when running the viewer, which based on the heavy memory requirement may impair viewer performance.<br /> <br /> <br /> == Signatories ==<br /> <br /> Please sign this below with "<nowiki>~~~~</nowiki>" if you agree with the version of this document you are reading. The date will indicate which version of the document you read and agree with. <br /> <br /> * [[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Viewer_Authentication_Critique&diff=33704 Viewer Authentication Critique 2007-09-29T19:37:55Z

<p>Matthew Dowd: /* Alternatives */</p> <hr /> <div>This is a formal critique of [[Viewer Authentication]] that was [https://lists.secondlife.com/pipermail/sldev/2007-September/005403.html requested] by [[User:Rob Linden]] on the [[SLDev]] mailing list.<br /> <br /> == Security ==<br /> <br /> === Pros ===<br /> * Viewer does not have to process (and "see") username and password<br /> <br /> === Cons ===<br /> * Viewer still involves running trusted code on the computer and could initiate other attacks e.g.<br /> ** Silently buy L$ and pass onto another account<br /> ** Pass token onto bot, and drop the users connection<br /> ** Install key logger<br /> * Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.<br /> * Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)<br /> * Too reliant on browser/OS implementations<br /> * Relies on browser security, and uses a mechanism often disabled due to security concerns<br /> <br /> === Alternatives ===<br /> * One time passwords<br /> * Account restrictions<br /> * CRAM-MD5 or a similar challenge-response type <br /> * Dictionary check to reject insecure passwords<br /> <br /> == Flexibility ==<br /> <br /> === Pros ===<br /> * Enables username/password authentication to work on third party sites without them having to "see" username and password<br /> <br /> === Cons ===<br /> <br /> === Alternatives ===<br /> * Use this mechanism for websites (including third party) only but not for viewers<br /> * Identity Metasystem - [http://en.wikipedia.org/wiki/Identity_Metasystem]<br /> ** OpenID - [http://openid.net/]<br /> ** CardSpace - [http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx]<br /> <br /> == Persistence ==<br /> <br /> === Pros ===<br /> <br /> === Cons ===<br /> * Inconvenient for those with alts<br /> ** Cumbersome to change alts and logon with multiple alts<br /> ** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL<br /> * Inconvenient for those with multiple clients<br /> * Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.<br /> <br /> === Alternatives ===<br /> * Is this really needed? <br /> <br /> == Signatories ==<br /> <br /> Please sign this below with "<nowiki>~~~~</nowiki>" if you agree with the version of this document you are reading. The date will indicate which version of the document you read and agree with. <br /> <br /> * [[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Viewer_Authentication_Critique&diff=33698 Viewer Authentication Critique 2007-09-29T19:08:13Z

<p>Matthew Dowd: /* Alternatives */</p> <hr /> <div>This is a formal critique of [[Viewer Authentication]] that was [https://lists.secondlife.com/pipermail/sldev/2007-September/005403.html requested] by [[User:Rob Linden]] on the [[SLDev]] mailing list.<br /> <br /> == Security ==<br /> <br /> === Pros ===<br /> * Viewer does not have to process (and "see") username and password<br /> <br /> === Cons ===<br /> * Viewer still involves running trusted code on the computer and could initiate other attacks e.g.<br /> ** Silently buy L$ and pass onto another account<br /> ** Pass token onto bot, and drop the users connection<br /> ** Install key logger<br /> * Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.<br /> * Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)<br /> * Too reliant on browser/OS implementations<br /> * Relies on browser security, and uses a mechanism often disabled due to security concerns<br /> <br /> === Alternatives ===<br /> * One time passwords<br /> * Account restrictions<br /> <br /> == Flexibility ==<br /> <br /> === Pros ===<br /> * Enables username/password authentication to work on third party sites without them having to "see" username and password<br /> <br /> === Cons ===<br /> <br /> === Alternatives ===<br /> * Use this mechanism for websites (including third party) only but not for viewers<br /> * Identity Metasystem - [http://en.wikipedia.org/wiki/Identity_Metasystem]<br /> ** OpenID - [http://openid.net/]<br /> ** CardSpace - [http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx]<br /> <br /> == Persistence ==<br /> <br /> === Pros ===<br /> <br /> === Cons ===<br /> * Inconvenient for those with alts<br /> ** Cumbersome to change alts and logon with multiple alts<br /> ** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL<br /> * Inconvenient for those with multiple clients<br /> * Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.<br /> <br /> === Alternatives ===<br /> * Is this really needed? <br /> <br /> == Signatories ==<br /> <br /> Please sign this below with "<nowiki>~~~~</nowiki>" if you agree with the version of this document you are reading. The date will indicate which version of the document you read and agree with. <br /> <br /> * [[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Viewer_Authentication_Critique&diff=33690 Viewer Authentication Critique 2007-09-29T18:39:58Z

<p>Matthew Dowd: /* Cons */</p> <hr /> <div>== Security ==<br /> <br /> === Pros ===<br /> * Viewer does not have to process (and "see") username and password<br /> <br /> === Cons ===<br /> * Viewer still involves running trusted code on the computer and could initiate other attacks e.g.<br /> ** Silently buy L$ and pass onto another account<br /> ** Pass token onto bot, and drop the users connection<br /> ** Install key logger<br /> * Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.<br /> * Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)<br /> * Too reliant on browser/OS implementations<br /> * Relies on browser security, and uses a mechanism often disabled due to security concerns<br /> <br /> === Alternatives ===<br /> * One time passwords<br /> <br /> == Flexibility ==<br /> <br /> === Pros ===<br /> * Enables username/password authentication to work on third party sites without them having to "see" username and password<br /> <br /> === Cons ===<br /> <br /> === Alternatives ===<br /> * Use this mechanism for websites (including third party) only but not for viewers<br /> * OpenID<br /> * CardSpace<br /> * Identity Metasystem<br /> <br /> == Persistence ==<br /> <br /> === Pros ===<br /> <br /> === Cons ===<br /> * Inconvenient for those with alts<br /> ** Cumbersome to change alts and logon with multiple alts<br /> ** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL<br /> * Inconvenient for those with multiple clients<br /> * Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.<br /> <br /> === Alternatives ===<br /> * Is this really needed? <br /> <br /> <br /> ----<br /> --[[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Viewer_Authentication_Critique&diff=33689 Viewer Authentication Critique 2007-09-29T18:37:54Z

<p>Matthew Dowd: New page: == Security == === Pros === * Viewer does not have to process (and "see") username and password === Cons === * Viewer still involves running trusted code on the computer and could initia...</p> <hr /> <div>== Security ==<br /> <br /> === Pros ===<br /> * Viewer does not have to process (and "see") username and password<br /> <br /> === Cons ===<br /> * Viewer still involves running trusted code on the computer and could initiate other attacks e.g.<br /> ** Silently buy L$ and pass onto another account<br /> ** Pass token onto bot, and drop the users connection<br /> * Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.<br /> * Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)<br /> * Too reliant on browser/OS implementations<br /> * Relies on browser security, and uses a mechanism often disabled due to security concerns<br /> <br /> === Alternatives ===<br /> * One time passwords<br /> <br /> == Flexibility ==<br /> <br /> === Pros ===<br /> * Enables username/password authentication to work on third party sites without them having to "see" username and password<br /> <br /> === Cons ===<br /> <br /> === Alternatives ===<br /> * Use this mechanism for websites (including third party) only but not for viewers<br /> * OpenID<br /> * CardSpace<br /> * Identity Metasystem<br /> <br /> == Persistence ==<br /> <br /> === Pros ===<br /> <br /> === Cons ===<br /> * Inconvenient for those with alts<br /> ** Cumbersome to change alts and logon with multiple alts<br /> ** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL<br /> * Inconvenient for those with multiple clients<br /> * Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.<br /> <br /> === Alternatives ===<br /> * Is this really needed? <br /> <br /> <br /> ----<br /> --[[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Talk:Viewer_Authentication_Critique&diff=33688 Talk:Viewer Authentication Critique 2007-09-29T18:37:43Z

<p>Matthew Dowd: Removing all content from page</p> <hr /> <div></div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Talk:Viewer_Authentication_Critique&diff=33687 Talk:Viewer Authentication Critique 2007-09-29T18:36:09Z

<p>Matthew Dowd: /* Cons */</p> <hr /> <div>== Security ==<br /> <br /> === Pros ===<br /> * Viewer does not have to process (and "see") username and password<br /> <br /> === Cons ===<br /> * Viewer still involves running trusted code on the computer and could initiate other attacks e.g.<br /> ** Silently buy L$ and pass onto another account<br /> ** Pass token onto bot, and drop the users connection<br /> * Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.<br /> * Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)<br /> * Too reliant on browser/OS implementations<br /> * Relies on browser security, and uses a mechanism often disabled due to security concerns<br /> <br /> === Alternatives ===<br /> * One time passwords<br /> <br /> == Flexibility ==<br /> <br /> === Pros ===<br /> * Enables username/password authentication to work on third party sites without them having to "see" username and password<br /> <br /> === Cons ===<br /> <br /> === Alternatives ===<br /> * Use this mechanism for websites (including third party) only but not for viewers<br /> * OpenID<br /> * CardSpace<br /> * Identity Metasystem<br /> <br /> == Persistence ==<br /> <br /> === Pros ===<br /> <br /> === Cons ===<br /> * Inconvenient for those with alts<br /> ** Cumbersome to change alts and logon with multiple alts<br /> ** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL<br /> * Inconvenient for those with multiple clients<br /> * Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.<br /> <br /> === Alternatives ===<br /> * Is this really needed? <br /> <br /> <br /> ----<br /> --[[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Talk:Viewer_Authentication_Critique&diff=33686 Talk:Viewer Authentication Critique 2007-09-29T18:33:18Z

<p>Matthew Dowd: /* Alternatives */</p> <hr /> <div>== Security ==<br /> <br /> === Pros ===<br /> * Viewer does not have to process (and "see") username and password<br /> <br /> === Cons ===<br /> * Viewer still involves running trusted code on the computer and could initiate other attacks e.g.<br /> ** Silently buy L$ and pass onto another account<br /> ** Pass token onto bot, and drop the users connection<br /> * Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.<br /> * Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)<br /> * Too reliant on browser/OS implementations<br /> * Relies on browser security, and uses a mechanism often disabled due to security concerns<br /> <br /> === Alternatives ===<br /> * One time passwords<br /> <br /> == Flexibility ==<br /> <br /> === Pros ===<br /> * Enables username/password authentication to work on third party sites without them having to "see" username and password<br /> <br /> === Cons ===<br /> <br /> === Alternatives ===<br /> * Use this mechanism for websites (including third party) only but not for viewers<br /> * OpenID<br /> * CardSpace<br /> * Identity Metasystem<br /> <br /> == Persistence ==<br /> <br /> === Pros ===<br /> <br /> === Cons ===<br /> * Inconvenient for those with alts<br /> ** Cumbersome to change alts and logon with multiple alts<br /> ** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL<br /> * Inconvenient for those with multiple clients<br /> <br /> === Alternatives ===<br /> * Is this really needed? <br /> <br /> <br /> ----<br /> --[[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Talk:Viewer_Authentication_Critique&diff=33685 Talk:Viewer Authentication Critique 2007-09-29T18:33:01Z

<p>Matthew Dowd: /* Flexibility */</p> <hr /> <div>== Security ==<br /> <br /> === Pros ===<br /> * Viewer does not have to process (and "see") username and password<br /> <br /> === Cons ===<br /> * Viewer still involves running trusted code on the computer and could initiate other attacks e.g.<br /> ** Silently buy L$ and pass onto another account<br /> ** Pass token onto bot, and drop the users connection<br /> * Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.<br /> * Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)<br /> * Too reliant on browser/OS implementations<br /> * Relies on browser security, and uses a mechanism often disabled due to security concerns<br /> <br /> === Alternatives ===<br /> <br /> == Flexibility ==<br /> <br /> === Pros ===<br /> * Enables username/password authentication to work on third party sites without them having to "see" username and password<br /> <br /> === Cons ===<br /> <br /> === Alternatives ===<br /> * Use this mechanism for websites (including third party) only but not for viewers<br /> * OpenID<br /> * CardSpace<br /> * Identity Metasystem<br /> <br /> == Persistence ==<br /> <br /> === Pros ===<br /> <br /> === Cons ===<br /> * Inconvenient for those with alts<br /> ** Cumbersome to change alts and logon with multiple alts<br /> ** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL<br /> * Inconvenient for those with multiple clients<br /> <br /> === Alternatives ===<br /> * Is this really needed? <br /> <br /> <br /> ----<br /> --[[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Talk:Viewer_Authentication_Critique&diff=33684 Talk:Viewer Authentication Critique 2007-09-29T18:32:31Z

<p>Matthew Dowd: /* Cons */</p> <hr /> <div>== Security ==<br /> <br /> === Pros ===<br /> * Viewer does not have to process (and "see") username and password<br /> <br /> === Cons ===<br /> * Viewer still involves running trusted code on the computer and could initiate other attacks e.g.<br /> ** Silently buy L$ and pass onto another account<br /> ** Pass token onto bot, and drop the users connection<br /> * Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.<br /> * Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)<br /> * Too reliant on browser/OS implementations<br /> * Relies on browser security, and uses a mechanism often disabled due to security concerns<br /> <br /> === Alternatives ===<br /> <br /> == Flexibility ==<br /> <br /> === Pros ===<br /> * Enables username/password authentication to work on third party sites without them having to "see" username and password<br /> <br /> === Cons ===<br /> <br /> === Alternatives ===<br /> * OpenID<br /> * CardSpace<br /> * Identity Metasystem<br /> <br /> == Persistence ==<br /> <br /> === Pros ===<br /> <br /> === Cons ===<br /> * Inconvenient for those with alts<br /> ** Cumbersome to change alts and logon with multiple alts<br /> ** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL<br /> * Inconvenient for those with multiple clients<br /> <br /> === Alternatives ===<br /> * Is this really needed? <br /> <br /> <br /> ----<br /> --[[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Talk:Viewer_Authentication_Critique&diff=33683 Talk:Viewer Authentication Critique 2007-09-29T18:31:14Z

<p>Matthew Dowd: /* Cons */</p> <hr /> <div>== Security ==<br /> <br /> === Pros ===<br /> * Viewer does not have to process (and "see") username and password<br /> <br /> === Cons ===<br /> * Viewer still involves running trusted code on the computer and could initiate other attacks e.g.<br /> ** Silently buy L$ and pass onto another account<br /> ** Pass token onto bot, and drop the users connection<br /> * Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.<br /> * Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)<br /> <br /> === Alternatives ===<br /> <br /> == Flexibility ==<br /> <br /> === Pros ===<br /> * Enables username/password authentication to work on third party sites without them having to "see" username and password<br /> <br /> === Cons ===<br /> <br /> === Alternatives ===<br /> * OpenID<br /> * CardSpace<br /> * Identity Metasystem<br /> <br /> == Persistence ==<br /> <br /> === Pros ===<br /> <br /> === Cons ===<br /> * Inconvenient for those with alts<br /> ** Cumbersome to change alts and logon with multiple alts<br /> ** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL<br /> * Inconvenient for those with multiple clients<br /> <br /> === Alternatives ===<br /> * Is this really needed? <br /> <br /> <br /> ----<br /> --[[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Talk:Viewer_Authentication_Critique&diff=33682 Talk:Viewer Authentication Critique 2007-09-29T18:28:59Z

<p>Matthew Dowd: /* Cons */</p> <hr /> <div>== Security ==<br /> <br /> === Pros ===<br /> * Viewer does not have to process (and "see") username and password<br /> <br /> === Cons ===<br /> * Viewer still involves running trusted code on the computer and could initiate other attacks e.g.<br /> ** Silently buy L$ and pass onto another account<br /> ** Pass token onto bot, and drop the users connection<br /> * Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.<br /> <br /> === Alternatives ===<br /> <br /> == Flexibility ==<br /> <br /> === Pros ===<br /> * Enables username/password authentication to work on third party sites without them having to "see" username and password<br /> <br /> === Cons ===<br /> <br /> === Alternatives ===<br /> * OpenID<br /> * CardSpace<br /> * Identity Metasystem<br /> <br /> == Persistence ==<br /> <br /> === Pros ===<br /> <br /> === Cons ===<br /> * Inconvenient for those with alts<br /> ** Cumbersome to change alts and logon with multiple alts<br /> ** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL<br /> * Inconvenient for those with multiple clients<br /> <br /> === Alternatives ===<br /> * Is this really needed? <br /> <br /> <br /> ----<br /> --[[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Talk:Viewer_Authentication_Critique&diff=33681 Talk:Viewer Authentication Critique 2007-09-29T18:27:43Z

<p>Matthew Dowd: Initial points</p> <hr /> <div>== Security ==<br /> <br /> === Pros ===<br /> * Viewer does not have to process (and "see") username and password<br /> <br /> === Cons ===<br /> * Viewer still involves running trusted code on the computer and could initiate other attacks e.g.<br /> ** Silently buy L$ and pass onto another account<br /> ** Pass token onto bot, and drop the users connection<br /> * Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.<br /> <br /> === Alternatives ===<br /> <br /> == Flexibility ==<br /> <br /> === Pros ===<br /> * Enables username/password authentication to work on third party sites without them having to "see" username and password<br /> <br /> === Cons ===<br /> <br /> === Alternatives ===<br /> * OpenID<br /> * CardSpace<br /> * Identity Metasystem<br /> <br /> == Persistence ==<br /> <br /> === Pros ===<br /> <br /> === Cons ===<br /> * Inconvenient for those with alts<br /> * Inconvenient for those with multiple clients<br /> <br /> === Alternatives ===<br /> * Is this really needed? <br /> <br /> <br /> ----<br /> --[[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Talk:Viewer_Authentication_Critique&diff=33680 Talk:Viewer Authentication Critique 2007-09-29T18:19:29Z

<p>Matthew Dowd: </p> <hr /> <div><br /> == Security ==<br /> <br /> === Pros ===<br /> <br /> === Cons ===<br /> <br /> === Alternatives ===<br /> <br /> == Flexibility ==<br /> <br /> === Pros ===<br /> <br /> === Cons ===<br /> <br /> === Alternatives ===<br /> <br /> <br /> == Persistence ==<br /> <br /> === Pros ===<br /> <br /> === Cons ===<br /> <br /> === Alternatives ===</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Talk:Viewer_Authentication_Critique&diff=33679 Talk:Viewer Authentication Critique 2007-09-29T18:18:39Z

<p>Matthew Dowd: Initial skeleton</p> <hr /> <div>== Motivations Behind the Proposed Authentication System ==<br /> <br /> <br /> === Security ===<br /> <br /> ==== Pros ====<br /> <br /> ==== Cons ====<br /> <br /> ==== Alternatives ====<br /> <br /> === Flexibility ===<br /> <br /> ==== Pros ====<br /> <br /> ==== Cons ====<br /> <br /> ==== Alternatives ====<br /> <br /> <br /> === Persistence ===<br /> <br /> ==== Pros ====<br /> <br /> ==== Cons ====<br /> <br /> ==== Alternatives ====</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Talk:User_Interface_Improvements&diff=28237 Talk:User Interface Improvements 2007-08-15T18:22:37Z

<p>Matthew Dowd: </p> <hr /> <div>== Problems with current UI (moved from main page) ==<br /> <br /> (These are just gathered from comments on the forums, and ones I've heard from helping new users)<br /> <br /> * User interface is rendered as part of the standard frame render cycle. Thus it does not use recognisable OS-standard components and lags whenever the sim does. Could seperate this to use a general platform-independant kit (wxWidgets?) - although a lot of work!<br /> <br /> * Users confused by a plethora of options that aren't related to their current situation. A user with no interest in content creation still has to deal with a huge number of related options on the pull-down menus. "Build" button on bottom toolbar is the only thing there related to building.<br /> <br /> * Too many valuable items are on the client debug menu. I've seen several Live Help calls in which users are sent to these menus! If they are needed for solving technical problems encountered by regular users, they shouldn't really be part of an "easter egg".<br /> <br /> * Mac OX X complaint: Mac OS X implements right-clicking with Control-click. The Mac OS X SL client implements right-clicking with cmd-click.<br /> <br /> == Considerations for the proposed UI ==<br /> * Users are generally used to Menus so removing the Menu entirely may not be recommended given that it may not be possible to reproduce all the functionality there. However a better reorganisation of the menu, and possibly having the menu contextual and hidable would improve things. May even take some ideas from the MS Office Ribbon bar. {{User|Matthew Dowd}}<br /> * The idea of regions needs careful thought - users could get annoyed if they go to click on something in world which is in a corner of the viewer only for a part of the UI to suddently popup in the way! {{User|Matthew Dowd}}<br /> * Consideration of how these regions would interact with HUD's attached to that position in the viewer needs careful thought to avoid the UI interfering with existing (and future) HUDs. {{User|Matthew Dowd}}</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Bug_triage/2007-10-23&diff=27502 Bug triage/2007-10-23 2007-08-07T08:28:53Z

<p>Matthew Dowd: </p> <hr /> <div>{{Bug triage}}<br /> <br /> Next meeting: 2007-08-07, 10am PDT at {{User|Benjamin Linden}}'s office. See [[Bug triage]] for details.<br /> <br /> == Note to UI Triagers ==<br /> If you find new issues which might be suitable for solution through open source programmers (many UI isses tend to fall into that category) please add them to/link them from {{jira|VWR-1577}} ([[User:Nicholaz Beresford|Nicholaz]] 06:59, 20 July 2007 (PDT))<br /> <br /> == Bugfix Patches ==<br /> *{{jira|VWR-315}} - 16 votes - Script loading twice.<br /> *{{jira|VWR-333}} - 38 votes - Missing Gesture problem. <br /> **{{jira|VWR-1944}} - 1 vote - can be closed as dup of VWR-333? <br /> *{{jira|VWR-423}} - 8 votes - Selecting group charter text causes Apply/Ignore/Cancel popup even if the text wasn't changed. vwr423.patch file will solve these three as well. <br /> **{{jira|VWR-1187}} - 7 votes - is resolved on jira, but issue still exists in latest source. Since Torley closed it I'm hesitant to reopen.<br /> **{{jira|VWR-1627}} - 2 votes - Classified metrics do not accumulate over the life of the ad<br /> **{{jira|VWR-1667}} - 3 votes - Profile "My Notes" tab - contents replaced by "Loading..." if you close it before it displays the actual<br /> * {{jira|VWR-2036}} - 3 Votes - Fixes a long standing UI inconsistancy, Build Tools window position not persistant.<br /> <br /> == Feature Request Patches == <br /> * {{jira|VWR-1827}} - Votes: 2 - Inventory double click: Linden provided attachments -> wear - {{User|Nicholaz Beresford}}<br /> ** This is where we left off when the grid shutdown due to database issues<br /> * {{jira|VWR-1647}} - Votes: 3 - "Show end of last IM conversation" in Preferences/Communication automatically remains checked after OK-ing unchecked - {{User|Eon Peterson}}<br /> * {{jira|VWR-546}} - Votes: 1 - Using inspect interfers with mouse usage. - {{User|Ryozu Kojima}}<br /> * {{jira|MISC-82}} - Votes: 28 - New Feature -> UI -> IM -> Teleport (other person) Button. - {{User|Paul Churchill}}<br /> * {{jira|VWR-1880}} - Votes: 4 - Modify "Ctrl-F" to call Search/Replace Dialog when invoked inside Script Window - {{User|Paul Churchill}}<br /> * {{jira|VWR-445}} - Votes: 11 - A minimize button on the inventory list - {{User|Paul Churchill}}<br /> * {{jira|VWR-1917}} - Votes: 5 - Have Friends and Groups display in a seperate window when accessed via menus. {{User|Matthew Dowd}}<br /> <br /> == Other Bug Reports ==<br /> <br /> * {{jira|VWR-1713}} - Votes: 1 - Object owner name truncated in Properties window - {{User|Benja Kepler}}<br /> * {{jira|VWR-1281}} - Votes: 1 - text selecting/hilighting rendering problem - {{User|Lex Neva}}<br /> * {{jira|VWR-1724}} - Votes: 1 - HUD zoom snaps back after selecting another HUD object - {{User|Celierra Darling}}<br /> * {{jira|VWR-1730}} - Votes: 1 - After accepting texture or notecard, Keep/Discard options display again - {{User|Celierra Darling}}<br /> * {{jira|VWR-1921}} - Votes: 9 - No Login possible after crash / crash report - {{User|kruemmelmonster bury}}<br /> * {{jira|VWR-1735}} - Votes: 8 - Directly interacting with a muted resident should unmute them - {{User|able whitman}}<br /> * {{jira|VWR-787}} - Votes: 7 - About Land - Objects: Temp objects are owned by everybody and returned to everybody. - {{User|Sascha Vandyke}}<br /> * {{jira|VWR-1549}} - Votes: 6 - Simple fix for the communicate window to move Friends and Groups tabs from left to top - {{User|Matthew Dowd}}<br /> * {{jira|VWR-1405}} - Votes: 5 - llMapDestination does not work as designed for OS X/Intel viewers - {{User|Hugo Dalgleish}}<br /> * {{jira|VWR-1567}} - Votes: 4 - Change the default item name for "snapshot to inventory" to something more usefull than "snapshot" - {{User|kerunix Flan}}<br /> * {{jira|VWR-1286}} - Votes: 3 - alt-zooming on hollow face mishandled - {{User|Lex Neva}}<br /> * {{jira|VWR-749}} - Votes: 3 - Bandwidth indicator: Kbps, should not have capital k - {{User|Daedalus Young}}<br /> * {{jira|VWR-1922}} - Votes: 3 - Nearby Scripted Objects Glow Red While Editing - {{User|Benja Kepler}}<br /> * {{jira|VWR-1231}} - Votes: 2 - Voice: Can Alt-arrow in, but not out of the Communicate window's "My Friends" tab - {{User|Torley Linden}}<br /> * {{jira|VWR-977}} - Votes: 2 - Alt-zoom on anything results in uncontrollable spinning camera - {{User|gonta maltz}}<br /> * {{jira|VWR-1945}} - Votes: 2 - toolbox floater displays window elements incorrectly when minimized then moved. - {{User|Ryozu Kojima}}<br /> * {{jira|VWR-1754}} - Votes: 2 - Cosmetic issue: unclutter notification/confirmation about items given - {{User|Nicholaz Beresford}}<br /> * {{jira|VWR-1724}} - Votes: 2 - HUD zoom snaps back after selecting another HUD object - {{User|Celierra Darling}}<br /> * {{jira|VWR-1095}} - Votes: 2 - Failed uploads prevent upload attempts - {{User|Haravikk Mistral}}<br /> * {{jira|VWR-749}} - Votes: 3 - Bandwidth indicator: Kbps, should not have capital k - {{User|Paul Churchill}}<br /> <br /> == Feature Request ==<br /> <br /> == Pre-meeting activity ==<br /> <br /> Some issues will be resolved in the course of building this agenda. Rather than deleting them from the proposed agenda, move the issue and associated discussion into the appropriate section below.<br /> <br /> === Imported ===<br /> <br /> === Resolved ===<br /> * {{jira|VWR-1713}} - Votes: 1 - Object owner name truncated in Properties window - {{User|Benja Kepler}} - Moved to resolved {{User|Paul Churchill}}<br /> <br /> === Edited ===</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Bug_triage/2007-10-23&diff=27501 Bug triage/2007-10-23 2007-08-07T08:13:31Z

<p>Matthew Dowd: </p> <hr /> <div>{{Bug triage}}<br /> <br /> Next meeting: 2007-08-07, 10am PDT at {{User|Benjamin Linden}}'s office. See [[Bug triage]] for details.<br /> <br /> == Note to UI Triagers ==<br /> If you find new issues which might be suitable for solution through open source programmers (many UI isses tend to fall into that category) please add them to/link them from {{jira|VWR-1577}} ([[User:Nicholaz Beresford|Nicholaz]] 06:59, 20 July 2007 (PDT))<br /> <br /> == Bugfix Patches ==<br /> *{{jira|VWR-315}} - 16 votes - Script loading twice.<br /> *{{jira|VWR-333}} - 38 votes - Missing Gesture problem. <br /> **{{jira|VWR-1944}} - 1 vote - can be closed as dup of VWR-333? <br /> *{{jira|VWR-423}} - 8 votes - Selecting group charter text causes Apply/Ignore/Cancel popup even if the text wasn't changed. vwr423.patch file will solve these three as well. <br /> **{{jira|VWR-1187}} - 7 votes - is resolved on jira, but issue still exists in latest source. Since Torley closed it I'm hesitant to reopen.<br /> **{{jira|VWR-1627}} - 2 votes - Classified metrics do not accumulate over the life of the ad<br /> **{{jira|VWR-1667}} - 3 votes - Profile "My Notes" tab - contents replaced by "Loading..." if you close it before it displays the actual<br /> * {{jira|VWR-2036}} - 3 Votes - Fixes a long standing UI inconsistancy, Build Tools window position not persistant.<br /> * {{jira|VWR-1917}} - 5 Votes - Have Friends and Groups display in a seperate window when accessed via menus.<br /> <br /> == Feature Request Patches == <br /> * {{jira|VWR-1827}} - Votes: 2 - Inventory double click: Linden provided attachments -> wear - {{User|Nicholaz Beresford}}<br /> ** This is where we left off when the grid shutdown due to database issues<br /> * {{jira|VWR-1647}} - Votes: 3 - "Show end of last IM conversation" in Preferences/Communication automatically remains checked after OK-ing unchecked - {{User|Eon Peterson}}<br /> * {{jira|VWR-546}} - Votes: 1 - Using inspect interfers with mouse usage. - {{User|Ryozu Kojima}}<br /> * {{jira|MISC-82}} - Votes: 28 - New Feature -> UI -> IM -> Teleport (other person) Button. - {{User|Paul Churchill}}<br /> * {{jira|VWR-1880}} - Votes: 4 - Modify "Ctrl-F" to call Search/Replace Dialog when invoked inside Script Window - {{User|Paul Churchill}}<br /> * {{jira|VWR-445}} - Votes: 11 - A minimize button on the inventory list - {{User|Paul Churchill}}<br /> <br /> == Other Bug Reports ==<br /> <br /> * {{jira|VWR-1713}} - Votes: 1 - Object owner name truncated in Properties window - {{User|Benja Kepler}}<br /> * {{jira|VWR-1281}} - Votes: 1 - text selecting/hilighting rendering problem - {{User|Lex Neva}}<br /> * {{jira|VWR-1724}} - Votes: 1 - HUD zoom snaps back after selecting another HUD object - {{User|Celierra Darling}}<br /> * {{jira|VWR-1730}} - Votes: 1 - After accepting texture or notecard, Keep/Discard options display again - {{User|Celierra Darling}}<br /> * {{jira|VWR-1921}} - Votes: 9 - No Login possible after crash / crash report - {{User|kruemmelmonster bury}}<br /> * {{jira|VWR-1735}} - Votes: 8 - Directly interacting with a muted resident should unmute them - {{User|able whitman}}<br /> * {{jira|VWR-787}} - Votes: 7 - About Land - Objects: Temp objects are owned by everybody and returned to everybody. - {{User|Sascha Vandyke}}<br /> * {{jira|VWR-1549}} - Votes: 6 - Simple fix for the communicate window to move Friends and Groups tabs from left to top - {{User|Matthew Dowd}}<br /> * {{jira|VWR-1405}} - Votes: 5 - llMapDestination does not work as designed for OS X/Intel viewers - {{User|Hugo Dalgleish}}<br /> * {{jira|VWR-1567}} - Votes: 4 - Change the default item name for "snapshot to inventory" to something more usefull than "snapshot" - {{User|kerunix Flan}}<br /> * {{jira|VWR-1286}} - Votes: 3 - alt-zooming on hollow face mishandled - {{User|Lex Neva}}<br /> * {{jira|VWR-749}} - Votes: 3 - Bandwidth indicator: Kbps, should not have capital k - {{User|Daedalus Young}}<br /> * {{jira|VWR-1922}} - Votes: 3 - Nearby Scripted Objects Glow Red While Editing - {{User|Benja Kepler}}<br /> * {{jira|VWR-1231}} - Votes: 2 - Voice: Can Alt-arrow in, but not out of the Communicate window's "My Friends" tab - {{User|Torley Linden}}<br /> * {{jira|VWR-977}} - Votes: 2 - Alt-zoom on anything results in uncontrollable spinning camera - {{User|gonta maltz}}<br /> * {{jira|VWR-1945}} - Votes: 2 - toolbox floater displays window elements incorrectly when minimized then moved. - {{User|Ryozu Kojima}}<br /> * {{jira|VWR-1754}} - Votes: 2 - Cosmetic issue: unclutter notification/confirmation about items given - {{User|Nicholaz Beresford}}<br /> * {{jira|VWR-1724}} - Votes: 2 - HUD zoom snaps back after selecting another HUD object - {{User|Celierra Darling}}<br /> * {{jira|VWR-1095}} - Votes: 2 - Failed uploads prevent upload attempts - {{User|Haravikk Mistral}}<br /> * {{jira|VWR-749}} - Votes: 3 - Bandwidth indicator: Kbps, should not have capital k - {{User|Paul Churchill}}<br /> <br /> == Feature Request ==<br /> <br /> == Pre-meeting activity ==<br /> <br /> Some issues will be resolved in the course of building this agenda. Rather than deleting them from the proposed agenda, move the issue and associated discussion into the appropriate section below.<br /> <br /> === Imported ===<br /> <br /> === Resolved ===<br /> * {{jira|VWR-1713}} - Votes: 1 - Object owner name truncated in Properties window - {{User|Benja Kepler}} - Moved to resolved {{User|Paul Churchill}}<br /> <br /> === Edited ===</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Bug_triage/2007-10-23&diff=27500 Bug triage/2007-10-23 2007-08-07T08:12:26Z

<p>Matthew Dowd: </p> <hr /> <div>{{Bug triage}}<br /> <br /> Next meeting: 2007-08-07, 10am PDT at {{User|Benjamin Linden}}'s office. See [[Bug triage]] for details.<br /> <br /> == Note to UI Triagers ==<br /> If you find new issues which might be suitable for solution through open source programmers (many UI isses tend to fall into that category) please add them to/link them from {{jira|VWR-1577}} ([[User:Nicholaz Beresford|Nicholaz]] 06:59, 20 July 2007 (PDT))<br /> <br /> == Bugfix Patches ==<br /> *{{jira|VWR-315}} - 16 votes - Script loading twice.<br /> *{{jira|VWR-333}} - 38 votes - Missing Gesture problem. <br /> **{{jira|VWR-1944}} - 1 vote - can be closed as dup of VWR-333? <br /> *{{jira|VWR-423}} - 8 votes - Selecting group charter text causes Apply/Ignore/Cancel popup even if the text wasn't changed. vwr423.patch file will solve these three as well. <br /> **{{jira|VWR-1187}} - 7 votes - is resolved on jira, but issue still exists in latest source. Since Torley closed it I'm hesitant to reopen.<br /> **{{jira|VWR-1627}} - 2 votes - Classified metrics do not accumulate over the life of the ad<br /> **{{jira|VWR-1667}} - 3 votes - Profile "My Notes" tab - contents replaced by "Loading..." if you close it before it displays the actual<br /> * {{jira|VWR-2036}} - 3 Votes - Fixes a long standing UI inconsistancy, Build Tools window position not persistant.<br /> * {{jira}|VWR-1917}} - 5 Votes - Have Friends and Groups display in a seperate window when accessed via menus.<br /> <br /> == Feature Request Patches == <br /> * {{jira|VWR-1827}} - Votes: 2 - Inventory double click: Linden provided attachments -> wear - {{User|Nicholaz Beresford}}<br /> ** This is where we left off when the grid shutdown due to database issues<br /> * {{jira|VWR-1647}} - Votes: 3 - "Show end of last IM conversation" in Preferences/Communication automatically remains checked after OK-ing unchecked - {{User|Eon Peterson}}<br /> * {{jira|VWR-546}} - Votes: 1 - Using inspect interfers with mouse usage. - {{User|Ryozu Kojima}}<br /> * {{jira|MISC-82}} - Votes: 28 - New Feature -> UI -> IM -> Teleport (other person) Button. - {{User|Paul Churchill}}<br /> * {{jira|VWR-1880}} - Votes: 4 - Modify "Ctrl-F" to call Search/Replace Dialog when invoked inside Script Window - {{User|Paul Churchill}}<br /> * {{jira|VWR-445}} - Votes: 11 - A minimize button on the inventory list - {{User|Paul Churchill}}<br /> <br /> == Other Bug Reports ==<br /> <br /> * {{jira|VWR-1713}} - Votes: 1 - Object owner name truncated in Properties window - {{User|Benja Kepler}}<br /> * {{jira|VWR-1281}} - Votes: 1 - text selecting/hilighting rendering problem - {{User|Lex Neva}}<br /> * {{jira|VWR-1724}} - Votes: 1 - HUD zoom snaps back after selecting another HUD object - {{User|Celierra Darling}}<br /> * {{jira|VWR-1730}} - Votes: 1 - After accepting texture or notecard, Keep/Discard options display again - {{User|Celierra Darling}}<br /> * {{jira|VWR-1921}} - Votes: 9 - No Login possible after crash / crash report - {{User|kruemmelmonster bury}}<br /> * {{jira|VWR-1735}} - Votes: 8 - Directly interacting with a muted resident should unmute them - {{User|able whitman}}<br /> * {{jira|VWR-787}} - Votes: 7 - About Land - Objects: Temp objects are owned by everybody and returned to everybody. - {{User|Sascha Vandyke}}<br /> * {{jira|VWR-1549}} - Votes: 6 - Simple fix for the communicate window to move Friends and Groups tabs from left to top - {{User|Matthew Dowd}}<br /> * {{jira|VWR-1405}} - Votes: 5 - llMapDestination does not work as designed for OS X/Intel viewers - {{User|Hugo Dalgleish}}<br /> * {{jira|VWR-1567}} - Votes: 4 - Change the default item name for "snapshot to inventory" to something more usefull than "snapshot" - {{User|kerunix Flan}}<br /> * {{jira|VWR-1286}} - Votes: 3 - alt-zooming on hollow face mishandled - {{User|Lex Neva}}<br /> * {{jira|VWR-749}} - Votes: 3 - Bandwidth indicator: Kbps, should not have capital k - {{User|Daedalus Young}}<br /> * {{jira|VWR-1922}} - Votes: 3 - Nearby Scripted Objects Glow Red While Editing - {{User|Benja Kepler}}<br /> * {{jira|VWR-1231}} - Votes: 2 - Voice: Can Alt-arrow in, but not out of the Communicate window's "My Friends" tab - {{User|Torley Linden}}<br /> * {{jira|VWR-977}} - Votes: 2 - Alt-zoom on anything results in uncontrollable spinning camera - {{User|gonta maltz}}<br /> * {{jira|VWR-1945}} - Votes: 2 - toolbox floater displays window elements incorrectly when minimized then moved. - {{User|Ryozu Kojima}}<br /> * {{jira|VWR-1754}} - Votes: 2 - Cosmetic issue: unclutter notification/confirmation about items given - {{User|Nicholaz Beresford}}<br /> * {{jira|VWR-1724}} - Votes: 2 - HUD zoom snaps back after selecting another HUD object - {{User|Celierra Darling}}<br /> * {{jira|VWR-1095}} - Votes: 2 - Failed uploads prevent upload attempts - {{User|Haravikk Mistral}}<br /> * {{jira|VWR-749}} - Votes: 3 - Bandwidth indicator: Kbps, should not have capital k - {{User|Paul Churchill}}<br /> <br /> == Feature Request ==<br /> <br /> == Pre-meeting activity ==<br /> <br /> Some issues will be resolved in the course of building this agenda. Rather than deleting them from the proposed agenda, move the issue and associated discussion into the appropriate section below.<br /> <br /> === Imported ===<br /> <br /> === Resolved ===<br /> * {{jira|VWR-1713}} - Votes: 1 - Object owner name truncated in Properties window - {{User|Benja Kepler}} - Moved to resolved {{User|Paul Churchill}}<br /> <br /> === Edited ===</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=Defines&diff=18497 Defines 2007-04-26T12:21:42Z

<p>Matthew Dowd: Added LL_RELEASE_FOR_DOWNLOAD information</p> <hr /> <div>==Debug Messages==<br /> <br /> _DEBUG - Turns on all debug Messages (set by compiler).<br /> <br /> RELEASE_SHOW_DEBUG, RELEASE_SHOW_WARN, RELEASE_SHOW_INFO, RELEASE_SHOW_ASSERT - turns on the appropriate category of debug messages even if it's a Release build.<br /> <br /> ==Operating system and platform settings==<br /> <br /> LL_WINDOWS - Enables Windows specific code.<br /> <br /> LL_LINUX - Enables Linux specific code.<br /> <br /> LL_DARWIN - Enables mac os x specific code.<br /> <br /> LL_LITTLE_ENDIAN, LL_BIG_ENDIAN - Notifies the build that the underlying machine stores multi-byte values in particular orders.<br /> <br /> ==Viewer Version==<br /> <br /> LL_RELEASE_FOR_DOWNLOAD - This is set for the compilation of the general released viewers from Linden Labs. It appears to remove features which were being tested in the Firstlook viewers. In particular, setting this appears removes to remove the support for dynamic mirrors.<br /> <br /> _CORY_TESTING - Enables a few menu items in the server debug menu that allow you to force import/export objects, code is buggy and deprecated. (Could be fixed to work again, pretty easy to enable export(fix file i/o functions)(oft crashes viewer). Import is fairly dead, I got it to import prims, but not textures.)<br /> <br /> HACKED_GODLIKE_VIEWER - Makes client '''always''' treat user as a Linden, even if they are not.<br /> <br /> TOGGLE_HACKED_GODLIKE_VIEWER - Enables the ''hacked Godmode'' option on the Client debug menu, which allows the user to be treated by the client as if they were a Linden even if they are not.<br /> <br /> ==Unknown==<br /> <br /> DEBUG_VOLUME<br /> DEBUG_MISS<br /> CRC_CHECK<br /> LL_DEBUG_PUMPS<br /> _PATCH_SIZE_16_AND_32_ONLY<br /> SABINRIG<br /> DEBUG_UPDATE_TYPE<br /> IGNORE_DEAD<br /> ORPHAN_SPAM<br /> IDC_STATIC<br /> APSTUDIO_INVOKED<br /> DEBUG_AGP<br /> CTYPE_WORKAROUND<br /> LSL_INCLUDE_DEBUG_INFO - Include debug information in scripts?<br /> EMERGENCY_DEBUG_PRINTOUTS<br /> EMIT_CIL_ASSEMBLER<br /> GL_GLEXT_FUNCTION_POINTERS<br /> TIME_THROTTLE_MESSAGES<br /> kAUDIO_ENABLE_WIND<br /> SIGBUS<br /> SIGSYS<br /> DIFF_INVENTORY_FILES<br /> MORPH_PANEL_SHOW_SPINNERS<br /> LL_RELEASE_FOR_DOWNLOAD<br /> LL_CHECK_FOR_FINITE<br /> WCOREDUMP - On Non-Windows, function to work out if a child thread dumped core or not<br /> TEST_HARNESS<br /> LL_DARWIN<br /> PROCESSOR_FREQUENCY_MEASURE_AVAILABLE<br /> HAVE_NETINET_IN_H<br /> HAVE_SA_LEN<br /> FT_FREETYPE_H<br /> SIOCGIFHWADDR<br /> SIOCGENADDR</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=SL_Certification/List_of_Resident_Participants&diff=18443 SL Certification/List of Resident Participants 2007-04-25T21:08:16Z

<p>Matthew Dowd: </p> <hr /> <div>[[Category:Certification]]<br /> Add yourself to the bottom of this list using the following Wiki code:<br /> <code><pre><nowiki>* ~~~</nowiki></pre></code><br /> <br /> * [[User:Ceera Murakami|Ceera Murakami]] (Fox and Ground Construction Company) Texture Artist<br /> * [[User:Elle74 Zaftig|Elle74 Zaftig]] (Bellissima!/Shoppe74) build/model/textures<br /> * [[User:Keiki Lemieux|Keiki Lemieux]] (HUDDLES Games & Gadgets) Building, Scripting, Animations, Textures<br /> * [[User:Tre Giles|Tre Giles]] (GiTech/Action Village Paintball) Building, Scripting, Animation, Photography<br /> * [[User:Alexander Regent|Alexander Regent]] (MageTech LLC) Scripting, website integration, cellphone integration, in-world building<br /> * [[User:Sitearm Madonna|Sitearm Madonna]] (Siterma): Sim Scale Project Planning and Management; Structural Builds and Simulator Performance Management; Social Builds and Community Growth Management; Modeling - Architecture, Terraforming, Waterscaping, Landscaping, Soundscaping<br /> * [[User:Hugo Dalgleish|Hugo Dalgleish]]<br /> * [[User:Kenn Nilsson|Kenn Nilsson]] (NDE)<br /> * [[User:Ravanne Sullivan|Ravanne Sullivan]] (Ravanne's Dance Poles and Animations) Animations and Scripting<br /> * [[User:Fox Diller|Fox Diller]] (Crystal Studio/Magrathean Technologies) Anything Second Life.<br /> * [[User:MSo Lambert|MSo Lambert]]<br /> * [[User:Rael Delcon|Rael Delcon]]<br /> * [[User:Dytska Vieria|Dytska Vieria]] (residential design/builds)<br /> * [[User:Skye McArdle|Skye McArdle]] - Modeling, Animation, Textures, AV Customization<br /> * [[User:Eladon Galsworthy|Eladon Galsworthy]] (PondLife - building and scripting)<br /> * [[User:Oz Spade|Oz Spade]]<br /> * [[User:Max Case|Max Case]]<br /> * [[User:Newfie Pendragon|Newfie Pendragon]] (Reality Check, LSL Scripting)<br /> * [[User:Gigs Taggart|Gigs Taggart]]<br /> * [[User:Peekay Semyorka|Peekay Semyorka]]<br /> * [[User:Osgeld Barmy|Osgeld Barmy]] (biulding textures lsl)<br /> * [[User:Nargus Asturias|Nargus Asturias]] (Avatar building, animations, scripts)<br /> * [[User:ForestMist Skjellerup|ForestMist Skjellerup]]<br /> * [[User:Rraven Moonlight|Rraven Moonlight]] (Terraforming Raw files, Texture developer, Large Scale Architectural Builds)<br /> * [[User:Xylo Quisling|Xylo Quisling]]<br /> * [[User:Thunderclap Morgridge|Thunderclap Morgridge]] (Texture artist, and nascent builder)<br /> * [[User:Hiro Pendragon|Hiro Pendragon]] (CTO, Infinite Vision Media) LSL scripting, modeling<br /> * [[User:Ethan Therian|Ethan Therian]] (Creative Director, Infinite Vision Media) modeling, texturing<br /> * [[User:Ciemaar Flintoff|Ciemaar Flintoff]] (associate, Infinite Vision Media) lsl scripting, web-to-SL-to-web scripting<br /> * [[User:Nimrodina Wayne|Nimrodina Wayne]] (build, animate, machinima)<br /> * [[User:Lias Leandros|Lias Leandros]] (VooDoo Corp.)Sim Scale Project Planning and Management; Social Builds and Community Growth Management<br /> * [[User:Erin Talamasca|Erin Talamasca]]<br /> * [[User:Till Stirling|Till Stirling]] (Scripter, Builder, Consultant)<br /> * [[User:Kri Ayakashi|Kri Ayakashi]] (AyakashiTEC) - LSL Scripting, Web2.0 integration, distributed programming (C/C++/C#, Python), in-world building, consultancy<br /> * [[User:Alison Wheels|Alison Wheels]] ([http://secondlife.creative.org.uk/ Creative Organisation]) Scripting, FL/SL Integration issues, construction, terraforming, design<br /> * [[User:FlipperPA Peregrine|FlipperPA Peregrine]] (Peregrine Salon/ESC) - LSL Scripting, Web integration, lots of other stuff. Creator of SLBoutique.com and SLTrivia.com.<br /> * [[User:Strife Onizuka|Strife Onizuka]] (Scripter, Builder, Consultant)<br /> * [[User:Porky Gorky|Porky Gorky]] - Hydro Homes : Prefabricated & customised building & architectural design.<br /> * [[User:Bru Yang|Bru Yang]]<br /> * [[User:Dirk Talamasca|Dirk Talamasca]] (Building, Custom Textures, Land/Estate Management. Internet Abuse Remediation, Sim Scale Layout, Planning and Development)<br /> * [[User:Aimee Weber|Aimee Weber]]<br /> * [[User:Banana Stein|Banana Stein]] (SL Brand) Builder, Textures, Sim Scale Project<br /> * [[User:Linnian Sugar|Linnian Sugar]] (*Lollipop Shop owner* Builder, Clothing and textures, scripting, animations)<br /> * [[User:Siobhan Taylor|Siobhan Taylor]] Building, Scripting.<br /> * [[User:Taco Rubio|Taco Rubio]] (Media Management) <br /> * [[User:RobbyRacoon Olmstead|RobbyRacoon Olmstead]] (Scripting, Building, C:SI Developer)<br /> * [[User:Dnali Anabuki|Dnali Anabuki]] (Structure,Process,Organizing of Cert) Satorifilmservices.com<br /> * [[User:Detect Surface|Detect Surface]] - (**D&D Creative Lab/The Brain Game/City of Abaddon** Building, Texturing, Skins, Texture-Mapping/Zoning, AV Design, Clothing, Sim Design and Construction, Architecture, Weapons, Vehicles, Furniture, Animation, Graphic Design, Artist and Pretty Flower Arranging.)<br /> * [[User:Meade Paravane|Meade Paravane]] (Script monkey, Builder)<br /> * [[User:Orange Montagne|Orange Montagne]]<br /> * [[User:Joshua Nightshade|Joshua Nightshade]] (Builder, avatar design - primarily smaller-than-normal avatars)<br /> * [[User:Zorena Deckard|Zorena Deckard]] (builder,textures,modeling)<br /> * [[User:Bartiloux Desmoulins|Bartiloux Desmoulins]] (Scripting, modeling and animations)<br /> * [[User:Ravenelle Zugzwang|Ravenelle Zugzwang]]<br /> * [[User:Little Penguin|Little Penguin]] Building, Scripting<br /> * [[User:Pol Tabla|Pol Tabla]]<br /> * [[User:Jade Opel|Jade Opel]] (Brides & Blooms by Jade Opel) Building, terra-forming, textures, particles, modeling<br /> * [[User:Auron Havercamp|Auron Havercamp]] ([http://www.kenthavercamp.com/ Kent-Havercamp Enterprises, Ltd.]) - Scripting, Web Interaction, Data Storage<br /> * [[User:Schuyler Kent|Schuyler Kent]] ([http://www.kenthavercamp.com/ Kent-Havercamp Enterprises, Ltd.]) - Building, Scripting, Consulting<br /> * [[User:Vincent Nacon|Vincent Nacon]] (all above)<br /> * [[User:Aradia Aridian|Aradia Aridian]] (Modeling, Land/Estate Management, Business Management, Marketing to the Virtual Customer)<br /> * [[User:Scarlet Singer|Scarlet Singer]] (Textures/Graphics) <3<br /> * [[User:Will Webb|Will Webb]]<br /> * [[Cocoanut Koala]] (Coco's Cottages) Builder<br /> * Illya Sullivan<br /> *[[User:Frans Charming|Frans Charming]] ([http://www.thevesuviusgroup.com The Vesuvius Group])Project Planning and Management, 3D Modeling/Building, Scripting, Texturing, etc<br /> * [[User:Nomasha Syaka|Nomasha Syaka]] build/model/textures<br /> *[[User:Rhiannon Chatnoir|Rhiannon Chatnoir]] ([http://www.thevesuviusgroup.com The Vesuvius Group])Creative Director of The Vesuvius Group (Project Management, Planning, Textures, Terraforming, machinima), also SL and web dev for Global Kids, Inc. and a RL professional graphic designer.<br /> * [[User:Shockwave Yareach|Shockwave Yareach]] (Textures/Scripting/Building)<br /> * [[User:Rebel Television|Rebel Television]] ([http://www.slexchange.com/modules.php?name=Marketplace&file=item&ItemID=147428 Airfoil]) Scripting, Animation, Vehicles, Avatars, Building, In-world RSS Feed Displays<br /> * [[User:Storm Thunders|Storm Thunders]]<br /> * [[Rocky Merosi]] (Objects, Furnishings/Interior Design, Weapons and Vehicles, Asset Managment, Movement, Attachments, Setting Properties, Communications)<br /> *[[User:Moriz Gupte|Moriz Gupte]] ([http://www.play2train.org Play2Train])Producer, Scripter, Builder SL educator<br /> *([http://homepage.mac.com/salazarjack/ Salazar Jack]) - Kahruvel Design - Environments, Landscapes, Forest Preservation, Terraforming, Architecture, Archeological Restoration, Furnishings/Interior Design, Objects, Textures<br /> *[[User:Raven Pennyfeather|Raven Pennyfeather]] Owner/operator for House of RFyre LLC,clothing and avatar development, textures building, business analyst, gragphic design.<br /> *[[User:Thraxis Epsilon|Thraxis Epsilon]] (Resume in Profile)<br /> *[[User:Angelica Puff|Angelica Puff]] (Communications, External <-> Inworld data, Asset Management)<br /> *[[User:Jeff Kelley|Jeff Kelley]] (Communications, Networking, Display, Data storage & access)<br /> *[[User:Ace Albion|Ace Albion]] (Ace's Spaces) prefab builder<br /> *[[User:SunShine Kukulcan|SunShine Kukulcan]] (Mercury Dev Studios - Music and Media Services, Sim planning)<br /> *[[User:Klink Epsilon|Klink Epsilon]] (Mercury Dev Studios - Builder, Custom Textures, Sim Design and planning, Media Services)<br /> *[[User:Parker McTeague|Parker McTeague]] (BLIP) building, textures<br /> *[[Demian Caldera]] Architecture, Furnishings/Interior Design, Objects, Landscaping, Terra Forming, Event Organizing, Event Set Building.<br /> *[[User:Rainbow Drake|Rainbow Drake]] Director of Education - [http://raindancer.ca/NCI New Citizens Incorporated]<br /> *[[User:Kamael Xevious|Kamael Xevious]] - Radio Babylonia/Batak Island Traders - Architecture, Furnishings and Interior Design, Media, Community Development and Region Construction, Education.<br /> *[[User:Pipe Hesse|Pipe Hesse]] Scripting, Building<br /> * [[User:Abramelin Wolfe|Abramelin Wolfe]] (Abramelin Studios Ltd / Abranimations) script/build/texture/animation/mocap/web integration<br /> * [[User:katykiwi Moonflower|katykiwi Moonflower]] interior design/furnishings/building/texturing/terraforming<br /> *[[User:Jade Jensen|Jade Jensen]] (Jaded Visions) Clothing Design, Avatar Creation/Design, Texturing, Graphics Design<br /> *[[Darien Caldwell]] Builder/Scripter<br /> *[[User:Azrazael Dhara|Azrazael Dhara]] Building, Terraforming, Sim Design, Landscaping, Instructing, Photography<br /> *[[User:Andreas Isachenko|Andreas Isachenko]] Building, Scripting, DB access<br /> *[[User:Jason Keegan|Jason Keegan]] (K-tech) Scripting<br /> *[[User:Gaius Goodliffe|Gaius Goodliffe]] (Second Skies) Vehicles, scripting, back-end server/website integration<br /> *[[User:Pericat Aquitaine|Pericat Aquitaine]] (Elf Harbour Boatyard) Vehicles, scripting, terraforming, general building<br /> *[[User:Karsten Rutledge|Karsten Rutledge]] (Play2Train/K.R. Engineering) Scripting, building.<br /> *[[User:Bubba Biberman|Bubba Biberman]] Building, textures, machinima<br /> *[[User:Kerian Bunin|Kerian Bunin]] (uʍop əpı̣sdn) Building, Scripting, Estate Management <br /> *[[User:Tsukasa Keiko|Tsukasa Keiko]] Building, Scripting<br /> *[[User:Morph Wollongong|Morph Wollongong]] Gadgets, Scripting<br /> *[[User:Ordinal Malaprop|Ordinal Malaprop]] - scripting, some building<br /> *[[User:Donnagh McDonnagh|Donnagh McDonnagh]] - Undergraduate education (School of Communication), machinima, scripting, general building, avatar skins/clothes, 3d textures, animation, web integration, vehicles, huds, event management, orientation, inworld collaboration<br /> *[[User:Able Whitman|Able Whitman]] - scripting, some building<br /> *[[User:Adri Saarinen|Adri Saarinen]] - ([http://www.metaversatility.com Metaversatility]) scripting, building, presence development<br /> *[[User:Curious Rousselot|Curious Rousselot]] - Scripting, Building<br /> *[[User:otakup0pe Neumann|otakup0pe Neumann]] - Pleiades Consulting & libsecondlife. Rich Educational Content, tech integration, libsl powered services<br /> *[[User:Damek Tretiak|Damek Tretiak]] - ([http://www.tretiakmedia.com Tretiak Media])/([http://www.slquery.com SLQuery.com]) scripting, building, project management<br /> * [[User:Jacques Groshomme|Jacques Groshomme]] - Building/Scripting<br /> * [[User:Iris Bourdeille|Iris Bourdeille]] - Building/Scripting/Texturing/Animation<br /> * [[User:Fallon Winnfield|Fallon Winnfield]] - ([http://www.centric.com Centric])/([http://www.secondtalk.com Second Talk]) - Business development, building, scripting<br /> * [[User:Adam Rakosi|Adam Rakosi]] - ([http://www.centric.com Centric])/([http://www.secondtalk.com Second Talk]) - Building/Scripting<br /> * [[User:Neko Longduk|Neko Longduk]] - ([http://www.centric.com Centric])/([http://www.secondtalk.com Second Talk]) - Business Development, scripting<br /> * [[User:Weasel Gough|Weasel Gough]] - ([http://www.centric.com Centric])/([http://www.secondtalk.com Second Talk]) - Building/Scripting/Texturing/Animation<br /> * [[User:Chime Bellman|Chime Bellman]] strategy/build/model/promote<br /> *[[User:Sage Duncan|Sage Duncan]] - animation/machinima/motion/media management/live performance<br /> * [[User:Economic Mip|Economic Mip]] -imagine/dream<br /> * [[User:Talarus Luan|Talarus Luan]] - Archaean Designs / Council of Wyrms - Scripting, Building, Consulting<br /> * [[User:Dustin Widget|Dustin Widget]] Builder/Scripter/Mentor/Lots More<br /> * [[User:Tab Scott|Tab Scott]] - Terry Beaubois, Montana State University - College of Art & Architecture - Art, Music, Architecture, Film - Sustainable Community Design<br /> * [[User:Hiro Market|Hiro Market]] - ([http://www.slicr.net Slicr]) Slicr - Scripting, Consulting<br /> * [[User:Scorpio Galatea|Scorpio Galatea]] - Builder (Phoenix), Texture Creator<br /> * [[User:Sylvia Trilling|Sylvia Trilling]] - Modeling, Scripting, Animating, Texturing<br /> * [[User:Earnest Candour|Earnest Candour]] - ([http://www.metaverseenterprises.com Metaverse Enterprises])<br /> * [[User:Carl Metropolitan|Carl Metropolitan]] - Building, Site Developement, Project Management, Marketing, Graphic Design, Event Hosting, Terraforming, Teaching<br /> * [[User:Lecktor Hannibal|Lecktor Hannibal]] - (Landscaping, Estate Management, Modeling, Media Streaming, Event Management)<br /> * [[User:Destiny Niles|Destiny Niles]] - Scripter/Mentor<br /> *[[User:Kim Anubis|Kim Anubis]], ([http://www.themagicians.us The Magicians])<br /> * [[User:Bobble Bertone|Bobble Bertone]] - ([http://www.coolbananas.com.au Cool Bananas Ventures]) - Building, Scripting, Terra forming, Project management, Networking with RL businesses.<br /> * [[User:Logan Bauer|Logan Bauer]] - Building/Texturing/Scripting/Ect.<br /> * [[User:In Kenzo|In Kenzo]] ([http://www.amoration.org Amoration]) Design, Building, Machinima, Events, Immersive Experiences for nonprofits and education<br /> * [[User:Gearsawe Stonecutter|Gearsawe Stonecutter]] - Scripting, HUDs, Building, complex prim transformations, single script simplification<br /> * [[User:Apollo Case|Apollo Case]] - (Armory Island and Armory Xtreme)- Virtual Weapons, Combat Items and Gadgets - Conceptualization, Testing, Marketing, Communication, Distribution, and Retailing - Combat Sim Owner and Developer<br /> * Sindy Tsure (Scripting, Buidling)<br /> * Huns Valen - ([http://valenheavy.com Valen Heavy Industries]) - Aircraft physics & avionics. Efficient interprocess communication. Remote business logic. Heuristic algorithms. Cryptography. User interfaces.<br /> * [[User:Damanios Thetan|Damanios Thetan]] - ([http://www.damanicorp.com Damani]) - Modeling, Building, Texturing, Scripting, External server comms.<br /> * [[User:Mary Edison|Mary Edison]] - (Phase 5) - Modeling, Building, Texturing, Design.<br /> * Catty Loon - Building/Scripting<br /> * [[User:Phelan Corrimal|Phelan Corrimal]] - ROCKCLIFFE UNIVERSITY - Please note that we are already more than 50% of the way there to having this already developed as we've been working on this since November 2006 when Linden Labs pulled out from financially supporting education. We are most interested in providing full support behind this initiative and would welcome people to come have a look at what we have to offer currently and where we are planning to be come end of August, 2007.<br /> * [[User:Restorator Ristow|Restorator Ristow]] - Promotion and Marketing, novice builder<br /> * [[User:Scout Detritus|Scout Detritus]] - Scripting, Building, Sounds, Animations, Clothing/Textures, Marketing, Sim Design.<br /> * [[User:Nylon Pinkney|Nylon Pinkney]] - Texturing<br /> * [[User:Alessio0108 Beck|Alessio0108 Beck]] - Nogravity - Full service italian agency - scripting - building - SltoRl web applications - design - sl real estate<br /> * [[User:Osprey Therian|Osprey Therian]] - building, texturing, machinima<br /> * [[User:Max Pitre|Max Pitre]] - building, texturing, scripting<br /> * [[User:Gus Poutine|Gus Poutine]] - Instructional Designer A.S.K. Learning<br /> * [[User:Lucian Overlord|Lucian Overlord]] - building, texturing,modeling, animations,sim design<br /> * [[User:Lordfly Digeridoo|Lordfly Digeridoo]] - Digeridoodesigns.com -- building, architecture, sim planning<br /> * [[User:Jauani Wu|Jauani Wu]] - second life is just like real life ... if you replace "second" with "no"<br /> * [[User:MadamG Zagato|MadamG Zagato]] - ([http://www.never30.com Never 30 & N30 Studios]) Residential and commercial building, Web <---> LSL Communications, SL to RL Fashion, Furniture and Interior Design [UMPIRE], Photography [N30].<br /> * [[User:Aradia Dielli|Aradia Dielli]] - Building, Modeling, Interior design, Photography.<br /> * [[User:PajVar Kerensky|PajVar Kerensky]] - DESHADOW CUSTOMS - Custom Building, Scripting, Sim Development, Business Consultation, Community Development, WWW Portals, WWW Sites, In-World Community tools.<br /> * [[User:Bobby Berwick|Bobby Berwick]] (QHB - Quality Home Builders) Scripting, Building<br /> * [[User:SignpostMarv Martin|SignpostMarv Martin]] - geek. Does all kinds of things.<br /> * [[User:Dnel DaSilva|D'Nel DaSilva]] (Xessories by D'Nel DaSilva) Builder, specializing in jewelry and other avatar accessories including the scripts used in them.<br /> * [[User:Joshua Perenti|Joshua Perenti]] - Live Helper, Sim Designer, Landscaper & Builder<br /> * [[User:Lucius Nesterov|Lucius Nesterov]] - ([http://lucius-games.blogspot.com/ Development Blog]) In-world game development<br /> * [[User:Lewis Nerd|Lewis Nerd]] - ([http://www.lewisnerd.com website]) - Construction, development, landscaping and consultation<br /> * [[User:Zal Chevalier|Zal Chevalier]] - Architect<br /> * [[User:Casu Capra|Casu Capra]]<br /> * [[User:Dalian Hansen|Dalian Hansen]] - Creative Director ([http://tretiakmedia.com/ Tretiak Media]) full service sim design and construction, SL > RL integration (advertising, marketing, internet/web design) ([http://www.cafepress.com/hantranslation/ Han Translation]) - Photography, Design/Translation in Japanese/Mandarin<br /> * [[User:Kami Harbinger|Kami Harbinger]] - Developer of many scripted devices and the Pellucidar adventure game.<br /> * [[User:Top Tank|Top Tank]] - Scripting, product design<br /> * [[User:Whispering Hush|Whispering Hush]] Custom scripting boats, cars, push and non push weapons, prim torture, and general building.<br /> * [[User:Nex Brannan|Nex Brannan]] Brutal Gear [http://gearshop.blogspot.com.com/ GearShop]) Clothing, Hair, Accesories, Building.<br /> * [[User:HatHead Rickenbacker|HatHead Rickenbacker]] [http://hatheadinc.com/ HatHead Incubators] Modeling, Scripting.<br /> * [[User:Desideria Stockton|Desideria Stockton]] (Literature Alive!) College Educator, Web 2.0, 3.0<br /> * [[User:Isandra Willunga|Isandra_Willunga]] - IDS - scripting, texturing, lowprim building, general guidance.<br /> * [[User:Derin Swenson|Derin Swenson]] ([http://www.olemissbusiness.com/ University of Mississippi, School of Business]) Building, Scripting, RL -> SL integration<br /> * [[User:Escort DeFarge|Escort DeFarge]] (Together Systems) All aspects of scripting<br /> * [[User:Davidorban Agnon|Davidorban Agnon]] ([http://www.questar.eu/secondlife Questar] and [http://vulca.no Vulcano])<br /> * [[User:Mevo Syaka|Mevo Syaka]] - LSL Scripting, Modelling, Texturing, Custom Work<br /> * [[User:Uccello Poultry|Uccello Poultry]] - Building, Texturing (including sign graphics), Clothing, Landscaping, Contract/On-Demand Work<br /> * [[User:Itazura Radio|Itazura Radio]] - Modeling Architecture and Furnishings/Interior Design as well as Avatars, Terraforming, and Land/Estate Management. Photoshop and custom graphics skills.<br /> * [[User:Phish Frye|Phish Frye]] - LSL scripter and expert programmer, specializing in connecting in-world objects to real world servers [http://www.purplestripe.com/ Purple Stripe]<br /> * [[User:Haterot Okina|Haterot Okina]] - LSL scripter and builder extraordinaire. [http://www.purplestripe.com/ Purple Stripe]<br /> * Noramyr Gullwing - ExtroVirtual (Flights of Fantasy) Builder, texturer, designer, graphic arts and development<br /> * [[User:Gregory McLeod|Gregory McLeod]] Scripter of Games.<br /> * [[User:Timeless Prototype|Timeless Prototype]] - Creator of the Multi Gadget<br /> * [[User:Zayn Till|Zayn Till]] ([http://www.metaverseunlimited.com/ Metaverse Unlimited]) Building, Texturing, Content & Concept Creation, Sim design & Management, Real life business solutions<br /> * [[User:Actionworx Pro|Actionworx Pro]] - MySQL, PHP, HTTP, LSL, XML.<br /> * [[User:Ipenda Keynes|Ipenda Keynes]] ([http://paws-above.com/ Paws Above University]) Founder of PAU, creator of widely accepted "content standards". Certified, K-12 Educator with skills in LSL, and general SL knowledge.<br /> * [[User:Yumi Murakami|Yumi Murakami]] - Scripting, Newbie helper volunteer, NCI contributor, RL education experience.<br /> * [[User:Arthur Fermi|Arthur Fermi]] - Scripting, Building, Fermi Sandbox, Landscaping [http://fermidesigns.com/ Fermi Designs]<br /> * [[User:Gatz Morang|Gatz Morang]] - Texture artist, builder<br /> * [[Jessica Ornitz]] - Architecture, Sim Planning, Texturing, Landscaping and Interior design<br /> * [[User:Fleep Tuque|Fleep Tuque]] - Faculty Educator, Concierge Member, Chilbo Community Building Project<br /> * [[User:Pumpkin Tripsa|Pumpkin Tripsa]] - (UV Taxidermy/ The Steamed Palette)- Custom Av Texturing and Shaping; Building, Scripting, Texturing<br /> * [[User:Ro Gastel|Ro Gastel]] - Liquid Prims, Scipting, Builder<br /> * [[User:AHG Hallard|AHG Hallard]] - Scripting, Design, Content and Concept creation, Building, Real Life educational, training and business solutions<br /> * [[User:SL Mathilde|SL Mathilde]] - Scripting, Building, Real Life educational, training and business solutions<br /> * [[Roderick Runo]] Builder/Scripter<br /> * [[User:Equitus Bosch|Equitus Bosch]] Architect and Planner, Mojo Business Ventures<br /> * [[Threshin Barnett]] - Terraforming, Building, Decorating, Landscaping, Animations, Design, Texturing, Land/Estate managment<br /> * [[Laylah Mistral]] ([http://www.get-inkd.com/ Get InkD!]) Tattoos, photography, graphic design/textures, and marketing for SL and RL ([http://www.slmarketing.us/ SL Marketing]).<br /> * [[Torment Thorn]] - Wicked, Inc. since 2004, Wicked stuff for Wicked folks. Childrens to Goreans we have something for everyone. Avatars, clothing, houses, furniture and more.<br /> * [[Charlene Trudeau]] - Building/Architecture.<br /> * [[User:Matthew Dowd|Matthew Dowd]] - Scripting, some building</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=LlSoundex&diff=16681 LlSoundex 2007-04-03T12:43:05Z

<p>Matthew Dowd: </p> <hr /> <div>{{LSL_Function|func_id|func_sleep=0.1|func_energy=10.0<br /> |func=llSoundex|sort=Soundex<br /> |p1_type=string|p1_name=text<br /> |return_text=phonetic representation of '''text'''<br /> |return_type=string<br /> |func_desc=<br /> |spec|caveats|examples|helpers|related|also|notes=Primarily intended for use with the proposed llSpeech2Text for "voice"-enabled objects to continue to exist should voice be introduced into SL.}}</div>

Matthew Dowd https://wiki.secondlife.com/w/index.php?title=LlSoundex&diff=16680 LlSoundex 2007-04-03T12:42:20Z

<p>Matthew Dowd: </p> <hr /> <div>{{LSL_Function|func_id|func_sleep=0.1|func_energy=10.0<br /> |func=llSoundex|sort=Soundex<br /> |p1_type=string|p1_name=text<br /> |return_text=phonetic representation of '''text'''<br /> |return_type=string<br /> |func_desc=Primarily intended for use with the proposed llSpeech2Text for "voice"-enabled objects to continue to exist should voice be introduced into SL.<br /> |spec|caveats|examples|helpers|related|also|notes=Essential for voice enabled objects to continue to exist if voice is introduced into SL.|mode=request}}</div>

Matthew Dowd