This CL moves the base::Feature from content_features.h to
a generated feature from runtime_enabled_features.json5.
This means that the base::Feature can be default-enabled
while the web API is co...
I rechecked the current spec. It does not fully cover what a user agent can ask to the attestor ( “content binding” to be defined). So we can assume this attestation spec is defined at the attestor.
Of course this does not mean attestor can not have different profiles to attest for.
So your comment even though is possible, just not defined yet. Which we can - I believe - rightfully assume will be in the final spec or implementation.
That’s even worse. Websites will trust only Microsoft, Apple, and Google. Those of us who value our security enough to install Linux will be left out in the cold. We’ll be such a small minority that no one ever cares enough to give up on attestation. The pressure will cause our numbers to dwindle to nothing as people flee to proprietary platforms in order to avoid losing access to their bank/doctor/government. All hail the eternal compulsory corporate triopoly.
For now spec calls “holdbacks”, which are designed for this purpose. Attestors will fail randomly for a set percentage of the requests so this can’t be used as a whitelist. Surely this “holdbacks” will either be not implemented or dropped in no time by attestors.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !technology@beehaw.org
A nice place to discuss rumors, happenings, innovations, and challenges in the technology sphere. We also welcome discussions on the intersections of technology and society. If it’s technological news or discussion of technology, it probably belongs here.
Remember the overriding ethos on Beehaw: Be(e) Nice. Each user you encounter here is a person, and should be treated with kindness (even if they’re wrong, or use a Linux distro you don’t like). Personal attacks will not be tolerated.
I rechecked the current spec. It does not fully cover what a user agent can ask to the attestor ( “content binding” to be defined). So we can assume this attestation spec is defined at the attestor.
Of course this does not mean attestor can not have different profiles to attest for.
So your comment even though is possible, just not defined yet. Which we can - I believe - rightfully assume will be in the final spec or implementation.
That’s even worse. Websites will trust only Microsoft, Apple, and Google. Those of us who value our security enough to install Linux will be left out in the cold. We’ll be such a small minority that no one ever cares enough to give up on attestation. The pressure will cause our numbers to dwindle to nothing as people flee to proprietary platforms in order to avoid losing access to their bank/doctor/government. All hail the eternal compulsory corporate triopoly.
For now spec calls “holdbacks”, which are designed for this purpose. Attestors will fail randomly for a set percentage of the requests so this can’t be used as a whitelist. Surely this “holdbacks” will either be not implemented or dropped in no time by attestors.
Surely. Remote attestation is only useful if it always succeeds on an approved device.