> You have to be deeply ensconced inside an impenetrable bubble to do that to yourself.
I largely agree with your point, but I’m afraid you are the one in the bubble. Detecting AI writing is a rare skill, not the norm. It’s glaringly obvious to those of us who use AI a lot, but it’s not that obvious to the average person.
To the point of absurdity in cases – I’ve seen loads of people who hate AI complain about AI online, not realising that the account they are talking to is nothing but a simple spam bot.
My favourite example of this was when Thatcher passed a law banning the broadcast of Sinn Féin. The BBC responded by dubbing the audio with actors’ voices. So you would watch the news and see an interview with Gerry Adams, but you would be hearing an actor speak his words, meaning the BBC were complying with the law by not broadcasting his voice.
This is an article about an encryption software project getting their Microsoft account terminated. It’s not the place to spam a completely off-topic complaint about the AI use of a service completely unrelated to the project.
I sketched out a protocol for this a while back. The root cause of email abuse is that the only thing you need to send email to somebody is knowledge of their email address. We need to change that so that you also need their consent.
The initial email verification sent to you (“click here to confirm your email address”) includes an attachment requesting an auth token. Emails with this attachment get presented to the user in something akin to a friend request for email, with a consent screen describing how they intend to use your email and for how long. Approving the request hands them a Biscuit token.
The sender attenuates this token when sending email to you or when sharing with a third party provider like Mailchimp. Any emails authorised by a token automatically skip all spam filters. This is the carrot for senders to adopt – they can stop worrying about all the deliverability and IP reputation nonsense and can just send direct from their own servers, reversing the centralisation of email and making it more reliable by skipping spam filter heuristics.
All of these emails have reliable provenance and traceability. If a leak / abuse happens, you can revoke the token and any emails sent with it. Senders can also proactively revoke any tokens provided to third-parties in case they were breached, without affecting the sender’s ability to send themselves or through other providers.
Once a critical mass hits, you can auto-deny anything without a token. At this point, all the email you receive is from somebody who has obtained your explicit consent to do so.
It’s not. I give a unique email address to every service I register with, which means I can see who is leaking my email address. Very few of them leak my email address at all, and those that do tend to do so involuntarily through data breaches.
The other main factors in spam are the sleazeballs at Apollo, ZoomInfo, et al., services that use my email address internally for more than I consented (if I use my email address to register for a service, this does not permit that service to add me to their product mailing list), and the spammers who guess email addresses based on LinkedIn info (e.g. name + company domain).
The number of services who appear to take an email address I have given them and sell it appear to be extremely rare.
There’s no real management involved. I set up a wildcard MX record for *.example.com and hand out jim@<some-id>.example.com whenever anything needs my email address. I don’t need to specifically set up an alias. If spam comes in, I look at the To address to determine where they obtained my email address. Fastmail can be configured this way, for instance.
Most mail providers also support plus addresses or wildcard local parts, so you can do jim+<some-id>@example.com or just <some-id>@example.com. Gmail supports plus addresses, for instance. The downside is that some services reject pluses and some spammers strip out the IDs.
Sometimes you also find hidden things lurking accidentally left behind in IPAs and APKs that are nice and juicy and realize they've been shipped on Google Play/App Store for years.
I've found everything from entire copies of internal company manuals to working test credentials for a physical place with a membership barcode in debug logs left inside the app from developers.
Also sometimes changelogs left inside by accident which include things like "It hasn't been sanitized for outside consumption and thus should remain internal
to <company>. Deliver it externally at your own risk of embarassment."
.docx and .xlsx are also just zip files with XML and attachments. The bad thing is that the XML is Word's internal document structure serialized and behavior for some values is only defined in Microsoft's code.
I've worked on docx and xlsx import/export and the public documentation for the formats was sufficient for normal documents (maybe excluding some very exotic features). That was ca 2010.
Well the executable binaries inside IPAs are encrypted, but the IPA bundles themselves are typically unencrypted. You should be able to see unencrypted assets inside of them
Even better, wait until people discover 7zip's 'parser mode' on Windows (especially). Right click a file -> 7zip -> Open archive -> #:e mode. Really fun way to quickly carve out files and snoop around. I use it like a poor man's binwalk to extract firmware files and updates and etc out of things to usual success.
(#:e Parser mode, ignoring full archives, and checks every single byte position of a file for 'start of archive' bytes to parse archives out of a larger file.)
I largely agree with your point, but I’m afraid you are the one in the bubble. Detecting AI writing is a rare skill, not the norm. It’s glaringly obvious to those of us who use AI a lot, but it’s not that obvious to the average person.
To the point of absurdity in cases – I’ve seen loads of people who hate AI complain about AI online, not realising that the account they are talking to is nothing but a simple spam bot.
reply