Speech should absolutely be protected—even threatening speech. However, if you say (credibly) that you're going to do something, other people should also be able to take you at your word and respond accordingly. That isn't punishment for the speech, it's a reasonable preemptive response to the action you claimed to be planning.

The usual rules for preemptive responses apply: there must be a reasonable expectation that the action is imminent and would result in irreversible harm.

They're one kind of private asset. There are others. Eliminating all public liabilities would not eliminate all private assets. Also note that the effects are not as evenly distributed as this simplistic balance-sheet view would suggest; "public liability" refers to the majority of future taxpayers who will be made to service the interest on the debt, while the interest-generating "private assets" end up in the hands of those select few with the ready capital (both financial and political) to purchase them. Not the sort of thing to promote if you favor a more equitable distribution of wealth.

When it comes to debts, that's pretty much exactly what it means:

If someone who owes you a debt offers to pay the full value in legal tender (regardless of the original form of the debt), you can either take what they're offering or give up on collecting. In general the offer must be exact; if someone who owes you $5 hands you a $100 bill, that legally satisfies the debt but you are under no obligation to provide change.

This doesn't mean that all transaction must involve legal tender, or that you can be compelled to trade goods or services for legal tender. It only applies to debts. If you insist on payment up front, rather than extending credit, then no debt is created and you can make the transaction conditional on whatever payment method you prefer. (Barring laws in the more restrictive jurisdictions outlawing alternate forms of payment, which is a separate issue.)

No signal which carries information can be perfectly distortion-free. Just switching the carrier on and off is a form of modulation (akin to a continuous wave RF transmitter), with a bandwidth dependent on just how quickly the amplitude is switched, which is related in turn to the maximum rate of data transmission. This can easily result in signal components below the carrier frequency.

However, a quick search suggests that harbor seals respond to frequencies as high as 180 kHz in water (with a peak sensitivity around 32 kHz), so they may well be able to hear the tags' carrier frequency directly.

In this case there are (potentially) many points. No one node can connect the source and destination of a given connection, but if the attacker monitors or controls enough of the internal routing nodes then it's not that difficult to analyse the timing and build up a statistical model linking the endpoints over time. For that matter, a busy .onion site would tend to stand out no matter how obfuscated the routing, simply because of the increased traffic.

That isn't true. They're calling the tablet's software "Gnome(TM)" as well:

Even if they were carefully using the name to refer to just the table rather than a "platform" (which would also describe GNOME(TM)), just imagine the hilarity which would ensue if some random company decided to market a "Windows(TM) tablet" without first clearing it with Microsoft(TM). Also note that there are existing Point-of-Sale terminals running the GNOME(TM) desktop environment.

The phrase "turn about is fair play" comes to mind. You always have the option of responding to another's actions in kind. You can't claim a right which you don't extend to others. The thief has no legitimate claim to property rights; the murderer cannot claim a right not to be killed.

If it was a mere promise, then yes. A promise of future action is not binding in the way that an actual transfer of ownership would be. (This is a consequence of inalienable self-ownership; the property rights themselves are transferable, but there is no right to make someone else act in a certain way.) On the other hand, if we had an established contract transferring the ownership to you, then by refusing to turn the property over after you became the owner I have stolen it from you. Withholding property from its rightful owner is an act of theft however it came to be in one's possession. At that point you would be free to respond in kind.

If you want assurance that a promised action will be carried out you can stipulate a performance bond, which is a conditional future transfer of ownership—not "I will perform the service" or even "I will give you the property if the service is not performed", but "the property is yours as of this future date if the service is not performed". You still can't compel the person to perform, but in the event that they don't, they already gave you the rights to the designated property when they agreed to the contract.

Perhaps. However, I'm not saying that the device should be locked down like Apple devices are—you should be able to install apps from other sources, at your own risk. Distributors (and particularly the default distributor for broad range of devices) should take responsibility for the behavior of the apps they distribute; users, in turn, should be free to choose where they get their apps from.

That won't really help. The problem isn't asking for permissions which explaining why they're needed; the problem is what the app can do with those permissions once it has them. Sure, that social media app has a nifty feature for inviting your contacts to join, and for that it needs access to your contact list (whether you want to use the feature or not). But once it has that access it can just as easily grab all your contacts' e-mail addresses for the purpose of sending junk mail.

In most cases it's entirely possible to disable a permission in a way that won't cause the application to crash. Instead of supplying the user's real contact list, just give the app an empty list. When the app asks to connect to the Internet, pretend the device is in airplane mode or out of the service area. Never reveal that a permission was denied, since that would allow the app to refuse to work without it.

As for whether the permission should be enabled in the first place, the system should ask the user the first time the permission is used. And rather than listing what the app claims it will do with the permission, the system should list the most damaging things the app could do with it.

To fight "permission bloat", every additional permission requested by the app should also require a thorough audit by the app store (at the developer's expense) to verify that the permission is used responsibly. Someone needs to follow up on how permissions are used as a basic security precaution, and it isn't reasonable to expect users to take up that task for apps released through the app store. (Sideloading is another matter.)

I agree that it would be interesting to see a definition of object-oriented programming which didn't include Smalltalk. However, Lisp has never been all that different from well-known procedural languages except for garbage collection, closures, and the use of lists as syntax—none of which are necessary or sufficient for functional programming. These features (the first two, anyway) make it easier to write functional programs in Lisp compared to, say, C, but they don't automatically make all Lisp programs functional. Programmers being programmers, the end result is procedural programming in a functional-capable language.

The pure functional languages, on the other hand, push programmers to actually use the functional style. Even when they support a familiar procedural syntax (like "do" notation in Haskell) the evaluation model remains referentially transparent. Since the whole program is guaranteed to be referentially transparent, it's much easier to reason about its behavior, both for the programmer and for the compiler.

Wikipedia gives a good general-purpose description of functional programming:

This implies referential transparency. Scheme, Lisp, JavaScript, and other impure "functional" languages are really multi-paradigm, and more often used to write procedural programs than functional ones. While they do have the necessary language support for functional programming, the fact that they are impure means that even when you're following the functional paradigm you can't count on the rest of the program playing by the same rules. Any call to external code may perform I/O or depend on or modify global mutable state.

The TREZOR is close to what the GP requested, or would be if 7-11s sold bitcoins. It requires a PIN to spend the funds, which protects against theft, and if it's lost or stolen or simply stops working you can recover your funds with the backup seed and any of several compatible wallet programs. Aside from the backup, which you keep in a secure place, the key never leaves the device, so you don't have to trust the USB host.

I just checked with my AT&T mobile phone and found an "x-acr" header which seems to serve much the same purpose, so switching away from Verizon might not help. (The header is not present when accessing the site through a VPN, so it wasn't sent by the browser.)

The content seems to be based on the Anonymous Customer Reference concept promoted by the GSM Alliance.

The number may have been assigned by the USB WG, but it was the manufacturer who decided to check for it in the drivers. Either way, the use of that number is a necessary part of creating drop-in-compatible hardware.

Of course, they can't advertise their product with the USB logo if they're not following the USB specifications, including the use of assigned ID numbers, but that's a separate matter. There is no requirement for non-members to adhere to the ID numbers assigned by the USB WG so long as they don't claim to be fully compliant.

It is a textbook trademark case, but you're referring to the wrong part of the textbook. Consider the case of the game consoles which wouldn't operate without a bit-for-bit copy of the manufacturer's logo in the ROM, a trick intended to shut out unlicensed game developers. The court ruled that third-party developers could include the logo image without a license despite the fact that it was both copyrighted and trademarked, because the manufacturer had chosen to make it necessary for compatibility.