Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Note: You can take 10% off all Slashdot Deals with coupon code "slashdot10off." ×

Comment Re:Tax it (Score 1) 274

Why should there be an incentive for people to grow their $5 million to $25 million? It no longer makes any difference to them.

You make a decent point. Having reached the point where money is "just a way of keeping score" and not directly correlated with quality of life, why do most rich individuals put in the effort to invest their funds into projects which ultimately benefit, not the investors, but rather a society at large which clearly doesn't appreciate them? Why not simply direct their accumulated savings into consumption, thus bidding up prices on consumer goods? Is it just force of habit, or is altruism perhaps more prevalent among the wealthy than the prevailing biases would suggest?

Comment Re:Gee... (Score 2) 73

The biggest problem I personally have with C++ is operator overloads, which I think are just a bad idea.

The problem isn't so much operator overloads as it is C++-style overloading in general. Operators are just another kind of function. The problem with overloading them is that there is no common type signature or interface definition binding the various overloads together. That, and the limited set of available operators, which drives developers to reuse operator names for unrelated tasks. Even the STL sets a poor example by overloading bit-shift operators for I/O.

Contrast that with user-defined operators in Haskell, where overloading is only allowed in the context of a typeclass instance:

-- Monoid laws:
-- x <> mempty == x
-- mempty <> y == y
-- (x <> y) <> z == x <> (y <> z)
class Monoid a where {
mempty :: a;
(<>) :: a -> a -> a;
}

instance Num a => Monoid (Sum a) where {
mempty = Sum 0;
Sum x <> Sum y = Sum (x + y);
}

instance Monoid [a] where {
mempty = [];
x <> y = x ++ y;
}

There can be any number of instances of the Monoid typeclass, but for every implementation of the (<>) operator the arguments and result must be the same type, and (per the Monoid laws—which admittedly are only convention, and not enforced by the type system) the implementation must be associative and have mempty as its left and right identity. The same overloading rules apply to the named function mempty and the operator (<>). Since Haskell permits arbitrary sequences of symbols as operator names, there is little pressure to abuse existing operators to new purposes, and while Haskell libraries tend to make extensive use of custom operators one rarely encounters them same issues that C++ project face with operator overloading.

The nearest C++ equivalent would be to define the built-in operators as members of various abstract base classes, and only allow a named function or operator to be redefined in classes which inherit their interface from the relevant base class. This unfortunately runs into some issues regarding polymorphism due to limitations of C++'s type system; for example, the implementation of mempty needs to be selected based on its return type, while C++ only supports selecting a class based on the type of the implicit parameter "this".

Comment Re:It's the base assumption that its invalid (Score 1) 392

Another approach would be breakable encryption with an auditable trail such that anyone who breaks an individual's encryption would have to defend such actions in court.

Fantasies don't count as viable alternatives.

First problem: A backdoor key which is available to law enforcement—who have every reason to view protecting your privacy as an extra expense with no benefit to them—might as well be public knowledge. Only you have the proper incentives to protect your private keys.

Second problem: Compliance would essentially be voluntary. Until the warrant is issued you would have no way to know whether the backdoor was actually implemented. The data could even be encrypted without a backdoor, then re-encrypted with one just to fool whatever technical measure you're using to detect non-backdoored encryption. The worst you could do would be to punish someone after the fact if it's discovered that they used an unapproved encryption scheme, but at that point you could already punish them for refusing to confess (or, equivalently, for refusing to turn over their decryption keys).

In short, mandatory backdoors would compromise everyone's security without actually guaranteeing law enforcement access.

Comment Re:Already patched (Score 1) 105

So, other than being incomplete, it's complete, right?

No, it's complete, period. It may not contain every bit of software in the world, like Google's proprietary apps, but AOSP builds are usable on actual hardware in their own right. This is quite unlike the open-source fragments of iOS, which are just that: fragments.

Sure, both Android and iOS as shipped on most consumer devices contain some open-source parts and some proprietary parts, but let's not make a false equivalency here. Android, even without Google's applications, is a fully usable operating system for smartphones and tablets. Depending on the specific hardware in that smartphone or tablet you might need some closed-source drivers to enable functionality like graphics acceleration or Wi-Fi—which Google provides—but you do have the option of running AOSP on equivalent hardware which does have open-source drivers (e.g. Android on x86). iOS, on the other hand, is a predominately closed-source operating system with a few open-source components. The bits of iOS available as open source aren't even enough to give you a basic iOS-style user interface; none of the graphical parts are included, and even if they were, there are no publicly-available drivers which would allow you to run the open source parts on Apple's own hardware the way that Google supplies the drivers necessary to run AOSP builds with full functionality on the Nexus line of smartphones and tablets.

Comment Re:Already patched (Score 1) 105

So, can you really expect to compile that and end up with something that you can load into your phone (and have it work?). No.

Yes, actually. The AOSP builds should work out of the box in the sense that you can load them onto an Android-compatible phone (with an unlocked bootloader) and run normal Android applications with the stock Android user interface. Some additional functionality may require the installation of closed-source drivers, most notably accelerated graphics and Wi-Fi. The closed-source drivers needed to run AOSP with full functionality on various Nexus devices are distributed for free by Google.

By contrast, while there are some open-source components in iOS, they only extend up to the UNIX core (Darwin) and do not include any of the user interface components. If you tried to build the open-source parts of iOS the result would not only be lacking support for various standard hardware (with no drivers available, open source or otherwise), it wouldn't even be an image you could load on your iPhone, and even if you manage to get a loadable image it wouldn't have a user interface. AOSP may lack the proprietary Google applications and open-source versions of some device drivers, but it otherwise comprises a complete operating system.

Comment Re:One time pad (Score 1) 128

While I have a basic understanding about one-time pads and how they work, I realize that there must be something wrong with this idea but I don't know enough to figure out what.

There are vast amounts of publicly available documents on the Internet. Why can't Alice and Bob agree that they will use the text of the first article posted on Slashdot after noon Central Standard Time each day that they have a message to send as their one time pad?

That isn't a One-Time Pad. In OTP the pad is secret; in the scenario you just described, the content of the "pad" is public. The encryption key is thus not the pad itself, but rather just the identification of the pad ("1st article on Slashdot after noon CST"). Putting aside the fact that an article has relatively low entropy per character, someone with access to just one cyphertext could conceivably test it against a large database of likely public documents and identify the pad simply by looking for a document which decrypts the cyphertext into something intelligible. Given a couple of cyphertexts they could derive the rule you use to select your "pads". In a true OTP setup there is no way to determine whether a given pad decrypts the cyphertext since every possible plaintext has an equally plausible random pad, and even knowing both cyphertext and plaintext for the same message gets you no closer to being able to decode future messages.

Comment Re:Here's a thought... (Score 1) 318

So, if your potential boss or landlord or police officer doesn't recognize that people change, what the heck do you do?

For the first two, obviously, you either persuade them or you find someone else to work for / rent from. Freedom of association means that they have no obligation to hire you or rent out their property to you, regardless of the reason. Hiding information about your past which you know would be considered relevant amounts to fraud.

If your treatment by a police officer or any other representative of the government acting in an official capacity is influenced by outdated posts on social media sites, or anything else apart from your current standing under the law, you've got bigger issues. In any case, odds are that a law permitting you to delete your information from the Internet, even if it could somehow be implemented effectively, would not prevent the police from learning about your youthful indiscretions.

Comment Re:The three keys on the top-right (Score 2) 698

If you expect to need it, create the file /proc/sys/kernel/sysrq with the contents set to 1. This makes the key combo active by default, and survives rebooting.

The /proc directory is a virtual filesystem; nothing in there survives rebooting. If you want the sysrq keys to remain enabled after a reboot you need to write to that file from an init script.

Comment Re:Here's a thought... (Score 1) 318

What's wrong with wanting it gone?

There's nothing wrong with wanting it gone, perhaps, but what's wrong about enforcing that desire by law is that it amounts to trying to censor factual information about the past. You don't have to tell anyone about your more embarrassing historical moments, but it's wrong to forcibly prevent others from sharing what information they possess.

The right answer here is to simply recognize that people change, that it's normal to have some things in one's past that may be embarrassing (or even outright illegal), that everyone goes through this period of growing up, and that what one said or did as a child—or for that matter, as a younger adult—does not necessarily correlate with one's views or behavior in the present.

Comment Re:That's copyright for you (Score 1) 292

All the embedded links are relative, actually. The browser shows them as file:// URLs because they're in a local file. They do appear to be session-specific, and don't work for me, either, now that my session has timed out. I'd probably have to download the pages all over again to get updated links.

Here is the script:

#! /bin/bash
BASE="http://web.lexisnexis.com"
URL="... first page ..."
N=1
while :; do
___FNAME="$(printf "gacode%03d.html" $N)"
___wget -T5 -t3 --no-cookies --header "`<cookie-header.txt`" -O "$FNAME" "$URL" || break;
___NEXT="$(xmllint --html --xpath 'string(//a[img/@title="Next"]/@href)' "$FNAME" 2>/dev/null)"
___[ -z "$NEXT" ] && { echo "No next URL." 1>&2; break; }
___N=$[N+1]
___URL="$BASE$NEXT"
done

(Leading spaces were replaced with underscores to preserve layout.) The file "cookie-header.txt" needs to contain the contents of the header, including the "Cookie:" prefix, as transmitted by your browser. You can get this by using Wireshark and the "Follow TCP Stream" function, among other methods.

Comment Re:Mobile password entry; acting on user's behalf (Score 1) 365

How would the user get the long password into the mobile device's password manager in the first place?

They would sync their encrypted password database to the mobile device. Alternatively, the password manager could generate the long password itself on the device if that is where the account is being created.

Provided the user has an own PC. Good luck logging in at a public library or Internet cafe.

The fundamental problem with this scenario is that you're proposing to place your trust in a public PC you can't control. At a minimum, that particular login session must be consider potentially compromised no matter what authentication scheme you use. Having said that, there are some options if you're forced into this scenario. An OTP hardware token would be preferred; at least that way an attacker can only hijack the current session, rather than having the means to sign in as you in the future. If you do use a traditional password then it must be considered compromised and should be changed from a secure PC as soon as possible.

And store this "own distinct, revocable API key" in what secure manner? Client applications distributed as free software have already run into problems with how to store an OAuth 1.0a or 2.0 client ID and client secret.

The problem you're referring to relates to application-level keys which are meant to identify the developer of the application rather than the user. The only real solution in such cases is to make your app communicate with one of your own servers, which holds the API keys and performs API access on behalf of the app. Any keys distributed with an app (whether open source or proprietary) must be considered compromised.

In this case the API key is user-specific, not app-specific, so there is no distribution issue. The user logs in and generates an API key, which the application then stores for future use. The API key is the application's password, permitting limited access to the user's account. (For example, it should not be possible for an app to change the account password or generate additional API keys using an API key.)

Comment Re:Maybe I just don't "get it" (Score 1) 259

Now, ostensibly, we have a single browser on which I can do basic wordprocessing and spreadsheet work through google docs, edit websites, play fairly sophisticated games....all through the same browser.

Google Docs is an app whether it's running natively under Android or from inside Chrome. The browser doesn't replace any apps; it's just another platform for apps to run on—one with a lot of historical baggage, overhead, and limitations compared to the native APIs. It's good to provide a mobile-optimized web site rather than requiring visitors to install an app, but a native app will always have the potential for more sophisticated integration, in terms of both functionality and the native look-and-feel of the host operating system.

Comment Re:Mobile password entry; acting on user's behalf (Score 1) 365

Other than that it's far harder to type a 60-character password on a mobile device...

That should be the user's choice, and anyway, that's what password managers are for. If the system is implemented properly, the user won't need to type in that 60-character password on their mobile device. The user can just unlock the password manager and paste in the saved password.

Unless you're storing the user's password in order to log on to a service on the user's behalf. A password manager is an example of such an application.

The password manager should run on the user's own PC, and encrypt the passwords with a master password known only to the user. Plaintext passwords and private keys should never leave the local PC. If an app needs to perform an action on behalf of a user, it should get its own distinct, revocable API key. There is no justifiable reason for anyone but the user to have access to the user's password.

Comment Re:That's copyright for you (Score 1) 292

External references were omitted deliberately; the HTML file consists only of the pages included in the T.O.C. at the URL you provided. The notes are considered a separate document. Downloading additional documents and fixing up the URLs would be a bit out of scope for this proof-of-concept, which has taken enough time already. If you merely want to make the links work, without downloading them, just add this tag in the <head> section:

<base href="http://web.lexisnexis.com/">

I could send you my script, if you wish, but the only part you could really use for this directly is the part to set the Cookie: header (wget --no-cookies --header "Cookie: ...").

Comment Re:That's copyright for you (Score 1) 292

As it happens, the script itself was very easy to write. It's about 30 lines of bash script, making use of wget for HTTP and xmllint to extract the link to the next page. Inputs consist of the URL of the first page and the contents of the Cookie: header as set by Chrome and captured through Wireshark. It took all night to run, though; there are over 30,000 separate pages.

Anyway, in case anyone's interested, here are the main contents of each of those pages spliced together into a single HTML file: gacode.zip. The uncompressed HTML is 78 MiB; even compressed it comes to over 13 MiB. (The original 30,000 pages totaled to nearly 1 GiB.) There is some room for improvement, as I didn't strip out the redundant section headers.

Anything cut to length will be too short.

Working...