legal: Handling of user incompetence #15

New Issue

kreyren · 2020-11-05T07:17:36+01:00

kreyren commented

2020-11-05 07:17:36 +01:00

DISCLAIMER: I ain't your lawyer and this is not a legal advise.

Currently it seems that dotya doesn't handle the scenario where end-users set weak password and then complain that someone was able to guess it which could be legally problematic.

See https://docs.github.com/en/free-pro-team@latest/github/site-policy/github-terms-of-service point 4 for reference

Suggesting to adapt simmilar policy to avoid possible lawsuit.

**DISCLAIMER:** I ain't your lawyer and this is not a legal advise. Currently it seems that dotya doesn't handle the scenario where end-users set weak password and then complain that someone was able to guess it which could be legally problematic. See https://docs.github.com/en/free-pro-team@latest/github/site-policy/github-terms-of-service point 4 for reference Suggesting to adapt simmilar policy to avoid possible lawsuit.

wanderer commented

2020-11-05 08:51:19 +01:00

thanks for the input.
how could anyone be liable for your crap password though?
anyway, currently users are forced to deliver a passwd of at least 12 characters and it has to contain uppercase, lowercase, digits and special signs - which, I believe, on its own makes this a-not-ridiculously-trivial password

thanks for the input. how could anyone be liable for your crap password though? anyway, currently users are forced to deliver a passwd of at least 12 characters and it has to contain uppercase, lowercase, digits and special signs - which, I believe, on its own makes this a-not-ridiculously-trivial password

kreyren commented

2020-11-05 08:59:10 +01:00

how could anyone be liable for your crap password though?

https://www.keepersecurity.com/blog/2015/02/23/linkedin-settles-lawsuit-for-1-25-million-over-weak-passwords/

https://bits.blogs.nytimes.com/2015/02/23/linkedin-settles-class-action-suit-over-weak-password-security/

> how could anyone be liable for your crap password though? https://www.keepersecurity.com/blog/2015/02/23/linkedin-settles-lawsuit-for-1-25-million-over-weak-passwords/ https://bits.blogs.nytimes.com/2015/02/23/linkedin-settles-class-action-suit-over-weak-password-security/

wanderer commented

2020-11-05 09:00:45 +01:00

I have no issues setting the requirement to be a at-least-80-character password.. 🥇
I think we need the CoC more, though @kreyren

I have no issues setting the requirement to be a at-least-80-character password.. 🥇 I think we need the CoC more, though @kreyren

kreyren commented

2020-11-05 09:07:25 +01:00

12 characters and it has to contain uppercase, lowercase, digits and special signs

What if there is a software that can easily brute-force these accounts?

e.g.

for hash in {0..zzzzzzzzzzzzz}; do
	# payload
done

you'd be rate-limited on our side 🚀 😞

> 12 characters and it has to contain uppercase, lowercase, digits and special signs What if there is a software that can easily brute-force these accounts? e.g. ```sh for hash in {0..zzzzzzzzzzzzz}; do # payload done ``` you'd be rate-limited on our side 🚀 😞

kreyren commented

2020-11-05 09:08:17 +01:00

I have no issues setting the requirement to be a at-least-80-character password.. 🥇

Not everyone prefers strong password i would suggest handling this legally stating that end-users are responsible to choose a strong password

> I have no issues setting the requirement to be a at-least-80-character password.. 🥇 Not everyone prefers strong password i would suggest handling this legally stating that end-users are responsible to choose a strong password

👍 1

wanderer commented

2020-11-05 09:26:20 +01:00

I have no issues setting the requirement to be a at-least-80-character password.. 🥇

Not everyone prefers strong password i would suggest handling this legally stating that end-users are responsible to choose a strong password

it would at least force people to either turn around or start using pass

> > I have no issues setting the requirement to be a at-least-80-character password.. 🥇 > > Not everyone prefers strong password i would suggest handling this legally stating that end-users are responsible to choose a strong password it would at least force people to either turn around or start using `pass`

wanderer added this to the General project 2020-11-05 09:26:54 +01:00

kreyren commented

2020-11-05 09:33:47 +01:00

it would at least force people to either turn around

Afaik Majority of the people are using weak passwords so that woudn't be good for the service if it's not user-friendly enough

> it would at least force people to either turn around Afaik Majority of the people are using weak passwords so that woudn't be good for the service if it's not user-friendly enough

wanderer commented

2020-11-05 09:37:47 +01:00

it would at least force people to either turn around

Afaik Majority of the people are using weak passwords so that woudn't be good for the service if it's not user-friendly enough

wdym
you can tell Gitea to force people to use passwords of certain complexity..
either you take it or not. that is more reasonable than putting the blame on them because a) is teaching them something about security b) is making them responsible for their own crap c) makes their account harder to compromise.

we can also force 2fa if you want

> > it would at least force people to either turn around > > Afaik Majority of the people are using weak passwords so that woudn't be good for the service if it's not user-friendly enough wdym you can tell Gitea to force people to use passwords of certain complexity.. either you take it or not. that is more reasonable than putting the blame on them because a) is teaching them something about security b) is *making* them responsible for their own crap c) makes their account harder to compromise. we can also force 2fa if you want

kreyren commented

2020-11-05 09:54:05 +01:00

you can tell Gitea to force people to use passwords of certain complexity..
either you take it or not. that is more reasonable than putting the blame on them

That's not what the law says afaik see the provided example

So we should be considering password failure to be the service responsibility unless state otherwise in the ToS. which would be

b) is making them responsible for their own crap

we can also force 2fa if you want

I would like to see some symbol for 2FA enabled accounts if the end-user desires that and for the organization management to see which users set up 2FA other then that i don't think we can do anything in the general interest here

> you can tell Gitea to force people to use passwords of certain complexity.. either you take it or not. that is more reasonable than putting the blame on them That's not what the law says afaik see the provided example So we should be considering password failure to be the service responsibility unless state otherwise in the ToS. which would be > b) is making them responsible for their own crap > we can also force 2fa if you want I would like to see some symbol for 2FA enabled accounts if the end-user desires that and for the organization management to see which users set up 2FA other then that i don't think we can do anything in the general interest here

wanderer commented

2020-11-05 12:42:34 +01:00

you can tell Gitea to force people to use passwords of certain complexity..
either you take it or not. that is more reasonable than putting the blame on them

That's not what the law says afaik see the provided example

So we should be considering password failure to be the service responsibility unless state otherwise in the ToS. which would be

b) is making them responsible for their own crap

we can also force 2fa if you want

I would like to see some symbol for 2FA enabled accounts if the end-user desires that and for the organization management to see which users set up 2FA other then that i don't think we can do anything in the general interest here

first of all, that's probably US law.
and should we be liable I don't see why not to set our passwd complexity reguirements to a proper level (over 9000) to avoid this completely.

symbol next to 2fa-enabled accounts is an upstream request and if we force it I don't think we need to show who's got it enabled anyway

> > you can tell Gitea to force people to use passwords of certain complexity.. > either you take it or not. that is more reasonable than putting the blame on them > > That's not what the law says afaik see the provided example > > So we should be considering password failure to be the service responsibility unless state otherwise in the ToS. which would be > > > b) is making them responsible for their own crap > > > we can also force 2fa if you want > > I would like to see some symbol for 2FA enabled accounts if the end-user desires that and for the organization management to see which users set up 2FA other then that i don't think we can do anything in the general interest here first of all, that's probably US law. and should we be liable I don't see why not to set our passwd complexity reguirements to a proper level (over 9000) to avoid this completely. symbol next to 2fa-enabled accounts is an upstream request and if we force it I don't think we need to show who's got it enabled anyway

kreyren commented

2020-11-05 13:15:00 +01:00

first of all, that's probably US law.

I belive that in EU GDPR is relevant as giving unauthorized access would probably count as privacy violation which in czechia would be probably 110/2019 Sb. §5 (b) https://www.zakonyprolidi.cz/cs/2019-110

Relevant: https://www.politico.eu/article/german-lawsuit-accuses-amazon-of-breaking-eu-privacy-law/

Relevant: http://ec.europa.eu/information_society/newsroom/cf/document.cfm?doc_id=835

and should we be liable I don't see why not to set our passwd complexity reguirements to a proper level (over 9000) to avoid this completely.

I believe that someone can make the claim that they were damaged by an online service's unauthorized access which wouldbe probaby weak at the court, but seems to hold for some cases.. So i would probably apply said clause in ToS just to be safe.

symbol next to 2fa-enabled accounts is an upstream request and if we force it I don't think we need to show who's got it enabled anyway

Referencing https://www.google.com/search?client=firefox-b-e&q=gentoo+hack which was caused by the lack of 2FA on compromised account.. After which github provides a symbol in organizations to show that they are using 2FA which i would recommend here too, but probably upstream bug if not set already.

> first of all, that's probably US law. I belive that in EU GDPR is relevant as giving unauthorized access would probably count as privacy violation which in czechia would be probably 110/2019 Sb. §5 (b) <https://www.zakonyprolidi.cz/cs/2019-110> Relevant: https://www.politico.eu/article/german-lawsuit-accuses-amazon-of-breaking-eu-privacy-law/ Relevant: http://ec.europa.eu/information_society/newsroom/cf/document.cfm?doc_id=835 > and should we be liable I don't see why not to set our passwd complexity reguirements to a proper level (over 9000) to avoid this completely. I believe that someone can make the claim that they were damaged by an online service's unauthorized access which wouldbe probaby weak at the court, but seems to hold for some cases.. So i would probably apply said clause in ToS just to be safe. > symbol next to 2fa-enabled accounts is an upstream request and if we force it I don't think we need to show who's got it enabled anyway Referencing https://www.google.com/search?client=firefox-b-e&q=gentoo+hack which was caused by the lack of 2FA on compromised account.. After which github provides a symbol in organizations to show that they are using 2FA which i would recommend here too, but probably upstream bug if not set already.

wanderer commented

2020-11-05 13:40:54 +01:00

you can be using 2fa and not tell anybody and telling everybody still doesn't make it more secure, that's imo just gh's marketing.
so what would probably work for us - forced 2fa and forced strong password.
and we can make it clear in the registration page, too.
problem solved. :D

you can be using 2fa and not tell anybody and telling everybody still doesn't make it more secure, that's imo just gh's marketing. so what would probably work for us - forced 2fa and forced strong password. and we can make it clear in the registration page, too. problem solved. :D

kreyren commented

2020-11-05 13:47:40 +01:00

@wanderer That won't cover you in case there is a major bug in gitea that allows unauthorized access.

wanderer commented

2020-11-05 13:49:42 +01:00

@wanderer That won't cover you in case there is a major bug in gitea that allows unauthorized access.

well how is an upstream bug our responsibility?

> @wanderer That won't cover you in case there is a major bug in gitea that allows unauthorized access. well how is an upstream bug our responsibility?

kreyren commented

2020-11-05 13:57:31 +01:00

@wanderer You are a service provider of a software that directly states that they are not liable for the software runtime to the extend permitted by the law https://github.com/go-gitea/gitea/blob/master/LICENSE#L14

Where service providers are afaik responsible for the:

content - Content accessible to children -> COPA and european eqvivalent violation https://ec.europa.eu/home-affairs/news/20200910_eu-continue-protect-children-from-child-sexual-abuse-_en
privacy - Possible GDPR violation and damages of intellectual or physical property
Copyrighted material - Violation of copyright law

on the platform unless specified otherwise in the ToS where law allows.

@wanderer You are a service provider of a software that directly states that they are not liable for the software runtime to the extend permitted by the law https://github.com/go-gitea/gitea/blob/master/LICENSE#L14 Where service providers are afaik responsible for the: 1. content - Content accessible to children -> COPA and european eqvivalent violation <https://ec.europa.eu/home-affairs/news/20200910_eu-continue-protect-children-from-child-sexual-abuse-_en> 2. privacy - Possible GDPR violation and damages of intellectual or physical property 3. Copyrighted material - Violation of copyright law on the platform unless specified otherwise in the ToS where law allows.

wanderer commented

2020-11-05 14:02:42 +01:00

@wanderer You are a service provider of a software that directly states that they are not liable for the software runtime to the extend permitted by the law https://github.com/go-gitea/gitea/blob/master/LICENSE#L14

Where service providers are afaik responsible for the:

content - Content accessible to children -> COPA and european eqvivalent violation https://ec.europa.eu/home-affairs/news/20200910_eu-continue-protect-children-from-child-sexual-abuse-_en

privacy - Possible GDPR violation and damages of intellectual or physical property

Copyrighted material - Violation of copyright law

on the platform unless specified otherwise in the ToS where law allows.

pardon my ignorance, but if upstream didn't find the bug, how were we supposed to do it? :D
putting this in the tos is just BS for it's own sake as anyone sane enough knows there's noone to blame here, really.

but ok, let's declare ourselves not liable and suddenly the problem is solved - this is crazy :D

> @wanderer You are a service provider of a software that directly states that they are not liable for the software runtime to the extend permitted by the law https://github.com/go-gitea/gitea/blob/master/LICENSE#L14 > > Where service providers are afaik responsible for the: > 1. content - Content accessible to children -> COPA and european eqvivalent violation <https://ec.europa.eu/home-affairs/news/20200910_eu-continue-protect-children-from-child-sexual-abuse-_en> > 2. privacy - Possible GDPR violation and damages of intellectual or physical property > 3. Copyrighted material - Violation of copyright law > > on the platform unless specified otherwise in the ToS where law allows. pardon my ignorance, but if upstream didn't find the bug, how were we supposed to do it? :D putting this in the tos is just BS for it's own sake as anyone sane enough knows there's noone to blame here, really. but ok, let's declare ourselves not liable and suddenly the problem is solved - this is crazy :D

kreyren commented

2020-11-06 00:42:57 +01:00

pardon my ignorance, but if upstream didn't find the bug, how were we supposed to do it? :D

Common sense would be to use source-based distro that requires passing of tests. To catch bugs that were caused by upstream's pebcak.

putting this in the tos is just BS for it's own sake as anyone sane enough knows there's noone to blame here, really. @

Disagree for sources provided e.g. with linkedin

> pardon my ignorance, but if upstream didn't find the bug, how were we supposed to do it? :D Common sense would be to use source-based distro that requires passing of tests. To catch bugs that were caused by upstream's pebcak. > putting this in the tos is just BS for it's own sake as anyone sane enough knows there's noone to blame here, really. @ Disagree for sources provided e.g. with linkedin

wanderer commented

2020-11-06 08:53:20 +01:00

pardon my ignorance, but if upstream didn't find the bug, how were we supposed to do it? :D

Common sense would be to use source-based distro that requires passing of tests. To catch bugs that were caused by upstream's pebcak.

as we're building Gitea from sources regularly, we'd have to write some of the tests, the current tests are more of a functional regression testing.

the distro doesn't solve this for us unless the maintainer/packager for the distro writes additional tests, too, which would then likely be contributed upstream anyway

regardless, the proper way is to put the blame away?

> > pardon my ignorance, but if upstream didn't find the bug, how were we supposed to do it? :D > > Common sense would be to use source-based distro that requires passing of tests. To catch bugs that were caused by upstream's pebcak. > as we're building Gitea from sources regularly, we'd have to write some of the tests, the current tests are more of a functional regression testing. the distro doesn't solve this for us unless the maintainer/packager for the distro writes additional tests, too, which would then likely be contributed upstream anyway regardless, the proper way is to put the blame away?

kreyren commented

2020-11-07 00:31:35 +01:00

as we're building Gitea from sources regularly, we'd have to write some of the tests, the current tests are more of a functional regression testing. @wanderer

That would be upstream bug for test tracking

regardless, the proper way is to put the blame away? @wanderer

Legally i was always recommeneded to handle the password scenario this way so that end-users are responsible for the password they've chosen to the reasonable degree

Also i would recommend adapting ToS for security issues to inform affected users which makes the service more trustworthy and should handle the legal liability for service-caused damages to it's users.

> as we're building Gitea from sources regularly, we'd have to write some of the tests, the current tests are more of a functional regression testing. @wanderer That would be upstream bug for test tracking > regardless, the proper way is to put the blame away? @wanderer Legally i was always recommeneded to handle the password scenario this way so that end-users are responsible for the password they've chosen to the reasonable degree Also i would recommend adapting ToS for security issues to inform affected users which makes the service more trustworthy and should handle the legal liability for service-caused damages to it's users.

👍 1

kreyren commented

2020-11-07 11:49:18 +01:00

fwiw: i am being forced to say that i've baited @wanderer into making that repo private through the mighty power of south park to prove my point.

wanderer added this to the v1.0 milestone 2020-11-17 21:26:37 +01:00

wanderer commented

2020-11-18 13:04:13 +01:00

fwiw: i am being forced to say that i've baited @wanderer into making that repo private through the mighty power of south park to prove my point.

yeah...you're almost worse than the RIAA
but the point sure is made.

> fwiw: i am being forced to say that i've baited @wanderer into making that repo private through the mighty power of south park to prove my point. yeah...you're almost worse than the [RIAA](https://github.com/ytdl-org/youtube-dl/issues/27013#issue-744276939) but the point sure is made.

Sign in to join this conversation.