IEEE WP MOBILE ADWARE-2015 en White Paper - SA Industry Connections and AMTSO Mobile Adware Guidelines (1 0).pdf

《IEEE WP MOBILE ADWARE-2015 en White Paper - SA Industry Connections and AMTSO Mobile Adware Guidelines (1 0).pdf》由会员分享，可在线阅读，更多相关《IEEE WP MOBILE ADWARE-2015 en White Paper - SA Industry Connections and AMTSO Mobile Adware Guidelines (1 0).pdf（8页珍藏版）》请在麦多课文档分享上搜索。

1、 IEEE-SA Industry Connections fitness for a particular purpose; non-infringement; quality, accuracy, effectiveness, currency, or completeness of the Work or content within the Work. In addition, IEEE-SA and AMTSO disclaim any and all conditions relating to results and workmanlike effort. The Work is

2、 supplied “AS IS” and “WITH ALL FAULTS.” Although IEEE-SA and AMTSO believe that the information and guidance given in the Work serve as an enhancement to users, all persons must rely upon their own skill and judgment when making use of it. IN NO EVENT SHALL IEEE-SA OR AMTSO, NOR ANY OFFICER, DIRECT

3、OR, AFFILIATE OR MEMBER OF EITHER IEEE-SA OR AMTSO, BE LIABLE FOR ANY ERRORS OR OMISSIONS OR DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO: PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION

4、) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THE WORK, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE AND REGARDLESS OF WHETHER SUCH DAMAGE WAS FORESEEABLE. Further, informa

5、tion contained in the Work may be protected by intellectual property rights held by third parties or organizations, and the use of this information may require the user to negotiate with any such rights holders in order to legally acquire the rights to do so, and such rights holders may refuse to gr

6、ant such rights. Attention is also called to the possibility that implementation of any or all of the Work may require use of subject matter covered by patent rights. By publication of the Work, no position is taken by IEEE-SA or AMTSO with respect to the existence or validity of any patent rights i

7、n connection therewith. IEEE-SA and AMTSO are not responsible for identifying patent rights for which a license may be required, or for conducting inquiries into the legal validity or scope of patents claims. Users are expressly advised that determination of the validity of any patent rights, and th

8、e risk of infringement of such rights, is entirely their own responsibility. No commitment to grant licenses under patent rights on a reasonable or non-discriminatory basis has been sought or received from any rights holder. The IEEE policies and procedures under which this document was created can

9、be viewed at http:/standards.ieee.org/about/sasb/iccom/. The AMTSO policies and procedures under which this document was created can be viewed at http:/amtso.org. The Work is published with the understanding that AMTSO and IEEE-SA are supplying information through the Work for general education purp

10、oses only, and are not attempting to render engineering or other professional services. If such services are required, the assistance of an appropriate professional Copyright 2015 IEEE and Anti-Malware Testing Standards Organization, Inc. All rights reserved. No part of this document may be reproduc

11、ed in any form, in an electronic retrieval system or otherwise, without the prior written consent of the publisher. iii should be sought. IEEE-SA and AMTSO are not responsible for the statements and opinions advanced in the Work. IEEE-SA and AMTSO believe the information in the Work is accurate as o

12、f its publication date; such information is subject to change without notice. IEEE-SA and AMTSO are not responsible for any inadvertent errors. The Institute of Electrical and Electronics Engineers, Inc. www.ieee.org. Anti-Malware Testing Standards Organization Inc. www.amtso.org Published December

13、2015. Printed in the United States of America. IEEE is a registered trademark in the U. S. Patent & Trademark Office, owned by The Institute of Electrical and Electronics Engineers, Incorporated. PDF: ISBN 978-1-5044-0068-8 STDVA20493 IEEE prohibits discrimination, harassment, and bullying. For more

14、 information, visit http:/www.ieee.org/web/aboutus/whatis/policies/p9-26.html. Find AMTSO standards and guidelines at: http:/amtso.org To order IEEE Press Publications, call 1-800-678-IEEE. Find IEEE standards and standards-related product listings at: http:/standards.ieee.orgCopyright 2015 IEEE and

15、 Anti-Malware Testing Standards Organization, Inc. All rights reserved. No part of this document may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written consent of the publisher. 1 IEEE-SA Industry Connections & AMTSO Mobile Adware Guidelines Introduc

16、tion This document sets out guidelines for advertising-supported software on mobile devices. These guidelines are intended to assist developers of both apps and advertising modules designed to integrate into third-party apps to help ensure that the advertising components operate in an acceptable man

17、ner and are presented to users clearly and fairly. It should also serve as a guide for users wishing to evaluate the approach taken by a given app, to help them decide whether it is providing all the information they require to make an informed decision on whether or not to use it. This document is

18、not a comprehensive listing of all issues related to mobile advertising. Unless otherwise defined herein, all terms included in this document are used with their common meaning. To order IEEE Press Publications, call 1-800-678-IEEE. You can find IEEE standards and standards-related product listings

19、at: http:/standards.ieee.org. AMTSO documents are best read in conjunction with AMTSOs “Fundamental Principles of Testing” and other documents on the AMTSO documents page at http:/amtso.org/documents.html. The Problem Our mobile app ecosystems rely heavily on “free” software. With many users unwilli

20、ng to pay up-front for apps, many app developers in turn rely on advertising to monetize their apps and fund the work that goes in to creating and maintaining them. To assist with this process, many advertising “frameworks” have evolved to simplify the process of including advertising in apps. Howev

21、er, our mobile devices hold a wide range of sensitive information about us, and much of that information is of great interest to advertisers who wish to target their messages to the right audiences. Advertisers are willing to pay more for this information than for merely displaying advertising alone

22、, so there is considerable incentive for app and ad framework developers to gain access to this data. Furthermore, in many cases revenue is paid on a per-click model, encouraging more aggressive ways to get users to follow advertising. Occasionally, underhanded methods are used to force or fake “cli

23、cks”. There are also other ways to make money directly from mobile devices, such as making phone calls or sending SMS messages, which may be taken advantage of by the most serious offenders, again without the proper consent or understanding on the part of the user. While most developers operate open

24、ly and ethically, there are inevitably some who will go to extreme lengths to obtain as much data as possible while remaining both within the legal limits and those limits set out by mobile platform providers. The increased yield from underhanded practices puts pressure on those operating fairly to

25、take advantage of more devious techniques. Users find themselves increasingly at risk of being tricked into granting apps access to highly-Copyright 2015 IEEE and Anti-Malware Testing Standards Organization, Inc. All rights reserved. No part of this document may be reproduced in any form, in an elec

26、tronic retrieval system or otherwise, without the prior written consent of the publisher. 2 sensitive information and device functions and having their devices and data misused by third parties in ways that could cost them money as well as privacy. These guidelines aim to set out what developers nee

27、d to do to avoid deceiving or endangering app users while continuing to benefit from advertising-supported monetization models. The guidelines are divided into two main sections: the first sets out a list of required and proscribed behaviors, while the second defines the “informed consent” advertise

28、rs should ensure they obtain from their users before carrying out any actions on those users devices. Guidelines for Acceptable Advertising Guideline Summary The following list defines the top-level requirements for all mobile advertising. Each entry will be explained in more detail in the following

29、 section. Advertising must be identifiable as advertising Advertisers must not display advertising outside of the normal in-app experience Advertisers must not harvest personally identifiable information without informedconsent Advertisers must not take advantage of unexpected or misleading ad click

30、 responses Advertisers must not make use of elevated privileges or unusual tactics Advertisers must not transmit personally identifiable information in the clearGuidelines Detailed The following list gives a detailed description of each guideline: 1. Advertising must be identifiable as advertisingWh

31、en advertising is being displayed to the user, it should be clear to device users that it is indeed advertising. Advertising should not be disguised as something else, such as a standard dialog or button, either from within the running app or from the mobile device platform itself. Advertising shoul

32、d not attempt to deceive users or trick them into clicking. 2. Advertisers must not display advertising outside of the normal in-app experienceApp-based advertising should operate within the confines of the app of which it is part. It should not make use of system information features such as “push”

33、 notifications. It should not place icons on mobile desktops. It should not modify browser settings such as bookmarks or default homepages. It should not make modifications to phone dialer settings such as ringtones. It should not install additional apps, although directing users to app stores may b

34、e acceptable with the proper consent. 3. Advertisers must not harvest personally identifiable information without informedconsent Copyright 2015 IEEE and Anti-Malware Testing Standards Organization, Inc. All rights reserved. No part of this document may be reproduced in any form, in an electronic re

35、trieval system or otherwise, without the prior written consent of the publisher. 3 It is usually acceptable to gather information concerning the specific app with which advertising is associated, such as usage patterns. However, additional data may be accessible by in-app advertising, which should o

36、nly be harvested with the proper informed consent. Informed consent is defined in detail in the final section of this document. “Additional data” may include the following: Device-specific identifiers such as Mobile Station International Subscriber DirectoryNumber (MSISDN) (phone number), Internatio

37、nal Mobile Subscriber Identity (IMSI)(which should only be harvested if required for non-advertising purposes such ascarrier billing), or International Mobile Station Equipment Identity (IMEI) (whichshould always be properly encrypted with appropriate salting and hashing beforetransmitting) Personal

38、 data such as user email address, contact lists, and photos or other storedmedia Browser, phone call, or SMS history Personal data from other connectivity apps such as VoIP or messaging apps Information on other apps installed or running on the device Location data when the app is in the background4

39、. Advertisers must not take advantage of unexpected or misleading ad click responsesWhen clicking on advertising, users should not be subjected to unexpected behaviors, such as initiation of phone calls or SMS messages, or “frictionless” installation of additional apps. Should any of the previous be

40、 desired, informed consent (see the next section) must be obtained on each and every occasion. 5. Advertisers must not make use of elevated privileges or unusual tacticsIn-app advertising should not initiate “rooting” or “jailbreaking” of devices, or attempt to exploit any form of vulnerability in a

41、pps or in the mobile device platform. It should not try to acquire device admin rights, or try to register for BOOT_COMPLETE or other unusual system broadcasts. It should not try to bypass or undermine the standard uninstallation process, or in any way render uninstallation difficult to achieve. 6.

42、Advertisers must not transmit personally identifiable information in the clearAll personally-identifiable information gathered by in-app advertising should be properly encrypted prior to being transmitted from the device. Informed Consent This section defines the informed consent required to confirm

43、 the user has understood and agreed to any action or behavior on the part of in-app advertising. Copyright 2015 IEEE and Anti-Malware Testing Standards Organization, Inc. All rights reserved. No part of this document may be reproduced in any form, in an electronic retrieval system or otherwise, with

44、out the prior written consent of the publisher. 4 Permissions Simply relying on the built-in device permissions system is not sufficient to qualify as informed consent. End User License Agreements (EULAs) and Terms of Service Acceptance of either a blanket EULA or Terms of Service document is not su

45、fficient to qualify as informed consent. Text All text must be easily understandable by an average user. Overly-complex or circuitous language should not be used. Text must be legible, with no tiny text and no use of hard-to-read color combinations. Text must accurately describe any and all actions

46、listed above that the app will take. Text must be in the language of either the device or the associated app. Dialogs The dialog used to acquire consent must be a modal dialog offering both accept and decline options. There should be no automatic or assumed acceptance. There should be a clear way to decline consent, with no use of confusing, concealed, or overly small buttons. Dialogs should only be presented once per action, with no repetition of dialogs in the event that a request for consent is declined.