[LIP-4] - Profile Guardian

[donosonaumczuk]

title: Profile Guardian
description: Introduce a safety layer to Lens Protocol profiles
author: Lens Protocol Core Team
status: Draft
type: Protocol
created: 2023-07-01

Motivation

Due to recent increase of phishing activity targeting Lens profiles, we have decided to introduce a safety layer to provide additional security to Lens Protocol profiles.

Specification

1. Disable asset meta-tx functions

Disable the following functions in the Lens Profiles collection (i.e. LensHub smart contract):

• burnWithSig
• permit
• permitForAll

Why?

• Users are used to gasless experience on Lens, so they tend to pay less attention when signing transactions.
• If a user signed a meta-tx message, it will be valid until its expiration date or nonce usage.
• You can check the on-chain state, but you cannot check if somebody possesses a meta-tx signed by you awaiting for future usage.
• Even if a signed meta-tx is not valid right now with guardian enabled, it can become valid when the guardian is disabled in the future.

Signature methods are disabled by reverting when being called.

2. Introduce a 7-day Security Cooldown Period for EOA wallets

This safety mechanism is address-based, meaning that it applies to a given address, and it is inherited by all the Lens profiles owned by it.

Every EOA wallet will have the Profile Guardian enabled by default. Meaning that the following functions will revert as specified:

• approve(address to, uint256 profileId)
  • Reverts if msg.sender has Profile Guardian enabled, except for revoking approvals (with to == address(0))
• setApproveForAll(address operator, bool approved)
  • Reverts if msg.sender has Profile Guardian enabled, except for revoking approval (with approved == false)
• transferFrom(address from, address to, uint256 profileId)
  • Reverts if from (i.e. owner of profileId) has Profile Guardian enabled
• safeTransferFrom(address from, address to, uint256 profileId)
  • Reverts if from (i.e. owner of profileId) has Profile Guardian enabled
• burn(uint256 profileId)
  • Reverts if owner of profileId has Profile Guardian enabled

To use any of the functions mentioned above, the user must explicitly trigger the safety layer disabling by executing the DANGER__disableTokenGuardian transaction, and wait for a 7-day Security Cooldown Period until the Profile Guardian becomes effectively disabled.

We specifically chose the DANGER prefix to draw users' attention and lower the risk of executing this transaction unintentionally.

After the Profile Guardian is effectively disabled, the user can use all the functions mentioned above without the listed restrictions.

The user can enable the Profile Guardian back by executing enableTokenGuardian transaction, it will become effective immediately after the transaction is confirmed.

3. Profile Guardian does not apply to non-EOA addresses

Non-EOA addresses are not affected by this safety layer in order to avoid issues with smart contracts (e.g. NFT protocols or smart wallets) that expect the default plain ERC-721 behaviour. Non-EOA adresses have a higher safety assumption as significant amount of the non-EOAs are multisigs, DAOs or protocols that have a higher threshold of observation from the users and are assumed to remain less affected.

4. Lens ecosystem support

Ecosystem services (including Lens API and others) should track the Profile Guardian status, so Lens applications can warn users about their protection state changes, providing a seamless experience to enable it back if desired. We encourage all Lens applications to do so.

The Cooldown Period is a key piece here, as it gives users a whole week to take measures on their address before any profile can get stolen by a potential attacker.

Copyright

Copyright and related rights waived via CC0.

[joshstevens19]

It makes a lot of sense to protect people by default, even more so when we encourage people to explore new lens apps built; this will allow you to do it safely if you have the guardian on. 💯

[EzR3aL]

In favour. After the recent attacks i think this could be a good start for some safety measurements

[JuanuMusic]

A (very) promising improvement that I'd love to see accepted!

[keiven0219]

Very good move, strongly supported

[ponpocopon]

good idea

[xifengguma]

good proposal

[sinxyz886]

good idea！

[ujjwal-mic]

I agree with the solution!

[Imsunvo]

Great feature, this will greatly improve the security of user data

[rashtrakoff]

Just to make sure I understand, this doesn't protect the users who have their seed phrase compromised right? Because a malicious user can trigger the enableProfileGuardian even if the legitimate user wants to transfer the Lens profile to a safe/uncompromised address.

[joshstevens19]

Just to make sure I understand, this doesn't protect the users who have their seed phrase compromised right? Because a malicious user can trigger the enableProfileGuardian even if the legitimate user wants to transfer the Lens profile to a safe/uncompromised address.

If your seed phrase is leaked then yes now they can do whatever they like. 99% of hacks are bad signatures so this protects mostly all people. That said people should never share their seed phrase and keep it safe at all times.

To add though if your seed phrase was leaked they could not take the profile without waiting 7 days so it be a race in time moment when it unlocks to save it.

[chhotu24]

i'm with it

[DanIsNearby]

Just to make sure I understand, this doesn't protect the users who have their seed phrase compromised right? Because a malicious user can trigger the enableProfileGuardian even if the legitimate user wants to transfer the Lens profile to a safe/uncompromised address.

Yeah but the hacker won't spend a month on the account you can play cat and mouse and finally you will be able to secure the profile it will take long time but most likely possible

[atlalvani]

title: Profile Guardian
description: Introduce a safety layer to Lens Protocol profiles
author: Lens Protocol Core Team
status: Draft
type: Protocol
created: 2023-07-01

Motivation

Due to recent increase of phishing activity targeting Lens profiles, we have decided to introduce a safety layer to provide additional security to Lens Protocol profiles.

Specification

1. Disable asset meta-tx functions

Disable the following functions in the Lens Profiles collection (i.e. LensHub smart contract):

• burnWithSig
• permit
• permitForAll

Why?

• Users are used to gasless experience on Lens, so they tend to pay less attention when signing transactions.
• If a user signed a meta-tx message, it will be valid until its expiration date or nonce usage.
• You can check the on-chain state, but you cannot check if somebody possesses a meta-tx signed by you awaiting for future usage.
• Even if a signed meta-tx is not valid right now with guardian enabled, it can become valid when the guardian is disabled in the future.

Signature methods are disabled by reverting when being called.

2. Introduce a 7-day Security Cooldown Period for EOA wallets

This safety mechanism is address-based, meaning that it applies to a given address, and it is inherited by all the Lens profiles owned by it.

Every EOA wallet will have the Profile Guardian enabled by default. Meaning that the following functions will revert as specified:

• approve(address to, uint256 profileId)

  • Reverts if msg.sender has Profile Guardian enabled, except for revoking approvals (with to == address(0))

• setApproveForAll(address operator, bool approved)

  • Reverts if msg.sender has Profile Guardian enabled, except for revoking approval (with approved == false)

• transferFrom(address from, address to, uint256 profileId)

  • Reverts if from (i.e. owner of profileId) has Profile Guardian enabled

• safeTransferFrom(address from, address to, uint256 profileId)

  • Reverts if from (i.e. owner of profileId) has Profile Guardian enabled

• burn(uint256 profileId)

  • Reverts if owner of profileId has Profile Guardian enabled

To use any of the functions mentioned above, the user must explicitly trigger the safety layer disabling by executing the DANGER__disableProfileGuardian transaction, and wait for a 7-day Security Cooldown Period until the Profile Guardian becomes effectively disabled.

We specifically chose the DANGER prefix to draw users' attention and lower the risk of executing this transaction unintentionally.

After the Profile Guardian is effectively disabled, the user can use all the functions mentioned above without the listed restrictions.

The user can enable the Profile Guardian back by executing enableProfileGuardian transaction, it will become effective immediately after the transaction is confirmed.

3. Profile Guardian does not apply to non-EOA addresses

Non-EOA addresses are not affected by this safety layer in order to avoid issues with smart contracts (e.g. NFT protocols or smart wallets) that expect the default plain ERC-721 behaviour. Non-EOA adresses have a higher safety assumption as significant amount of the non-EOAs are multisigs, DAOs or protocols that have a higher threshold of observation from the users and are assumed to remain less affected.

4. Lens ecosystem support

Ecosystem services (including Lens API and others) should track the Profile Guardian status, so Lens applications can warn users about their protection state changes, providing a seamless experience to enable it back if desired. We encourage all Lens applications to do so.

The Cooldown Period is a key piece here, as it gives users a whole week to take measures on their address before any profile can get stolen by a potential attacker.

Copyright

Copyright and related rights waived via CC0.

highly recommend

[Anyaeneh]

Good proposal.
Let's do it

[lujun5048]

Very cool feature!

[poapify]

Awesome!!! too bad mine was already stolen but I appreciate thoughts are put to protect folks!

[TONIBZH155]

makes sense

[okhaimie-dev]

Love this, plus users have the option to disable it if they don't like that security.

I support 💯

[carstenpoetter]

makes a lot of sense. I'm not a technical person but in favour of it if it works as advertised.

[rashtrakoff]

Just to make sure I understand, this doesn't protect the users who have their seed phrase compromised right? Because a malicious user can trigger the enableProfileGuardian even if the legitimate user wants to transfer the Lens profile to a safe/uncompromised address.

If your seed phrase is leaked then yes now they can do whatever they like. 99% of hacks are bad signatures so this protects mostly all people. That said people should never share their seed phrase and keep it safe at all times.

To add though if your seed phrase was leaked they could not take the profile without waiting 7 days so it be a race in time moment when it unlocks to save it.

I think if the incentive is good enough (famous profile with followers) it's possible the hacker would play that endless game. It's not too hard as well a simple bot can handle the takeover.

[rashtrakoff]

Just to make sure I understand, this doesn't protect the users who have their seed phrase compromised right? Because a malicious user can trigger the enableProfileGuardian even if the legitimate user wants to transfer the Lens profile to a safe/uncompromised address.

If your seed phrase is leaked then yes now they can do whatever they like. 99% of hacks are bad signatures so this protects mostly all people. That said people should never share their seed phrase and keep it safe at all times.

To add though if your seed phrase was leaked they could not take the profile without waiting 7 days so it be a race in time moment when it unlocks to save it.

How about this solution:

A user can delegate some actions of a profile (post, mirror etc) to another address which won't be able to transfer the profile NFT at all. So in tandem with your proposal, have this as well. Users can then have the profile NFT in their hardware wallet or Gnosis safe which would be safer than having them in hot wallets.

Was something like this thought of and if so, any arguments against it?

[Imsunvo]

Just to make sure I understand, this doesn't protect the users who have their seed phrase compromised right? Because a malicious user can trigger the enableProfileGuardian even if the legitimate user wants to transfer the Lens profile to a safe/uncompromised address.

If your seed phrase is leaked then yes now they can do whatever they like. 99% of hacks are bad signatures so this protects mostly all people. That said people should never share their seed phrase and keep it safe at all times.
To add though if your seed phrase was leaked they could not take the profile without waiting 7 days so it be a race in time moment when it unlocks to save it.

How about this solution:

A user can delegate some actions of a profile (post, mirror etc) to another address which won't be able to transfer the profile NFT at all. So in tandem with your proposal, have this as well. Users can then have the profile NFT in their hardware wallet or Gnosis safe which would be safer than having them in hot wallets.

Was something like this thought of and if so, any arguments against it?

I think this is close to the perfect solution 👍

[donosonaumczuk]

Just to make sure I understand, this doesn't protect the users who have their seed phrase compromised right? Because a malicious user can trigger the enableProfileGuardian even if the legitimate user wants to transfer the Lens profile to a safe/uncompromised address.

If your seed phrase is leaked then yes now they can do whatever they like. 99% of hacks are bad signatures so this protects mostly all people. That said people should never share their seed phrase and keep it safe at all times.

To add though if your seed phrase was leaked they could not take the profile without waiting 7 days so it be a race in time moment when it unlocks to save it.

I think if the incentive is good enough (famous profile with followers) it's possible the hacker would play that endless game. It's not too hard as well a simple bot can handle the takeover.

The owner can also use some bot to enable it, as long as it runs once a week.

Anyways, if your seed phrase is compromised, you have a lot of issues, the attacker can start posting with your profile which can harm your identity. It is the worst case scenario, and a more complex solution should be developed for this, maybe something like social recovery.

This proposal is aiming to increase security against getting your profile stolen (mainly through phishing attacks), not against your seed phrase being compromised.

[donosonaumczuk]

Just to make sure I understand, this doesn't protect the users who have their seed phrase compromised right? Because a malicious user can trigger the enableProfileGuardian even if the legitimate user wants to transfer the Lens profile to a safe/uncompromised address.

If your seed phrase is leaked then yes now they can do whatever they like. 99% of hacks are bad signatures so this protects mostly all people. That said people should never share their seed phrase and keep it safe at all times.

To add though if your seed phrase was leaked they could not take the profile without waiting 7 days so it be a race in time moment when it unlocks to save it.

How about this solution:

A user can delegate some actions of a profile (post, mirror etc) to another address which won't be able to transfer the profile NFT at all. So in tandem with your proposal, have this as well. Users can then have the profile NFT in their hardware wallet or Gnosis safe which would be safer than having them in hot wallets.

Was something like this thought of and if so, any arguments against it?

Yes, this delegation feature is already developed for Lens V2, when using it you delegate social permissions (publishing, following, etc) but not asset permissions (approvals, transfers, etc).

Take into account that the security layer proposed by this LIP only applies to EOAs (i.e. does not apply to contracts such as the multisigs).

[rashtrakoff]

Just to make sure I understand, this doesn't protect the users who have their seed phrase compromised right? Because a malicious user can trigger the enableProfileGuardian even if the legitimate user wants to transfer the Lens profile to a safe/uncompromised address.

If your seed phrase is leaked then yes now they can do whatever they like. 99% of hacks are bad signatures so this protects mostly all people. That said people should never share their seed phrase and keep it safe at all times.

To add though if your seed phrase was leaked they could not take the profile without waiting 7 days so it be a race in time moment when it unlocks to save it.

How about this solution:

A user can delegate some actions of a profile (post, mirror etc) to another address which won't be able to transfer the profile NFT at all. So in tandem with your proposal, have this as well. Users can then have the profile NFT in their hardware wallet or Gnosis safe which would be safer than having them in hot wallets.

Was something like this thought of and if so, any arguments against it?

Yes, this delegation feature is already developed for Lens V2, when using it you delegate social permissions (publishing, following, etc) but not asset permissions (approvals, transfers, etc).

Take into account that the security layer proposed by this LIP only applies to EOAs (i.e. does not apply to contracts such as the multisigs).

Is the Lens V2 codebase public yet? Where can I find more information regarding Lens V2?

[donosonaumczuk]

Just to make sure I understand, this doesn't protect the users who have their seed phrase compromised right? Because a malicious user can trigger the enableProfileGuardian even if the legitimate user wants to transfer the Lens profile to a safe/uncompromised address.

If your seed phrase is leaked then yes now they can do whatever they like. 99% of hacks are bad signatures so this protects mostly all people. That said people should never share their seed phrase and keep it safe at all times.

To add though if your seed phrase was leaked they could not take the profile without waiting 7 days so it be a race in time moment when it unlocks to save it.

How about this solution:

A user can delegate some actions of a profile (post, mirror etc) to another address which won't be able to transfer the profile NFT at all. So in tandem with your proposal, have this as well. Users can then have the profile NFT in their hardware wallet or Gnosis safe which would be safer than having them in hot wallets.

Was something like this thought of and if so, any arguments against it?

Yes, this delegation feature is already developed for Lens V2, when using it you delegate social permissions (publishing, following, etc) but not asset permissions (approvals, transfers, etc).

Take into account that the security layer proposed by this LIP only applies to EOAs (i.e. does not apply to contracts such as the multisigs).

Is the Lens V2 codebase public yet? Where can I find more information regarding Lens V2?

It is not public yet, but it will be soon. Stay tuned!

[donosonaumczuk]

Functions have been renamed to enableTokenGuardian and DANGER__disableTokenGuardian respectively, in order to set a generic naming that can be followed by other collections too.

[Dolzyn]

This looks good. But it will looks better when you take my restriction off in Lens Profile. Dunno how to contact you about this. Trying many times...

[vibicer]

Non-EOA addresses are not affected by this safety layer in order to avoid issues with smart contracts (e.g. NFT protocols or smart wallets) that expect the default plain ERC-721 behaviour.

I cannot buy or sell my NFT now, how is it?

[azizyousefi]

perfect idea

[joshstevens19]

you can remove it on lenster settings