Jump to content

Kathrine Jansma

  • Posts

  • Joined

  • Last visited

Everything posted by Kathrine Jansma

  1. The authentication isn't Microsoft Auth or something but the TOTP standard at work: https://en.wikipedia.org/wiki/Time-based_One-Time_Password or for a more graphic explanation try https://www.allthingsauth.com/2018/04/05/totp-way-more-secure-than-sms-but-more-annoying-than-push/ While it would be nice to have other, additional options, it is technically one of the safer options that does not require any privacy invading apps or phone numbers or similar stuff. WebAuthn would be another step up in security. If your country has a nice and working eID implementation, thats cool (and sadly still rare worldwide). But LL probably does not target all the fragmented eID ecosystems in all the countries, especially not for smaller countries as a priority. In addition, some countries have hillariously bad national eID programs. For example germany with its citizen cards, "Personalausweis", which is technically very advanced and really good for eID, but hampered by stupidly complex requirements for anyone trying to use it. If you, as a provider, wanted to use the german eID functionality, you would have to register with the federal office, buy some expensive license, setup some specialized service etc, all amounting to costs of at least 50.000 €/per year or more to offer it at all, according to some estimates. So if other countries have similar programs it would be quite expensive to offer the specialized service for every country SL works in.
  2. Makes obvious sense, when thinking about it. The number of draw calls might scale linear, but the visible effect doesn't.
  3. Nice as well, but, well I'm trained in physics, so not scared of graphs and statistics. Thats quite some significant FPS drop in your intro text: Does that scale linear? Like 2x Maitreya users => 81 FPS, 3x => 69 etc.? Otherwise it looks pretty conclusive from the numbers and graphs.
  4. You could probably get it to work with liberal use of stuff like NTFS Reparse Points (Junctions), but performance over network drives tends to be atrocious. (Unless you happen to talk about stuff like very low latency 40 GB/s Mellanox cards and good SANs). So just not worth it. If you still have spinning rust (aka HDDs), just get any SSD. Always better.
  5. More memory is always pretty nice. Might also wish for some efficient shared memory between scripts in the same object. E.g. allow one script to "export" a read only list to other parts of a script set, to avoid tons of messages and duplication back and forth. That could simplify some things even when the 64kB limit of writeable memory per script survives.
  6. Excellent read, really curious about the numbers, even if all benchmarks are advanced examples of lying with statistics. I guess there is no real chance to get the current render pipeline to use stuff like glMultiDrawElementsIndirect() to optimize the batches for those bodies, other than just rewriting the whole stack for Vulcan? But guess the OS X (non-)support for anything OpenGL means a solid no, as it stops with OpenGL 4.1.
  7. If you got a Windows 11 or Apple MacOS Box, the viewer could simply do some FIDO/WebAuthn stuff based on the device TPM and you are mostly done for 2FA without complex extra user input. Throw in some TOTP tokens (aka Google Authenticator) for people without phones or some email codes and App push/SMS for the people that really want to use a phone just because they are used to it. But using MFA/2FA for simple logins is probably total overkill anyway. The hard part is doing proper tech/user support and preventing the two horrible scenarios of 2FA. The tech part is easy: Attackers fast talking support into doing a password/2FA reset with just a single factor left... Being locked out of the account due to failing hardware tokens/phone number/email address lost without any reasonable way to claim it back.
  8. @Monty Linden Any plans to run the CDN with Quic/HTTP2/3 instead of old HTTP1.1 Pipelining? It does not serve https:// so the default http/2 stuff obviously does not work yet. With the newish multithreaded texture decoders the fetching can be a bottleneck, so some more concurrency without head-of-line blocking would be nice to have.
  9. In most viewers it is a single thread to fetch and decode textures. But some viewers have a multi-threaded decoder by now (Cool VL Viewer, and i saw the change in the Firestorm repos too, but not yet released) which can speed up texture loading&rezzing quite a bit. Those viewers have settings to adjust the number of threads for texture decoding.
  10. It's called TOR. And if you look at the shenannigans that fly out of the browser customization needed to keep it safe, it is pretty much an uphill battle if you want to enable interactive stuff like Javascript and external resources. The other way you could do it would be Appstore style walled garden with compiled apps that simply lack the APIs to get close to anything identifying. And just watch the whole supercookie, canvas fingerprinting or HSTS fingerprinting efforts by the ad industry you can basically forget it as well. You do not need the IP to identify a machine/user. Once you have device dependent timings, you have lost. So, if one really wanted it, one could do a kind of "streaming texture", where you attach something like a VNC/RDP datastream to a prim texture and just have the browser running headless on some common cloud services rendering its output to the VNC display. (think Google Stadia/Gefore Now or similar concepts). But that has obvious costs attached as the VNC setup would need to be run by a trusted 3rd party.
  11. Would have helped me back in the day, when i tried for around 2 hours to unpack my first bought outfit. So a modern help system would be okay. Its kind of adding a little of what makes Electron Apps attractive to people. Use web stuff for boring UI tasks and have it look pretty. And lock it down to just a few allow listed origins.
  12. Looking at the openssl 1.1 patch i really wonder a bit about compile options: (and really hope it is 1.1.1 as 1.1 is out of support as well...) # disable idea cypher per Phoenix's patent concerns (DEV-22827) perl Configure "$targetname" no-asm no-idea zlib threads -DNO_WINDOWS_BRAINDEATH \ --with-zlib-include="$(cygpath -w "$stage/packages/include/zlib")" \ --with-zlib-lib="$(cygpath -w "$stage/packages/lib/release/zlib.lib")" zlib is kind of "YES, give me CRIME attacks". So most Linux distros disable TLS compression and LL should too, gives a nice CVE (https://nvd.nist.gov/vuln/detail/CVE-2012-4929 ) so better build with no-comp. Even if it works around the lack of compression support on the HTTP layer but well, textures should be highly compressed anyway, and you want HTTP/2 with the efficient Header compression in the end. no-asm is also not really a smart thing to do, as it disables AES-NI support which costs a lot of CPU time (see https://www.openssl.org/docs/faq.html Listed at "Does OpenSSL use AES-NI or other speedups?") LL could be way more liberal in disabling dead algorithms and unused stuff (e.g. Triple-DES, RC4, and a ton of others you do not need) No one needs SSLv3 anymore, and while at it kill TLS 1.0 & TLS 1.1 defaults as well (https://datatracker.ietf.org/doc/html/rfc8996)
  13. Well, WebAuthn claims to be phishing resistant. And it actually helps a bit for people that have some amount of common sense left. There are still some gulliable people that fall to ANY phishing attempts, but thats unfixable. https://i.blackhat.com/USA-19/Thursday/us-19-Brand-WebAuthn-101-Demystifying-WebAuthn.pdf
  14. Dual passwords are basically longer passwords. So why not simply require longer passwords?
  15. Doing anything with the username is worthless for other reasons too. Lets imagine you use email instead, like all the other sites. Great! You just enabled trivial password spraying attacks. So the only benefit of username = inworld name is that attacks on a specific users account gets a tiny bit harder. But it fails anyway if the password is strong enough so there is no benefit. Which is basically https://en.wikipedia.org/wiki/Kerckhoffs's_principle So if your password is weak, no username trickery will save anything for long.
  16. Actually it is current best practice to move away from password complexity rules towards other measures. The current best practice is use a long and unique password for each service and do not enforce any complexity rules. Thats at least the recommendation of US NIST, German BSI, and the UK. Mandatory XKCD https://xkcd.com/936/
  17. 2FA done right is a good thing, no doubts there. But most 2FA is done in a terrible way. A few of the really common pitfalls. offer SMS only (or worse: demand SMS to a mobile phone only) offer a push TAN app on some proprietary non jailbroken mobile phones only. Use TOTP from RFC 6238 but modify it slightly so only your own app can generate the codes Have a support hotline that ignores 2FA and just asks some trivial knowledge based questions to recover credentials Have a password recovery process that just asks for the 2FA key and common knowledge (turning 2FA into single factor again) Try to do WebAuthn and have users run away from the complexity of setting things up properly Allow only a single hardware token per user for 2FA (you need at least two, or you end up with the password recovery process ending up as 1FA, it only works with a single token in a corporate environment where the IT can establish identity out of band) Have super aggressive timeouts like 5 minutes between 2FA (e.g. shop on the marketplace and get asked 2FA code for login and again 5minutes later for checkout), thats what some banks do due to PSD2 regulations in the EU. Ask the payment industry to do it (you end up with junk like Verified by Visa (https://www.cl.cam.ac.uk/~rja14/Papers/fc10vbvsecurecode.pdf ) Ask the government to do it (you end up with hyper complex junk like the german eID system, safe but unusable) Ask the smart card industry to do it (you end up with a smart card based system that needs new cards every year as a source of income) If i was to decide upon 2FA or auth system options, i would probably go with ALL the following: Offer TOTP as a good secure baseline system: Good enough, works everywhere. Offer SMS or some App for people that really want it. Because people know it. Offer WebAuthn for the technology savy people that want hardware tokens or have high values in their account. Good tech, strange crypto, a bit high entry barrier still. Allow linking accounts to external ID providers via OpenID connect or social logins/services in order to have a third factor for password/2FA recovery. Do some basic risk based assesment when to ask for 2FA (e.g. logging in, buying/selling RL currency, large transactions > 25.000 L$, land changes, many account data changes). The hard part is not really the tech. The hard parts are "Ease of Use/UX and Password Recovery."
  18. Typically you add a fps limiter to avoid silly cases like your GPU overheating and sucking massive amounts of energy when it tries to render the static pause screen of a game because you left the house for work with the game still open. Some games had that issues and rendered 1000+ fps on the paused screen and broke the GPU (or burnt down the house...). After all, its totally useless (if you go by https://en.wikipedia.org/wiki/Nyquist–Shannon_sampling_theorem ) to render more then 2x the Hz of your display in fps (fps is basically Hz), so setting some limit in the display update range is useful to save energy.
  19. Blame AMD for their utterly shoddy Open GL drivers (especially on Windows). I use a RX Vega 56 on Windows and watching the Visual Studio Profiler on an AVX2 optimized build of the Cool VL Viewer is kind of depressing. The profiler shows maybe 10-20% of time still spent in the viewer code in lots of methods (e.g. not really nice stuff to optimize), but about 80-90% inside the crappy AMD driver or the OS. So even if one could optimize the viewer perfectly the fps will not increase by more than maybe 10-20%. Henri tends to get 5-10x my fps for his NVIDIA setup/Intel/Linux, compared to my AMD Ryzen 2700x + RX Vega 56 + Win10. With the multi-threaded texture fetcher i actually get near 100% CPU usage, when teleporting to a new region full of AVs with a draw distance of 512m or flying over the mainland, and it is kind of awesome to see the texture console races through textures as the viewer sucks in like 60+ Mbit/s of data. But frame rate doesn't change.
  20. Feel free to reuse the multi threaded patch (http://sldev.free.fr/forum/viewtopic.php?f=10&t=2141#p10405) Consider it dual-licensed under GPL and LGPL.
  21. I didn't see a thread pool inside the Firestorm code (besides the KDU internal ones), but maybe I'm wrong, just did a cursory look and found the same old llQueuedThread stuff. In any case, more cores help, just not for speeding up the actual rendering due to OpenGL shortcomings.
  22. You can throw a few more threads at the viewer and it actually helps, but not directly for fps... Have a look at the latest version of the Cool VL Viewer, it uses a thread pool for texture decoding, which improves rezzing speed massively.
  23. No, its untrue. The rumour might be because some forms of UUIDs (Type 1 GUIDs) could be used to track the unique serial number of your network card, the MAC, because it was used to create the GUID number. (Microsoft had some troubles with that with their Office products, which embedded GUIDs..). Even in that case you cannot find out any geographical information or much useful other info. A totally different thing is an IP address. Those can be tracked to your general area of residence pretty easily. But the viewer does not propagate that information and it is not related to your Avatar Key. Kath
  • Create New...