wampus

I have IPv6 through my ISP, Comcast. It's completely broken and unusable due to a bug in the router they upgraded me to last year and force me to use because I have a business account. It took me half a day to figure out the cause of the problem. I'll probably wait another six months to look at it again. This is just one of many sad details plaguing the rollout of IPv6. Maybe the solution will come by skipping it entirely and using something backwards-compatible with IPv4, only with a larger address space (baby steps).

I remember reading about American Indians killing nursing buffalo calves and cutting open the stomachs to feed the curdled milk to their children as a special treat (almost like ice cream). Surely hunters of mammals throughout the ages were familiar with this delicacy. Why isn't this considered the 'discovery' of cheese?

In this case, that's an appropriate attitude. If your environment is a mess and you add complexity with a CDN, you've got a complicated mess. But a local optimization like this benefits your entire organization and puts off the need for a CDN (a solution to a problem that no longer exists). They may grow to a point where a real strain is being put on their systems, they can't make local improvements, and involving a CDN is the right choice.

A nice benefit of using DuckDuckGo is the distinctive way it flags an official site.

Thanks! Any idea what the quoted carriage return does? I wouldn't have thought of that in a million years.

But how do you combine the two on the command line, so less is tailing the file AND highlighting a pattern when launched?

I typically read logfiles with less +F, but it would be nice to create an alias for patterns in specific types of logs, so I don't have to remember them or rely on command history.

I don't think it's permanent, but once you authenticate, any other device that can spoof the MAC address can connect. It might expire a month or so after the last connection.

Who, what, where, & when are mandatory items on a checklist for this type of communication. But if the way you point to them draws attention to your finger and away from the vital information itself, you've failed. That's why the headings are useless. You allude to this yourself in your final sentence.

The thing is, none of those headers are even necessary. For example, replace "Beginner Class" with "AIKIDO", remove the "Regular Classes" and "Come Visit" headings, enlarge the text, and you've already improved the poster.

For bonus points, pluralize the days ("Tuesdays 7:30 p.m.") and separate the phone and URL from the address a bit.

The point is, the information is self-describing. It doesn't need a header to announce what it is.

A better test might be: what if this was a street sign? I'd probably have to get out of my car to read the one on the right. If the goal is to convey information quickly and efficiently, I think the left one has the edge.

The important information is larger and more legible in the poster on the left. I can locate the schedule, address, phone number and URL immediately.

In the poster on the right, my eye is drawn to the enormous headings, which contain no useful information by themselves. The "Come Visit" heading isn't close enough to the address, and the address/phone/URL has been squeezed into a single block of tiny, fuzzy text. Compare that to the left poster, where each one is distinct from the other.

I feel the need to put on my glasses to read the one on the right, but not the one on the left. That alone indicates a major issue and potential loss of audience.

It appears AWS lets you configure this[1]. You may have chosen a policy and never changed it. A note on that page says if you don't choose a policy, you'll always use the latest one. It looks like you can create a custom one, as well.

[1]http://docs.aws.amazon.com/ElasticLoadBalancing/latest/Devel...

Lynx doesn't support images, CSS or script. It does support cookies and redirects (by default it prompts for both). Basically, it renders the bare HTML of the page you open, without fetching external resources. If you find it behaves differently, make sure your lynx command isn't actually symlinked to links (or another text browser with graphical/enhanced capabilities).

A typical Mutt configuration relies on the entry for text/html in ~/.mailcap. It's quite common to use lynx for rendering, as in the following:

    text/html; lynx -dump %s; nametemplate=%s.html; copiousoutput

Since lynx doesn't load images, that would be safe from this kind of tracking. But another configuration using a different renderer might allow it.

Furthermore, it is also possible to prefer the plaintext version of an email if there's a choice. From my ~/.muttrc:

    alternative_order text/plain text text/html

I can't remember ever being put out by not being able to read messages that fetch images from the web. Even if I have to open a URL, I do it in Firefox, where I run RequestPolicy.

I believe it's up to the Exchange admin to require a PIN or remote wipe capability, so it will vary from site to site.

One workaround is to use IMAP, if available (also up to the admin), but you lose the calendar capability, which is arguably the killer feature of Exchange.

Another workaround is to increase the time your phone will require a password after inactivity to something large, like 30 minutes or an hour. You still have to enter a PIN once in a while, but it's more convenient and will still be effective in some cases when lost or stolen.

Alcohol is a common solvent used to create varnish, so it's not that surprising.

Encryption can be implemented flexibly on systems you control. When it come to encrypting backups, the toughest issue is doing it safely on target systems you don't control (duplicity attacks this problem well). I'd recommend starting there. Encrypted replication is a very interesting idea, and actually helps with the problem of maintaining local & remote backups. I usually stagger them, but being able to replicate to arbitrary targets would be very convenient (I don't like to rsync backups after the fact, because you risk corrupting the target if there is a local failure).

I use rdiff-backup as my main backup solution. It's efficient and restoring from the latest backup is reasonably fast and simple. But I've found that the further you go back in time, reconstructing the file from all the deltas takes so long I don't consider it useful as an archiving solution. At least that seems to be true for large and/or complex collections of files. Have you actually restored large databases from years ago in less than a few hours?

"Once we have the SHA1 name of a file we can safely request this file from any server and don’t need to bother with security."

I don't understand this statement. Dispensing with encryption makes the request and returned content susceptible to passive observation. Saying that this approach is resistant to active manipulation assumes the existence of some kind of web of trust between hashed documents. At some point you're going to have to click on a hash without knowing its provenance. How do you know you're not being phished?

But if you can run this, you can run VirtualBox, which is a much safer alternative (and simpler, if a live ISO meets your needs).

Is someone testing their MarketSpeak Generator?

I absolutely hate dealing with vendors who use Salesforce.com. It's a red flag that support might be dismal. The only lesson to be taken from this is that you can build a business around a terrible product.

Even when it was popular, you had to compile qmail from source after applying third-party patches to provide necessary features. For sites that wanted to leverage a distribution's package manager for seamless integration and security updates, this was a huge barrier to entry.

It sounds more like a side effect than a bug. Both domains have conflicting policies. He wants any Gmail user to be able to impersonate a sender from his domain, but not in a way Gmail supports.

Indeed. Email forwarding has been broken for years. I don't allow it on any MX I run. Even with the best defenses, it's too risky to allow users who are spam magnets to harm your server's reputation.

Just my 2 cents, but I feel strongly that publicly released programs should be named with a minimum of 3 characters, reserving shorter names for user aliases and local commands.

I version control the entire directory (ignoring the known_hosts file) somewhere like ~/config/ssh and symlink it to ~/.ssh. It contains a Makefile with a target that runs this command:

    ln -s ${PWD} ~/.ssh

Just make sure the directory is chmod 700 and the important files in it are chmod 600.

I like the idea, but you'd be amazed at how many databases only allow 30 character email addresses, or javascript email validators that don't recognize "+" as a legal character.

I love the concept of certificate pinning, but I don't see how it solves the core problem:

User: Why should I trust this root CA to secure this domain?

Domain Owner: How can I specify which root CA should be trusted to secure this domain?

If neither of these parties are significantly involved in the trust decision, how can it be said that trust has been established at all?

Most pinning implementations seem to either delegate the trust to someone else (browsers, OS, libraries, etc.) or blindly trust the information presented in the first encounter. This is no different than the historical model. There's nothing preventing any application from presenting a warning when a known certificate changes or a new one is encountered, so what does pinning offer other than extra complexity?

Locally cached relationships aren't any more viable than using an /etc/hosts file for the whole Internet (and pose additional privacy concerns). Leveraging DNS is a worthy goal, but if it was secure enough for this purpose, it would eliminate the need for pinning because a domain owner could confidently present its public key via DNS.

I believe in defense in depth, and this work is important, but we seem to be making little progress in solving the fundamental problem of establishing trust. Maybe it's as unsolvable on the Internet as it is in the real world.

You've undermined both if your proxy is powered by Komodia or another product with similar flaws. What if you've hardened your workstations, but your proxy client supports inferior ciphers? All that work is undone. What if your proxy is easily fingerprinted? That's valuable information to an attacker. There are so many details to get right, and it can take years to discover the flaws that can be exploited by an attacker poking in the right places.

If the button image is hosted on Facebook's servers (and it commonly is), they have a log of your request for it, including the page it was on (from the "Referer" header). This request is sent when you load the page, without the need to click on the button. Every site you visit that includes a Facebook resource gives them the ability to collect data about you and your habits. These are often part of a site's template, included without regard to the page it might appear on. You'd be surprised what a Referer URL can reveal about you.