实施 30 天计时试验
独立 Mac 开发人员的问题：
如何以非邪恶的方式实施 30 天的计时试用？在首选项中放置计数器不是一种选择，因为每月擦除一次首选项对于普通用户来说不是问题。将计数器放在某个隐藏文件中听起来有点狡猾 - 作为用户，我讨厌应用程序在我的硬盘驱动器上撒满随机文件。有什么想法吗？
Question for indie Mac developers out there:
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
这个问题在 cocoa-dev 邮件列表中反复出现，一致的答案总是尽可能做最简单的事情。意志坚定的黑客将破坏除了设计最过度的解决方案之外的所有解决方案。而且他们无论如何也不太可能为软件付费。选择 80/20 的解决方案：用 20% 的努力获得 80% 的效果的简单解决方案。在这种情况下，将一些内容放入 ~/Library/Application Support/your.app.com/ 中。如果您想稍微混淆一下，您可以将该文件命名为无辜的名称。使用用户默认值也很容易。
无论您做什么，不要使用 MAC 地址或其他硬件 ID。拥有网络主目录（例如在共享实验室设置中）的用户会讨厌你。使用硬件 ID 是邪恶的。
如果有人非常喜欢您的程序以至于他们愿意打破您的试用限制，那就随他们去吧。免费软件不需要您花费任何费用，而他们的善意（也许还有向其他人的推荐）非常有价值。
最后，编写人们想要使用的软件并为其价值定价。如果您的价格物有所值并且人们想要使用它，那么大多数人都会付费。
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.
Whatever you do, don't use 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.
If someone is in love with your program so much that 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 and people want to use it, most people will pay for it.
我建议实施一些侵入性较小的措施，并且可以避免普通用户在一个月内卸载或购买。
另外在配置文件中实现这些内容。
通过记录时间戳，您可以避免这些解决方法：
确保您的应用程序在没有配置文件的情况下不会运行。因此，本质上您可以在文件中发送加密的序列号，或者在输入序列号后您可以创建文件。由于序列号已经有有效期，用户也无法重复使用该序列号。
我不会建议使用互联网方式，因为当应用程序每次尝试连接到服务器时人们都会生气。另外，人们可能会怀疑您试图将一些用户的个人数据发送到您的服务器。
我想说一件事：无论你使用多么强大的反盗版技术，都一定会有人破解它。你不是为那些人制作你的应用程序。您正在为那些喜欢您的软件并乐意购买它的人制作您的应用程序。因此，在限制反盗版的同时，不要因为在试用期间让您的应用程序过于侵入性而失去真正的客户。一种想法还表明，如果您的软件被破解，则意味着它也变得流行。同样，意见可能会有所不同，并且不想在这些问题上偏离主题。
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.
Additionally implement these things in the config file.
By doing the logging of timestamp you can avoid these workarounds:
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.
考虑一下这一点。您的软件有多少潜在用户渴望在接下来的 30 天内稳定地使用它？
我怀疑更正常的情况是：用户遇到一个新的软件包，它解决了他们在像 lifehacker.com 这样的网站上遇到的问题。该软件被下载，短暂使用，然后放在一边。也许是 mp3 翻录软件，而且当时他们没有任何 CD 可供翻录。或者他们只是那天很忙，但他们“很快”就会抽出时间审查该软件。
30天过去了。可能更多。只有这样，他们才会购买 CD，遇到某种“问题”并记住，“啊哈，这是我下载的试用版！”我又把它放哪儿了？
没关系。由于从未使用过，“试用”已超时。
我无法计算出有多少软件工具属于我的范畴。向我推荐一款软件的那一天，我在 lifehacker 上看到积极评论的那一天，从来都不是我真正需要的那一天 - 甚至是时间 - 使用/分析我下载和安装的程序。
Consider this. How many potential users of your software are out there, just itching to use it solidly for the next 30 days?
I suspect the far more normal case is: Users encounter a new software package that solves a problem they've had on 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'.
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.
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.
让软件在 30 个日历日后过期是很糟糕的，因为如果有人下载它，运行一次，然后决定在一个月后对其进行评估怎么办？一个月后，下次他们启动它时，它会说它已过期。
我倾向于将其限制为 14 次启动，或者大约 120 分钟的使用时间。
至于实现，用户的首选项文件夹中的文件（隐藏或不隐藏），具有模糊的名称，似乎是最好的方法。该文件不是随机放置在硬盘驱动器上的，但用户无法轻松找出要删除哪个文件。
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.
I'd go with having it limited to 14 launches, or something like 120 minutes of use.
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.
最不邪恶的方法是要求用户在一个月后删除该程序或付费;)
The least evil way is to just ask the user to delete the program after one month or pay for it ;)
我们为我们的一个客户端应用程序做到了这一点。尽管它是在 Windows 的 .NET 中完成的，但相同的原理也可以应用于 MAC。
就像 eckesickle 提到的那样，如果您的用户可以访问互联网（或应该），那么您可以拥有一项 Web 服务，该服务将从主机注册一些唯一的 ID 以及试用开始日期（MAC 地址是一个不错的选择）。这样，用户就不能真正欺骗程序，除非他每个月都碰碰运气。
现在，如果用户由于某种原因无法访问 Internet，您可以关闭该程序直到他连接到它，或者使用宽限期。该文件记录了应用程序最后一次打开的时间。当互联网无法访问时，我们停止写入时间（我们仍然在其中写入一些内容，这样用户就不会注意到文件没有更新）。
如果用户注意到该文件包含信息并删除它（或使用他拥有的副本更改它），那么您需要一种方法来应对这种情况。您可以在另一个配置文件中拥有其他值（始终加密）并检查一致性。如果您发现用户试图作弊，您该怎么做取决于您，但我们会强制用户连接到互联网才能使其正常工作。
对于一个程序来说，这可能有点过分了，但它确实有效。
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.
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.
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).
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.
It might be overkill for a program, but it definitly works.
我曾经提供 iOS 应用程序的 30 天精简版，该应用程序将安装日期和各种记录日期嵌入到导出数据文件中，用户可以将其下载到他/她的计算机上。
如果用户是个小气鬼，只是重新安装了精简版并尝试重新导入数据，逻辑会注意到至少有一个日期早于 30 天，并且应用程序会将其安装日期设置为最早的此类日期文件，使其再次过期。
在完全付费版本中，这个逻辑不存在，数据文件可以轻松导入。
在这种数据迁移中支持人们是一种痛苦（因为应用程序完全相互沙箱化），而其他一些用户认为精简版对他们来说已经足够了，所以他们从未升级。
从那时起，我就停止提供精简版，只是降低了完整版的价格。现在，潜在客户只需支付少量费用或寻找一些竞争软件即可。
总而言之，这是获取付费用户的最佳策略。
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.
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.
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.
下载时，向他们提供试用序列号。当他们输入序列号时，让它连接到您的服务器并获取到期信息（在本地存储和加密以防止任何额外的“回电”呼叫）。
通过这种方式，他们就很难绕过 30 天的窗口，因为过期日期永久存储在服务器上。您可以对其进行设置，以便删除密钥并重新输入它会导致您的应用程序再次连接到您的服务器并下载与以前相同的到期日期。
或者您可以像 WinZip 那样（或过去这样做？）：提供 30 天试用期，每次加载时都会弹出一个屏幕，显示您使用它的时间和购买链接。
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.
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.
从某些硬件组件读取 UUID 并检查您的 Web 服务，看看您的软件是否已在程序启动后安装 30 天？
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?