My wife works for a major bank, and understandably they are rather anal retentive about security, to the point where trying to get access to a database is a three day affair involving reams of paperwork and authorizations. In a way also understandable, but as a developer who needs to connect to multiple databases (staging, QA etc.) it is a real pain in the ass. Googles approach sounds like a nightmare in comparison. I will let her know tonight that it can be way worse, it might stop her whining about it as much.
At Google it would have taken her 15 minutes to get access, all done electronically (unless regulations required ink on paper signatures). Her manager would have submitted a request to have her added to the group that has access, and forwarded that request to the appropriate authorizing people (actually, the forwarding is generally automated, but it can be done either way). Those people would have checked what they needed to check and approved. Once added to the group, the same login she uses to get to her email, etc., would get her into the database.
And it very well may have been even easier than that. Because all access to sensitive databases (e.g. anything containing user data) is logged and the logs audited by automated systems and humans, it's often not necessary to do extensive pre-authorization. It's possible that at Google her manager could simply have given her access without any other approvals. Or if all of her manager's employees need that access, then the system might have been configured to automatically grant access to all of his/her direct reports. It depends on the nature of the data, of course. Some data requires both auditing and pre-authorization, especially when required by regulation.
> The perimeter defense model is based on the notion that it's possible to build a network that is physically secure and which contains only trusted, managed systems.
If I may disagree? It's based on the notion that it's possible to reduce your vulnerability, profoundly, by reducing your exposed surface and enabling some tracking of who is accessing the internal network with what privileges.
You may disagree, but you're wrong:-)
Perimeter defense as a defense in depth strategy is fine. In theory. In practice, it breeds an assumption that the network is "safe" in some important sense. That's the "ambient authority" to which I referred. If you can avoid that assumption and properly secure everything within the network in addition to implementing strong perimeter defense, great. If you tell me you have done this, I will laugh at you. I was a corporate security consultant for 15 years, working for Fortune 100 companies, the world's biggest banks, even militaries... and no one does this right, even when they think they do.
The Google strategy actually does provide defense in depth for the servers. In fact, it provides *more*, because they're only reachable through the proxies. I guess in that way, Google actually does have a defensive perimeter: The data center, where both proxies and servers live, and the network is structured so that the only the proxies are reachable from outside. This, arguably actually is a secure network. It's physically isolated inside buildings with highly-restricted access.
But your office buildings, where employees of all sorts are in and out every day, which allows even non-employees in? No network in that environment can really be considered secure. Even less if you're a large company with tens of thousands of employees. No network accessible by that many people is secure.
And note that you don't actually need Google-scale data centers to do this. You can put proxies and servers in a room with an isolated network, and restrict physical access to the room.
> [Google's approach ] It's a better approach than VPNs. More secure, more convenient, more flexible.
It is _expensive_, in manpower to maintain the sophisticated systems in and in detailed management of the various resources.
No, it's not. It's actually simpler and easier to manage. Google's corporate NETOPS team has shrunk, even as the company has tripled in size, because of just how simple it is.
I didn't go into the authorization system much in my previous post, though, so I can see how you'd think that. It's actually very simple, and based on bog-standard LDAP: Every user has an identity. Every identity can be a member of some number of groups (which are also identities). Servers almost always have a single LDAP group as the authorized user. So, giving an employee access to a given service is as simple as adding them to the correct LDAP group.
Services accessible by all full-time employees? They're configured to allow access by full-time-employee. Services accessible by everyone but contractors? The employee group. Services accessible by anyone? Those actually can use an "ambient authority" model; if the request can get through the proxy it is authorized... but note that no one without an LDAP entry has access. Universal user authentication is enforced.
For most environments, it's added overhead that returns nothing concrete for ordinay use, and for which VPN is a much simpler and much lower cost system to implement.
Also wrong, particularly if you also end up implementing a single sign-on system in addition to the VPN.
VPNs are part of a badly broken security model: the perimeter defense model. It doesn't work very well at small scales, definitely does not scale for large enterprises and generally creates a lot of misunderstandings that result in bad security decisions.
Google had a segmented perimeter defense model for several years, but has spent the last five years or so getting rid of it. The VPNs aren't entirely gone, but nearly so. You now have to get special permission to run a service that requires VPNs to access.
The perimeter defense model is based on the notion that it's possible to build a network that is physically secure and which contains only trusted, managed systems. The assumption is that any machine connected to the network is inherently trusted to some degree, and has access to some potentially-sensitive resources merely by virtue of being connected.
The problem is that it's cost-prohibitive to build a physically-secure network, and a management nightmare to try to ensure that only trusted systems can be connected to it. 802.11X authentication, which requires every device that connects to perform a cryptographic authentication, can help keep unauthorized devices off the network but it doesn't prevent sniffing or impersonation, and can't prevent compromised devices from exploiting the trust they're given.
That last point is a really telling one, because if you assume that there's some ambient authority available to any device on the network, you inevitably end up granting that ambient authority permission to access resources that only a subset of the connected devices should actually have. Also, for all of the systems that require more authorization than the ambient authority, you still have to have some sort of login system, either per application, or else build out some sort of single sign-on infrastructure.
The solution is a zero-trust network, where no device is assumed to have any authority merely by virtue of being connected, and all connections are end-to-end authenticated and encrypted. Then, a compromised device still can only access the resources that it is supposed to be able to access, because it doesn't have authorization for anything else. It also means there's no need to try to keep unauthorized devices off the network, and no worry about attackers having physical access to the network (other than DoS concerns). This approach does increase the importance of keeping all "legitimate" devices on the network secured and patched, but that really has to be done anyway.
Google's calls its version of this approach BeyondCorp. It's build around a set of proxies which take responsibility for user authentication and identification. User devices connect to the proxy (in the case of web apps it's a literal HTTPS proxy) and strongly authenticate themselves with username, password and two-factor auth token. The proxy then has an already strongly-secure connection to the backend system the user is trying to reach, and it forward's the user's request to the backend with the user's identity (in an HTTP header, for web requests). The backend (or a service it delegates to) can then decide whether the user is authorized to connect and use the service, and if so which parts of the service the user can use, what data the user can see, etc.
The approach divides authentication from authorization, doing the first in the proxy and the latter in the backend that knows what different users are allowed to do. The backend doesn't have to know anything about user authentication, meaning as authentication needs and approaches change, they can all be implemented in the client and proxy, without touching the backends. Meanwhile the proxy doesn't know anything about authorization; it's a backend-agnostic, general-purpose single sign-on service. And, of course, all connections are encrypted and authenticated, all the time.
What all of this means to Google employees is that there is exactly zero difference bet
That would be a valid argument if "cold snaps" were becoming statistically more likely or more severe.
Not really. Global warming will rearrange climate patterns, so we should expect that some regions will begin to have more severe winters, with longer and more severe cold snaps, etc. even as the global average increases.
We'll all remember your insistence that weather is climate the first extreme cold snap that occurs this winter, which by your logic utterly disproves global warming...
Individual, localized events are weather. Widespread patterns of events are climate. It's really not hard. And we have a pattern of increases in severe storms. This storm by itself is not evidence, but the larger pattern it fits into is.
Also, note that you should expect global warming to produce extreme cold weather in some locations, where "extreme" is compared to local historical records. Global warming is going to significantly alter weather patterns, and that will result in some areas getting colder, others getting hotter, some getting wetter, others getting drier, etc. Heck, some areas will probably get both hotter and colder.
And capitalism does NOT guarantee reasonable equality. For the past the 40 years or so, the rich have got much richer while the rest mostly stagnated.
"Guarantee" is a very strong word, and I'm not sure I'd want to try to defend it. But I think it's clear that capitalism does tend to flatten out inequality over time. During periods of rapid technological change the social upheaval created provides great opportunities to create massive new wealth, and it ends up concentrated at first among the people best positioned to grab it. But as the new technologies settle in and it becomes about optimizing production rather than doing incredible new things, commoditization starts driving out the massive profits and the new wealth begins to spread out.
That's the pattern we saw after the industrial revolution, at least, and it seems to me that it's likely the information age would eventually go the same way... except that this disruption looks to be one that will move us to a post-scarcity world, and capitalism probably isn't suited to that. Free markets are good at optimizing allocation of scarce resources, including labor, but what happens when labor is no longer scarce?
I understand the difference between criminal prosecution and torts. I don't think the corporate structure is an effective shield against either, otherwise we'd see a lot more corporations setting up subsidiaries to shield them from risky actions. e.g. (again) the VW case, which actually includes both criminal and civil liability.
Serious question. If what you're getting is their AdWords, why should they care what or how you're set up wrt landing pages, etc? It doesn't impact their ad business.
It does, actually.
Google gets paid when people click on the ads. That means that Google wants to maximize the chance that people will click. If people have a bad experience when they click, they'll be less likely to click in the future.
Google actually goes well beyond the landing page requirements, and offers a lot of guidance to advertisers on how to make their sites more effective. You can advertise with AdWords if you don't follow the guidance, but your results will be less effective, which means you'll make fewer sales, which means you'll make lower bids, which means Google will make less money. So, Google invests a lot in helping advertisers to improve their sites.
All of this, the requirements and the guidelines, is well-documented and has nothing to do with whether the advertised product competes with Google.
People keep saying that Apple only has 10~20% of the market, however those are world-wide numbers. I'm pretty sure the numbers are different for the U.S.A., Canada, Japan, France, Germany, etc. China alone probably skews the number toward Android.
In the US, Android has 64.8% of the market, iOS 34%.
In Japan, Android has 58.9% of the market, iOS 48.4%.
In France, Android has 80.5% of the market, iOS 18.1%
In Germany, Android has 81.9% of the market, iOS 15.6%.
In China, Android has 80.5% of the market, iOS 19.2%
So, no, China doesn't skew the numbers that much. Europe's numbers are quite close to China's. The market share of iOS in the US is higher, but still only 34%. In Japan iOS is very popular, but still lags Android.
I read it. It was a pretty good argument by a human how humans are special, but it wouldn't convince an octopus.
The argument wasn't about humans at all. It's about how people (meaning entities capable of generating and applying explanatory theories about the universe, regardless of whether those entities are humans) are special, not because they're special to themselves but because they are uniquely capable of changing the universe.
What an octopus might be able to understand is that people are ultimately capable of creating an octopus, or any other life form that the laws of physics allow to exist.
Wouldn't a better solution be Google requiring the bootloader code to all be free and open source, and all phones to be rootable?
I won't go into detail because I'm not sure how much I can actually say, but I'll just point out that Google has to walk a very fine line. Every player in the ecosystem understands Google's role in ensuring compatibility across the ecosystem, so they're willing to accept Google's imposition of the compliance test suite (CTS). Which isn't to say they don't grumble about it and roll their eyes when they think Google is quibbling over minor details that they think don't matter, but they accept.
And I think they'll be willing to go along with the new form of compatibility demanded by Treble and the vendor test suite (VTS). CTS ensures that apps run on all Android devices. VTS aims to ensure that future versions of Android run on all Android devices (up to a point).
But there are real limits. Android is open source, and any of the big players, or a consortium of smaller ones, could fork Android and run with it. If Google steps too far out of the compatibility-enforcement role and starts trying to dictate how OEMs can do business with their customers (the carriers, mostly), the OEMs absolutely will fork Android. You think there are fragmentation problems now? And how much do you think those leading the new fork(s) will care about unlockable bootloaders?
So Google has to step lightly with mandating anything outside of compatibility. And by "step lightly" I pretty much mean "not do it". What we can do is to try to engineer things so it's easier for OEMs to do the right thing, but if they don't want to, or carriers don't want them to, we can't make them.
BTW, one note on your use of the word "rootable". That's the wrong word. Rooting is neither necessary nor sufficient to actually take control of your device. Thoroughgoing application of SELinux is actually making rooting irrelevant. Since root can't violate the SELinux restrictions, it can't really do much anymore anyway. I think we're not too far from making root just another user.
No, what you want is to be able to unlock the bootloader so you can flash custom images to it. Your custom images, of course, can eschew SELinux and make root all-powerful again, if that's what you want (though it's a bad idea, and I strongly recommend against it). But the key is that with the bootloader unlocked you can do whatever you like with the device.
I realized that it could be just a way to allow OEM's to update their firmwares more easily without much effort on their part
In fact, the goal is to give OEMs the option to turn updating over to Google, making it literally zero effort (and cost!) for them. That's a pretty big step, though, so I don't think it will happen quickly, and when it does happen it will probably be second- and third-tier OEMs that do it. I hope I'm wrong on that last part.
It is quite obvious that almost all OEM's and hardware manufacturers have it on their business plan to not update older capable devices in order to force the users to change them frequently.
It may be "obvious", but it's simply not true, not that I've ever seen, and I've talked to a lot of people at a lot of OEMs.
That actual reason they're reluctant to do updates is not forced obsolescence, it's because updating is hard, which means expensive, and the vast majority of their customers do not care. Planning to do updates means including money in the business plan to pay for doing updates, and since the OEMs only do one transaction with you, that means they have to add that cost to the purchase price. The Android phone business is intensely competitive and margins for almost all of the OEMs are razor thin, so that simply won't happen unless and until customers demand it.
lockdowns from hardware manufactures needs to be stopped. Google had a big chance with the Nexus line to change this behavior and blew it.
Google did change this with the Nexus/Pixel line. All devices you buy from Google have unlockable bootloaders. This isn't something that Google can, or really even should try to, dictate to OEMs.
Look, I understand where you and ShakaUVM are coming from. I believe users should be able to fully own their devices, and so does nearly everyone else at Google. But it's not Google's job to dictate how devicemakers interact with their customers. Google's job is to make sure that Android devices are all compatible, that an app written to the standard Android APIs runs on all of them. Google has expanded that role a little with Treble, but it's still fundamentally one of compatibility, making sure that devices are compatible with future versions of Android.
Google is leading by example, and hoping that enough Android users care about unlockable bootloaders enough to vote with their wallets. So far, that hasn't worked. If you care about this, commit to refusing to buy any device without a specific commitment to vendor-provided updates, and without an unlockable bootloader, and convince everyone you know to do the same. If enough people do, OEMs will go along.
BTW, that link doesn't support your claim. The curve it describes is net demand on non-PV generation capacity. The reason for the evening peak is not because total demand has peaked, but just that PV generation has ceased. As the article puts it:
Because variable generation resources like solar power significantly reduce the load on conventional generators during the day but not during the night, a surge in generation demand may occur as the sun sets.
This section should also be noted:
Note that CAISO does not specify how they produced the hourly net loads shown in the "duck curve" image, nor under what conditions the hourly net loads were modeled. (Some accuse CAISO of using a worst-case scenario for the spring day in which clear, sunny skies boost solar production while cold temperatures increase nighttime heating demand to exaggerate the curve's steepness.
The reason they used character typing was that they didn't have the CPU power do do anything fancier.
Actually, the difference is more about software improvement than hardware. Good swipe keyboards make heavy use of machine learning both to create their general models and to refine them for individual users. The ML heavy lifting is generally not done on-device and the CPU required to execute the trained deep neural network is trivial, so you don't actually need much CPU on device at all. Or storage, since the trained NN is quite small.
Tesla's powerpacks (to pick one) are rated for 5000 cycles to 80% capacity. Not that you have to get rid of them at 80% capacity.
But you don't want to haul them around in your car when their capacity has declined significantly, because in an automobile capacity/weight is important. Where it isn't so important is on the floor in your garage. The growth of electric vehicles should provide a growing supply of cheap second-hand batteries for both home and grid-scale power storage.
Solar power peaks at noon, power usage peaks at sundown.
Cite?
That seems unlikely. Lots of lights get turned on at sundown, but lights are a pretty small power draw -- and getting smaller with the shift to LEDs. The heaviest usage of residential power in sunny areas is air conditioning, and while I could see a couple of hours' lag between peak insolation and peak temperatures (and hence peak AC usage), it seems unlikely to be nearly as large as you say.
Further, it should be pretty easy to mitigate with smart thermostats that take the availability of maximum PV energy to run the AC a little earlier than it would otherwise be needed, cooling the house to a temperature below the selected ideal, in anticipation of the coming greater exterior temperatures and lower insolation. Utilities could provide incentives to do this easily enough.
"Ethanol ablation is used to treat one type of liver cancer" -- oh the irony.
I suppose it's ironic in cases where the liver cancer was caused by alcohol, but that's not normally the case. Liver cancer is usually secondary, having metastatized from cancer elsewhere in the body. And the reason ethanol ablation is used on that particular type of cancer is precisely because the liver -- unlike most tissues in the body -- can tolerate ethanol leakage, since breaking down ethanol is one of its functions.
This seems to me like a major hindrance for developers of custom firmwares.
(Google Android engineer here, though please note that I don't work on either the kernel, or Treble, so take my comments with a grain of salt. I do own a couple of important Android hardware abstraction layer interfaces, and the client code that uses them, so I'm a knowledgeable user of Treble.)
This kernel version requirement should have no impact on developers of custom firmware, positive or negative. Project Treble, however, should make the lives of custom firmware developers much better.
Treble forces a hard boundary between/system and/vendor + kernel[1], with a consistent, tested interface between the former and the latter two components. This means that even after an OEM stops updating the kernel and hardware blobs, you will still be able to flash new system images, either official ones or custom, because those system images will have a fixed, reliable interface to the hardware using the kernel and firmware already on the device.
This doesn't mean that we want OEMs to ignore updates to kernel and hardware blobs. Security patches to those components are crucial -- especially the kernel, since that's where all of the most severe Android vulnerabilities are found. But the idea is to break the functional interdependency between specific kernel and firmware versions and the system that sits atop them, so the system can be updated at will even if the bottom layer is never updated.
This means that if you buy a phone that launches with Oreo, and can unlock the bootloader, you should be able to flash pure AOSP Oreo onto it instead of the OEM's system. Further, you should be able to customize AOSP in whatever way you like... and you should still be able to continue doing this when P, or Q, or S, etc., lands in AOSP.
Clearly there will have to be some point at which AOSP simply drops support for old hardware abstraction layer versions, and at that point the/vendor on your device will be providing APIs that AOSP refuses to use, so it'll stop working without heavier customization.
So what is the kernel version requirement about if it's all hidden behind a strong hardware abstraction boundary anyway? Security. As I said above, the most serious vulnerabilities we see in Android today are pretty much all in the kernel. If OEMs use ancient kernel versions, that means that all kernel security bugs have to be backported to those old versions. Such backporting is tedious and error-prone, and many OEMs -- especially smaller ones -- simply don't have the expertise to do it, so they don't. Google does a lot of kernel security patch backporting, but there are limits to how far back Google's engineers can reasonably support. By forcing OEMs to get onto more-current kernel versions, Google is better able to ensure that patches are at least made available to OEMs.
Note that this still will not force OEMs or carriers to actually deliver the patches. There are other initiatives under way that focus on trying to do that, but the first step is for Google to make it easy for them to apply the patches. That's what the kernel version requirements are about, setting up a situation where Google can provide the patches so OEMs can deliver them.
[1] I assume that "Treble" is a reference to the treble/bass line distinction in music, including the punning of "bass" with "base". So the/vendor partition, with all of the firmware blobs and implementations of the hardware abstraction layer APIs, plus the kernel, is the "base/bass", on which the code from the/system partition (treble) depends. Project Treble is about defining a bass line with consistent characteristics, to allow the melodic treble line to be swapped out at will, to replace an OEM melody with an AOSP melody or even a custom melody. Yeah, the musical analogy is a bit of a stretch, but it's still useful. And it's not even that much of a stretch, since some genres of music do have common bass lines which underlie a wide variety of melodies and even melodic structures.
I know lots of feminists who are coders. Most of them are men, though.
The population we're talking about isn't "feminists who are coders" but "feminists who advocate coding but refuse to do it themselves". Those kinds of hypocrites are common.
No, that's the population you're talking about... but not what you actually said. If that's what you meant, you should have said it. Of course, if you had said it, your comment would have been:
Same reason feminists who advocate coding but refuse to do it themselves love to talk about how more other women should be coders but don't want to be coders themselves.
You mean the keypunch girls? I respect what they did, but it's a bit of a stretch to call them programmers. They transcribed instructions from the actual programmers to punch cards. They were transcribers, not programmers.
No, I mean programmers. Most programmers were women, in many parts of the industry.
I work for Google, and your comments are consistent with what I see. Plus I can add a couple of points you didn't consider.
The company is young, and mostly hires new grads. They hire some older guys (I was hired at 42, now 48, and have worked with Google engineers as old as 70), and they're perfectly happy to do it, but still they find it easier to hire new grads. That skews the median young.
The first point you didn't consider is that Google has an academia-like "up or out" system, with a sort of tenure level. New grads are hired at level 2 or 3 and expected to get promoted to level 5. Once you reach level 5, that's "tenure", where as long as you continue doing your job you can stay forever. There aren't any hard timelines for getting to 5, but if you stall at some level below that you'll eventually be asked to leave.
L5s are basically team leads. To become an L5 you have to demonstrate that you can find a significant business problem, design the solution and build and lead a small team in building and deploying it your solution. So the only people who are allowed to stay are those with the technical and social skills to excel in a pool of pretty high-performing people. Google L5s would be rockstars at most companies... and most of them live in the tech startup capital of the world.
That leads obviously to the second point: Google has moderately high turnover among its more senior engineers, because they leave to join -- or found -- startups. They go off and take a pay cut for a few years in exchange for a pretty solid possibility of becoming independently wealthy. If they've been at all careful with their money, they can afford to take such risks, and with Google on their resume they can pretty easily find another job if it doesn't work out. Or go back to Google... that's easy to do, and common.
So... young company, young hires, many of the early hires were able to cash out and retire young, many others were forced out because they didn't show the requisite growth, and a fair rate of more senior (and hence older) people leaving for startups. There's really no need to wonder why the median is young. It's rising, though, because some percentage of people (like me) don't want to do the startup thing.
Slashdot Mirror
in the current ecosystem, it is basically impossible unless you have an unlocked device. Please correct me if I'm wrong.
You are correct. My recommendation is to make bootloader unlockability a must-have feature when buying your next device. Sorry I can't offer more.
My wife works for a major bank, and understandably they are rather anal retentive about security, to the point where trying to get access to a database is a three day affair involving reams of paperwork and authorizations. In a way also understandable, but as a developer who needs to connect to multiple databases (staging, QA etc.) it is a real pain in the ass. Googles approach sounds like a nightmare in comparison. I will let her know tonight that it can be way worse, it might stop her whining about it as much.
At Google it would have taken her 15 minutes to get access, all done electronically (unless regulations required ink on paper signatures). Her manager would have submitted a request to have her added to the group that has access, and forwarded that request to the appropriate authorizing people (actually, the forwarding is generally automated, but it can be done either way). Those people would have checked what they needed to check and approved. Once added to the group, the same login she uses to get to her email, etc., would get her into the database.
And it very well may have been even easier than that. Because all access to sensitive databases (e.g. anything containing user data) is logged and the logs audited by automated systems and humans, it's often not necessary to do extensive pre-authorization. It's possible that at Google her manager could simply have given her access without any other approvals. Or if all of her manager's employees need that access, then the system might have been configured to automatically grant access to all of his/her direct reports. It depends on the nature of the data, of course. Some data requires both auditing and pre-authorization, especially when required by regulation.
> The perimeter defense model is based on the notion that it's possible to build a network that is physically secure and which contains only trusted, managed systems.
If I may disagree? It's based on the notion that it's possible to reduce your vulnerability, profoundly, by reducing your exposed surface and enabling some tracking of who is accessing the internal network with what privileges.
You may disagree, but you're wrong :-)
Perimeter defense as a defense in depth strategy is fine. In theory. In practice, it breeds an assumption that the network is "safe" in some important sense. That's the "ambient authority" to which I referred. If you can avoid that assumption and properly secure everything within the network in addition to implementing strong perimeter defense, great. If you tell me you have done this, I will laugh at you. I was a corporate security consultant for 15 years, working for Fortune 100 companies, the world's biggest banks, even militaries... and no one does this right, even when they think they do.
The Google strategy actually does provide defense in depth for the servers. In fact, it provides *more*, because they're only reachable through the proxies. I guess in that way, Google actually does have a defensive perimeter: The data center, where both proxies and servers live, and the network is structured so that the only the proxies are reachable from outside. This, arguably actually is a secure network. It's physically isolated inside buildings with highly-restricted access.
But your office buildings, where employees of all sorts are in and out every day, which allows even non-employees in? No network in that environment can really be considered secure. Even less if you're a large company with tens of thousands of employees. No network accessible by that many people is secure.
And note that you don't actually need Google-scale data centers to do this. You can put proxies and servers in a room with an isolated network, and restrict physical access to the room.
> [Google's approach ] It's a better approach than VPNs. More secure, more convenient, more flexible.
It is _expensive_, in manpower to maintain the sophisticated systems in and in detailed management of the various resources.
No, it's not. It's actually simpler and easier to manage. Google's corporate NETOPS team has shrunk, even as the company has tripled in size, because of just how simple it is.
I didn't go into the authorization system much in my previous post, though, so I can see how you'd think that. It's actually very simple, and based on bog-standard LDAP: Every user has an identity. Every identity can be a member of some number of groups (which are also identities). Servers almost always have a single LDAP group as the authorized user. So, giving an employee access to a given service is as simple as adding them to the correct LDAP group.
Services accessible by all full-time employees? They're configured to allow access by full-time-employee. Services accessible by everyone but contractors? The employee group. Services accessible by anyone? Those actually can use an "ambient authority" model; if the request can get through the proxy it is authorized... but note that no one without an LDAP entry has access. Universal user authentication is enforced.
For most environments, it's added overhead that returns nothing concrete for ordinay use, and for which VPN is a much simpler and much lower cost system to implement.
Also wrong, particularly if you also end up implementing a single sign-on system in addition to the VPN.
VPNs are part of a badly broken security model: the perimeter defense model. It doesn't work very well at small scales, definitely does not scale for large enterprises and generally creates a lot of misunderstandings that result in bad security decisions.
Google had a segmented perimeter defense model for several years, but has spent the last five years or so getting rid of it. The VPNs aren't entirely gone, but nearly so. You now have to get special permission to run a service that requires VPNs to access.
The perimeter defense model is based on the notion that it's possible to build a network that is physically secure and which contains only trusted, managed systems. The assumption is that any machine connected to the network is inherently trusted to some degree, and has access to some potentially-sensitive resources merely by virtue of being connected.
The problem is that it's cost-prohibitive to build a physically-secure network, and a management nightmare to try to ensure that only trusted systems can be connected to it. 802.11X authentication, which requires every device that connects to perform a cryptographic authentication, can help keep unauthorized devices off the network but it doesn't prevent sniffing or impersonation, and can't prevent compromised devices from exploiting the trust they're given.
That last point is a really telling one, because if you assume that there's some ambient authority available to any device on the network, you inevitably end up granting that ambient authority permission to access resources that only a subset of the connected devices should actually have. Also, for all of the systems that require more authorization than the ambient authority, you still have to have some sort of login system, either per application, or else build out some sort of single sign-on infrastructure.
The solution is a zero-trust network, where no device is assumed to have any authority merely by virtue of being connected, and all connections are end-to-end authenticated and encrypted. Then, a compromised device still can only access the resources that it is supposed to be able to access, because it doesn't have authorization for anything else. It also means there's no need to try to keep unauthorized devices off the network, and no worry about attackers having physical access to the network (other than DoS concerns). This approach does increase the importance of keeping all "legitimate" devices on the network secured and patched, but that really has to be done anyway.
Google's calls its version of this approach BeyondCorp. It's build around a set of proxies which take responsibility for user authentication and identification. User devices connect to the proxy (in the case of web apps it's a literal HTTPS proxy) and strongly authenticate themselves with username, password and two-factor auth token. The proxy then has an already strongly-secure connection to the backend system the user is trying to reach, and it forward's the user's request to the backend with the user's identity (in an HTTP header, for web requests). The backend (or a service it delegates to) can then decide whether the user is authorized to connect and use the service, and if so which parts of the service the user can use, what data the user can see, etc.
The approach divides authentication from authorization, doing the first in the proxy and the latter in the backend that knows what different users are allowed to do. The backend doesn't have to know anything about user authentication, meaning as authentication needs and approaches change, they can all be implemented in the client and proxy, without touching the backends. Meanwhile the proxy doesn't know anything about authorization; it's a backend-agnostic, general-purpose single sign-on service. And, of course, all connections are encrypted and authenticated, all the time.
What all of this means to Google employees is that there is exactly zero difference bet
That would be a valid argument if "cold snaps" were becoming statistically more likely or more severe.
Not really. Global warming will rearrange climate patterns, so we should expect that some regions will begin to have more severe winters, with longer and more severe cold snaps, etc. even as the global average increases.
We'll all remember your insistence that weather is climate the first extreme cold snap that occurs this winter, which by your logic utterly disproves global warming...
Individual, localized events are weather. Widespread patterns of events are climate. It's really not hard. And we have a pattern of increases in severe storms. This storm by itself is not evidence, but the larger pattern it fits into is.
Also, note that you should expect global warming to produce extreme cold weather in some locations, where "extreme" is compared to local historical records. Global warming is going to significantly alter weather patterns, and that will result in some areas getting colder, others getting hotter, some getting wetter, others getting drier, etc. Heck, some areas will probably get both hotter and colder.
And capitalism does NOT guarantee reasonable equality. For the past the 40 years or so, the rich have got much richer while the rest mostly stagnated.
"Guarantee" is a very strong word, and I'm not sure I'd want to try to defend it. But I think it's clear that capitalism does tend to flatten out inequality over time. During periods of rapid technological change the social upheaval created provides great opportunities to create massive new wealth, and it ends up concentrated at first among the people best positioned to grab it. But as the new technologies settle in and it becomes about optimizing production rather than doing incredible new things, commoditization starts driving out the massive profits and the new wealth begins to spread out.
That's the pattern we saw after the industrial revolution, at least, and it seems to me that it's likely the information age would eventually go the same way... except that this disruption looks to be one that will move us to a post-scarcity world, and capitalism probably isn't suited to that. Free markets are good at optimizing allocation of scarce resources, including labor, but what happens when labor is no longer scarce?
I understand the difference between criminal prosecution and torts. I don't think the corporate structure is an effective shield against either, otherwise we'd see a lot more corporations setting up subsidiaries to shield them from risky actions. e.g. (again) the VW case, which actually includes both criminal and civil liability.
Serious question. If what you're getting is their AdWords, why should they care what or how you're set up wrt landing pages, etc? It doesn't impact their ad business.
It does, actually.
Google gets paid when people click on the ads. That means that Google wants to maximize the chance that people will click. If people have a bad experience when they click, they'll be less likely to click in the future.
Google actually goes well beyond the landing page requirements, and offers a lot of guidance to advertisers on how to make their sites more effective. You can advertise with AdWords if you don't follow the guidance, but your results will be less effective, which means you'll make fewer sales, which means you'll make lower bids, which means Google will make less money. So, Google invests a lot in helping advertisers to improve their sites.
All of this, the requirements and the guidelines, is well-documented and has nothing to do with whether the advertised product competes with Google.
People keep saying that Apple only has 10~20% of the market, however those are world-wide numbers. I'm pretty sure the numbers are different for the U.S.A., Canada, Japan, France, Germany, etc. China alone probably skews the number toward Android.
Here are numbers as of May:
In the US, Android has 64.8% of the market, iOS 34%.
In Japan, Android has 58.9% of the market, iOS 48.4%.
In France, Android has 80.5% of the market, iOS 18.1%
In Germany, Android has 81.9% of the market, iOS 15.6%.
In China, Android has 80.5% of the market, iOS 19.2%
So, no, China doesn't skew the numbers that much. Europe's numbers are quite close to China's. The market share of iOS in the US is higher, but still only 34%. In Japan iOS is very popular, but still lags Android.
I read it. It was a pretty good argument by a human how humans are special, but it wouldn't convince an octopus.
The argument wasn't about humans at all. It's about how people (meaning entities capable of generating and applying explanatory theories about the universe, regardless of whether those entities are humans) are special, not because they're special to themselves but because they are uniquely capable of changing the universe.
What an octopus might be able to understand is that people are ultimately capable of creating an octopus, or any other life form that the laws of physics allow to exist.
Wouldn't a better solution be Google requiring the bootloader code to all be free and open source, and all phones to be rootable?
I won't go into detail because I'm not sure how much I can actually say, but I'll just point out that Google has to walk a very fine line. Every player in the ecosystem understands Google's role in ensuring compatibility across the ecosystem, so they're willing to accept Google's imposition of the compliance test suite (CTS). Which isn't to say they don't grumble about it and roll their eyes when they think Google is quibbling over minor details that they think don't matter, but they accept.
And I think they'll be willing to go along with the new form of compatibility demanded by Treble and the vendor test suite (VTS). CTS ensures that apps run on all Android devices. VTS aims to ensure that future versions of Android run on all Android devices (up to a point).
But there are real limits. Android is open source, and any of the big players, or a consortium of smaller ones, could fork Android and run with it. If Google steps too far out of the compatibility-enforcement role and starts trying to dictate how OEMs can do business with their customers (the carriers, mostly), the OEMs absolutely will fork Android. You think there are fragmentation problems now? And how much do you think those leading the new fork(s) will care about unlockable bootloaders?
So Google has to step lightly with mandating anything outside of compatibility. And by "step lightly" I pretty much mean "not do it". What we can do is to try to engineer things so it's easier for OEMs to do the right thing, but if they don't want to, or carriers don't want them to, we can't make them.
BTW, one note on your use of the word "rootable". That's the wrong word. Rooting is neither necessary nor sufficient to actually take control of your device. Thoroughgoing application of SELinux is actually making rooting irrelevant. Since root can't violate the SELinux restrictions, it can't really do much anymore anyway. I think we're not too far from making root just another user.
No, what you want is to be able to unlock the bootloader so you can flash custom images to it. Your custom images, of course, can eschew SELinux and make root all-powerful again, if that's what you want (though it's a bad idea, and I strongly recommend against it). But the key is that with the bootloader unlocked you can do whatever you like with the device.
I realized that it could be just a way to allow OEM's to update their firmwares more easily without much effort on their part
In fact, the goal is to give OEMs the option to turn updating over to Google, making it literally zero effort (and cost!) for them. That's a pretty big step, though, so I don't think it will happen quickly, and when it does happen it will probably be second- and third-tier OEMs that do it. I hope I'm wrong on that last part.
It is quite obvious that almost all OEM's and hardware manufacturers have it on their business plan to not update older capable devices in order to force the users to change them frequently.
It may be "obvious", but it's simply not true, not that I've ever seen, and I've talked to a lot of people at a lot of OEMs.
That actual reason they're reluctant to do updates is not forced obsolescence, it's because updating is hard, which means expensive, and the vast majority of their customers do not care. Planning to do updates means including money in the business plan to pay for doing updates, and since the OEMs only do one transaction with you, that means they have to add that cost to the purchase price. The Android phone business is intensely competitive and margins for almost all of the OEMs are razor thin, so that simply won't happen unless and until customers demand it.
lockdowns from hardware manufactures needs to be stopped. Google had a big chance with the Nexus line to change this behavior and blew it.
Google did change this with the Nexus/Pixel line. All devices you buy from Google have unlockable bootloaders. This isn't something that Google can, or really even should try to, dictate to OEMs.
Look, I understand where you and ShakaUVM are coming from. I believe users should be able to fully own their devices, and so does nearly everyone else at Google. But it's not Google's job to dictate how devicemakers interact with their customers. Google's job is to make sure that Android devices are all compatible, that an app written to the standard Android APIs runs on all of them. Google has expanded that role a little with Treble, but it's still fundamentally one of compatibility, making sure that devices are compatible with future versions of Android.
Google is leading by example, and hoping that enough Android users care about unlockable bootloaders enough to vote with their wallets. So far, that hasn't worked. If you care about this, commit to refusing to buy any device without a specific commitment to vendor-provided updates, and without an unlockable bootloader, and convince everyone you know to do the same. If enough people do, OEMs will go along.
Cite?
http://large.stanford.edu/cour...
BTW, that link doesn't support your claim. The curve it describes is net demand on non-PV generation capacity. The reason for the evening peak is not because total demand has peaked, but just that PV generation has ceased. As the article puts it:
This section should also be noted:
Here's a better idea, build some nuclear power plants.
I don't disagree conceptually, but that ship has sailed. Not going to happen.
The reason they used character typing was that they didn't have the CPU power do do anything fancier.
Actually, the difference is more about software improvement than hardware. Good swipe keyboards make heavy use of machine learning both to create their general models and to refine them for individual users. The ML heavy lifting is generally not done on-device and the CPU required to execute the trained deep neural network is trivial, so you don't actually need much CPU on device at all. Or storage, since the trained NN is quite small.
Tesla's powerpacks (to pick one) are rated for 5000 cycles to 80% capacity. Not that you have to get rid of them at 80% capacity.
But you don't want to haul them around in your car when their capacity has declined significantly, because in an automobile capacity/weight is important. Where it isn't so important is on the floor in your garage. The growth of electric vehicles should provide a growing supply of cheap second-hand batteries for both home and grid-scale power storage.
Solar power peaks at noon, power usage peaks at sundown.
Cite?
That seems unlikely. Lots of lights get turned on at sundown, but lights are a pretty small power draw -- and getting smaller with the shift to LEDs. The heaviest usage of residential power in sunny areas is air conditioning, and while I could see a couple of hours' lag between peak insolation and peak temperatures (and hence peak AC usage), it seems unlikely to be nearly as large as you say.
Further, it should be pretty easy to mitigate with smart thermostats that take the availability of maximum PV energy to run the AC a little earlier than it would otherwise be needed, cooling the house to a temperature below the selected ideal, in anticipation of the coming greater exterior temperatures and lower insolation. Utilities could provide incentives to do this easily enough.
"Ethanol ablation is used to treat one type of liver cancer" -- oh the irony.
I suppose it's ironic in cases where the liver cancer was caused by alcohol, but that's not normally the case. Liver cancer is usually secondary, having metastatized from cancer elsewhere in the body. And the reason ethanol ablation is used on that particular type of cancer is precisely because the liver -- unlike most tissues in the body -- can tolerate ethanol leakage, since breaking down ethanol is one of its functions.
So, really not very ironic.
This seems to me like a major hindrance for developers of custom firmwares.
(Google Android engineer here, though please note that I don't work on either the kernel, or Treble, so take my comments with a grain of salt. I do own a couple of important Android hardware abstraction layer interfaces, and the client code that uses them, so I'm a knowledgeable user of Treble.)
This kernel version requirement should have no impact on developers of custom firmware, positive or negative. Project Treble, however, should make the lives of custom firmware developers much better.
Treble forces a hard boundary between /system and /vendor + kernel[1], with a consistent, tested interface between the former and the latter two components. This means that even after an OEM stops updating the kernel and hardware blobs, you will still be able to flash new system images, either official ones or custom, because those system images will have a fixed, reliable interface to the hardware using the kernel and firmware already on the device.
This doesn't mean that we want OEMs to ignore updates to kernel and hardware blobs. Security patches to those components are crucial -- especially the kernel, since that's where all of the most severe Android vulnerabilities are found. But the idea is to break the functional interdependency between specific kernel and firmware versions and the system that sits atop them, so the system can be updated at will even if the bottom layer is never updated.
This means that if you buy a phone that launches with Oreo, and can unlock the bootloader, you should be able to flash pure AOSP Oreo onto it instead of the OEM's system. Further, you should be able to customize AOSP in whatever way you like... and you should still be able to continue doing this when P, or Q, or S, etc., lands in AOSP.
Clearly there will have to be some point at which AOSP simply drops support for old hardware abstraction layer versions, and at that point the /vendor on your device will be providing APIs that AOSP refuses to use, so it'll stop working without heavier customization.
So what is the kernel version requirement about if it's all hidden behind a strong hardware abstraction boundary anyway? Security. As I said above, the most serious vulnerabilities we see in Android today are pretty much all in the kernel. If OEMs use ancient kernel versions, that means that all kernel security bugs have to be backported to those old versions. Such backporting is tedious and error-prone, and many OEMs -- especially smaller ones -- simply don't have the expertise to do it, so they don't. Google does a lot of kernel security patch backporting, but there are limits to how far back Google's engineers can reasonably support. By forcing OEMs to get onto more-current kernel versions, Google is better able to ensure that patches are at least made available to OEMs.
Note that this still will not force OEMs or carriers to actually deliver the patches. There are other initiatives under way that focus on trying to do that, but the first step is for Google to make it easy for them to apply the patches. That's what the kernel version requirements are about, setting up a situation where Google can provide the patches so OEMs can deliver them.
[1] I assume that "Treble" is a reference to the treble/bass line distinction in music, including the punning of "bass" with "base". So the /vendor partition, with all of the firmware blobs and implementations of the hardware abstraction layer APIs, plus the kernel, is the "base/bass", on which the code from the /system partition (treble) depends. Project Treble is about defining a bass line with consistent characteristics, to allow the melodic treble line to be swapped out at will, to replace an OEM melody with an AOSP melody or even a custom melody. Yeah, the musical analogy is a bit of a stretch, but it's still useful. And it's not even that much of a stretch, since some genres of music do have common bass lines which underlie a wide variety of melodies and even melodic structures.
If I want to have an adult discussion, I have it with adults.
Really? That response is one (small) step above "I know you are but what am I?". Very adult.
The population we're talking about isn't "feminists who are coders" but "feminists who advocate coding but refuse to do it themselves". Those kinds of hypocrites are common.
No, that's the population you're talking about... but not what you actually said. If that's what you meant, you should have said it. Of course, if you had said it, your comment would have been:
Which is tautological.
https://www.google.com/search?...
You mean the keypunch girls? I respect what they did, but it's a bit of a stretch to call them programmers. They transcribed instructions from the actual programmers to punch cards. They were transcribers, not programmers.
No, I mean programmers. Most programmers were women, in many parts of the industry.
I work for Google, and your comments are consistent with what I see. Plus I can add a couple of points you didn't consider.
The company is young, and mostly hires new grads. They hire some older guys (I was hired at 42, now 48, and have worked with Google engineers as old as 70), and they're perfectly happy to do it, but still they find it easier to hire new grads. That skews the median young.
The first point you didn't consider is that Google has an academia-like "up or out" system, with a sort of tenure level. New grads are hired at level 2 or 3 and expected to get promoted to level 5. Once you reach level 5, that's "tenure", where as long as you continue doing your job you can stay forever. There aren't any hard timelines for getting to 5, but if you stall at some level below that you'll eventually be asked to leave.
L5s are basically team leads. To become an L5 you have to demonstrate that you can find a significant business problem, design the solution and build and lead a small team in building and deploying it your solution. So the only people who are allowed to stay are those with the technical and social skills to excel in a pool of pretty high-performing people. Google L5s would be rockstars at most companies... and most of them live in the tech startup capital of the world.
That leads obviously to the second point: Google has moderately high turnover among its more senior engineers, because they leave to join -- or found -- startups. They go off and take a pay cut for a few years in exchange for a pretty solid possibility of becoming independently wealthy. If they've been at all careful with their money, they can afford to take such risks, and with Google on their resume they can pretty easily find another job if it doesn't work out. Or go back to Google... that's easy to do, and common.
So... young company, young hires, many of the early hires were able to cash out and retire young, many others were forced out because they didn't show the requisite growth, and a fair rate of more senior (and hence older) people leaving for startups. There's really no need to wonder why the median is young. It's rising, though, because some percentage of people (like me) don't want to do the startup thing.