As someone who had the misfortune of working on clipboard support in Chrome, I thought "wow, there's no way we do that in places other than Linux".
... turns out we do and I helped review that patch. Doh!
For how widely the clipboard is, the actual implementation (both in the OS and in the browser) is surprisingly unloved and unmaintained.
FWIW, Chrome intentionally doesn't plumb through the original image bytes. I wasn't around when it was initially implemented, but even for many years afterwards, there were no (Windows) platform conventions for passing around non-bitmap images on the (Windows) clipboard. And another (probably unintentional) benefit was "the encoded image bytes are from an untrustworthy source and could trigger bugs in buggy image decoders", while bitmaps are (relatively) safe in comparison.
Of course, this is a rather arbitrary line, because it's easy to get the original image bytes out of the sandboxed renderer, e.g. by dragging out the image or by saving the image.
At this point, someone could probably try plumbing through the original bytes or even implementing delayed rendering... but it's quite expensive in terms of time, especially to test all the random things that might break. :(
Oilpan isn't without issues though: finalization causes quite a few headaches, implementation details like concurrent marking make it hard to support things like std::variant, and the interface between Oilpan and non-Oilpan types often introduces opportunities for unsafety.
Indeed. It's tradeoffs, but they've been sufficient for much of the codebase for a very long time. Taking no major action (Oilpan or memory safe language) for nearly a decade was also a tradeoff. I don't think the long list of security issues there was worth it.
Hmm. The blink dirs seem to have a very large number of security issues relevant too, despite oilpan. Which is what we'd expect, honestly; oilpan does not solve all uaf problems, uafs are not all (or even the majority of) security problems, etc. The combo of "sufficient for much of the codebase" and "the long list of security issues" paints a picture of most of the codebase being secure due to oilpan, while UI code is riddled with holes due to its lack. The reality is dramatically more nuanced (as you know, but readers of your comment might not).
As a views maintainer, I'm familiar with some of the security bugs on the UI side. Clickjacking-type issues are more common there than uafs. Uafs are an issue, but the problems are not so much due to problematic use of unsafe c++ types and idioms as problematic API designs -- resulting in, for example, cases where it's not clear whether an object is expected to be able to respond safely to calls at all, whether or not it's technically alive. Oilpan, MiraclePtr, proper use of smart pointers would all help bandaid the uafs, but are in many cases difficult to apply correctly without understanding (and often fixing) the underlying systemic design problems. Which is happening, but slowly.
There are also more dimensions of tradeoffs involved, but this is long winded enough as it is. The tldr is that at this point I would consider a couple other options better uses of effort for tackling this specific problem compared to converting browser types to oilpan.
Possibly another way of expressing your point: after writing my above comment, I found myself wondering how much a system that kept these UAF pointers alive longer (to eliminate the UAFs, e.g a GC) would actually reduce the attack surface -- the UAF-ish bugs are still bugs, and code poking at a GC-preserved object that the rest of the code doesn't really expect to still be alive might itself be pretty fraught.
> the UAF-ish bugs are still bugs, and code poking at a GC-preserved object that the rest of the code doesn't really expect to still be alive might itself be pretty fraugh
For the LayoutObject heirarchy - the team doing that conversion added a NOT_DESTROYED() macro for this reason. It's gross, but was the least worst option.
As an aside - the performance of oilpan is broadly net positive now if you avoid some of the pitfalls. (The largest being a write into a Member<> requires a write-barrier). E.g. Things become trivially destructible, and no ref incrementing/decrementing, etc.
Templated code can lead to some really long symbol names. As a random tangent, I was trying to figure out why Chrome's stack symbolizer wasn't working for some stack frames this week… and came across this comment in the symbolizer.
char demangled[256]; // Big enough for sane demangled symbols.
Turns out the longest symbol name in the Chrome binary is 32k characters long... and some of the tests have even longer ones (the longest one I found was 98k characters).
Crikey. We (C++Builder) were looking at some Boost debugging issues a couple of years ago and realised some symbols were a couple of thousand characters long. I thought _that_ was bad!
Disclaimer: I am a Chrome developer, who formerly worked on the clipboard.
For a long time, Chrome did not allow pages on the open web to use document.execCommand('copy') or document.execCommand('cut'), and there was a fairly steady stream of requests from web developers to enable this. Eventually, Chrome did expose this gated behind a user gesture: https://chromestatus.com/feature/5223997243392000
> So instead of changing their new tab page to require a gesture like all other sites... they decided to allow any website to copy text into the clipboard. Nice.
Ownership of the clipboard features has moved around a bit, and sometimes historical context around things like the user gesture requirement are lost. Here, the NTP doesn't actually need this to work without a user gesture. The correct fix here is to fix the NTP tests to correctly simulate a user gesture, not to allow writing to the clipboard without a user gesture.
> I think copying into the clipboard needs an overhaul—even with a gesture. Don't you hate when news sites add a "- from XYZ" to your clipboard? That shouldn't be possible. I'm not sure how you'd fix this, but it should be fixed.
This is a difficult problem to fix. There are absolutely websites that abuse this. But there are also pages that do use the legacy clipboard API events in non-abusive ways (e.g. rich text editors), and blocking this outright would break legitimate uses as well.
Maybe something like a "copy as plain text" option would make sense...
> Maybe something like a "copy as plain text" option would make sense
That's ask I _ever_ want. I never want to copy rich text. I even have a background script that removes formatting from the clipboard every second, to make copying less frustrating.
Hide it in some hidden flag or something, but please, make plain text copying an option!
Right? I think, in 25+ years of computing, I have never once wanted to paste rich text. Ever. I just want to paste the text! Yet every time, I have to either fumble for the "paste and match style" key combo, or fix things afterwards.
FWIW, I actually have wanted that, usually when I'm copying a chunk of text and I want to keep inline hyperlinks intact. I'm not sure I want that more often than I want a plain text option that strips out all the formatting, but it does come up.
The trick is that 99% of the time I want Markdown. That is, I want hyperlinks, bullets, headers, strong, etc. to stay hyperlinks, bullets, headers, etc.
But all the other styling? The fonts, the colors, stuff like that that isn't in markdown? Nobody wants that.
Don't most apps allow you to paste plain text with Ctrl+Shift+V nowadays? That's what I almost always use, unless I have some use for the copied rich text.
Annoyingly the GitHub comment box doesn't. Incredibly frustrating to copy someones name from the GitHub webpage and paste it and it pastes as a markdown link which doesn't trigger a mention.
Sure, it depends on `xclip`, which you might need to install, and `perl` which you probably already have. I only run it while I'm actually copying and pasting as I don't like leaving loops running, that said, with the 1 second sleep it's really not so bad.
#!/bin/bash
while true ; do xclip -sel primary -o | perl -pe 'chomp if eof' | xclip -sel primary ; sleep 1 ; done
Note that this affects only the primary selection, e.g. the copy-on-highlight and paste-on-middle-click clipboard. I hardly ever use the rodent, but when I do, this is what I use it for. You could easily adapt the script to the Ctrl-C Ctrl-V clipboard.
Then make it a regular option. My point was that _if_ it's not deemed important enough to expose a UI option for, at least let make it possible some other way.
I’ve remapped ⌘V on my work laptop to paste as plain text which works great everywhere except Outlook, which disables that in email metadata (recipients, subject).
So bloody annoying, thanks Microsoft for continuing to make my life harder than it needs to be.
Better than Gmail which automatically parses text on paste, and, as the cherry on top, even when it recognizes that and alerts on a failed parse (making a red chip), refuses to let you edit the text to fix it.
Why do you call it a "user gesture" and not "consent" as it should absolutely be? Is it to reinforce the notion that users' actions are only to be taken as mere suggestions and ignored if they are contrary to your goals?
"user gesture" and "consent" are two completely different things.
Currently (until this bug) it’s supposed to trace back the call stack to the event that triggered it, and only allow it if the triggering event is something like a click. That’s what’s meant by “user gesture”, the opposite of code triggering it independently of the user.
“Consent” would be a positive acceptance in a browser controlled message box asking for permission to use the clipboard.
Most people agree that for copying to the clipboard the first is all that’s needed (there isn’t really a security concern here), for pasting from the clipboard the later is always required.
> Is it to reinforce the notion that users' actions are only to be taken as mere suggestions and ignored if they are contrary to your goals?
Wow, rude.
One possible answer to your question: there is no way for a browser to detect "consent", which is a subtle and nuanced concept, but user gestures have a hard and fast definition, so that's the proxy they use.
When a site wants access to my camera or microphone, the browser detects my consent by asking me. I don't see why listening to clipboard events shouldn't be treated in the same way. Likewise with mouse and keyboard tracking events.
The number of sites that reasonably need to know when I copy/paste or need to override what happens when I do that is approximately zero. There's no reason to allow it by default for all sites.
Chromium has a presubmit that enforces that code is autoformatted. However, it only enforces this for changed lines, and in practice, it works pretty well.
... turns out we do and I helped review that patch. Doh!
For how widely the clipboard is, the actual implementation (both in the OS and in the browser) is surprisingly unloved and unmaintained.
FWIW, Chrome intentionally doesn't plumb through the original image bytes. I wasn't around when it was initially implemented, but even for many years afterwards, there were no (Windows) platform conventions for passing around non-bitmap images on the (Windows) clipboard. And another (probably unintentional) benefit was "the encoded image bytes are from an untrustworthy source and could trigger bugs in buggy image decoders", while bitmaps are (relatively) safe in comparison.
Of course, this is a rather arbitrary line, because it's easy to get the original image bytes out of the sandboxed renderer, e.g. by dragging out the image or by saving the image.
At this point, someone could probably try plumbing through the original bytes or even implementing delayed rendering... but it's quite expensive in terms of time, especially to test all the random things that might break. :(