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.
No worries - I didn't mean to imply that you copied me, but just to point out persistent this problem has been, and to underline the fact that Google doesn't consider it an issue.
Google doesn't care about any of this, otherwise it would have been fixed in 2010. But if you really want to add them their e-mail addresses are:
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.
Ah yes, fun when your CEO's email address is the same as the name of a product. I worked on +Pages, and we'd constantly be adding +page@google.com to discussions in Google Docs by mistake. ^_^
I wouldn't be surprised if there are hardcoded rules that guard senior Google execs against such inadvertent (or by design, take your pick) communications from hoi polloi that uses their products.
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
Just in case anybody took parent seriously, you shouldn't do this for the same reason you shouldn't flood their email inboxes about this. They will just mark your calendar invitation as spam.
Privacy, where it exists, creates impedance in Google's cash flow because it requires designing for some n sigma tail where n does not entail statistical significance and the case analysis must be very fine grained.
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.
Do you have a source for this? I've worked on user data and privacy-related stuff (I work on Maps, not Calendar) and everyone involved took it extremely seriously. We sent PMs back to the drawing board more than once when we found edge cases with potential privacy issues.
Google's single identity policy is an obvious example.
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.
Yes, but how does this particular privacy leak benefit Google? Google wants to have all your information themselves. Why would they want to give that info to your boss?
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 simply one expression of the corporate protocols in which privacy does not exist. It's not a bug. It's not an honest mistake. It is an implementation detail of a higher level abstraction.
Of Course this isn't a bug- It's a feature. the only problem is that there isn't a confirmation screen when it detects that you have put a person's email address in the incorrect spot. All that is needed is for a popup to ask "Would you like to send this event to email@example.com?".
That is one of the problems I see more and more often the last days:
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 ...
> 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!
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.
Yes, and people that insist steering their car themselves will be punished by public opinion. They will be treated nearly the same way as Muslim looking people in US airports directly after 9/11.
I hate PHP as a language, I really do, but bugs can happen in any language (eg C++ bugs are exploited all the time to gain machine access). Plus when you get a platform as popular as Wordpress, you'll find that it will constantly be under attack from 'hackers' who bank on people being slow to update their plugins.
Something like this will happen with any bad written code. It's not PHP related. But you are right, PHP makes it easy to write bad code. There's no "security" layer build in. I hope ownCloud gets public enought to be secure. If more eyes look at the source they will hopfully do a good job.
well, you had a problem with a badly written wordpress plugin ,not PHP. or are you saying PHP is insecure and no insecure code can be written in other plateforms ? for a project to be popular amongs developers and hobbyists , it has to be written in PHP, because PHP is easy to deploy even if you dont know PHP.
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.
> you had a problem with a badly written wordpress plugin
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.
* > > you had a problem with a badly written wordpress plugin
> The plugin is top 10 popular one*
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.
I haven't tried it since the previous version, but syncing a few directories with thousands of small files completely brought owncloud to its knees.
The type of database used didn't matter, the syncing just started taking longer and longer, and because it hadn't started an auto sync in the last 10 (I think it's default time is) minutes, it would start another and essentially never be able to finish attempting to sync.
Apart from that issue, I thought it was quite good, will have to give it another try.
It changes nothing but it is a fact. The original ancestor of this thread was put off Owncloud by the fact it was PHP and Pydia was offered as an alternative. The name suggest at least to me that it would be Python based.
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++.
> 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)
The worst thing about things like this happening is the feeling of helplessness when you can't reach anyone in the company or when they just say "it's not a problem".
This seems like a business opportunity -- come up with a steady stream of "security issues," then use the resulting access to provide paid customer service for GOOG.
Well, it takes me approx. 1 minute to have a MS rep chatting with me when I have problems. Even when paying Google, it's impossible to get answers quick. And often the answers are just templates until you have bothered them enough to give you an actual reply.
this is a feature. it's actually pretty awesome for setting up quick meetings. It's a function of the "Quick add" feature that carries over into the title of the event: https://support.google.com/calendar/answer/36604?hl=en
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.
Ugh, I understand that it can be useful for some people, but I find natural language parsing of calendar events intrusive and annoying.
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.
but you can create an event from the calendar interface prior to going into the event interface. from the calendar interface, it only gives you the option of creating a title. so i can put meet with name@email.com and create the event. that's it.
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.
> Normally, once you show someone how it works and explain that it isn't likely to change, they adapt.
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.
This is not a "private information leak." It's expected behaviour. Entering information in that field to create a new event results in Google Calendar parsing your information as best as it can, to automatically set things like the date, time, event description and of course, the participants (the apparent privacy leak here.)
Why then, does a notification dialogue box pop up when you enter the information on the calendar overview page?
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?
If you're aware of the feature, it's not a privacy leak. If you aren't, it could be very damaging.
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.
Personally I kinda wish we could use different terminology for this. When the phrase "leak private information" is used, I think of Target losing my credit card info. In this case a more accurate title would be "Google Calendar Sometimes Sends Emails on Your Behalf which You May Or May Not Want." Granted this title sucks and is no where near any kind of quality link bait.
I'm gradually stopping using all of google's services. One by one they either turn out to have "features" like this, or they "improve" them into being horrible. There isn't much left I use any more. And I used to like google a lot... Times change
Theres an option in your settings for google calendar that is something along the lines of "Automatically add invitations to Calendar" that you can turn off, and I think it will fix that problem for you.
I'm going to take a stab here and say that "Automatically add invitations to my calendar" being set to yes is what allows you to be on the receiving end of this. Can someone try turning that setting off in the gear menu and repeating this?
It would at least stop spammers (and people on HN from inviting execs to reminders about this).
Google does work extremely hard trying to protect the privacy of its users. Yes, we might miss the boat sometimes but let's not make blanket statements like yours.
User privacy against other people? I actually mildly agree, but no more than any other company.
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.
Would you be so kind and provide your definition of "privacy"?
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"?
I am not looking for a debate here but your points are related to Google's algorithms analyzing user data. Google developers do not have access to that data and Google does not reveal data to anyone. Yes, I consider our handling of this data a success of our privacy engineers.
Thanks for the answer. I understand that times have changed and that revealing that you're from Google is not as fun as it used to be.
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.
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.
Additionally, when the dust settles and people figure out what's really going on in all those data-collection companies, we need clear regulations what kind of data may be collected, how it is used and when it must be deleted.
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.
This reminds me of the interesting security implementation in Netscape Calendar. Among the interesting security practices:
- 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.
I discovered this by accident some time ago as well but I've always appreciated the convenience - when I add an event using the Quick Add dialog, it's very useful for me to be able to say "Movie Night with alice@example.com" and have it show up on Alice's calendar automatically. I use it all the time at work and at home and it saves me time from having to go to the dedicated event creation page to add people.
I don't think anyone is arguing the potential usefulness of the feature. It'd just be nice to know when its going to happen and have an alert box verifying that you actually wanted to add the user to the event. The alert box could even have an "Always do this" option.
A good friend told me once: " the moment you enter info in an electronic device, you can assume it's public ".
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.
That is good advice. Let's see a change to all the peivacy policies so it is made clearer.
"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.
I've had bad experiences with this "feature" lately too - scammers can pop notifications into my phone simply by "inviting" me to events. I have no idea that anything is afoot until my phone pings me the notification.
Right. So you write "Tell Phil at example dot org he's a jerk," or "Tell phil, example, org he's a jerk," or something else that makes sense to humans but not machines.
That's terrible UX though. The point of using a computer is to make things easier - at least on the first try the program needs to ask you if you wish to enable automated invites (it could offer the option to "enable automated invites for only this address" too).
Indeed it's awful. I just thought it was ironic that email obfuscation, a tactic used against malicious address-harvesting programs, would also be useful against "helpful" obnoxiousness.
It's evidently not 'expected' behaviour from the point of view of the user. Just because you happen to put an email address in the title of a calendar event doesn't imply that I expect the software to go and send messages on my behalf.
A good UI would make it explicitly clear by highlighting the email address and/or by auto adding an explicit entry to the guest list.
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.
When the user gets unexpected behaviour doing something that many believe to be reasonable, telling them they're doing it wrong is really bad user interaction.
You can't change the behaviour of users, but you can make your software easier to use and more predictable in its behaviour.
You know what, reading all your desperate posts is very disturbing. Even Google Now knows to ask before auto-doing shit, but you sit here with some stupid surgeon-like "I can do no wrong" attitude.
Generally, I thought Google hired smarter people than you seem to be, so possibly you're some sort of false-flag bullshit.
It's mine, I just signed up to join the discussion, but evidently new users get rate-limited to only a few comments, so I've incremented the username by 1 to indicate it's still me.
The rate limiting exists for a reason. It is a bit arrogant of you to assume that your comments are worty of evadin site controls.
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.)
I would guess rabid fan, or maybe Google employee off the meter, who's about to get in trouble. Google's HN gardening is rather more sophisticated than this, but it does leave signals.
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.