I'm not sure that Amazon is an outlier, but rather that as you say, other companies fear they would get raided if they tried to reinvest all their profits (what most companies probably ought to do a lot more of IMO) instead of issuing them as dividends and/or taking the money off-shore.
Given that Jeff Bezos cut his teeth at D.E. Shaw, I'll bet he went into this with his eyes wide open as opposed to the usual lucky and wet behind the ears ivy-league hipster willing to sign away 90+% of his/her idea's net worth from the get-go just to get a shot to pursue it.
Jeff Bezos was the right guy in the right place at the right time. That doesn't mean Amazon can't be taken out, it just means that someone needs to enter the space with a background capable of competing with him rather than creating another pets.com.
I have a static IP at home. I use my Pi to enforce IP-based access restrictions on most sites that allow it. I use ssh's built-on socks proxy (-D on command line or DynamicForward config option) to do this. Firefox and Chrome both support SOCKS proxies.
I'm very curious what aspect of Twitter's TLS code makes hard to intercept whereas other websites can be easily intercepted? I'm also very curious about how they intercepted Whatsapp. Does it do something stupid like eval'ing code received over regular HTTP?
Quoting the paragraph, in case my paraphrasing is inaccurate: "What’s depressing is that I could have easily helped them intercept basically all of the traffic they were interested in (except for Twitter – I helped write that TLS code, and I think we did it well). They later told me they’d already gotten a WhatsApp interception prototype working, and were surprised by how easy it was. The bar for most of these apps is pretty low."
They pin the TLS certificate: to successfully create a connection to Twitter, their mobile apps will check not only the validity of the certificate the server presents, but also a hardcoded digest of the correct certificate, so that a "valid" certificate for Twitter from a CA Twitter has no relationship with will be rejected.
What's "pinned" isn't the site's certificate, but rather the CA's certificate. Or more accurately, the CA's public key.
This is the problem with public key pinning. The site is still vulnerable to a compromise from its own CA, and many sites actually use a number of different CAs for unfortunate reasons. If you check out the list of pins for twitter.com, it's quite large. Still, at least it's not vulnerable to compromise from every CA that exists.
Trevor Perrin and I have been working on something called TACK (http://tack.io) to make all of this easier and more secure. Rather than embedding pin fingerprints into the binaries of web browsers and mobile apps, you can advertise them and update them via a TLS extension. What's pinned is also your site's certificate, not the CA's certificate, making the site additionally immune to compromise from its CA (or list of CAs, as it were).
Just a quick note that there are apps that pin site certs and not just CA certs; if you're implementing your own iOS app, for instance, you can do it either way depending on your margin of error w/r/t certificate revocation and expiration and software update.
That makes sense if yours is the only client that connects to your endpoint, but less sense if your client shares an endpoint with, say, a web app.
I try and I try to get clients to consider just rolling their own root certificate and eschewing the TLS PKI, but people have an irrational fear of the process of making certificates.
It's like Firmware in VoIP, although VoIP implementations leave something to be desired. In essence they're doing something similar to a checksum on the certificate such that any change to the certificate causes the transaction to fail.
I seem to remember their authentication was a combination of your phone number and the IMEI of your handset, which is woeful security through obscurity at best.
I was hoping for Yubikey support. But I'll take this for now.
I'll have to see if the Google Authenticator app shows up on all of my iDevices linked to my Apple account and whether the code from any of them will work (from the setup process, I don't see why not). Does anybody know?
If the app will work from any of iDevices, it would not be secure enough for a service storing bitcoins :) because the second factor should be hard to copy (which a real hardware token is, while a software token isn't).
it would not be secure enough for a service storing bitcoins
Linode was hacked twice (once where Bitcoins were stolen) in recent times and was shown to have the worst security practices I've ever seen. They have never been secure enough for storing Bitcoins.
What you were doing is the equivalent of living your wallet in a public place unattended, and then shouting and screaming it got stolen. You are putting your bitcoin wallet on a public accessible server, you should know the risks of this by now.
Don't leave your wallet in a public place unattended, that includes your bitcoin wallet.
Let me guess, you didn't bother to encrypt your wallet either, didn't you?
Don't blame others for lack of security, if you can't even figure out your own security best practices...
It's per-device, not per account (I know the guy who developed it for Google; one of the smarter people in the industry).
It uses protected storage for the credential so it isn't backed up to iCloud, either. Sadly on Android they don't have the same security features available, due to limitations in the OS; it would be fun to talk to Samsung and make a "actually secure Google Authenticator" specific to the S3/S4 since they have a security element.
If you do want it on multiple iDevices, you need to do that at setup time, by copying the secret manually.
The Duo-Security people, who have an Android Token claim to use the secure element in NFC enabled phones. It is a TOTP token and can be used just like the Google Authenticator. You don't have to use Duo-Security's system to use it (though there system is worth looking at if you are rolling out your own authentication system).
URL? I don't see anything about their android "duo push" or "duo mobile" client supporting the secure element, but their website is designed around the kind of people who buy $3/mo authentication systems (enterprise, not saas developers).
Each copy of the software needs to be initialized with a token. Google tries to limit you to have one copy initialized at a time, but I'm not too sure how effective they are.
Is this an iDevice limitation? The android version doesn't connect to Google's servers at all, so there would be no way for them to know you've setup multiple copies.
Generally it is because sites only show you the seed once; you can't get them to give you the seed again. You can just write down the seed or enter it into multiple devices if you know this when you set it up initially, though.
I personally like semicolons. It's similar in spirit to the period of English. Even languages which didn't traditionally have the period have adopted it in the last couple of centuries.
More practically, it seems to remove a class of errors. Semicolons are optional in Javascript and I've seen posts here about subtle errors that can creep in when you change code a little carelessly.
And even more practically, it allows you to type "one liners" into things like REPLs even if they aren't one liners.
The period is necessary in human languages because we write sentences next to each other and we need some way to separate them. Programming languages are line-based and are more akin to recipes or poetry. So that's a bad analogy. Unless you consistently write all your statements on a single line, of course.
Furthermore, you present a false dichotomy here. A semicolon-free language can easily have semicolons as an optional measure if you do want to cram several statements together on the same line. You mention one-liners; a semicolon-free language can support semicolons. Here's a Ruby one-liner:
>> b = Box.find(3); t = Thing.new; b.add_thing(t)
A class of errors: Well, anecdotally, I have personally never had a single issue with semicolons in JavaScript in all my years developing with it, simply because I always use semicolons. The reason is that JavaScript has a bunch of "semicolon insertion" rules that are not well understood, so dropping the semicolons is a bad idea, as the recent "fiasco" showed, and I just decided very early on not to go that route.
As I understand it, JS is a semicolon-enforced language that allows you to drop them at your convenience, whereas Ruby, for example, is a semicolon-free language that allows you to include them at your convenience. I'm not a parser expert, and I won't swear there is a significant difference except in which rules are defined. But I do know that semicolons are categorically not an issue in Ruby. So I would say that this argument is invalid, too, because it presents a flawed language as the ideal. The Rust guys should not need to base their design on JavaScript.
Being able to write if and while loops with am empty body is due to braces being optional if you only have one statement and due to the empty statement being a legal statement (doing so keepsthings simpler).
As for the second {}, its to allow you to create inner scopes where you can declare variables with a more restricted scope without needing to do something silly like "if(true)".
Empty block statements are OK sometimes with while and for loops when the real action that matters is in the condition:
while(!trySomething()){} //empty body for the loop
The semicolon following the conditional is an empty statement; it ends the if statement equivalently to "if (something()) { }". It's not often seen, but sometimes can be found in:
for (i = 0; a[i] != x; i++) ;
to find the first index equaling x.
Personally, I always use braces in conditional and loop statements, so I'll never have the empty statement semicolon. But that's me.
> Personally, I always use braces in conditional and loop statements, so I'll never have the empty statement semicolon. But that's me.
But if you have
if (something()); { somethingOther(); }
Then you have a new problem: you intended the braced statement to execute iff the if-statement evaluated to true. But since you put the semicolon after if by accident, now the braced part will execute no matter what the if-condition evaluates to.
(my point was about unintentional use of semicolon after if-statement - in which case always using braces doesn't seem to help.)
The big difference is that Flask is based on other technologies such as Werkzeug and Jinja2 that exist for a longer time and it does not try to reinvent things. Bottle on the other hand tries to stick to the one-file approach. I want to merge them but the Bottle developer does not seem to be very happy about the idea of stepping away from the “one file” requirement.
Regarding flexibility: there are no reasons you shouldn't be able to use flask with other template engines if that's what you're after. In fact, things like Flask-Genshi exist: Flask-Genshi and it's incredible easy to use mako with it, even without extension if you want to.
Bias warning: I am the developer of Flask, Werkzeug and Jinja2.
In my own experience, both are great, and similar. For a simple REST API bottle has an added advantage of being a single file which is nice to just include with all of your other code rather than having to install anything. Flask, however, is my go-to framework. I used it extensively at a previous job and still do today with my current employer (and the app is pretty substantial). Flask also has a lot of extension support now. A pip freeze | grep Flask yields the following for one project.
>The big difference is that Flask is based on other technologies such as Werkzeug and Jinja2 that exist for a longer time and it does not try to reinvent things. Bottle on the other hand tries to stick to the one-file approach. I want to merge them but the Bottle developer does not seem to be very happy about the idea of stepping away from the “one file” requirement.
And seeing that Flask still does not support Python 3, while Bottle does, I'm happy with the decision of the Bottle developer.
Not to mention that the "one file" makes deployment very easy.
Plus: Bottle is quite faster than Flask, even if you count the overhead of a DB query:
> Plus: Bottle is quite faster than Flask, even if you count the overhead of a DB query:
If you see bottle being faster than Flask in a real-world benchmark and the difference the problem there are still knobs to turn if you need to. Flask does not optimize at all for Benchmarks and you pay for some overhead out of the box for a better development experience.
In my mind, there are two main differences. First bottle supports Python 3. Second, Flask is built on Werkzeug, which is a very flexible WSGI toolkit. In practice, I have never used Werkzeug much, except for the excellect stacktrace pages, which let you run the debugger right where you problem failed. I pick bottle for new projects, basically because of the Python 3 support. Fixing unicode is worth quite a lot to me.
Also, Flask the concept of modules/Blueprints for building larger apps. I'm not sure whether Bottle does or not, but the bottle website seems to imply that it's optimized for single file applications.
I used Bottle for a small learning project, though, and found conceptually a lot of things are very similar. We ended up using Flask because it seemed better constructs were in to use it as a foundation for a large code-base, similar to Django, but custom built with legos.
Try Adobe Lightroom [yes, our favorite whipping boy Adobe :)]. It's really really awesome as a photo management tool. IMHO. If you find it slow, try throwing in an SSD. Don't run it with less than 8 GB RAM.
I can second that. Lightroom is indeed an awesome tool. You should really check it out if you have large amounts of images to be organized and want to bulk-optimize them. It takes some dedication to get used to the workflow and the available set of tools (many!), but it's worth it. Also, Adobe dropped the price significantly some time ago, making this great product available for a bigger audience.
Given your last point re: kids, how is it "insane" that people want to buy houses? Most people have/want to have kids.
Btw, I don't agree with your last point. It's pretty much possible to stay in a rented apartment for 5 years at a time quite easily. And kids go through wrenching changes every five years on average (home->kindergarten->middle->high school).
You make good points about the drawbacks of buying a house. However, the ability to lock in your housing expenses for the next 30 years (i.e., no impact of inflation) shouldn't be underestimated. IMHO.
Amazon is an outlier.
If another company did this, but it's stock price didn't keep rising, corporate "raiders" will replace the board and get money back as dividends.
Sorry if my point isn't clear. I'm typing this in a hurry.