I reverse engineered Google Docs to play back any document's keystrokes (2014) | Hacker News Reader

I reverse engineered Google Docs to play back any document's keystrokes (2014)

features.jsomers.net

413 pointsflurly140 comments

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.

Edit: u meant encoded as Json - never mind.

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

Not easier than JSON, but it's much easier than reversing some C++ structs that some webassembly based application might send over the wire...

Messages and submessages and arrays make figuring out what data is what very easy for the most part.

Just curious - Did you guys hire that person to work for Google? or let them go just with a lunch?

You're assuming the person would want to work at Google.

And you're assuming he wouldn't.

Sometimes these chats are just good for network building and professional courtesy. They don’t need to have a direct outcome.

The eng director may get some cool ideas from talking to him. The guy might get cool ideas from talking to the eng director. It’s also a free lunch.

This guy may want a job at Google in 2 years. He can then email the eng director for a referral.

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?

Yes.

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.

The guy writes for the New Yorker and the Atlantic, doubt he would be willing to work at Google.

Both work for employers that depend on ad sales in order to survive.

Yes, and both work for employers incorporated in the United States. What is your point?

He's active on HN as well, his username is jsomers. He made an interesting visualization a couple of days ago and submitted the link.

https://observablehq.com/@jsomers/we-need-more-tiny-knowledg...

I think he currently works at Jane Street https://blog.janestreet.com/author/jsomers/

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.

https://en.wikipedia.org/wiki/Operational_transformation

The new alternative to this approach for collaborative editing (and large scale distributed database concurrency without locks) are CRDTs: https://en.wikipedia.org/wiki/Conflict-free_replicated_data_...

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 think Google Wave proved that UX confusion was a bigger hurdle than the tech for collaborative editing.

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.

But groups are on Slack, etc, which everyone doesn't have.

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.

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.

> I wasn't sure if Google Calendar would live long enough to make it worthwhile.

I didn’t use google calendar for repeating yearly appointments for almost a decade because I thought the same thing. Glad to know I wasn’t alone!

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.

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.

Have you looked at missiveapp.com and frontapp.com ?

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.

Microsoft teams does this which surprised me. I sent someone an excel file as an attachment and they were able to edit the file inline

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.

Then use something else. That doesn’t mean those of us who find such a feature valuable shouldn’t have tools with these capabilities.

> Then use something else.

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?)

Where on Earth did that come from?

Did you miss the (2014) in the title?

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)

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.

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

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.

https://support.google.com/a/answer/9381067?hl=en

Approvals ends up solving some of this by freezing changes to approved documents.

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

- Much, much more, given some data and time

All valid points, but to be fair you can already do all those things with regular documents.

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.

The point is that all the data is centralized in a single database in this case.

the difference being the database in this case is a culmination of god knows how many accounts on the www several TB-PB of data so it bit more scary.

Carmack2Vec: Identifying and quantifying productivity through keystroke patterns.

I studied this vector for attack in college[0] almost 20 years ago based on work done in 1986[1]!

[0] - https://dl.acm.org/doi/abs/10.1016/S0167-4048(03)00010-5

[1] - https://patents.google.com/patent/US4805222A/en

I once did an experiment on identifying based solely on keystroke timing:

https://github.com/mturnshek/keystroke-timing-identifier

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.

I believe this would work at most scales.

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.

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.

I love how git calls this feature “blame” :)

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.

Strangely enough, this does seem to exist for Google Sheets:

https://webapps.stackexchange.com/questions/73080/is-there-a...

$ git config --global alias.praise blame # Who wrote this most beautiful piece of.. code?

I thought something like that shipped by default, but I can't find it. I find git annotate though, a confusing almost doppelgänger to git blame.

SVN called it blame, before git. There might be other predecessors.

Apparently CVS had it, probably but not certainly before SVN https://linux.die.net/man/1/cvs

I bet you money that 5 years from now this will be renamed to "attribute" or "authorship".

% git thank-profusely

Because of Linus's well documented concern for people's feelings?

It is happening to master -> main on github.

Linus does not control GitHub.

Care to take the bet then? 5 years to get 'blame' renamed?

No, but, if you remember, then you've got documented bragging rights when it happens.

I have bragging rights on putting my money where my mouth is today.

Jetbrain's IDEs label it as "annotate".

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.

Annotate is used in Mercurial (and probably others).

CVS called it annotate back in the 90s.

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.

Sheets does it and it's so useful!

If curious see also

discussed at the time: https://news.ycombinator.com/item?id=8562483

also 2015 https://news.ycombinator.com/item?id=9686135

>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 ?

I always make a copy and then share that when I’m ready. This is the only method I’m aware of to remove history.

I'm pretty sure only editors can see document history as well. If you share as view or comment the history is not visible.

Correct, only editors can see edit history. Making a copy also takes a snapshot of the document without history.

Indeed. It's definitely happened to me before that I accidentally pasted, then removed, some credentials from a Google doc.

Usually the expectation is that as long as you don't hit "send" it's fine, but this is clearly not the case here.

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.

> a "virtual on-site interview" (an oxymoron I know)

... But seriously, what? What is a virtual on-site meant to be?

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.

Do they get consent from the interviewee saying they could do this? For privacy reasons.. you know

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.

It sort of has to do this. How can you see others' keystrokes if they aren't being sent anywhere?

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.

You can always make a copy which clears the 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.

Google Docs also uses OT, with a single master server per document that handles all of the mutations.

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....

> without user knowledge

File -> version history

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.

This has been a feature of Google Docs from jump. And it has never been a secret that you can browse doc version history.

Yes, but that version history is not as detailed as every keystroke, so it's not obvious that every keystroke is recorded.

This is just silly, I've worked on systems to write text and that is just wat you do to solve the problem of (collaborative) editing a document.

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.

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.

I don't think that's the right way to look at it. If there is no reason to store specific information - then don't.

This is the stance that GDPR takes.

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.

Fun read and clever hacking. It's fun to think about the insane resolution of the breadcrumbs we leave online.

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.

can someone please throw a light on the framework used behind the UI of Google docs or sheets? Is it opensource?

It's Google's proprietary code. Google Docs is too unique, complex and valuable to use any typical opensource UI framework.

Actually, Google Docs was (and possibly still is) built on Google Web Toolkit (http://www.gwtproject.org/)

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

This sh*t is the reason that I write offline and then copy-paste the final text only at the end.

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.

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.

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.

Can we add 2014 to title?

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.

How do you delete a line from an email that you sent to someone else’s GMail account?

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.

PET RANT: horrible use of monitor areas by Gdocs.

Look at the image from the article. Ughh. Maybe 3rd of the monitor is actually used to display text

https://cloud.githubusercontent.com/assets/21294/4930884/70f...

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.

>any website

CSS permitting

Browser zoom is independent of CSS.

if that were true then all websites would scale uniformly

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

View>fit

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.

[0] https://practicaltypography.com/line-length.html

Reply on news.ycombinator.com