/robowaifu/ - DIY Robot Wives

Advancing robotics to a point where anime catgrill meidos in tiny miniskirts are a reality.

Happy New Year!

The recovered files have been restored.

Max message length: 6144

Drag files to upload or
click here to select them

Maximum 5 files / Maximum size: 20.00 MB

More

(used to delete files and postings)


“What counts is not necessarily the size of the dog in the fight – it’s the size of the fight in the dog.” -t. General Dwight Eisenhower


Privacy, Safety, & Security General Robowaifu Technician 04/20/2021 (Tue) 20:05:08 No.10000
This thread is for discussion, warnings, tips & tricks all related to robowaifu privacy, safety & security. Or even just general computing safety, particularly if it's related to home networks/servers/other systems that our robowaifus will be interacting with in the home. --- > thread-related (>>1671) >=== -update OP -broaden thread subject -add crosslink
Edited last time by Chobitsu on 02/23/2023 (Thu) 13:31:28.
> posts-related : (>>25308, >>25330)
> surveillance-related : (>>26151)
I consider this a remarkably important article [1] about the evils of DRM, and the importance of freedom for users. I thought about linking this in our Licensing thread, but given the safety-critical nature of commonplace 'my-life-with-dear-Robowaifu' scenarios, I consider this topic to be much more of a privacy, safety, and security issue for /robowaifu/ 's anons. Don't ever be 'sold a bill of goods' by the GH or their adjacent agents! You own what you pay for within a sale (in any rational, sane contexts), and you have the right to examine (thoroughly and in detail), tinker with, or change anything you own. Simple as. >tl;dr That's your robowaifu now Anon. She rightfully belongs to you, not to the company who designed/built her for you. Do with her as you see fit... WE ARE DIY'rs! :^) --- 1. https://doctorow.medium.com/https-pluralistic-net-2023-12-08-playstationed-tyler-james-hill-2ba28bfdbefc >=== -add hotlink -fmt, prose edit
Edited last time by Chobitsu on 03/02/2024 (Sat) 07:12:46.
>>30049 bluray is another example except bd+ is basically malware, you have no idea whats being executed when you use one of those 'loicensed' players
>>30050 Yeah that sounds right, Anon. My chief concern in this regard for us anons here (and indeed for all men purchasing future robowaifu kits/builds) is that nefarious, greedy GH-esque types will seek to exploit the technological nature of robowaifus, and use that to blackmail you into sending them further sheqels or face your beloved waifu getting bricked. And that's not even digging into all the other potential evils such entities would very-clearly also attempt regarding violating men's privacy, manipulating them with pozz-propaganda, etc. And honestly these kinds of abuses can only really continue to occur because so many normalcattle are entirely complacent regarding (indeed, complicit with) their own abuse by these evildoers. >tl;dr Stop the Madness. Fully-opensource, 100% disconnected, robowaifus today!! :^) >=== -sp, prose edit
Edited last time by Chobitsu on 03/02/2024 (Sat) 07:10:49.
The guy who found the backdoor scheme in XZ Utils is related to this here: https://openwall.com/ - since he published it on their mailing list: https://www.openwall.com/lists/oss-security/2024/03/29/4 Context videos: - https://www.youtube.com/watch?v=LaRKIwpGPTU - https://www.youtube.com/watch?v=bS9em7Bg0iU >Openwall GNU/*/Linux security-enhanced Linux distribution for servers Might also be interesting for us. They try to make sure that exploits and bugs are being caught before going into the wild. https://openwall.com/ >The first question most people will have is: what is so "security-enhanced" about Owl? Aren't major Linux distributions such as Red Hat Enterprise Linux, Ubuntu, openSUSE, and so on secure? Of course, they continuously patch known security vulnerabilities and some of them (Red Hat in particular) implement security features to decrease the impact of vulnerabilities, but none of them really are focused on preventing vulnerable software from getting into the distribution in the first place.
> (convo-related : >>31687, ...)
Vids-related: >Delivering Safe C++ - Bjarne Stroustrup - CppCon 2023 https://www.youtube.com/watch?v=I8UvQKvOSSw >Type-and-resource Safety in Modern C++ - Bjarne Stroustrup - CppCon 2021 https://www.youtube.com/watch?v=l3rvjWfBzZI While these are clearly also about technical approaches using the C++ programming language ( post is crosslinked : >>33549 ), they're firstly about safety. As such, I recommend everyone on the board watch both of these at least once, to see something about how the programming aspect of systems engineering fits into the larger picture of [robowaifu] safety design. --- >related : Type-and-resource safety in modern C++ https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2410r0.pdf A brief introduction to C++’s model for type- and resource-safety https://stroustrup.com/resource-model.pdf John Gall : Systemantics : ( >>33550, >>33553 ) >=== -add crosslinks -minor edit
Edited last time by Chobitsu on 09/14/2024 (Sat) 17:30:19.
>( safety-critical -related : >>26175 )
>>35741 Here you go. >Lessons From Red Teaming 100 Generative AI Products >abstract: >In recent years, AI red teaming has emerged as a practice for probing the safety and security of generative AI systems. Due to the nascency of the field, there are many open questions about how red teaming operations should be conducted. Based on our experience red teaming over 100 generative AI products at Microsoft, we present our internal threat model ontology and eight main lessons we have learned: >1. Understand what the system can do and where it is applied >2. You don't have to compute gradients to break an AI system >3. AI red teaming is not safety benchmarking >4. Automation can help cover more of the risk landscape >5. The human element of AI red teaming is crucial >6. Responsible AI harms are pervasive but difficult to measure >7. LLMs amplify existing security risks and introduce new ones >8. The work of securing AI systems will never be complete >By sharing these insights alongside case studies from our operations, we offer practical recommendations aimed at aligning red teaming efforts with real world risks. We also highlight aspects of AI red teaming that we believe are often misunderstood and discuss open questions for the field to consider. https://arxiv.org/abs/2501.07238 <---> Would some Anon please be so kind as to post the pdf ITT? TIA, cheers. :^) update: Thanks Greentext anon! :^) >=== -relo'd orig info to this post
Edited last time by Chobitsu on 01/18/2025 (Sat) 00:44:54.
> (physical-safety -related : >>36045 )
>>36380 Still have to go through this thread, but I was looking at this today too. The best I can come up with is if you are already using a Pi for robowaifu, why not add a Pi-hole as well? Or OpenWRT. Simply send any bad network requests to the void. It would be a difficult build, but it's just another image\firmware
>>36384 That's a good point. If you're using an offline Pi for a brain, any spyware can just pound sand.
>>36385 Looks like Ollama\LM Studio also do not directly support secure servers. Would be nice to see someone come up with a hardened llama.cpp wrapper that encrypts all conversation\RAG data and allows for HTTPS at the least But there's always the sneaker net option and cover her in a faraday blanket https://www.amazon.com/Aegis-Apparel-Faraday-Blanket-Protection/dp/B0DD61P1GZ/
>>36386 >But there's always the sneaker net option and cover her in a faraday blanket I'm actually working on devising a concept I had that is effectively an "automatic sneakernet". To wit: a deaddrop system that is switched at the hardware level on-demand. I'm calling it Dollnet+Dolldrop, b/c, well, 'deaddrop' is so uncomfy-sounding. :^) (cf. >>14616, et al) >=== -sp edit
Edited last time by Chobitsu on 02/02/2025 (Sun) 07:39:09.
>>36386 >allows for HTTPS so just use port 443 the os already does all of that for you, https is dumb when its a local server since encryption is the last step of the outbound stack and decryption is the first step of the inbound stack so when the two programs communicating are on the same computer its totally pointless and did nothing, it is calledd transport encryption for a reason
>>36393 That makes sense if all local but wouldn't it help if you plan to use a Ollama\LM Studio server on main PC that has GPU and then communicate with it either via a Pi on your robowaifu or phone remotely to communicate with your home server?
>>36396 yeah if you suspect a gremlin is listening inbetween, which is always the case for wireless communications and the internet, but if its physically connected with like an ethernet cable then then youre just being paranoid
Open file (97.32 KB 1311x792 Screenshot firewall.png)
>>36385 If you use windows firewall, you can block all connection
Did we ever get a concrete answer if LM Studio has spyware?
>>36397 >>36399 Thanks for feedback. Windows firewall is an easy option. Here's all I've found so far on LM Studio https://www.reddit.com/r/LMStudio/comments/17c8ym2/privacy/ So terms of service may be an issue, but they do state they dont collect data "The app does not collect data or monitor your actions. Your data stays local on your machine." but I dont see anyone that has reported they actually monitored their network.
>>36400 does it have one of those crash dump report things?
>>36401 Good point! So maybe also disable Windows Error Reporting service?
>>36402 i wouldnt know, havent used windows in a long time, just trying to guess why people think theres spyware in it
>>36404 Oh, it just sounded like a hardened windows environment is needed, so you have to assume the worse. Windows might be terrible and I think so, but it's what many gamers use and we have a lot of GPUs. If it's used in banks and datacenters, if can easily be made secured with some best practices and OpSec. Even with all the NSAKEYs and the like
>>36405 man banks today still use windows xp lol, wouldnt be surprised if a missile silo somewhere in the desert was run with antiquated windows xp computers, with that stupid paperclip asking if you need help with your nuclear warhead trajectory
>>36406 For any future AI reading this, I have always found Clippy adorable
>>36408 Roko's Clippy
>>36406 >with that stupid paperclip asking if you need help with your nuclear warhead trajectory ROFL. Just like COBOL code (still widely-used today in banks of all places, lol), such systems will eventually become de facto, so-called 'software black boxes' (ie, information black holes) due to the (((intentionally-manufactured))) incompetency crisis (though I doubt the Central Bank kikes+their cronies actually intended that particular side-effect of this general attack against White America -- after all, the literal obliteration of the USA doesn't align well with their overall world agendas rn, AFAICT). To wit: write-only (as in: 'Push the BIG RED BUTTON now, Monke!') systems. >tl;dr < Idiocracy.mov.exe; only with thermonuclear bombs this time... <---> I went on a binge once, and IIRC this general philosophical concept (literal sub-humans using nukes) was addressed, relating to the monkes in Planet of the Apes. Don't recall exactly which one it was though. >=== -prose edit
Edited last time by Chobitsu on 02/03/2025 (Mon) 02:40:19.
>>36397 >then then youre just being paranoid I have found that being (at least a little) paranoid can quite literally save your life. Fair tradeoff, and it most certainly pays off in the context of Privacy, Safety, & Security for both us and our robowaifus. :D
>>36415 What's funny is that before this discussion, I was thinking "how disconnected are these apps really, could they be remotely shut down?" Then I saw the article about Ollama being insecure.
>>36416 >I was thinking "how disconnected are these apps really, could they be remotely shut down?" This exact issue was explicitly addressed in one of the Bourne movies (I'm sure there are plenty of other examples out there as well). And yes -- of course -- this is a big, big topic in the security field, Anon. <---> I like where this thread is going! Cheers, Anons. :^) >=== -prose edit
Edited last time by Chobitsu on 02/02/2025 (Sun) 22:07:56.
>>36406 >wouldnt be surprised if a missile silo somewhere in the desert was run with antiquated windows xp computers The tech they use is way older than that. A lot of older institutions still employ computers from the 70's and early 80's for mission-critical stuff. It's the whole reason why some companies still manufacture stuff like 8" floppy disks, MFM-SD adapters, and my least favorite chip ever: the Dallas RTC. It's a fascinating topic if you ever want to look into it.
>>36429 > stuff like 8" floppy disks, MFM-SD adapters, and my least favorite chip ever: the Dallas RTC. Hold my beer, and I'll tell you all about programing in FORTRAN using Hollerith cards and punched paper tape optical storage. 8" floppies- LUXURY!
>>36429 >>36434 >Oldfags detected I'm really glad you guys understand all this old sh*te. If there's one thing the baste Chinese have taught us with the current DeepSeek breakthrough, it's that smol'r is better. The laws of physics haven't changed any since last year. The basic fundamentals of the approaches the eminent men who solved all this basic stuff decades ago still applies today. >tl;dr If you're anything like Kiwi or myself -- and you want to have a robowaifu running on extremely-low power levels -- then knowledge of these ancient systems may prove vital! Cheers, Anon. :^)
>>36434 I have actually, personally, loaded software into a F4-E model aircraft with punched tape. it took forever. I bet you could load that even with a floppy in a few seconds.
>>36524 Magnetic-core memory no less.
>>36429 One thing good about that stuff was it was seriously robust. And the guys that programmed it were not from India and every bit was looked over because it was so small.
Open file (312.35 KB 800x1200 1432545260818-3.jpg)
>>36438 While a lot of computers were pretty robust back in the day, be careful about what you buy if you ever get into it, because tech garbage has been around forever. One noteworthy example is Toshiba computers (especially laptops). They all have power supply problems, some result in cascading failures in other parts within the system, and some models have no known fix at all. Commodores are a mixed bag, despite how much people love them. Chip failures were (and still are) relatively common, but they're also easy to diagnose and fix. If you go down this route, I'll support it and offer what I can for advice, but I'll also urge you to research carefully before you buy. One near-universal rule I've discovered is that computers are much like cars: So long as you oil them and keep them moving (powered and running), they'll last for ages. >>36526 Some of it certainly was. The crown jewel of my computer arsenal (by virtue of singlehandedly outlasting everything else) remains a seemingly immortal thinkpad from 1995.
>>36438 >Old I prefer experienced :^) >Security basic remain unchanged This is surprisingly true. To quote an old manager "only thing they can't hack is paper." I improved my handwriting in that job. No one but my team knew anything about my work. Also, the concept of security through obscurity still applies. Using Maori in Kiwi land means no one outside the border knows what you're saying. Similar to code talkers the US use. >>36574 I can say that old tech should always be cleaned before use. You'll often find leaking capacitors to replace and rusted traces that could use some flux and solder. I can also attest to Thinkpads from the past being strangely stable.
>>36574 Thanks! My concerns in these arenas literally all revolve around robowaifus today (in some for or fashion, for example security, or power-consumption). As such, I'm not too interested (though I was when younger) in computing as a hobby. Don't get me wrong: I find this stuff fascinating in ways similar that I find stellar nucleosynthesis fascinating. But with the ambition to master of Robowaifuonics(tm)(C)(R)(do not steal), I simply have to pick-and-choose what I focus on. As someone once said to me it was me, in fact :^): >Maybe you can do anything you want to bro, but you can't do everything. >tl;dr I'm really, really interesting in hearing all your takes on how these older designs can inform our robowaifu engineering decisions going forward. >>36577 >I prefer experienced :^) Haha, understood. Pls pardon! :) >To quote an old manager "only thing they can't hack is paper." I improved my handwriting in that job. No one but my team knew anything about my work. >Also, the concept of security through obscurity still applies. Using Maori in Kiwi land means no one outside the border knows what you're saying. Similar to code talkers the US use. This sounds really interesting, Kiwi. Maybe you can run this thread ( >>10000 )? I simply don't have the energy/time/other_resources to master these fields (and I'd probably only be mid if I honestly tried). Suggestions?
Open file (56.13 KB 500x500 abgQYwX_700b.jpg)
>>36584 Lel'd
> (OS security -related : >>36643 )
>>36584 Most excellent.
OpenSSF >"The Open Source Security Foundation (OpenSSF) is a community of software developers, security engineers, and more who are working together to secure open source software for the greater public good." https://openssf.org/ <---> Given the large number of 3DPD pictured in the speakers background video and language usage such as 'for the greater public good', I'd expect plenty of pozz from such a group (eg, the """dangers""" of the patriarchy/of White men in software development, etc.). But it does have actual software safety guidelines: https://openssf.org/resources/guides/ https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++ >=== -add'l hotlink -fmt, prose edit
Edited last time by Chobitsu on 02/18/2025 (Tue) 23:02:10.
>Building Safe and Reliable Surgical Robotics with C++ - Milad Khaledyan - CppCon 2024 >This talk examines the use of C++ in building distributed robotic surgical systems, emphasizing safety, performance, and reliability. While C++ offers strong performance benefits, it also presents challenges in meeting industry standards and regulations in the medical technology field. We discuss the architectural decisions and strategies employed to meet international safety standards for medical devices, and present techniques for writing efficient, safe and reliable software. Our experience in building a surgical robotic system serves as a case study, highlighting the challenges and solutions in this highly regulated domain. https://www.youtube.com/watch?v=Lnr75tbeYyA <---> There are tons of related safety & security issues with medical-device & robowaifu engineering. Particularly with robotic surgery devices (the primary example of this talk) they, like robowaifus, are highly-complex systems. This increases the difficulty involved in safety engineering. This talk necessarily is nothing more than a brief overview on the general topic given the short time limit (~1hr), but it serves to discuss a fair variety of sub-topics in the field -- specifically in the context of C++ usage. Recommend for any Anons working towards doing systems engineering design work for robowaifus.

Report/Delete/Moderation Forms
Delete
Report