If you think you "know" anything, you have no clue about how science works.
Fine. People who understand how science works know that the best available explanatory theories for observed phenomena indicate that climate change is substantially the result of human release of CO2, and that GMOs are safe.
Of course, new evidence may be discovered tomorrow that upends these conclusions. That's science. But it's really unlikely.
With FPI enabled, the ad tracker won't be able to see all the cookies it dropped on that user's PC, but only the cookie created for the domain the user is currently viewing.
Why the fuck isn't that by design? Who's the moran who decided not to include that in the specifications?!
It is by design and it is in the specification, always has been. Sites can only set cookies for the domain that serves the content.
Depends on whether you have any data on the phone that you'd like to protect. Even if you only use it to make calls, you still have your call log and perhaps some contacts on there. A good social engineer can create lots of trouble with that information.
Basically, you need to think about everything that's on the phone, and how it could be used to steal from you. Think especially about remote services that your phone has access to. Then decide if you should lock it.
I think the vast majority of people should lock their phones, but that they don't actually need really strong authentication. Fingerprint is a very good choice for most. Convenient and reasonably secure. The jury is still out on whether face can be made sufficiently secure.
Completely wrong. Biometrics are neither user IDs nor passwords.
There are three aspects to security: something you are, something you know, something you have. Implement two for rudimentary security, implement all three for good security.
"Security" is not the same as "user authentication". Actually "security" isn't even a well-defined concept; it's utterly context-dependent.
- Something you are: User ID, biometrics, or some other public information that serves to identify the person.
WTF? Your user ID is "something you are"?
- Something you know: Typically a password, used to prove the identity
Knowing something doesn't prove "identity" it proves knowledge.
- Something you have: Second factor, used to prove that the password and identity were not stolen.
Again, possession of a second factor does nothing of the sort.
Okay, look, access control consists of three elements:
1. Identity
2. Authentication
3. Authorization
Authorization determines what resources a given identity has access to. Authentication validates that a person is connected to an identity. A user ID is a specification of an identity.
We have devised various ways of authenticating people as identities. They all suck. The reason using multiple methods (factors) is good isn't because there's some inherently ideal way to authenticate, it's because all of the individual methods suck. Using multiple methods allows us to paper over the deficiencies of one method with another.
For example, passwords suck because they're just information, and information leaks. Phishing, shoulder surfing, keyboard audio, even brute force search, there are lots of ways for an attacker to attempt to get your password, or parts of it. And once the attacker has that information, he can authenticate as you. Further, he can give it to all of his friends and they can all now authenticate as you, too. If the "attacker" is a friend or family member, getting your password is really easy.
Lots of people think that biometrics suck because it's too easy to get your biometric data. But the biometric security model assumes that your biometrics are public information. The attacker and all his friends already have it. Biometric security is based on the theory that if the device measures a body part then only the person who has that body part is authenticated. It's based on the integrity of the measurement process, not the secrecy of the information measured. But, the measurement process on consumer devices sucks. It's feasible to fake body parts and fool the measurement into accepting them as real.
As for physical tokens, well, they suck because objects are movable (losable, stealable, etc.). But unlike passwords, they aren't easily copyable, which means that the legitimate user can know the token is gone and can take appropriate steps.
So, when you combine these things, they cover for each other. Still not perfectly. I can get your password, fake your face/finger, and steal your token, and then I can claim to be you. But it's a lot harder. The token limits my time window, because when its loss is discovered the access will get closed down. The password is easy for friends and family to steal, potentially very, very hard for strangers. The biometric is moderately hard for anyone to fake, including friends and family (assuming it's properly implemented and family faces don't just work).
Face-ID and fingerprints are insecure and easily fooled.
There you go with that word again: "secure" (okay, its negation). Secure against who? In what context? These questions matter.
Linus's context is entirely in terms of the kernel. If you ignore that, you write comments that are complete non-sequiturs.
More importantly, Linus's context is the particular discussion. If you lift the comment to the context of the kernel as a whole, it's wrong.
In the full context, I think he has a point; he was arguing against panicking the kernel when an out-of-spec situation is found. The security guy's (Kees) patch presumed that out-of-spec indicated an attack, when it most likely just indicates a bug. Being a security guy myself, I sympathize with Kees, we tend to think about things in terms of how to mitigate possible attacks, and reducing pwnage to DoS is a good thing. Not so much, though, if the panic gets triggered a lot by ordinary bugs. In that case, we need to detect the problems, but continuing to run is good.
But, if we take the statement as an absolute, even in the kernel context, it's wrong. There are lots of security problems which aren't "just bugs", they're fundamental design and architectural flaws. And Linux has a really bad one: it's monolithic. A bug in any driver can compromise the entire OS, giving the attacker access to the entire system. The "hardening as debugging" which Kees is doing is a rearguard action which could reasonably be described as hopeless. Oh, it's well worth doing, but it will never really solve the problems. We've been trying for years to staunch the flow of critical security vulnerabilities in the kernel, and there's no evidence that it's getting better.
At some point, we need to get away from monolithic kernels and move to micro-kernel models with strong mandatory access control firewalls between all of the components. It's clearly not possible to retrofit that approach onto Linux, though.
Bitcoin has intrinsic cost. That's not the same as value. All of Bitcoin's value is based on the belief that it has value. Of course, that's mostly true of all currencies -- including so-called precious metals. But it's truly "pure" in the case of Bitcoin.
The failed attempt count probably isn't stored in the secure enclave, but I don't know.
It would be rather dumb if it weren't.
FWIW, Android's secure environment stores the failed attempt account. Further, implementations are required to increment the failure counter before checking the passcode, to eliminate the possibility that the attacker could block the counter update.
I looks like editors learned their lesson.
If you read carefully, in the summary, no mention is made of any causal relationship so the following possibilities are still open:
1- excessive screen time causes depression
2- depression causes excessive screen time
3- what causes depression also causes excessive screen time
Whenever someone says this, ask them if they are comfortable with the command-line. The answer is always no.
I've used Mercurial from the command line for 5+ years, didn't even cross my mind to use a GUI for it. Git however is completely unusable to me without SourceTree. Git has a horrible UI, especially on the command line.
How does Mercurial perform on a 300GB repo? Honest question; I've dabbled briefly with Mercurial on small projects (where I found it nice, but slow) but never looked into how it scales.
your comment make me realize that versions 6 and 7 may become the new Android-4-like plague
That's not what I said, and I don't think that will happen. It's certainly not what the people behind Project Treble intend. OEMs aren't refusing to move to Oreo, its just going to take some effort. And once the transition is made, the updates and upgrades will flow much more smoothly. It'll be easier for even budget phone makers to launch the latest OS, and to upgrade it.
That's the idea, anyway. It'll take three or four years to see if it really pans out.
It won't surprise me if OEMs are a little slower to roll out Oreo than they have previous dessert releases, because Project Treble is an enormous change for them. With Treble, Google is drawing a hard line between the Android system and the underlying hardware. Because OEMs have in the past been accustomed to being able to change things at all levels of the stack -- as long as the compatibility test suite passes and associated non-functional requirements are met -- this change is requiring them to restructure their customizations.
Further, since the hardware API is now well-defined, Google is testing it. That couldn't be done before. It's a good thing for the ecosystem and for future compatibility, but it requires work. For example, I wrote a suite for the hardware API that I own and found that the Google Pixel couldn't pass it, because the implementation (from Qualcomm) on the Pixel didn't actually meet the specification in many small ways. Not ways that actually produced observably-incorrect functionality at the higher layers, but it was wrong. It took Qualcomm a couple of months to fix the problems and deliver a version that could pass the new test suite.
So, Oreo has created a lot of new work for component vendors and OEMs, and it's going to take them time to work through it.
In the long run, of course, this should be great for the ecosystem. It should actually allow a vanilla AOSP build to be be flashed onto any device (assuming locked bootloaders and verified boot don't stop you). And once everyone is accustomed to the new structure, it should actually make it much easier for OEMs to get new versions out faster, not only for updates, but on new devices as well.
In the short term, I'm not surprised to see OEMs choosing to launch with Nougat, where they don't have to meet Oreo's requirements. This isn't because they don't want to, but because they have product launch deadlines to hit. By next year's launches they'll have had time to get squared away and I expect things to start moving faster than in the past.
New laws require all electric vehicles to include noisemakers which could potentially make them LOUDER than modern internal combustion vehicles (I wish I was joking!)
Only at low speed, where the sound might actually be a useful warning to pedestrians. Once the speed gets over 20 mph or so, the vehicle is moving fast enough that it would have to be really loud for a pedestrian to hear it at a useful distance.
The Nissan LEAF has always had such a noisemaker. It shuts off at about 20 mph.
The resulting network is the algorithm. "Develop" usually means "propose a specific neural network architecture" in this context. So no, no meta-learning, nor novel optimization algorithm.
OTOH, choosing a good neural network architecture makes a huge difference, and is decidedly non-trivial.
That's like saying the Webb Space Telescope is old tech because Sputnik. Papnet can't read x-rays, and it's not because it never occurred to anyone to try to automate the analysis 20 years ago, it's because it's a harder problem that 90s-era technology couldn't handle.
Did they take into account the trained conservatism in diagnosis? Radiologists (and doctors in general) will err on diagnosing as possible positive and then testing for validation. AI doesn't care about playing it safe.
I think you'd still want human judgement in the loop, at least in the near term. However, there's no reason the AI couldn't be trained to emit "probably X, do tests A, B and C to confirm".
No, the whole reason that they're convoying is so they don't have to pay a driver for each vehicle.
They showed pictures of the convoying. The space between vehicles was quite large.
Further, even if they did close up tight, there's no reason the self-driving systems couldn't see your turn signal and open a space for you to get in / through. Unlike human drivers, computers don't become inattentive or annoyed.
If the data is say held by Google and they allow only certain aggregate queries to be done but never give you anything but the aggregate answer then Safegraph won't know what happened in individual houses.
Your hypothetical makes sense, but it doesn't appear to be the case. According to TFA, Safegraph doesn't get the data from Google or any similar source, they get it from many third-party apps, and they have to get full detail because they are the aggregator. They can take steps to anonymize it, of course.
I didn't have room in the summary to cover charging (tried to fit in as many specs as I could!), but I probably should have made room: 30 minutes to 80% when empty. And you can install those chargers (quite compact, and don't need underground tanks) at depots; they trickle charge to fill a battery buffer, when then surge charges a vehicle when it connects, so it doesn't even mean stops "on the road".
I wonder if they're also planning to support the obvious (to me, at least) option of putting an additional battery in the trailer. Trucks often run loaded less than 100% capacity so trading off some cargo volume/mass for additional range could make a lot of sense. In fact I'm kind of surprised the battery capacity in the tractor isn't more modular. Battery swapping doesn't make so much sense for consumer vehicles, but it seems perfect for commercial fleets with maintenance depots. I'd think a smallish internal battery, good for short trips, plus a bay where additional capacity can be installed with a forklift would make a lot of sense -- and the ability to add additional towed battery capacity, perhaps up to non-stop coast-to-coast range (for full self-driving, which on freeways is probably achievable with only cameras and radar).
Some screening might be better than none... but there's no evidence that anything more than what's been done in the past is required. So it's all just a waste of money and time, serving no purpose other than to make the US look like xenophobic assholes. Which, I'll grant, a substantial number of us appear to be.
FWIW none of the Google security and privacy engineers I know have any concern about having a Google Home in their house, and many do. Those who don't, don't because they don't see the value, not because they perceive privacy or security problems.
I'll venture to say that somebody who works at Google already doesn't care about privacy - in particular for other people.
The truth is quite the opposite. Google hires the nerdiest of nerds, and they (we) care about what nerds care about.
Google will track you whether you choose to be tracked or not, and there is no way to opt out (and no, the current "solution" they suggest, to create an account with them in order to to tell them "don't track" is not sufficient or even workable).
Actually, that's not the opt-out mechanism. The opt-out mechanism is a setting that's tracked in a non-unique browser cookie, and, optionally, a browser plugin that makes sure the cookie doesn't get lost.
IMO it's Google and other similar companies' business model that's based on a misunderstanding: the misunderstanding by the general population of Google's actions and scale of data gathering. As people were generally unaware, Google has expanded their spying and made stalking and data slurping the current accepted model for anything.
You're right, far more concerning that someone on the internet finds a 0day and puts your Amazon camera on some open website.
No, I don't think that would be particularly likely. It would require a much deeper compromise of the device. And if someone had such a deep compromise, why would they bother using it to stream a picture of your front door? Well, maybe yours is much more interesting than mine.
I'd say 'the bad' is that you never really know if every flaw is patched.
Sure you do.
There will always be unpatched flaws. This is true of everything.
On the other hand the probability that some deliveryman has access to an unknown 0day and is willing to use it to steal from you is quite low. Much lower than the probability that some random burglar is willing to break your window in order to steal from you. A regular stream of vulnerability reports like this is a good thing, because it means researchers are paying attention. It's better if the researcher practices responsible disclosure and you only hear about it after the vulnerability is patched, though.
Buying smart-home devices at this time would be really dumb. They are insecure, unreliable and overpriced. The only thing they will do for you is cause problems.
FWIW none of the Google security and privacy engineers I know have any concern about having a Google Home in their house, and many do. Those who don't, don't because they don't see the value, not because they perceive privacy or security problems. I haven't spoken with any similar engineers at Amazon, but I expect the same is true there.
IMO, the privacy concerns are overblown and based on a misunderstanding of how the tech works, and I think the big tech companies are also quite good at security. Pricing is a personal value judgement, and depends both on how much money you have and how much value you expect to receive. I have a Google Home and like it. I've been considering buying an Echo just to see how it compares.
Slashdot Mirror
If you think you "know" anything, you have no clue about how science works.
Fine. People who understand how science works know that the best available explanatory theories for observed phenomena indicate that climate change is substantially the result of human release of CO2, and that GMOs are safe.
Of course, new evidence may be discovered tomorrow that upends these conclusions. That's science. But it's really unlikely.
Why the fuck isn't that by design? Who's the moran who decided not to include that in the specifications?!
It is by design and it is in the specification, always has been. Sites can only set cookies for the domain that serves the content.
sexconker posted a good explanation: https://news.slashdot.org/comm...
Anyone expecting TouchID or FaceID to provide iron clad security has incorrect ideas about what they are for and what their limitations are.
Apple seems to do. ApplePay, for example, is authorized by FaceID by default.
Why do you think ApplePay requires "iron clad security"? Remember it only has to be better than a magnetic stripe card.
Am I missing something here?
Depends on whether you have any data on the phone that you'd like to protect. Even if you only use it to make calls, you still have your call log and perhaps some contacts on there. A good social engineer can create lots of trouble with that information.
Basically, you need to think about everything that's on the phone, and how it could be used to steal from you. Think especially about remote services that your phone has access to. Then decide if you should lock it.
I think the vast majority of people should lock their phones, but that they don't actually need really strong authentication. Fingerprint is a very good choice for most. Convenient and reasonably secure. The jury is still out on whether face can be made sufficiently secure.
Biometrics are user-ids, not passwords.
Completely wrong. Biometrics are neither user IDs nor passwords.
There are three aspects to security: something you are, something you know, something you have. Implement two for rudimentary security, implement all three for good security.
"Security" is not the same as "user authentication". Actually "security" isn't even a well-defined concept; it's utterly context-dependent.
- Something you are: User ID, biometrics, or some other public information that serves to identify the person.
WTF? Your user ID is "something you are"?
- Something you know: Typically a password, used to prove the identity
Knowing something doesn't prove "identity" it proves knowledge.
- Something you have: Second factor, used to prove that the password and identity were not stolen.
Again, possession of a second factor does nothing of the sort.
Okay, look, access control consists of three elements:
1. Identity
2. Authentication
3. Authorization
Authorization determines what resources a given identity has access to. Authentication validates that a person is connected to an identity. A user ID is a specification of an identity.
We have devised various ways of authenticating people as identities. They all suck. The reason using multiple methods (factors) is good isn't because there's some inherently ideal way to authenticate, it's because all of the individual methods suck. Using multiple methods allows us to paper over the deficiencies of one method with another.
For example, passwords suck because they're just information, and information leaks. Phishing, shoulder surfing, keyboard audio, even brute force search, there are lots of ways for an attacker to attempt to get your password, or parts of it. And once the attacker has that information, he can authenticate as you. Further, he can give it to all of his friends and they can all now authenticate as you, too. If the "attacker" is a friend or family member, getting your password is really easy.
Lots of people think that biometrics suck because it's too easy to get your biometric data. But the biometric security model assumes that your biometrics are public information. The attacker and all his friends already have it. Biometric security is based on the theory that if the device measures a body part then only the person who has that body part is authenticated. It's based on the integrity of the measurement process, not the secrecy of the information measured. But, the measurement process on consumer devices sucks. It's feasible to fake body parts and fool the measurement into accepting them as real.
As for physical tokens, well, they suck because objects are movable (losable, stealable, etc.). But unlike passwords, they aren't easily copyable, which means that the legitimate user can know the token is gone and can take appropriate steps.
So, when you combine these things, they cover for each other. Still not perfectly. I can get your password, fake your face/finger, and steal your token, and then I can claim to be you. But it's a lot harder. The token limits my time window, because when its loss is discovered the access will get closed down. The password is easy for friends and family to steal, potentially very, very hard for strangers. The biometric is moderately hard for anyone to fake, including friends and family (assuming it's properly implemented and family faces don't just work).
Face-ID and fingerprints are insecure and easily fooled.
There you go with that word again: "secure" (okay, its negation). Secure against who? In what context? These questions matter.
Linus's context is entirely in terms of the kernel. If you ignore that, you write comments that are complete non-sequiturs.
More importantly, Linus's context is the particular discussion. If you lift the comment to the context of the kernel as a whole, it's wrong.
In the full context, I think he has a point; he was arguing against panicking the kernel when an out-of-spec situation is found. The security guy's (Kees) patch presumed that out-of-spec indicated an attack, when it most likely just indicates a bug. Being a security guy myself, I sympathize with Kees, we tend to think about things in terms of how to mitigate possible attacks, and reducing pwnage to DoS is a good thing. Not so much, though, if the panic gets triggered a lot by ordinary bugs. In that case, we need to detect the problems, but continuing to run is good.
But, if we take the statement as an absolute, even in the kernel context, it's wrong. There are lots of security problems which aren't "just bugs", they're fundamental design and architectural flaws. And Linux has a really bad one: it's monolithic. A bug in any driver can compromise the entire OS, giving the attacker access to the entire system. The "hardening as debugging" which Kees is doing is a rearguard action which could reasonably be described as hopeless. Oh, it's well worth doing, but it will never really solve the problems. We've been trying for years to staunch the flow of critical security vulnerabilities in the kernel, and there's no evidence that it's getting better.
At some point, we need to get away from monolithic kernels and move to micro-kernel models with strong mandatory access control firewalls between all of the components. It's clearly not possible to retrofit that approach onto Linux, though.
Bitcoin has plenty of intrinsic value.
Bitcoin has intrinsic cost. That's not the same as value. All of Bitcoin's value is based on the belief that it has value. Of course, that's mostly true of all currencies -- including so-called precious metals. But it's truly "pure" in the case of Bitcoin.
The failed attempt count probably isn't stored in the secure enclave, but I don't know.
It would be rather dumb if it weren't.
FWIW, Android's secure environment stores the failed attempt account. Further, implementations are required to increment the failure counter before checking the passcode, to eliminate the possibility that the attacker could block the counter update.
I looks like editors learned their lesson. If you read carefully, in the summary, no mention is made of any causal relationship so the following possibilities are still open :
1- excessive screen time causes depression
2- depression causes excessive screen time
3- what causes depression also causes excessive screen time
#2 doesn't explain the increase in depression.
Whenever someone says this, ask them if they are comfortable with the command-line. The answer is always no.
I've used Mercurial from the command line for 5+ years, didn't even cross my mind to use a GUI for it. Git however is completely unusable to me without SourceTree. Git has a horrible UI, especially on the command line.
How does Mercurial perform on a 300GB repo? Honest question; I've dabbled briefly with Mercurial on small projects (where I found it nice, but slow) but never looked into how it scales.
your comment make me realize that versions 6 and 7 may become the new Android-4-like plague
That's not what I said, and I don't think that will happen. It's certainly not what the people behind Project Treble intend. OEMs aren't refusing to move to Oreo, its just going to take some effort. And once the transition is made, the updates and upgrades will flow much more smoothly. It'll be easier for even budget phone makers to launch the latest OS, and to upgrade it.
That's the idea, anyway. It'll take three or four years to see if it really pans out.
I remember when I was called a customer, not a consumer.
At 28 I guess I'm just old.
No, you remember when you didn't pay attention. We've been called consumers since well before my time, and I'm knocking on 50.
It won't surprise me if OEMs are a little slower to roll out Oreo than they have previous dessert releases, because Project Treble is an enormous change for them. With Treble, Google is drawing a hard line between the Android system and the underlying hardware. Because OEMs have in the past been accustomed to being able to change things at all levels of the stack -- as long as the compatibility test suite passes and associated non-functional requirements are met -- this change is requiring them to restructure their customizations.
Further, since the hardware API is now well-defined, Google is testing it. That couldn't be done before. It's a good thing for the ecosystem and for future compatibility, but it requires work. For example, I wrote a suite for the hardware API that I own and found that the Google Pixel couldn't pass it, because the implementation (from Qualcomm) on the Pixel didn't actually meet the specification in many small ways. Not ways that actually produced observably-incorrect functionality at the higher layers, but it was wrong. It took Qualcomm a couple of months to fix the problems and deliver a version that could pass the new test suite.
So, Oreo has created a lot of new work for component vendors and OEMs, and it's going to take them time to work through it.
In the long run, of course, this should be great for the ecosystem. It should actually allow a vanilla AOSP build to be be flashed onto any device (assuming locked bootloaders and verified boot don't stop you). And once everyone is accustomed to the new structure, it should actually make it much easier for OEMs to get new versions out faster, not only for updates, but on new devices as well.
In the short term, I'm not surprised to see OEMs choosing to launch with Nougat, where they don't have to meet Oreo's requirements. This isn't because they don't want to, but because they have product launch deadlines to hit. By next year's launches they'll have had time to get squared away and I expect things to start moving faster than in the past.
New laws require all electric vehicles to include noisemakers which could potentially make them LOUDER than modern internal combustion vehicles (I wish I was joking!)
Only at low speed, where the sound might actually be a useful warning to pedestrians. Once the speed gets over 20 mph or so, the vehicle is moving fast enough that it would have to be really loud for a pedestrian to hear it at a useful distance.
The Nissan LEAF has always had such a noisemaker. It shuts off at about 20 mph.
The resulting network is the algorithm. "Develop" usually means "propose a specific neural network architecture" in this context. So no, no meta-learning, nor novel optimization algorithm.
OTOH, choosing a good neural network architecture makes a huge difference, and is decidedly non-trivial.
They've had this sort of tech to read digital images for decades. Papnet is used to read pap smears since the mid-1990s.
http://www.lightparty.com/Heal...
That's like saying the Webb Space Telescope is old tech because Sputnik. Papnet can't read x-rays, and it's not because it never occurred to anyone to try to automate the analysis 20 years ago, it's because it's a harder problem that 90s-era technology couldn't handle.
Did they take into account the trained conservatism in diagnosis? Radiologists (and doctors in general) will err on diagnosing as possible positive and then testing for validation. AI doesn't care about playing it safe.
I think you'd still want human judgement in the loop, at least in the near term. However, there's no reason the AI couldn't be trained to emit "probably X, do tests A, B and C to confirm".
No, the whole reason that they're convoying is so they don't have to pay a driver for each vehicle.
They showed pictures of the convoying. The space between vehicles was quite large.
Further, even if they did close up tight, there's no reason the self-driving systems couldn't see your turn signal and open a space for you to get in / through. Unlike human drivers, computers don't become inattentive or annoyed.
If the data is say held by Google and they allow only certain aggregate queries to be done but never give you anything but the aggregate answer then Safegraph won't know what happened in individual houses.
Your hypothetical makes sense, but it doesn't appear to be the case. According to TFA, Safegraph doesn't get the data from Google or any similar source, they get it from many third-party apps, and they have to get full detail because they are the aggregator. They can take steps to anonymize it, of course.
I didn't have room in the summary to cover charging (tried to fit in as many specs as I could!), but I probably should have made room: 30 minutes to 80% when empty. And you can install those chargers (quite compact, and don't need underground tanks) at depots; they trickle charge to fill a battery buffer, when then surge charges a vehicle when it connects, so it doesn't even mean stops "on the road".
I wonder if they're also planning to support the obvious (to me, at least) option of putting an additional battery in the trailer. Trucks often run loaded less than 100% capacity so trading off some cargo volume/mass for additional range could make a lot of sense. In fact I'm kind of surprised the battery capacity in the tractor isn't more modular. Battery swapping doesn't make so much sense for consumer vehicles, but it seems perfect for commercial fleets with maintenance depots. I'd think a smallish internal battery, good for short trips, plus a bay where additional capacity can be installed with a forklift would make a lot of sense -- and the ability to add additional towed battery capacity, perhaps up to non-stop coast-to-coast range (for full self-driving, which on freeways is probably achievable with only cameras and radar).
Some screening might be better than none... but there's no evidence that anything more than what's been done in the past is required. So it's all just a waste of money and time, serving no purpose other than to make the US look like xenophobic assholes. Which, I'll grant, a substantial number of us appear to be.
FWIW none of the Google security and privacy engineers I know have any concern about having a Google Home in their house, and many do. Those who don't, don't because they don't see the value, not because they perceive privacy or security problems.
I'll venture to say that somebody who works at Google already doesn't care about privacy - in particular for other people.
The truth is quite the opposite. Google hires the nerdiest of nerds, and they (we) care about what nerds care about.
Google will track you whether you choose to be tracked or not, and there is no way to opt out (and no, the current "solution" they suggest, to create an account with them in order to to tell them "don't track" is not sufficient or even workable).
Actually, that's not the opt-out mechanism. The opt-out mechanism is a setting that's tracked in a non-unique browser cookie, and, optionally, a browser plugin that makes sure the cookie doesn't get lost.
IMO it's Google and other similar companies' business model that's based on a misunderstanding: the misunderstanding by the general population of Google's actions and scale of data gathering. As people were generally unaware, Google has expanded their spying and made stalking and data slurping the current accepted model for anything.
Cite?
You're right, far more concerning that someone on the internet finds a 0day and puts your Amazon camera on some open website.
No, I don't think that would be particularly likely. It would require a much deeper compromise of the device. And if someone had such a deep compromise, why would they bother using it to stream a picture of your front door? Well, maybe yours is much more interesting than mine.
I'd say 'the bad' is that you never really know if every flaw is patched.
Sure you do.
There will always be unpatched flaws. This is true of everything.
On the other hand the probability that some deliveryman has access to an unknown 0day and is willing to use it to steal from you is quite low. Much lower than the probability that some random burglar is willing to break your window in order to steal from you. A regular stream of vulnerability reports like this is a good thing, because it means researchers are paying attention. It's better if the researcher practices responsible disclosure and you only hear about it after the vulnerability is patched, though.
Buying smart-home devices at this time would be really dumb. They are insecure, unreliable and overpriced. The only thing they will do for you is cause problems.
FWIW none of the Google security and privacy engineers I know have any concern about having a Google Home in their house, and many do. Those who don't, don't because they don't see the value, not because they perceive privacy or security problems. I haven't spoken with any similar engineers at Amazon, but I expect the same is true there.
IMO, the privacy concerns are overblown and based on a misunderstanding of how the tech works, and I think the big tech companies are also quite good at security. Pricing is a personal value judgement, and depends both on how much money you have and how much value you expect to receive. I have a Google Home and like it. I've been considering buying an Echo just to see how it compares.