Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?

Comment Re:One time pad (Score 1) 125

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) 689

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
URL="... first page ..."
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; }

(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) 258

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

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

Comment Unethical, but not for the obvious reason (Score 1) 71

I find their business unethical, but only because they primarily marketed their products to governments, which means that they knowingly sought out and accepted stolen funds in payment. The same objection would apply to any government contractor. I have no ethical objection to the development of "hacking tools". It's the use of the tools against innocent third-parties which would be unethical.

Comment Re:Several reasons (Score 1) 267

Online copies are very handy but they are not a "backup" by any useful definition. If it can be wiped by the same event that wipes the original it's not a backup adequate to deal with such an event.

By that definition, backups don't exist. Any "backup" system on the planet is vulnerable to planet-destroying meteor impacts, for example. Online backups need not imply hard drives directly attached to the system being backed up, and while an online backup might not protect against certain things as well as an offline backup, it certainly does qualify as a backup.

The only reason RAID isn't a form of backup is that it always mirrors the latest version of the data in real time. If a system preserves one or more historical snapshots of the original data for later retrieval, it's a backup system. RAID won't let you go back to a previous version; its main purpose (in combination with suitable backups) is to increase availability.

Comment Re:Get the terms straight (Score 2) 195

"Triple Level" does not sound like three bits or eight levels.

You're assuming that "levels" means "voltage levels". It's more like levels of a fractal; each level divides the range of voltages in half, yielding one additional bit of storage. This corresponds to the way the cells are actually programmed, shifting the voltage by 1/2 step relative to the previous bit, e.g.:

111 = 0.5 -> 0.75 -> 0.825
101 = 0.5 -> 0.5 -> 0.625
011 = 0 -> 0.25 -> 0.375

You could also visualize each cell as a three-level binary tree with eight leaf nodes.

"The number of Unix installations has grown to 10, with more expected." -- The Unix Programmer's Manual, 2nd Edition, June, 1972