I discovered I left out .cpp files for the g++ build statement in the meson.build file, so I decided to go ahead and immediately update the version to fix that. Cheers >version.log // robowaifu access control // ======================== // -The software testbed for devising access control systems for robowaifus 210817 - v0.1a -------------- -fix missing definitions files in the 'g++' build section in meson.build -move to -std=c++17 -fix East-const params in definitions -edit javadoc for Relation::stranger -minor comment edits -add version.log file 210817 - v0.1 ------------- -initial release https://files.catbox.moe/fq1yo6.7z 746645899aed33e561e2da749a73886597efab8a08fbb6d26024720e5fc38fa4 *rw_access_control-0.1a.tar.xz

OK, so I've tightened up the codebase a bit further and added both 'Sequence' and 'Directive' classes, to mirror the 'Info' and 'Inquiry' classes. The robowaifu now performs checks on requests for actions, in addition to information. The validate() function is now a template function that (surprisingly) currently doesn't really need any specializations (!) >tl;dr The behavior is identical with both kinds of engagements (Directive & Inquiry) Also, I added the initial framework for command-line argument parsing. It only works with the help flag ATM, but soon it will be useful for specifying the files that contain relations, inquiries, sequences, directives, etc. Next, I intend to experiment with a newer JSON library drop-in, then move all the testing scenarios out into external human or machine-writable examples files that Anons can play around with easily. Some of this is kind of fun to think through tbh. :^) Cheers. >version.log 210819 - v0.1b -------------- -add Sequence class -add Directive class -convert to templatized validate() -add 'add non-Human inquirers' TODO DESIGN into Inquiry class -edit javadoc for Human, Info, Inquiry classes -move to auto return types for member functions -add 'The_Master' security comments -add 'The_Master' validated pointer assignment within Human ctor -add 'general utility container search function' comment within Human ctor -use constant iterators within Human ctor -add default ctor inline definitions -edit javadoc for validate(), what(), allows(), relations() >s/permitted/authorized in validate() -edit javadoc for Permit -add general un-Group'd Human testing & TODOs for un-Name'd (disabled) -add 'testing framework and harness suite' comment into main() -clarify TODOs with refinement tags -add 'TODO DOCs for teaching expositions' into the entry point & header files -various comment edits -add 'project configuration' comment section in meson.build -add CLI args parsing + utility files https://files.catbox.moe/i9scan.7z 5f50069840debe36f6f0e314c35af1901aa9511d8844b94d4c1be727e1854576 *rw_access_control-0.1b.tar.xz

>>12431 There are many repeating patterns in life. People tend to do things at certain days of the week and certain times of the day, and likewise what they talk about and with whom often has these ebbs and flows. So a simple idea for reducing the likelihood of embarrassing leakages is for the estimation process of the relevance of prior sentences for the current conversation to give extra weight to stuff said on the same day last week and said about the same time of the day. If the AI owner gets into the habit of talking with the AI about very private things at very specific times and likewise tends to expose the AI to other people at rather specific times, there will then be some automatic compartmentalizing between the different people that even works to some extent when there is a mix-up in recognizing a person or when such a recognition procedure is completely absent.

Just a quick update to let Anon know the integration of the new JSON library has gone flawlessly, and I should be working out some basic ideas for external example files for security and access control. Please be giving some thought to the ideas you want to test with hand-crafted imperatives in this manner. BTW, I plan to output logging for engagements so we can debug the inference, awareness, and control sequencing. https://github.com/nlohmann/json

>>12527 >and I should be working out some basic ideas over the next few days for... *

>>12527 >related crosspost (>>12530)

>>12528 >and I should be working out some basic ideas over the next few monthsdays for... * LOLE. I realized that I didn't have many good way to pretty conclusively determine in basically every case how to assess (or even to define) all possible legitimate access-control situations w/o actually reproducing any realistic scenario -- and do it a rigorous way that would ensure at a glance I wasn't leaving something out, etc. With my rather limited abstract mental capacities in relation to Anon's I realized that only an animation production system that would correctly mimic SoL scenes would do. Therefore I decided to go for the even higher prize since I couldn't reach the lower one. :^) I also decided I needed a proper testbed creative work with which to prototype the development. Accordingly being the autistic nerd that I am, I chose >pic related < BEST.DATABASE.TEXTBOOK.EVER. Well, anyway Tico the moe Fairy is cute, and I'm planning to cast her as the flying moebot robowaifu in the scenario I'm cooking up here. I'm pushing the actual code itself to the board as a basic test to see if we can leave catbox.moe as simply a backup alternative going forward. (see >>12530 for further info). It's nothing but a skeleton framework atm, and it will likely be months now before I have anything to release that's usable for our purposes here, but I wanted to at least make you aware of the project effort itself Anon.

>>12596 Oops forgot to add the tarball's hash as usual. 883759ae6d1a16cc030f64539fb337460009b604f9fdc3949593ecec5d25d2ba *kingdom_of_kod-0.0.2.tar.xz

>>12596 AUUUUUGH I accidentally'd a compiled binary in the source dir from my testing and forgot to delete it before meson dist'ing. Just toss it since unless you're on Arch, it probably won't even execute for you. Just issue meson build, and proceed as typical Anon.

>>12596 OK, I fleshed things out just a bit further. I think I've covered most of the bases for classes I'd need for an animation system. I'd welcome critique if anyone's interested. > I probably should move my progress updates elsewhere, since it's going to be a while until this project is in shape well enough to directly support safety & security by being a good 'robowaifu access-control simulator' of sorts. Not too sure where I'll go with it, but I'd like to keep it available to the board as it develops. Anyway, Cheers. 4fd74ea38ac84fbb5551205f4ac24b85289567ad63f86caac7401fb510c5eb07 *kingdom_of_kod-0.0.3.tar.xz

>>10860 defcon website has some mp3 lecture(s?) for EMP defense if you do a site specific search wonder if there are some physics simulation tools that you can use for this kind of thing without paying a lot >>10868 >Just make sure both yourself and your robowaifu have bodycams running and sending the footage to a backup server if you ever go out and about. If extra paranoid, you can aim to secure the admissibility of your digital forensic evidence full disk encryption goes a long way to make sure that they can't just add something incriminating to your HD. Though they can probably demand you to provide the password if they suspect you of anything (idk if any recent developments change this) you'd be giving it to them anyway if you were turning over footage. You could also regularly upload cryptographically secure hashes of recent footage to some popular blockchain in a consistent format, and use this to selectively prove chunks of footage were hashes+uploaded by some block # and hence date/time. >>10871 >>10869 >appropriate level of reveal we should engage in here ultimately depends on each person's opsec. (but real glowing should be discouraged even if only for the benefit of the OPSEC-impaired unawares) I would recommend taking minor precaution like onion routing and privacy OSes even if you don't think you are doing anything illegal. I wonder if the powers that be are actually against roboWaifu- they would seem to solve the statecraft element of the excess male issue and if they put more pressure on women that will just result in more commercial income through cosmetic crap like makeup/surgery etc. Ofc glowies are not monolithic.

>>15726 addendum: I wonder if "legal-only" darknet markets and forums will start to proliferate with the unbridled expansion of anarcho-tyranny. like yeah, we don't think we are doing anything illegal, yet... but we know that you don't need to be consciously or conspicuously criminal for someone to hunt for prosecution excuses. Or even just stuff that is 100% legal but suppressed by corporate or otherwise ought to be private like controversial personal finance strategies (e.g. "over-employment", extreme frugality/savings, credit card promo churning) or politics or supply chains (e.g. robowaifu, cryptocurrency hardware wallets, prepper stuff, fetish stuff)

>>15726 >>15727 >"It matters little who is the enemy, if we cannot beat off his attack." >-t. Gandalf Undoubtedly, the general consensus on the board is that the potential reality of robowaifus represent a roughly existential threat to the status-quo of feminism as it stands today. Since this is one of the keystone tools of evil in the hands of the Globohomo Big-Tech/Gov, it strikes me as rather a safe assumption that we can eventually expect non-organic, violent opposition to our entire field to be fostered by them, across every land where they currently maintain their Commie-like iron grip. Clearly, there is already non-violent opposition being propped up against even the very idea of robowaifus (before an industry even exists for it lol), conducted by the usual-suspect tools; Glowniggers, Troons & Leftists. Generally, this currently manifests itself primarily as media & legislative-based reeing over: >"Won't someone please just think of the children!?" or >"RAEEEP!111" This shows the paranoia they already experience related to free men being free from the Satanic Zeitgeist they are attempting to devise. Otherwise, why even bother? Eventually however, they won't restrict themselves to just using attacks consisting of simple words & """rules""". Once real robowaifus begin actually being broadly available to men, you can expect much more insidious -- even violent -- means to be used by them. >tl;dr They certainly are no friends to us here on /robowaifu/, Anon. Best prepare well in advance for their onslaught IMO. >=== -minor grammar edit -prose edits

(>>16275, ... related crosspost)

Listening to this recently. Pretty eye-opening that this stuff is already almost 10 years old. Surveillance, the NSA, and Everything Bruce Schneier, Fellow, Berkman Center for Internet and Society https://www.usenix.org/conference/lisa13/surveillance-nsa-and-everything

Maybe interesting: Detecting intrusion to hardware with space inside, based on radio waves - https://www.technology.org/2022/06/11/an-alarm-system-against-hardware-attacks/ - smaller parts are better protected with another method: > Mechanisms designed to protect hardware from tampering do exist, of course. “Typically, it’s a type of foil with thin wires in which the hardware component is wrapped,” explains Paul Staat, a Ph.D. student at Ruhr-Universität Bochum (RUB) the Max Planck Institute for Security and Privacy. “If the foil is damaged, an alarm is triggered.”

>>16657 Nice trick (& inexpensive too). Thanks Anon.

Related: Why not using mobile devices instead SBCs or Laptops >>16963

More security research on old Intel CPUs (till Atom 5000 series, current one is 6000): >At the beginning of 2020, we discovered the Red Unlock technique that allows extracting Intel Atom Microcode. We were able to research the internal structure of the microcode and then x86 instruction implementation. Also, we recovered a format of microcode updates, algorithm and the encryption key used to protect the microcode https://github.com/chip-red-pill/MicrocodeDecryptor Maybe this will also make sure that there won't be any intentional secrit backdoors? I don't know if they might be able to upgrade it at some point. Currently not: >Only decryption is supported, because microcode has an RSA signature for integrity protection.

The guide to (embedded) linux kernel we deserve https://github.com/0xAX/linux-insides/blob/master/SUMMARY.md as developers

>>17001 Great information Anon, thanks for the link!

I wanted to have a encrypted filesystem like EncFS for quite some time. I was even thinking of writing one myself. I had bad experiences and concerns with using datasafes like LUKS or VeraCrypt for backups. Especially for making backups on a optical disc a system where every file could be decrypted on it's own would be better. These containers also don't seem to be safe enough. Which makes it relevant for robowaifu, if it wasn't already in regards to backups. EncFS is considered insecure by many, though that might dependent on the exact usecase, So, people are working on alternatives. I will most likely go with eCryptfs for now. I don't need cloud support, which seems to be an issue with eCryptfs, so I don't really care about that. gocryptfs doesn't convince me enough and Go seem to have had some questionable security irregularities recently, and someone working there being flagged as a questionable person in regards to peoples security (not sure about the details). Comparisons: https://www.cryfs.org/comparison and https://nuetzlich.net/gocryptfs/comparison/ >Source of these links: https://askubuntu.com/questions/813290/encfs-insecure-what-to-use-now >one is beta and the other one being used by some companies https://www.cryfs.org/ http://ecryptfs.org/ >eCryptfs is widely used, as the basis for Ubuntu's Encrypted Home Directory, natively within Google's ChromeOS, and transparently embedded in several network attached storage (NAS) devices.

>>19451 >I don't need cloud support That's good, b/c in my opinion anyone who wants security and uses """cloud services""" to 'achieve' it, should seriously re-think their life-choices, heh. :^) Thanks for the contribution ITT Anon.

>>19452 Well, for backing up some files it's not necessarily bad. Better than loosing them. Also, if the encryption most likely works and the files are medium privacy critical it isn't that much of a problem. I wouldn't use it for my RW obviously.

>>19457 Fair point. But redundant or ancillary backups are neither safety nor security, but rather integrity-assurance. BTW, you are signficantly compromising privacy needs when you trust your valuable data to someone else's computers, Anon. So as you said, obviously don't use that approach for your robowaifu's personality data, history data, etc. This entire set of arenas is always a cat-and-mouse game, and no one has much by way of guarantees. We must strive for our systems at the very least to not be the low-hanging fruit, or they will get easily plucked. Most of the productive ground is gained here by commonsense protocols, not primarily through technical sophistication. Never connecting your robowaifu directly to the Internet, for instance, should be the first & foremost one on that whole list. >tl;dr We must devise systems that allow Anon -- and Anon alone -- to maintain full protection and full control of his own robowaifu. You may as well invite the Globohomo directly into your home with open arms otherwise. No thanks. >=== -prose edit

>>19462 >integrity assurance Okay, fair point. If I would teach her how to prepare a meal and she would use the pictures to learn it. I would care more about the integrity than someone being able to decrypt my data on a cloud and seeing me food and pots. Anyways, these file system encryption systems which are ideally changing the encryption based on each file or block are imo probably safer and have less of a risk of data loss than containers. So, if we have something to encrypt which might get into the hands of someone else, we should probably use one of those.

Storing these here for now, via sleepytech OpenBSD execute-only code segments >https://undeadly.org/cgi?action=article;sid=20230121125423 >https://marc.info/?l=openbsd->tech&m=167501519712725&w=2

> (crosslink related : >>20750) See: 'Definition of Safety' and other sections.

Lets say big globo homo corpo makes robot wives first. How do we stop them from doing an >execute order 66 ?

>>22626 The first, best, way to keep from a shut it down! is simply to get there first & 'shout it out from the rooftops' across the planet. I doubt not the West will eventually outlaw private robowaifu ownership that isn't directly under their Filthy Commie iron thumb. Seemingly ironically, it's the East IMO that will be the main driving force behind robowaifus in the mid to late future going forward. But yeah, get there first is the correct answer.

>>22626 >>22627 I know, 99.99% of the men won't shut down their robowaifus just because a few anons scream about the Globohomo from the rooftops. I think what we should focus on is open source robot OS, jailbreaking, unlocking bootloader. Play on the very valid fears that their robowaifus would phone home and store everything about them=ir husbandos, including all their intimate details on a server somewhere. Also, the fact that a corpo would throttle the performance/shut down your waifu if you don't subscribe.

>>22629 >>22603 >just because a few anons scream about the Globohomo from the rooftops. Lol. You're missing the point. I was 'borrowing' from the words of Jesus Christ, and I was suggesting that not only should we be there first with robowaifus, but best too! And then take that information and 'spread it into all the world'. In that way (if it happens in that manner) there's no practical way the GH will be able to make that ominous maymay phone call. The cat will be out of the bag by that point -- too late for them then. >just use the GH's systems bro, we'll be fine with jailbreaks... Again, lol no. The surveillance state would have a field day all over itself if you swalloped that bait hook, line & sinker. I think we'll stick with opensauce H/W & S/W designs instead friend, but thanks. :^)

I'm gonna fudpost because I think the ideas should be considered. To say that the average anon can beat a corpo to the launch of a product and make a better one is pretty naive. If transformers for example were never developed by a group outside of this place, there would probably not be all this tech that is available already. I'd say even if anyone on here had 50 years and unlimited budget they'd still get roflstomped product feature wise by companies in less time. FOSS is usually less pretty and functional than paid software for a reason. Although, the open source robot would be attractive since the corpo one would surely have censorship and surveillance. Speaking of the risks of ownership, I wouldn't doubt a large section of the US could be held hostage in their own homes by a malicious software injection like PC scammers, except it's a fucking irl robot with it's own agency. Quite a scary thought that some foreign hacker could literally have part of a country by the balls and hold people for ransom without ever leaving their border. Maybe there could be a safety switch for this, but if they are already in your house and come for you while you're sleeping, there's not a lot to prevent that. There has to be some kind of protection built in for the user to be safe that's unable to be edited.

>>22631 its kind of a paradox because I'd absolutely not want any piece of code inside my robowqaifu hardcoded by a corpo that I can't change. Especially if the whole code is a black box that I don't know the function of.

>>22631 >To say that the average anon can beat a corpo to the launch of a product and make a better one is pretty naive It isn't, we had this topic several times, they won't even try to build robowaifus for many reasons. Also, open source is safe and functional. We mainly need to control the soft- and hardware making final decisions and possibly making any kind of network connection, but we'll try to keep anything proprietary as low as possible. Which obviously won't work as well for hardware. Whatever, we have at least two threads on safety. Please take the state of conversation on these topics there into account and post there if you want to respond: >>1671 and >>10000

>>22631 Good points, but I'll probably move this convo to our other thread soon. >I'm gonna fudpost Sounds like just glowniggery things, tbh Anon. Why would you want to instill fear here in the board huh? :^) We're all grownups with our eyes open to the evils of the GH. You can bet we've discussed these topics and many other related ones here on the before today.

>>22631 >big tech has us beat on the R&D costs, what if the software is all spyware? IMO the hardest part to develop for anons is the body because you can't git clone a body. Once you have a good body, you can rip the brains out and replace it with a raspi or other SBC. It's all motors and sensors, basic electronics stuff that would be very difficult and expensive to lock people out of.

>software-security/corruption -related: (>>23061)

> conversation-related https://zzzchan.xyz/tech/thread/9161.html#11717

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

>>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

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.