On Access Control, Capabilities, Their Equivalence, and Confused Deputy Attacks

[Alan Karp]

https://ieeexplore.ieee.org/document/7536373

I've only skimmed the paper, but I understand that the authors claim capabilities don't prevent all confused deputy attacks.  I don't agree.

A confused deputy vulnerability is when the deputy uses its permissions on a resource designated by someone else.  If I understand correctly, this paper says there's another form where the deputy uses its permissions to write data provided by somebody else.

First of all, that's not usually a vulnerability; you do it every time you log the requests you receive.  Even when it is a vulnerability, I wouldn't call it the confused deputy as Norm defined it.

--------------
Alan Karp

[John Carlson]

Is this like writing to random integers with write() instead of UNIX file descriptors?   Someone could send a deputy an integer that either match or didn’t match one of your file descriptors.

But capabilities (objects) are supposedly unforgeable, so a file descriptor is not a capability.   Perhaps they are confusing integers with capabilities.

If capabilities are instances of resource combined with operations, there’s no way to specify another resource than the “hidden” by the capability.

I don’t know if “data” is a resource or not.  There’s probably some confusion about whether primitive data is an object or not, in some languages.   Do I need a capability to change an integer-valued variable?  Do integer resources even have operations?  integer.square()?   Where’s the capability?  Sure, I can share the capability to square an integer, but I wouldn’t share the integer in that case.

Perhaps this is why my idea of encrypting SQL statements and parameters separately never flew as capabilities.

I am wondering how capabilities as keys are unforgeable, but that’s a whole another question, and probably involves encryption.

Are bearer tokens stored in encrypted databases?  How does one store bearer tokens for reuse?

John 

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z39nD9JbQ2EgvwV27JEjBkYBDpv5XqzOS1QG38SGkNP9A%40mail.gmail.com.

[Matt Rice]

First thing I'm not certain in the paper about is the following:

The paper Alan linked:
>> It has been claimed in the past that in the presence of Miller et al.’ s property A, Cs prevent CDAs

This references both Norm's original confused deputy paper, capability
myths demolished, and another paper.
I don't see anywhere in Norm's paper where he actually claims that
they are prevented. The closest I could find to that
in Norm's description of the confused deputy problem is the following...

Norm (The confused deputy problem)
>> If you try to solve this problem without capabilities, remember that the file (SYSX)STAT must also be protected.)
>> The capability solution would endow the compiler with a direct capability to the statistics file.

He seems to merely point out that there exists a solution with
capabilities which does not require knowledge and encoding of all the
security properties
and states. Making even providing a solution outside of capabilities
relatively intractable. At least that is what I always took from it.

Capability myths demolished:
>> capabilities provide much better support for least-privilege operation and for avoiding confused deputy problems.

Then later this gem...

>> Eliminating ambient authority helps make it possible to avoid confused deputies, but doesn’t guarantee that
>> deputies will never be confused.

And this:
>> Even if one can distinguish the keys, deciding to try all available keys puts one at risk of becoming a confused deputy.

I don't see anywhere these two papers purport to prevent confused
deputy attacks?

[Alan Karp]

On Fri, Oct 2, 2026 at 3:25 PM John Carlson <yott...@gmail.com> wrote:

I am wondering how capabilities as keys are unforgeable, but that’s a whole another question, and probably involves encryption.

In that case, you trade unforgeability for unguessability. 

Are bearer tokens stored in encrypted databases?  How does one store bearer tokens for reuse?

I'm not an expert on the specs, but I don't recall any of them even mentioning storing them.  That means they're leaving it up to the application to protect its tokens.

--------------
Alan Karp

[Alan Karp]

On Fri, Oct 2, 2026 at 3:30 PM Matt Rice <rat...@gmail.com> wrote:

I don't see anywhere these two papers purport to prevent confused
deputy attacks?

It is certainly possible to have a confused deputy with capabilities.  I managed to do that in Client Utility by examining a list of capabilities to find a match.  In that case, I had separated designation from authorization, the designation being which capability rather than which resource.  That's the kind of newbie mistake I've seen in some specs.

You can create vulnerabilities in any system if you allow for bad design.  I'm assuming we're talking about well designed systems used properly.

--------------
Alan Karp

[Matt Rice]

I take from "prevent", and even less ambiguously "CDA-freedom" that
they are purporting a much stronger property, the non-existence of
confused deputy attacks.
It seemed to me they were ascribing that to both Norm's paper, and
myths demolished. While Norm's paper doesn't seem to purport
CDA-freedom, and myths demolished seems to claim the opposite. That
while capabilities allow one to write programs without confused-deputy
problems, they acknowledge explicitly and counter to the claim in that
paper that it's still possible to create confused deputies with
capabilities.

Anyhow, at least to me in my first cursory reading it seems to me like
they're ascribing much stronger claims to those papers than they are
actually making about CDA-freedom.

[Alan Karp]

I don't have the math chops to understand what they say about the classic confused deputy, except that they say in prose that it does (can?) prevent CDA (confused deputy attack).  What I disagree with is their example, where they claim the deputy using values provided by the adversary is a CDA.

--------------
Alan Karp

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CACTLOFp0XaOxjkcCmd8huwmHXG%2B-XWhYPAMFjAG_4wA6Wj9qXw%40mail.gmail.com.

[Matt Rice]

I doubt I have gotten that far yet (to the example you refer), I'm
just saying I'm really skeptical of that line which I read as meaning:
"capability myths demolished says Property A implies there does not
exist confused deputies",
when capability myths demolished seems to go out of its way to explain
how to bootstrap a confused deputy by enumerating over
capabilities. Perhaps I'm reading the "It has been claimed in the
past" as being claims made by the following references when the claims
could have been made by anybody? I really don't know...

> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z1N%2Bxq-tJZb4RDn_Sqe6HVMEyf3_x6T2bK0Zo5%3DGmeDMg%40mail.gmail.com.

[Matt Rice]

So reading further, It seems like it kind of depends upon what one
considers a designation?
While booleans and the like are certainly not a very good designation,
If one considers value based
conditionals and indexing as designations these would seem to fall
under either "not confused" because it was designated, or designation
without authority.
In the case where one considers only meaningful labels that preserve
context to be designations the definition of confused deputy might
squeak by?
I definitely don't follow the description of sql injection attack, as
it doesn't actually vary its authority?

> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z1N%2Bxq-tJZb4RDn_Sqe6HVMEyf3_x6T2bK0Zo5%3DGmeDMg%40mail.gmail.com.

[John Carlson]

Typically, this might be SQL statements with parameters, but not bind parameters.  So if you’re doing string-parameters concatenation of values without validating input and output of concatenation, that’s confused deputy.

But I don’t think SQL is capabilities.   There aren’t any objects in SQL, unless you’re talking something like PL*SQL.  Records and rows, sure.

Are ORMs capabilities?

John 

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CACTLOFrH%2BFuUy%3Dh-e-27CpTTwED%3DDDm4jV9u-Y9mdCG4_53FdA%40mail.gmail.com.

[Matt Rice]

It's a vulnerability for sure, but the relational model isn't even
turing complete, if we consider a simplification of the problem
of unvalidated input, like CSV with data containing unescaped commas,
I guess there is some amount of designation via table names.
But if we assume that a database is one gigantic file, and file
descriptors are capabilities, it is just one big spatially sorted
bundle of authority.

Anyhow that is basically what I meant, there is no separation of data
from capabilities really...

> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAGC3UE%3Dh6jV48bOTuZs%2B_YH2kPK8xO0enF_u53VjEr534LgAEQ%40mail.gmail.com.

[Matt Rice]

On Fri, Oct 2, 2026 at 3:30 PM Matt Rice <rat...@gmail.com> wrote:
>

Sorry, In this one myths demolished is talking about property D, while
the other paper is talking about property A. mea culpa.

[Matt Rice]

Two things the paper says this, which is a very strong property.

> It has been claimed in the past that in the presence of Miller et al.’ s property A, Cs prevent CDAs

"in the presence of property A, Capabilities prevent confused
deputies", that is to say in the absence of any given program and
regardless of any bad program design.
whether property A alone makes it impossible to produce programs
containing confused deputy vulnerabilities.

I just want to point out here Alan, that the version of Property A:
you use above, and the version of Property A: in capability myths
demolished where
yours: "Do not separate designation from authorization", and in myths
demolished "No designation without authority",
are not exactly the same. And I think the way you interpret it is
stronger than how they did.
Especially since when they discuss "implicit designation", they mean a
designation which has been separated from authority
but which is authorized because the ability to designate it implies
the authority or something to that effect.

I tend to assume a very strict "No shared designation", and note that
their model includes provenance which is stronger than anything
required by any of these versions of property A.
*who* is authorizing and who is designating aren't properties that are
of concern to property A.
"No shared designation" implies that only the one who invented the
designation is able to use the designation, and thus all authority is
passed anonymously by value.
rather than by name. This tends to produce a chain of provenance
implied at each point the authority is conveyed, allowing me to just
ignore designation entirely.

What I guess I don't understand is if we take such a loose
interpretation of "no designation without authority", where the
existence of the designation implies the authority who is to say that
acl systems have confused deputies because their designations imply
authority. I suppose the "confusion" is that acl systems list who is
authorized explicitly and those lists are a subset of who may
designate, which is right?

That is to say if we consider who is authorized as the source of
confusion, I can see the argument that these aren't confused deputies
due to the lack of a differing set of authorizations. However it feels
extremely weird to me when we can create posix emulation layers
running on top of on top of pure capability systems, and when we run
the same exact programs with confused deputy problems on other
systems, that these might somehow not be confused deputy problems? If
we can say with some program equivalence proof like homotopy type
theory that these programs are exactly the same with the exact same
vulnerabilities, then I kind of have trouble faulting someone for
referring to them by the same confused deputy nomenclature...

sorry for the long rant...

[William ML Leslie]

On Sat, 3 Oct 2026 at 09:02, Matt Rice <rat...@gmail.com> wrote:

I take from "prevent", and even less ambiguously "CDA-freedom" that
they are purporting a much stronger property, the non-existence of
confused deputy attacks.

This is the impression I am getting, too.  I'm not finished digesting it, but I have thoughts I want to get down, too.

Part of the challenge with characterising a confused deputy attack is that it's supposed to be that the author of the deputy didn't intend to use its authority, but there are a lot of use cases where we absolutely intend for the deputy to use its authority on behalf of the user.   Membranes, the mechanism that makes enforcing abstract security properties tractable in a capability system, rely on doing just that.  Which is why I think this formalisation is of limited utility.  I think that there is a property worth formalising, but before we get to that, I need to discuss another point mentioned in the paper in passing that needs correcting.

How we got the Confused Deputy Vulnerability

As a second contribution, we formally examine confused deputy attacks (CDAs) [16], which may have been the primary reason for the invention of capabilities.

I get that it is difficult to understand the relationship.  Let me flesh out the story a little better.  I know that many on this list know the history, but there are a few pieces that are routinely misunderstood, so hopefully I can clarify this point and wrap it up in a little bow.

Norm gives some details on the timeline of KeyKOS, and hence his interaction with capabilities, here: http://cap-lore.com/CapTheory/KK/EKK.html

When Norm first wrote about the confused deputy vulnerability, he was working at Tymshare, who rented out time on their wide range of computers.  Ann Hardy wrote the first of the operating systems at Tymshare, based on the Berkeley Timesharing System.  According to her Oral History at the Computer History Museum, customers started hacking the system "almost immediately".  Enterprising computer users loved finding ways to get extra CPU time or disk space, but seemed to take similar glee in just hanging the system.  You might say that, having invented cloud computing, they were discovering the impact of malicious users without any sort of prior art.  This really is the birth of the cybersecurity industry as it exists today.

From Norm's writing, it sounds like the GNOSIS team spent quite a bit of time trying to figure out what security problems could not be solved with capabilities.  In documenting the design process in the 1970s, he remarks in hindsight:

I recall now (2017) that we were then committed to capabilities but not yet convinced that they were a universal solvent that “solved all interaction problems”. This was not evident to us. We sought solutions to forms of interaction not evidently available via caps. Alas it is still not evident. We, however, never came across such a problem capabilities could not solve. We gradually came to realize that if there were non capability like relationships, we would loose (sic) some styles of security arguments that pure capabilities allowed.

It's in this scope specifically that Norm first wrote about the Confused Deputy Vulnerability.  After a decade of watching people attack their legacy time-sharing systems at Tymshare, it was remarkably obvious that the attack described in the CDV paper would not have worked on a capability system.  Not that you couldn't make software that misused its authority if you really wanted to, but that you could write software and be confident it used its authority correctly, and that you didn't have to try very hard to get this right.  The ability to write components defensively is the part that is worth formalising, if that isn't clear, and I think MarkM's thesis did a pretty decent job of describing the details.

The other thing that I think is non-obvious and bears pointing out is that publishing the CDV paper upset the apple cart.  The prevailing wisdom of the time, thanks to Lampson, was that capabilities and access control lists were two sides of the same coin, with little reason to favour one over another.  The CDV paper was clearly a disproof of this: the dynamic nature of permissions matters in practice, and capabilities enable it to work safely, almost by accident.

Explicit Access Policy

One paragraph of the paper reads:

> An alternative to this implicit specification of authority is to specify, via an explicit access policy, what references (capabilities) each principal is authorized to access and to ensure that each principal can only obtain references that it can legitimately use. This approach is taken in some practical implementations of object capabilities, e.g., Firefox's security membrane [5], which intercepts all transmissions from one domain to another and restricts objects (capabilities) in accordance with relevant policies (Firefox' s policies are drawn from web standards like the same-origin policy). Our capability semantics models a simplified version of this general pattern. It intervenes on every transmitted and computed value and checks that if the value is a reference (capability), then the executing principal is authorized to use the capability according to the access policy. This intervention is computationally expensive, since every value must be checked.

I honestly don't know what to make of this.  The reference in [5] does not exist.  The paper was written in 2016, so maybe they really were doing this.  I can't fathom why.  If you really want to do this sort of confinement, a c-list would suffice, and that would not be computationally expensive.

Implicit Designation

Examples 2 through 4 I would not consider confused deputies, but the exploration is interesting nontheless.  Given that SQL Injection is one of only two items on the original OWASP Top 10 that can't be avoided just by switching to capabilities, this probably deserves its own digression.  We have a history of integrating capability security into languages (with the FLEX ALGOL compiler the latest brick in that wall) and a comprehensive breakdown of what is going on in this space would be stimulating.

--

William ML Leslie

responsible ai use is not a thing

[Matt Rice]

On Sat, Oct 3, 2026 at 12:51 AM William ML Leslie
<william.l...@gmail.com> wrote:
>
> Which is why I think this formalisation is of limited utility. I think that there is a property worth formalising

I feel like strong properties, even if they are too strong to be
practical, can still be interesting. In particular
just because we have a strong property, we can still weaken it
allowing confused deputies into existence for programs admitting the
weak properties.
The one which targets the stronger model still may contain reduced
auditing requirements, simply because its program model precludes more
vulnerabilities.
Similar to rust with safe/unsafe language subsets. The more safety
properties that we can machine check the more we can reduce auditing
burden imo...

[Alan Karp]

No problem with the long rant if you forgive me for the delayed response.  I wanted to give your email the attention it deserves.

I like your framing that in ACL systems the set of authorized parties is a subset of those who can designate, which means you can create a designation without authorization.  In fact, you can create a designation out of whole cloth, e.g., by guessing file names.

--------------
Alan Karp

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CACTLOFr13mtfLskphDbyBynE76QL5V8cNADzKcnLqd6hzmE%2B7g%40mail.gmail.com.

[Alan Karp]

On Sat, Oct 3, 2026 at 12:51 AM William ML Leslie <william.l...@gmail.com> wrote:

Part of the challenge with characterising a confused deputy attack is that it's supposed to be that the author of the deputy didn't intend to use its authority, but there are a lot of use cases where we absolutely intend for the deputy to use its authority on behalf of the user.   Membranes, the mechanism that makes enforcing abstract security properties tractable in a capability system, rely on doing just that.  Which is why I think this formalisation is of limited utility.  I think that there is a property worth formalising, but before we get to that, I need to discuss another point mentioned in the paper in passing that needs correcting.

You're making a good point about what constitutes a designation.  I think only something that explicitly points to a specific resource is a designation.

I'll give you a silly example, a web server.  Only the server and admin have access to the file containing the home page, call it home.html.  The server will show you the contents of that file if you do a GET on the URL but nothing if you do a GET on the file name.  By my thinking, the URL does not designate the file.  It designates something that the web server uses to know which file to designate.    

--------------
Alan Karp

[Alan Karp]

On Sat, Oct 3, 2026 at 1:42 AM Matt Rice <rat...@gmail.com> wrote:

Similar to rust with safe/unsafe language subsets. The more safety
properties that we can machine check the more we can reduce auditing
burden imo...

We also need fewer security checks at runtime.

--------------
Alan Karp

[Matt Rice]

On Mon, Oct 5, 2026 at 10:46 AM Alan Karp <alan...@gmail.com> wrote:
>
> No problem with the long rant if you forgive me for the delayed response. I wanted to give your email the attention it deserves.
>
> I like your framing that in ACL systems the set of authorized parties is a subset of those who can designate, which means you can create a designation without authorization. In fact, you can create a designation out of whole cloth, e.g., by guessing file names.
>

No worries about the delayed response. I'd probably be a much better
communicator if I were better at delayed responses...

I think the most important part I was trying to convey is that this
later statement, "you can create a designation out of whole cloth,

e.g., by guessing file names."

can still be applied to authorized resources, depending upon the
strength of our Property A is in use (or perhaps depending upon one's
interpretation of it).
This allows program authors to create probabilistic guessable
resources from unforgeable capabilities, a weakening of the model even
if by the system model of authorization such resources are still
authorized.

If we consider "No designation without authority" as `designation ->
authorized(resource)` or on an acl system `designation -> resource`
(authorized or otherwise)
I view your "no separation" qualifier as talking more about tuples in
the sense that it might be okay to share a `(designation, resource)`
than implications or functions from designations to resources. And "No
shared designations", to be about the non-existence of implications
from designations to resources so `not(exists(designation ->
resource))`. at least for shared functions.

So that is where I feel like all the nuance in the paper is coming
from, their definition of confused deputy involves implications from
designations to resources,
while their interpretation of property A: allows these implications.
While other definitions of confused deputy require implications to
unauthorized resources, and all the interpretations of property A
prohibit those.

Anyhow, my feeling is that a lot of the impedance mismatch in these
discussions revolves around whether or not a designation -> resource
implication
even for authorized resources fits the definition of a confused
deputy. and alternately whether property A allows the exchange of
designations for resources.

If you're using a strict definition of confused deputy which prohibits
the exchange of designations for resources, then you also require a
strict definition of property
A, which prohibits the exchange.

It may be better to use different nomenclature to avoid this
ambiguity, "vulnerable deputy", when talking about
designation/resource exchange on capability systems where by the
system definition such authority is authorized, but doesn't stop
program authors from making mistakes via assuming unguessability from
a guessable designation.

Then reserving "confused deputy vulnerability" for the similar
vulnerability when acting on unauthorized resources...

I don't know if that helps or if it's just more blathering.

> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z1S0QqJfMeFc8t1u0PXppO_XFy1rPnP9bzt14Sq3eAWLQ%40mail.gmail.com.

[Alan Karp]

On Mon, Oct 5, 2026 at 12:17 PM Matt Rice <rat...@gmail.com> wrote:

Anyhow, my feeling is that a lot of the impedance mismatch in these
discussions revolves around whether or not a designation -> resource
implication
even for authorized resources fits the definition of a confused
deputy. and alternately whether property A allows the exchange of
designations for resources.

Every system has a way to use a designation to refer to a resource.  The question is permissions.  Any separation between designation and permission is the source of a confused deputy vulnerability.

It may be better to use different nomenclature to avoid this
ambiguity, "vulnerable deputy", when talking about
designation/resource exchange on capability systems where by the
system definition such authority is authorized, but doesn't stop
program authors from making mistakes via assuming unguessability from
a guessable designation.

Then reserving "confused deputy vulnerability" for the similar
vulnerability when acting on unauthorized resources...

The confused deputy vulnerability has such a simple definition, I prefer to limit it use to denote the case where the deputy uses its permission on a resource designated by someone else.  Using the same term for other vulnerabilities, such paper's of writing data provided by someone else, will be confusing.

--------------
Alan Karp

[Matt Rice]

I suppose what I'm trying to say is that it doesn't appear to be using
restrictions on shared designation in their definition of confused
deputy.
It rather seems to say that a confused deputy is *just* about the
inability to reach unauthorized resources.

Then it appears to say that according to property A in myths
demolished that reachability implies authorization, and shared
designation implies reachability, thus shared designation implies
authorization. Which according to your definition of confused deputy
above would allow confused deputies since it allows shared
designations.

Then rather than try to restrict shared designations, it attempts to
restrict the ability to designate unauthorized resources.
With designation being just normal values, the things that fit the
formal definition of plain old "data value" on the left hand side,
resource on right start to look like normal parsing problems.

I too prefer the definition like you gave that restricts shared
designations, I would change your definition wording only slightly to
"where the deputy conveys permission", where conveyance can be either
usage/direct invocation of the permission by the deputy, or indirect
transmission of the permission for future invocation outside the
deputy.

anyhow...

[Alan Karp]

I must have missed something.  What's "shared designation"?

--------------
Alan Karp

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CACTLOFrMTp%2Bm81wjwgDXO0ZpzP_M1wnDSd9WoYzHMmW_8-bQEw%40mail.gmail.com.

[Matt Rice]

It is just shorthand for a data value or name which designates a
resource where the resource exists across a sharing boundary.
For instance in your definition you gave "a deputy which uses its

permission on a resource designated by someone else."

In that case the deputy would be taking a shared designation, it's
just the resource name.

[Matt Rice]

Let me try an alternate (but intended to be equivalent) definition
eschewing designations all together

demolished according to this paper: data channels which allow you to
reach capabilities are either authorized or your system is in
violation of property A:
this paper: only capabilities you are authorized to access are
reachable via data channels.
your definition: only capability channels can reach capabilities...

[Alan Karp]

On Mon, Oct 5, 2026 at 7:29 PM Matt Rice <rat...@gmail.com> wrote:

demolished according to this paper: data channels which allow you to
reach capabilities are either authorized or your system is in
violation of property A:

 

this paper: only capabilities you are authorized to access are
reachable via data channels.

Sounds very ACL-like

your definition: only capability channels can reach capabilities...

--------------
Alan Kar

[Matt Rice]

On Mon, Oct 5, 2026 at 9:23 PM Alan Karp <alan...@gmail.com> wrote:
>
> On Mon, Oct 5, 2026 at 7:29 PM Matt Rice <rat...@gmail.com> wrote:
>>
>>
>> demolished according to this paper: data channels which allow you to
>> reach capabilities are either authorized or your system is in
>> violation of property A:
>
>
>>
>> this paper: only capabilities you are authorized to access are
>> reachable via data channels.
>
>
> Sounds very ACL-like
>

Seems fair, but also exactly the kind of weird thing one might expect
to observe from a system
built to compare ACLs and capabilities for equivalence.

>> your definition: only capability channels can reach capabilities...
>
>
> --------------
> Alan Kar
>

> --
> You received this message because you are subscribed to the Google Groups "cap-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z3HVtBqrMO3SbRvvZ5QLkbzcRwOMFZCbA9Ct%2BQd_6T0ug%40mail.gmail.com.