OTHER THAN AS EXPRESSLY SET OUT IN THESE TERMS OR ADDITIONAL TERMS, NEITHER GOOGLE NOR ITS SUPPLIERS OR DISTRIBUTORS MAKE ANY SPECIFIC PROMISES ABOUT THE SERVICES..... WE PROVIDE THE SERVICES "AS IS"
Maybe he'll sue on grounds other than "broken promise".
And there are lots of grounds for suing even when something is "as is". For instance, attractive nuisance (doesn't apply here); negligence (would have to establish duty, breach, causation, damages); defective product; that the terms in the TOS aren't enforceable; intentional infliction of emotional distress (would have to establish that Google's behavior was extreme, outrageous and caused harm).
I'm not evaluating the strength of any of these grounds. Just saying that the TOS isn't a blanket "off-the-hook" as your post suggests.
When I bought my house there were 40+ pages of documents that I had t sign at the end, for deed transfer I think.
I skimmed through them, noticed one term that looked wrong, pointed it out. They said "you're right! In our ten years of doing business no one has ever noticed this mistake before. I'll fix it up for you here and now."
For everyone who swore up and down that Windows 10 will never be a subscription and Microsoft will always stick with their old business model (pay once for the OS, additional support by subscription): hope the crow is tasty!
What? Who would have said that? Microsoft have been offering Windows by subscription for many years already.
The problem being nobody actually understood what 'full access' through Google's API actually does, or bothered to go look it up.
RTFM kids, you'll look a lot less stupid.
What is the "FM"?
I see a lot of google OAUTH scopes listed at https://developers.google.com/.... I don't think there is a "FM" which tells us how to map the poorly-phrased UI dialog to the actual OAUTH scopes. If the UI claims to be asking for "full access", which of those scopes do you think it's asking for? All of them? Including the scope "https://www.googleapis.com/auth/gmail.modify"?
I've not used Google OAUTH, but I have used Microsoft OAUTH where the scopes had very badly worded UIs, and I bet the same is true of Google.
For instance, if your app requests the Microsoft scope "wl.signin | wl.offline_access" then all it technically does is let your app use a Microsoft ID to sign into the app but without giving even one iota of access to any of your account information. However the way it's presented to the user is "This app wants to sign you in automatically and access your info anytime". My users (reasonably) thought this meant that my app could access any of their account details anytime, and a portion of them declined to grant permission.
In this Microsoft case I don't think anyone was being stupid, and no one should be expected to RTFM, and the fault lies squarely with the folks who design the UI for the Microsoft signin process. My hunch is that the same is true of Google's OAUTH too.
Not that I'm defending the shooting, but by now everyone knows what the police officer will want when they pull you over. Get your license out of your wallet and registration/insurance out of the glove compartment, and have them ready in your hands while the officer is walking towards your car.
Leave your hands in sight at all times, like on the steering wheel.
Those two things you've said are self-contradictory. If the police officer comes over, is the officer going to see you rummaging in your glovebox for your registration (and think you're reaching for a gun)? Or is the officer going to see you with your hands in sight at all times?
There may be situations where a landlord has a good reason to limit who is accessing and modifying the cable/wire infrastructure of a property
Curious -- what kind of reasons? What's a good reason for which a landlord would allow Comcast to come modify the cable infrastructure but not, say, Time Warner? I honestly can't think of any.
Do you really think at a certain point data will have every single possible scenario? There will always be edge cases that may make AI too dangerous to use ever.
Oh no! I just think they'll gather edge scenarios at 50x the rate at which Google gathers them.
Tesla didn't recorded anything. They don't have any hardware that would provided the data, i.e. laser radar system. They don't have enough connection bandwidth to transfer the data in real time. For autonomous driving, their system is dead (sometimes literaly) end from yesterday that will be replaced soon with better systems that will provide more advanced data anyway. You can't teach a pig to fly no matter how many million miles you will run with it.
It seems like for every incident they do somehow get detailed logs of what their sensors recorded. Sure it's not realtime, and sure it's not cases where the system performed fine. It feels like a variation of what ESR said -- "given enough eyes, all bugs are shallow". In this case Tesla is getting a load of real-world "bug reports" about their software.
You seem to be arguing that historical sensor reading data for a system with "X" sensors (and software developed for it) will be irrelevant for a system with "X+Y" sensors. That's a plausible assertion, although I'd bet against it.
The other main difference is that Tesla has logged data from 50 million miles of autopilot data from all over the world, while Google has logged data from 1.5 million miles mainly in the Bay area.
I think this gap will widen exponentially, and good enough AI for driving will come only through masses of data, so Tesla have a huge advantage.
In my experience, all the hospitals do it the wrong way - which is to write down the actual password. The correct way to do it is simple, right down a password that is systematically wrong. If the password is 845, write down 734. If the password is EmerC@rE, write down eMERc2Re, or perhaps R,rV#tR (check your keyboard). simple cryptography works fine.
Sure, great idea. That way you'll have two post-it notes stuck on the monitor: * "password is 734 * "add 1 to each digit to get real password"
What actual threat model do you imagine anyway? Which danger model is more likely? (1) That a clinician forgets a password or the password sticky note convention and so care is delayed by several hours while it gets restored? (2) Or a new clinician comes to the shift and doesn't know the convention and care is delayed? (3) Or an electronic attacker tries to get into the medical systems via remote access? (4) Or an electronic attacker tries to get into the system via local access?
Your solution would guard against (4) at the cost of (1,2) and without impacting (3).
Read the article. It says "the health IT itself can undermine the central mission of the clinician: serving patients". Your idea
They pick a bench mark test, run it, profile the code, and optimize it to beat the test... The real test would be to record normal browsing habits or a large cross section of people, and then repeat exactly the same mouse clicks and key board input to various browsers and then check the battery endurance.
From the article: "Second, we examined the real-world energy telemetry from millions of Windows 10 devices."
We're not opposed to all this bullshit "everyone should code" crap because we're anti-social curmudgeons; it's because we all understand that it's just meant to try to flood the job market with cheap labor.
The effect of "everyone should code" is a citizenry more empowered to make sense of the data-driven world around them, to not just be consumers of media.
You want to sacrifice that social good so that your job market doesn't get flooded with cheap labor. So yes, you are a precisely an anti-social curmudgeon.
No it's not. Ken Thompson's work was beautiful and subtle - a compiler disguised all evidence of its backdoor even when you write code to search for these backdoors or when you compile the compiler itself.
If Ken Thompson had gone on stage to say "hay guys I made a compiler which inserts a call at the entrypoint of your program" -- well, that's trivial.
Twice a day for the past month I've been telling my Nest to use 68 as my preferred temperature, not 72. It still hasn't figured out that I prefer 68. "learning thermostat" indeed.
What I love most about web pages is you can "open link in new tab" (often) to make up for Poor ui or slow internet, or just to stack up a bunch of things to do in turn.
I believe it doesn't send *memory dumps*. It sends crash dumps, also called "mini-dumps" within Visual Studio. They don't have the heap. They include registers. They include callstacks, but I think these only include address pointers not the stackframes themselves (not sure). They include a list of all loaded DLLs/EXEs in the process along with the address at which they're loaded.
(I work at Microsoft, and have had to investigate the occasional crash-dum- to fix whatever bug caused it, and the dumps didn't have any heap, so it's always taken a lot of guesswork and detective work to figure out what the bug was based only on the callstack).
When you're unemployed you get some form of welfare. Then when you get a job, and get income from it, the amount of welfare decreases.
In the UK the amount of welfare decrease is equivalent to an 80% tax rate on people earning $0 - $10,000. (in terms of how much their net take-home money increases for every additional $ they earn).
Now I know that super-rich folks are disincentivized by having to pay tax above 40%. But I wonder if super-poor folks are also likewise disincentivized? [sarcasm]
Slashdot Mirror
OTHER THAN AS EXPRESSLY SET OUT IN THESE TERMS OR ADDITIONAL TERMS, NEITHER GOOGLE NOR ITS SUPPLIERS OR DISTRIBUTORS MAKE ANY SPECIFIC PROMISES ABOUT THE SERVICES. .... WE PROVIDE THE SERVICES "AS IS"
Maybe he'll sue on grounds other than "broken promise".
And there are lots of grounds for suing even when something is "as is". For instance, attractive nuisance (doesn't apply here); negligence (would have to establish duty, breach, causation, damages); defective product; that the terms in the TOS aren't enforceable; intentional infliction of emotional distress (would have to establish that Google's behavior was extreme, outrageous and caused harm).
I'm not evaluating the strength of any of these grounds. Just saying that the TOS isn't a blanket "off-the-hook" as your post suggests.
When I bought my house there were 40+ pages of documents that I had t sign at the end, for deed transfer I think.
I skimmed through them, noticed one term that looked wrong, pointed it out. They said "you're right! In our ten years of doing business no one has ever noticed this mistake before. I'll fix it up for you here and now."
For everyone who swore up and down that Windows 10 will never be a subscription and Microsoft will always stick with their old business model (pay once for the OS, additional support by subscription): hope the crow is tasty!
What? Who would have said that? Microsoft have been offering Windows by subscription for many years already.
The problem being nobody actually understood what 'full access' through Google's API actually does, or bothered to go look it up.
RTFM kids, you'll look a lot less stupid.
What is the "FM"?
I see a lot of google OAUTH scopes listed at https://developers.google.com/.... I don't think there is a "FM" which tells us how to map the poorly-phrased UI dialog to the actual OAUTH scopes. If the UI claims to be asking for "full access", which of those scopes do you think it's asking for? All of them? Including the scope "https://www.googleapis.com/auth/gmail.modify"?
I've not used Google OAUTH, but I have used Microsoft OAUTH where the scopes had very badly worded UIs, and I bet the same is true of Google.
For instance, if your app requests the Microsoft scope "wl.signin | wl.offline_access" then all it technically does is let your app use a Microsoft ID to sign into the app but without giving even one iota of access to any of your account information. However the way it's presented to the user is "This app wants to sign you in automatically and access your info anytime". My users (reasonably) thought this meant that my app could access any of their account details anytime, and a portion of them declined to grant permission.
In this Microsoft case I don't think anyone was being stupid, and no one should be expected to RTFM, and the fault lies squarely with the folks who design the UI for the Microsoft signin process. My hunch is that the same is true of Google's OAUTH too.
Not that I'm defending the shooting, but by now everyone knows what the police officer will want when they pull you over. Get your license out of your wallet and registration/insurance out of the glove compartment, and have them ready in your hands while the officer is walking towards your car.
Leave your hands in sight at all times, like on the steering wheel.
Those two things you've said are self-contradictory. If the police officer comes over, is the officer going to see you rummaging in your glovebox for your registration (and think you're reaching for a gun)? Or is the officer going to see you with your hands in sight at all times?
Well,a plane autopilot's only job is the boring "uneventful freeway" of the air, and the pilot has to take over in unexpected situations.
The normal phrase "I was on autopilot" is always used to describe subconscious activity that doesn't handle well the unexpected.
So yes, "autopilot" is exactly the right word for what tesla does today.
Once they start calling it "self driving", that'll be something different.
There may be situations where a landlord has a good reason to limit who is accessing and modifying the cable/wire infrastructure of a property
Curious -- what kind of reasons? What's a good reason for which a landlord would allow Comcast to come modify the cable infrastructure but not, say, Time Warner? I honestly can't think of any.
Do you really think at a certain point data will have every single possible scenario? There will always be edge cases that may make AI too dangerous to use ever.
Oh no! I just think they'll gather edge scenarios at 50x the rate at which Google gathers them.
Tesla didn't recorded anything. They don't have any hardware that would provided the data, i.e. laser radar system. They don't have enough connection bandwidth to transfer the data in real time. For autonomous driving, their system is dead (sometimes literaly) end from yesterday that will be replaced soon with better systems that will provide more advanced data anyway. You can't teach a pig to fly no matter how many million miles you will run with it.
It seems like for every incident they do somehow get detailed logs of what their sensors recorded. Sure it's not realtime, and sure it's not cases where the system performed fine. It feels like a variation of what ESR said -- "given enough eyes, all bugs are shallow". In this case Tesla is getting a load of real-world "bug reports" about their software.
You seem to be arguing that historical sensor reading data for a system with "X" sensors (and software developed for it) will be irrelevant for a system with "X+Y" sensors. That's a plausible assertion, although I'd bet against it.
The other main difference is that Tesla has logged data from 50 million miles of autopilot data from all over the world, while Google has logged data from 1.5 million miles mainly in the Bay area.
I think this gap will widen exponentially, and good enough AI for driving will come only through masses of data, so Tesla have a huge advantage.
How many good movies can you name that were styled after a sandbox game? Umm... erh ... well...
The Lego Movie. That was totally awesome. And it's the closest analog to Minecraft.
In my experience, all the hospitals do it the wrong way - which is to write down the actual password. The correct way to do it is simple, right down a password that is systematically wrong. If the password is 845, write down 734.
If the password is EmerC@rE, write down eMERc2Re, or perhaps R,rV#tR (check your keyboard). simple cryptography works fine.
Sure, great idea. That way you'll have two post-it notes stuck on the monitor:
* "password is 734
* "add 1 to each digit to get real password"
What actual threat model do you imagine anyway? Which danger model is more likely? (1) That a clinician forgets a password or the password sticky note convention and so care is delayed by several hours while it gets restored? (2) Or a new clinician comes to the shift and doesn't know the convention and care is delayed? (3) Or an electronic attacker tries to get into the medical systems via remote access? (4) Or an electronic attacker tries to get into the system via local access?
Your solution would guard against (4) at the cost of (1,2) and without impacting (3).
Read the article. It says "the health IT itself can undermine the central mission of the clinician: serving patients". Your idea
"There are three kinds of lies: lies, damn lies, and benchmarks." --- Jon "Maddog" Hall, Atlanta, GA, 1999
From the article: "we examined the real-world energy telemetry from millions of Windows 10 devices"
So it's statistics, not benchmarks.
They pick a bench mark test, run it, profile the code, and optimize it to beat the test... The real test would be to record normal browsing habits or a large cross section of people, and then repeat exactly the same mouse clicks and key board input to various browsers and then check the battery endurance.
From the article: "Second, we examined the real-world energy telemetry from millions of Windows 10 devices."
We're not opposed to all this bullshit "everyone should code" crap because we're anti-social curmudgeons; it's because we all understand that it's just meant to try to flood the job market with cheap labor.
The effect of "everyone should code" is a citizenry more empowered to make sense of the data-driven world around them, to not just be consumers of media.
You want to sacrifice that social good so that your job market doesn't get flooded with cheap labor. So yes, you are a precisely an anti-social curmudgeon.
Boy this is at the scale of the Ken Thompson attack. Compilers that insert backdoors
http://c2.com/cgi/wiki?TheKenT...
No it's not. Ken Thompson's work was beautiful and subtle - a compiler disguised all evidence of its backdoor even when you write code to search for these backdoors or when you compile the compiler itself.
If Ken Thompson had gone on stage to say "hay guys I made a compiler which inserts a call at the entrypoint of your program" -- well, that's trivial.
Twice a day for the past month I've been telling my Nest to use 68 as my preferred temperature, not 72. It still hasn't figured out that I prefer 68. "learning thermostat" indeed.
What I love most about web pages is you can "open link in new tab" (often) to make up for Poor ui or slow internet, or just to stack up a bunch of things to do in turn.
Almost no apps allow for this.
I would never remember the extra "I" before the $...
It took my a while to figure out a really secure password... but once I did, it's so secure I've been using it for everything ever since.
If anyone else wants to use it too, it's "may$in1a_pzy"
I believe it doesn't send *memory dumps*. It sends crash dumps, also called "mini-dumps" within Visual Studio. They don't have the heap. They include registers. They include callstacks, but I think these only include address pointers not the stackframes themselves (not sure). They include a list of all loaded DLLs/EXEs in the process along with the address at which they're loaded.
(I work at Microsoft, and have had to investigate the occasional crash-dum- to fix whatever bug caused it, and the dumps didn't have any heap, so it's always taken a lot of guesswork and detective work to figure out what the bug was based only on the callstack).
When you're unemployed you get some form of welfare. Then when you get a job, and get income from it, the amount of welfare decreases.
In the UK the amount of welfare decrease is equivalent to an 80% tax rate on people earning $0 - $10,000. (in terms of how much their net take-home money increases for every additional $ they earn).
Now I know that super-rich folks are disincentivized by having to pay tax above 40%. But I wonder if super-poor folks are also likewise disincentivized? [sarcasm]
hey, on this note, if you do decide that you can indeed copyright a string, then can I copywrite pi in base64?
Of course you can copyright a string. That's what a book is - a string.
No you can't copyright pi because it's NOT AN ORIGINAL WORK.
Notably, windows file explorer never used to allow file operations on >260 filepaths.
I wonder how the cost of high voltage DC compares to the cost of an oil pipeline?