Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×

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.

Comment Can we maybe fix the memory leaks? (Score 4, Interesting) 67

Sometime in the last five releases it feels like the number of memory leaks in Chrome have just skyrocketed. Maybe I'm not the normal use case, but I typically leave Chrome and various tabs open for days or weeks at a time, and eventually causes Windows to panic and close Chrome to recover that memory. My wild-ass-guess is that it's related to HTML5 video but maybe it's something else. I freakin' love chrome, but the memory leaks are seriously making me consider something a little more stable.
 
Chrome is the only application I use that ever, ever has memory leaks now in 2015.

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:Meh (Score 3, Insightful) 351

Yes to #1, take your TV, throw it out the window. Tune your radio to NPR, install Ad Block, Flash Block, uBlock, Ghostery, etc. on your web browser. You will be shocked - SHOCKED - to find out from your friends when the latest summer blockbuster movies are coming out.
 
When I moved out of the house at 19 I did not take a TV with me, and I did not miss it. Only at 29 did I buy a TV, and only then so I could watch Netflix on a larger screen, in my living room.

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:Big truck != Big company (Score 1) 363

You can buy a used food truck/UPS van for just a few thousand. You can buy a LOT of truck used for twenty large. Independent delivery vehicles typically aren't bought new. If you're in that market as an independent contractor, you're lucky to have a dedicated consumer Garmin unit. There exists a market outside of the new 18 wheeler semitractor, which don't really fit inside of a city as dense as NYC.

Slashdot Top Deals

And it should be the law: If you use the word `paradigm' without knowing what the dictionary says it means, you go to jail. No exceptions. -- David Jones

Working...