Skip to content
This repository has been archived by the owner on Nov 2, 2023. It is now read-only.

Proposal entirely skips how attestors are supposed to actually function? #44

Open
SilverAndro opened this issue Jul 20, 2023 · 6 comments

Comments

@SilverAndro
Copy link

As far as I can tell the proposal leaves the question of how attestors should actually attest to anything as an open question, but im having trouble seeing any possible way these could work?

The only descriptions we have are that "the attesters will typically come from the operating system (platform) as a matter of practicality" and comparisons to App Attest and Play Integrity. The issue is though that

  1. The operating system is not trustworthy either for the purposes of this proposal
  2. The other comparisons are on closed platforms, sometimes with dedicated hardware for detecting tampering

How do you propose this system actually functioning without

  • Destroying general computation on all desktops
  • Every client sending massive amounts of data at all times to multiple attestation authorities (and verifying the information from those computers is legit, somehow)

The attestor cannot run on the client device as it is untrusted and could be either modifying the attestation software or feeding it false information, and running outside of the client device seems like a privacy and security nightmare.

@tendstofortytwo
Copy link

This is the an issue that concerns me deeply as an end-user - while the proposal does respect my privacy with respect to the websites I visit, it is unclear to me if there is any implementation of an attestor that that could simultaneously:

  • Not collect huge amounts of information on legitimate users, which can then be used by a nefarious attestor as they see fit
  • Collect enough information to determine legitimate users from the kind of clickfarms etc that this proposal intends to detect/block

Note here that a "nefarious attestor" problem can't simply be solved with user choice in which attestors to use, as the proposal currently suggests - if UnspecifiedMegacorp Inc pays enough money to UnspecifiedBank, the bank may choose to only use UnspecifiedMegacorp's attestor servers, in which case "simply choosing another attestor" may no longer be an option the bank's customer can pursue. The key point being that an attestor that is considered nefarious by the user may not be considered nefarious by the website.

@SilverAndro
Copy link
Author

SilverAndro commented Jul 20, 2023

Having had some extra time to put together my thoughts, i think it essentially boils down to this:

The WEI proposal seems to assert the existence of a software ecosystem whos creation would be, by necessity, antitetical to the proposal's stated goals.

The protocol by itself seems fine for privacy, other than its potential for abuse, but relies on a key component (attestation) that cannot be built without either resulting in "Enforce[ing] or interfere with browser functionality, including plugins and extensions." or failing to prevent "new cross-site user tracking capabilities through attestation."

The creation of attestors cannot be reasonably separated from this protocol, and attestors would require (as far as I can tell) breaking either the open internet or privacy, if not both, with no reasonable way to reign them in.

@SilverAndro
Copy link
Author

that would be a side effect of attestation software, not of the protocol itself, hence the distinction i made.

yes the protocol would essentially require that, but by itself, in the technical sense, it is fine for privacy, as it only defines a request to a (theoretical) attestor about if the client is "good" and then maybe basic information (that it should be able to track anyways, but i digress). On a technical level, the protocol doesnt leak any particurally large pieces of information as far as im aware, other than that some authority trusts the client.

you can argue about if that trust is privacy violating, but i personally dont consider it particularly worse than, say, oauth2 login, so i made the distinction between the abstract form of the proposal and how it might be practically implemented in order to make my point.

I even specifically said "other than its potential for abuse" because im aware the implementation would cause issues😓

@SilverAndro
Copy link
Author

youre welcome to do that, but i specifically wrote this issue with the intention of attempting to lay out a specific, targeted implementation concern.

if you want to complain about the protocol in general others have already created numerous issues to do so.

@SilverAndro
Copy link
Author

well youre welcome to not interact if you dont believe it will be effective, at worst ive only wasted an hour writing, and i think it could be interesting to have the maintainers address this 🤷‍♀️

@zb3
Copy link

zb3 commented Jul 21, 2023

The attestor cannot run on the client device as it is untrusted

Nah, it's precisely where they want it to run. Currently these devices are untrusted because the user can still control them to a large extent, for example by modifying apps that are running there.

But Google doesn't want that. Look at Android, look at all these crazy efforts to bring "security" by preventing users from modifying the device. Look how hard it is to get rid of Google on your smartphone...

The effect of this is that banking apps now require your phone to be "secure" (unmodified, look at "hardware attestation"), but by this you'd have to let Google track you and shove ads, which is unacceptable for me, hence I can't even use these banking apps.

But at least now I can use the banking website without installing the app. And Google clearly doesn't like that.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants
@zb3 @tendstofortytwo @SilverAndro and others