This is also a valid self-contained HTML document. You have to add `;charset=utf-8`, if you need to go beyond ASCII, and for some browsers watch for URI-encoding of some syntactically significant characters (like `#` and `%`, `?`).
Base64 is indeed good to be "safe" and/or somewhat 'conceal' the payload, but it also makes it larger by 1/3 (every three bytes of input become four characters of the base64 output). So taking the risk some devices would not like raw "ASCII dataURI", the QR of the backrooms QR could shave off 738 bytes.
BTW, this is my "HTML sandbox" for testing stuff in a browsers that I summon daily through keyword bookmark to test simple stuff:
Yeah, sadly, top-level dataURIs are increasingly neglected and banished from browsers, mainly because they were misused for scams in the past; for example no modern browser allows navigating to top-level dataURI by clicking a link. Only bookmarks, manual entry, and external invocation (share) work (sometimes).
My pleasure :]
N.b., if you'd like to try fiddling with Backdooms in that Sandbox, either use the "original" HTML payload (with or without `data:text/html,` prefix in the content), or use "verbatim" (`data:text/html;verbatim,` prefix) when trying that last dataURI payload from the comment, otherwise all `%23` would be double encoded, so you'd get wrong colours. ";verbatim" turns off implicit URI Encoding. (It is not part of the tech, just my hacky hatch to be able to test both "true" dataURIs that can be used "verbatim" in URLs, or have convenience of auto-encoding, but have to extract sandbox iframe resulting payload afterwards, for "ejecting" the "project".
I'm saying the primary gateway most iOS users are using for loading a QR code - the camera app - will not present a transition to load your URL in this situation
Whether the resulting HTML game is playable in Safari is a different discussion.
The QR code, as generated, is effectively "not clickable" for most iOS users, unless they are using something other than the most common way to read QR codes on their phone like a 3rd party QR code reading app or similar.
In 2016, that laptop also came with System Integrity Protection - you couldn't change /usr/bin/python if you wanted to. And you still can't to this very day. Changing System-provided python was always against recommendations in prior OS versions because the next OS update could re-replace it at any time.
I agree that it probably contributed to python 2 inertia as it was re-exposing people to the idea that "typing python in the Terminal gets me python 2" and "I just used what I already had" - but it definitely wasn't stopping people installing a newer version.
It depends on where you're authenticating to. If you're authenticating to yourself, then sure a signature is will just be converted to a yes/no and be no better. But if you're authenticating to a server, the server can do the signature verification, whereas a server looking at a yes/no that a client sends would be mostly useless.
The next time you'd like to diagnose, you can reboot into Recovery and use "csrutil enable --without dtrace --without debug" and you should be able to avoid those issues.
One workaround is actually to just cp /bin/whatever to /tmp/whatever and debug that, but in this particular case I needed to follow forks (from zsh to ssh) so that wasn't as easy. Or I guess I could have played games with $PATH. Ah well.
Either way, there is something funny going on with ssh and private keys and their passphrases. Very odd how "-o BatchMode=yes" fails to load encrypted private keys that don't require any user input in normal use. And it's definitively something new because this was never a problem in 10.11 or below.
I think Apple stopped loading the passphrases into the agent automatically. I think they're strictly only loaded from the keychain now, per connection, unless you explicitly use -A to add them to the agent.
In prior versions, it was stored in Login keychain, which was not synchronized.
Additionally, the items were visible in the security command line tool and in Keychain Access, so you could delete them.
The Local Items keychain / iCloud Keychain is a new style keychain that was back ported from iOS. The security and Keychain Access tools have no visibility into it, it's 100% handled by the secd service.
Edit: Ah, sorry, you meant in Sierra specifically. Yes. But I'll leave these clarifying details here for posterity :)
Edit2: Additional detail - in prior OSes, there was a GUI prompt asking if you wanted to store the passphrase in the keychain. This is gone now. It just does it (unless you preemptively edited the ssh config file to disable keychain storage in advance)
Edit3: Can confirm that "ssh-add -K -d" does in fact delete the passphrase from the keychain, even though it may throw an agent error.
> The security and Keychain Access tools have no visibility into it, it's 100% handled by the secd service.
That's not quite true: Keychain Access can write to Local Items keychain, but not everything in Local Items are visible to Keychain Access. Apple changed ssh to store private key passphrases differently than before, in a way that's invisible to Keychain Access. However, you can freely move / copy entries from, say your login keychain, to Local Items with Keychain Access, and vice versa, and they would remain visible.
Fortunately, the Local Items keychain, stored in ~/Library/Keychains/<UUID>/keychain-2.db is just a sqlite3 database, with (presumably) encrypted fields. If you run "ssh -vvv" you can even see the query.
> Edit3: Can confirm that "ssh-add -K -d" does in fact delete the passphrase from the keychain, even though it may throw an agent error.
Huh, I thought I'd tried that before resorting more drastic measures. Or maybe "-d" works but not "-D", hmm or maybe I'd neglected to also pass "-K".
There's an IL interpreter in the mix - it's simulating an app and what it would do based on the opcodes emitted by the compiler for the code you write.
This is indeed in line with existing scripting languages (Lua, Python, etc) which are in the App Store.
But the presentation of it might be too close for comfort for Apple. He's not presenting it as ".NET scripting" but specifically mentioned porting the .NET Roslyn compiler.
It all boils down to the same thing, but I wouldn't be surprised to see an App Store submission reviewer deny it, misunderstanding what's they've read/seen.
I would love to see this develop into a widely adopted standard. Apple uses a similar technology with their Airport Express devices for printer sharing, always been annoyed it was so restrictive in being able to connect to it.
For example, this self-contained webpage: <html><body>Hi!</body></html>
encoded is: data:text/html;base64,PGh0bWw+PGJvZHk+SGkhPC9ib2R5PjwvaHRtbD4=
If you paste that into a browser, it will render "Hi!". Very short and easy.
But if you encode is as a QR code, it won't work in this situation.