commit 7676b4280175a6ed16b3c41ec663ee0842d496a1 · bmann.ca/bmannconsulting.com

_notes/ACL.md

···

       1
       1
       +
       ---

     

       2
       2
       +
       title: Access control lists

     

       3
       3
       +
       tags:

     

       4
       4
       +
         - acronym

     

       5
       5
       +
         - ACL

     

       6
       6
       +
       ---

     

       7
       7
       +
       Access control lists

+14

_notes/ACLs don't.md

···

       1
       1
       +
       ---

     

       2
       2
       +
       tags:

     

       3
       3
       +
         - paper

     

       4
       4
       +
         - ACL

     

       5
       5
       +
       link: http://waterken.sourceforge.net/aclsdont

     

       6
       6
       +
       excerpt: The ACL model is unable to make correct access decisions for interactions involving more than two principals, since required information is not retained across message sends. Though this deficiency has long been documented in the published literature, it is not widely understood. This logic error in the ACL model is exploited by both the clickjacking and Cross- Site Request Forgery attacks that affect many Web applications.

     

       7
       7
       +
       ---

     

       8
       8
       +
       Tyler Close, Hewlett-Packard Labs

     

       9
       9
       +
       

     

       10
       10
       +
       ## Abstract

     

       11
       11
       +
       

     

       12
       12
       +
       The ACL model is unable to make correct access decisions for interactions involving more than two principals, since required information is not retained across message sends. Though this deficiency has long been documented in the published literature, it is not widely understood. This logic error in the ACL model is exploited by both the clickjacking and Cross- Site Request Forgery attacks that affect many Web applications.

     

       13
       13
       +
       

     

       14
       14
       +
       ![PDF - ACLs don't](/assets/2024/acls-dont.pdf)

_notes/Apple Intelligence.md

···

       1
       1
       +
       ---

     

       2
       2
       +
       tags:

     

       3
       3
       +
         - Apple

     

       4
       4
       +
         - AI

     

       5
       5
       +
       ---

     

       6
       6
       +
       [[Apple]]'s name for their AI systems.

_notes/Capabilities Adoption.md

···

       1
       1
       +
       Capabilities a

     

       2
       2
       +
       ## CapCon

     

       3
       3
       +
       

     

       4
       4
       +
       When is the right time to have a "Capabilities Conference"?

     

       5
       5
       +
       

     

       6
       6
       +
       What do we want to accomplish out of having an in person conference?

     

       7
       7
       +
       * talks that are recorded

     

       8
       8
       +
       * discussion about?

     

       9
       9
       +
       * interop / plug fest

+53

_notes/Capability Myths Demolished.md

···

       1
       1
       +
       ---

     

       2
       2
       +
       tags:

     

       3
       3
       +
         - paper

     

       4
       4
       +
         - capabilities

     

       5
       5
       +
       excerpt: "We address three common misconceptions aboutcapability-based systems: the Equivalence Myth (accesscontrol list systems and capability systems are formallyequivalent), the Confinement Myth (capability systemscannot enforce confinement), and the IrrevocabilityMyth (capability-based access cannot be revoked). TheEquivalence Myth obscures the benefits of capabilitiesas compared to access control lists, while the Confinement Myth and the Irrevocability Myth lead people tosee problems with capabilities that do not actually exist.The prevalence of these myths is due to differing interpretations of the capability security model. To clear upthe confusion, we examine three different models thathave been used to describe capabilities, and define a setof seven security properties that capture the distinctionsamong them. Our analysis in terms of these propertiesshows that pure capability systems have significantadvantages over access control list systems: capabilitiesprovide much better support for least-privilegeoperation and for avoiding confused deputy problems."

     

       6
       6
       +
       author:

     

       7
       7
       +
         - Mark Miller

     

       8
       8
       +
         - Ka-Ping Yee

     

       9
       9
       +
         - Jonathan Shapiro

     

       10
       10
       +
       link: https://srl.cs.jhu.edu/pubs/SRL2003-02.pdf

     

       11
       11
       +
       ---

     

       12
       12
       +
       * [[Mark Miller]], Combex, Inc.

     

       13
       13
       +
       * Ka-Ping Yee, University of California, Berkeley

     

       14
       14
       +
       * Jonathan Shapiro, Johns Hopkins University

     

       15
       15
       +
       ## Abstract

     

       16
       16
       +
       

     

       17
       17
       +
       We address three common misconceptions about capability-based systems: the *Equivalence Myth* (access control list systems and capability systems are formally equivalent), the *Confinement Myth* (capability systems cannot enforce confinement), and the *Irrevocability Myth* (capability-based access cannot be revoked). The Equivalence Myth obscures the benefits of capabilities as compared to access control lists, while the Confinement Myth and the Irrevocability Myth lead people to see problems with capabilities that do not actually exist. The prevalence of these myths is due to differing interpretations of the capability security model. To clear up the confusion, we examine three different models that have been used to describe capabilities, and define a set of seven security properties that capture the distinctions among them. Our analysis in terms of these properties shows that pure capability systems have significant advantages over access control list systems: capabilities provide much better support for least-privilege operation and for avoiding confused deputy problems.

     

       18
       18
       +
       

     

       19
       19
       +
       ## A Note on the word "Capability"

     

       20
       20
       +
       

     

       21
       21
       +
       Given these various interpretations of the capability model, the reader may wonder what one should adopt as the most legitimate meaning for the term capability. We should also explain why we feel justified in declaring the Irrevocability Myth and Confinement Myth to be false, rather than merely false in certain cases. We would argue that the “true” capability model is the object-capability model, because all known major capability systems take the object-based approach (for examples, see [^1] [^4] [^9] [^11] [^16] [^17] [^19] [^21]). In all of these systems, a capability is an object reference – not something that behaves like a key or ticket in the real world. Definitive books on capability-based systems [6, 16] also describe these systems from the objectcapability perspective, and explicitly characterize them as “object-based”.

     

       22
       22
       +
       

     

       23
       23
       +
       We know of no security mechanisms outside of the object-capability model that have described themselves using the word capability except for “POSIX capabilities”, “Netscape capabilities”, and “split capabilities” [14]. POSIX capabilities are not generally described as “[[Capability-based security]]”. The “Netscape capabilities” extensions to Java were fairly short-lived and have not been presented in the research literature as a capability system. Moreover, both “POSIX capabilities” and “Netscape capabilities” have never been presented as security mechanisms that can stand on their own, instead only serving as an extension to existing security systems. The split capabilities model is explicitly presented in contrast to the pure capability model [14].

     

       24
       24
       +
       

     

       25
       25
       +
       ## References 

     

       26
       26
       +
       1. [^1]: M. Anderson, R. Pose, C. S. Wallace. A Password Capability System. The Computer Journal, 29(1), 1986, p. 1–8.

     

       27
       27
       +
       2. W. E. Boebert. On the Inability of an Unmodified Capability Machine to Enforce the ＊-Property. Proceedings of 7th DoD/NBS Computer Security Conference, September 1984, p. 291–293. Online at: http://zesty.ca/capmyths/boebert.html

     

       28
       28
       +
       3. A. Chander, D. Dean, J. C. Mitchell. Proceedings of the 14th Computer Security Foundations Workshop, June 2001, p. 27–43.

     

       29
       29
       +
       4. The E Language: Open Source Distributed Capabilities. http://erights.org/.

     

       30
       30
       +
       5. C. Ellison, B. Frantz, B. Lampson, R. Rivest, B. Thomas, T. Ylonen. SPKI Certificate Theory. IETF RFC 2693. Online at: http://www.ietf.org/rfc/rfc2693.txt

     

       31
       31
       +
       6. E. F. Gehringer. Capability Architectures and Small Objects. UMI Press, 1982.

     

       32
       32
       +
       7. L. Gong. A Secure Identity-Based Capability System. Proceedings of the 1989 IEEE Symposium on Security and Privacy, p. 56–65.

     

       33
       33
       +
       8. M. Granovetter. The Strength of Weak Ties. American Journal of Sociology 78, 1973, p. 1360–1380.

     

       34
       34
       +
       9. N. Hardy. The KeyKOS Architecture. ACM Operating Systems Review, September 1985, p. 8–25. Online at: http://www.agorics.com/Library/KeyKos/architecture.html

     

       35
       35
       +
       10. N. Hardy. The Confused Deputy (or why capabilities might have been invented). Operating Systems Review 22(4), October 1988, p. 36–38.

     

       36
       36
       +
       11. G. Heiser, K. Elphinstone, S. Russel, J. Vochteloo. Mungi: A Distributed Single Address-Space Operating System. Proceedings of the 17th Australasian Computer Science Conference, p. 271–280.

     

       37
       37
       +
       12. A. J. Herbert. A Microprogrammed Operating System Kernel. Ph. D. thesis, University of Cambridge Computer Laboratory, September 1982.

     

       38
       38
       +
       13. P. Karger. Improving Security and Performance for Capability Systems. Technical Report 149, University of Cambridge Computer Laboratory, 1988. (Ph. D. thesis.)

     

       39
       39
       +
       14. A. H. Karp, R. Gupta, G. J. Rozas, A. Banerji. Using Split Capabilities for Access Control. IEEE Software 20(1), January 2003, p. 42–49.

     

       40
       40
       +
       15. B. Lampson. Protection. Proceedings of the 5 th Annual Princeton Conference on Information Sciences and Systems, 1971, p. 437–443.

     

       41
       41
       +
       16. H. Levy. Capability-Based Computer Systems. Digital Press, Bedford, Massachusetts, 1984. Online at: http://www.cs.washington.edu/homes/levy/capabook/

     

       42
       42
       +
       17. A. S. Tanenbaum, S. J. Mullender, R. van Renesse. Using Sparse Capabilities in a Distributed Operating System. Proceedings of 6 th International Conference on Distributed Computing Systems, 1986, p. 558–563. Online at: ftp://ftp.cs.vu.nl/pub/papers/amoeba/dcs86.ps.Z

     

       43
       43
       +
       18. D. D. Redell. Naming and Protection in Extendible Operating Systems. Project MAC TR-140, MIT, November 1974. (Ph. D. thesis.)

     

       44
       44
       +
       19. J. Rees. A Security Kernel Based on the LambdaCalculus. Technical Report AIM-1564, MIT, March 1996. (Ph. D. thesis.)

     

       45
       45
       +
       20. J. H. Saltzer, M. D. Schroeder. The Protection of Information in Computer Systems. Proceedings of the IEEE 63(9), September 1975, p. 1278–1308.

     

       46
       46
       +
       21. J. S. Shapiro, J. M. Smith, D. J. Farber. EROS: A Fast Capability System. Proceedings of the 17th ACM Symposium on Operating Systems Principles, December 1999, p. 170–185.

     

       47
       47
       +
       22. J. S. Shapiro, S. Weber. Verifying the EROS Confinement Mechanism. Proceedings of the 2000 IEEE Symposium on Security and Privacy, p. 166–176.

     

       48
       48
       +
       23. K. Sitaker. Thoughts on Capability Security on the Web. Online at: http://lists.canonical.org/pipermail/kragen-tol/2000-August/000619.html

     

       49
       49
       +
       24. D. S. Wallach, D. Balfanz, D. Dean, E. W. Felten. Extensible Security Architectures for Java. In Proceedings of the 16th Symposium on Operating Systems Principles, 1997, p. 116–128. Online at: http://www.cs.princeton.edu/sip/pub/sosp97.html

     

       50
       50
       +
       25. D. Wagner, D. Tribble. A Security Analysis of the Combex DarpaBrowser Architecture. Online at: http://www.combex.com/papers/darpa-review/

     

       51
       51
       +
       26. K.-P. Yee, M. S. Miller. Auditors: An Extensible, Dynamic Code Verification Mechanism. Online at: http://www.erights.org/elang/kernel/auditors/index.html

     

       52
       52
       +
       

     

       53
       53
       +
       ![PDF - Capability Myths Demolished](/assets/2024/cap-myths-demolished-SRL2003-02.pdf)

+47

_notes/Capability-based security.md

···

       1
       1
       +
       ---

     

       2
       2
       +
       wikipedia: https://en.wikipedia.org/wiki/Capability-based_security

     

       3
       3
       +
       tags:

     

       4
       4
       +
         - programming

     

       5
       5
       +
         - capabilities

     

       6
       6
       +
       ---

     

       7
       7
       +
       **Capability-based security** is a concept in the design of [secure computing](https://en.wikipedia.org/wiki/Computer_security "Computer security") systems, one of the existing [security models](https://en.wikipedia.org/wiki/Computer_security_model "Computer security model"). A **capability** (known in some systems as a **key**) is a communicable, unforgeable [token](https://en.wikipedia.org/wiki/Access_token "Access token") of authority. It refers to a value that [references](https://en.wikipedia.org/wiki/Reference_(computer_science) "Reference (computer science)") an [object](https://en.wikipedia.org/wiki/Object_(computer_science) "Object (computer science)") along with an associated set of [access rights](https://en.wikipedia.org/wiki/Access_control "Access control"). A [user](https://en.wikipedia.org/wiki/User_(computing) "User (computing)") [program](https://en.wikipedia.org/wiki/Computer_program "Computer program") on a [capability-based operating system](https://en.wikipedia.org/wiki/Capability-based_operating_system "Capability-based operating system") must use a capability to access an object. Capability-based security refers to the principle of designing user programs such that they directly share capabilities with each other according to the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege "Principle of least privilege"), and to the operating system infrastructure necessary to make such transactions efficient and secure. Capability-based security is to be contrasted with an approach that uses [traditional UNIX permissions](https://en.wikipedia.org/wiki/File-system_permissions "File-system permissions") and [Access Control Lists](https://en.wikipedia.org/wiki/Access-control_list "Access-control list").

     

       8
       8
       +
       

     

       9
       9
       +
       Although most operating systems implement a facility which resembles capabilities, they typically do not provide enough support to allow for the exchange of capabilities among possibly mutually untrusting entities to be the primary means of granting and distributing access rights throughout the system. A capability-based system, in contrast, is designed with that goal in mind.

     

       10
       10
       +
       

     

       11
       11
       +
       ## Introduction

     

       12
       12
       +
       

     

       13
       13
       +
       Capabilities achieve their objective of improving system security by being used in place of forgeable [references](https://en.wikipedia.org/wiki/Reference_(computer_science) "Reference (computer science)"). A forgeable reference (for example, a [path name](https://en.wikipedia.org/wiki/Path_(computing) "Path (computing)")) identifies an object, but does not specify which access rights are appropriate for that object and the user program which holds that reference. Consequently, any attempt to access the referenced object must be validated by the operating system, based on the [ambient authority](https://en.wikipedia.org/wiki/Ambient_authority "Ambient authority") of the requesting program, typically via the use of an [access-control list](https://en.wikipedia.org/wiki/Access-control_list "Access-control list") (ACL). Instead, in a system with capabilities, the mere fact that a user program possesses that capability entitles it to use the referenced object in accordance with the rights that are specified by that capability. In theory, a system with capabilities removes the need for any access control list or similar mechanism by giving all entities all and only the capabilities they will actually need.

     

       14
       14
       +
       

     

       15
       15
       +
       A capability is typically implemented as a [privileged](https://en.wikipedia.org/wiki/Privilege_(computing) "Privilege (computing)") [data structure](https://en.wikipedia.org/wiki/Data_structure "Data structure") that consists of a section that specifies access rights, and a section that uniquely identifies the object to be accessed. The user does not access the data structure or object directly, but instead via a [handle](https://en.wikipedia.org/wiki/Handle_(computing) "Handle (computing)"). In practice, it is used much like a [file descriptor](https://en.wikipedia.org/wiki/File_descriptor "File descriptor") in a traditional operating system (a traditional handle), but to access every object on the system. Capabilities are typically stored by the operating system in a list, with some mechanism in place to prevent the program from directly modifying the contents of the capability (so as to forge access rights or change the object it points to). Some systems have also been based on [capability-based addressing](https://en.wikipedia.org/wiki/Capability-based_addressing "Capability-based addressing") (hardware support for capabilities), such as [Plessey System 250](https://en.wikipedia.org/wiki/Plessey_System_250 "Plessey System 250").

     

       16
       16
       +
       

     

       17
       17
       +
       Programs possessing capabilities can perform functions on them, such as passing them on to other programs, converting them to a less-privileged version, or deleting them. The operating system must ensure that only specific operations can occur to the capabilities in the system, in order to maintain the integrity of the security policy.

     

       18
       18
       +
       

     

       19
       19
       +
       Capabilities as discussed in this article should not be confused with Portable Operating System Interface (POSIX) Capabilities. The latter are coarse-grained privileges that cannot be transferred between processes.

     

       20
       20
       +
       

     

       21
       21
       +
       ## Implementations

     

       22
       22
       +
       

     

       23
       23
       +
       Notable research and commercial systems employing capability-based security include the following:

     

       24
       24
       +
       

     

       25
       25
       +
       - [Tahoe-LAFS](https://en.wikipedia.org/wiki/Tahoe-LAFS "Tahoe-LAFS"), an open-source capability-based filesystem

     

       26
       26
       +
       - [GNOSIS](https://en.wikipedia.org/wiki/GNOSIS "GNOSIS"), an operating system developed at [Tymshare](https://en.wikipedia.org/wiki/Tymshare "Tymshare")

     

       27
       27
       +
           - [KeyKOS](https://en.wikipedia.org/wiki/KeyKOS "KeyKOS"), successor to GNOSIS

     

       28
       28
       +
               - EROS, The [Extremely Reliable Operating System](https://en.wikipedia.org/wiki/Extremely_Reliable_Operating_System "Extremely Reliable Operating System"), successor to KeyKOS

     

       29
       29
       +
                   - [CapROS](https://en.wikipedia.org/wiki/CapROS "CapROS"), a project to further develop the EROS code base for commercial use

     

       30
       30
       +
       - [Cambridge CAP computer](https://en.wikipedia.org/wiki/Cambridge_CAP_computer "Cambridge CAP computer")

     

       31
       31
       +
       - [Hydra (operating system)](https://en.wikipedia.org/wiki/Hydra_(operating_system) "Hydra (operating system)"), part of the C.mmp project at Carnegie Mellon University

     

       32
       32
       +
       - StarOS, part of the CM* project at [Carnegie Mellon University](https://en.wikipedia.org/wiki/Carnegie_Mellon_University "Carnegie Mellon University")

     

       33
       33
       +
       - IBM [System/38](https://en.wikipedia.org/wiki/System/38 "System/38") and [AS/400](https://en.wikipedia.org/wiki/AS/400 "AS/400")

     

       34
       34
       +
       - [Intel iAPX 432](https://en.wikipedia.org/wiki/Intel_iAPX_432 "Intel iAPX 432")

     

       35
       35
       +
       - [Plessey System 250](https://en.wikipedia.org/wiki/Plessey_250 "Plessey 250")

     

       36
       36
       +
       - [Flex](https://en.wikipedia.org/wiki/Flex_machine "Flex machine")

     

       37
       37
       +
       - [L4 microkernel family](https://en.wikipedia.org/wiki/L4_microkernel_family "L4 microkernel family"):

     

       38
       38
       +
           - OKL4 from Open Kernel Labs

     

       39
       39
       +
           - seL4 from NICTA

     

       40
       40
       +
           - Fiasco.OC and NOVA from [TU Dresden](https://en.wikipedia.org/wiki/TU_Dresden "TU Dresden")

     

       41
       41
       +
       - [Amoeba](https://en.wikipedia.org/wiki/Amoeba_(operating_system) "Amoeba (operating system)") distributed operating system

     

       42
       42
       +
       - [FreeBSD](https://en.wikipedia.org/wiki/FreeBSD "FreeBSD") [Capsicum](https://en.wikipedia.org/wiki/Capsicum_(Unix) "Capsicum (Unix)")

     

       43
       43
       +
       - [Genode](https://en.wikipedia.org/wiki/Genode "Genode")

     

       44
       44
       +
       - [Google Fuchsia](https://en.wikipedia.org/wiki/Google_Fuchsia "Google Fuchsia")

     

       45
       45
       +
       - [HarmonyOS](https://en.wikipedia.org/wiki/HarmonyOS "HarmonyOS") ([HarmonyOS NEXT](https://en.wikipedia.org/wiki/HarmonyOS_NEXT "HarmonyOS NEXT")) derived from [OpenHarmony](https://en.wikipedia.org/wiki/OpenHarmony "OpenHarmony") at customised level with capability-based like features via [Access token manager](https://en.wikipedia.org/wiki/Access_token_manager "Access token manager")

     

       46
       46
       +
       - [Phantom OS]

     

       47
       47
       +
       - [[WebAssembly]] System Interface (WASI)

_notes/Mark Miller.md

···

       1
       1
       +
       ---

     

       2
       2
       +
       tags:

     

       3
       3
       +
         - person

     

       4
       4
       +
         - capabilities

     

       5
       5
       +
       title: Mark S. Miller

     

       6
       6
       +
       aliases:

     

       7
       7
       +
         - Mark S. Miller

     

       8
       8
       +
       ---

_notes/Matthew Green Apple PCC Thread.md

···

       1
       1
       +
       ---

     

       2
       2
       +
       link: https://threadreaderapp.com/thread/1800291897245835616.html

     

       3
       3
       +
       tags:

     

       4
       4
       +
         - PCC

     

       5
       5
       +
       ---

     

       6
       6
       +
       So Apple has introduced a new system called “[[Private Cloud Compute]]” that allows your phone to offload complex (typically AI) tasks to specialized secure devices in the cloud. I’m still trying to work out what I think about this. So here’s a thread. [@matthew_d_green](https://x.com/matthew_d_green/status/1800291897245835616)

+30

_notes/Object-capability model.md

···

       1
       1
       +
       ---

     

       2
       2
       +
       wikipedia: https://en.wikipedia.org/wiki/Object-capability_model

     

       3
       3
       +
       tags:

     

       4
       4
       +
         - programming

     

       5
       5
       +
         - capabilities

     

       6
       6
       +
       ---

     

       7
       7
       +
       The **object-capability model** is a computer security model. A capability[^capability-based-security] describes a transferable right to perform one (or more) operations on a given object. It can be obtained by the following combination:

     

       8
       8
       +
       

     

       9
       9
       +
       [^capability-based-security]: [[Capability-based security]]

     

       10
       10
       +
       

     

       11
       11
       +
       - An unforgeable reference (in the sense of object references or protected pointers) that can be sent in messages.

     

       12
       12
       +
       - A message that specifies the operation to be performed.

     

       13
       13
       +
       

     

       14
       14
       +
       The security model relies on not being able to forge references.

     

       15
       15
       +
       

     

       16
       16
       +
       - Objects can interact only by sending messages on references.

     

       17
       17
       +
       - A reference can be obtained by:

     

       18
       18
       +
       

     

       19
       19
       +
       1. Initial conditions: In the initial state of the computational world being described, object A may already have a reference to object B.

     

       20
       20
       +
       2. Parenthood: If A creates B, at that moment A obtains the only reference to the newly created B.

     

       21
       21
       +
       3. Endowment: If A creates B, B is born with that subset of A's references with which A chose to endow it.

     

       22
       22
       +
       4. Introduction: If A has references to both B and C, A can send to B a message containing a reference to C. B can retain that reference for subsequent use.

     

       23
       23
       +
       

     

       24
       24
       +
       In the object-capability model, _all_ computation is performed following the above rules.

     

       25
       25
       +
       

     

       26
       26
       +
       Advantages that motivate [object-oriented programming](https://en.wikipedia.org/wiki/Object_(computer_science) "Object (computer science)"), such as encapsulation or [information hiding](https://en.wikipedia.org/wiki/Information_hiding "Information hiding"), [modularity](https://en.wikipedia.org/wiki/Modularity_(programming) "Modularity (programming)"), and [separation of concerns](https://en.wikipedia.org/wiki/Separation_of_concerns "Separation of concerns"), correspond to security goals such as [least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege "Principle of least privilege") and [privilege separation](https://en.wikipedia.org/wiki/Privilege_separation "Privilege separation") in capability-based programming.

     

       27
       27
       +
       

     

       28
       28
       +
       The object-capability model was first proposed by [Jack Dennis](https://en.wikipedia.org/wiki/Jack_Dennis "Jack Dennis") and Earl C. Van Horn in 1966[^dennis_vanhorn]

     

       29
       29
       +
       

     

       30
       30
       +
       [^dennis_vanhorn]:  J.B. Dennis, E.C. Van Horn. [“Programming Semantics for Multiprogrammed Computations.” (PDF)](http://srl.cs.jhu.edu/pubs/SRL2003-03.pdf) Communications of the ACM, 9(3):143–155, March 1966.

+13

_notes/Private Cloud Compute New Frontier.md

···

       1
       1
       +
       ---

     

       2
       2
       +
       link: https://security.apple.com/blog/private-cloud-compute/

     

       3
       3
       +
       tags:

     

       4
       4
       +
         - Apple

     

       5
       5
       +
         - article

     

       6
       6
       +
         - PCC

     

       7
       7
       +
         - decentralizedcompute

     

       8
       8
       +
       title: "Private Cloud Compute: A new frontier for AI privacy in the cloud"

     

       9
       9
       +
       published: 2024-06-10

     

       10
       10
       +
       ---

     

       11
       11
       +
       Written by Apple Security Engineering and Architecture (SEAR), User Privacy, Core Operating Systems (Core OS), Services Engineering (ASE), and Machine Learning and AI (AIML)

     

       12
       12
       +
       

     

       13
       13
       +
       [[Apple Intelligence]] is the personal intelligence system that brings powerful generative models to iPhone, iPad, and Mac. For advanced features that need to reason over complex data with [larger foundation models](https://machinelearning.apple.com/research/introducing-apple-foundation-models), we created [[Private Cloud Compute]] (PCC), a groundbreaking cloud intelligence system designed specifically for private AI processing. For the first time ever, Private Cloud Compute extends the industry-leading security and privacy of Apple devices into the cloud, making sure that personal user data sent to PCC isn’t accessible to anyone other than the user — not even to Apple. Built with custom Apple silicon and a hardened operating system designed for privacy, we believe PCC is the most advanced security architecture ever deployed for cloud AI compute at scale.

+11

_notes/Private Cloud Compute.md

···

       1
       1
       +
       ---

     

       2
       2
       +
       title: Apple Private Cloud Compute

     

       3
       3
       +
       aliases:

     

       4
       4
       +
         - PCC

     

       5
       5
       +
       tags:

     

       6
       6
       +
         - Apple

     

       7
       7
       +
         - decentralizedcompute

     

       8
       8
       +
       ---

     

       9
       9
       +
       Announced at [[Private Cloud Compute New Frontier]] blog post.

     

       10
       10
       +
       

     

       11
       11
       +
       [[Matthew Green]] initial reaction thread [[Matthew Green Apple PCC Thread]]

assets/2024/acls-dont.pdf

This is a binary file and will not be displayed.

assets/2024/cap-myths-demolished-SRL2003-02.pdf

This is a binary file and will not be displayed.