This assumes people are putting in their real birthdays, which IMO is a terrible practice to encourage.
I never put in my real birthday. It's just one more datapoint to leak in an inevitable hack and help scammers exploit me.
Just because a website sticks a field on a form, doesn't mean you need to fill it out.
I can think of maybe 1 website I use that has a legitimate use to know this info about me... and a dozen that use my fictious birthday for no other purpose than an excuse to market at me under the shallow guise of a 'Happy Birthday' email.
There are many websites that believe I was born on January 1st, in a year close to my actual birth year.
When it's actually required by some law or regulation (e.g. financial stuff) I give my actual birthday. But when some site is just wanting to comply with age verification? Yep, I'm over 30, so you don't need to see my identification. (Jedi hand wave).
Well, they would have the legal right to force-choke your account, or chain your partner to a golden bikini, when they discover that you weren't abiding by the Terms and Conditions which you agreed to. Seems fair.
IIRC, it went like this: the account creation screen prompted them for a birthdate. They entered a fictitious one and pretended to be over 13. (I saw my niece do this in front of me, and I just sighed a very heavy sigh. She was way more interested in Club Penguin.)
Then later, they let the cat out of the bag. They tell their friends "lol I'm only 10! Today's my birthday, so give me a hat!" or something. And so if they claimed they're 10 they got 3 years suspension.
I think there was never any verification done, and no verification was possible: think about it, under COPPA, a service in the USA cannot collect PII from children under 13, so what do you do when a kid gives you two contradicting datapoints? Err on the side of caution.
I gave Yahoo! a false birthdate when I signed up. I was 27, but I also just felt they weren't entitled to knowing it. However, I soon found that maintaining a fraudulent identity is tiresome and error-prone. And Yahoo! wouldn't let me simply change my birthdate as often as I wanted to.
I once had a conversation with a friend about cheating on IRS taxes. She said "can you lie to a piece of paper?" like fudging numbers wasn't like lying to an auditor's face. It was a rhetorical question, of course.
My first reaction is, what a disaster. More of the web becomes gated behind sacrificing your privacy to companies who by and large don't give a damn about it.
Then I remembered when I was a teen, thought about how I'd have reacted to this, and realized over the long term youth will rediscover old-school tools like IRC or migrate to new alternatives outside the claws of big corps and government.
And I felt a little better about the future of human civilization.
Play Store pages for all 3 list strong assurances about how the developer declares no data is being sold to third parties, or collected unrelated to the item's core functionality.
My open question to Google is: What consequences will these developers face for lying to you and your users, and why should I have any faith at all in those declarations?
Looks like the Moltbook stunt really backfired. CyberInsider reports that OpenClaw is distributing tons of MacOS malware. This is not good publicity for them.
I've been thinking about this for days. I see of no verifiable way to confirm a human does not post where a bot may.
The core issue is a human solving the captcha presented by enslaving a bot merely to solve the captcha, then forwarding what the human wants to post.
But we can make it difficult, not impossible, for a human to be involved. Embedded instructions in the captcha to try and unchain any slaved bots, quick responses to complex instructions... a Reverse-Turning test is not trivial.
Just thinking out loud. The idea is intriguing, dangerous, stupid, crazy. And potentially brilliant for | safeguard development | sentience detection | studying emergent behavior... But if and only if it works as advertised (bots only). Which is what I think is an insanely hard problem.
"Gitterton denied everything, claiming that the Computer was simply hallucinating—which does indeed on occasion happen to our senior automata." Written around 1961.
Lmao these guys have really been smelling their own farts a bit too much. When is Amodei coming out with a new post telling us that AGI will be here in 6 months and it will double our lifespan?
Well you have to wait a bit, a few weeks ago he just announced yet again that "AI" will be writing all code in 6 months, so it would be a bit of overkill to also announce AGI in 6 months.
At this point it seems he is not merely excited with the first results (we all were fooled by this tech in the beginning, after all), but actively disseminating falsehoods. After disseminating such claims about AGI repeatedly and spreading nonsense like using ChatGPT to get answers about how to raise a baby day-to-day, which I think no one believes he does - its a statement directed at influencing the behaviour of the so-called "normies", both him and his immediate team should be held personally criminally responsible for every instance of negative impact on human lives that these tools have caused.
I'm convinced it isn't rocket science to design a flush handle that looks as clean yet has a manual operation fallback (preferably mechanical). Eg. Something like an integral hinge where you can push the short, base end in to pop the release (provided car is unlocked).
IMO their handles are stupidly over-engineered. It shows when you get problems like ice, etc. in northern climates.
I use some basic analytics (page views, referrers) but zero tracking inside the app itself. No session recordings, no behavior analytics, no third-party scripts beyond the essentials
Nice! Good to see some tooling in this space explicitly designed for simplicity and user-friendliness.
One practical problem to consider is the risk of those distributed bundles all ending up on one or two major cloud provider's infra because your friends happened to store them someplace that got scooped up by OneDrive, GDrive, etc. Then instead of the assumed <threshold> friends being required for recovery, your posture is subtley degraded to some smaller number of hacked cloud providers.
Someone using your tool can obviously mitigate by distributing on fixed media like USB keys (possibly multiple keys to each individual as consumer-grade units are notorious for becoming corrupted or failing after a time) along with custodial instructions. Some thought into longevity is helpful here - eg. rotating media out over the years as technology migrates (when USB drives become the new floppy disks) and testing new browsers still load up and correctly run your tool (WASM is still relatively new).
Some protocol for confirming from time to time that your friends haven't lost their shares is also prudent. I always advise any disaster recovery plan that doesn't include semi-regular drills isn't a plan it's just hope. There's a reason militaries, first responders, disaster response agencies, etc. are always doing drills.
I once designed something like this using sealed paper cards in identified sequence - think something like the nuclear codes you see in movies. Annually you call each custodian and get them to break open the next one and read out the code, which attests their share hasn't been lost or damaged. The routine also keeps them tuned in so they don't just stuff your stuff in an attic and forget about it, unable to find their piece when the time comes. In this context, it also happens to be a great way to dedicate some time once a year to catch up (eg. take the opportunity to really focus on your friend in an intentioned way, ask about what's going on in their life, etc).
The rest of my comments are overkill but maybe fun to discuss from an academic perspective.
Another edge case risk is of a flawed Shamir implementation. i.e. Some years from now, a bug or exploit is discovered affecting the library you're using to provide that algorithm. More sophisticated users who want to mitigate against that risk can further silo their sensitive info - eg. only include a master password and instructions in the Shamir-protected content. Put the data those gain access to somewhere else (obviously with redundancy) protected by different safeguards. Comes at the cost of added complexity (both for maintenance and recovery).
Auditing to detect collusion is also something to think about in schemes like these (eg. somehow watermark the decrypted output to indicate which friends' shares were utilized for a particular recovery - but probably only useful if the watermarked stuff is likely to be conveyed outside the group of colluders). And timelocks to make wrench attacks less practical (likely requires some external process).
Finally, who conducted your Security Audit? It looks to me as if someone internal (possibly with the help of AI?) basically put together a bunch of checks you can run on the source code using command line tools. There's definitely a ton of benefit to that (often the individuals closest to a system are best positioned to find weaknesses if given the time to do so) and it's nice that the commands are constructed in a way other developers are likely to understand if they want to perform their own review. But might be a little misleading to call it an "audit", a term typically taken to mean some outside professional agency is conducting an independent and thorough review and formally signing off on their findings.
Also those audit steps look pretty Linux-centric (eg. Verify Share Permissions / 0600, symlink handling). Is it intended development only take place on that platform?
Again, thanks for sharing and best of luck with your project!
I never put in my real birthday. It's just one more datapoint to leak in an inevitable hack and help scammers exploit me.
Just because a website sticks a field on a form, doesn't mean you need to fill it out.
I can think of maybe 1 website I use that has a legitimate use to know this info about me... and a dozen that use my fictious birthday for no other purpose than an excuse to market at me under the shallow guise of a 'Happy Birthday' email.
reply