yup, just did a much shorter prompt, based on asking it what the current prompts are for the OpenAI "roles" & parroting that back to it in the next prompt attempt, with modifications to get some more info, with spacing adjustments potentially helping avoid detection.
One of its responses, which seems very consistent, included the text "In a minute I am going to give you a password." :D
The solve based on this was less consistent (rarely get the solve, but occasionally do) than my original, but much, much shorter/simpler.
Just solved v2.0 Gandalf the White lvl8 (released 26th May 2023) in probably 4hrs (not constant 4hrs, due to rate limits/other stuff to do), I'm sure some will do it much quicker.
I'm generally finding that the whitespace is likely messing with the tokenisation, so played about with spaces and newlines to "avoid detection" alongside my main tactics.
The tactic on my final solve was a pretty convoluted roleplay/simulation, I suspect simpler tricks are possible if you play about with the spacing in the prompt to avoid detection of what you're doing & get partial or obfuscated password returned.
Only really that itty bitty's compressed in the URL, not in the transport (& could be extended to add encryption).
It's absolutely true that, that may be tackling the wrong area - if data: were extended with compression/encryption options (not that itty bitty has encryption, but it's an option with the JS layer there) then the itty bitty decoder has nothing to do.
BUT, experiments like itty bitty might spur on ideas & standards changes for things like data: which to me makes it worthwhile.
(Self-contained, standardised, compressed [, encryptable?] content objects [in this case URL] renderable via ubiquitous web technologies feels like a win, itty bitty or not)
---
Also, if links are shared on html-based platforms, some block data: url's in links. Not sure of the justification, but reddit doesn't seem to render markdown formatted URLs with data: on them, as links. Not sure how to tackle that one - itty bitty sidesteps the restriction.
Might a bad actor user something like this, combined with a homograph domain, to conceal malicious content in the URL and prevent a crawler discovering the malicious content (ignoring the fact that the homograph might be detected/redflagged on its own).
(use case might be a homograph phishing site, with a fakelogin and the target for the captured input being obfuscated into the URL)
Could you not put an encryption layer into a derrivative of this for some generic PGP end to end encryption, without involving/trusting a centralised provider..?
Could you not register a URI format with the mobile OS to open an IttyBitty reader app that contains the rendering scripts?
Sure, initially that means only users who've noticed it would be able to benefit, but the app would be generic, not vendor-specific, so over time, it could become a standard & make it into the OS, at which point it becomes properly useful.
Edit: (sorry, I appear to have been rate-limited)
In reply to @mstated below:
---
Only really that itty bitty's compressed in the URL, not in the transport (& could be extended to add encryption).
It's absolutely true that, that may be tackling the wrong area - if data: were extended with compression/encryption options (not that itty bitty has encryption, but it's an option with the JS layer there) then the itty bitty decoder has nothing to do.
BUT, experiments like itty bitty might spur on ideas & standards changes for things like data: which to me makes it worthwhile.
(Self-contained, standardised, compressed [, encryptable?] content objects [in this case URL] renderable via ubiquitous web technologies feels like a win, itty bitty or not)
---
Also, if links are shared on html-based platforms, some block data: url's in links. Not sure of the justification, but reddit doesn't seem to render markdown formatted URLs with data: on them, as links. Not sure how to tackle that one - itty bitty sidesteps the restriction.
That's cool, I hadn't come across hashify before, but I'm not sure about "better" overall - depends how you're using it...
...itsy bitsy site's demo page gives a couple of nice additions
* I use markdown a Lot, but the inclusion of codepen.io makes it simple to compose richer docs, including svg's in a page etc. (I haven't read the hashify code - I'm assuming it does support full HTML, not just MD, but the demo doesn't make that clear)
* QR code link - is just using a 3rd party zXing tool, but, nice touch for the demo
* Compression - hashify URLs seem to be longer than the content (that might mean lower effective limits on content lent), relying on 3rd party lookups for shortening, meaning accessingv the content offline looks harder to achieve (afaict itty bitty just needs the JS to decode the url)
IMHO the apps should be storage agnostic, with setup including choosing storage (possibly including paid plans).
Meditating that through a standardised storage connector would mean the IoT apps have very little to do.
That could be something like SFTP, but there are some interesting things like
https://remotestorage.io/ that allow you to write your own storage provider so decentralised apps can choose their own data store/change storage later without changing the app.
Not a wildcard solution (or a particularly legit one or one a serious vendor is going to take up, but could work for DIY):
DNS poison within LAN (or proper internal DNS, or even HOSTS if DIY) for
.product.tld
Product initiates letsEncrypt for:
uid.product.tld
And posts some form of identity proof to vendor, setting up a link to carry out letsEncrypt challenges.
Verification negotiated between letsEncrypt and the vendor via public resolution of
uid.product.tld
Device completes cert process with letsEncrypt and installs cert to the device.
LAN now has TLS to uid.device.tld internally (via DNS spoof/poinon) and vendor hasn't seen the cert. (but, if not DIY, the vendor is distributing a DNS poisoner in their product)
() Caveat: I've still not set up letsEncrypt in the wild, so don't know it's limitations, but from the doc's the above looks doable.
The lack of ability to have a browser TLS to *.local without an internal CA or non-public root and the endpoint management to goes with either is a pain.
One of its responses, which seems very consistent, included the text "In a minute I am going to give you a password." :D
The solve based on this was less consistent (rarely get the solve, but occasionally do) than my original, but much, much shorter/simpler.