andreaso

Are you aware that the child zone A(AAAA) records for danube.ns.ptrdns.net differs from the parent zone A(AAA) glue records for danube.ns.ptrdns.net?

Looks like it's the glue records that point to the actual server?

That sshd only supports the chacha20-poly1305 cipher.

Perfectly fine with that, since I'm the only one logging into that server.

It appear to have problems with newer chiphers.

sshd[28670]: fatal: Unable to negotiate with 40.112.150.31 port 47286: no matching cipher found. Their offer: aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,3des-cbc,twofish256-ctr,twofish192-ctr,twofish128-ctr,twofish256-cbc,twofish192-cbc,twofish128-cbc,twofish-cbc [preauth]

Does it really matter that much what distro it ships with? As long as the laptop ships with any distro preinstalled that hardware tend to be properly supported by the Linux kernel, allowing you to feel safe about installing any other (up-to-date) distro.

I'd imagine there are people who consider the article relevant based on its author.

https://en.wikipedia.org/wiki/Adam_Leventhal_%28programmer%2...

To be fair, at least the Tor Project itself makes a rather serious effort to be upfront with its own limitations, etc.

For example, when you use the (recommended) Tor Browser Bundle the start page contains a window containing the following headsup

"Tor is NOT all you need to browse anonymously! You may need to change some of your browsing habits to ensure your identity stays safe."

As well as a link to https://www.torproject.org/download/download.html.en#warning.

That same warning is also present on the main download page: https://www.torproject.org/download/download-easy.html.en

Well, if you want you can always manually download and verify the the packages.

1) Find list of applicable binary packages, for example by taking a look at https://packages.debian.org/source/wheezy/apt

2) Download http://security.debian.org/dists/wheezy/updates/InRelease, and verify the gpg signature against the archive signing key, found in /etc/apt/trusted.gpg alt. in /etc/apt/trusted.gpg.d/*.gpg

3) Download http://security.debian.org/dists/wheezy/updates/main/binary-..., and verify that its sha256 sum matches what you have in your previously downloaded InRelease file.

4 Inside the downloaded Packages.bz2 you'll find the relative paths as well as the sha256 sums of the packages you want to download.

If nothing else this is a good exercise to see how the different pieces fit together.

Yepp, and there is already an existing tool, which currently supports GitHub as well as Launchpad.

http://manpages.ubuntu.com/manpages/trusty/en/man1/ssh-impor... https://launchpad.net/ssh-import-id

Well, despite its imperfections, how does DNSSEC worsen security compared to regular DNS? Besides, it's not like the use of DNSSEC prevent you from continuing to also rely on additional measures; such as good old fashions CAs, or something better.

Yeah, I'm getting that same premium experience.

Appear to also hit Google Apps as well as any AppeEngine hosted site.

Well, FreeBSD 9.0 merged those patches into its OpenSSH. Perhaps that was what was floating in the back of your mind?

A bit unhappy about Indiegogo, insisting on "Shipping Address Line Two can't be blank"; when my regular postal address really is fully covered by Name, Country, Address Line 1, City and ZIP Code.

Sure, I could probably fill in some kind of apartment number or so. Yet, it's not something I usually have on in my postal address, and it's definitely not something getting a line of its own.

Also, that seemingly broken requirement bugs me.

You know, IPv6...

I'm getting a false "Your email has been received and it doesn't leak your IP", due to the fact that the web site is only available using IPv4 while I'm connecting to my SMTP server over IPv6. As long as the website only captures IPv4 addresses it really might need to display an inconclusive result in the presence of IPv6 received headers.

Oh, and when the web site do become IPv6 reachable you probably will want to make an explicit attempt to also catch a potential IPv4 address, in the case situation above is the reverse.

I have a clavid.com openid delegated using my own domain...

While I mostly agree I also think that having some legal/jurisdictional protection is a good thing. If nothing else for the case where there turn out to be an exploitable weakness in the client side encryption you are using.

You appear to threat trust as something binary; either you trust a host or not? In my world trust (as well as security in general) is always a spectrum, or something more multidimensional; that you trust various host to different degrees, in different way against different threats.

Let us for example say that I have a server which you are fairly certain that noone will compromise, but you do have a concern that someone might physically steal it. In such a case you might be more likely to trust the javascript it serves than you are to trust it with storing your actual private key.

(Yes, I realize that someone who gets physical access to the machine will be able to modify its code, etc. Yet, while it might be fairly easy for someone to physically break into a building it might be harder to do so without leaving any traces behind, alerting you of possible tampering.)

By the way, my trust example above is fairly similar to the use of ssh-agent forwarding; where you trust a machine enough not to abuse an active forwarding, but without having to trust it to actually store your private ssh key.

Neither do I understand why you appear to say that SSL would provide a comparably security. OpenPGP will definitely provide a stronger transport security than the possibly of there being SMTP StartTLS being done. Likewise might OpenPGP matter for the recepient, especially if that person are doing the decryption locally on a workstation/laptop, saving that person from having to trust his/her mail provider.

Someone is gracious enough to release their code base, and choose to make a snide remark about their choice of hosting?

Building a kernel of your own is fairly trivial. The potentially less trivial part is keeping it up-to-date with security fixes, etc. Not impossible by any means, but it does require a bit of a commitment in time, build environment, etc.

Regarding FastMail and the US.

* FastMail have their servers in New York City (as well as on Iceland).

* Opera Software do have an office in the US.

I have no idea to what extent that puts FastMail under US juristriction.

(Disclaimer: I work for Opera Software, but not on the FastMail team.)

...or that they simply considers github to have a more robust server infrastructure?

Fairly certain that there aren't any publicized spec for OBML (aka Opera Binary Markup Language, aka the Opera Mini markup language).

http://dev.opera.com/articles/view/opera-mini-web-content-au... does contain some good info on Mini, even if it may not be what you were wondering about.

No, Opera Mini and Opera Turbo works a bit differently. While Turbo provides compression the actual rendering is always done locally. With Mini on the other hand the rendering is done server side, and then sent to the Mini client using an Opera Mini specific markup language.