Export copy to clipboard functionality by weizman · Pull Request #50 · LavaMoat/LavaDome

weizman · 2024-07-12T22:55:20Z

close #46 by providing a new LavaDome method copy which copies the secret to clipboard without leaking it to any other entity.

legobeat · 2024-10-01T06:21:53Z


-    function text(text) {
-        if (typeof text !== 'string') {
+    let secret = '';


It doesn't feel great to have the secret hang out in memory in this long-lived scope... Not that I have a proposal on how it could be achieved differently, though...

I see your point, but essentially, it's only natural that in order to provide service where the input is somehow manipulated we must have access to it

legobeat · 2024-10-01T06:24:59Z

-    defineProperties(this, {text: {value: text}});
+    defineProperties(this, {
+        text: {value: text},
+        copy: {value: copy},


Re https://github.com/LavaMoat/LavaDome/pull/50/files#r1782176796

Could setting the value of copy (including its declaration and instantiation) be moved to the inner scope of text? If so, maybe the need to move secret out of scope is no longer here?

Or would that conflict with the "make exported API tamper-proof" part? If so I think I'm still leaning towards that as the lesser bad. WDYT?

How would we export copy if it's inside text?

If we assign it inside the handler of text, is there a need to?

AFAIU, if you move the copy function into the text function, you closure the secret within the text scope instead of the LavaDome scope, which doesn't solve the problem, just shifts it elsewhere - the secret still must be scoped somewhere

The secret is already part of the text scope (by virtue of being an argument).

However, moving/copying it to the outer scope widens the exposure (and lifetime, but not sure to what extent we can actually limit that if introducing the copy-to-clipboard functionality as intended).

For example, consider a scenario where text() is called a second time with invalid input on an existing LD instance:

ld.text('actualsecret'); // at some point later... ld.text();

This will throw an Error where 'actualsecret' is still in scope. I don't have a PoC or anything but does seem like it could more easily leak to a malicious extension or devtool/debugger integration.

Vs if it's contained in the text function, separate text() invocations are not able to access each others' secrets, and subsequent calls would make new copy instances with isolated scopes wrt secret.

One way to at least prevent one aspect of scope-creep of secret itself without compromising on the tamper-proofing could be to freeze a property accessor and reassign copy itself instead:

// instead of `let secret` let _copy = () => Promise.resolve(); async function copy() { await _copy(); } // [...] function text(input) { _copy = async () = { // `_copy` can now access `input` from `text` directly } }

sold c8c9cd7

I actually just removed c8c9cd7 because:

it turns out the way i did it dropped a commit coming from main by accident which could have been a terrible mistake

a younger comment made me realize the implementation isn't right, and that also I'm again not convinced this can be solved without storing the secret in some upper scope

For example, I'm not sure how #50 (comment) demonstrates this otherwise, how scoping a function that has access to the secret instead of the secret itself is far better?

A demonstrating PR here could very much help me understand 🙏

legobeat · 2024-10-02T01:39:36Z

+        if (typeof input !== 'string') {
            throw new Error(
-                `LavaDomeCore: first argument must be a string, instead got ${stringify(text)}`);
+                `LavaDomeCore: first argument must be a string, instead got ${stringify(input)}`);


Suggested change

`LavaDomeCore: first argument must be a string, instead got ${stringify(input)}`);

`LavaDomeCore: first argument must be a string, instead got ${typeof input}`);

Type should be enough, no need to template secret in error message

also 38ef179

legobeat · 2024-10-02T01:40:48Z

+        const type = 'text/plain';
+        const blob = new Blob([secret], {type});
+        const data = [new ClipboardItem({[type]: blob})];
+        await write(clipboard, data);


Maybe swallow errors on write?

Suggested change

const type = 'text/plain';

const blob = new Blob([secret], {type});

const data = [new ClipboardItem({[type]: blob})];

await write(clipboard, data);

try {

const type = 'text/plain';

const blob = new Blob([secret], {type});

const data = [new ClipboardItem({[type]: blob})];

// do we also want to return the result of the await here?

await write(clipboard, data);

} finally {}

To reduce the likelihood of an error containing a reference to the secret?

We shouldn't swallow errors that have nothing to do with us, the app should become aware of such errors being thrown. The error will never leak the secret, because if it did, it would have been a major info leak in the design of the native API, which should remain outside of LavaDome's jurisdiction.

boneskull

mostly just questions. I'm not familiar with this (or React)

boneskull · 2024-10-07T21:30:47Z

    }
 }
+
+export function LavaDome(host, opts) {


Is this a constructor? A React component? if the former, why not use class?

It's the former.
Because there's no way to make methods of a class (truly) private and inaccessible.

not even with #private? but wait, why do we need to worry about that at all in this use case? I don't see any methods.

not even with #private

text and the new copy are methods.
They're not assigned to the prototype as methods for the same privacy reason, but they are effectively methods of the instance.

for the sake of being through, I still don't understand why it needs to be a function and not a class with a constructor impl

I have to admit I can't think of the reason I used to have when making this decision

boneskull

I'm going to approve this because I don't know any better

support issue 46

63633a6

weizman marked this pull request as draft July 12, 2024 23:01

weizman added 2 commits July 16, 2024 14:30

support ld react

81297dc

update comment

d165398

weizman marked this pull request as ready for review July 16, 2024 11:38

weizman added 2 commits July 16, 2024 14:52

use safe native

2e9046f

button to anchor

3f371ae

weizman self-assigned this Jul 25, 2024

weizman added 2 commits September 4, 2024 15:33

address navigation bypass

cebd9cb

Merge branch 'main' into issue-46

ea7f8e5

legobeat reviewed Sep 10, 2024

View reviewed changes

Comment thread packages/core/src/lavadome.mjs Outdated

weizman force-pushed the main branch 2 times, most recently from 7958a69 to fa4643f Compare September 18, 2024 08:04

weizman added 2 commits September 18, 2024 11:27

Merge remote-tracking branch 'origin/main' into issue-46

1b57716

change var name

fb25541

weizman requested review from legobeat and naugtur September 18, 2024 08:28

legobeat reviewed Oct 1, 2024

View reviewed changes

legobeat reviewed Oct 2, 2024

View reviewed changes

weizman added 2 commits October 4, 2024 13:08

Merge branch 'main' into issue-46

ac1636d

safer

5265dd4

weizman requested a review from legobeat October 7, 2024 13:51

boneskull previously approved these changes Oct 7, 2024

View reviewed changes

legobeat reviewed Oct 7, 2024

View reviewed changes

Comment thread packages/core/src/lavadome.mjs Outdated

weizman dismissed boneskull’s stale review via fb55997 October 8, 2024 15:14

weizman added 3 commits October 9, 2024 14:07

improve

4f01fac

error to typerror

19ed8a9

change api

1b73fe6

weizman force-pushed the issue-46 branch from c9f2ec4 to 1b73fe6 Compare October 9, 2024 11:11

boneskull previously approved these changes Jan 10, 2025

View reviewed changes

update docs

43a64db

weizman dismissed boneskull’s stale review via 43a64db January 13, 2025 15:02

Merge branch 'main' into issue-46

d2cc637

weizman requested a review from boneskull January 13, 2025 15:04

boneskull approved these changes Jan 14, 2025

View reviewed changes

weizman merged commit 46df348 into main Jan 15, 2025

	`LavaDomeCore: first argument must be a string, instead got ${stringify(input)}`);
	`LavaDomeCore: first argument must be a string, instead got ${typeof input}`);

Conversation

weizman commented Jul 12, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

legobeat Oct 1, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

legobeat Oct 1, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

legobeat Oct 2, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

legobeat Oct 2, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

boneskull left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

boneskull Oct 8, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

boneskull left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

weizman commented Jul 12, 2024 •

edited

Loading

legobeat Oct 1, 2024 •

edited

Loading

legobeat Oct 1, 2024 •

edited

Loading

legobeat Oct 2, 2024 •

edited

Loading

legobeat Oct 2, 2024 •

edited

Loading

boneskull Oct 8, 2024 •

edited

Loading