Earlier I released a token at 0x779084304ff90e8be79d5c4dbd1ca323b9ac555e and it has been listed on the uniswapV3 exchange. Since the wallet was stolen, I did a transferOwnership to a new wallet, but there was no transfer pool. Finally, I published the mnemonic of the old wallet. Someone used setApprovalForAll to transfer the ownership of my pool. How can I get my pool back?
Usually, once an ownership is transferred to a new address, there's no taking back.
Unless the contract specifically allows it, which the Uniswap V3 pool does not.
Related
Apple's new policy requires the possibility to delete an account and all personal information. Imagine this scenario:
User A pays to User B in advance for a service User B provides.
User B deletes their account after getting the money
User A writes to customer support that they haven't received any service but we have absolutely no information on the User B and no way to contact them or inform legal authority on promised and paid services not provided.
How should we deal with this?
If there are situations like this that are applicable to your situation, then simply inform users that in the event of an account deletion some information will be retained via a legal document they can read when they are about to initiate account deletion.
Apple's review team is unlikely to be so thorough but even if they do ask you about it just explain why some user information has to be retained for legal purposes.
Apple states here:
Deleting an account removes the account from the developer’s records, along with any data associated with the account that the developer isn’t legally required to maintain.
Lots of apps are still retaining information after users delete their accounts because of legal requirements. For example, an investment app cannot just erase all your personal information when you delete your account because of compliance regulations.
In your case, you may want to prevent users from deleting their accounts until their transactions have all settled. I have worked on a similar situation, where users cannot initiate deletion until their balance is zero and they have no pending transfers. Have had no issues with App Store Review.
Implementing subscriptions on an iOS app means we want to handle SSEs in case of subscription status change, as to manage the user's rights inside the service.
The Apple documentation doesn't show an explicit customer GUID.
They provide, in each SSE's payload, receipts, e.g. the latest one.
The question is: how can an API server uniquely identify customers?
Should the API server keep track of every receipt, in an inheritance way?
I.e. should the API persist every receipt, and a link to the previous receipt, up to the first
one that was emitted (which can be linked to a customer through the iOS app the user used to initiate its subscription), and re-trace this history on every SSE?
Per this thread, the applicationUsername service-side UUID (used by apple, for "irregular activity checking") isn't a solution, as it isn't provided in receipts or SSEs. The thread hints that using the transaction IDs is still the best way to identify a SSE, as it is ultimately tied to a user, and it is up to the service to keep track of transactions made by the user on the Apple platform for the given service.
Isn't there an easier, more direct, way, to establish the relationship between a SSE, its apple customer, and the service's user?
After digging for a while and asking around, I reached the following conclusion:
There is only one way to tie a transaction event to a user, and that is by the
restoration mechanism one has to implement on their application.
For this reason, you need to at least keep track of original transaction IDs,
so when the restoration mechanism is triggered on your app, you can check the
currently logged user on your app, and call your back-end with the logged user,
and a list of original transaction IDs.
Usually, when a user subscribes, it is mainly done from within your app, so you
can do this link in a trivial way.
But, because you can "re-subscribe" from the AppStore after a while, without
going through your app, Apple may send a SSE to your back-end which would contain
a new (hence unknown) original transaction ID, since this new subscription is
has a new transaction.
In short,
You need to keep at least a DB of original transaction IDs you receive as SSEs
You need to implement the restoration mechanism as to contact your server every
time the app starts, with the list of transaction IDs / original transaction IDs Apple gives you
You need to accept having transactions stored in your backend without a link
to a user (because the user may have re-subscribed without launching the app yet)
I am migrating our organisation's app to a new developer account, for internal reasons. I've learned that upon transferring the app to the new account, and after we release an update for the app from the new developer account, we will incur a one time loss of keychain data.
My concern is, that we cannot afford this loss of data. Due to security reasons and nature of the type of clients using the app.
So my question is 2 part;
1) Is there any way that I can prevent this keychain data loss?
2) If not, what are the alternate strategies I can use to prevent the users from getting logged out during this transition?
Assuming you're talking about a real, full App Transfer I don't think this is possible. Keychains are not just differentiated via the app ID, but also the organization's ID (or more precisely the organization's ID is part of an app ID). Since the app's ID de facto changes with a transfer, iOS will prevent it to look up its old keychain. Not even app groups get around this, as a group cannot consist of apps by different organizations AFAIK. Apple would need to implement a kind of exception to this for at least a certain "migration period", but I doubt that will ever happen (for security considerations).
The only way to circumvent a re-login so that the transferred app can save the credentials in its "new" keychain would be to first have an update for the old, not-yet transferred app and have it save the credentials elsewhere, then have the transferred app look them up from there. I'd strongly recommend against this for security reasons, but if you absolutely must do that, you could upload the credentials somewhere secure (via an encrypted connection, obviously, i.e. SSL). You might even be able to use shared web credentials for this, but I haven't looked into that too deeply, so I am not sure whether both apps can be configured to be associated with that website (they're coming from two different teams, after all, but it might be allowed).
Even then, some users might "miss" the update of the older app before the transfer (and update to the "new" one), then they would have to re-login anyways.
If you follow this idea, be aware that you're "moving around" users' private data in a new way! Considering the recent GDPR fuzz this might even have string legal implications, so check with your company's legal advisors about this, too!
1) There is no way your can prevent data loss, since the App ID Prefix has changed during app transfer TN2311 > A one-time loss in keychain data will occur if you switch your App ID prefix
2)
If you application utilizes Push Notification, you can use the APNs device tokens to remap the user account.
Once the new app is launched:
Send the device token to server
Find the username from your database
Generate a session token (add your own security design here)
Save username + the token in your new Keychain
For those who doesn't allow notification, just force them to relogin
I have an app that involves messaging (and it's a big part of the app). People can text each other through the app, and every message is kept on our server, uncrypted. (We never really thought of encrypting it)
The user has to accept terms when he creates his account and it's all written there, but my question is the following :
Knowing the user supposedly read the terms, is it still legal/allowed by apple to keep all the messages on our servers? We can identify who wrote it and what is written, obviously, but the users can only read his own messaging feed. Is that ok? Or should we run a encrypt algorithm when uploading the message and decrypt it on the reciever side? Or any other relevant idea/solution?
The T&C your working with Apple are documented in iTunes Connect > Contract, Tax, Bank > iOS Paid Applications and iOS Free Applications
TINLA: They don't say anything about how to store the data of your customers (by my brief understanding)
When distributing your App thru App Store as you say have you own Privacy Policy provided. If not then the standard EULA applies. the standard also does not say anything about privacy / encryption.
I have a woocommerce store with a plugin which generates license keys.
The idea is that the user of my app, will enter a license key which will be checked against a server. If it is correct then the app will create a special file/persistent flag some how.
Once activated, the user can reset the device or whatever and the app will simply check to see if this persistent file/flag is there.
My questions are:
Is there a library available specifically for this sort of thing?
If not, what is the best/standard way of doing this so the file can't be copied to another device to fake an activation?
Could I use something untouchable inside the application bundle that isn't a file to do this?
Thanks guys, some guidance or suggestions would be great.
The "standard" way to do it is to have Apple manage the licensing for you via in-app purchasing or subscriptions, they provide a secure implementation for checking if something is paid for, but this may not be an option for you.
If you need to roll it yourself, you need to use assymetric encryption, with a private key on a server that nobody can access (except you) and a public key distributed in the app. You also need the [UIDevice currentDevice].identifierForVendor.UUIDString value on the device, which is a value unique to that device which cannot be changed by the user (unless they jail break).
The server encrypts some data like 2014-03-23,purchased-three-month-license,<device-identifier-for-vendor>,<long-random-number> and gives the encrypted data to the device as the license key.
The device has the public key, and uses it to decrypt the license key. Then it checks the result to see if the date is in the last three months, the device identifier matches the device's actual identifier, and verifies that the long random number is there and at least 10 digits or something (it doesn't matter what the random number is, it just needs to be there).
Anybody who jail breaks their device will still be able to bypass your security. There is no way to prevent this. But it will take the user a lot of work, they'll probably just pay instead.
All the libraries you need for the encryption are built in, but they're low level APIs and a bit complicated to use and it's easy to screw it up. I recommend RNCryptor as a high level wrapper around them.
Also note that if the user uninstalls your app, then re-installs it (or sometimes when Xcode installs a new build) the identifierForVendor will change to a new value. Apple enforces this to protect user privacy, there's no way around it. You will need to have the server re-generate a new license key based on the new identifier... perhaps by asking the user to enter an email address and password. You can prevent piracy by monitoring how many times a particular email address is used. If they generate license keys 5 times in 30 days, then you could flag them as a pirate.
Whatever license key the "woocommerce store plugin" is generating will not work, because it won't be using [UIDevice currentDevice].identifierForVendor.UUIDString as part of the license key generation. Without that value, it's going to be trivial for anybody to pirate your software.
There is no such thing as "something untouchable inside the application bundle". The only such thing is the Secure Enclave in Apple's hardware. And to protect user privacy app developers are not allowed to use it directly. identifierForVendor is the only option.
In older versions of iOS there were more options, but they were abused by advertising companies tracking Apple's customers, and so one by one Apple has blocked access over the years.