I was working on the Google Slides team at the time this blog post was originally published back in 2014.
Slides and Doc are extremely closely related projects, sharing lots of code (and even sitting next to eachother, at the time at least).
Our entire team was impressed with the details of the operational transform protocols that the author was able to reverse engineer, and for the most part get correct. IIRC our engineering director ended up calling the guy up for a lunch.
Sending around protobufs encoded as JSON makes reverse engineering much easier than you might imagine. I can just imagine what the internal .proto files must look like - especially the arrangement/ordering of fields which tells you how the software design evolved. Two fields with tags next to eachother? They're probably part of the same feature and they were added by the same person as part of the same commit.
Just curious, how does Protobuf make it easier? Easier than Json? Protobuf doesn’t even include field names or readable descriptors - unless of course you are talking about reading client side JS
In that situation (let's say the boss finds his new protege or whatever) would you still have to go through the (in)famous invert a binary tree technical interviews?
I never understood why people advocate for job offers sans interviews for someone who has interesting projects. IMO any company allowing such practices opens itself up to corruption and nepotism.
I've worked for startups and even mid-sized publicly traded companies where managers with sufficient seniority were allowed to extend offers on a whim and it always resulted in friends of said employees being hired. Inevitably, entire teams and even business orgs would be filled with friends or fraternity brothers and their work performance would vary greatly.
No one likes interviews but it's crazy that I keep seeing HN users considering this an acceptable practice.
there's a difference between hiring people with a proven track record (especially in this industry, e.g. known projects through github) and hiring your nephew just because he's a great guy.
Although I do agree that knowing about people's projects doesn't say enough about the fit (e.g. teamwork). However, white board code reviews won't really help finding that out either, imo. Parent poster didn't want imply that the whole interview process should be circumvented, only the (or some of the) technical part - I agree.
I am against the principle of any individual within a company being able to extend offers at will without any interviews or input from others. A "proven track record" is often too vague and arbitrary a bar and this just lends way to allowing personal bias in hiring decisions. Having interesting experience, projects or an impressive github allows you to get your foot in the door and get to the interview stage. It should not circumvent the technical interviews.
I hire developers and researchers for my company and we are very selective in who we choose to interview (small company in a bleeding edge field). We only consider engineers with relevant, impressive expertise and academics with solid published papers. Still, many of those interviewed don't receive offers and it's not because we ask them to recite some esoteric solution to a riddle. We have called candidates in just because they have promising github projects related to our work, only for these individuals to completely flop when questioned about basic fundamentals. Our interviews were extremely lenient and informal in these cases and we gave multiple chances to some.
Given the history of Google Docs dating back to Google Wave with its architecture of Operational Transformations, this makes perfect sense and is a bit obvious if you know the history.
I always wonder if Google Wave was just ahead of its time. Why can't any email be the start of a collaborative document, and if you and the recipient happen to be online and available at the same time, turn it into a chat?
I mean, Google Wave was also very slow and unusable in practice as it was invite only in a way that meant even in my pretty tight knit circles of "people who all went to Google I/O almost every year" there was always at less than one person who didn't have access to it... I don't see how it possibly could have succeeded; it is as if they fundamentally didn't understand that the reason that worked for Gmail was because Gmail was just one option in a federated ecosystem, and so everyone already had email, but would never work for a real communication tool building an audience from scratch.
They also repeatedly said that Wave would be federated, but the official Wave instance never was. That and the only code they released (at least until the project was canned, AFAIK) was missing several features that seemed pretty core to the usage of the software.
I was CEO of a software company who sold an Outlook add-in product and did a lot of Outlook/Exchange consulting. I went to I/O every year as well, and toyed with the idea of making a better Exchange<-->Wave connector. Glad I didn't.
Also have a prototype for what at the time was an improved Outlook to Google Calendar sync (e.g. it maintained coloring by converting color categories in Outlook to Google subcalendars of matching colors) but was hesitant to productize it one reason being I wasn't sure if Google Calendar would live long enough to make it worthwhile.
I wonder if a reputation for prematurely killing their products is harming Google's ecosystem-building efforts.
Slack does not limit the number of people who can sign up for it. If Wave gave everyone using it infinite invites then it could have worked fine, but they did not.
Was Wave part of gapps though? Or did it predate all of that? Maybe it might have had a chance if you could have collaborated within an organization rather than only as individuals.
Edit to answer my own question, looks like the original G Suite was in August 2006, but at the time it was just GMail, Calendar, and Sites. Docs was added in early 2007. Wave was a thing under Google from 2009-2012, but was never part of G Suite.
If Google could integrate Gmail, Google Docs, and Chat to make this happen it would make a huge difference to me. I spent a lot of time collaborating on incoming and outgoing email with a combination of Docs and Slack. This also has the tendency to silo both the end-result and the discussion where that would be something useful to have in some sort of shared repository.
They both look really interesting but suffer from the same issue: top-down vs. bottom-up adoption. There’s no way I can convince everyone to choose a new system for email just to collaborate with me.
Because email runs on protocols, formats and implementations built decades ago and running everywhere. It's why it's so universal and reliable but also why new advancements can't really happen - unless everyone is on the same service using proprietary features.
I’m certain that advance can happen. Just look at Calendar invites. They certainly weren’t envisioned at the time that email, MIME, SMTP, etc were started. But calendar invitation were cleverly designed to work within email itself. I know many users who don’t even realize that when they create calendar events and invite colleagues at other companies to a meeting, that that is actually just going over email. The clients do a good job of obfuscating that fact.
This is going to open a huge can of worms when lawyers demand the document history for discovery. You think that the final contract, patent application, user manual, or product specification you wrote is what matters? When the lawyers, regulators, law enforcement, and litigious people want to get you, you'll have to defend every edit back to beginning of time.
"Yes, we know what the final contract says, but based on your edit on January 7, 2003, at 5:21 pm and 0.210403 microseconds, your real intent was ...". "And then on June 12, 2006, you took out some words that have a bearing on this lawsuit -- obviously you were trying to cover things up."
I was quite surprised to learn that during patent litigation for example, the history and changes made to your application do matter. I assumed that the final patent as issued is what matters and everything else is irrelevant. Well, lawyers have made it matter, and now things will be 10,000 times worse when they want to find something to argue.
So great, now we have to worry about how someone might interpret every single edit rather than the final document.
Version history isn’t exactly new in legal docs. IANAL but I’ve worked on redlining legal contract terms commercially.
Almost every legal (or otherwise collaborative) document has “track changes” enabled on its source document for the last 25+ years, which captures every keystroke in Word or WordPerfect.
I cannot recall there’s ever been a subpoena for the track changes source. It’s generally immaterial. Negotiation proceedings are not the contract, the contract is what was signed and both parties have a copy as paper, image, or PDF.
Computer forensics are often about determining whether a final image was altered after mutual acceptance. This is also why important documents get notarized.
This is why, when you start to discuss it in writing, you To line your in-house counsel into a new thread that you mark privileged and confidential. Discussions of legality and regulatory compliance are discussions you should have with the guidance of your lawyer, and it would be exceptionally rare for a court to be willing to break legal privilege.
How do you know you're doing something really funky? Even your lawyer doesn't want to put it in writing.
When there is ambiguity, can context during negotiation proceedings be bought as evidence to clarify?
Obviously no lawyer worth their salt is going to clarify ambiguity via email instead of redlining the contract with a change, but post-contract ambiguity can often be discovered.
You control-v a bunch of code from a copyrighted source. You then change all of the code semantics, syntax, etc.
While not your lawyer example, a very common example developers would follow while infringing on code. I can think the same for someone writing a manuscript or other large work of writing
Sure, until that feature is built into almost everything and it becomes mandatory to use it. Filing an income tax return? You must use this online system that captures every edit and every keystroke. There is no other way to file.
When people complain about lack of privacy when using credit cards and bank cards, would you dismiss it by saying, use something else -- just use cash? I could list a hundred things that you can no longer pay with cash.
Look, if you can assume that the legal system will start caring about specific edits along the way to the final draft, and you can assume that essentially all tools will start tracking the history of these changes, and you can assume that the trivial fix (copy paste the final version into a new document) will be underlined either technically or legally, then I can assume that Congress will change the law to make these inconsequential details no longer matter. (It's highly unlikely that Congress would actually do a useful thing, but then the sum total of all your assumptions was also highly unlikely, wasn't it?)
Has case law determined an outcome yet? I can’t think how in the world it would rule in favor of the plagiarist though.
Just more of a reason to write your document in notepad or on a collaborative system you control. You don’t control the hardware, then someone else can walk off with the software (or output of the software)
According to lawyer friends of mine, they do not use Google Docs for any official work because storing confidential client documents on somebody else's storage opens up serious liability issues. Plus Word is better at tracking management anyway.
It's crazy how vast and powerful databases of even the most simple things turn out to be. You just store characters and context information when someone types them, and this is the result.
Using this data alongside ML, you could do things such as:
- Identify people based upon their typing style easily, given so much data about them
- Find a lot of secrets that were accidentally pasted into document including passwords, keys, etc
- Try to model the emotions people were feeling as they typed things
I did not test it on a large group, but it worked pretty well for a group of ~8 styles and minimal data. I believe a deeper model with enough data could identify on a large scale through timing alone.
Have you noticed how, for example, you can identify a guitar player easily, no matter what guitar they're playing on?
When guitar players are first learning or are transcribing, they often slow the music down. If you slow it down enough, you can hear a pattern of the player slowing down and speeding up (behind and ahead of the beat). I believe that has a lot to do with that instant-identifiability, even though it is so hard to detect at speed.
sure and i can find out your real time location by hiring a PI to follow you around all day, but it's a lot cheaper and easier if i just pay google for it. plus i cant hire a PI to follow everyone around, there's a cost to that.
I’ve long wanted what seems like a simple feature in GDocs: right click and “show me who wrote this”. All the data is there, and can eventually be determined by inspecting the history, but it’s not well exposed.
Funny story, I was once in a company meeting and said something alone the lines of "blame is on X Engineer for that feature". Non technical product manager thought I was actually calling the guy out. Well sorta, but more technically.
Though, I suspect that's intended as a generalization of the various VCS options they support.
---
I do think it'd be good to move away from the negative connotation associated with blame. I want to know who to ask about some code, not who to blame for it breaking.
you can use the versions feature and enable the detailed view to see who wrote any character over time. not as easy as right click, but you can definitely do it.
>Everyone I’ve talked to about this has been surprised, and maybe a little unnerved, to discover that whenever they share a Google Doc with someone, they’re also sharing an extremely detailed record of them typing the thing.)
No shit. I'm stopping to share anything on Google docs now. Who knows what secrets are here somewhere ?
We've just made it a first class part of our workflow. Colleague tells me he's made a round of edits; I check the history to see what they are. Promotion committees also use edit history to validate whether "coauthors" really are.
Fun fact: when you do a "virtual on-site interview" (an oxymoron I know) at Google, the interviewer does get to see a playback of whatever the interviewee typed. There's a bar that allows you to select the time just like a movie playback UI.
It's an interview that would have been an onsite in non-pandemic times. In other words it means you're past the screens and you're now doing a full panel of interviews, possibly including members of your prospective team.
In hiring committees I've sat on, people for some reason had a lower bar for code that was written during a "phone screen" than during an "on-site", even when both were done with the same tech "stack" (phone call / Skype + coderpad or similar).
Maybe the name "virtual on-site" is supposed to convey to both interviewer and interviewee that "this is for serious".
Typically you only get one or two phone screen interviews at Google, so the bar should be much lower. The purpose of the phone screen is to see whether it's worth the time for onsite (now virtual onsite) interviews.
This may vary by hiring committee, but on mine we don't look at feedback from the phone screen interviews at all.
As a candidate, I will put in as much effort into phone screens (with real code pads) as the real interview.
As an interviewer, I will give a slight benefit to the doubt for “screens” because I understand some candidates don’t take it as seriously as the main interview.
It sounds like they're just recording the text you're typing and not the entire interview (video recording, conversation) but I could be wrong. If that is the case though, I doubt they'd need additional consent since it's implied that they're evaluating you based on the code you share with them anyways.
I use operational transformation (OT) for undo/redo and collaborate editing in an editor that I wrote (for) myself. Inspired by Scrimba I made it so I can "record" tutorials by adding time stamps to the OT undo/redo history. Then when replaying the tutorial/session (which is also voice annotated) you can write code as well while the record is playing thanks to the OT.
If it saves that much history I suppose in the future I'll be drafting my stuff outside Google docs and pasting it in, instead of drafting within Google docs.
I was more concerned about editing a doc privately, then sharing it, and then others being able to see all the keystrokes during the private edit time prior to sharing.
I would have hoped that it cuts off diffs/undos to a certain point in history.
It would be wise to support https when publishing content that may be security sensitive. Both OP's site and the site used for the extension run on http.
“We cannot judge either of the feelings or of the characters of men with perfect accuracy from their actions or their appearance in public; it is from their careless conversations, their half finished sentences, that we may hope with the greatest probability of success to discover their real characters.” - Maria Edgeworth
It's interesting to think about what is it about keystrokes that tend to make people worry about privacy. I don't think it's as simple as "they are storing a lot more data than I assumed". It can't just be a matter of degree. The reason must be broadly along the lines given in the Edgeworth quote.
I wonder if ‘journey data’ like this one is a better type of data to feed ML? Showing the corrections, improvements, etc. Any idea if someone tried this?
heh I maintain the timeslider code in Etherpad, it's actually really quite simple and there is a nice set of visual representation and auditing/diff plugins now available made by the community :)
I thought the post would address what they do with the changes from individual contributors and how they merge them and manage conflicts. It's been known for quite a while that Wave used OT, and if I recall correctly, some engineers there said that it would take them as long to implement it again [I think two years] in discussions about CRDT/OT, etc.
Storing keystrokes used to make a document reminds of a comparison between personal data and toxic asbestos.
Storing and indexing keystrokes is unique, and it might even be useful, yes. However, this does not at all seem safe to store without user knowledge for every document created. What could possibly go wrong....
It's just super interesting that the granular record is persistent and can be replayed years later. Pretty non-obvious to me, and something I usually pay attention to!
The event log of key strokes is the source of truth for the entire document editing system, I can't think of a reason why one can't rewrite history after a certain time, except to say that this requirement will probably impact a lot of sub-systems from storage to UI, that now have to keep working under historical revisionism. I certainly haven't bothered doing that.
It's probably one of those situations where you'd write a "Diversion Report" for the security team where you talk about limited assets at rist and a huge investment in engineering resources.
In the PDF editor I use there’s an option called “Flatten”.
Storing the change vector is essential for collaborative editing in the moment. But the UI should highlight a Flatten feature as part of explicit Saving or Sharing actions.
You definitely don't need that level of granular detail from 10 years ago. There is no use-case for reproducing every keystroke. Major edits would be fine after literally only after a major save, or a day has passed.
FYI - this is a kind of 'biometric' leakage eh.
Your typing style is probably as unique as your finger print.
It's not shockingly bad, but probably something, under thoughtful review, they should take care of.
Edit: by 'no use case' I mean, no use case for long term history. Obviously there's a good use case for 'very short term' individual keystrokes.
Also Edit: the answer to this issue is not 'Don't worry about it, it's a low risk problem'. This is the 'slow boil' SV way of thinking that is seemingly benign, but not acceptable in the long run. The answer is: don't store personal data that is unnecessary. It's that simple. It doesn't diminish the product a single bit.
Considering Google doesn't really support anonymous accounts very well, and anyway only the owner and at most collaborators can see version history, the idea that there's a practical attack here seems pretty far-fetched.
To be fair there is also: share, new, open, make a copy, email, download, make available offline, rename, move, make a shortcut in drive, move to trash, publish to the web, document details, language, page setup, and print.
That is just for the file menu. There are 7 other menus each with their own long list of options.
IIRC the version history only shows snapshots hours apart. Not the sensitive info some of the millions of users have accidentally pasted in and deleted within seconds — which now everyone they share edit access with years later can see, as well as Alphabet and the various alphabet-soup agencies of the government they share a revolving door with.
I imagine the next chapter in this story will be someone scraping the web for public google doc links, reconstructing the keystroke timeline, and training a NN with the timeline in order to break captchas or other keystroke-pattern-based identification systems.
I believe other apps like Microsoft office 365 word, Airtable, Quip, Smartsheet etc. - are very similar in frontend architecture to Google Sheets. So, I was looking if there's a common engine or approach to handle UI
For what it's worth, you can make a copy with "File > Make a copy" and delete the edited doc. The copy will not preserve history. You can verify this yourself - after making the copy, the only thing in the copied doc's revision history is a single change that adds the entire document's contents.
This shit is the reason why we use LibreOffice online, running on my own server when an "office" thing is required. I can access it from all over the 'net, documents only leave my network when I want them to, nobody gets to data-mine them, it has supported nearly everything I've thrown at it.
This sh*t is the reason that I carve my words into clay tablets using LinearB and have an army of assistants to translate and upload them. The only downside to this is that the change history is a bit of a mess until it's cleaned up and uploaded.
Whilst this is on the front of hackernews there is one element to this that intrigues me...And that's how this is compliant with the GDPR?
For example, as far as I am aware this isn't information that is included in Google Takeout, nor is it included in any SAR that you may ask for. There is no ability to have a list of comments you've made and a choice to delete them. Even if you delete your account I am not sure these pointers are actually removed from the database.
Google collects so much data across so many vast areas I am not sure how they can ever be truly GDPR compliant and in accordance with the law as it's written.
For example, how do I delete my Google Fit data? It is seemingly impossible, of course this is where you have to ask them to. How about deleting every single edit history across all of my documents, or a specific edit in a specific document? Will they be able to remove that unique entry in the edit history?
I do know they store edit history for an indefinite period of time, I've accessed documents 6 years old (never edited again, unopened for many years) and the edit history is still perfectly intact. I wonder how many PB's of data Google has of pure and utter data-rot, and why they don't have systems in place to clean that up (especially old, inactive data like document comments or revision history).
I imagine every single record Google creates and logs must be liable to the GDPR, so of the trillions of data points they have on their systems it must be a pain to try and ensure any of them can be modified if required to do so.
This feature most likely predates the GDPR and it's just an oversight that a toggle hasn't been implemented for it.
However, Google has demonstrated their bad faith and unwillingness to comply with the GDPR with their non-compliant consent popup so I would be very surprised if they suddenly decide to spend resources on modifying this feature to make it compliant.
I don't know that I agree. If you magnified the page to fill the screen you would see too few lines at a time. If you reflowed the text to fill the screen it would violate common typographical/usability wisdom [0] and no longer resemble the finished product.
Also, just realized that screencap isn't even Google Docs.
That's their history extension, not google docs. You can zoom in on documents in Google Docs (or any website in your browser) as much as you want. Also fixed width for text improves readability.
Uniformity is an entirely different issue. All browsers can zoom in, regardless of the CSS, but how they implement it is different.
Safari on mobile devices uses a visual zoom which is like scaling up an image, while desktop browsers usually scale up CSS units and reflow the layout with the bigger dimensions.
or users can use a magnifying glass, if they own one
it is not true that all browsers can zoom in. there are some cases, e.g. mobile platform with stock browser, where CSS dictates no zoom and the browser honours this and therefore cannot zoom
that might be due to browser implementation but ultimately CSS dictates it
I have no interest in mobile Safari but its non-vector based zoom sounds useless, and desktop zooming is unreliable
Slides and Doc are extremely closely related projects, sharing lots of code (and even sitting next to eachother, at the time at least).
Our entire team was impressed with the details of the operational transform protocols that the author was able to reverse engineer, and for the most part get correct. IIRC our engineering director ended up calling the guy up for a lunch.