Non-Muslims have to pay tax (jizya). Muslims have to pay tax too; it just goes by a different name (zakat). Which non-failed state doesn't enforce laws against tax evasion?

Sorry I wasn't clear. I meant from the perspective of a publisher seeking to distribute its own works.

How closely are e-ink readers coupled to their respective stores? Can they not read epub or mobi format?

Which major platform doesn't already have a reader for epub or mobi format?

A newly installed web application has to create a first authenticated session that lets the founder set his own password (or set his own e-mail address in order to recover his password) and grant himself founder privileges. The URL of this first session is effectively a password (or more properly a substitute for a password), though I'll grant that it should be disabled through other means most of the time.

I see at least two problems.

The first is that Android's permissions are far too coarse-grained. SD card permissions don't have separate settings for "read and write the app's own folder and folders explicitly chosen by the user" and "read and write the whole damn thing". Internet permissions don't have separate settings for "communicate only with a specific set of hostnames" and "communicate with everything". Phone state permissions don't have separate settings for "read whether the phone is ringing as a cue to pause the game or video and save the user's work immediately" and "read the identity of the cellular subscriber whose SIM is in this device".

The other problem is that unlike (say) Bitfrost in OLPC Sugar, Android's model isn't designed for users to be able to turn permissions on and off. A user must either grant all privileges that an application requests or not install the application at all. For example, a keyboard app might be able to read the user's location and contacts, ostensibly for adding nearby landmarks and friends' names to the autocorrect. But a privacy-conscious user has no technical means of preventing the application from misusing those permissions. Android 4.3 experimented with "App Ops", an app on Google Play Store to disable individual permissions of individual applications, but Google did away with that in Android 4.4 because it caused too many applications to crash on an uncaught SecurityException.

Until the device blocks sophisticated users from running their own software. This is where the walled garden concept comes in.

I understand how you might see a non sequitur, so let me connect the dots. Verifying a sender is only authentication. According to the article, authentication should always be followed by authorization, a decision as to whether or not the system should trust software from a particular sender. A platform owner could play up its strong authentication and gloss over the inflexible authorization policy that follows it. And "inflexible authorization policy" is another word for a walled garden.

It becomes censorship when the moderation authority continues: "You can't talk about over there, it is evil!"

That depends on what you think keeps other companies from going into business.

Software isn't "infinitely malleable" when it exposes interfaces to anything else. This could be APIs to other software or user interfaces. You have to build on the old interface compatibly, and when you do make a clean break, you need to keep supporting the old interface until others have had a reasonable time to migrate.

APIs need at least as much consistency as UIs. In fact, I'd argue that APIs need even more consistency because human users are slightly better at adapting to a UI through reflection, that is, figuring out a UI by inspection.

Then take this guide as something to consider when determining when you have enough negative tests, or tests that are expected to succeed by failing.

If you're using a CAPTCHA as part of a process to authenticate a user, how do you perform automated testing on that?

For example, some organizations will claim a real business need to store intellectual property or other sensitive material on the client. The first consideration is to confirm that sensitive material really does need to be stored on the client.

Video game publishers might take this as an excuse to shift to OnLive-style remote video gaming, where the game runs entirely on the server, and the client just sends keypresses and mouse movements and receives video and audio.

watermark IP

I'm not sure how binary code and assets for a proprietary computer program could be watermarked without needing to separately digitally sign each copy.

Authentication via a cookie stored on a browser client may be sufficient for some resources; stronger forms of authentication (e.g., a two-factor method) should be used for more sensitive functions, such as resetting a password.

For small web sites that don't store financial or health information, I don't see how this can be made affordable. Two-factor typically incurs a cost to ship the client device to clients. Even if you as a developer can assume that the end user already has a mobile phone and pays for service, there's still a cost for you to send text messages and a cost for your users to receive them, especially in the United States market where not all plans include unlimited incoming texts.

a system that has an authentication mechanism, but allows a user to access the service by navigating directly to an “obscure” URL (such as a URL that is not directly linked to in a user interface, or that is simply otherwise “unknown” because a developer has not widely published it) within the service without also requiring an authentication credential, is vulnerable to authentication bypass.

How is disclosure of such a URL any different from disclosure of a password? One could achieve the same objective by changing the URL periodically.

For example, memory access permissions can be used to mark memory that contains only data as non-executable and to mark memory where code is stored as executable, but immutable, at runtime.

This is W^X. But to what extent is it advisable to take this principle as far as iOS takes it, where an application can never flip a page from writable to executable? This policy blocks applications from implementing any sort of JIT compilation, which can limit the runtime performance of a domain-specific language.

Key management mistakes are common, and include hard-coding keys into software (often observed in embedded devices and application software)

What's the practical alternative to hard-coding a key without needing to separately digitally sign each copy of a program?

Default configurations that are “open” (that is, default configurations that allow access to the system or data while the system is being configured or on the first run) assume that the first user is sophisticated enough to understand that other protections must be in place while the system is configured. Assumptions about the sophistication or security knowledge of users are bound to be incorrect some percentage of the time.

If the owner of a machine isn't sophisticated enough to administer it, who is? The owner of a computing platform might use this as an excuse to implement a walled garden.

On the other hand, it might be preferable not to give the user a choice at all; or example if a default secure choice does not have any material disadvantage over any other; if the choice is in a domain that the user is unlikely to be able to reason about;

A "material disadvantage" from the point of view of a platform's publisher may differ from that from the point of view of the platform's users. Another potential walled garden excuse.

Designers must also consider the implications of user fatigue (for example, the implications of having a user click “OK” every time an application needs a specific permission) and try to design a system that avoids user fatigue while also providing the desired level of security and privacy to the user.

Google tried this with Android by listing all of an application's permissions up front at application installation time. The result was that some end users ended up with no acceptable applications because all applications in a class requested unacceptable permissions.

A more complex example of these inherent tensions would be the need to make security simple enough for typical users while also giving sophisticated or administrative users the control that they require.

That or an application or platform publisher might just punt on serving sophisticated users.

Validate the provenance and integrity of the external component by means of cryptographically trusted hashes and signatures, code signing artifacts, and verification of the downloaded source.

This too could be misinterpreted as a walled garden excuse when a platform owner treats applications as "external components" in this manner.

Including promotion? Even if its illustrators and editors work on an hourly or fee for service basis, how would a startup publisher establish a reputation of sorting worthwhile books from not-so-worthwhile ones? Otherwise, it could be seen as more of what some people might call a "vanity press".

Until the single marketplace uses its market power to exclude sellers entirely from a market. This has allegedly happened in the markets for iOS apps and console games. What editorial power does Amazon exercise over its Kindle store, other than to remove obvious copyright infringements and erotica? Is the "preference to publishers with larger ebook catalogs" a way of dealing with the likes of VDM and 30 Percent Fewer Shades of Grey?

Or at least it will be in three years and change. That's how much longer the 1-Click patent family (U.S. Patent 5,960,411 and foreign counterparts) has left, based on the priority date of 1997-09-12 and the common worldwide patent term of twenty years.

True of books but not video. The only phones that stream Amazon video are the iPhone and Fire Phone. And because the Fire Phone is exclusive to AT&T, that's reduced to one if you happen to live outside AT&T's 4G coverage.