In the past I have pointed out that overlaying the ENS name and logo over a user’s selected image will always lead to exploits. Imagine offering for sale mazon.eth with an A inserted into the avatar image in the right place? Can an L be made to look like a 1 using the avatar image? Checks can be put in place to make sure this type of trickery doesn’t turn into buyers getting scammed, but it will be a never ending cat and mouse game.
The solution is simple, just don’t show avatar images anymore.
Ok, but everyone loves their ENS/PFP identity, so what can be done?
The solution I am imagining is to allow owners of names to create a profile attestation NFT that creates an on chain provable profile NFT or ProAt. A ProAt can only be minted if the minter is the owner of both an ENS name and a PFP to be used as the avatar image. ProAts would be non-transferable, so that there would be no way to have them confused for the actual assets.
What happens if the ENS name or PFP are no longer held by the holder of the ProAT? The ProAt would only prove that the owner of the ProAt held the name and PFP at the time of minting, but there could be a challenge feature, wherein anyone could check to see if the owner of the ProAt still held the underlying name and PFP. If the owner no longer held the assets then anyone could burn the ProAt. This process could be automated as well. If any parties were willing to regularly check and pay the gas for burning the ProAts, the system could be kept up-to-date.
The ProAts could be used for admission to events, etc. It might be possible to use other forms of attestation to set a controller address on the ProAt as well, so that it would be possible to demonstrate ownership of a profile without having to posses the actual wallet that controls the asset.
Hmm, someone else said they were having an issue as well on twitter, so I think it wasn’t just me, I reworked the post to delete the part about OpenSea.
Letting users display images under ENS names in marketplaces is dangerous and leads to exploits. The only effective solution is to remove images from ENS names in marketplaces. This will definitely happen with upcoming dedicated ENS marketplaces.
We can still use the metadata preview with avatar images under ENS names in wallets and dapps though? The problem with this is that ENS ends up having to choose between trying to verify the ownership of avatar images or letting people put whatever they want as the avatar image. The latter seems to make more sense for a protocol, but it will then not serve as a verified identity, i.e. PFP NFT + ENS name. With the former, it will make it harder for people to use a normal headshot or other standard images, and might lead people to spend more money on gas, making 1-of-1 NFTs just to use as the background image of their name.
The solution is to first get rid of preview images behind domains.
Next create a service for ProAts where people can mint an NFT that attests to their identity using only ENS names and verified ownership of avatar NFTs. ProAts are not ENS domain names, they are something entirely different and cannot be transferred in a wallet for example. Finally if people want to set their ENS avatar image to whatever they want, services can pick it up and use the avatar image in the traditional way, where the avatar image is placed to the side of the name, e.g., the way twitter does it.
I don’t really agree - it’s deliberately very difficult to create a misleading avatar image. Names are left-aligned, and outlined, both to make this harder.
I don’t understand what relation your proposal has to this, though.
Another problem that can be solved by ProAts is the problem of having to use the actual wallet that owns the assets to get into events or token gated apps. With ProAts it is possible to set the “owner” address to something other than the owner of the underlying assets. That “owner” address is authorized to use the ProAt, by the owner of the underling assets. In this way it is possible to lend identities to others as well. An event can either accept or reject this type of arrangement, since everything is visible on chain.
I think the easiest hack is to add an i to the front of a word, so ndia.eth becomes india.eth. The alignment is not so noticeable with only adding an i to the front of the word.
I did notice the drop shadow now, which I guess stops anyone from touching up a letter with white.
A simple solution to fixing the add an i to the front of the word attack, is instead of using a drop shadow use a semitransparent black box background to the text that extends out to the left of the text by at least a character width.
This was being done and I let opensea know, as well as reporting those items that did it. I let the 100kclub and 10kclub know of this scheme and advised to confirm on ENS.
Seems like it’d be much easier to solve this by just changing the preview the metadata service generates to put the ENS name underneath the profile image instead of overlayed on top of it, right?
There is another hack which this won’t fix, misspellings with pictures. A good example would be tyranosaurus.eth with a picture of a Tyrannosaurus. The picture helps to validate the misspelling, and will inevitably lead to people buying misspellings. I think the only solution is to remove images from domain listing, and create verified profile attestation NFTs.
I mean, at a certain point you can’t protect people from just being careless lol
I think I’m as lost as @nick.eth , why would attestations solve this case? Wouldn’t it be trivial for me to copy/paste the JPEG, create a new NFT I do actually own that has the same image, and have a “valid” PFP NFT with the misspelled name?
Additionally, why couldn’t I do the same thing with the “l” fake ENS name letter image? The user would now have to make sure it’s the right ENS name and the legit NFT collection with the correct contract address, wouldn’t they? When in reality, all they really have to check today is looking at the actual ENS name and seeing if it’s the right one they want versus just looking at the image.
@Premm.eth do you have examples of such attack happening in the wild or is just theoretical? While I think your point about ndia.eth and gloo.eth are clever, I’m not sure they’d be enough to fool someone as the actual name is always visible on marketplaces. It seems it would only affect someone who did absolutely no checks when buying a name, maybe just took a glance at the preview and clicked buy.
Avatars are a very popular feature and I wouldn’t take it down based on a theoretical attack that isn’t a real problem at the moment.
If the problem is to verify that an NFT truly belongs to the user, and it’s a verified collection, I think the other proposal above highlighted by @serenae solves the problem better than any NFT attestation.
ProAts are very similar to Lens protocol profiles, and they could be made to be compatible with Lens protocol or other distributed social graphs. It is also possible to change the profile standards as needed and allow users to upgrade their profiles without changes to the underlying assets.
/**
* @notice A struct containing profile data.
*
* @param pubCount The number of publications made to this profile.
* @param followNFT The address of the followNFT associated with this profile, can be empty..
* @param followModule The address of the current follow module in use by this profile, can be empty.
* @param handle The profile's associated handle.
* @param uri The URI to be displayed for the profile NFT.
*/
struct ProfileStruct {
uint256 pubCount;
address followNFT;
address followModule;
string handle;
string uri;
}
ProAts could be managed by a DAO or multiple DAOs. It is inevitable that there will be client facing social media apps that decide only to include safe verified profiles into their client side applications. A DAO that manages their own members profiles is able to decide which type of profiles can and cannot be created. Web3 Social media apps could choose to include all the members of a trusted profile DAO, therefore decentralizing the problem of verified social media handles. There may be client facing apps that allow for any profile image, including spoof NFT avatars and fake ENS names with hidden characters, but these type of apps will probably not be the most popular.
I expect the social profile which includes a “handle” and a “uri” to become a standard. ProAts build upon this standard and include additional features including lending or delegating a profile to a mobile wallet or third party, verified NFTs, and ENS names.
ENS names will become very valuable assets in the future, and for this reason, marketplaces will continue to limit what can be done with an ENS name within a marketplace. I expect that this will include not showing avatar images. I could of course be wrong about this, and I also love avatar images, but I do think that it will be necessary at some point the in the future to abstract profiles away from the underlying ENS name asset.
Ok, but now is this a solution to an exploit, or a feature you think would be cool? @AvsA gave a pretty compelling challenge to reasoning that seems to have been ignored.
I haven’t seen anything in this thread yet that creates a strong argument for why attestations are necessary as an anointed ENS project.
With a profile attestation it would be possible to add tickets to that profile that are stored in a vault, but are attached to the user.
The other reason it makes sense to use a profile system is that it is possible to change a .eth name and still maintain the same profile data.
A ProAt can have a controller address, which can be a hot wallet. For ticketed events it would be possible to show when the controller address was updated, and if it was updated during the event, deny entry. This would prevent already admitted users from changing the controller address of their ProAt to their friend’s address to get other people in the door as well.
What an event may want to avoid is NFT holders selling or renting access to their events, but this is already possible using collateral. If someone provides enough collateral, then it is possible to lend the NFT to anyone, getting them into an event, even if they are really not owners of the NFT membership pass. Later if the membership pass is not returned then the lender would keep the collateral.
If the ENS name is transferred, you don’t need attestations to easily show that to the ticket checker at an event. Any UI can easily lookup the controller address and see if it matches an original address. But really, it seems it’d be simpler if the ticket was attached to a wallet and non-transferrable, for the use-case outlined.
I’m not sure any of the use-cases you’ve outlined are actually the use-case for attestations. Usually, attestations are actually about proving some attribute without revealing the underlying data. It’s about privacy.
But at the very least, I’m still lost on why we’re talking about this in the context of ENS Maybe I’ve missed something, though!
Chatterjee said that the cumbersome use of long wallet addresses — the public key which, on Ethereum, begins with 0x — remains a barrier to adoption. To reduce complexity, the Coinbase Wallet will allow a user to claim an Ethereum Name Service (ENS) address for free. ENS is just one of several services Coinbase plans to integrate, a spokesperson told Blockworks, to address problems around Web3 identity.
To alleviate privacy concerns, Coinbase proposes to become a secure provider of know your customer (KYC) verification, which can be passed on to third-party dApps while maintaining user privacy, using zero-knowledge proofs (ZKP). To do that, the wallet will let developers access an open ZKP SDK, which should provide verification for required data — such as meeting a minimum age requirement — without revealing a user’s specific details.
Maybe I’ve missed something, though!