Google Calendar Unexpectedly Leaks Private Information
shkspr.mobi
shkspr.mobi
Even the titles are similar: this one's called "Another Google Privacy Flaw"; mine was called "Another Google Privacy Disaster Brewing". So people have been complaining about this since at least 2010, and Google by now has pretty firmly established that they don't care.
Although I did search for information about this issue, I didn't come across your blog.
I'll update mine with a link to yours.
T
A whitelist wouldn't work, because these people need to be contacted from the outside, from people with gmail addresses (usually goes through a secretary though)
A dedicated (unfiltered) internal email sounds more likely, or just routing directly google.com to google.com addresses.
But then again this is google and maybe internally it's only Hangouts
vicg@google.com page@google.com
The calendar is going to be replaced by Timely, the next generation version (more feature-rich then the current one) Bigtop will replace the GMail interface.
By the way, I'm adopting https://code.google.com/p/j2objc/ ASAP -- yesterday, if it were possible. I was just contemplating writing my own C++/jni bridge but I'll take what already works, especially if it's being battle-tested by Google. :)
Edit: And with bugs like https://code.google.com/p/j2objc/issues/detail?id=224 I'm considering changing my mind. My Java code isn't that great either, and a few classes with JNI might go a long way compared to hacking together ObjC from Java code. The hard part that neither directly addresses is how to integrate Gradle-powered flavours and build types with Xcode/iOS targets and simple macro keywords. Sharing language files, string/config values and some assets... all seem project-specific at this point and not very well generalized.
Google doesn't have a category labeled "private" information". It never has and creating one is not planned. Privacy is not amenable to computer science. It is a social concept not a technical one. The closest technical concern is security. It scales and so that is where Google devotes resources.
As far as Google is concerned: All your bit are belong to us.
This sounds like somebody being really clever and whipping up a fancy feature, but forgetting to finish it with proper meeting requests and a freaking confirmation box and whatnot.
The idea itself is good - check for email addresses in meeting information and tying those to a Google account as invites. The problem is that the user isn't asked.
This is why it's not a privacy leak. "Privacy" has no meaning when the context is Google. It only has meaning outside their operations.
Sharing that Google identity with other websites when that identity is logged into Google is a less obvious one.
Analytics, cookies, personalized search results, etc. take it to Google's very core.
Driving around collecting WiFi data, storing WiFi passwords, reading documents via Docs and email via Gmail, and just plain crawling the web don't embody any common language notion of privacy.
Instead security stands in for it. Two factor authentication for a Google account is an example. It keeps a person's account secure but does not enhance privacy because Google will still share and slice and analyze everything that can possibly be associated with that account.
What does this mean?
Applications try to be extra-clever (more clever than their users) and think 2 steps further ... thus doing more than the users said.
So in my opinion, it is not only a privacy problem, but a problem of our "computing-" era. Applications get more and more clever, but in the effect they become extra-stupid, not doing what the user really wants, but doing what the programmer thought (or worse, some weird AI thought) could be right to do now.
I think, the reason is, that somehow applications must more and more show that they are "better" than just simple eMail, or just simple groupware or just a simple (you name it), as it existed before and as thousands exists as open source apps. The way it goes, is adding some "extra benefit" (same as in the food area) to the applications. But sometimes the extra benefit plainly backfires.
That's also the reason, I shiver when I think that the car industry wants cars that more and more take over control. That will become a big mess!
I also will reduce my usage of Google products, because it becomes more and more "you have to do it the Google-way" products and I must say, that e.g. Gmail has worsen it's user experience over time ...
It's only a matter of time before any traffic infraction anywhere results in an automatic debit from your bank account, and then Google lets everyone know, with a sad-face icon next to your name.
I run a wordpress site for 3 years, and one day a hacker took my site over with a bug from a plugin.
By the way, most CMSes on other plateforms assume you know the language , PHP CMSes dont, so maybe there is some effort to be made on these plateform to make thing easier or write better docs.
Wordpress would not be popular if it was in Python,Ruby or Java. Anyway the issue is with Wordpress plugin architecture , not PHP.
A clean plugin architecture would require some kind of DSL instead of plain PHP.
The plugin is top 10 popular one
> because PHP is easy to deploy even if you dont know PHP.
Wordpress has clean URL, but under the hood many .php files are directly accessible via URL, so hacker found a exploit, crafted a parameter aginst one particular .php, and got in.
The solution? Limit URL entry to only one .php file (like index.php), more rewrite configs and mod_security. So you lost the benefit of copy-to-update, it becomes just as hard like other language/frameworks.
As ownCloud community grows, I think this problem will surf again and it will end up like many PHP forum/CMS today. You can put up a usable site very quickly, but once or few months you have to patch the system, and many plugins you need most are abandon-ware.
Popular !== Good (where in this case good is in the context of being well written)
> so hacker found a exploit, crafted a parameter aginst one particular .php, and got in
That could happen with almost any laguage/framework though. While PHP makes it easy to write bad code (as do other options) it doesn't make it impossible to write secure code and you can't blame PHP and/or Wordpress for every bad plugin out there, even the massively popular ones.
It is though.
With regards to ownCloud, that is PHP by the way.
Though I do also run ownCloud for automatic photo uploads from my phone
Now whether the PHP should put us off is a separate question. I have probably unfair doubts about the quality of things developed in PHP based worrying about the sort of people who would choose it when they have a free choice (see fractal of bad design post). However I personally don't want to learn PHP so I would prefer something in Python, Rails or possibly even Node (I've a feeling that I'm going to need to learn Javascript one day), Java, C or C+++ so that the barrier to me tinkering/fixing is lower.
> The original ancestor of this thread was put off Owncloud by the fact it was PHP and Pydia was offered as an alternative.
No, I said I preferred Pydio over ownCloud. You added the subtext to my post.
> The name suggest at least to me that it would be Python based.
Only if you place too much emphasis on naming conventions. Names are in fact just arbitrary labels, thus not everything that begins with "py" has to be written in Python.
> Now whether the PHP should put us off is a separate question. I have probably unfair doubts about the quality of things developed in PHP based worrying about the sort of people who would choose it when they have a free choice (see fractal of bad design post).
I'm aware of the Fractal Of Bad Design blog post and you're using that to justify your conclusion that 2+2=5. Just because a language might be -in our opinion- complete garbage to develop in, it doesn't mean all code developed in that language is garbage. And you're also making the assumption that all developers choose PHP because it's easy; where as many of these projects are actually written in PHP because it makes it easier for end users to deploy.
> C or C+++ so that the barrier to me tinkering/fixing is lower.
If you think writing a web application in C or C++ (two pluses) lowers the barrier of things that can go wrong or the amount of tinkering you'd need to do, then you clearly don't know what you're talking about. Sorry, but that last part just struck me as the stupidest thing I've read in a long time.
Most computer software named pySOMETHING is Python but I didn't assume and went and looked in the repo.
I said that my feelings about code written in PHP were unfair and you are right that ease of deployment is a valid reason to develop in it. I did not say that all code developed in it or developers for it are garbage but I do treat it as a slight warning flag. The big thing is that I don't want to learn enough to be working around gotchas in the language.
Yes C or C++ aren't the obvious choice for a web framework and would probably put me off to some extent but I am sufficiently familiar with them to evaluate how clean the code is and tinker here or there if necessary. Of languages that I don't currently know well that I might be prepared to learn some more to tinker are the functional programming languages (Scala, Haskell, ML) I might be interested in anyway or JS/Node.
In terms of the stupidity of using a C/C++ based web framework Apache can probably be used as a basic web framework and I've heard about people using Postgres to do the templating not just managing the data so it isn't implausible to use C/C++.
That's ok, we've all done similar things :)
> Most computer software named pySOMETHING is Python but I didn't assume and went and looked in the repo.
This isn't named 'pySomething', this is named 'Pysomething'. It's not camel cased like a lot of python software is.
>I said that my feelings about code written in PHP were unfair and you are right that ease of deployment is a valid reason to develop in it. I did not say that all code developed in it or developers for it are garbage but I do treat it as a slight warning flag. The big thing is that I don't want to learn enough to be working around gotchas in the language.
When you're rolling out software that's accessible to the world via the web, then all languages will have their "gotchas" which you need to work around. Even C++ (in fact especially C++ since it's prone to buffer overflows and that's a pretty common attack vector for remote code execution)
> In terms of the stupidity of using a C/C++ based web framework Apache can probably be used as a basic web framework and I've heard about people using Postgres to do the templating not just managing the data so it isn't implausible to use C/C++.
Apache is only the web server, a web framework would consist of the tools required to build dynamic web pages (including the templating you mentioned in Postgres, but not just limited to), parse the HTTP request data (which Apache does do) and connect to the db. This is where things like CGI come in to play, but that's massively slow. Other languages have their own C++ hooks that compile into Apache (perl -> mod_perl, Python -> mod_python, etc) so they can provide a webframe work while tying closely with the Apache web server, but Apache on it's own wouldn't give you enough tools to provide a web framework.
In addition to that, you don't want to offload your templating to your database because that will be slow and will cripple your site. In fact most sites are built around minimizing DB queries rather than thrashing the database. This is why templates are cached (in fact whole pages are where possible) and even db lookups are cached with tools like memcache.
So even ignoring the fact that you're missing a whole stack of essential frameworks to build modern web applications, you're also setting yourself up for building a slower and buggier site than most of the PHP sites are that's already online.
If you really want to develop sites in a C/C++-like language, then you're much better off developing in Java, Go (lang) or C#. But honestly, trying to build a pure C++ website would cause you more problems than if you developed in PHP.
I'm sure you're very adept in C++, I'm not trying to dismiss your abilities here, but I genuinely post from experience as I've developed in about a dozen different languages, build websites and manages web servers for a living. Like yourself, I've spent a lot of time in C/C++ over the years and even I wouldn't dream of building a website in either of those languages (in fact since my work as drifted more towards web and sys admins roles, I've found I rarely touch C++ these days)
Apart from that issue, I thought it was quite good, will have to give it another try.
The security team is very responsive but for normal users there is no way to communicate with Google.
https://news.ycombinator.com/threads?id=ritikk
https://news.ycombinator.com/threads?id=ritikk2
https://news.ycombinator.com/threads?id=ritikk3
https://news.ycombinator.com/threads?id=ritikk4
(Should I add the 5th link or wait for him to create that ID as well?)
Edit: I am very familiar with Google's products, having helped many businesses move to Google Apps through the years. "Features" like this often surprise users and it is not unusual to get negative reactions. Normally, once you show someone how it works and explain that it isn't likely to change, they adapt.
99% of the time it ends up parsing a field incorrectly, and if I wanted to set a field it's on the form anyway, so why bother? In this case, why parse out an email address and send them an invite when there's an "invite" text box on the same page?
If the only way to set the time, date and invite list was to have the subject line get parsed, it would be obvious that this sort of thing will occur.
Honestly, to me this is a solution in search of a problem.
Google Calendar should TOTALLY notify you you are adding someone to the event and ask if you want to send an invite. Also, if you are in the events interface and add someone's email to the title, it should add that person to the guest list on the fly. It should do these things, but it doesn't. I think that is the root of the complaint, not the feature itself.
Soon we'll read reports of pipes bursting and apartments flooding because a Nest switched off the heating during winter after a Google calendar user added an event named "Feature freeze on home delivery project". Of course people will adapt and simply stop using temperature related keywords in their event titles?
My point being: Users shouldn't need to adapt to unexpected features. If such features exist, they are implemented badly or shouldn't exist in the first place. That's Interaction Design 101.
It would have been nice if the first time the Calendar parsed and sent emails on behalf of a user, it would ask if this is what they wanted. It doesn't have to bug them ever again, but that's a single instance of training that would minimize confusion.
'Email alice@example.com' does not match this spec.
Evidently, someone thought it was a good idea to warn there that an invite was going to be sent. So why does no warning pop up when you're in the "Edit Event" view?
There's a discrepancy here.
See my video in the blog https://www.youtube.com/watch?v=ZqjYb6eiMWE
It would at least stop spammers (and people on HN from inviting execs to reminders about this).
They would need to start protecting it first.
D: I work for Google.
The first thing that comes to mind is how much information about users Google itself stores and processes. This happened earlier and faster than people learned and understood the consequences of.
The next thing would be how the real name policy can make it difficult to keep someones Youtube-habits separated from a gmail/g+ account.
For you, do these two concerns fall under the term "privacy", or how do you reconcile all of that with your claim "protect the privacy of the users"?
The distinction you seem to be making between data that Google has and data that is "revealed to anyone" is misleading in my opinion. No matter who has the data, "privacy" is concerned.
Also I need to call you out on your blanket statements that Google developers have no access to that data (clearly, some would, as part of their jobs, also [1]), and that data is not revealed to anyone (seriously?). As of January 2014, this position is not defensible and you might have to face a more nuanced, and possibly inconvenient reality.
http://gawker.com/5637234/gcreep-google-engineer-stalked-tee...
The reference you point out was a one-off event from 2010 though, and a lot of our systems and checks have developed in the subsequent years to prevent a recurrence.
I'll concede the point about my blanket statement especially when talking about NSA and Government espionage though. All I can say is Google does fight in courts against that. I wish I had a good way to stop spying completely. All we can do is continue to make our encryption stronger.
The data, properly analyzed, represents an immense power and has to be transparent and under democratic control. In the EU the first steps go into this direction already.
User privacy against the NSA? No. Any company with ethics would have gone public with PRISM.
User privacy against google's analytics and targeted advertising? Definitely not. Users are the product as far as google is concerned. Why else would they have privacy options shrink monthly, close well-used and liked services like Reader (disclosure: I never used Reader), and spend so much time forcing people into google+ against their wishes? Combine that with the latest anti-privacy features in Android 4.4 and google's creeping "you must use your real name" and it's about as far from privacy as you can get.
- the server sends the (obscured) password to the client, so the client can check it
- if you want to look at another person's calendar, the server will send you the person's entire calendar, with the 'public/private' flag of each entry. It's up to the client to decide whether to show the user each entry.
- If you click on another person's private entry, the calendar data was copied to the clipboard. Paste it somewhere to view the details.
It was in response to me getting a pic of him wearing red thongs (dont' ask), but the point stands in regards to Google, any email account, your PC, your phone, and everything else.
"Anything you enter might be leaked. We might not warn you before we leak your information. We have complex confusing interactions between your accounts on all our services, and we hide the settings pages, but if any information is lealed then LOL that's your fault".
I kind of feel sorry for Google here - it's the 21st centuary and people are still persecuted for their sex or sexual preference. Part of the outrage is misplaced here - why the hell should she feel the need to hide such a fundamental aspect of herself from her colleagues?
But then again, who cares what the reason was? She wasn't trolling or abusive or trying to male the Internet a worse place, so let her use whatever name she wants and stop linking everything together.
There are much better ways of doing unified accounts that the mess that Google has given us.
Hopefully it should make it a lot more obvious to users when a meeting invitation is about to be sent.
(If you were being sarcastic, I rescind my comment)
That is expected behaviour, email address in reminders applies coordination. It's basically parsing your command correctly 'email this address'.
Second, the zdnet post you link to towards the end is full of inaccuracies:
A proper way to do it is, Title: "Email Alice", Description: "alice@example.com".
You can't change the behaviour of users, but you can make your software easier to use and more predictable in its behaviour.
At present there's no way to predict the behavior until after the fact. Something with that much consequence (sending an email to an unintended recipient) should never be done silently. By all means take the initiative with autofill etc, but the user should have the final say.
If the supposed design revolution within Google (http://www.fastcodesign.com/3016268/google-the-redesign) isn't just for show, the Calendar team (assuming there even is an ongoing team) clearly hasn't been touched by it and that ought to be corrected.
Generally, I thought Google hired smarter people than you seem to be, so possibly you're some sort of false-flag bullshit.
Except the "3" at the end, their pseudonym is identical to yours. Here on HN people do not like fake accounts.
And is it actual rate limiting? Try clicking the [link] url, whic should give you a reply text box.
Disclosing company affiliations is polite.
Not making comments in public fora, but letting company spokespeople do it, is a practice I dislike but which I understand having seen the mess you've made with your comments.
The violet blue article is lousy. If there are errors it should be easy enough to find corrections. Take the time to do it properly - find the sources, pull out relevant quotes, build the post. Put that as a blog post and get hits, or put it as an answer in the thread and get upvotes.
As a user, I would never have guessed that Calendar would do this. It frightens me in much the same ways that Buzz did. (And Buzz did leak some data that I considered very private.)
Google employee, or rabid google fan? I can't decide.