tyler_larson

reCAPTCHA is a rate-limiting measure. Google handles all the heavy-lifting and attacker protection for you, and the slow fade you see in the video is that rate-limiting in action. But if you get a clean CAPTCHA result back from them, then that client is very unlikely to be an automated attacker. It's super easy and scales really well.

Conveniently, normal users with typical browser configurations get nothing but the animated checkbox. For nearly everyone, the whole experience is simple and easy. The only people who get inconvenienced are the low-grade privacy enthusiasts who think that preventing tracking is the path to Internet safety. Ironically, "tracking" is literally the mechanism by which legitimate users can be distinguished from attackers, so down that road lies a sort of self-inflicted hell for which the only sensible solution is to stop hitting yourself.

Congratulations, you played yourself.

It's not Firefox that's the problem; reCAPTCHA works just fine on Firefox. It's all those anti-tracking measures you installed and enabled -- they work by making your browser indistinguishable from a low-quality bot, kicking the website into self-defense mode. The slow fade is a rate-limiting measure. It's annoying to you, but it's more annoying to people trying to automate login attempts.

The site is attempting to protect your account by preventing automated attacks against it. Meanwhile your browser is doing it's best to look like a shell script, refusing to send any sort of behavioral feedback or distinguishing characteristics that might give away the fact that you're a human.

So the question is: is it really worth alienating those quirky, paranoid users who take extraordinary anti-tracking measures, just to protect your normal users from automated attacks?

Yes.

Of course it is.

> This may sound melodramatic...

Yeah. A bit.

Thing is, Blink is not Chromium, Chromium is not Chrome, neither of them is Google, and BSD-3-clause is a pretty damn solid bulwark against the monopolization of the "control of fundamental online infrastructure", were that to ever become a concern again.

And the other bit is that the building blocks that make up Chromium power a lot of technology that is totally independent of anything under Google's influence, including NodeJS, Cloudflare's Workers, Microsoft's VS Code, and Amazon's Firecracker. They use it because it's solid, well-engineered tech. And even though Google wrote it, Google can't control it or stop you from using it against them. Microsoft isn't ceding anything at all to Google, Google's not in control of anything here.

The uncomfortable truth is that the role of neither Gecko nor Firefox nor Mozilla is particularly critical in terms of protecting the free and open Internet. What prevents Google from going all IE6 with Chrome isn't Mozilla, it's Chromium. If IE had been a BSD-licensed open-source project since 1995, then all the BS we endured in 2002 could never have happened; explorerium would have been trivially forked to create a sensible competitor with no switching cost.

Google tied their own hands from the very beginning, and by ensuring Chromium doesn't lag behind, they're keeping their hands tied. Almost as if they were doing it on purpose. In fact, the fact that Microsoft is switching to Chromium locks both tech giants into an intriguing sort of bargain. Each can benefit from the other's work as long as neither strays too far from the open source codebase, as long as they both push their changes into the open. So you end up with a reasonable guarantee that the future of the Internet stays independent; not because of a nonprofit competitor with a strongly-worded manifesto, but because none of the the main players can afford to make it closed.

I dug into the details earlier this year, and it turned out at the time that Microsoft counts some undisclosed but significant percentage of revenue from sales of Office 365 in their "Commercial Cloud" category, even if you buy it in a box at a store... because in theory that box entitles you to Office In the Cloud. This (Azure plus some percentage of Office) is the "Azure" revenue number that gets compared to AWS and GCP to determine the market share number that you see in all the graphs.

Can anyone confirm/deny? I'm reasonably certain this is right from my reading of financial reports, but I'm no accountant.

The idea of SMTPing email out from your home ISP turned out to be problematic once spam became a business model. Gmail's not the only place that categorically won't trust it.

You need a mail server. You can run it yourself if you're in to that sort of thing, but you can't run it off a residential/consumer uplink. Sorry, this one's non-negotiable. Then your home server authenticates to your mail server as a client, and send email through your mail server. Your mail server is recorded as the IP address of origin, not your home address. MTAs are already designed to do this with nearly zero effort on your part, so you don't have to change your workflow, just your config file.

Don't want to pay for a mail server? Good news! There's like a gazillion services that actually do this for free. Gmail actually turns out to be one of them. Don't want to have to use Oauth? Good news! Gmail's not the only mail service. There's ten billion others.

Gmail's primary UI is a web browser. How... how do you think that _actually_ might work?

The thing is, in this case we HAVE a solid pictures of every alternative. There's no speculation necessary. We have the "before" and "after" story to point to, and we even have the "alternate universe" story along with it.

Before Android and iOS, the phone ecosystem was pretty mature already. There was more os-level diversity but a lot less choice. It was just half a dozen utterly crappy worlds of lock-in, with barriers to entry that kept newcomers strictly out, and removed any hint of incentive for the incumbents to improve their platform. Remember everything was SO BAD that blackberry actually looked good in comparison? It was practically a parody of monopolistic inflexibility. Regardless of platform, everyone universally hated their phone with such passion that it was a meme in its own right.

Google and Apple both poured a boatload of money into each making a phone platform people would actually like to use. That alone was revolutionary. But each company showed their philosophy in how they presented it:

In the Apple case, the iPhone was shiny and proprietary and carefully presented and DONT TOUCH THAT. You couldn't even write apps for it. You could have web pages, that was enough for you.

In the Google case, Android was open and messy and unconstrained. It wasn't locked down an any meaningful sense; Google originally just kept some basic control of their branding and their marketplace. But without rules, carriers went back to their old tricks, and the ecosystem started to crumble. Remember that almost nobody but Google ever ships "Android", every carrier and manufacturer ships their own fork of Android. And for a long while they were all pretty bloody awful as everyone in the supply chain tried to extract value with preloaded apps, ads, lock-in features, crap hardware, and egregious branding. So using their only leverage (the play store), Google has slowly and carefully been pulling Android back from the brink.

Ironically, sadly, it's exactly these actions Google took to save Android that the EU objects to. They can't see (they refuse to see) the whole picture; they just see the tiny bits they think are relevant. They're like a nearsighted sleuth who finds blood on the floor in a hospital, and arrests the first nurse they see for the murder of persons unspecified. Whatever you say of the evidence they found, they clearly don't even begin to understand the environment.

As for the two companies and their strategies: For Apple, their phone very literally saved the company from demise. They make so much money from selling iPhone hardware that nothing else they do is even important. For Google, going the "open" route with Android wasn't the strategic commercial miracle we like to pretend. But if (and only if) you look at Android as an investment in the future of their Search business, then you can justify the ongoing expense. If you think of how much money it _could_ cost Google in ads revenue to have Apple or Amazon monopolize and manipulate the market, now you've got something huge.

Android can't survive on its own. There's nothing even there to survive; it's not a business. But it can be part of the search and ads business. That's where it can find a niche.

Remember that Android was, and remains today, the ONLY successful open-source consumer operating system, ever. There isn't even a runner-up. Nothing. This is not a business model with legs.

No, it's functionally equivalent to uninstalling; the only difference is that since the app was installed on a read-only filesystem, the apk can't be deleted. But it's gone as far as the OS cares; it can't be seen or used or run (even in the background) unless the user manually re-activates it.

Android added this capability specifically so that users can remove anything that's pre-loaded, regardless of what any company wants. There's no iOS equivalent because Apple doesn't want to to remove their stuff.

I guess it depends on how "experience" is defined. I had 8 years of "experience" programming before my first full-time paid job.

I am somewhat entertained every time a see jobs requiring 10+ years of experience with Go or Typescript or Swift. It's a sign of just how well-thought-out these postings are.

Sponsored by Morton Salt? I knew it was too good to be true.

It seems like every free arts-promoting venture these days is just another opportunity for _Big Salinity_ to push their salty agenda on us!

Follow the money!

This is perfect. Now I can translate all my Pascal into Haskell.

Trading on research, no. But attempting to artificially manipulate the market while doing so is effectively "pump-and-dump" but short instead of long. A lot comes down to timing and exactly what the communication says.

Not a sure-thing conviction, but certainly a dangerous business plan.

This first of all: never underestimate the nearsightedness and self-importance of a university governance board.

http://wikipedia.org/wiki/Whataboutism

The problem here isn't so much that Amazon is going to hurt Google. Google will survive. But we only hear about this story because Google is who Amazon is attacking (today).

The bigger problem is that Amazon has set themselves up as the global arbiter of commerce, acting as a relatively neutral marketplace matching buyers to sellers worldwide, replacing many or most of the smaller commerce hubs and marketplaces that used to exist.

But once in that position, they exercise control over which products can be sold with the explicit intention of destroying competitors, replacing what would otherwise be a consumer favorite with their own inferior (according to market preference) alternate.

Everyone talks about monopolists and moral hazard and market manipulation, but Amazon seems to be the only modern company with the unique combination of dominance, confidence, and poor executive judgment to actually make it a consistent and overt company policy.

It sounds like the report glossed over a rather important bit of ux:

If, when logging in, you see a big modal dialog asking if you want to grant webusb access to the site, then DONT select your yubikey out of the list of connected USB devices and click "Allow".

As long as you can convince yourself to avoid taking that particular unusual action, it sounds like you're fine.

For instance HTTP 2.0 does not require TLS, but none of the browsers support plain text HTTP 2.0. (So the browsers are ignoring the standard)

H2 requires TLS for practical reasons; without it, poorly-written transparent proxies mangle this protocol that they don't understand. Requiring SSL was the solution to this otherwise intractable problem during the initial SPDY work, and became a hard requirement for SPDY. But due to pressure from certain groups during the IETF standardization process (who didn't want the web to "go dark"), this requirement from SPDY was dropped in the official HTTP2 spec.

But dropping the requirement from the spec doesn't solve the problem that put it there in the first place. You still can't reliably use any protocol newer than HTTP/1.1 unencrypted with many ISPs. It's been demonstrated to fail in ways that are difficult to debug and which would otherwise make HTTP2 seem unreliable. So no consumer-facing implementation will let you try.

You misunderstand what CAs are. Or, indeed, what their certificates imply.

CAs don't provide permission, they vouch for an identity.

Saying that CAs give you permission to communicate is like saying notaries give you permission to sign a contract. You can assert your identity without verification as long as the other party in the relationship is fine with the increased risk of fraud.

Similarly, you can use HTTPS without a signed certificate (precisely as you can use HTTP without HTTPS) as long as you and the other party is happy with the risk that Verizon could be "sanitizing" your speech or injecting your real-world identity into all your HTTP requests without your knowledge.

But both the site operator and visitor stand to lose from someone tampering your traffic. And increasingly, it's the users that are getting burned in this relationship.

So then it's akamai or limelight, then. Still not a threat.

Open standard, opt-in free cdn, independent compatible alternatives; this does not sound like a hostile takeover of your freedom.

A VPN tunnel in the abstract provides the benefits you mentioned, but a VPN service is a slightly different beast. It doesn't solve the problem with your untrusted ISP, it just gives you effectively a different untrusted ISP.

Imagine if, in response to the question, "how do I protect myself from snooping ISPs" someone provided the answer, "Just use an ISP that specializes in providing anonymity." You'd probably object on the following grounds:

* Saying you provide anonymity doesn't mean that you actually do. And track records tend to demonstrate otherwise.

* Your ISP still knows exactly who you are, even if they promise not to tell.

* ISPs who specialize in shady customers are more likely to be under surveillance themselves, meaning you're now more likely to be under surveillance rather than less.

* You're solving the wrong problem: you need end-to-end privacy, not just customer-to-ISP

You'd be right. But more importantly, these same objections apply to VPN providers. They more-or-less ALL specialize in aggregating known-suspicious traffic, which is not the bundle you want to be tied in with.

In fact, any argument you could make against using a Cloud VPN endpoint can also be made against a VPN service provider. Because, and this should be painfully obvious already, VPN providers just terminate their traffic through Cloud and/or Colo hosting providers as well; usually optimized on bandwidth cost over all else. So by setting up your on VM, you're just cutting out one of the middle men. There's nothing they can do that you can't do just as well without them.

The GDPR was specifically sold as limiting the things that well-known US tech companies (Facebook, Google, Twitter, etc.) can do with respect to EU citizens. The sad irony is that only well-resourced tech companies with a small army of lawyers and a large army of programmers can afford to be GDPR compliant.

The sort of unintuitive machinations it takes to maintain honest compliance while providing useful services is kind of mind-blowing. Every bit of it that I've delt with has left me depressed about what this will do to small companies and innovation. Facebook will have no trouble at all being GDPR compliant, but your average 50-person startup or small-town business hasn't got a chance.

Encrypt all person-specific data with the a key unique to that person, and if the person requests deletion, delete the key. This effectively deletes all backups.

Can it safely autorotate to the ground in the case of a motor failure?

I have adblock on my primary chrome profile, but occasionally browse using a profile where it is disabled because [reasons]. My experience has been generally pleasant if you discount the low-quality ads that would be blocked under this new scheme.

Instead, I get ads for interesting new components on DigiKey or Mouser, or the similar, and I find myself clicking on ads several times a week because I'm genuinely interested in what I see -- it's like a news feed for unusual devices.

Imagine if your Twitter feed was served several tweets at a time embedded in other sites you regularly visit. You could argue it's a distraction, but but it's far from unpleasant. "Personalized ads" work a lot the same way for me.

The GKE reference is a lot more relevant than you think, it's just a bit deeper below the surface.

Google's relationship with k8s and GKE and in particular their motivation for creating an open-source orchestration service is well documented and frequently retold, but ironically appears to not be well-understood.

With any sufficiently complex compute solution, you're going to need both a platform and some sort of management. Typically vendors sell you their management service (for which you often pay a recurring fee) by locking you into a proprietary platform. What's more, the management service can be dismal but you'll pay anyway because your app is built on their platform. It happens everywhere, the industry is full of examples, and anyone could see that it was going to hit Cloud sooner rather than later. And the result would be ... bad ... for everyone (customers and providers alike) but the dominant platform.

So Google took an exceptionally gutsy gamble. Google excels at platform management. They invented SRE. They posited that in a level playing field, all else being equal, Google would have the best platform management service, and people would pay for it based on its merits alone.

By making k8s open source, they leveled the playing field. It was by far the best tool for the job, and everybody could have it at no cost; neither money nor burden. So there was no business model or justification for building a lock-in sub-par alternative. The platform became a commodity; nobody could own it.

Which is where we are now, and what this article depicts. You still need a management strategy, k8s doesn't change that. But now everyone's management service has to compete on its own merits. Nobody gets to play the lock-in game.

Google's management service is GKE. It's good, but not because Google started Kubernetes. Rather, Google started Kubernetes because Google has the expertise and experience to make GKE good.

Seriously? What are you talking about? Have you ever used online advertising before? The fact that you can show it, the fact that you can point directly from any specific ad campaign to the exact set of results it generated, is literally the whole point of what makes online advertising so valuable.

Presumably you mean they're to low? Don't forget that land and construction prices have continued to increase by a fair amount in the past two years, so expect to pay somewhere between 10% and 20% more, depending on the area. Also note that your local muni government may flat out refuse to let you build the house you want to build, depending on which city you're in and how big the house is you're trying to build.

The answer to both the byod and permissions questions is the "tiered" device trust part from the article. You, the policy-maker decide how certain you are that a device hasn't been pwned given its provenance and user access story, and you assign a "trust tier" accordingly, which determines what resources it can access.

I don't think beyondcorp necessarily changes your incident response story, assuming you already have one.

A lot of this discussion glosses over the fact that U2F really makes this a viable system. U2F solves the MITM problem and ensures that the anyone who logs in does so with a company-issued hardware authenticator in physical communication (usually USB, but maybe also NFC or Bluetooth) with the client device. This means that even in a byod story, there's a piece of corp-issued hardware always attached. This in turn means that impersonation requires physical device theft in addition to credential theft.

Most companies need to be able to answer the question, "is this client one of ours," when protecting sensitive resources.

Most companies will instead answer the question, "is the client on our network," and pretend that it was the same question. The fact that it clearly is not has some very obvious security implications and attack vectors that we've been living with for decades.

Beyondcorp tries to more directly answer the original question about device identity rather than subbing in the network question in its place.

The fact that this approach is novel says a lot about the maturity of our industry.

So... like this? https://www.theverge.com/2017/8/9/16117850/deepmind-blizzard...