Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×

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:Google did it (Score 3, Interesting) 70

It is about 70-85% perfect with all callers, and about 97% perfect with people who regularly leave voicemails like family members. In either case it's good enough for me to know what's going on and if I need to call back in the next 15 minutes or not. If there are four sentences and it picks up 3 out of 4 nouns and verbs generally you can figure it out. And that's all I really care about. If I save 30 minutes per week not listening to voicemail, that's a huge win for me. Listening to voicemail ranks up there with getting a root canal for me.

Comment Google's Titan Aerospace did this in 2014... (Score 3, Interesting) 34

Google bought Titan Aerospace after their prototype flew for one solid year. In 2014. That was a drone... And then recently there was a 120 hour manned flight from Japan to Hawaii in a manned solar powered plane. They've flown about halfway around the world and plan on finishing the full round the world trip with the plane. 4 days flying time is not even notable at this point manned or drone. Airbus is already building and flying prototype 4 person consumer jets across the english channel.

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:Everybody List What You Think Went Wrong (Score 0) 552

No, this is like bringing up abortion in an economics discussion. It's intentionally inflammatory and only tangentially related at best. Maybe we should be discussing animal rights too, I just have to put it behind a bullet point and a well reasoned argument and it's ok to derail the whole discussion to advance my agenda, right? No. That's stupid. Let him start a newsletter about his issues and people can subscribe to it if they want, there's no reason to drag that topic in here today.

Comment Kickstarter to buy out slashdot? (Score 1) 552

What would it cost to buy out slashdot, presuming it was running at a profit with a skeleton crew before it was sold to dice? Form a non profit, buy the site, rights, etc etc. $2 million? Is slashdot even worth that much? Would they take $300,000 in return for perpetual dice.com banner ads or something? Their tax lawyers would be able to write it off as a loss/capital gain and shareholders could swallow it due to the perpetual advertising presence. We could keep the existing staff and just turn it back in to the independent walled garden it was at one point.
 
If dice.com, an IT jobs site, could not turn a profit with this, and weren't able to monetize slashdot without destroying what little value it had, I doubt the market value is much more than 95% of the current ad revenue they're getting. These sorts of sites aren't really geared towards being sold to the highest bidder, as the community is ready to walk at any point so you're kind of stuck with the revenue it's already generating via banner ads.
 
Maybe they could just gift it to the community with the advertising condition? We all knew the buyout was a terrible idea, maybe it's time to just give back the site.

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

Slashdot Top Deals

The Macintosh is Xerox technology at its best.

Working...