macos 实施 30 天的计时赛

Implementing a 30 day time trial

提问by svintus

Question for indie Mac developers out there:

独立 Mac 开发者的问题：

How do I implement a 30-day time trial in a non-evil fashion? Putting a counter in the prefs is not an option, since wiping prefs once a month is not a problem for an average user. Putting the counter in a hidden file somewhere sounds a bit dodgy - as a user I hate when apps sprinkle my hard drive with random files. Any ideas?

我如何以非邪恶的方式实施 30 天的计时赛？在首选项中放置计数器不是一种选择，因为对于普通用户来说，每月擦除一次首选项不是问题。将计数器放在某个隐藏文件中听起来有点狡猾 - 作为一个用户，当应用程序在我的硬盘上散布随机文件时，我讨厌。有任何想法吗？

回答by Barry Wark

This issue comes up repeatedly on the cocoa-dev mailing list and the consensus answer is always do the simplest thing possible. Determined hackers will break all but the most over-engineered solution. And they're unlikely to pay for the software anyways. Go for the 80/20 solution: the easy solution that gets 80% effect for 20% effort. In this case, putting something in ~/Library/Application Support/your.app.com/. You might name the file something innocent if you want to obfuscate things just a bit. Using the user defaults is easy too.

这个问题在 cocoa-dev 邮件列表中反复出现，共识的答案总是尽可能做最简单的事情。坚定的黑客将破坏除最过度设计的解决方案之外的所有解决方案。无论如何，他们不太可能为该软件付费。寻求 80/20 解决方案：简单的解决方案，只需 20% 的努力即可获得 80% 的效果。在这种情况下，将一些内容放入 ~/Library/Application Support/your.app.com/。如果您想稍微混淆一下，您可以将文件命名为无害的。使用用户默认值也很容易。

Whatever you do, don'tuse the MAC address or an other hardware ID. Users with a network home directory (e.g. in a shared lab setting) will hate you. Using hardware IDs is just evil.

无论您做什么，都不要使用 MAC 地址或其他硬件 ID。拥有网络主目录（例如在共享实验室环境中）的用户会讨厌您。使用硬件 ID 是邪恶的。

If someone is in love with your program so muchthat they're willing to break your trial limits, let them. The free software costs you nothing and their good will (and maybe recommendation to others) is worth a lot.

如果有人非常喜欢你的程序，以至于他们愿意打破你的试用限制，那就让他们来吧。免费软件不会花费您任何费用，而且他们的善意（可能还会推荐给其他人）非常值得。

Finally, write software that people want to use and price it for its value. If your price is a good value andpeople wantto use it, most people will pay for it.

最后，编写人们想要使用的软件并为其价值定价。如果您的价格物有所值并且人们愿意使用它，那么大多数人都会为此付费。

回答by K Singh

I would suggest to implement few of things which are less intrusive and may avoid a normal user to either uninstall or buy at one month period.

我建议实施一些侵入性较小的东西，并且可以避免普通用户在一个月内卸载或购买。

1. Use a special series of trial-serial number which stores expiry date in it. You can use encrpytion to store expiry date within the serial number.
2. Now create a configuration file which stores data in the encypted format and contain the serial number.

1. 使用一系列特殊的试用序列号，其中存储了到期日期。您可以使用 encrpytion 在序列号中存储到期日期。
2. 现在创建一个配置文件，以加密格式存储数据并包含序列号。

Additionally implement these things in the config file.

另外在配置文件中实现这些东西。

1. Make a note of time/date every time user starts the application.
2. Note the duration of the time application was open.

1. 每次用户启动应用程序时记下时间/日期。
2. 请注意应用程序打开的持续时间。

By doing the logging of timestamp you can avoid these workarounds:

通过记录时间戳，您可以避免这些变通方法：

1. If user reverses the computer date, you would know that app was already run on that day. Say user ran app on 1 and 3 day of month. Now after 30 days reverses the date and sets it to 2nd of month. Now by config file you would know that app already ran on 1 and 3 so user has messed up dates on the computer.
2. Let's say every time user starts your app by first setting date to 5th of the month. By logging your application running time you would see that if the total hours in a day exceed 24 then user is fooling around.

1. 如果用户反转计算机日期，您就会知道该应用程序已在当天运行。假设用户在一个月的第 1 天和第 3 天运行应用程序。现在 30 天后反转日期并将其设置为每月 2 日。现在通过配置文件，您会知道该应用程序已经在 1 和 3 上运行，因此用户弄乱了计算机上的日期。
2. 假设每次用户通过首先将日期设置为每月 5 号来启动您的应用程序。通过记录您的应用程序运行时间，您会发现如果一天中的总小时数超过 24，那么用户就是在胡闹。

Ensure that your app doesn't run without the config file. So essentially you send the encrypted serial number in a file or maybe upon entering the serial number you can create file. Since the serial number already has the expiry date user can't reuse the serial number also.

确保您的应用程序在没有配置文件的情况下无法运行。因此，本质上您将加密的序列号发送到文件中，或者在输入序列号后您可以创建文件。由于序列号已经有有效期，用户也不能重复使用序列号。

I would not suggest the internet way because people get pissed off when app tries to connect to server every time. Plus, one may get suspicious that you trying to send some personal data of users to your servers.

我不建议使用互联网方式，因为当应用程序每次都尝试连接到服务器时，人们会很生气。另外，人们可能会怀疑您试图将用户的一些个人数据发送到您的服务器。

One thing I would like to say: No matter how strong the anti-piracy technique you use, someone is bound to break it. You are not making your app for those guys. You are making your app for people who would like your software and will buy it happily. So have the anti-piracy in limits without losing the genuine customers by making your application too intrusive during the trial period. One thought also says, if your software is getting cracked that means it's getting popular also. Again opinions may differ and would not like to digress on these issues.

我想说的一件事是：无论你使用的反盗版技术有多强，都一定会有人破解它。你不是为那些人制作你的应用程序。您正在为那些喜欢您的软件并乐意购买它的人制作您的应用程序。因此，通过在试用期间使您的应用程序过于侵入性，在不失去真正客户的情况下限制反盗版。一种想法还说，如果您的软件被破解，则意味着它也越来越流行。同样，意见可能会有所不同，并且不想在这些问题上离题。

回答by Chris Becke

Consider this. How many potential users of your software are out there, just itching to use it solidly for the next 30 days?

考虑一下。您的软件有多少潜在用户，只是渴望在接下来的 30 天内坚定地使用它？

I suspect the far more normal case is: Users encounter a new software package that solves a problem they've hadon a site like lifehacker.com. the software gets downloaded, played with briefly, then put aside. Perhaps its mp3 ripping software and they don't have any cd's to rip at that time. Or they're just busy that day, but they'll get round to reviewing that software 'soon'.

我怀疑更为正常的情况是：用户遇到一个新的软件包，解决了他们的问题有像lifehacker.com网站。该软件被下载，短暂播放，然后放在一边。也许是它的 mp3 翻录软件，当时他们没有任何 cd 可以翻录。或者他们那天只是很忙，但他们会“很快”该软件。

30 days pass. Probably more. Only Then do they buy a CD, encounter some sort of 'problem' and remember, 'aha, theres that trial version I downloaded! Where did I put it again?' It doesn't matter. Without ever being used, the 'trial' has timed out.

30天过去了。可能更多。只有这样他们才会购买 CD，遇到某种“问题”并记住，“啊哈，这是我下载的试用版！我又把它放在哪里了？没关系。从未使用过，“试用”已超时。

I can't count the number of software tools that have fallen into that bucket for me. The day a piece of software is recommended to me, the day I see a positive review on lifehacker, is NEVER the day I actually have a need - or even the time - to use / analyse the program I've downloaded and intalled.

我无法计算已经落入该桶的软件工具数量。向我推荐一款软件的那一天，我看到 Lifehacker 正面评价的那一天，从来都不是我真正需要——甚至是时间——使用/分析我下载和安装的程序的那一天。

回答by lucius

Having the software expire after 30 calendar days is bad because what if someone downloads it, runs it once, and then decides they'll evaluate it a month later? Next time they launch it, a month later, it'll say it's expired.

让软件在 30 个日历日后过期是不好的，因为如果有人下载它，运行一次，然后决定在一个月后对其进行评估怎么办？下一次他们推出它时，一个月后，它会说它已经过期。

I'd go with having it limited to 14 launches, or something like 120 minutes of use.

我会同意将它限制为 14 次发射，或者类似 120 分钟的使用时间。

As for implementation, a file (hidden or not) in the user's Preferences folder, with an obfuscated name, seems like the best way to go. The file isn't randomly placed on the hard drive, but the user can't easily figure out which file to delete.

至于实现，用户的 Preferences 文件夹中的文件（隐藏或不隐藏），具有混淆的名称，似乎是最好的方法。该文件不是随机放置在硬盘上的，但用户无法轻易弄清楚要删除哪个文件。

回答by Andreas Brinck

The least evil way is to just ask the user to delete the program after one month or pay for it ;)

最不邪恶的方法是要求用户在一个月后删除程序或付费；)

回答by David Brunelle

We did it for one of our client application. Granted it was done in .NET for Windows, but the same principles can be applied in MAC.

我们为我们的一个客户端应用程序做了它。当然，它是在 Windows 的 .NET 中完成的，但同样的原则也可以应用于 MAC。

Like eckesickle mentioned, if your user have access to the internet (or should), then you can have a web service that will register some unique id from the host computer with the starting date trial (MAC adress is a good one). With this, the user cannot really cheat the program unless he chances his network card every month.

就像eckesickle提到的那样，如果您的用户可以访问互联网（或应该访问互联网），那么您可以拥有一个网络服务，该服务将从主机上注册一些具有开始日期试用的唯一ID（MAC地址是一个很好的）。有了这个，用户就不能真正欺骗程序，除非他每个月都有机会使用他的网卡。

Now, if the user doesn't have access to the Internet for some reason, you can either shut down the program until he connect to it or use a grace period. This file records the last time the app is opened. When the Internet is not accessible, we stop writing the time (we still write something in it so the user doesn't notice the file is not updated).

现在，如果用户由于某种原因无法访问 Internet，您可以关闭该程序，直到他连接到该程序或使用宽限期。此文件记录上次打开应用程序的时间。当 Internet 无法访问时，我们停止写入时间（我们仍然在其中写入一些内容，因此用户不会注意到文件未更新）。

Should a user notice that this file contains the information and delete it (or change it using a copy he has), then you need a way to counter that. You can have some other value in another config file (encrypted always) and check for consistency. What you do if you discover that the user is trying to cheat is up to you, but we force the user to connect to the internet for it to work.

如果用户注意到此文件包含信息并删除它（或使用他拥有的副本更改它），那么您需要一种方法来反驳。您可以在另一个配置文件中设置其他值（始终加密）并检查一致性。如果您发现用户试图作弊，您会怎么做取决于您，但我们会强制用户连接到 Internet 以使其工作。

It might be overkill for a program, but it definitly works.

对于程序来说，这可能有点矫枉过正，但它绝对有效。

回答by Brad Butner

At the time of download, provide them with a trial serial number. When they enter the serial number, have it connect to your server and gets expiration information (stored and encrypted locally to prevent any additional "phone home" calls).

下载时，请向他们提供试用序列号。当他们输入序列号时，将其连接到您的服务器并获取到期信息（在本地存储和加密以防止任何额外的“回拨”电话）。

By doing it this way, you make it fairly hard for them to get around your 30-day window, as the expiration date is permanently stored on the server. You could set it up so deleting the key and re-entering it would cause your application to connect to your server again and download the same expiration date as before.

通过这样做，您将很难让他们绕过您的 30 天窗口，因为到期日期永久存储在服务器上。您可以将其设置为删除密钥并重新输入它会导致您的应用程序再次连接到您的服务器并下载与以前相同的到期日期。

Or you can do it like WinZip does (or used to do it?): Provide a 30-day trial and just pop-up a screen at every load that shows how long you've been using it and links to purchase.

或者您可以像 WinZip 那样（或曾经这样做？）：提供 30 天的试用期，并在每次加载时弹出一个屏幕，显示您使用它的时间和购买链接。

回答by Jason Fuerstenberg

I used to offer a 30-day lite edition of my iOS app that embedded the install date and various record dates in the export data file that the user could download to his/her computer.

我曾经提供我的 iOS 应用程序的 30 天精简版，在用户可以下载到他/她的计算机的导出数据文件中嵌入了安装日期和各种记录日期。

If the user was a cheapskate and just reinstalled the lite edition and tried to re-import the data, logic would notice that at least one of the date was older than 30 days and the app would set its install date to the earliest such date from the file, rendering it expired again.

如果用户是小气鬼并且刚刚重新安装了精简版并尝试重新导入数据，则逻辑会注意到至少有一个日期早于 30 天，并且应用程序会将其安装日期设置为最早的此类日期文件，使其再次过期。

In the full paid edition, this logic didn't exist and the data file could be imported easily.

在完全付费版本中，此逻辑不存在，并且可以轻松导入数据文件。

It was a pain supporting people in this data migration (since apps are completely sandboxed from one another) and some other users felt the lite edition was enough for them so they never upgraded.

在这种数据迁移中支持人们是一种痛苦（因为应用程序彼此完全沙盒化），而其他一些用户认为精简版对他们来说已经足够了，所以他们从未升级过。

I've since stopped offering my lite edition and just reduced the price of the full edition. Now potential customers just have to pay a small amount or go find some competing software.

从那以后我就停止提供我的精简版，只是降低了完整版的价格。现在潜在客户只需要支付少量费用或去找一些有竞争力的软件。

All in all, that was the best strategy for getting paying users.

总而言之，这是获得付费用户的最佳策略。

回答by Fredrik E

Read an UUID from some hardware component and make a check against your web service to see if your software has already been installed for 30-days upon program launch?

从某个硬件组件读取 UUID 并检查您的 Web 服务以查看您的软件是否在程序启动后已安装 30 天？