2012-07-27 13 views
15

Domyślna wersja ServerManagedPolicy, którą Google udostępnia w swoim numerze License Verification Library, opiera się na odpowiedziach serwera w celu określenia okresu przedłużenia licencji. Powoduje to konieczność przedłużania ważności co kilka dni, bezterminowo. Jest to nie tylko uciążliwe dla użytkowników, ale może stanowić poważny problem dla użytkowników, którzy korzystają z długich okresów bez połączenia. (. Mieliśmy zapytania od użytkownika, który oczekuje, że będzie bez połączenia z Internetem przez kilka tygodni, co jest, co motywuje to pytanie)Czy ta implementacja zasad Google LVL byłaby rozsądnie bezpieczna?

Podsumowując, Szukam algorytmu, który będzie osiągnąć dwie rzeczy:

  1. drastycznie zmniejszyć wymagania dotyczące połączeń w porównaniu do ServerManagedPolicy;
  2. zapewniają ten sam poziom ochrony przed piractwem.

W odpowiedzi na this question algorytm polityka sugerowane jest, aby ignorować razy przewidzianych w odpowiedzi z serwera Google i zamiast korzystać z licencjonowanego okres ważności około miesiąca, z kontroli licencyjnych jest próba co kilka dni (do przedłużyć okres wygaśnięcia, jeśli otrzymano odpowiedź LICENCJONOWANA).

Podczas gdy to podejście częściowo rozwiązuje pierwszy cel, nadal wymaga, aby użytkownicy byli podłączani raz w miesiącu podczas korzystania z aplikacji, aby nie działał (przynajmniej jeden z) naszych użytkowników.

Następujący algorytm osiąga pierwszy cel, ale nie wiem o drugim. Wszelkie komentarze wskazujące na słabości tego algorytmu lub sugestie dotyczące innego podejścia byłyby mile widziane.

  1. Po pierwszym uruchomieniu sprawdź licencję i nalegaj na LICENCJONOWANĄ odpowiedź przed zapewnieniem pełnej funkcjonalności. Po otrzymaniu ustaw stosunkowo krótki okres wygaśnięcia (ale dłuższy niż okres zwrotu, który zapewnia Google Play, obecnie 15 minut). Zarejestruj również okres karencji kilka dni później.
  2. Aplikacja zacznie się ponownie sprawdzać po wygaśnięciu licencji. Jeśli nie uda się połączyć (tryb samolotowy itp.), Będzie działał do końca okresu karencji.
  3. Po upływie okresu karencji nalegaj na drugą LICENCJONOWANĄ odpowiedź, zanim zezwolisz na normalne działanie aplikacji.
  4. Po otrzymaniu drugiej odpowiedzi LICENCJONOWANE, na stałe włączyć wszystkie funkcje aplikacji i nigdy nie zawracaj sobie głowy sprawdzaniem.
  5. Jeśli w dowolnym momencie zostanie odebrana odpowiedź NIEOCYFENCYJNA, należy trwale wyłączyć pełną funkcjonalność. (Użytkownik może oczywiście powrócić do kroku 1, usuwając wszystkie dane aplikacji.)

Dodatkowe punkty:

  • Sugestia powstał rezygnują pierwszy czek licencyjnego i czekać aż do wygaśnięcia okres zwrotu przed sprawdzeniem licencji. Celem nalegania na pierwszą odpowiedź LICENCJONOWANĄ jest zapobieganie exploitowi, gdy po nieudanej próbie licencyjnej użytkownik po prostu zatrzymuje proces aplikacji, usuwa dane aplikacji i ponownie uruchamia aplikację. (Aplikacja zapewnia wartość nawet wtedy, gdy jest używana tylko przez 15 minut).
  • Celem nalegania na drugą odpowiedź LICENCJONOWANĄ jest obejście exploita buy-run-backup-return-restore.
  • Nie pytam, czy sprawdzenie licencji na oddzwonienie jest dobrym pomysłem, czy nie (to właśnie oferuje Google zamiast ich nieaktualnego mechanizmu ochrony przed kopiowaniem). Doskonale zdaję sobie sprawę, że żadna ochrona przed piractwem nie jest niezawodna, a cały mechanizm licencjonowania Google można obejść (w takim przypadku wszystkie pytania dotyczące projektowania algorytmu strategii są nieistotne). Głównym punktem tego pytania jest względne ryzyko (dla nas) i korzyści (dla użytkownika) powyższego algorytmu w porównaniu do innych polityk (takich jak ServerManagedPolicy).
+0

„niewidzialna” przejścia od „zakupiony, nadal wymaga weryfikacji” "zakupione, nie wymaga więcej weryfikacji" ma problemy. Musisz odzwierciedlić to gdzieś w swojej aplikacji, jeśli tylko w niektórych oknach dialogowych ustawień. (Licencja: prowizorycznie gdzieś, że kliknięcie po zamknięciu "okna powrotu" wymusza w tym miejscu czek *), generując komunikat o błędzie, jeśli jest "zbyt wcześnie", aby uzyskać licencję wieczystą. Po weryfikacji 2-giej (automatycznej lub ręcznie), staje się Licencja: wieczna.) – Yakk

+0

@Yakk - Nie jestem pewien, jaki problem widzisz. Czy użytkownik musi mieć zapewnioną kontrolę nad czasem drugiego czeku? –

+1

Ktoś kupuje twój produkt, wiedząc, że "działa w trybie offline". Następnie pobierają go, uruchamiają, działają. Następnie tracą łączność (brak danych, wifi z jakiegokolwiek powodu). 3 dni później ich aplikacja przestaje działać, z małą diagnostyką. Chodzi o to, aby móc powiedzieć "Aplikacja działa w trybie offline * po napisaniu wieczystej licencji *". Jest to (widocznie) ważna zmiana stanu dla klientów: ważna jest wtedy zmiana stanu widoczna dla klientów. – Yakk

Odpowiedz

5

Jeśli chodzi o piractwo, zawsze istnieje ryzyko, nic nie zrobisz, całkowicie temu zapobiegniesz.

W przeciwieństwie do innych ryzykownych produktów, ryzykujesz, że klienci nie będą mogli korzystać z aplikacji, z której nie mogą korzystać.

Spodziewałbym się wielu opinii 0 * od niezadowolonych klientów, którzy nie mogą nawet użyć aplikacji, za którą zapłacili, ponieważ została ona wyłączona, podczas gdy osoby, które otrzymały tę aplikację za darmo, prawdopodobnie nie będą miały żadnych przerw. To tak, jakby kupować DVD i mieć twarz pełną ostrzeżeń o prawach autorskich, gdy piraci otrzymują nieprzerwane oglądanie.

Nalegam na licencjonowaną odpowiedź przy zakupie aplikacji i nie przejmuję się drugą odpowiedzią. Jeśli ktoś znajdzie drogę do jednej odpowiedzi, odnajdzie ich około drugiej sekundy.

Edit: Zgadzam się z kcoppock że licencjonowanego sprawdzić 20 minut po zakupie będzie powodować jak najmniejsze zakłócenia w odbiorze klientów i uniknąć błędów zwrotu już wspomniano

+2

Zatwierdzenie jednostrzałowe podlega bardzo łatwemu i dobrze znanemu exploitowi: 1) zakup aplikacji; 2) uruchomić i uzyskać odpowiedź LICENCJONOWANĄ; 3) wykonaj kopię zapasową urządzenia; 4) zwrócić aplikację (w ciągu 15-minutowego okna zwrotu); 5) przywróć swoją aplikację z kopii zapasowej. Voila - nie kupiona aplikacja, która myśli, że jest licencjonowana. Aby temu zapobiec, musi być co najmniej jedna kontrola licencji po zamknięciu okna powrotu. Powinienem dodać, że chodzi o to, czy proponowana polityka ma więcej piractwa lub innego ryzyka niż polityka domyślna, która jest związana z LVL (co wymaga kontroli co kilka dni, na zawsze). –

+1

Dlaczego po prostu nie opóźnić sprawdzania licencji (pozwalając na pełną funkcjonalność) przez około 20 minut po pierwszym uruchomieniu? Następnie jesteś poza oknem powrotu. – kcoppock

+0

@kcoppock - Tak, to chyba dobry pomysł. Jest zgodny z zaleceniami opublikowanymi [tutaj] (http://www.androidpolice.com/2010/08/24/response-to-a-response-more-on-googles-android-licensing-service/). Prawdziwe pytanie brzmi, czy poleganie na pojedynczej LICENCJONOWANEJ odpowiedzi dostarczonej po upływie okresu ważności naraża nas na większe ryzyko niż, na przykład, domyślne zachowanie 'ServerManagedPolicy'. –

Powiązane problemy