Forgot your password?
typodupeerror

Comment: Patent on this new feature (Score 1) 53

by tepples (#47791133) Attached to: MIPS Tempts Hackers With Raspbery Pi-like Dev Board

MIPS32r6 [...] added things like [...] the requirement that hardware supports unaligned loads and stores (or, at least, that the OS traps and emulates them)

What kind of patent does Imagination Technologies have on features essential to MIPS32r6? And how is it licensed, compared to (say) ARM? If you'll recall, unaligned loads and stores were one of the few things about the original MIPS ISA that were patented.

Comment: Re: Editorial control of the monopoly market (Score 1) 110

by tepples (#47791105) Attached to: Japanese Publishers Lash Out At Amazon's Policies

are customers suppose to go to 8 different websites and know which publisher publishes which book?

They could go to the book review site where they learned about the book in the first place and follow the link to the publisher's page for the book. Or they could find the page in a generic web search engine, such as Bing or Google.

Comment: Re: Editorial control of the monopoly market (Score 1) 110

by tepples (#47788301) Attached to: Japanese Publishers Lash Out At Amazon's Policies

All another company has to do is make distribution deals with all the major publishers

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

get people to give up their e-ink readers

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

and make apps for every major platform

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

Comment: Two problems with Android app permissions (Score 1) 48

by tepples (#47788215) Attached to: IEEE Guides Software Architects Toward Secure Design

I believe the article is saying that you don't just blindly allow the use of URLs without verifying that the caller is within an authenticated session. This has nothing to do with changing passwords.

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.

But if you don't want any app to do anything, why do you have a device capable of running apps?

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.

Those users who are "too sophisticated" may need to write their own software

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

Or it could be correctly interpreted as "use digital signatures to verify senders and that the message has not been tampered with."

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.

Comment: API consistency; negative tests (Score 3, Insightful) 48

by tepples (#47786881) Attached to: IEEE Guides Software Architects Toward Secure Design

Of course, when the end product is as infinitely malleable as software

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.

The human interface needs a design in order to mesh with the humans in an elegant and consistent fashion, but the code? No. The only purpose of code design is to make the code readable and maintainable, and those are attributes you achieve through test driven development and continual refactoring.

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.

The engineering the IEEE is trying to achieve is accomplished by test-first development

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.

continual automated testing

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

Comment: An excuse for walled gardens and OnLive (Score 2) 48

by tepples (#47786759) Attached to: IEEE Guides Software Architects Toward Secure Design
I read the featured article, and I see ways that publishers could misuse some of the recommendations as excuses for profit-grabbing practices that plenty of Slashdot users would detest.

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.

Comment: Difference between publisher and vanity press (Score 1) 110

by tepples (#47786343) Attached to: Japanese Publishers Lash Out At Amazon's Policies

An agile publishing start up company can do everything the old dinosaurs do thanks to digital publishing.

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".

"How to make a million dollars: First, get a million dollars." -- Steve Martin

Working...