Menu
▾
▴
unity-idm-discuss
|
From: Sander A. <sa....@fz...> - 2020-10-02 08:54:53
Attachments:
smime.p7s
|
Good Morning Krzysztof, we got a lot of feedback of 3rd site content and cookies triggered by unity. This content is are the logos and cookies of the remote IdPs (from eduGAIN). The users never visited these IdPs. The users are very unhappy with this behaviour. Can this be changed, that unity fetches the logos, caches them and provide them with the login screen? Best regards, Sander -- Federated Systems and Data Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ---------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Volker Rieke Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Krzysztof B. <kb...@un...> - 2020-10-02 09:13:40
|
Hi Sander, W dniu 02.10.2020 o 10:54, Sander Apweiler pisze: > Good Morning Krzysztof, > > we got a lot of feedback of 3rd site content and cookies triggered by > unity. This content is are the logos and cookies of the remote IdPs > (from eduGAIN). The users never visited these IdPs. The users are very > unhappy with this behaviour. Can this be changed, that unity fetches > the logos, caches them and provide them with the login screen? > Do you mean that the process of showing SAML federation logos (which are provided as links in federation metadata) should not happen lazy when user enters the authentication page, but rather be done in background, from time to time, so that all logos are served from Unity server itself? Cheers Krzysztof |
|
From: Sander A. <sa....@fz...> - 2020-10-02 09:18:07
Attachments:
smime.p7s
|
Hi Krzysztof, On Fri, 2020-10-02 at 11:13 +0200, Krzysztof Benedyczak wrote: > Hi Sander, > > W dniu 02.10.2020 o 10:54, Sander Apweiler pisze: > > Good Morning Krzysztof, > > > > we got a lot of feedback of 3rd site content and cookies triggered > > by > > unity. This content is are the logos and cookies of the remote IdPs > > (from eduGAIN). The users never visited these IdPs. The users are > > very > > unhappy with this behaviour. Can this be changed, that unity > > fetches > > the logos, caches them and provide them with the login screen? > > > Do you mean that the process of showing SAML federation logos (which > are > provided as links in federation metadata) should not happen lazy > when > user enters the authentication page, but rather be done in > background, > from time to time, so that all logos are served from Unity server > itself? Exactly. I guess when the logos are served from unity instead of the IdPs, the cookie issue is solved, too. Cheers, Sander > > Cheers > Krzysztof > -- Federated Systems and Data Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ---------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Volker Rieke Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Krzysztof B. <kb...@un...> - 2020-10-02 09:55:04
|
Hi Sander, W dniu 02.10.2020 o 11:17, Sander Apweiler pisze: > Hi Krzysztof, > > On Fri, 2020-10-02 at 11:13 +0200, Krzysztof Benedyczak wrote: >> Hi Sander, >> >> W dniu 02.10.2020 o 10:54, Sander Apweiler pisze: >>> Good Morning Krzysztof, >>> >>> we got a lot of feedback of 3rd site content and cookies triggered >>> by >>> unity. This content is are the logos and cookies of the remote IdPs >>> (from eduGAIN). The users never visited these IdPs. The users are >>> very >>> unhappy with this behaviour. Can this be changed, that unity >>> fetches >>> the logos, caches them and provide them with the login screen? >>> >> Do you mean that the process of showing SAML federation logos (which >> are >> provided as links in federation metadata) should not happen lazy >> when >> user enters the authentication page, but rather be done in >> background, >> from time to time, so that all logos are served from Unity server >> itself? > Exactly. I guess when the logos are served from unity instead of the > IdPs, the cookie issue is solved, too. Yes - we can change the behavior, I've opened a ticket. This will be a rather complex process (this is lot's of data which would need to be downloaded, stored and refreshed) - rather a bigger change, so hard to say when we schedule it. On the other hand, users are constantly tracked by FB, Google, and ton of other sites with real consequences. The fact that the user gets a cookie from a site which was not visited is just few bytes on her hard drive, nothing more. So I can ask: what is the real problem here? Cheers, Krzysztof |
|
From: Marcus H. <ha...@ki...> - 2020-10-05 09:12:00
Attachments:
smime.p7s
|
On 10/02/20 11:54, Krzysztof Benedyczak wrote: > Hi Sander, > > W dniu 02.10.2020 o 11:17, Sander Apweiler pisze: > > Hi Krzysztof, > > > > On Fri, 2020-10-02 at 11:13 +0200, Krzysztof Benedyczak wrote: > > > Hi Sander, > > > > > > W dniu 02.10.2020 o 10:54, Sander Apweiler pisze: > > > > Good Morning Krzysztof, > > > > > > > > we got a lot of feedback of 3rd site content and cookies triggered > > > > by > > > > unity. This content is are the logos and cookies of the remote IdPs > > > > (from eduGAIN). The users never visited these IdPs. The users are > > > > very > > > > unhappy with this behaviour. Can this be changed, that unity > > > > fetches > > > > the logos, caches them and provide them with the login screen? > > > > > > > Do you mean that the process of showing SAML federation logos (which > > > are > > > provided as links in federation metadata) should not happen lazy > > > when > > > user enters the authentication page, but rather be done in > > > background, > > > from time to time, so that all logos are served from Unity server > > > itself? > > Exactly. I guess when the logos are served from unity instead of the > > IdPs, the cookie issue is solved, too. > > Yes - we can change the behavior, I've opened a ticket. This will be a > rather complex process (this is lot's of data which would need to be > downloaded, stored and refreshed) - rather a bigger change, so hard to say > when we schedule it. > > On the other hand, users are constantly tracked by FB, Google, and ton of > other sites with real consequences. Yes, and in addition to google and facebook, nyob has started to sue 101 companies in europe that do the same thing [1]. > The fact that the user gets a cookie > from a site which was not visited is just few bytes on her hard drive, > nothing more. So I can ask: what is the real problem here? By requesting the picture, the user informs _all_ IdPs that he is about to log in to unity. That does not seem right, does it? Plus, some (very few) are configured to offer certificate authentication, if an appropriate certificate is in the browser. The browser shows a popup for the user to choose. So, when I want to choose KIT on unity, some other site asks for the certificate? Fortunately, not _all_ IdPs are queried (as did another project in an early version). [1] https://noyb.eu/en/update-noybs-101-complaints-eu-us-data-transfers -- Marcus. |
|
From: Krzysztof B. <kb...@un...> - 2020-10-06 07:24:30
|
Marcus, W dniu 05.10.2020 o 10:47, Marcus Hardt pisze: >> The fact that the user gets a cookie >> from a site which was not visited is just few bytes on her hard drive, >> nothing more. So I can ask: what is the real problem here? > By requesting the picture, the user informs _all_ IdPs that he is about to > log in to unity. That does not seem right, does it? No, that's not true. The IdPs can only know that some *anonymous* one is trying to enter unity instance (and only after if and after they check that referer URL is of some unity instance). Nothing more. What privacy concern is there? > Plus, some (very few) are configured to offer certificate authentication, > if an appropriate certificate is in the browser. The browser shows a popup > for the user to choose. So, when I want to choose KIT on unity, some other > site asks for the certificate? Fortunately, not _all_ IdPs are queried > (as did another project in an early version). That is obvious misconfiguration of your IdP sites. They should not require authN for public assets like a logo advertised in metadata for authentication purposes. I can see the value in the request to cache the images by unity - but that's more of an optimization, not a privacy issue. Best, Krzysztof |
|
From: Marcus H. <ha...@ki...> - 2020-10-06 07:32:58
Attachments:
smime.p7s
|
On 10/06/20 09:24, Krzysztof Benedyczak wrote: > Marcus, > > W dniu 05.10.2020 o 10:47, Marcus Hardt pisze: > > > The fact that the user gets a cookie > > > from a site which was not visited is just few bytes on her hard drive, > > > nothing more. So I can ask: what is the real problem here? > > By requesting the picture, the user informs _all_ IdPs that he is about to > > log in to unity. That does not seem right, does it? > > No, that's not true. The IdPs can only know that some *anonymous* one is > trying to enter unity instance (and only after if and after they check that > referer URL is of some unity instance). Nothing more. The anonymous is the goal here. For this unity needs to proxy the requests. At the moments it's my browser requesting those images. This is by no means anonymous. > What privacy concern is there? I am unneccessarily forced to releasing information to third parties, potentially outside europe, that I've never wanted to authorise. > > Plus, some (very few) are configured to offer certificate authentication, > > if an appropriate certificate is in the browser. The browser shows a popup > > for the user to choose. So, when I want to choose KIT on unity, some other > > site asks for the certificate? Fortunately, not _all_ IdPs are queried > > (as did another project in an early version). > > That is obvious misconfiguration of your IdP sites. Not at all. It's any IdP that is in the metadata. We have no control about them. > They should not require > authN for public assets like a logo advertised in metadata for > authentication purposes. Absolutely agreed. > I can see the value in the request to cache the images by unity - but that's > more of an optimization, not a privacy issue. -- Marcus. |
|
From: Krzysztof B. <kb...@un...> - 2020-10-06 09:32:30
|
W dniu 06.10.2020 o 09:32, Marcus Hardt pisze: > On 10/06/20 09:24, Krzysztof Benedyczak wrote: >> Marcus, >> >> W dniu 05.10.2020 o 10:47, Marcus Hardt pisze: >>>> The fact that the user gets a cookie >>>> from a site which was not visited is just few bytes on her hard drive, >>>> nothing more. So I can ask: what is the real problem here? >>> By requesting the picture, the user informs _all_ IdPs that he is about to >>> log in to unity. That does not seem right, does it? >> No, that's not true. The IdPs can only know that some *anonymous* one is >> trying to enter unity instance (and only after if and after they check that >> referer URL is of some unity instance). Nothing more. > The anonymous is the goal here. For this unity needs to proxy the > requests. At the moments it's my browser requesting those images. This is > by no means anonymous. Are you browsing the web? Entering _any_ page opens a huge risk that this webpage has an asset embedded and your browser will download it. What's more in the age of CDNs you are sharing your "data" with them almost always. Not to mention cloudflare and other similar services. >> What privacy concern is there? > I am unneccessarily forced to releasing information to third parties, > potentially outside europe, that I've never wanted to authorise. Well, what information? That some unknown person using say Firefox entered a webpage Y from IP Z. If you are very concerned about Z use one of public VPN services (I do - solves the problem for all cases). Still Z is mostly useless information in age of NAT and dynamic IPs. You can also fake client agent (pretend that you are curl) if this matters for you - but why? If your concern is about tracking for advertising/marketing - disable 3rd party cookies in your browser. But seriously: are edugain IdPs providing contextual ads around the globe? :-) Best, Krzysztof |
|
From: Marcus H. <ha...@ki...> - 2020-10-06 09:46:18
Attachments:
smime.p7s
|
On 10/06/20 11:32, Krzysztof Benedyczak wrote: > W dniu 06.10.2020 o 09:32, Marcus Hardt pisze: > > On 10/06/20 09:24, Krzysztof Benedyczak wrote: > > > Marcus, > > > > > > W dniu 05.10.2020 o 10:47, Marcus Hardt pisze: > > > > > The fact that the user gets a cookie > > > > > from a site which was not visited is just few bytes on her hard drive, > > > > > nothing more. So I can ask: what is the real problem here? > > > > By requesting the picture, the user informs _all_ IdPs that he is about to > > > > log in to unity. That does not seem right, does it? > > > No, that's not true. The IdPs can only know that some *anonymous* one is > > > trying to enter unity instance (and only after if and after they check that > > > referer URL is of some unity instance). Nothing more. > > The anonymous is the goal here. For this unity needs to proxy the > > requests. At the moments it's my browser requesting those images. This is > > by no means anonymous. > > Are you browsing the web? Entering _any_ page opens a huge risk that this > webpage has an asset embedded and your browser will download it. What's more > in the age of CDNs you are sharing your "data" with them almost always. Not > to mention cloudflare and other similar services. I know. Personally, I'm using uMatrix to get rid of that stuff. Plus I'm supporting initatives like noyb.eu to help enforcing the existing legislation against this. But this is not about me. This is about Data Privacy Officers in the Public Sector. The one of FZJ is apparently rather tolerant. I hear people at KIT that claim their service had to be deactivated until fixed for such reasons. For HIFIS and HDF we cannot risk that. M. > > > What privacy concern is there? > > I am unneccessarily forced to releasing information to third parties, > > potentially outside europe, that I've never wanted to authorise. > > Well, what information? That some unknown person using say Firefox entered a > webpage Y from IP Z. > > If you are very concerned about Z use one of public VPN services (I do - > solves the problem for all cases). Still Z is mostly useless information in > age of NAT and dynamic IPs. > > You can also fake client agent (pretend that you are curl) if this matters > for you - but why? > > If your concern is about tracking for advertising/marketing - disable 3rd > party cookies in your browser. But seriously: are edugain IdPs providing > contextual ads around the globe? :-) > > Best, > Krzysztof > -- Marcus. |
|
From: Sander A. <sa....@fz...> - 2020-12-17 06:20:57
Attachments:
smime.p7s
|
Good morning Krzysztof, We have another reason for providing the logos through unity, instead of users browser. While normal browser do not load the content if a certificate is not trusted or a hostname mismatch appears, some apps, e.g. RocketChat throws errors and the user think we have an issue on our site and open tickets. To explain users without IT, especially AAI background, is hard to explain that on our site everything is fine and the problem is out of our control. Cheers, Sander On Tue, 2020-10-06 at 11:32 +0200, Krzysztof Benedyczak wrote: > W dniu 06.10.2020 o 09:32, Marcus Hardt pisze: > > On 10/06/20 09:24, Krzysztof Benedyczak wrote: > > > Marcus, > > > > > > W dniu 05.10.2020 o 10:47, Marcus Hardt pisze: > > > > > The fact that the user gets a cookie > > > > > from a site which was not visited is just few bytes on her > > > > > hard drive, > > > > > nothing more. So I can ask: what is the real problem here? > > > > By requesting the picture, the user informs _all_ IdPs that he > > > > is about to > > > > log in to unity. That does not seem right, does it? > > > No, that's not true. The IdPs can only know that some *anonymous* > > > one is > > > trying to enter unity instance (and only after if and after they > > > check that > > > referer URL is of some unity instance). Nothing more. > > The anonymous is the goal here. For this unity needs to proxy the > > requests. At the moments it's my browser requesting those images. > > This is > > by no means anonymous. > > Are you browsing the web? Entering _any_ page opens a huge risk that > this webpage has an asset embedded and your browser will download it. > What's more in the age of CDNs you are sharing your "data" with them > almost always. Not to mention cloudflare and other similar services. > > > > What privacy concern is there? > > I am unneccessarily forced to releasing information to third > > parties, > > potentially outside europe, that I've never wanted to authorise. > > Well, what information? That some unknown person using say Firefox > entered a webpage Y from IP Z. > > If you are very concerned about Z use one of public VPN services (I > do - > solves the problem for all cases). Still Z is mostly useless > information > in age of NAT and dynamic IPs. > > You can also fake client agent (pretend that you are curl) if this > matters for you - but why? > > If your concern is about tracking for advertising/marketing - disable > 3rd party cookies in your browser. But seriously: are edugain IdPs > providing contextual ads around the globe? :-) > > Best, > Krzysztof > -- Federated Systems and Data Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ---------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Volker Rieke Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Marcus H. <ha...@ki...> - 2020-12-17 07:07:05
Attachments:
smime.p7s
|
And, to reinforce this, some users complained that they're asked for their certificate, that they have in the browser, just because of some malconfigured IdP, that requested the certificate for sending the logo. This all creates pain to the user -- unnecessarily M. On 12/17/20 07:20, Sander Apweiler wrote: > Good morning Krzysztof, > > We have another reason for providing the logos through unity, instead > of users browser. While normal browser do not load the content if a > certificate is not trusted or a hostname mismatch appears, some apps, > e.g. RocketChat throws errors and the user think we have an issue on > our site and open tickets. To explain users without IT, especially AAI > background, is hard to explain that on our site everything is fine and > the problem is out of our control. > > Cheers, > Sander > > On Tue, 2020-10-06 at 11:32 +0200, Krzysztof Benedyczak wrote: > > W dniu 06.10.2020 o 09:32, Marcus Hardt pisze: > > > On 10/06/20 09:24, Krzysztof Benedyczak wrote: > > > > Marcus, > > > > > > > > W dniu 05.10.2020 o 10:47, Marcus Hardt pisze: > > > > > > The fact that the user gets a cookie > > > > > > from a site which was not visited is just few bytes on her > > > > > > hard drive, > > > > > > nothing more. So I can ask: what is the real problem here? > > > > > By requesting the picture, the user informs _all_ IdPs that he > > > > > is about to > > > > > log in to unity. That does not seem right, does it? > > > > No, that's not true. The IdPs can only know that some *anonymous* > > > > one is > > > > trying to enter unity instance (and only after if and after they > > > > check that > > > > referer URL is of some unity instance). Nothing more. > > > The anonymous is the goal here. For this unity needs to proxy the > > > requests. At the moments it's my browser requesting those images. > > > This is > > > by no means anonymous. > > > > Are you browsing the web? Entering _any_ page opens a huge risk that > > this webpage has an asset embedded and your browser will download it. > > What's more in the age of CDNs you are sharing your "data" with them > > almost always. Not to mention cloudflare and other similar services. > > > > > > What privacy concern is there? > > > I am unneccessarily forced to releasing information to third > > > parties, > > > potentially outside europe, that I've never wanted to authorise. > > > > Well, what information? That some unknown person using say Firefox > > entered a webpage Y from IP Z. > > > > If you are very concerned about Z use one of public VPN services (I > > do - > > solves the problem for all cases). Still Z is mostly useless > > information > > in age of NAT and dynamic IPs. > > > > You can also fake client agent (pretend that you are curl) if this > > matters for you - but why? > > > > If your concern is about tracking for advertising/marketing - disable > > 3rd party cookies in your browser. But seriously: are edugain IdPs > > providing contextual ads around the globe? :-) > > > > Best, > > Krzysztof > > > > -- > Federated Systems and Data > Juelich Supercomputing Centre > > phone: +49 2461 61 8847 > fax: +49 2461 61 6656 > email: sa....@fz... > > ---------------------------------------------------------------------- > ----------------------------------------------------------------------- > Forschungszentrum Juelich GmbH > 52425 Juelich > Sitz der Gesellschaft: Juelich > Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 > Vorsitzender des Aufsichtsrats: MinDir Volker Rieke > Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), > Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt > ----------------------------------------------------------------------- > ----------------------------------------------------------------------- -- Marcus. |
|
From: Krzysztof B. <kb...@un...> - 2020-12-17 12:46:15
|
Marcus, Sander, OK, we have a ticket opened, I've moved it bit up in the backlog. Cheers, Krzysztof |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X