brianhempel
Joined 15 years ago
Joined 15 years ago
There are multiple name suggestions when:
(1) Multiple items are being replaced and each replaced item had a different name.
(2) There would be a name collision. To resolve the collision, either one or the other variable can be renamed.
Copyright divestment by failing to put a proper copyright notice must happen with the "consent of the copyright owner". The song in the 1922 songbook said, "Special permission through courtesy of The Clayton F. Summy Co." without the appropriate copyright notice. The lack of proper copyright notice would have released it to the public domain (proper notice was included on other songs in the songbook). However, Warner/Chappell claims that Summy didn't own the copyright in 1922: the songbook asked the wrong people for permission.
"There is no evidence that the Hill Sisters (Jessica or Patty) granted anyone the right to publish the Happy Birthday to You! lyrics until 1935. The evidence instead shows that Summy sought and obtained a license to publish the Happy Birthday to You! lyrics from Jessica Hill in 1935."
As circumstantial evidence, Warner/Chappell also points out that in earlier court battles in the 30s and 40s the copyright holders never indicated that there was any authorized publication before 1935.
Warner/Chappell doesn't address the filmmaker's claim that a 1922 publication would put the song into the public domain in 1997. I'm confused here: Would the publication have to be authorized for the 1997 date to hold?
Filmmaker's request for summary judgement: http://www.scribd.com/doc/272751583/Birthday-Evidence
Warner/Chappell's response: http://www.scribd.com/doc/272870978/Warner-Chappell
Most browsers these days implement window.crypto.getRandomValues() so you could use that and do the generation client-side in Javascript. That way, I don't have to trust that you're not storing these passwords in preparation for a later attack.
1. Browser-encrypted so the server cannot decrypt it. The decryption key is stored in the URL fragment after the # so the server never sees the decryption key. (Fragments are not sent in HTTP requests.)
2. Secrets never touch disk. SneakyNote.com even goes to lengths to clear the in-memory buffers on storage/access.
3. Verified delivery. If you're going to send the link over an insecure channel, you can't prevent someone else from getting to it first. But you'd like to know if they replaced your link. The verification code step solves this problem.
4. Open source.
Incidentally, this is written in Go because it of its good HTTP support and because Go is a memory-safe language that will also allow you to clear memory.
Other reasons for "shoot to kill" relate to effectiveness: in the energy of the situation if you aim to wound you may either kill by accident, or not hit at all.
For example, if you search for "Bob Peterson", Postgres will rank these two documents the same:
"I saw Bob."
"I saw Peterson."
In contrast, an IDF-aware search would notice that "Peterson" occurs in fewer documents than "Bob" and score "I saw Peterson" higher for that reason.
[1] http://en.wikipedia.org/wiki/Tf%E2%80%93idf
[2] http://stackoverflow.com/questions/18296444/does-postgresql-...
[ my public key: https://keybase.io/brianhempel; my proof: https://keybase.io/brianhempel/sigs/EDzJfzCMT37hI9g7tQUuQwOFIaKtcMRQIf4kQNoEyP8 ]