What's even better than the distance measurement is the fact that the ranging process includes a secure key derivation protocol. The two radios that participate in the "secure bounding" process, as it's called, emerge with both a highly-accurate range estimate and a shared secret key. Eavesdroppers can't easily compute the shared key (I haven't actually looked into the details of how this works), which means that if subsequent communications are encrypted and authenticated using the shared secret plus another mutual secret, relay attacks become very hard.
Suppose we have a secure authentication protocol that we only want to operate at close range (say, unlocking your car). Without precise ranging we have two problems. The first is that the protocol may be carried out at a longer range than you want. For example, unlocking your car in your driveway when you're in the house. Precise ranging by itself solves that problem. The second is that an active attacker may perform a relay attack and carry out the protocol at an arbitrary distance, such as unlocking your car in the mall parking lot when you're walking around the mall. The relay is performed by putting one radio near your phone and other near your car and relaying messages between them.
Note that without secure bounding, cryptography can't solve the relay problem because the attacker doesn't have to be able to read the messages, just pass them back and forth. And precise ranging doesn't help because your phone will measure the distance to the attacker's first radio and your car will measure the distance to the attacker's second radio. You can try to do something like have each side encrypt its distance measurement and send it to the other side, but that just means the attacker has to be careful to get both of his radios about the same distance from yours.
But with secure bounding, each pair of actually-communicating radios will compute a distinct session key. The attacker will know both of these, but if your phone and the car both securely combine the bounding-derived session key with a secret the two share and the attacker doesn't have, the result will be a shared session secret which will only be identical if the phone and car are actually communicating directly.
According to Marx under normal circumstances capitalists will...
According to Marx, knowledge is irrelevant to production, only labor and raw materials matter. IOW, Marx's ideas are inapplicable in any economy or market where new ideas are created, which is pretty much the opposite of what the tech industry is/does. Under Marx's assumptions all workers are identical and replaceable and there are always enough workers available so that any worker that demands more than is necessary for bare survival can be replaced with one who does not.
None of Marx's assumptions are valid in the modern world, and it's debatable whether they were ever valid.
No, it's not. Pre-installed apps are stored on the system partition. Deleting it would make absolutely no difference to your usable space.
The storage used by the system partition is carved out of the same pool of storage used by the data partition. If the apps weren't pre-installed, the system partition would be smaller and the data partition would be larger.
Microsoft's app sent 1MB of data from my phone to their servers. It came pre-installed, and I never used it. At what point exactly did I agree for Microsoft to slurp down 1MB worth of my private data from my phone?
Out of curiosity, what permissions does that app have? What might it have sent?
As an employee and investor, I'm all for Google growing up a little bit and toning down some policies that aren't suitable for a large company
As an employee (which means investor) I think this shift may be necessary, but find it sad. Mostly, I regret the loss of Google's ability to practice radical transparency internally. When I joined the company eight years ago (from incredibly-siloed IBM), I was floored by the amount of information that was shared in the weekly TGIFs, and the fact that any employee could stand up and ask hard questions of the CEO, in front of all of the rest of the employees -- and almost always get real answers, not tapdancing. I really liked that I had access to nearly all of the code for every product, and that I could submit changes to any of it (my CLs would have to be approved by the project owners, of course). And there were hundred other ways in which Google was truly different from the other corporations I'd worked for in the last 20 years.
Most of that may not actually have contributed much to the bottom line, but it has certainly made for a pleasant working environment that attracted and retained lots of really talented -- and very nice! -- people. I still feel like I'm surrounded by nice, talented people. So much so that I find keeping up with them a constant challenge. But I am concerned that as Google becomes a more traditional corporation, that may be lost along with the rest.
The problem is that some panned out (a user base that liked what they were doing), and Google killed them anyway
Google has a different definition of "panned out", at least for free services. Unless a service has 100M+ users, or looks likely to get there, it's a flop and not worth the effort it takes to operate it.
Or just plain shot the kitten, as per Google Reader.
Google Reader is a good example. It had a few million devoted users, but wasn't growing and was clearly never going to build a large user base.
In cases like that, I do wish Google would experiment with charging for services and making them profitable that way. I think that might have worked with Reader. Or, if not, it would at least have been more understandable to users. I think Google would be better off with a reputation for making the first hit free then charging later than for making free stuff that abruptly disappears. People understand fee-for-service, even if they often don't want to pay. I'd also like to see more experiments with charging for ad- and tracking-free versions of free services. I think the vast majority of people would opt to continue trading data for services, but I think it would do everyone good to make the choice more explicit.
I'm obviously not speaking for my employer here. If I were in a position to do that, Google would be doing these things.
But the reaching out we know of occurred after publication to the whole world.
You're being deliberately disingenuous. Obviously the information they were seeking hadn't been published, otherwise they wouldn't have had to try to get it.
No disingenuousness, the only information they ever received was the already published info.
That's irrelevant. They were clearly seeking additional, unpublished information. Else why bother?
Yeah, lying to the feds is bad. Is there anything else shocking or illegal in these events? There doesn't seem to be.
Yes. Getting dirt on your opponent is receiving a campaign contribution, and there are laws restricting who can give you contributions. Getting them from foreigners is illegal.
So if you are buying the dirt from foreigners you are fee and clear, as opposed to receiving it for fee?
I'm not sure, but I would think that would still constitute foreign assistance.
Of course, this doesn't apply to dirt that is published to the whole world. But reaching out to Wikileaks to get Russian-sourced dirt on Hillary would be soliciting an illegal foreign contribution to Trump's campaign.
But the reaching out we know of occurred after publication to the whole world.
You're being deliberately disingenuous. Obviously the information they were seeking hadn't been published, otherwise they wouldn't have had to try to get it.
Yeah, lying to the feds is bad. Is there anything else shocking or illegal in these events? There doesn't seem to be.
Yes. Getting dirt on your opponent is receiving a campaign contribution, and there are laws restricting who can give you contributions. Getting them from foreigners is illegal.
Of course, this doesn't apply to dirt that is published to the whole world. But reaching out to Wikileaks to get Russian-sourced dirt on Hillary would be soliciting an illegal foreign contribution to Trump's campaign. Anyone involved in soliciting or receiving such contributions committed a crime. Anyone who directed someone to solicit or receive such contributions committed a different crime: conspiracy. And the conspiracy charge doesn't depend on the underlying crime actually being carried out. And anyone who tried to cover up either crime by interfering with the investigation committed yet another crime: obstruction.
The right thing for a person involved in a US political campaign to do when someone offers them foreign-sourced dirt on their opponent is to call the FBI immediately. If they're offered domestically-sourced dirt, they should probably consult with the campaign's legal staff before accepting it.
Ah yes, the 'programming challenge' final.. i.e. the 'guess what specific niche that if you have a solid base can probably look up in 10 minutes but if you don't know it off the top of your head and solve it the way I picture it, that means you don't know anything!' test.
If that's what you get, the interviewer doesn't know what they're doing. Programming tests should test your ability to solve problems and write code. They shouldn't require any knowledge beyond basic algorithms and data structures, plus, of course, a knowledge of the syntax and idioms of the language you're using.
And if the interviewer is expecting you to solve the problem in the same way they would, that's bad, too. Any correct solution should be fine. I had one candidate who created a better solution than the one I had in mind, which is pretty impressive since I'd already had several of my colleagues and a few dozen interview candidates give it a shot, plus spending a fair amount of time on it myself. Yes, he got the job, and has excelled.
Further, if the interviewer is doing the job right, it shouldn't even matter that much whether you solved it correctly! That's not the point. The point is to see how you think your way around the problem. Someone who blunders around blindly and happens to stumble onto a good approach is not going to get as high marks from me as someone who methodically and intelligently works through the possibilities and can clearly explain their rationale, even if they happen to miss something. (Though the best programming challenges don't rely on the candidate getting any flashes of insight, and can be solved fairly quickly by anyone competent.)
Does it have a power button, or do you just wait for the battery to go dead? Using the touchscreen to turn something on means the touchscreen needs to constantly be drawing power...
It has a power button, in the form of a pressure-sensing edge.
When switching between T-Mobile and AT&T, I had to buy new SIM cards, which makes me wonder if this comes locked to a specific carrier. (The sad thing is when I switched back to T-Mobile, I had to buy another SIM card!)
I'm sure it uses an eSIM. My Pixel 3 has one (and also a SIM slot). It's the same sort of chip as in a SIM, but it's inside and it's reprogrammable. You connect to Wifi, install a carrier app and the app configures the eSIM with data from the carrier. Over the next few years I expect SIM slots to gradually disappear.
You know, there was a time when no one had cell phones and we all got along fine. In many ways it was better.
Meh. I didn't get my first cellphone until I was almost 30, so I had plenty of experience with the pre-cellular life. We got along fine only because we spent a lot of extra time and effort on pre-planning. Want to meet your friends or relatives somewhere? Better get it all set up in advance, and with a high degree of precision. If one of you makes a mistake and is off by a smallish amount on the time or the location, you're not going to meet. Break down on the road? If you can't fix it on the spot you're going to have to hitch a ride to where you can get help, or hope a cop comes buy to radio for a tow truck. And if you were on your way to meet someone, they'll have no idea why you didn't show up.
Those are just two examples. Those who have grown up with the freedom provided by cell phones have no idea how much extra effort it took to get around. Some who grew up without phones have forgotten, or are just engaging in the Golden Age fallacy.
Nimbyism, regulations, and lawsuits seem to make most all power generation more expensive or impossible. Pipelines, dams, power lines, wind farms, fracking.
But none of them provoke the visceral fear of the unknown that nuclear power does, or evoke visions of mushroom clouds, even though every one of them has killed orders of magnitude more people (except maybe fracking; but I don't think we yet understand the costs of fracking). This means none of them have the depth of organized opposition, or the many options for running up costs.
Unregulated nuclear is scary. Cost cutting, companies that shutdown as soon as problems appear and such, all leaving the tax payers on the hook.
Sure, sensible regulation is sensible. But that's not what we have in the nuclear industry. We have a combination of ridiculous over-regulation that essentially stops all new construction, combined with ridiculously lax extensions on operating permits because without new construction we don't have anything else to take over the baseload when we shut an old plant down. This is the worst of all worlds. We're essentially running headlong toward a significant nuclear accident because of our regulations that are supposed to prevent nuclear accidents.
I have no opposition to sun, wind, etc. I think they're great, and I'm just fine with replacing nuclear power with them. But that's going to take time, and in the meantime we're going to keep burning coal and dumping gigatons of CO2 into the atmosphere. At this point it's probably too late to try to ramp up nuclear production. Even if we got instantly rational about it, by the time we could build the nuclear capacity we need, we can probably deploy the same capacity in renewables + utility-scale storage. We screwed ourselves 20-30 years ago when renewables weren't practical, and now we're just going to eat the cost, in the form of a warmer planet than we might have had otherwise.
Hangouts has over a billion installs on Android. It's extremely popular, by far Google's most popular messaging app and the default for handling SMS on Android.
Hangouts does not handle SMS on Android any more, unless you're using Google Voice or Google Fi. SMS on non-Google carriers must use the Messages app or a third party app. Even before they removed the ability for Hangouts to handle (non-Google) SMS, Messages was the default.
because we think people should be able to do what they want with their devices.
You should add the caveat, - "as long as Google can mine the users data". That is the only thing Google really cares about.
It's really not.
First, let me make clear that I work on Android. This is completely separate from the Google Apps. From my team's perspective, Google is just another app developer (though obviously a very influential one).
The Android system provldes no special access to Google. None whatsoever. If you want to scoff, please point me to the Google-data-mining hooks in AOSP.
Further, Google's apps are not special to Android. They cannot get any data from any other apps that don't choose to share it with them. That said, the Google suite of apps is very comprehensive, and users do tend to use a lot of them, and nearly all of their personal data does flow through them. Mail, contacts, location services, browsing, etc.
OTOH, it's also a very broad, deep and high-quality set of services, for which users pay nothing, in dollars. The deal is you trade the ability for Google to target ads to your eyeballs in exchange for all of that. If you think that's a bad deal, you're completely free to opt out. Buy an unlockable device, unlock it, remove all the Google apps, use a different search engine, don't use gmail, etc.
(Yes, I recognize I'm being a little disingenuous here. Most people couldn't actually do what I describe. But it is possible, and many Google engineers put in a lot of extra work to make sure that it continues being possible.)
In a sense, allowing vulnerabilities means that there's competition to get to the data.
No... we do not consider attackers who exploit vulnerabilities to be in any way "competition". Facebook is competition, as are other app developers who build tools that attract a lot of user data and then advertise to users.
It makes sense in other contexts too as to why Google is never going to allow users to encrypt the Inbox.
You certainly can do it if you want. GMail has full IMAP4 and POP3 interfaces, and you can use them with mail clients that support S/MIME or OpenPGP. Yes, I'm also disapointed that the Google end-to-end encryption project has died. I don't know why that happened, but I suspect that it was lack of executive support, probably for exactly the reasons you postulate: it undermines the business model that pays the bills -- including for the operational costs of GMail.
Anyway, my point is that your claim is wrong. Google does allow you to encrypt the inbox... Google just doesn't encourage it. A different sort of company would ban it.
We don't mind you guys fixing vulnerabilities, or even employing dark patterns across your products, or even trying to trick people to use your products - Hey, its a tough world out there. Its only when you cloak your actions under altruism that we find it reprehensible.
There actually is a huge amount of altruism at Google. it's not a cloak, it's reality. Of course, it's sometimes in tension with the need to generate profits, but less often than you might think. Generally, if you build something that hundreds of millions or billions of people want to use, there's some way to make it generate revenue -- which is good because running such massive services is expensive.
For me, personally, making Android secure is as much about improving the world as it is about getting a paycheck. I could get paid to do a lot of things. Few of them would be as rewarding as what I do.
Why can't I get root on any android phone just by connecting it to a pc, enabling developer mode, letting the pc with adb set or deny root, or special commands like let apps of my choosing enable or disable wifi, data, gps, etc.?
Let me tell you a story. A true one. It's not actually an answer to your question, but it points the way.
Last year, a major Android device maker came to me and asked how I planned to fix the developer mode vulnerability. "What developer mode vulneability?" I asked, reaching for my laptop to look up the CVE.
They explained that in various parts of the world, especially Asia, but not only Asia, there are lots of free charging stations at bus stations, airports, coffee shops, Internet cafes, restaurants... and just about everywhere else you can think of, including public restrooms. These charging stations have a sign hanging over them with a list of instructions that people have to follow to get free charging:
Go into the settings app (actual signs explain in detail how to do this on many common devices).
Go into "About phone"
Tap the "build number" seven times.
Go into "System", tap "Developer options"
Turn on "USB Debugging"
Plug your phone in. When the dialog pops up asking to "Allow USB debugging", tap "OK".
According to the device maker asking the question, If you go watch one of these locations you'll see that 95+% of people dutifully carry out all of the steps so they can charge their phone. They often don't notice the flood of malware the charging station sideloads onto their phone. This is because it doesn't do anything right away, usually not until after the next reboot plus a random delay.
I put my laptop away and explained that we had no plans to fix the developer mode vulnerability.
Given your UID, I'm guessing we're probably around the same age, having grown up with early x86 machines, dos, os/2, slackware, etc.
I suspect so. I'm 50.
Not to go all nostalgic, but "those were the days." We were free to explore, learn, tinker, fix, and break. We could output directly to ioports and trigger interrupts as a matter of course. I learned more about what makes a computer compute as a kid with a beat up old 8086 than I have as an adult (both in University and professionally).
Yep, but the openness of the systems isn't the only thing that has changed in the last 30-40 years. When we were tinkering, computers were rare, little-used and isolated. Now they're ubiquitous, so heavily-used they're almost a brain expansion pack and they're networked all of the time. The fact is that the vast, vast majority of computer users -- especially of mobile devices -- know absolutely nothing about how they work, and have no interest at all in learning, exploring, tinkering. They just want to read Facebook, surf porn, make phone calls, etc. They would look at the computers that you and I started on as completely and utterly useless because it took a tremendous amount of work to make them do anything.
Another thing that has changed is the nature of the threats. 35 years ago I wrote a little terminate-stay-resident DOS program that made the characters on the screen fall into piles on the bottom. I gleefully installed this on lots of friends' and family members' computers (well, "lots" was like four; machines were rare). Later I modified it to spread itself virally, by writing itself into the boot sector of any floppy it could. I never installed that one anywhere, though. But we're long, long past the days of the casual, for-fun hacker. Today security is a serious problem. The attackers are often organized criminals, of varying but often significant sophistication. Sometimes the attackers are nation states. Military cyberwarfare groups, intelligence agencies, etc. (Aside: We'll never keep the really serious attackers out of consumer devices, but we maybe can make it hard enough that they can't scale their attacks.)
The reason that the attackers have changed is because the way we use computers has changed. Absolutely everything is on a machine somewhere. Our mobile phones contain pretty much our whole lives: personal, financial, photographic, you name it. This puts even the average person at significant risk, mostly financial. We've seen hundreds of thousands, perhaps millions, of people scammed out of significant amounts of money by people who explolited vulnerabilities in their devices. And that's nothing compared to the risks to high-profile people, who have much more to steal.
The total number of Android users has passed three billion, and it won't be long before it hits four. Shipping vulnerable software to damned near 50% of humanity would be unthinkable, especially in the high-threat world we live in.
So... we do everything we can to make it secure. We fail, of course. We always will. But we fail less every year.
(Aside: Working on Android security is particularly challenging, because we write our specs and our code, and then throw it all over the wall to the device makers, who are free to change almost anything. So we have to come up with ways to make stuff secure, and then we have to further find ways to design/build it so that it's hard for the device makers to screw up.)
If I could beg Google for one thing, it would be to deny compliance certification (and Play Store access) to any manufacturer that doesn't provide bootloader unlock codes to their users at the point of sale.
Now you're talking about something well above my pay grade. But I'll take a stab at it anyway. I think the reason Google doesn't do this is because carriers and device makers would Just Say No. It wouldn't take much for them to organize and set up an alternative app
Sorry, I have nothing to do with any of that. But, can you not still install a custom launcher and change it however you want? Your complaints are all about the lack of configurability of the default launcher... but that's hardly your only option.
However, if you look at modern C++, there is a smaller, cleaner, safer language emerging. Using it requires discipline since you need to avoid all of the other stuff that's still there because it can't be taken away. I'm actually really enjoying C++ since C++11, and it's still getting better.
Well, that is good to know. Of course, they should pack all the problematic stuff away into some "#pragma oldstuff" or the like and define a clean, simple and clear core language. Then I would take another look. Don't get me wrong, I do know that there is a sane core in there in C++, the problem is just that most people working in C++ do not know this or understand what it is and end up using and abusing the really problematic stuff.
Good taste is essential. Of course, that's true in every language. It's just more true in C++.
Also, have they finally fixed the virtual function dispatch performance mess?
There's no problem with virtual function dispatch performance. It's very close to optimal; you might be able to beat it by careful organization of vtables to optimize cache usage, but it is precisely an offset load to get the vtable address, then an offset load to get the function address and then jump. And actually ARM and X86 can both accept an offset address as a load or jump target, so it's all done in two instructions.
The biggest performance hit you get from using virtual functions is that when the compiler can't know statically what function you're going to call, it can't do any optimization of that call. It can't inline stuff, omit saving and restoring of registers the callee won't touch, etc. But this isn't a problem with C++, it's an inherent limitation of dynamic dispatch in a statically-compiled language. JIT compilation can fix it in many cases, but not all, and that adds many other costs. Of course, if C++ compilers can prove that a a potentially-polymorphic call will always go to the same place, they're free to optimize the dynamic dispatch out and proceed with whatever other optimizations are available. And they do.
But modern C++ tends to focus much less on run-time polymorphism, since in many cases compile-time polymorphism gives you what you need, and allows compilers their full range of optimization options.
That one is a myth. This "greater productivity" does not exist.
I have decades of experience proving you wrong on this, including plenty of examples of parallel development of the same or very similar projects in C and C++.
Also, very often a specific language is used because it is hyped or because the developers you have cannot do anything else.
Availability of programmers is one of the most important language features you have to consider when choosing a language for a project. If the language is an absolutely perfect fit, but no one knows it and no one is interested in learning it, it's the wrong choice. In practice, you can usually find people willing to learn most anything, so schedule and cost are additional considerations. If choosing the perfect language will mean three months of ramp-up and one month of development, but an already-known language will mean two months of development time, then the already-known language wins. Well, maybe not, because maintenance. But now you have to consider what will happen if the programmers who've learned the perfect language leave and you have to train another batch.
In practice, there are a lot of solid, pragmatic, engineering reasons to stick with imperfect but popular and well-established languages that have good ecosystems and user bases. Like C++:-)
Slashdot Mirror
What's even better than the distance measurement is the fact that the ranging process includes a secure key derivation protocol. The two radios that participate in the "secure bounding" process, as it's called, emerge with both a highly-accurate range estimate and a shared secret key. Eavesdroppers can't easily compute the shared key (I haven't actually looked into the details of how this works), which means that if subsequent communications are encrypted and authenticated using the shared secret plus another mutual secret, relay attacks become very hard.
Suppose we have a secure authentication protocol that we only want to operate at close range (say, unlocking your car). Without precise ranging we have two problems. The first is that the protocol may be carried out at a longer range than you want. For example, unlocking your car in your driveway when you're in the house. Precise ranging by itself solves that problem. The second is that an active attacker may perform a relay attack and carry out the protocol at an arbitrary distance, such as unlocking your car in the mall parking lot when you're walking around the mall. The relay is performed by putting one radio near your phone and other near your car and relaying messages between them.
Note that without secure bounding, cryptography can't solve the relay problem because the attacker doesn't have to be able to read the messages, just pass them back and forth. And precise ranging doesn't help because your phone will measure the distance to the attacker's first radio and your car will measure the distance to the attacker's second radio. You can try to do something like have each side encrypt its distance measurement and send it to the other side, but that just means the attacker has to be careful to get both of his radios about the same distance from yours.
But with secure bounding, each pair of actually-communicating radios will compute a distinct session key. The attacker will know both of these, but if your phone and the car both securely combine the bounding-derived session key with a secret the two share and the attacker doesn't have, the result will be a shared session secret which will only be identical if the phone and car are actually communicating directly.
According to Marx under normal circumstances capitalists will...
According to Marx, knowledge is irrelevant to production, only labor and raw materials matter. IOW, Marx's ideas are inapplicable in any economy or market where new ideas are created, which is pretty much the opposite of what the tech industry is/does. Under Marx's assumptions all workers are identical and replaceable and there are always enough workers available so that any worker that demands more than is necessary for bare survival can be replaced with one who does not.
None of Marx's assumptions are valid in the modern world, and it's debatable whether they were ever valid.
No, it's not. Pre-installed apps are stored on the system partition. Deleting it would make absolutely no difference to your usable space.
The storage used by the system partition is carved out of the same pool of storage used by the data partition. If the apps weren't pre-installed, the system partition would be smaller and the data partition would be larger.
Microsoft's app sent 1MB of data from my phone to their servers. It came pre-installed, and I never used it. At what point exactly did I agree for Microsoft to slurp down 1MB worth of my private data from my phone?
Out of curiosity, what permissions does that app have? What might it have sent?
As an employee and investor, I'm all for Google growing up a little bit and toning down some policies that aren't suitable for a large company
As an employee (which means investor) I think this shift may be necessary, but find it sad. Mostly, I regret the loss of Google's ability to practice radical transparency internally. When I joined the company eight years ago (from incredibly-siloed IBM), I was floored by the amount of information that was shared in the weekly TGIFs, and the fact that any employee could stand up and ask hard questions of the CEO, in front of all of the rest of the employees -- and almost always get real answers, not tapdancing. I really liked that I had access to nearly all of the code for every product, and that I could submit changes to any of it (my CLs would have to be approved by the project owners, of course). And there were hundred other ways in which Google was truly different from the other corporations I'd worked for in the last 20 years.
Most of that may not actually have contributed much to the bottom line, but it has certainly made for a pleasant working environment that attracted and retained lots of really talented -- and very nice! -- people. I still feel like I'm surrounded by nice, talented people. So much so that I find keeping up with them a constant challenge. But I am concerned that as Google becomes a more traditional corporation, that may be lost along with the rest.
The problem is that some panned out (a user base that liked what they were doing), and Google killed them anyway
Google has a different definition of "panned out", at least for free services. Unless a service has 100M+ users, or looks likely to get there, it's a flop and not worth the effort it takes to operate it.
Or just plain shot the kitten, as per Google Reader.
Google Reader is a good example. It had a few million devoted users, but wasn't growing and was clearly never going to build a large user base.
In cases like that, I do wish Google would experiment with charging for services and making them profitable that way. I think that might have worked with Reader. Or, if not, it would at least have been more understandable to users. I think Google would be better off with a reputation for making the first hit free then charging later than for making free stuff that abruptly disappears. People understand fee-for-service, even if they often don't want to pay. I'd also like to see more experiments with charging for ad- and tracking-free versions of free services. I think the vast majority of people would opt to continue trading data for services, but I think it would do everyone good to make the choice more explicit.
I'm obviously not speaking for my employer here. If I were in a position to do that, Google would be doing these things.
But the reaching out we know of occurred after publication to the whole world.
You're being deliberately disingenuous. Obviously the information they were seeking hadn't been published, otherwise they wouldn't have had to try to get it.
No disingenuousness, the only information they ever received was the already published info.
That's irrelevant. They were clearly seeking additional, unpublished information. Else why bother?
Yeah, lying to the feds is bad. Is there anything else shocking or illegal in these events? There doesn't seem to be.
Yes. Getting dirt on your opponent is receiving a campaign contribution, and there are laws restricting who can give you contributions. Getting them from foreigners is illegal.
So if you are buying the dirt from foreigners you are fee and clear, as opposed to receiving it for fee?
I'm not sure, but I would think that would still constitute foreign assistance.
Of course, this doesn't apply to dirt that is published to the whole world. But reaching out to Wikileaks to get Russian-sourced dirt on Hillary would be soliciting an illegal foreign contribution to Trump's campaign.
But the reaching out we know of occurred after publication to the whole world.
You're being deliberately disingenuous. Obviously the information they were seeking hadn't been published, otherwise they wouldn't have had to try to get it.
Yeah, lying to the feds is bad. Is there anything else shocking or illegal in these events? There doesn't seem to be.
Yes. Getting dirt on your opponent is receiving a campaign contribution, and there are laws restricting who can give you contributions. Getting them from foreigners is illegal.
Of course, this doesn't apply to dirt that is published to the whole world. But reaching out to Wikileaks to get Russian-sourced dirt on Hillary would be soliciting an illegal foreign contribution to Trump's campaign. Anyone involved in soliciting or receiving such contributions committed a crime. Anyone who directed someone to solicit or receive such contributions committed a different crime: conspiracy. And the conspiracy charge doesn't depend on the underlying crime actually being carried out. And anyone who tried to cover up either crime by interfering with the investigation committed yet another crime: obstruction.
The right thing for a person involved in a US political campaign to do when someone offers them foreign-sourced dirt on their opponent is to call the FBI immediately. If they're offered domestically-sourced dirt, they should probably consult with the campaign's legal staff before accepting it.
Trump can't pardon him until he's actually convicted of something.
Ford pardoned Nixon. Nixon was never even indicted, much less convicted.
I thought the president is already suffering from dementia.
This is interesting: https://www.statnews.com/2017/...
I find your ideas intriguing and would like to subscribe to your newsletter.
Ah yes, the 'programming challenge' final.. i.e. the 'guess what specific niche that if you have a solid base can probably look up in 10 minutes but if you don't know it off the top of your head and solve it the way I picture it, that means you don't know anything!' test.
If that's what you get, the interviewer doesn't know what they're doing. Programming tests should test your ability to solve problems and write code. They shouldn't require any knowledge beyond basic algorithms and data structures, plus, of course, a knowledge of the syntax and idioms of the language you're using.
And if the interviewer is expecting you to solve the problem in the same way they would, that's bad, too. Any correct solution should be fine. I had one candidate who created a better solution than the one I had in mind, which is pretty impressive since I'd already had several of my colleagues and a few dozen interview candidates give it a shot, plus spending a fair amount of time on it myself. Yes, he got the job, and has excelled.
Further, if the interviewer is doing the job right, it shouldn't even matter that much whether you solved it correctly! That's not the point. The point is to see how you think your way around the problem. Someone who blunders around blindly and happens to stumble onto a good approach is not going to get as high marks from me as someone who methodically and intelligently works through the possibilities and can clearly explain their rationale, even if they happen to miss something. (Though the best programming challenges don't rely on the candidate getting any flashes of insight, and can be solved fairly quickly by anyone competent.)
Does it have a power button, or do you just wait for the battery to go dead? Using the touchscreen to turn something on means the touchscreen needs to constantly be drawing power...
It has a power button, in the form of a pressure-sensing edge.
When switching between T-Mobile and AT&T, I had to buy new SIM cards, which makes me wonder if this comes locked to a specific carrier. (The sad thing is when I switched back to T-Mobile, I had to buy another SIM card!)
I'm sure it uses an eSIM. My Pixel 3 has one (and also a SIM slot). It's the same sort of chip as in a SIM, but it's inside and it's reprogrammable. You connect to Wifi, install a carrier app and the app configures the eSIM with data from the carrier. Over the next few years I expect SIM slots to gradually disappear.
You know, there was a time when no one had cell phones and we all got along fine. In many ways it was better.
Meh. I didn't get my first cellphone until I was almost 30, so I had plenty of experience with the pre-cellular life. We got along fine only because we spent a lot of extra time and effort on pre-planning. Want to meet your friends or relatives somewhere? Better get it all set up in advance, and with a high degree of precision. If one of you makes a mistake and is off by a smallish amount on the time or the location, you're not going to meet. Break down on the road? If you can't fix it on the spot you're going to have to hitch a ride to where you can get help, or hope a cop comes buy to radio for a tow truck. And if you were on your way to meet someone, they'll have no idea why you didn't show up.
Those are just two examples. Those who have grown up with the freedom provided by cell phones have no idea how much extra effort it took to get around. Some who grew up without phones have forgotten, or are just engaging in the Golden Age fallacy.
Nimbyism, regulations, and lawsuits seem to make most all power generation more expensive or impossible. Pipelines, dams, power lines, wind farms, fracking.
But none of them provoke the visceral fear of the unknown that nuclear power does, or evoke visions of mushroom clouds, even though every one of them has killed orders of magnitude more people (except maybe fracking; but I don't think we yet understand the costs of fracking). This means none of them have the depth of organized opposition, or the many options for running up costs.
Unregulated nuclear is scary. Cost cutting, companies that shutdown as soon as problems appear and such, all leaving the tax payers on the hook.
Sure, sensible regulation is sensible. But that's not what we have in the nuclear industry. We have a combination of ridiculous over-regulation that essentially stops all new construction, combined with ridiculously lax extensions on operating permits because without new construction we don't have anything else to take over the baseload when we shut an old plant down. This is the worst of all worlds. We're essentially running headlong toward a significant nuclear accident because of our regulations that are supposed to prevent nuclear accidents.
I have no opposition to sun, wind, etc. I think they're great, and I'm just fine with replacing nuclear power with them. But that's going to take time, and in the meantime we're going to keep burning coal and dumping gigatons of CO2 into the atmosphere. At this point it's probably too late to try to ramp up nuclear production. Even if we got instantly rational about it, by the time we could build the nuclear capacity we need, we can probably deploy the same capacity in renewables + utility-scale storage. We screwed ourselves 20-30 years ago when renewables weren't practical, and now we're just going to eat the cost, in the form of a warmer planet than we might have had otherwise.
Hangouts has over a billion installs on Android. It's extremely popular, by far Google's most popular messaging app and the default for handling SMS on Android.
Hangouts does not handle SMS on Android any more, unless you're using Google Voice or Google Fi. SMS on non-Google carriers must use the Messages app or a third party app. Even before they removed the ability for Hangouts to handle (non-Google) SMS, Messages was the default.
You make some valid points, but..
because we think people should be able to do what they want with their devices.
You should add the caveat, - "as long as Google can mine the users data". That is the only thing Google really cares about.
It's really not.
First, let me make clear that I work on Android. This is completely separate from the Google Apps. From my team's perspective, Google is just another app developer (though obviously a very influential one).
The Android system provldes no special access to Google. None whatsoever. If you want to scoff, please point me to the Google-data-mining hooks in AOSP.
Further, Google's apps are not special to Android. They cannot get any data from any other apps that don't choose to share it with them. That said, the Google suite of apps is very comprehensive, and users do tend to use a lot of them, and nearly all of their personal data does flow through them. Mail, contacts, location services, browsing, etc.
OTOH, it's also a very broad, deep and high-quality set of services, for which users pay nothing, in dollars. The deal is you trade the ability for Google to target ads to your eyeballs in exchange for all of that. If you think that's a bad deal, you're completely free to opt out. Buy an unlockable device, unlock it, remove all the Google apps, use a different search engine, don't use gmail, etc.
(Yes, I recognize I'm being a little disingenuous here. Most people couldn't actually do what I describe. But it is possible, and many Google engineers put in a lot of extra work to make sure that it continues being possible.)
In a sense, allowing vulnerabilities means that there's competition to get to the data.
No... we do not consider attackers who exploit vulnerabilities to be in any way "competition". Facebook is competition, as are other app developers who build tools that attract a lot of user data and then advertise to users.
It makes sense in other contexts too as to why Google is never going to allow users to encrypt the Inbox.
You certainly can do it if you want. GMail has full IMAP4 and POP3 interfaces, and you can use them with mail clients that support S/MIME or OpenPGP. Yes, I'm also disapointed that the Google end-to-end encryption project has died. I don't know why that happened, but I suspect that it was lack of executive support, probably for exactly the reasons you postulate: it undermines the business model that pays the bills -- including for the operational costs of GMail.
Anyway, my point is that your claim is wrong. Google does allow you to encrypt the inbox... Google just doesn't encourage it. A different sort of company would ban it.
We don't mind you guys fixing vulnerabilities, or even employing dark patterns across your products, or even trying to trick people to use your products - Hey, its a tough world out there. Its only when you cloak your actions under altruism that we find it reprehensible.
There actually is a huge amount of altruism at Google. it's not a cloak, it's reality. Of course, it's sometimes in tension with the need to generate profits, but less often than you might think. Generally, if you build something that hundreds of millions or billions of people want to use, there's some way to make it generate revenue -- which is good because running such massive services is expensive.
For me, personally, making Android secure is as much about improving the world as it is about getting a paycheck. I could get paid to do a lot of things. Few of them would be as rewarding as what I do.
Why can't I get root on any android phone just by connecting it to a pc, enabling developer mode, letting the pc with adb set or deny root, or special commands like let apps of my choosing enable or disable wifi, data, gps, etc.?
Let me tell you a story. A true one. It's not actually an answer to your question, but it points the way.
Last year, a major Android device maker came to me and asked how I planned to fix the developer mode vulnerability. "What developer mode vulneability?" I asked, reaching for my laptop to look up the CVE.
They explained that in various parts of the world, especially Asia, but not only Asia, there are lots of free charging stations at bus stations, airports, coffee shops, Internet cafes, restaurants... and just about everywhere else you can think of, including public restrooms. These charging stations have a sign hanging over them with a list of instructions that people have to follow to get free charging:
According to the device maker asking the question, If you go watch one of these locations you'll see that 95+% of people dutifully carry out all of the steps so they can charge their phone. They often don't notice the flood of malware the charging station sideloads onto their phone. This is because it doesn't do anything right away, usually not until after the next reboot plus a random delay.
I put my laptop away and explained that we had no plans to fix the developer mode vulnerability.
Given your UID, I'm guessing we're probably around the same age, having grown up with early x86 machines, dos, os/2, slackware, etc.
I suspect so. I'm 50.
Not to go all nostalgic, but "those were the days." We were free to explore, learn, tinker, fix, and break. We could output directly to ioports and trigger interrupts as a matter of course. I learned more about what makes a computer compute as a kid with a beat up old 8086 than I have as an adult (both in University and professionally).
Yep, but the openness of the systems isn't the only thing that has changed in the last 30-40 years. When we were tinkering, computers were rare, little-used and isolated. Now they're ubiquitous, so heavily-used they're almost a brain expansion pack and they're networked all of the time. The fact is that the vast, vast majority of computer users -- especially of mobile devices -- know absolutely nothing about how they work, and have no interest at all in learning, exploring, tinkering. They just want to read Facebook, surf porn, make phone calls, etc. They would look at the computers that you and I started on as completely and utterly useless because it took a tremendous amount of work to make them do anything.
Another thing that has changed is the nature of the threats. 35 years ago I wrote a little terminate-stay-resident DOS program that made the characters on the screen fall into piles on the bottom. I gleefully installed this on lots of friends' and family members' computers (well, "lots" was like four; machines were rare). Later I modified it to spread itself virally, by writing itself into the boot sector of any floppy it could. I never installed that one anywhere, though. But we're long, long past the days of the casual, for-fun hacker. Today security is a serious problem. The attackers are often organized criminals, of varying but often significant sophistication. Sometimes the attackers are nation states. Military cyberwarfare groups, intelligence agencies, etc. (Aside: We'll never keep the really serious attackers out of consumer devices, but we maybe can make it hard enough that they can't scale their attacks.)
The reason that the attackers have changed is because the way we use computers has changed. Absolutely everything is on a machine somewhere. Our mobile phones contain pretty much our whole lives: personal, financial, photographic, you name it. This puts even the average person at significant risk, mostly financial. We've seen hundreds of thousands, perhaps millions, of people scammed out of significant amounts of money by people who explolited vulnerabilities in their devices. And that's nothing compared to the risks to high-profile people, who have much more to steal.
The total number of Android users has passed three billion, and it won't be long before it hits four. Shipping vulnerable software to damned near 50% of humanity would be unthinkable, especially in the high-threat world we live in.
So... we do everything we can to make it secure. We fail, of course. We always will. But we fail less every year.
(Aside: Working on Android security is particularly challenging, because we write our specs and our code, and then throw it all over the wall to the device makers, who are free to change almost anything. So we have to come up with ways to make stuff secure, and then we have to further find ways to design/build it so that it's hard for the device makers to screw up.)
If I could beg Google for one thing, it would be to deny compliance certification (and Play Store access) to any manufacturer that doesn't provide bootloader unlock codes to their users at the point of sale.
Now you're talking about something well above my pay grade. But I'll take a stab at it anyway. I think the reason Google doesn't do this is because carriers and device makers would Just Say No. It wouldn't take much for them to organize and set up an alternative app
Sorry, I have nothing to do with any of that. But, can you not still install a custom launcher and change it however you want? Your complaints are all about the lack of configurability of the default launcher... but that's hardly your only option.
However, if you look at modern C++, there is a smaller, cleaner, safer language emerging. Using it requires discipline since you need to avoid all of the other stuff that's still there because it can't be taken away. I'm actually really enjoying C++ since C++11, and it's still getting better.
Well, that is good to know. Of course, they should pack all the problematic stuff away into some "#pragma oldstuff" or the like and define a clean, simple and clear core language. Then I would take another look. Don't get me wrong, I do know that there is a sane core in there in C++, the problem is just that most people working in C++ do not know this or understand what it is and end up using and abusing the really problematic stuff.
Good taste is essential. Of course, that's true in every language. It's just more true in C++.
Also, have they finally fixed the virtual function dispatch performance mess?
There's no problem with virtual function dispatch performance. It's very close to optimal; you might be able to beat it by careful organization of vtables to optimize cache usage, but it is precisely an offset load to get the vtable address, then an offset load to get the function address and then jump. And actually ARM and X86 can both accept an offset address as a load or jump target, so it's all done in two instructions.
The biggest performance hit you get from using virtual functions is that when the compiler can't know statically what function you're going to call, it can't do any optimization of that call. It can't inline stuff, omit saving and restoring of registers the callee won't touch, etc. But this isn't a problem with C++, it's an inherent limitation of dynamic dispatch in a statically-compiled language. JIT compilation can fix it in many cases, but not all, and that adds many other costs. Of course, if C++ compilers can prove that a a potentially-polymorphic call will always go to the same place, they're free to optimize the dynamic dispatch out and proceed with whatever other optimizations are available. And they do.
But modern C++ tends to focus much less on run-time polymorphism, since in many cases compile-time polymorphism gives you what you need, and allows compilers their full range of optimization options.
That one is a myth. This "greater productivity" does not exist.
I have decades of experience proving you wrong on this, including plenty of examples of parallel development of the same or very similar projects in C and C++.
Also, very often a specific language is used because it is hyped or because the developers you have cannot do anything else.
Availability of programmers is one of the most important language features you have to consider when choosing a language for a project. If the language is an absolutely perfect fit, but no one knows it and no one is interested in learning it, it's the wrong choice. In practice, you can usually find people willing to learn most anything, so schedule and cost are additional considerations. If choosing the perfect language will mean three months of ramp-up and one month of development, but an already-known language will mean two months of development time, then the already-known language wins. Well, maybe not, because maintenance. But now you have to consider what will happen if the programmers who've learned the perfect language leave and you have to train another batch.
In practice, there are a lot of solid, pragmatic, engineering reasons to stick with imperfect but popular and well-established languages that have good ecosystems and user bases. Like C++ :-)