Yes, it's prompted with the particular experiment that is being done on it, with the "I am an interpretability researcher [...]" prompt. From their previous paper, we already know what happens when concept injection is done and it isn't guided towards introspection: it goes insane trying to relate everything to the golden gate bridge. (This isn't that surprising, given that even most conscious humans don't bother to introspect the question of whether something has gone wrong in their brain until a psychologist points out the possibility.)
The experiment is simply to see whether it can answer with "yes, concept injection is happening" or "no I don't feel anything" after being asked to introspect, with no clues other than a description of the experimental setup and the injection itself. What it says after it has correctly identified concept injection isn't interesting, the game is already up by the time it outputs yes or no. Likewise, an answer that immediately reveals the concept word before making a yes-or-no determination would be non-interesting because the game is given up by the presence of an unrelated word.
I feel like a lot of these comments are misunderstanding the experimental setup they've done here.
This seems to be missing the point? What you're describing is the obvious form of introspection that makes sense for a word predictor to be capable of. It's the type of introspection that we consider easy to fake, the same way split-brained patients confabulate reasons why the other side of their body did something. Once anomalous output has been fed back into itself, we can't prove that it didn't just confabulate an explanation. But what seemingly happened here is the model making a determination (yes or no) on whether a concept was injected in just a single token. It didn't do this by detecting an anomaly in its output, because up until that point it hadn't output anything - instead, the determination was derived from its internal state.
I think it’s perfectly clear: the model must know it’s been tampered with because it reports tampering before it reports which concept has been injected into its internal state. It can only do this if it has introspection capabilities.
Sure I agree what I am talking about is different in some important ways; I am “yes and”ing here. It’s an interesting space for sure.
Internal vs external in this case is a subjective decision. Where there is a boundary, within it is the model. If you draw the boundary outside the texts then the complete system of model, inference, text documents form the agent.
I liken this to a “text wave” by metaphor. If you keep feeding in the same text into the model and have the model emit updates to the same text, then there is continuity. The text wave propagates forward and can react and learn and adapt.
The introspection within the neural net is similar except over an internal representation. Our human system is similar I believe as a layer observing another layer.
I think that is really interesting as well.
The “yes and” part is you can have more fun playing with the models ability to analyze their own thinking by using the “text wave” idea.
> 3. Curseforge's website and modrinth both seem to be legit places to get mods from. I personally find the installable Curseforge program itself to be bad and spammy, and would never use that, but the site still lets you directly download the jars you need, and lets you check "Dependencies" to find out what other mods you need.
PrismLauncher, a popular MultiMC fork, has direct integration with Curseforge and Modrinth, while being completely ad-free. Best of both worlds.
A few mods are not available because Curseforge allows mod authors the option to force ad monetization by blocking API access, but these are few and far between.
You still need quite a lot of mixins / modified code to actually do useful things. Mojang isn't always making things unnecessarily extensible, just extensible enough for them to keep updating the game.
> No, It was obfuscated since around 1.8 when you (Microsoft) buy up Mojang Studios. before that? meh, It wasn't.
Huh? This is not true. The very first version released in 2009 was obfuscated with ProGuard, the same obfuscator used today.
The reason Minecraft 1.7 was a popular version for modding was because Forge was taking too long to come out, and the block model system was changed in a fundamental way in the next update. Has nothing to do with obfuscation.
> The motive behind this is probably due to them finding out people can not get their mods/server software updated in-time (due to extra work required) and this leading people being really reluctant to update their versions.
Not really accurate. The Minecraft modding and custom server software ecosystem has more agility right now than it ever had in the past. In the past 5 years, a remarkable shift has occurred: people have actually started updating their game & targeting the latest version. Minecraft 1.21 has the highest number of mods in the history of the game.
> I had no idea that minecraft modders (presumably kids/teens?) [...]
Players who were teenagers when the game first came out are now 29 to 35 years old. It's a pretty ancient game at this point. From my experience, most contemporary modders are in their late 20s.
We're still relying on legacy code written by inexperienced kids, though...
Paper isn’t a mod loader, it uses Fabric under the hood. Also, what makes you think it’s the most popular server? I thought it was fading. I switched my server from Paper to Fabric years ago.
It doesn't use Fabric under the hood, where did you hear that?
> Also, what makes you think it’s the most popular server?
Because it's the only server software that can actually scale and support a long-term server with feature and bugfix stability. Its popularity bears out in what hosting companies say people are most commonly using. Though I'm not sure if there is a specific publicly published statistic to point to to prove this - there is bStats global stats, but it is biased towards the Paper ecosystem.
Fabric is getting close with certain optimization and bugfixing mods, but it's still not there. Paper has a checklist of what optimizations and fixes must be included for a release to proceed, whereas Fabric ecosystem is still a hodgepodge of different things that are only available on specific Minecraft versions.
I've recently been setting up a velocity server network for some friends and friends of friends, and I agree with your findings. I don't have much history on Forge vs Paper vs Fabric vs..... (and found it all very overwhelming, honestly) but from what I can tell, the popular sites like modrinth have communities way more focused around Forge/NeoForge.
Paper does seem to have it's own site for plugins, hangar or something? (Don't have my web history on this PC) but the community support doesn't seem nearly as fleshed out.
It is incredible though, before 1.21 the last time I played around with MC server hosting was probably around 1.8 days, when it seemed like you only had Bukkit and a few plugins for it
Paper is custom server software and could be easily argued to be a mod loader if you consider plugins to be mods (although it’s probably a weak argument since there’s no mixin support built-in, although some large servers have added mixin support to their own Paper forks). However, it does not use Fabric under the hood (it’s based on Bukkit/CraftBukkit). By playercount, it is the largest (custom, standalone) MC server software in the world.
I tend to think the distinction between "plugins" and "server-side mods" is a little pointless these days. I would consider something a "mod" if it's in an environment where it can deeply touch Mojang code and completely transform it if needed. And before we ever had Fabric/Sponge mixins, we had reflection and ASM for doing just this. We still have that, and a lot of Paper plugins make extensive use of reflection - particularly libraries that reflect into netty to hook directly into the protocol are quite common.
You’re right, my bad, Spigot (from Bukkit), not Fabric. I got the impression it’s actually using ~~Fabric~~ Spigot code for this because you’re using plugins compiled for Spigot and both a paper.whatever and spigot.whatever config file, but after looking it up I see that they forked it.
I’m not really clear on mod vs plugin vs mixin, I was just trying to refer to whatever software does the decompilation work rather than just consuming APIs provided by projects that do.
Sounds like it’s correct that Paper didn’t do its own mod API, but incorrect that Paper doesn’t do its own decompilation work.
> By playercount, it is the largest (custom, standalone) MC server software in the world.
Do you have a source on this? Not trying to accuse you of anything, I just know that a few servers claim this, and don’t know if we have reliable numbers.
Transport encryption should be a huge priority for everyone. It's completely unacceptable to continue using unencrypted protocols over the public internet.
Especially for the use case of transferring files to and from the backend of a web host. Not using it in that scenario is freely handing over control over your backend to everything in between you and the host, putting everyone at risk in the process.
How would you know if the transfers were interfered with? Do you take checksums of the files you upload and then check that the files apparently uploaded are the same?
Also, how do you know that there isn't someone performing a MITM (man in the middle) attack? FTP has no mechanism that I know of to verify that you're connecting to the server that you think you are.
It may well be that you're not a sizeable target and that no-one is interested in hacking your site, but that's just luck and not an endorsement of unencrypted FTP.
How would you know that your neighbours aren't secretly spying together on you and interfering with your life in ways you don't notice?
We have to put a limit to paranoia. If things work correctly for decades and there are no signs of foul play after endless real world usage, it's safe to say nobody is hacking our FTP.
It's different if you're a bank or the KGB or the CIA.
> It may well be that you're not a sizeable target and that no-one is interested in hacking your site, but that's just luck and not an endorsement of unencrypted FTP.
Needing an armored car or protection from neighbours is specifically to guard against proximity based exploits and those are very unlikely threats to most people. FTP interception can be easily performed from anywhere in the world with a little bit of DNS poisoning and then perform a MITM attack (or even just alter the data in transit from a malicious wifi hotspot).
It costs approximately zero to use encryption and protect against the FTP exploits, so why continue to use FTP? There's literally no advantage and several possible disadvantages. Just relying on not being hacked before seems a foolish stance to me.
If it's so easily done, then most FTP websites would be hacked every week. But hundreds of millions of people have FTP websites and never get hacked in decades.
I challenge you to select any FTP website of your choosing and make a tiny change to prove that you've hacked it and let me know here.
There's little reason to expect to be run over when you're on a bike, jut like there's little reason to expect your website to be hacked because you use FTP. If you're a normal person.
We have to be proportional when we do risk assessment. Just because it's part of modern programmer faith to be against FTP, doesn't mean it's sensible. Most hackers are just repeating what others have told them, and a lie becomes common sense.
If FTP is considered unsafe, then riding any non-armored vehicle should also be unacceptable.
Not true. Your hosting provider already has physical access to the computer you're connecting to.
Whether or not the connection you're using is encrypted doesn't really matter because the ISP and hosting provider are legally obligated to prevent unauthorized access.
(It's different if you're the NSA or some other state-level actor, but you're not.)
ISPs very frequently do not give a shit about the law. There are so many instances of major ISPs intercepting and modifying traffic, injecting ads, redirecting people to gambling websites, etc. It's not some freak incident involving the NSA targeting you, it happens all the time. All it takes is one bribe.
And what happens if your ISP is compromised without their knowledge? What happens when it's a consumer device such as a router? Don't forget that nearly every TP-Link router has an active malware infection.
It's not just one ISP that you have to trust, it's every single intermediate piece of equipment.
Intercepting traffic is a trivial & common form of compromise, and the problem multiplies by how many different parties you are handing your data to. It is wildly irresponsible to not attempt to protect against this.
"You <-> ISP <-> Bank webpage" is an entirely different security threat model than "You <-> Server you rent from an ISP".
Also, unsanctioned wiretapping is an entirely different criminal offense than stealing leaked credentials.
You can't make blanket statements like that without understanding ISP peering agreements and how data is stored and where.
Let's not pretend like slapping cryptography over L3 is the entirety of being secure. Often (most of the time?) cryptography doesn't even matter much for security.
P.S. Security (prevent stealing sensitive data) and verification (making sure nothing extra is added during transfer) are different problems.
> "You <-> ISP <-> Bank webpage" is an entirely different security threat model than "You <-> Server you rent from an ISP".
...In what world do people rent servers from consumer ISPs? This used to exist in the 1990s, but is nonexistent now.
If this still exists, it's email-only and has already been outsourced elsewhere. No consumer ISP currently in existence is running these sorts of services on their own hardware.
> Also, unsanctioned wiretapping is an entirely different criminal offense than stealing leaked credentials.
I want to be very clear: There are countries that effectively do not have laws that would ever be adequately enforced on ISPs, either because of corruption, a lack of resources in the courts systems, or both. The use of bribery to compel ISPs into intercepting and recording internet traffic is already rampant at scale. You can't rely on the law to protect you when the internet goes across borders.
> Let's not pretend like slapping cryptography over L3 is the entirety of being secure. Often (most of the time?) cryptography doesn't even matter much for security.
Not sure what your point is. Yes, transport security is not the solution to every problem. But it is by far the lowest hanging fruit, the threat modelling is incredibly clear and obvious. There is a reason transport encryption has become universal across every use case imaginable - it's the literal first step to not getting completely pwned before you've even done anything.
> P.S. Security (prevent stealing sensitive data) and verification (making sure nothing extra is added during transfer) are different problems.
And? On the transport level, they have the same solution: TLS. Confidentiality and integrity work hand-in-hand. It's very rare you will need one without the other.
Unencrypted FTP does not give you either of these, and in fact by being limited to password authentication, it helps turn every passive data collection attack into a persistent remote control attack.
> It's completely unacceptable to continue using unencrypted protocols over the public internet.
That is nonsense. The reality is that most data simply is not sensitive, and there is no valid reason to encrypt it. I wouldn't use insecure FTP because credentials, but there's no good reason to encrypt your blog or something.
You're missing the opposite issue - people might not care about your data, but you might well care if their data (e.g. porn sites) was uploaded to your blog.
It's not so much about the data, but protecting your credentials for the server.
I'd argue that most people like knowing that what they receive is what the original server sent(and vice versa) but maybe you enjoy ads enough to prefer having your ISP put more of it on the websites you use?
Jokes aside https is as much about privacy as is is about reducing the chance you receive data that has been tampered. You shouldn't only not use FTP because credentials but also because embedded malware you didn't put there yourself.
This is the usual horseshit people say about this topic when they don't understand it. It's not just about encryption, but authentication (tamper-resistance). Your blog might not contain sensitive information, but if the entire website is intercepted and becomes malware, you're in trouble.
The bad news with FTP in particular is that only one request has to be intercepted and recorded to have persistent compromise, because the credentials are just a username and password transmitted in clear.
> There is a possibility of collisions in the future, we can use the reserved flags as a nonce for known collisions if this ever comes up.
This is a ticking time bomb. Good luck getting folks using this standard to implement this properly when this eventually happens. If this is the contingency for a collision, then a massive non-hash-based list of every combination was probably a better solution to begin with.
Edit: On second look, I'm not sure if binmoji is working properly? The component hash lookup table seems way too short to cover even a fraction of possible combinations, and it doesn't seem like it can properly roundtrip emojis such as this diverse family emoji: https://apps.timwhitlock.info/unicode/inspect?s=%F0%9F%91%A8...
Agreed. I feel that a lookup table can probably map all emojis possible to a uint32 (maybe optimistically uint16, [1] says there's about 4k emojis, does that include skin variations?). And you can add new ones sequentially after so IDs remain stable.
reply