Backpack send usage from you server. You are warned. #267
-
Hi Backpack, Because you send server usage to your stats api? If you do this you need to explain it on your documentation. I don't need to show you where I use backpack. Detect used unlicensed is only an excuse. `
` |
Beta Was this translation helpful? Give feedback.
Replies: 0 comments 4 replies
-
Hello @dgironella ! Indeed. It's a known fact for everybody, atleast I tougth it was, mainly because it's open in the code, cleary visible (no obfuscation or whatsoever), also very noticeable of what is collected and we also state it in our Privacy Policy: https://backpackforlaravel.com/privacy-policy#the-data-we-collect Our random usage stats ensures we don't actually have any kind of accurate data in terms of value, the value is only for us internally and the main reason for that was indeed licencing problems, but also helps knowing server specs where backpack is beeing used, software version etc. One can argue that if we get more requests from domainA than domainB we can guess that domainA have more traffic than domainB, but well, Alexa and many other website rank engines are probably a better source for that information than our own analytics. 🙃 We are not in the data analytics business, that's why we don't care about data accuracy in terms of usage as you define. I talked with @tabacitu about this, and I think we both agree that in v5 (we did a core split), we migth be able to make this optional, since now our paid product is close-sourced, in contrast with 4.1 where paid/non-paid users used the same codebase and pirated the hell out of Backpack. And if you think "licencing" is not a good reason for it, please have a look on public Backpack usage stats in Packagist for example, you will imediatelly see that there is NO-WAY so many people are working on "non-comercial" projects with Backpack, otherwise we would be a team of 5~10! That said, I don't think there is nothing alarming here, but you migth have another interpretation of it. Me and @tabacitu will be taking this discussion further about making it optional now in v5 Thanks for raising the issue 👍 |
Beta Was this translation helpful? Give feedback.
-
Hey @dgironella , Sorry to have caused you anger or disappointment. I agree - we can probably do a better job of explaining it. Maybe you can help us with that. Where in the docs would you have expected to read that? Then again, like @pxpm said, now that Backpack\CRUD v5 is free and open-source... it's a bit weird to have it there at all. So we could make it optional... or move it to We could:
We can't do (A), because we still need the stats in Backpack\PRO, to see who's bought just a Single license but is using it in multiple projects. So let's choose between B or C. IF we do (B), and make it optional/configurable in
IF we do (C), and move it to
I think I prefer option B. It has more benefits, it's more transparent and more configurable. You? PS. For PRO users, this will probably be a lot more transparent in the future, anyway. We plan to show all domains that are using their tokens, in their Backpack account. That will not only make it super-clear that Backpack's sending usage stats. But it will also allow them to see if their tokens are being used by someone else. It's something a lot of people have asked for, and we plan to do it. We just never got to it. |
Beta Was this translation helpful? Give feedback.
Thank you for answering @pxpm - I only feel the need to add one two observations for @dgironella :
(1) Why is that there? To detect unlicensed usage, like its docs say, of course. BUT ALSO, to have a record of what domains are using Backpack in production - what versions and in what combinations. This wasn't our intention at first, it was a side-effect. But it was particularly useful in March 2021, when there was a security issue for those using SQL Server. Thanks to those records, we were able to identify who is using SQL Server + Backpack 4.1.17-4.1.34 in production, and contact them directly. And not only did we contact the people who bought Backpack. We even contacted people who were p…