thomas-st

Is it possible that a (non-privileged) process could read data of a process that has previously terminated by looking at uninitialized memory and gain access to sensitive information that way?

Thanks for noticing. Looks like a HN bug. I copy pasted the URL with the apostrophe.

"If you encrypt text within a note, we derive a 64-bit RC2 key from your passphrase and use this to encrypt the text. This is the longest symmetric key length permitted by US Export restrictions without going through a complex process to gain export approval."

Is this still true? Weren't US cryptography export restrictions relaxed in 2000? (See e.g. http://www.rsa.com/rsalabs/node.asp?id=2327)

os.system("touch files/"+file)

Oops. What if my file is called " && rm -rf ~"?

My main problem with this is that Spotify utilizes the full upstream bandwidth, causing the latency to go up dramatically on connections where the upstream is limited. If they were just a little bit intelligent and limited the streaming to 90% of the available bandwidth I'd be okay with it since that wouldn't affect the latency.

Question: What is the best way to traffic shape all upstream connections on OS X? I've tried ipfw but I can't figure out a good way to e.g. limit the upload on all apps except for e.g. SSH.

True, looks like it's important to use a C module if available:

In [13]: from M2Crypto.EVP import pbkdf2

In [14]: %time pbkdf2('mypassword', open('/dev/urandom').read(16), 250000, 32) CPU times: user 1.16 s, sys: 0.02 s, total: 1.18 s Wall time: 1.18 s

Are DMG passwords really going through 250,000 rounds of PBKDF2-HMAC-SHA1?

I've been using the Python PBKDF2 module with fewer iterations as it takes over 18 seconds to hash a password with 250,000 iterations on my 2.7 GHz Core i5:

In [1]: import pbkdf2

In [2]: %time pbkdf2.PBKDF2('mypassword', open('/dev/urandom').read(16), 250000).read(32) CPU times: user 18.36 s, sys: 0.07 s, total: 18.43 s Wall time: 18.45 s Out[2]: '<>\x17\x03q+\x1d\x1c+\x94^\xa2\xc9&\xa9\xa56\xc2\xfa\x97A\xd7\xfb\xc8\x93r\x9d\xa0\xd67|\x1e'

Also, everyone else seems to be using way fewer iterations, e.g. 5000 for LastPass (http://helpdesk.lastpass.com/security-options/password-itera...)

I wonder if the C implementation is much faster, or if Apple uses some special hardware acceleration (GPU or special CPU instructions), as I'd love to increase the number of iterations in my Python application.

The Windows app is using Qt + CEF (Chromium Embedded), the Mac app is using Cocoa with a native WebView.

Not only is it easier and doesn't require the use of an ID, it also allows you to click in the space between the checkbox and the label text.

Just tried it out. This extension "highlights" the links in the most annoying way possible I've seen since the introduction of the blink tag :). Looks like it also could conflict with many sites if they use shortcuts. Are you using this extension on a regular basis?

Currently you have to hit tab three times to highlight the comments link, then press return. Not ideal, but should still be faster than having to use the mouse.

It's the command key on the Mac and the control key on Windows. What OS are you using?

It's faster and easier to use than Vimium for common use cases as there is no need to enter a two digit link code to open a link.

Seems like it's illegal to use in California: http://www.dmv.ca.gov/pubs/vctop/d11/vc21968.htm

You get the pre-Lion behavior back.

For TextEdit you additionally have to disable autosave so you don't get error messages:

defaults write -app textedit AutosavingDelay -int 0

defaults write -g ApplePersistence -bool no

Problem solved.

You should also notify any users who already signed up and stored their access token in the database.

Revoke application access here: https://accounts.google.com/b/0/IssuedAuthSubTokens?hl=en

psql -h ec2-107-22-171-68.compute-1.amazonaws.com -p 5732 -U u1npugarlguimh -d ddbs2kvmqeieon

Since DEBUG=True, finding the password is left as a trivial exercise for the reader. I wouldn't trust the service until they fix the issue.

a link for the lazy: https://elasticsales.com/

Cool, you guys should consider extending MongoAdmin at the hackathon.

Haven't tested it with replica sets, it will probably not work. You're free to implement that though :)

I thought about making it a hosted service, but I wanted to release a minimal version and see what the feedback is, so I decided to make it open source instead of putting a credit card form on the page.

Why does session affinity not solve the problem of session caching? The author says it's "a whole other world of pain and suffering" but doesn't explain why.

Currently it only captures known input widgets, i.e. no global key strokes.

Planned (no capture for password fields and an opt-out for other text fields). An option might be also to just display stars on regular input fields, so you could see that users are typing, but not see what they actually type.

Try http://beta.oyolive.com/accounts/password/change/ I'll place a link to this page on the account page.

Right now it captures any text field. I am planning to implement a filter so the website owner can choose which fields they don't want to capture. An idea would be also to specify an entire area of the page that shouldn't be captured.

I invited some of my developer friends to support my project. I didn't know who has a HN account and who doesn't, but these are all real people.

There is no storage policy yet for the beta. I was thinking of storing the visits for a certain period of time, with the ability to save selected visits forever. The beta will give me an idea on how much storage I should anticipate. I am currently storing data in MongoDB's GridFS.

Thank you for your feedback!

Regarding the resolution, there is room for improvement as the server is currently located in Europe and the website visitor only sends new mouse positions when the previous request returns from the server (in order to avoid multiple requests that may be stuck).

oyoLive should not slow down the site, as it loads asynchronously, but tell me if you notice any slowdowns.

I'll contact you soon to hear more feedback from you. Thanks so far!