Dear viewer, these subtitles were generated by a machine via the service YouTube and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/2572 Thanks!
[Music]
um so um before we start let's talk a
bit about me so I'm currently doing an
internship um where I work on secure
codebox which is an open source project
uh Cloud security scanner um and I study
computer science at theod damad where I
also did my thesis at Simo and this talk
is about my
thesis so um let's start with a quick
introduction into Internet Protocol like
in an abstract way um so what happens
when you visiting a website with your
browser and for example in the Apple
Cosmos with zafari so first your browser
um or operating system performs a DNS
request to a DNS resolver with the
particular host name so in that case
Simo and the DNS resolver responds um
with the corresponding IP
address then the browser establishes the
connection to that IP address so to the
web server um and then um performs an
HTTP request um to the web server to
which the web server just responds with
the web page
contents however there are privacy
problems in both of these steps so first
regarding DNS um you expose your IP
address to the DNS resolver together
with the content of the DNS query so the
um host name um you are requesting um so
the DNS resolver can simply create a
browsing history um consisting of your
IP address as an identifier for you um
together with these host names um as the
websites you visited so he knows like
exactly which um websites you
visited and in the Second Step um the
web browser to which you also connect to
and indirectly expose your IP address um
which is then often used by for example
advertisement companies as a unique
identifier again for
you there are some current approaches to
um counter these privacy problems
however most of them require some sort
of trust for example we have the DNS
resolver of cloudflare
1.11.1 which simply claims that yeah we
are not collecting anything which you
send to so very trust is required and
also um we have VPN Services um here for
example the very famous famous novpn um
which you all know from several um
advertisements on for example YouTube
and they claim um that there are a
so-called no loog VPN so that they don't
collect um um your traffic
either the way to go tool for privacy um
is tour when browsing the internet
however it is not really used by normal
people on a daily basis um mainly do its
bad speed
um in the context of apple and privacy
um they are currently strongly
emphasizing um it in all their devices
and services um especially regarding
privacy for example they introduced
their app tracking transparency um which
was very famous in media um yeah they
also have a buck Bounty program called
the Apple security Bounty however if you
read it like um very little there um it
also um pays you for privacy
vulnerabilities so privacy is that
important for them that they even pay
you money if you find some
vulnerabilities inside of
it with that um strong privacy focus of
Apple in mind they invented their iCloud
private relay um it is included with all
iCloud plus subscriptions which already
start at 99 Cents uh here in Europe and
it is available on Mac OS iOS and iPad
OS um whereas it where it is already
pre-installed so you don't have to
install any additional software um so
the entry barriers to use the servers
are very
low um about their service Apple says
that it prevents websites and network
providers from creating a detailed
profile about you while the browsing
experiments Still Remains fast so the
Privacy benefits um but you don't um
really know it because it you can still
browse like normal
the offered privacy is even so good that
carriers started blocking their service
so for example here um T-Mobile um
blocked private relay because they don't
get any vital network data and meta data
anymore because the offered privacy of
private relay is that
good um so why do we need private relay
and not just use a normal VPN or tour um
about that Apple makes several claims in
two sources so first in the white paper
which they published and second in
multiple talks at WWDC which is their
yearly developer
conference so regarding privacy they
claimed that their approach has privacy
built-in by Design so privacy built in
by Design and that users must not trust
Apple in order to use their service
because their service is so privacy
friendly and also regarding um security
that only valid Apple devices and
accounts are allowed to use their
service so no Linux device or something
like
that um now first let's talk about the
cause architecture which is described in
these two
sources so first um for DNS queres um
private relay deploys oblivious DNS over
https which is simply DNS over https but
with an additional proxy or here um
relay between the client and the
resolver um so the relay knows the IP
address of the client so who's making
the request but due to the established
https encryption um he doesn't know the
DNS C's content and also the resolver
knows the content but not who's making
the request because he only sees the IP
of the relay between
them um in the case of private relay the
uh relay between them is operated by
Apple um and the resolver is operated by
one of their Partners which is Akamai
Cloud flare or fastly and under the
assumption that the two parties are not
colluding um we successfully separated
the IP from the DNS CES
content regarding Network traffic the
idea is pretty similar to oblivious DNS
over https as um traffic is proxied
through their self-proclaimed Innovative
dual hob
architecture so how does that works so
first the client connects to the first
relay called the Ingress relay which is
again operated by Apple and over that
established connection to the second
relay called the ESS relay which is
again operated by one of their
partners and now um we have the
following case that um the the first
relay only knows the IP address of the
client but not the destination web
server and the second relay um don't
knows the client's IP address but the
destination of the web server and again
under the assumption that the two relays
are not colluding we again separated the
IP address um from the destination web
server um as private delay is a paid
service um there must be of course any
kind of Access Control deployed but when
considering the Dual hop architecture um
users must must authorize um especially
to the ESS so the second relay without
revealing their identity as that break
the previously mentioned separation of
um who's making the request and where's
where it is going
to um Apple introduced privacy tokens
for that case um which split the
authentication and the authorization
into two steps so we have an additional
party um the authentication server so um
first the client sends his his
credentials to the authentication server
and they perform the RSA blind signature
protocol together um which is just a
protocol call to generate private um
authorization tokens um without the
server learning the content of the token
and then the token is simply presented
to the relays to authorize
itself um knowing the architecture um we
can now Define threats and their impact
so we start with their security claim um
so Apple mentions that all connections
um through their servers are validated
at the account and the device level so
that means that users connecting have an
iCloud account and an active iCloud Plus
subscription and also that the
connection is originating from a genuine
Apple device so why is it interesting to
look into that claim um these IP
addresses are often used as anti-abuse
measures by several websites and apple
even proactively publishes all IP
addresses which they use so um it is
simply available at a CSV file um and
you can see like all addresses used by
the
service so the problem now is that
people started to WID listing all of
these IP addresses directly into their
firewall so for example here um we have
an entry of the developer fir of Apple
um where somebody is asking um how can I
whiteless these IP addresses on my web
server so they put that much trust into
Apple's validation process that they say
any connection from one of these IP
addresses is assumed to be genuine as
this validation um is fine um so um from
that IP addresses you can make requests
without any firal restrictions um if
somebody Whit listed
them and second regarding their privacy
claim we have two threats so first um if
the assumption is broken that the two
relays are not colluding um you can
perform traffic correlation and the
architecture itself is now similar to
like a normal VPN
um and we don't have these privacy
guarantees anymore and the second threat
um if you expose your identity um to the
second relay which should only know um
the destination of your
request now um we can start into um the
reverse engineering process with that
theory in mind and we can look how it
really works um so I did some videos for
that and um I will take you into the
process of discovering how works and
yeah so how do we start um first we have
to find the location um where we can
interact with the private relay so for
that we open up the system settings and
it's very hidden here in the profile on
the iCloud then we have to scroll down
and here we see private
relay and here um we have this window um
with a lot of text which is um a l
boring so you don't have to read it um
we have a simp Le done button which just
closes the model so also pretty boring
and we have a small button at the to at
the top to enable private relay um so we
can um just press the
button and we see um that the relay is
now Avail uh enabled um due to that PRI
delay on we also have now two options
two radio buttons available where we can
influence the selection of the IP
address which um web servers then see um
but that's not interesting for us and of
course now at the top um we can disable
private delay
again um so now to ensure that the
private relay is pretty uh is uh enabled
um we can just open up Safari um and
visit a website which gives information
about the IP address from which we are
visiting um the website um so here we
see that the ISP is akam my Technologies
so the second relay in that case is
operated by Akamai um we see that the
organization is set to iCloud private
relay and we also have an IP address
which is part of this um CSV
file so now we have like an interaction
possibility with the prior delay
implementation in the operating
system um so now for the reversing setup
um I started with fra um which is a
dynamic instrumentation toolkit in fancy
words and simply said um it just lets
you to inject uh JS code into a running
native process um that's very cool
because we can then um hook into a
running process and look into class
instances variables and other stuff um
during the runtime so with real
values directly built on top on Frida is
xpc spy um which allows us um to
intercept communication between um
different processes and we can view the
um xbc messages which is the
interprocess communication in the Apple
Cosmos um so for that
um we fire up in terminal first um and
we search for um the um process ID of
the settings so the settings are is
called Apple ID settings and here we see
the first entry um with the process ID
3271 that's the settings
process so with that um we can fire up
xbc spy
um with an minus rle um which is just um
there for passing Apple's um propietary
BP list format so don't mind about it um
and also the process
ID um now we have to be a little bit
fast because there's a lot of
communication going on between the
system settings and other processes um
so now um we open up the terminal we go
right before and the enabling step then
we launch xpc spy and wait for it until
it is attached so now we see here hook
enabled and we stop the script and here
we have like all communication of the
settings with other processes and here
um we look around to find interesting
stuff so there's a lot of uninteresting
stuff so UI stuff and stuff like that um
but here we have a pretty interesting
xpc call so there we are communicating
with a process called com apple network
service proxy and we sent there a
dictionary containing uh NSP server
comments with uh the value 20 so what
send is not that interesting for us but
we have like another process in which we
can um hook
into um so now we again try to find a
process um which has this network
service proxy inside of it um so we grab
from the processes everything called
network service proxy and here we
discover a file located in user lip EXC
and network service proxy so we simp
simply copy that file into our current
directory and we perform the file
comment on it to see what it is and here
we see it is a m universal binary which
is an executable um for
mechos and here we have two flavors and
we are choosing the arm version as I'm
on an arm
Macbook so to look in that binary we use
another tool um gitra and gitra is a
reverse um a software reverse
engineering framework again in fancy
words and simply said it allows us to
analyze um binaries or compiled
code so we can throw that binary um into
gidra and we
can look um into the code so here we
have the um raw arm code um which is
pretty hard to read um but getra also
provides some extraction for that so
here we see the five classes located
inside that binary and we we can look
into them um however like with these
whole implementation details in mind
that's a bit less um for all that
functionality um so there must be any
other um location where um stuff is
located so we look into the Imports so
what is um mounted into that executable
and we find a lot of Frameworks and
especially interesting here is the
network um service proxy framework so if
we have a binary and a library with the
same name um it is likely that they are
connected in some way um so we look into
that however there are some problems
because um the framework is part of the
private Frameworks folder um which is
only intended to be used by Apple's own
apps so if you for example write your
own um iPhone app and you include
functionality um of one of these
Frameworks um the app is straight up
rejected if you submit them to the App
Store um because of that um it is closed
source and of course there is no
documentation um yeah and further the
framework is not directly stored on the
disk so we need to extract it from the
dyld cach um which is some large cache
file which contains all Frameworks which
are then dynamically mounted during the
runtime um having that done um we can
again throw that framework in G again
and here we can look into the
functions and we see here the same
prefix as we saw earlier like these NSP
and we can look into it and we see a lot
of classes and here um we choose the NSP
configuration class just for an example
and here we see all functions of that
class so it's full
functionality
yeah um so now as we have already opened
it we can look into the configuration
which is part of this NSP configuration
class um because it fully controls the
behavior of Prior relay which we see now
and it also contains um a very privacy
critical part um so we are going to
explore
together um so first again we use a
frider tool now frider Trace um on the
NSP configuration class um with a star
so it um catches all function CS um um
to that class object um so now um we are
tracing 101 functions all of that NSP
configuration class and we can open the
system settings and enable private relay
and here we see all functions which are
called um of that class and here
interesting is the proxy configuration
function um as it's called like very
much and it very much sounds like a
getter for a proxy conf configuration
obviously so we use f Trace again but
now for the proxy configuration function
only to see its arguments and the stuff
which is then returned so we fire that
up
again and we open the system settings
and we enable prior delay and we see a
lot of stuff going on so for example
here directly down at the bottom um we
see the two um DNS oblivious DNS over
https resolvers which are currently
available for private relay so on the
top we have one of cloud flare and on
the bottom we have one of Akamai um
which is this um AKA secure. net
domain um now um we can scroll up a bit
and you see there is a a lot of
items and they are part um of a list
called proxies and this list contains
all available proxies which the prior to
client can then use um so here we see um
first the type which is called proxy hop
which defines if the relay is an Ingress
relay or an egress relay um then we see
some other not that interesting stuff um
we have the proxy URL um which is the
URL that the client is then connecting
to we have a version and then some more
interest not interesting stuff and at
the end we have the vendor um so the
partner which is providing the service
so in that case that is a server
provided by
Akamai um now uh we can scroll up again
and here we see a lot of entries um
which defines like the possible
combinations so the possible path um and
where the relays can be combined so for
example the first entry um is over the
um relay with the index Zero from the
proxies list which we saw and the second
one and that path has a probability of
30% of being Chosen and also we see
there down there with a probability of
um 65% and so
on um so where is this information
coming from um the client performs an
HTTP request to an API server um which
is um owned by Apple um upon multiple
triggers um these triggers are called
reasons in the implementation and there
are several um so for example if a relay
which are currently connecting to to
experience an outage um the
configuration is fetched again um if you
press this enable button or disable
button inside the settings you fetch a
new configuration and also it is fetched
periodically so without required user
interaction like for example every 8
hours so if we want to look into that
request we fire up wire Shar um which
allows us to record and analyze Network
traffic and again um we open up the
settings and we enable it and we disable
it so the configuration should be
fetched but as you see there is no
request um that's because Apple um
deploys certificate pinning which is a
technique to prevent sniffing of
encrypted Network traffic so exactly
what we want to do so um I use a fra
script by Andy Davis um which allows us
to extract these traffic secrets and
import them into wire shark um so that
we can see the request which are being
made so we do that and here we see um a
lot of http2 requests being made to um
the IP of the Apple API
server um so we see that request here
and we scoll a bit right there um we see
a lot of http2 stuff going on so this
magic header the window update and the
settings which is not interesting and
here the header's request which contains
the request itself which is performed to
the client um so we also have a lot of
headers so to sum up the configuration
fetch request is just a plain HTP get
request to that domain and we have
multiple headers being included in that
request by the client so for example we
have the xmk client info header which
contains information about the device
and the operation system from which the
request is being made from um we have
the reason so why the configuration
fetch request is performed and
especially interesting with we have a
header called xmk subscription token um
which starts with an ey and ey is likely
to be a Json web token so a w JWT token
and they are just simply decodable so we
can throw that header on the left um
simply in a tool to decode it and we get
the payload which is contained inside
these jwt's so let's zoom in into the
contents and here we we have two
interesting attributes so first we have
an attribute called account ID um which
could be an a unique account identifier
and also we have an device ID which
could be a unique device
identifier so first let's look into this
device ID um the device ID can simply be
found in the system settings under the
name um provisioning UD ID um in the
iPhone Vicki um which is an inofficial
apple Vicki um you find that these UD is
called a unique device identifier um
which uniquely identifies each s so
manufactured by Apple so yes obviously
the device ID is a unique device
identifier now to the account ID um it
gets a bit more tricky because you
cannot find it anywhere in the system
settings directly um so um I started
Googling like every possible
combinations of uh Apple iCloud account
ID ID and stuff like that uh and I was
successful uccessful even if it's Prett
pretty stupid to just Google these words
right away and because I found this
tweet by MK um where they talk about an
identifier called dsid or directory
service identifier which they found in
the Apple analytics um
service so let's look into that tweet
and here we see the dsid so that number
looks pretty similar to our account ID
they both start in the same number range
and are pretty
similar um in that tweet again um they
claimed that this ID um now in that
screenshot um it's called um DS personal
ID um is directly linked with all your
data Apple has about you so like your
full name your email address and
everything and to verify that that our
account ID is really um directly linked
with all my account data um I Ed a very
powerful tool we have here in Europe or
in Germany um which is the general data
protection regul regulation um because
we can simply request a data copy from
Apple containing all the data which they
have about
me so I did that and um I got especially
the Apple account ID and device
information stuff is interesting and I
got this table back and here you see on
the left now it's called Apple ID number
which is the account ID um and directly
linked to my Apple ID my first name my
fake last name my phone number my
address which I entered and everything
so yeah of course the account ID is
definitely a unique account identifier
and linked with all of my data which
Apple has about
me um so now with that in mind um let's
remember back the Dual hop architecture
which private relay
deploys um so what do we know um so
first as you saw the configuration um
fully determines all available relays
and also the
combinations um it is fetched before
every activation and even periodically
without user interaction it is
intransparent to users so you cannot see
to which relays you are connecting to
and also interesting um the account and
device ID so here I have an additional
additional entity um the API configur
the API conf configuration server and
what the header does is that you send
your account and device ID to that
server so you tell them indirectly who
you are from what device you are
connecting um from and like everything
and now um as Apple claimed that their
service provides privacy by Design um we
can now assume that they want to abuse
that personal information because they
say oh now I want to Target that
specific user on that specific device
device um to De anonymize his traffic so
um they can decide to serve you not a
genuine configuration um but a
configuration which only contains
exactly two relays which are both
operated by Apple so now um the
architecture looks like that and we have
two apple relays um that breaks the
assumption that the two relays are not
colluding and now we have the same setup
as we would use like a normal VPN so no
privacy guarantees
anymore um regarding their these two
claims which they make we can corrected
to that their approach has some privacy
built-in by Design so it's bit above a
VPN but not like comparable to the
Privacy offered by for example tour and
especially that users must trust Apple
that they don't abuse your personal data
to serve you such a malicious
configuration how to fix that problem um
the first and very easy fix would be to
just remove the header which is sent
which contains this account ID and
device ID um because I wrote a small
python script which also fetches the
configuration and it doesn't even check
this header so you can just let it out
and it also works fine so that's very
easy however the CAA problem still
persists as you are making again an HTTP
connection to fetch the configuration
and you again expose your IP address and
apple could abuse that as well um that
is not that critical as sending like
your full account data and device
information to them um so it's less
critical but it's still like a greater
problem of their architecture um with
their configuration
approach now we come to their security
claim um where they said that only Apple
devices can connect to to private relay
and um I found it at least let's say
interesting um that they want to limit
uh Network protocol to a certain device
um so to bypass that restriction um I
wrote an non implementation of their um
client um to make a connection to that
relays um so first what do we need to
connect to private relay so first we
need these privacy tokens um which are
used for authorization um here we are
handling the authentication part as a
blackbox so we only get these privacy
tokens and fine and of course we need to
implement the protocol um which private
way deploys which is here the mask
protocol um which is proxying over
HTTP um what is a privacy token a
privacy token is just raw bytes and
consists of four part parts so first we
have a leading one um then we have the
ID of the public key which is used to
generate this token um by the
server we have a random token which is
generated on on the device and we have
the signature of the token which is
blindly made by the authentication
server um the request or the RSI blind
signature protocol itself um is pretty
similar to the request um of the
configuration fetch however that time it
is a post request so not just a get
request and we sent there a list of
several tokens um so these tokens from
the slide earlier and some additional
authentication data um to prove um that
you have an iCloud account and that you
are an Apple device and the
authentication server responds with the
signatures which you can put together
with the tokens um to build a privacy
token
um so um the client automatically
fetches these privacy tokens and
periodically and if they are like low in
number um so I wrote a small python
script which just extracts them because
they are likely not Spann all in a
single session so the client stores them
on the device to use them later to
prevent an additional um
request um so there token extraction
script um simply um reads these stored
tokens from the device um so in that
case um we extract the tokens from
Akamai and write them to our current
directory current directory and here we
see we have um 50 tokens for Akamai
which we can then use for authorization
to the
relays um they also have an expire date
and that is also checked so um you
cannot store them forever and use them
like in 5 years um to authorize yourself
so the tokens need to be um some kind of
fresh the client implementation itself
um is over the M protocol um it is
pretty new and currently standardized by
the
ietf and on the right um You can see the
protocol step uh stack so as you can see
um it is built upon quick and TLS and
with an HD pp3 implementation on the top
um where also the mask implementation
proxy lives um so you want if you wonder
um why would you proxy um traffic
especially Network traffic over HTTP
which is normally a protocol like to
fetch websites and to get the response
back um there are several benefits so
first it very obvious um it has these
TLS uh encryption inside of it so it's
https um which is um pretty common and
assumed to be secure and also we can
bypass firewalls with that who block for
example um IPS
traffic um s htps runs on Port 443 UDP
or TCP which is likely not to be blocked
in network um because then nobody could
make Network
requests um we need to make some
adjustments to part of that
implementation so for example here in
the TLs layer um because the white paper
mentions that the TLs handshake does not
use a certificate for authentication but
raw public keys so normally in the TLs
handshake the client sends the client
Hello message to the web server and the
web server responds with several
messages and again with its certificate
and the raw public key only contains the
and the certificate contains a key and
the raw public Keys is like only that
key out of the certificate without the
additional overhead information so we
need to adjust that in our TLS handshake
to make it
work um then the mask implementation
itself um uses the connect and connect
UDP method of
HTTP um The Connect method for TCP
traffic and the connect UDP traffic um
for UDP or quick
traffic um so you can see here on the
right um the headers of the connect UDP
request where we have the method set to
connect the scheme https and um most
importantly the protocol is set to
connect UDP to indicate that you use
that protocol and also in the path you
define the destination to which you want
to proxy um your traffic
to so um the procedure to make uh to
Tunnel a request over a relay now works
as follows so first you establish a
connection to a relay with a connect
method where you also present a privacy
token to um authorize yourself and if
everything works fine the relay responds
with a 200 okay status code so the
connection is assumed to be
established then um here in that case we
just simply a tunnel an HTTP 1.1 request
over the relay to that site which we saw
earlier which gives this information
about the implementation and we get the
response
back so let's see that in action um
again I wrote a python script which can
make that and we can follow that
up and here we
see that the whole uh that we get the
response back we get the 200 status code
back from the web request and here we
see the information about the IP address
and here again we see the ISP ass set to
AKA my Technologies the organization is
iCloud private relay and again in the
query we see that the IP address from
which we are making the request from um
is also contained on that CSV
file so regarding Apple security claim
um we can correct that that it's not
correct because obviously that client
can run on a Linux device on a Windows
device or in whatever um where python
can run and you have an internet
connection so that's wrong with the only
limited
that you need an Apple device as a
donator for these privacy tokens which
you can then use in the
authorization um this if so why this
claim does not hold has a large impact
um as you saw earlier due to that white
listing because now it is very easy to
generate like spam Bots for example um
if the IP addresses um are WID listed
and you can make arbitrary amount of
requests with like a simple um prox
client all
right um now a quick conclusion so
reverse engineering is fun um privacy by
Design is hard um especially um as you
saw that the architecture itself with
the separation into the two relays um is
assumed to be P privacy friendly however
that simply CH chose of configuration
like fully destroys the whole
architecture and last last but not least
that limiting access to a certain device
type um in a network protocol is at
least let's say difficult as one could
simply um reimplement the protocol for
himself and just make the
requests all right so um thank you for
your attention and feel free to ask me
questions and I would like to especially
thank yisa and Matias um which
supervised me during my thesis and that
work um a lot So yeah thank
[Applause]
you I'm mute yeah so we have some
questions from the
audience hi uh yes tying to devices is
at least difficult yeah um did you
happen to see in uh the when it's
request those tokens whether uh it is
checking enforcement of any remote
attestation of the identity and
integrity of the device that's making a
request yeah so there's a lot of stuff
going on which is also like um pretty
deep down into the operating system um
with keys which are generated upon the
um initial setup of the device um so
there are some stuff going on but I
don't know like the very deep technical
details of
it
so I noticed with the public key the raw
public key that they send they don't
have revocation
information uh which would normally be
sent along with
certificate so say that the keys of
those servers would leak you would have
no way as a user to establish that the
public key actually hasn't been revoked
so have you looked into that as
well um so normally like in the
certificate you rely on that public key
infrastructure and containing these
trusted certificates which are stored on
your device and the approach of the
configuration is now um that like apple
um holds all of these certificates for
you and only serves you um the
certificates which they assumed to be
genuine um in that configuration to you
so it has like the same um outcoming but
you um yeah you move like this um point
of trust from your device to the apple
one any more questions I don't see any
hands
then what there's one here okay
right I assume Apple has some mechanism
to fight against unwanted uses of this
anization like do have they published on
how they do it do they like collude
between the two relays or what's that um
they claim that they perform some um
asynchronous double um double spend
prevention of these tokens but in
general we don't know and they don't
make any claims about it and we can only
see it as a blackbox so we don't know
but my question is like if not like
w
limit I don't hear it I'm not only about
like double usage and the usage limits
but about
preventing people from using it for
purposes they that would be bad PR for
them basically is there something about
that so if that would be possible that
would break the Privacy claims of their
architecture so yeah of course that
would be
bad uh I would like to know if you ever
contacted with the apple and did you get
any feedback about this like thank you
or any Bounty or anything yeah I
reported it to their um um bu foundy
program and there's um currently um an
open disclosure going on um but that was
like um two or 3 months ago and still
then nothing changed so that's like
still the state of the
service we have the question on the very
far left of the
stage
y
okay I need closer to the
middle in your for truck you mentioned
uh that the Apple Dart sler you excluded
the uh the header why did you do that
and can you talk more about that with
your Pyon script you excluded the the
head before putting everything into the
D Scher yeah um so the request you are
making to get the configuration contains
this jbt and it it's also named like
this authorization so at first you could
think that it's supposed to prevent
people without such a token from
accessing the configuration um but it's
not checked and because it has like this
privacy critical impact um I suggested
to just remove it from there as it's not
even checked on the server so yeah
well thank you very much that be on time
exactly um thank you for the talk thank
you thank you for
coming