Property talk:P4092

From Wikidata
Jump to navigation Jump to search

Documentation

checksum
small-sized datum derived from a block of digital data for the purpose of detecting errors. Use qualifier "determination method" (P459) to indicate how it's calculated, e.g. MD5.
Descriptionsmall-sized datum derived from a block of digital data for the purpose of detecting errors
Representschecksum (Q218341)
Data typeString
Domainany (note: this should be moved to the property statements)
Allowed values
According to this template: any
According to statements in the property:
[a-z\d]{128}|[a-z\d]{64}|[a-z\d]{40}|[a-z\d]{32}|[a-z\d]{16}|[a-z\d]{8}(-[a-z\d]{4}){3}-[a-z\d]{12}
When possible, data should only be stored as statements
Exampledistribution of historical monuments in the city of Zurich, Switzerland, June 2017 (zip) (Q30243079) → 23908402390 (note: this information should be moved to a property statement; use property Wikidata property example (P1855), Wikidata property example for properties (P2271), Wikidata property example for lexemes (P5192), Wikidata property example for forms (P5193) or Wikidata property example for senses (P5977))
See alsopHash checksum (P9310)
Lists
Proposal discussionProposal discussion
Current uses
Total137
Main statement12490.5% of uses
Qualifier107.3% of uses
Reference32.2% of uses
Search for values
[create Create a translatable help page (preferably in English) for this property to be included here]
Required qualifier “determination method (P459): this property should be used with the listed qualifier. (Help)
List of violations of this constraint: Database reports/Constraint violations/P4092#mandatory qualifier, hourly updated report, SPARQL
Format “[a-z\d]{128}|[a-z\d]{64}|[a-z\d]{40}|[a-z\d]{32}|[a-z\d]{16}|[a-z\d]{8}(-[a-z\d]{4}){3}-[a-z\d]{12}: value must be formatted using this pattern (PCRE syntax). (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P4092#Format, SPARQL
Allowed entity types are Wikibase item (Q29934200), Wikibase MediaInfo (Q59712033): the property may only be used on a certain entity type (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P4092#Entity types
Scope is as main value (Q54828448), as qualifier (Q54828449): the property must be used by specified way only (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P4092#Scope, SPARQL

As per zh:Wikipedia:互助客栈/技术#User_committed_identity哈希算法脆弱, it's possible that values of this property can fill rainbow table (Q1139146), any opposition? --Liuxinyu970226 (talk) 15:01, 30 April 2018 (UTC)[reply]

Without comments on why it shouldn't be that, I added this as P17 value. --Liuxinyu970226 (talk) 00:29, 2 May 2018 (UTC)[reply]
@Liuxinyu970226: not sure to understand, could you explain? This property is barely use (only 5 times, none on person) so it's difficult to say but I don't see how this property "may violate privacy", creating a rainbow table (Q1139146) seems indirect and unlikely and it's not the sense of Wikidata:Living people for which property that may violate privacy (Q44601380) was created. + @Andheb: Cheers, VIGNERON (talk) 19:36, 25 June 2019 (UTC)[reply]
@VIGNERON: There are many hack teams that can guess passwords of many Internet services accounts by such rainbow table-based dictionaries, not enough? --Liuxinyu970226 (talk) 02:33, 26 June 2019 (UTC)[reply]
@Liuxinyu970226: I'm not an expert but as I understand it, rainbow table doesn't works for all checksum (not if checksum is salted for instance) and works only if you have a large quantity of checksum for a system (which is obvioulsy not the case here). Plus, checksum is not always used for personal password. So in the end, I don't see how it may violate privacy in our context, it seems too indirect (in comparison to place of birth (P19) or date of birth (P569) where the violation is direct and obvious). Did I miss something? Cheers, VIGNERON (talk) 09:20, 26 June 2019 (UTC)[reply]
@VIGNERON: Plus, checksum is not always used for personal password., really even applies to credit card (Q161380) passwords (you should know that unless if some ATM supports, those passwords are generally 6 digits, and can simply be guessed, stole and even SNS-shared, just with some checksum knowledges)? --Liuxinyu970226 (talk) 22:07, 28 June 2019 (UTC)[reply]
@Liuxinyu970226: yes, I would say personal applies to credit card (Q161380). My remark was more for the current (and only) use of this property: Pole Chudes (Q4369590), distribution of historical monuments in the city of Zurich, Switzerland, June 2017 (zip) (Q30243079) and distribution of historical monuments in the city of Zurich, Switzerland, June 2017 (kmz) (Q30243243) which don't seems personnal at all. Cheers, VIGNERON (talk) 07:07, 29 June 2019 (UTC)[reply]

@Liuxinyu970226: This is missing the point of that tag. By this logic, all software tools, even Google itself, could be used to violate privacy. Hashes by themselves do not violate privacy. Neither do rainbow tables, but that's just piling more wrong on top of wrong. Opencooper (talk) 17:45, 1 September 2020 (UTC)[reply]

Using this property for software[edit]

Just to put it out there: is anyone confused why checksums would be used for software? If yes I'd like to know why. Thank you in advance!! Maskingself (talk) 23:55, 17 March 2022 (UTC)[reply]