Comment Re:how hard do you want it to be? (Score 1) 120
Thank you, Captain Obvious!
Of course, adding a copyright license doesn't prevent anyone from using the code in a place without copyright, so that's completely irrelevant.
Thank you, Captain Obvious!
Of course, adding a copyright license doesn't prevent anyone from using the code in a place without copyright, so that's completely irrelevant.
Don't make it public domain, because that's not valid everywhere. Use CC0 or WTFPL.
They just don't to GPL
They actually do, since they publish CUPS, though with proprietary exceptions.
It's just your impression. Yale, for example, has a 20 billion dollar fund, with returns that make a Wall Street investor jealous.
Your average CCTV camera has a lower resolution than a 30 year old camcorder, and while there are attempts to bring the resolution up currently there is neither the bandwidth, storage, or processing power to capture/process all of that data cheaply enough to be widely distributed.
Sure there is, if instead of trying to stream high-def video to the mothership, the feed is processed on the spot and only the digested information (e.g., iris hashes) is sent.
Yeah, but why would you want to save a species full of jerks, anyway?
Not everyone lives in some uncivilized shithole. The cops here got my brother's $25 cellphone back after it was stolen. And they didn't need a full SWAT team with heavy gear to take it from the kid who stole it, either.
As the sibling post said, they don't. But unlike cash, Bitcoin are extremely divisible (you can send 0.00000001 BTC to someone), so the same practical problems (not having enough coins and bills to pay for things) don't really apply.
There are economic consequences of having a fixed supply, of course, but that's a different issue.
Now I'll grant you that a malicious extension could modify a link somewhere that causes *my* JavaScript code to do something on behalf of the user, but even in that case, the risk is no greater than it would be with cookies.
Well, if you used cookies, you could set them as HttpOnly, which would prevent even your JavaScript code from accessing them.
That said, I was thinking more about that scheme vis-a-vis using HTTPS, and in particular in the case of a man-in-the-middle attack. The problem with JS crypto is that you can't securely deliver the code to the browser, so all bets are off if you have an attacker that can modify the stream.
That's fine; I rather work harder than help the slave owners.
In the same way that increasing the cost of whips would help the slaves.
Because I spent a lot of time on that software, and I'm not really interested in giving it away?
So, it's not that it can't, it's just that you don't want to. That's fine, but hardly the same.
None of the ones I saw met my needs. None of them even came close, actually. The token-based authentication that most websites use makes it way too easy to sniff a few packets and then impersonate someone, and regrettably, the exorbitant cost of multi-domain certificates makes SSL infeasible at this time. Therefore, my base requirement was a robust and fairly lightweight, pure-JavaScript means of signing each individual HTTP request with a shared secret key derived from the user's passphrase and an arbitrary nonce generated by the server. (Still on my to-do list is adding synchronized timestamping and/or regular nonce rotation to prevent replay attacks, but given the site design, the damage posed by such an action would be fairly minimal, so I'm in no hurry.)
Just curios: how does your system prevent an attacker from simply replacing/modifying your JavaScript code with a snippet that copies the user's passphrase to his/her server?
Have you read Matasano Security's critique of JavaScript cryptography? Last time it was discussed on Hacker News, the only real objection was that you could use a browser extension to implement the crypto - nobody had a solution for pure, extension-less cryptography.
It forces proprietary developers to spend time and money writing their own code instead of milking the free software cash-cow. If nothing else, that makes it worthwhile.
because that authentication system cannot necessarily be made open source
What? Why not? There are plenty of open source authentication systems. In fact, I'd say it's extremely reckless to use a security system that hasn't been widely vetted, and that requires available source.
Besides, it's not true that it would necessarily require open sourcing the authentication system. If you're using something with a service interface, then only the "bridge" that extends the webapp to talk to it should have to be open sourced.
Mind you, I prefer to give those changes back when possible, because it makes future upgrades easier, but when the changes involve many thousands of lines of code changes (e.g. rewriting every single SQL query in parameterized form), this is often not appreciated as much as one might expect.
Irrelevant. None of the (A)GPL licenses require you to give anything back. All you need to do is inform your users that a copy can be arranged if they ask for it, nothing more.
I find it extremely hard to believe that a court would consider a schema to be a "derivate work".
It's not an optical illusion, it just looks like one. -- Phil White
