Jerrymouse 歪歪鼠的窝

Jerrymouse

Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.6) Gecko/20070914 Firefox/2.0.0.7

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7

Mozilla/5.0 (Windows; U; Windows NT 6.0; en) AppleWebKit/522.15.5 (KHTML, like Gecko) Version/3.0.3 Safari/522.15.5

Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/103u (KHTML, like Gecko) safari/100

Opera/9.23 (X11; Linux x86_64; U; en)

Opera/9.23 (Windows NT 5.1; U; en)

Mozilla/4.0 (compatible; MSIE 6.1; Windows XP)

Mozilla/5.0 (Windows; U; MSIE 7.0; Windows NT 6.0)

Mozilla/5.0(iPad; U; CPU iPhone OS 3_2 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) Version/4.0.4 Mobile/7B314 Safari/531.21.10

查看浏览器User-Agent的网站，http://whatsmyuseragent.com/

firefox设置UA：
地址栏输入“about:config”，找到“general.useragent.override”，如果没有这一项，则点右键“新建”->“字符串，设置上面的值。

Jerrymouse

引用自：http://www.firefox.net.cn/forum/viewtopic.php?t=31181

最近的更新中，GreaseMonkey 脚本再也不能用在本地的文件上了，也就是说，什么文本链接化、自动高亮、划词翻译等等等等的 GM脚本，对另存到本地的网页、电子书的 HTML 页面、甚至 Scrapbook 保存下来的网摘等等等等都无效了。

经过一轮“翻山越岭做好汉”，我终于找到了讨论此问题的几乎唯一的帖子：

引用:

On Wed, Dec 30, 2009 at 1:00 AM, Matt Sargent <matt.sarg...@earthlink.net wrote:

Until a recent release, Greasemonkey could run on locally stored HTML pages. This was very handy, especially when combined with the Scrapbook add-on. Does anyone know of a way to restore this behavior to a script?
>>>
On 12/29/2009 7:06 PM, esquifit wrote:
Since a couple of releases there are two new 'hidden' preferences:

greasemonkey.aboutIsGreaseable
greasemonkey.fileIsGreaseable

The default value is "false". If you want Greasemonkey to run on file:/// urls, you have to set the second one to "true" (in about:config).
>>>
On Fri, Jan 1, 2010 at 7:49 AM, Matt Sargent <matt.sarg...@earthlink.net wrote:
THANK YOU!! This was exactly what I was looking for. It works perfectly.

也就是说，把 about:config 里面“greasemonkey.fileIsGreaseable”值改为“true”就可以让 GM脚本对本地文件生效了。
但是：

引用:

esquifit
Fri, 01 Jan 2010 02:39:49 -0800

Glad to know. Keep in mind, however, that this implies a security risk. A malicious userscript could open a tab or a frame, load a "file:" url from your local drive into it, read the contents and send them to any server. Even binary files could be stolen in this way, including files stored in your Firefox profile containing sensitive information (passwords, cookies, history, etc). In order to know the exact location of the profile folder the attacker could either do a recursive scan of your hard disk (directory contents can also be listed via file: urls) until it reached the profile.ini file in which all profile directories are listed, or it could open the about:cache page and read the profile from there, provided access to about: urls is granted via the "greasemonkey.aboutIsGreaseable" preference. This security risk was in fact the motivation for the new preferences, as far as I can remember. This was handled in bug #1000:

http://github.com/greasemonkey/greasemonkey/issues/closed#issue/1000

也就是说，这样做是有风险的，对于恶意的 GM脚本来说就是开了一个盗取你的隐私的大门。
这个其实也不是解决不了的，方法就是打开上述键值之后，对于确认安全的而且需要对本地文件生效的 GM脚本，通过 GreaseMonkey 的脚本管理将“file:///*”加入到其允许规则中，对于信不过的脚本则把同样的规则加入到其除外规则中。在安装脚本的时候注意，要是有脚本的对所有网页生效（允许规则为“*”），就要在安装后马上将其允许规则修改（例如改成“http://”）或者在除外规则中加入“file:///*”以作预防。

Jerrymouse

几次碰到页面的图片没法载入，直接找到图片地址打开还是说“未找到文件”，试着用安全模式还是不行，想想跟扩展、插件的应该没关系，备份profile后重做了一个，好了；开始一堆设置，想想应该都是保存在prefs.js这个文件里的，回去刚才的profile里把prefs.js删了，果然也好了；遂开始一项项排除，终于发现在设了browser.cache.disk.parent_directory这个cache目录后出问题，进入firefox的选项->高级->网络，发现缓存满了，清楚缓存，一切恢复正常。

不知道这个是不是firefox缓存管理的一个bug，在缓存设到别的目录然后满了就不知道怎么做了。

Jerrymouse

Google Talk https://talkgadget.google.com/talkgadget/popout

MSN Messenger https://home.live.com/Handlers/WebIM.mvc

WebQQ Mini http://w.qq.com/

Jerrymouse

【TEST】Win7模拟激活，俗称OEM7【/TEST】

由于skydrive的不断升级更新，外部共享链接经常过一个月甚至一个星期就失效，上面这个是直接的下载地址，不知道多久失效。

Jerrymouse

保护你的隐私，五种控制Android应用的权限的方法:

　　这篇文章目的在于介绍Android系统上控制权限的方法，读者只要使用过Android，或是对智能机平台有所了解，就能看懂，不需要专门的编程知识。

　　1 为什么Android总是事无巨细地告诉你应用索取的每一项权限？

　　相比Apple，Microsoft严格控制生态系统(从苹果给开发者的"App Store Guideline"可见一斑)，只允许通过官方应用商店安装应用，并对每份上传进行仔细地审查而言，Android的开放就意味着，Google需要向用户提供一系列用于为自己负责的流程、工具。所以在安装应用前，Android总是要事无巨细地告诉你，应用肯需要控制什么权限。

　　同样，开发者也制作了一系列易用的工具，用以鉴别可疑的应用程序，或是控制权限。

Android权限

图1 Android 官方市场会强制提醒用

　　Andoird哪里开放了？

　　在Android中，用户能自由从本地安装应用，自由地对SD卡进行操作，自由选择应用市场。

　　如果愿意放弃保修，用户还能轻易地实行root，解锁基带(baseband)。只有一些产品会严密地锁定bootloader(如摩托罗拉)。

　　最重要的是，因为ASOP(Android源代码开放计划)的存在，绝大部分的Android代码都是开源的，开发者可以由此对Android系统进行深入的修改，甚至可以自行编写一个符合Android规范的系统实例(如Cyanogen Mod)。正是因为ASOP，这篇文章才可能介绍多达5种原理不同的权限控制方法。

图2， Android开源计划的标志

图2 Android开源计划的标志

　　开放的风险

　　不考虑Symbian，Windows Phone 6.5(及以下)平台，那么几乎所有的智能手机病毒都是Android平台的，甚至官方Android Market也闹过几次乌龙。在国内水货横行的市场，情况更是火上浇油，不法业者可以在手机的ROM，甚至是bootloader中做好手脚，让用户有病无法医。

　　在Android中，用户可以允许系统安装来自"未知源"(也就是非Google官方的，或手机预置市场的)应用程序。于是，移动平台最重要的门神------数字签名就被绕过了。

图3 Android 允许未知安装未知来源的应用程

　　出于Android的开放性，也有不允许"未知源"的反例：亚马逊的Kindle Fire平板使用了深度定制的Android，它只允许安装来自亚马逊官方商店的应用程序。

图4 亚马逊的 Kindle Fire 仅允许通过自带的市场安装应用

　　2 Android有哪些"权限"

　　首先需要明确一下Android中的种种"权限"。Android是在Linux内核上建立一个硬件抽象层(Android HAL)，通过Dalvik以及各种库来执行android应用的。在手机启动时，首先需要由Bootloader(HTC手机上称作Hboot)引导Linux及手机上各个硬件设备的驱动程序，之后才启动Android系统。所以其实我们会涉及到四种不同涵义的权限：

　　Android权限(Permission)

　　这指Android中的一系列"Android.Permission.*"对象，是本文的中心内容。

　　Google在Android框架内把各种对象(包括设备上的各类数据，传感器，拨打电话，发送信息，控制别的应用程序等)的访问权限进行了详细的划分，列出了约一百条"Android.Permission"。应用程序在运行前必须向Android系统声明它将会用到的权限，否则Android将会拒绝该应用程序访问通过该"Permission"许可的内容。

　　比方说，搜狗输入法提供了一个智能通讯录的功能，用户可以在输入联系人拼音的前几个字符，或首字母，输入法就能自动呈现相关联系人的名字。为了实现这个功能，输入法必须声明它需要读取手机中联系人的能力，也就是在相关代码中加上声明"android.permission.READ_CONTACTS"对象。

图5 搜狗输入法的智能联系人功能

　　原生Android只提供了对"一刀切"式的管理，要么同意使用，否则就根本就不安装应用程序。当用户遇到希望使用程序的同时，又想禁止部分Permission的场合，他就无路可走。

　　于是，不少开发者就捣鼓出了"第三条道路"；可惜的是，没有一种方法能同时做到既不需要将手机固件Root，又完全不涉及对原始应用程序进行反向工程的方法。

　　Root

　　Root指获得Android所在的Linux系统的Root(根)权限，有了根权限，你才能对Linux做出任意的修改。iOS中的越狱(Jailbreak) 相当于获得iOS系统的Root权限(iOS是一种类Unix系统，和Linux都使用Root的概念)。在已Root的设备中，通常都是使用一个叫"Superuser"(简称SU)的应用程序来向许可的程序授以Root权限。

　　Bootloader的解锁(Unlock)

　　利用数字签名，Bootloader可以限定只有正确签名的系统可以被引导。在修改固件以获得Root以前，解锁Bootloader通常是必须的。安装第三方修改、编译的固件也需要解锁Bootloader。

　　基带(Radio)解锁

　　在Android系统中，基带是上层软件与手机中无线设备(手机网络，Wi-Fi，蓝牙等)的驱动程序之间的中介。国外的网络运营商很喜欢锁定基带，从而保证用户只能使用运营商自己指定的sim卡。在我国，锁定基带是非法的，手机制造商、网络运营商也不可以通过锁定基带的方法对待违约客户。iOS的"解锁"就是解锁iOS中的基带软件。

　　为什么要控制Android权限

　　鱼和熊掌不可兼得，Android的世界有很多自由，坏人也能自由地做坏事。它的生态系统很强调自主：用户可以自主地减小风险，仅使用官方市场的应用程序，也可以自主地解除安全限制，从而获得更多自由。因此，在遇到坏事的时候，用户也不得不自主一下：

　　1，抵制不道德，乃至非法行为

　　几乎所有的Android安全软件都能对来电、信息进行控制，以减少骚扰。

　　另一方面，很多应用都会要求它们实际功能以外的权限，表现在非(主动)告知地搜集设备序列号，位置信息，诱使用户默认地上传联系人列表等方面。

　　更坏一点的应用程序，则会踏入犯罪的范畴，比如能偷偷发出扣费信息，或是作为黑客的偷窥工具。

　　2，减少恶意软件的损害

　　恶意软件即便潜伏成功，也难以获得权限，从而减少损失。

　　3，用户有权自主地在抑制应用程序的部分权限时，继续使用该应用程序，而只承担由于自行设置不当而带来的后果。

　　用户拥有设备的所有权，因此有权自主控制设备上的内容、传感器等对象的访问；同时有权(不)运行，(不)编译设备上的应用程序。

　　大多数应用程序在运行时，并未达成主动告知的义务，是失误；然而即使主动告知，用户还是可以不理会。

　　为什么Android官方市场的强制提醒权限的行为不属于主动告知：

　　通过Android官方市场，"打包安装器"安装应用程序时，所显示的"权限"仅是在安装包内AndroidManifest.xml声明的值，而非应用程序实际上会调用的内容。该值仅用来表明Android系统能向应用授予的最大可能的权限。即便一个"Hello World"式的应用程序，也可以在AndroidManifest.xml中声明所有可能的Android Permission。

　　这就是说，在AndroidManifest.xml中声明的值与应用程序实际调用的权限有关联，但不等同，且这种提示是由Android系统负责实施的强制行为。

　　正确的理解是："应用程序(被迫地)让Android系统告知用户，它在AndroidManifest.xml中所声明的事项。"

　　这意味着应用程序在使用重要权限前，依然需要自行、主动地通知用户相关事宜。

图6 应用程序须要AndroidManifest.xml中声明调用到的权限

　　然而，即便只是让一半的应用程序达到以上的标准，也是不可能的。应用程序需要通过收集用户信息，程序的错误日志。从而统计用户的喜好，改进程序。另一方面，这也是发送精确广告但不追溯到用户身份信息的方式，这一点对于免费应用而言，是极其重要的。我们之所以能知道不同型号手机的占有率，应用软件的流行度，是与这样的统计不可分离的。

　　一旦每个应用程序都专业地主动发出提醒，不专业的用户(大多数用户都是不专业的)通常会将之视为如同海啸警报一般的危机。

　　这么做对谁都没有好处------用户方的隐私权是毋庸置疑的，然而应用程序方面的获取信息记录的需求也是无可阻挡的。如果每个用户都打算阻止，只会落得被迫接受不平等条约的下场，在温饱以前，不会有人考虑小康的问题。

　　于是，现状就变得有趣：用户人享受着相同的服务；其中大部分用户出于不知情/好意，默默地向开发者、广告商提供了信息，剩下的少数用户则能阻断这种劳务。而作为维持Android平台的信息商人Google，只确保在它的地盘里，不会发生触碰底线的事情。

　　一句话总结：

　　设备是我的，不管你怎么说，反正我说了算，但我说的话大多是不算数的。

　　3 权限控制的方法

　　这里开始介绍各种控制Android权限的办法。可惜的是，几乎所有的手段都需要对设备进行Root，如果不这么做，则需要付出不小代价。

　　App Shield(国内常见的名字:权限修改器)

　　它是一个需要付费的Android应用，其原理是修改应用程序的apk安装包，删除其中AndroidManifest.xml文件内，用于声明权限的对应"Android.Permission.*"条目，然后再用一个公开的证书对安装包重新签名(需要允许"未知源")，这样一来，应用程序就不会向系统申请原先所需的权限。当应用运行至相应的流程时，系统将直接拒绝，从而达到用户控制权限的目的。

　　对于已安装的应用，AppShield也会按照同样方法制作好apk安装包，然后让用户先卸载原始的应用，再安装调整过的应用。除了该应用数字签名外，用户可以随时通过执行同样的流程，将吊销的权限恢复。

图7 AppShield

　　Apk文件的结构

　　Android应用都是打包成以.apk扩展名结尾，实际上是zip的文件格式。

　　一个合法的apk至少需要这些成分：

　　根目录下的"AndroidManifest.xml"文件，用以向Android系统声明所需Android权限等运行应用所需的条件。

　　根目录下的classes.dex(dex指Dalvik Exceptionable)，应用(application)本身的可执行文件(Dalvik字节码) 。

　　根目录下的res目录，包含应用的界面设定。(如果仅是一个后台执行的"service"对象，则不必需)

　　Apk根目录下的META-INF目录也是必须的，它用以存放应用作者的公钥证书与应用的数字签名。

　　当应用被安装后，这个apk文件会原封不动地移至设备的data/app目录下，实际运行的，则是Dalvik将其中Classes.dex进行编译后的Classes.odex(存放在Dalvik缓存中，刷机时的'cache wipe就是清除Dalvik的odex文件缓存')。

　　优点：

　　完全不需要Root，适用于所有版本的Android设备。不会损坏系统，可以吊销任意一项Android权限。

　　问题：

　　1，需要重新安装应用，该行为可能会丢失应用的配置、历史记录。

　　2，执行权限吊销的应用的数字签名会被更改，无法直接更新。对于那些设计不良(没有意料到'不声明权限'情况的)，或有额外自校验的应用，可能会无法运行。

　　3，无法用于设备上的预装应用，除非制造商好心地将该应用设置为"可以删除"的状态。

　　4，这个方法修改了apk包中的内容------尽管实际上AndroidManifest.xml和数字签名并不算是应用程序的本身，但修改它们可能引发著作权的问题。

　　5，需要开启"未知源"。

　　6，这是一个收费应用。

　　CyanogenMod 7.1(及以上版本)

　　Cyanogenmod是一款著名的第三方编写的开源Android ROM。

　　CM7.1加入了控制权限的开关，官方的名称是"Permission Revoking"，任何非系统/保护应用在安装后，可直接吊销任意一项权限，其效果等价于直接删除apk包中AndroidManifest.xml的对应条目，但不会引发自校验的问题。CM的权限工具的作用等同于AppShield，无非是在Android自身的权限系统中添加了一个开关。

图8 Cyanogen Mod 7.1中的权限吊销(Permission Revoking)设定

　　优点：

　　免费，使用简便，可随时，任意地吊销、恢复非预装应用的任意一项权限；不存在数字签名的问题，因而不影响使用自校验的应用程序。

　　问题：

　　此功能仅在Cyanogen Mod 7.1及以上版本提供，无法用于其它rom。因为是由Android系统出面吊销权限，其实现原理与App Shield完全相同，同样的，应用程序会因为设计不良而出现崩溃。

　　Permission Denied

　　这是可以吊销任意Android应用(注意，不当地吊销系统应用的权限可能会导致手机固件损坏，无法启动)的任意权限，对权限的修改在重启后生效。

　　实现原理应该与Cyanogen Mod 7.1+完全相同，适用于任何已经Root的系统，因为一般的Android系统虽然事实上支持权限吊销，但没有像Cyanogen Mod那样放置接口，因此需要重启后才能应用权限配置。同样也有系统出面拒绝权限而导致的崩溃现象。

图9 Permission Denied免费版吊销应用程序权限的场景

　　优点：

　　效果与Cyanogen Mod中的权限吊销效果一致，且可吊销系统应用的权限。同时提供了免费与收费版本，免费版并没有基本功能的缺失。适用于所有版本号不低于1.6的Android设备。

　　问题：

　　调整后的权限需要重启才能生效。设计不良的应用会崩溃。不恰当的权限修改会损坏系统，导致无法开机。

　　PDroid

　　PDroid实际上是一个Android内核补丁加上一个用于管理的外部应用。补丁需要在Recover环境中刷入系统，也可以由开发者自行移植入系统。该软件在Android ASOP 2.3.4代码基础上开发，仅适用于没有改动内核的Android 2.3系统，目前还未支持Android 4。

图10 PDroid的界面

　　为了避免Cyanogen Mod 7.1+权限吊销(Permission revoking)导致的崩溃问题，以及后台服务(如LBE，QQ手机管家等，PDroid的作者认为通过后台服务拦截权限并不是好办法)，PDroid并不阻止应用程序声明权限，但会在其实际索取相关信息时，予以阻止。通俗地说，就是签署协议但不执行。在PDroid的用户界面，用户能随时精确地控制涉及隐私的各项权限。对于某些内容，除了阻止外，用户还可以伪造一个随机或指定的数据。

　　可控制的内容包括：

　　IMEI(可伪造)

　　IMSI(可伪造)

　　SIM卡序列号(可伪造)

　　手机号码(可伪造)

　　来，去电号码

　　SIM卡信息

　　当前蜂窝网络信息

　　(以上七者均来自Android.Permission.READ_PHONE_STATE)

　　GPS定位信息 (可伪造，来自Android.Permission.FINE_LOCATION)

　　基站定位 (可伪造，来自Android.Permission.COARSE_LOCATION)

　　系统自带浏览器的历史，书签(Android.Permission.BOOKMARKS)

　　联系人 (android.permission.READ_CONTACTS)

　　通话记录 (android.permission.READ_CONTACTS)

　　系统日志 (android.permission.READ_LOGS)

　　当前账户列表 (android.permission.GET_ACCOUNTS)

　　当前账户的授权码 (android.permission.USE_CREDENTIALS)

　　短信，彩信 (可能与这5个权限有关)

　　　　　　　　　　android.permission.READ_SMS

　　　　　　　　　　android.permission.RECEIVE_SMS

　　　　　　　　　　android.permission.SEND_SMS

　　　　　　　　　　android.permission.WRITE_SMS

　　　　　　　　　　android.permission.RECEIVE_MMS

　　日历 android.permission.READ_CALENDAR

　　PDroid的内核补丁并不通用，每一个Rom都需要特定的补丁。开发者除了提供了几个特定机型下Cyanogen Mod，HTC Sense修改版ROM的专用补丁外，还推出了一个补丁生成工具(PDroid Patcher)，用户可以给自己的ROM生成专用的内核补丁。使用该Patcher需要安装JDK(java Development Kit)。

　　优点：

　　PDroid避免了通过Android系统进行权限吊销的导致的潜在崩溃问题，也不需要后台服务。对隐私信息的控制是最精细的。尽管设备必须Root，但应用本身不需要Root权限。

　　问题：

　　安装过程是最繁琐，最不可靠的，容易导致ROM损坏，适用范围也小，需要用户有相当的技能(能安装JDK，会刷机)才可使用；只提供对隐私有关权限的控制，不提供网络访问，的控制。以这些为代价，它几乎没有其它缺点。

　　LBE安全大师

　　实际上最常用的是以LBE为代表的通过一个Root权限的后台服务来拦截相关行为的工具。除了LBE外，还有QQ手机管家等应用。这里以LBE安全大师为例介绍。

图11 LBE安全大师

　　LBE是国内一个叫"LBE安全小组"开发的工具，支持Android2.0～4.0。它的核心功能是像杀毒软件一般，通过一个需要Root权限的后台服务，劫持所有调用权限的行为，并放行用户许可的部分(其官方宣传为'API级别拦截')。它和PDroid一样几乎不会引发应用程序崩溃，它支持拦截几个涉及用户的关键权限(LBE手机管家3.1/3.2)：

　　读取短信 (android.permission.READ_CONTACTS)

　　联系人记录 (android.permission.READ_CONTACTS)

　　通话记录 (android.permission.READ_CONTACTS)

　　定位 (Android.Permission.COARSE_LOCATION

　　　　　　　　Android.Permission.FINE_LOCATION)

　　手机识别码 (与Android.Permission.READ_PHONE_STATE有关)

　　通话状态 (与Android.Permission.READ_PHONE_STATE有关)

　　发送短信(具体原理不明，同样类似于禁止这五个权限

　　　　　　　　android.permission.READ_SMS

　　　　　　　　android.permission.RECEIVE_SMS

　　　　　　　　android.permission.SEND_SMS

　　　　　　　　android.permission.WRITE_SMS

　　　　　　　　android.permission.RECEIVE_MMS)

　　拨打电话 (android.permission.CALL_PHONE)

　　通话监听 (android.permission.PROCESS_OUTGOING_CALLS)

　　除此以外，LBE还可以分别控制应用在Wifi，手机网络的联网权限，其原理是依靠IPtables防火墙，而非通过Android的"Internet"权限。

　　此外LBE手机管家还提供基于智能内容审查的短信拦截、来电归属地显示，以及禁用系统(保护)应用，进程管理，杀毒等功能。

　　LBE提供两个版本，一个叫"LBE安全大师"，是一个全面的手机管家类应用，更新比较频繁，另一个版本(LBE手机隐私卫士，LBE Security lite)仅提供权限方面的管理。

　　考虑到主要市场在国内，LBE的发行策略看上去有些奇怪，它在Google的官方市场并不发行最新版。通常只能只能在LBE的官方网页，以及国内的应用市场获得最新版本。

　　优点：

　　使用非常简单，功能强大而全面，风险很小，可以控制系统应用。适用范围广，有很多替代产品。

　　问题：

　　需要后台服务 (尽管蚕豆网有个评测，认为它对能耗几乎没有影响)，不能控制所有的Android权限。

　　4 自启动的控制

　　Android对后台服务有着最好的支持。

　　在Android中可以自由地开发一种称为'Service'的后台运行的对象，加上没有苹果公司对应用程序的严格限制。诸如QQ挂机，即时调用第三方应用程序之类的形式都可以轻易实现。

　　为了全面支持后台服务，也为了适应移动设备资源紧张，不得不经常清理内存的问题，应用可在系统中设置触发器，当系统发生了某个特定特定事件时(系统启动，拨打电话，收发信息，安装、卸载应用，插上电源等，或应用程序自行定义的事件)，就会触发启动应用程序。

　　AutoStarts 自启动管理

　　AutoStarts是一个收费应用，通过它，用户能了解系统中每一项程序会在什么场合下被触发运行。如果提供Root权限，则还能禁止这样的行为。

　　这里以Google Maps应用6.2版为例。默认情况下，这款应用总是会保持后台运行，并每小时向Google发送一次当前用户的位置信息。为了阻止这样的行为，需要联合使用AutoStarts与任意一款进程管理应用：在AutoStarts中，阻止Google Maps的自行启动(如图)，在每次使用完后，把Google Maps的进程杀掉。

图12 AutoStarts可以对自启动项目进行修改

　　5 其他

　　Root带来的风险

　　有一个钻牛角尖的说法认为，一旦对设备进行了Root，便无安全一说，只要恶意程序一旦偷偷获得Root级别，一切都是空谈。

　　这种说法之所以钻牛角尖，是因为：一方面Android中的Root权限通常都是需要用户通过Superuser应用进行授权的，这已经够用，虽然不能指望Superuser无懈可击；另一方面，控制Android权限主要是为了让应用程序在"灰色地带"的行为收敛一些，它们实际显然不是病毒等犯罪软件。

　　著作权的问题 (作者不是法律方面的专家，以下言论仅供参考)

　　我们知道，Android中的应用程序是基于Java语言编写的。而为了达到跨平台的目的，Java软件是以字节码(或叫中间代码，bytecode)，而非计算机能直接执行的机器码(Machine Code，有时也叫作Binary)的形式存在。因此执行Java软件时，需要一个Java虚拟机(Android系统中的Java虚拟机就是Dalvik)负责解释运行，有的时候，虚拟机还会通过即时编译(JIT)的方法将字节码编译为机器码后再运行，以提高程序的执行效率。

　　这就出现一个很有趣的现象：

　　除非另行规定，作为设备的拥有者，用户总是可以自行决定如何使用软件，能自行决定程序能否访问用户自己的计算机(移动设备亦然)里面的各个内容、对象。

　　由此衍生出，在需要对代码编译、解释的场合，用户也能通过对编译器(解释器)的干预，来影响代码的执行效果。在Android中，用户还可以在Dalvik解释、编译的时候动手。

　　这是因为，著作权仅保护了软件代码不受到非授权的反向工程，未授权传播等侵犯。另一方面，对于Android上的Java，网页中的javascript程序，赋予用户解释、编译的权利是程序能执行的先决条件；同时，软件发行者发通常也会主动提出放弃这种权利(表现为'软件按原样提供'、'不对使用软件造成的后果负责'等条目)

　　在编译、解释的过程中，需要通过汇编(Assemble)，连接(Link)等方法将编译好的对象(Object)、方法(Function)联系起来。默认情况下，这些行为是由原始的代码(源代码、中间代码)与编译器(解释器)决定的，但是用户可以通过制约编译器(解释器)的设置，从而影响到最终代码。这么做是没有问题的。

　　还有一种，应用程序在安装后，会在系统中产生一些缓存，或注册一些信息。当其中的内容有关用户数据时，读取或修改它们也是没有问题的。这就是所谓"只要是你的东西总是你的"；也是Cyanogen Mod、Permission Denied不会涉及版权问题的原因所在。

　　总之，一个Android应用之所以能运行的前提是：

　　1，首先，用户允许使用这个应用

　　这也可以理解成：用户安装了应用(以及因此设定的后台对象)，购买了预装应用的手机。这一点即不影响应用程序的主动通知义务，也不影响用户事后的干预。

　　2，接下来，用户允许Dalvik对该应用使用"解释"，"JIT"的方法，从而该应用程序得以执行。

　　3，用户随时可以对该应用作出任意不违反版权的干预。

　　所以，在没有另行规定的前提下，用户总是可以自行决定，通过给应用程序分配自定义的权限；或是在应用程序调取内容，对象时予以阻断。同时，用户也需要自行承担因不当操作产生的后果。

　　附录:

　　1、数字签名

　　数字签名是一种使用了公钥加密领域的技术实现，用于鉴别数字信息的方法。一套数字签名通常定义两种互补的运算，一个用于签名，另一个用于验证。数字签名可以轻易地验证完整性(正确性)，合法签署的数字签名具有不可否认性。 (摘录自维基百科"数字签名"条目，有修改)

　　3、一些行为的说明

　　不道德行为

　　应用程序在启动时，或在主动告知以前，试图索取、收集电话号码、邮箱地址、位置信息等与个人身份直接关联的内容。如果是与个人关联，但不能直接联系到个人信息的IMEI等设备、SIM卡的串号，则稍微好一些。

　　附图1，不道德的应用程序在启动的第一时间就试图获取隐私信息

新浪微博

(新浪微博2.8)，无论用户是否绑定了手机，应用都会第一时间记录当前手机的号码

UCWEB

(UC浏览器，快拍二维码)，应用总是会不主动通知地记录设备的位置信息

　　没有实行主动通知的例子

附图2 这个应用程序在第一次启动时便开始收集位置信息，用户需要切换六次屏幕才能看到有关位置信息的提示。这项提示还有意忽略应用程序本身就会记录用户位置信息，即便用户并不使用需要位置信息的服务

　　主动通知的例子

taobao

附图3 主动通知就是在第一屏的醒目处，或用醒目的对比色等强调方式进行通告

　　来源：fcerebel投稿。

评论《保护你的隐私，五种控制Android应用的权限的方法》的内容...

Jerrymouse 歪歪鼠的窝

2012年2月21日星期二

常用的User-Agent

2012年2月19日星期日

Greasemonkey 脚本应用在本地文件的办法

firefox Cache Bug？

2012年2月13日星期一

网页版（Web）的QQ、MSN、GTalk

2012年2月12日星期日

测试下Skydrive链接共享的有效时间

[转贴]保护你的隐私，五种控制Android应用的权限的方法

1 为什么Android总是事无巨细地告诉你应用索取的每一项权限？

2 Android有哪些"权限"

3 权限控制的方法

4 自启动的控制

5 其他

附录:

相关文章:

2012年2月7日星期二

foxyproxy的用法