WIP

2 files changed, 57 insertions, 0 deletions

diff --git a/content/blog/epa-sgd-crypto/index.rst b/content/blog/epa-sgd-crypto/index.rst
index f2dd79f..ccbf648 100644
--- a/content/blog/epa-sgd-crypto/index.rst
+++ b/content/blog/epa-sgd-crypto/index.rst
@@ -45,10 +45,44 @@ Healthcare providers in Germany need to be registered with GKV Spitzenverband to
 insurance providers. Since these public providers constitute approximately 90% market share, the vast majority of
 healthcare providers are registered this way.
 
+Before the new national health record system, a number of healthcare IT processes have already been standardized and
+implemented by the parties above. In particular, every insured person already owns a cryptographic smartcard that acts
+as their proof of identity when accessing healthcare services. On the other side of such transactions, healthcare
+providers are likewise identified by cryptographic smartcards. Until now, these cards were used to facilitate billing of
+services from healthcare providers to insurers and to transfer prescriptions from prescribing doctors to pharmacies.
+
+A central role in this existing infrastructure is assumed by VPN gateways that link healthcare providers to
+the centrally-run backend infrastructure. Gematik GmbH calls these devices "Konnektor". They are specially-built
+hardware devices that contain multiple smart cards to authenticate the VPN connection towards the backend, and besides
+acting as a standard VPN gateway for client applications in the healthcare provider's network to tunnnel their backend
+requests through, the Konnektors also perform cryptographic operations in some of Gematik GmbH's protocols, such as
+authenticating certain requests using signatures.
+
 ## Design principles
 
+The new health record system was built on top of the existing infrastructure described above. In particular, access to
+health records is managed through keys stored in the patient's and the healthcare provider's existing smartcards, and
+all backend communication is tunneled through the existing VPN. Access to the files is mediated through the healthcare
+provider's existing patient management software. While in early drafts of the system, access to healthcare records
+through the patient's smartcard was gated behind a PIN, the impracticality of making the entire patient populace
+remember PINs led the implementors to scrap this provision, meaning that the patient's smartcard is all a healthcare
+provider needs to access the patient's record.
+
+A critical cornerstone in the system's design is that the system's designers decided that a lost smartcard should not
+lead to any data loss. As a consequence of this decision, while some of the record's access keys are kept on the
+patient smartcard, in contravention to conventional smartcard designs the same keys are kept accessible in a centralized
+key escrow system named "Schlüsselgenerierungsdienst" and abbreviated as SGD. Furthermore, these keys are not generated
+on the smartcard either -- instead, the key escrow system generates these access keys, one copy of which is then
+transmitted and stored inside the smartcard.
+
+The system supports re-issuing a smartcard to gain access to a healthcare record. Since the record's privacy pivots on
+this process, the system incorporates some organziational countermeasures that aim to make it hard to gain access to a
+re-issued copy of a patient smartcard without the patient's help or otherwise multiple colluding parties.
+
 ## Cryptographic design
 
+
+
 ## The implied adversary model
 
 While Gematik GmbH publishes detailed specifications of the systems they standardize, these specifications and some
@@ -59,6 +93,8 @@ threat model or an adversary model. As a result of this, we will deduce an adver
 published standards in the national healthcare setting. We will base our further analysis of the system on this
 adversary model.
 
+
+
 ## Previous reviews and audits of the system
 
 [0] https://www.destatis.de/DE/Themen/Arbeit/Arbeitsmarkt/Qualitaet-Arbeit/Dimension-2/krankenversicherungsschutz.html
diff --git a/content/blog/jupyterlab_notebook_file_oneliner/index.rst b/content/blog/jupyterlab_notebook_file_oneliner/index.rst
new file mode 100644
index 0000000..8885c4c
--- /dev/null
+++ b/content/blog/jupyterlab_notebook_file_oneliner/index.rst
@@ -0,0 +1,21 @@
+---
+title: "Getting the .ipynb Notebook File Location From a Running Jupyter Lab Notebook"
+date: 2025-06-30T23:42:00+01:00
+summary: >
+    If you need to get the path of the ipynb file in a running #Jupyter notebook, this one-liner will do the trick. It
+    seems chatgpt is confused, and a bunch of other approaches on the web look fragile and/or unnecessarily complex to
+    me.
+---
+
+If you need to get the path of the ipynb file in a running #Jupyter notebook, this one-liner will do the trick. It seems
+chatgpt is confused, and a bunch of other approaches on the web look fragile and/or unnecessarily complex to me.
+
+.. code:: python
+
+    import sys
+    Path(json.loads(Path(sys.argv[-1]).read_bytes())['jupyter_session'])
+
+The way this works is that for each notebook, jupyter starts a python "kernel" process that actually runs the notebook's
+code. That kernel gets a json file with info on the notebook's location on the disk passed through its command line.
+Since we're running code in that exact python process, we can just grab that json file from sys.argv, and read it
+ourselves.