all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Gabriel Goller <g.goller@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>
Cc: Proxmox Backup Server development discussion
	<pbs-devel@lists.proxmox.com>
Subject: Re: [pbs-devel] [PATCH backup/proxmox-backup 0/4] fix #5463: add optional consent banner before login
Date: Thu, 23 May 2024 14:10:08 +0200	[thread overview]
Message-ID: <20240523121008.c6p4eixaatbzwhzl@luna.proxmox.com> (raw)
In-Reply-To: <fc22ec23-a300-488d-821f-bea1285881a8@proxmox.com>

On 23.05.2024 11:24, Thomas Lamprecht wrote:
>Am 23/05/2024 um 09:51 schrieb Dominik Csapak:
>> On 5/22/24 17:31, Thomas Lamprecht wrote:
>>> This is currently still missing any actual barrier as it's all frontend,
>>> shouldn't there be a cookie that is checked on the backend side if a
>>> consent.txt exist? If this specific consent type (RMF AC-8 for US gov)
>>> doesn't need that, it might be worth to replace the generic text box
>>> with a type selection for that, we could always add a "custom" type
>>> that takes a generic text and extent that with an option about how
>>> strict it should be checked, if we get this now.
>>
>> when checking https://csf.tools/reference/nist-sp-800-53/r5/ac/ac-8/
>> (not the "official" document, but very close , the original can be downloaded
>> in docx form here:
>> https://csrc.nist.rip/projects/risk-management/about-rmf/assess-step/assessment-cases-download-page)
>> it does not seem to be necessary for any cookie handling
>> since it just wants the disclaimer to be displayed before login
>
>ack, thanks for the links.
>
>>
>>>
>>> And how should API calls made using API tokens get handled, should they
>>> have a header signalling consent or not? If, should there be a set of
>>> standard consents that one can explicitly consent too? As a blanket
>>> consent to an unknown text would not be of much use.
>>
>>
>> also it says that this is only for human interaction, so any api
>> access etc. is exempt IIUC
>
>
>So pretty much a worthless "keep out" sign [0], can one be even
>enterprise ready without those? ;-)
>
>[0]: https://i.imgur.com/mSHi8.jpeg
>
>Anyhow, fine by me, but I then still would prefer having this saved
>as structured data with an explicit type so that we can easily extend
>this with an option for actually enforcing such a consent, if ever
>requested.
>
>Maybe we can even add it as encoded text to an existing config, for PVE
>the datacenter one would be a good fit, for PMG with also have a cluster
>wide one IIRC and for PBS we could just add it to the node.cfg (and cache
>inside the http daemon).

I don't think we will gain much from adding the text in a config file
here. The config files don't support multi-line values and thus we have to
escape all the newlines. If we do this, we would have to introduce a ui
textfield where the user can edit the consent file, otherwise he would
have to escape all the newlines manually in the node.cfg file (which is
a PITA).

I am also kind of opposed to a ui element because this is quite a niche
feature and would only clog the interface.

I don't think an option to strictly enforcing the consent won't come any
time soon, as it's quite complicated to implement and is mostly used as
a legal requirement anyway.

Another plus would be that VMWare does the same, so a user would just
have to come the .txt file /etc/proxmox-backup (+ rename it) and would
be ready to go.

If we want to add other visual configs such as optional buttons (e.g.:
"I Accept", "I Decline") I think we should add the in the txt file like
such (or something similar):

	multi-line
	text

	I Agree|I Disagree|Ignore



_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel


  reply	other threads:[~2024-05-23 12:09 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-22 13:19 Gabriel Goller
2024-05-22 13:19 ` [pbs-devel] [PATCH proxmox-backup 1/4] api: add consent api handler and config Gabriel Goller
2024-05-22 13:19 ` [pbs-devel] [PATCH proxmox-backup 2/4] ui: show consent banner before login Gabriel Goller
2024-05-22 15:21   ` Thomas Lamprecht
2024-05-23  9:41     ` Gabriel Goller
2024-05-22 13:19 ` [pbs-devel] [PATCH proxmox-backup 3/4] docs: add section about consent banner Gabriel Goller
2024-05-22 13:19 ` [pbs-devel] [PATCH backup 4/4] window: add consent modal Gabriel Goller
2024-05-22 15:31 ` [pbs-devel] [PATCH backup/proxmox-backup 0/4] fix #5463: add optional consent banner before login Thomas Lamprecht
2024-05-23  7:51   ` Dominik Csapak
2024-05-23  9:24     ` Thomas Lamprecht
2024-05-23 12:10       ` Gabriel Goller [this message]
2024-05-23 12:42         ` Thomas Lamprecht
2024-05-28  8:18           ` Gabriel Goller
2024-05-28  8:33             ` Gabriel Goller
2024-06-04 12:50 ` Gabriel Goller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240523121008.c6p4eixaatbzwhzl@luna.proxmox.com \
    --to=g.goller@proxmox.com \
    --cc=pbs-devel@lists.proxmox.com \
    --cc=t.lamprecht@proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal