Reviews
Review Structure (CCS conference format)
Overall merit
-------------
( strong reject (1), reject (2), weak accept (3), accept (4), strong accept(5) )
Reviewer expertise
------------------
( No familiarity (1) Some familiarity (2), Knowledgeable (3), Expert (4) )
Note: Usually, this field is used to indicate whether you have prior knowledge and expertise of the topics discussed in the
paper. However, in our role-playing game, you can indicate the expertise of your persona as you like, since this field
will not be taken into account for the grading of the review.
Paper summary (2-3 sentences)
-----------------------------
Comments for author (400~500 characters)
-------------------
Strengths (at least 1 and up to 4)
---------
Weaknesses (up to 3)
----------
Review Examples
Reviews for two papers. Paper 770 was accepted to be presented at the conference (with some minor improvements)
and paper 683 was rejected.
Review #770A
===========================================================================
Overall merit
-------------
3. Weak accept
Reviewer expertise
------------------
3. Knowledgeable
Paper summary (2-3 sentences)
-----------------------------
The paper deals with the membership privacy problem in Fully Dynamic Group Signatures. This is a different notion of anonymity where not only the signature is anonymous but additionally the participation to the corresponding group is hidden to external observers. New definitions related to the membership privacy are introduced, namely join and leave privacy, i.e. privacy upon joining and leaving the group. The definitions are compatible with the (most general) dynamic GS definition, hence they generalize and apply to Fully Dynamic Group Signatures.
A generic construction is presented, which utilizes signatures with flexible public key, structure preserving signatures on equivalence classes and other classical primitives (digital signatures, encryption scheme, ZK proofs etc). Then a concrete instantiation is presented for which a novel SFPK scheme is also introduced. The new concrete group signature is in the standard model and under standard assumptions, while it has less or equal sized signatures than the other state of the art GS schemes in the standard model.
Comments for author
-------------------
Notes on the context:
-- It should be more clear that due to the approach of generating a fresh key at each epoch and re-signing, the group manager must do linear work at every epoch change. Doing such a work seems a quite significant overhead and it is not clear whether this would be acceptable in practical scenarios (even regardless of the concrete cost for the specific instantiation proposed in this paper). On the other hand, doing such linear work seems inherent when considering leave privacy. If this was the case, it would be at least a justification. The authors should discuss this aspect and its practical consequences.
Yet, I note that even with this linear work the approach used by the construction is better than a naive solution in which at every epoch the system is restarted (this would require to run the join protocol).
-- Does the user have to also make linear work at every epoch in order to search the list to find her (c,\sigma_{SPS})? From the GS.Sig algorithm it is interpreted in this way. Again, this sounds like a lot of burden for the user: it should be discussed if this is the case or not and what practical matters occur out of it and possible ways to fix it and reduce the cost.
-- The way it is defined, it seems that the leave privacy definition captures only privacy for users that have joined the system at the same epoch. To see this, let us consider a modification of your construction in which in the info list published by the group manager, each user information (c,\sigma_{SPS}) is associated to a freshly sampled random number (an identifier) that however does NOT get refreshed from one epoch to another. Such modified construction seems to still satisfy the definition in the paper. However, leave privacy would not hold in a game where the two challenge existing users had joined the system in different epochs (the attacker simply checks which random identifier is no longer in the list). If such a weakness in the definition exists, I do not think that it makes the paper necessarily weaker (overall this is the first one that considers this problem of membership privacy), yet it deserves discussion.
Notes on the paper writing:
Important notes:
-- In figure 4 GS.Join algorithm is missing. Also misses in the concrete scheme of figure 7 in the appendix.
-- In all the theorems of C2 it is stated that it is sufficient for SPS-EQ to be euf-CMA, while the instantiation uses euf-COMA. One should argue why the weaker SPS-EQ signature is sufficient for this specific instantiation.
-- In figure 1 in correctness the isActive algorithm is not specified.
-- In the proof of theorem 1, in GAME_3 PrivChall is never defined.
Suggestions:
-- formal definitions of security oracles in section 3.1 are not well comprehensible. The variable dec isn't explained properly and the intuition behind SndToM, SndToU isn't clear.
-- In section 3.2, functional tracing is not expressed very clearly in the first 2 paragraphs. One has to compare functional and original tracing soundness (from Bootle et al.) to understand.
-- In figure 4, info_{\tau_{current}}[uid] should be info_{\tau_{current}}.
-- A conclusion/future work section could be included.
-- In appendix C1, ChgPK, ChgSK could be included in figure 6.
Typos:
--p.8 bullet 3: signture --> signature
--p.11 next-to-last paragraph: use define --> use (or define)
--p.11 next-to-last paragraph: the the --> the
--p.12 last paragraph: be efficiently be --> be efficiently
--p.12 last paragraph: there --> their
--p.20 first paragraph: show --> shown
Strengths
---------
-- The paper formalizes the problem of membership privacy in fully dynamic group signatures, introducing new definitions for the membership privacy. The problem seems well motivated and makes the result a nice contribution in the area.
-- The generic construction is quite neat and works in the most general GS definition.
-- The concrete scheme is in the standard model and under standard assumptions.
-- The concrete scheme seems the most efficient (in terms of signature size) in this setting of fully dynamic group signatures (even without considering membership privacy).
-- Among the technical contributions, the paper also includes a SFPK scheme more efficient than the state of the art.
Weaknesses
----------
-- The group manager does linear (in the size of the group) work at each epoch. Similarly, it appears that also the user must do expensive work at every epoch change.
-- Related point is that the efficiency evaluation is only theoretical: no implementation is provided, concrete costs are given only for communication (signatures size), but no clear concrete computational costs are provided.
The two points above raise a concern about the practicality of the schemes and approach proposed in the paper, and the fit of a conference like CCS.
-- The generic construction doesn't have strong novelty. It shares many similarities with 2018 Backes et al. SFPK and Derler and Slamanig (2016, 2018) dynamic group signatures.
-- Leave privacy definition doesn't seem to capture scenarios of users that joined at different epochs.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Review #770B
===========================================================================
Overall merit
-------------
3. Weak accept
Reviewer expertise
------------------
2. Some familiarity
Paper summary (2-3 sentences)
-----------------------------
This paper revisits the notion of fully-dynamic group signatures and adds a new security requirement called "membership privacy". This means the set of members (who is a member and who is not) is hidden to outsiders, meaning to verifiers of the signature. They give a generic construction meeting the new requirements in the standard, using signatures with flexible public keys (SFPK) and signatures on equivalence classes (SPS-EQ) as building blocks. They then give an efficient instantiation of the generic construction.
Comments for author
-------------------
The examples given of when membership privacy may be needed are vague, or seem contrived and artificial. A compelling application or applied motivation is lacking. However, the goal does seem natural.
The schemes seem to be able to add membership privacy without too much (or even any) extra cost compared with prior schemes, but this cost is still rather high. The paper does not indicate (and I do not know) what are real applications of group signatures and their performance constraints. Are schemes like this desirable in practice?
Even if the cryptographic scheme hides membership according to the definitions in this paper, other real-world observables can easily leak it. For example, the adversary can observe which ip addresses or users are engaging in the join protocol by looking at the traffic and activity on the network. It may be that to actually achieve membership privacy one has to run the join protocol over Tor, which will add to cost. The submission should discuss these issues.
Definitions are not too precise. For example it fixes a group, but then talks of PPT, but the latter is an asymptotic notion, so one would expect a family of groups.
- p5, Def 2.5 (1): The output of the two algorithms cannot be identical by
construction since TKeyGen outputs trapdoor.
- In proofs (e.g. p9-11), it is stated that the distance between two hybrids is
bounded by the advantage of the same adversary ``A'' against different
security notions of different schemes. What is stated does not seem correct,
even though it might be standard to construct these reduction adversaries.
- Style of security definitions are not consistent. Game oracles are given in
text but games themselves are given in code. The need and reason for
``SndToM'' and ``SndToU'' is not clear from the definitions.
Strengths
---------
Membership privacy is a natural notion to consider. Schemes not less efficient than prior ones.
Weaknesses
----------
Lack of compelling and concrete applications. Schemes not apparently efficient enough for usage. Comparison with previous schemes (Fig 5) compares signature sizes (among other things) but leaves much more (e.g. comparison of efficiency for operations) to be desired.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Review #770C
===========================================================================
Overall merit
-------------
2. Weak reject
Reviewer expertise
------------------
4. Expert
Paper summary (2-3 sentences)
-----------------------------
Group signatures allow a member of a group to anonymously sign on behalf of the group where an opener can reveal the identity of the signer when required.
The contribution of the paper is that it "revisits" the recent model for fully dynamic group signatures by Bootle et al. (ACNS 2016) by adding a membership-privacy
requirement. This new requirement aims at hiding the population of the group from outsiders. The new requirement relies on 2 security experiments called Join-Privacy
and Leave-Privacy. The former captures that an adversary cannot tell which of 2 identities of his choice joined the group whereas the latter captures that an adversary cannot
tell which of 2 active members of his choice left the group. The paper also provides a generic construction as well as a concrete instantiation satisfying the revisited model.
Comments for author
-------------------
Paper Summary:
Group signatures allow a member of a group to anonymously sign on behalf of the group where an opener can reveal the identity of the signer when required.
The contribution of the paper is that it "revisits" the recent model for fully dynamic group signatures by Bootle et al. (ACNS 2016) by adding a membership-privacy
requirement. This new requirement aims at hiding the population of the group from outsiders. The new requirement relies on 2 security experiments called Join-Privacy
and Leave-Privacy. The former captures that an adversary cannot tell which of 2 identities of his choice joined the group whereas the latter captures that an adversary cannot
tell which of 2 active members of his choice left the group. The paper also provides a generic construction as well as a concrete instantiation satisfying the revisited model.
Strengths:
Group signatures are a central cryptographic primitive and has received a lot of attention from the community and it is therefore commendable to pursue improvements to the security
and efficiency of the notion, especially when the fully dynamic group setting is concerned.
Weaknesses:
The new requirement the authors introduce failed to impress me and the applications listed, e.g. defending against targeted DoS of group members, to motivate the need for the new requirement
has not convinced me that the requirement is as crucial as the paper tries to sell it. Moreover, the defined variant still relies on a table containing public keys of the potential members
being public which could, for instance, exclude existing constructions in which the user key pair is generated as part of the Join/Issue protocol. Furthermore, the size of the group is not hidden
and hence it actually might not be that difficult to infer the population of the group given that the identity of the group manager is public. Also, the requirement relies on both authorities
being honest. It might also be worth mentioning that various existing models for group signatures grant access to the registry table mainly to the opener/issuer and some allow the member to only access
their entry in the table and hence they do not necessarily require that such a table being known to other parties. Also, in practice, this proposed added privacy feature comes at the expense of increasing
other overheads, e.g. size of the group information.
The efficiency comparison in figure 5 only considers the signature size which I think is not fair. It should include other efficiency metrics such as efficiency of signing, size of keys and public information
published at each epoch, etc. Also, [44] estimates Groth-Sahai efficiency as per the original Groth-Sahai proof complexity and not the fine-tuned instantiation of the proof system so that should also be taken into
consideration when comparing the new instantiation with [44].
Overall, I think the paper's novelty is rather incremental and hence I think it is below par for ACM CCS. Moreover, I am not convinced of the importance of the new security requirement proposed and do not envisage
that such a requirement is crucial for applications of group signatures. On that basis, I am inclined towards rejection.
Other issues/questions/typos:
-) What happens if in the Join-Privacy game in the first stage of the adversary, the adversary calls ADDU on both challenge users?
-) The UpdateGroup algorithm syntax specifies that members to be revoked as a set whereas in Leave-Privacy game the algorithm is called with individual members
-) Strictly speaking, it is not correct to say the construction is in the standard model as it relies on a common string generated by trusted third party
-) Use \mbox{-} instead of $–$ in the advantage in the last line of page 5
-) Page 6, [if it protect] --> [if it protects]
Strengths
---------
Group signatures are a central cryptographic primitive and has received a lot of attention from the community and it is therefore commendable to pursue improvements to the security
and efficiency of the notion, especially when the fully dynamic group setting is concerned.
Weaknesses
----------
The new requirement the authors introduce failed to impress me and the applications listed, e.g. defending against targeted DoS of group members, to motivate the need for the new requirement
has not convinced me that the requirement is as crucial as the paper tries to sell it. Moreover, the defined variant still relies on a table containing public keys of the potential members
being public which could, for instance, exclude existing constructions in which the user key pair is generated as part of the Join/Issue protocol. Furthermore, the size of the group is not hidden
and hence it actually might not be that difficult to infer the population of the group given that the identity of the group manager is public. Also, the requirement relies on both authorities
being honest. It might also be worth mentioning that various existing models for group signatures grant access to the registry table mainly to the opener/issuer and some allow the member to only access
their entry in the table and hence they do not necessarily require that such a table being known to other parties. Also, in practice, this proposed added privacy feature comes at the expense of increasing
other overheads, e.g. size of the group information.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Review #770D
===========================================================================
Overall merit
-------------
3. Weak accept
Reviewer expertise
------------------
3. Knowledgeable
Paper summary (2-3 sentences)
-----------------------------
A Fully dynamic group signatures scheme with membership privacy is similar to a FDGS with the main difference of lacking a member registry, and guaranteeing privacy wrt join and leave operations.
The construction operates by having group members sign via a SFPK scheme, ie a signature scheme where verification keys are blindeable. In every epoch member keys are re-blinded individually and members are offered an (encrypted) blinding factor and endorsement by the trusted issuer on their blinded key. The endorsements themselves are signed via a SPS scheme and are thus also blindable.
Comments for author
-------------------
I enjoyed reading the paper as it is clearly organised and presented, especially in the face of size restrictions. The paper also serves as a good introduction to the area both in terms of models as well as constructions. The authors follow the model of [16] with MP-specific additions and the necessary deviations. This helps ease readers into the new notions, but would bennefit from some explicit callouts wrt the deviations (e.g $reg$ being private is mentioned inside the discussion/intuition of S. 3.3).
My main gripe with the paper is the motivation: while the importance of keeping membership private is important at first glance, it is diminished considerably by two issues: first, as noted in the text, efficient solutions seem to imply the size of the membership is made public, and second, there is little discussion of how valuable privacy actually is, if identities are made pseudonymous e.g by having $reg$ values appear nowhere else. There is some hint at that in the introduction (wrt members having different levels of delegation, pottentially highlighting a use case where user keys are reused amongst multiple groups), so I believe that such an argument can be made.
The technical side of the paper is robust, with the expected level of formalism for the venue. The generic construction seems somewhat straighforward in view of [5]+[26], but the optimized version is less so. The size metrics also operate in the paper's favor.
In terms of notation, I'd prefere that the implicit parsing is reversed for reasons of readability. In the figures, "parse x as (y,z)" is presented as "x=(y,z)" while "(y,z)=x" would better follow the convention of the RHS being assigned to the LHS. This is especially relevant in CS.UpdateGroup, where in line 1 $msk=(skd,sks)$ represents parsing and in line 3 $msk:=(skd,sks')$ represents assignment.
Strengths
---------
Clear presentation and definitions
Good coverage of related work
Integration with existing models
Generic Version + Optimized instantiation with size metrics and comparison
Weaknesses
----------
Weak motivation (vs keys being pseudonymous)
Review #683A
===========================================================================
Overall merit
-------------
1. Reject
Reviewer expertise
------------------
4. Expert
Paper summary (2-3 sentences)
-----------------------------
The paper builds TrollThrottle, a system for rate limiting anonymous account postings globally (i.e. across multiple websites). It does so using existing cryptographic protocols.
Comments for author
-------------------
There are several issues with this paper:
* Rate limited anonymous authentication is not new. There are many schemes that provide it. Why use DAA? Why not "How to win the clone wars: Efficient Periodic n-Times Anonymous Authentication", bulk issue single use credentials, or any of a set of techniques with more modern and efficient blind signature primitives? DAA does not seem to be the right choice here.
* The problem of verifying identities is not well addressed. Reddit, youtube, and twitter have trouble dealing with troll accounts (usually throw aways) without the added complications introduced in this setting. Why would we expect TrollThrottle to help? Implicitly, the authors are asserting that by making identities global, stronger and practical id verification schemes could be used. But if there were strong schemes, it seems some provider would use them if only locally on their platform.
* The system is not practical:
* It takes 1.5 seconds on average to submit, check and post a comment. This does not seem acceptable. Again, other anonymous credential schemes would likely be faster, but were not explored.
* It cannot scale to global usage. To prevent multiple use of credentials, the system relies on an append only ledger that must:
1. log every single use of a credential anywhere on the web and
2. check and block duplicates.
Such a service would need to handle the combined flow of comments on twitter, reddit, youtube and facebook. The authors benchmarks don't model this level of load. Moreover they do not model the overhead of requests from those sites. It seems they simply model wall clock run time of checking a list of posts.
The idea of enforcing a global limit on comments across the internet simply isn't plausible.
One might be able to deploy TrollThrottle to cover a small number of medium sized sites. But what is gained by covering them together ? Why not just do limits per website? Performance would likely be greatly improved.
* The paper does not propose new cryptography. As such its a systems and implementation paper. However, it does not actually explore the appropriate primitive for use here. There are several anonymous credential schemes that likely provide better performance: the authors should consider " Anonymous Credentials Light", "Algebraic MACs and Keyed-Verification Anonymous Credentials", the recent "Fast Keyed-Verification Anonymous Credentials on Standard Smart Cards," or Pointcheval sanders signature. Most of these can be adapted to the n-time anonymous authentication setting and offer better performance than DAA. These alternatives should be discussed and the promising ones benchmarked.
Strengths
---------
The problem of bulk content spamming is a long standing issue effecting email, web comments, and even conference submissions.
Weaknesses
----------
Trollthrottle is neither novel, nor efficient, nor effective.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Review #683B
===========================================================================
Overall merit
-------------
3. Weak accept
Reviewer expertise
------------------
4. Expert
Paper summary (2-3 sentences)
-----------------------------
This paper presents TrollThrottle, a system designed to thwart astroturfing campaigns by imposing a real-world cost on the act of creating an identity and then rate-limiting each identity in the system. The scheme comprises a relatively modest modification of Brickell and Li's DAA with a public ledger to record comments that ought (or ought not, as it may be) published on participating websites.
Comments for author
-------------------
I have conflicting feelings about this work. On the one hand, you target an important problem and have done a reasonable job of looking at the big picture. I like the fact that users in the scheme can publicly shame websites that choose not to post their comments for reasons that fall outside that website's terms of use. On the other hand, I struggled to find any fundamentally new/interesting technical contributions, and the paper lacked a direct comparison with prior work in this space. This leaves me wondering whether you've really done anything new, or simply built a more polished version of what already exists in the research literature. Given the importance of the problem, I think there is still real value in efforts of the latter form; however, I'm not sure that CCS would be the correct venue for such work.
The precise nature of the unlinkability should be more clearly described. It seems that one can decisively conclude that two comments with different basenames (in the same epoch) came from different users, which necessarily makes the nature of unlinkability provided by TrollThrottle significantly more nuanced than what one would normally refer to as "unlinkability".
**Random nits:**
Abstract: "...effective[;] however, we..."
S1: "...also called `cyberturfing'[,] is a [S]ybil..."
- "succumbed under the weight of moderation" $\gets$ odd word choice. It almost sounds like you're claiming the NYT no longer exists...
S2.2: "...public ledger keeps record[s] about..."
S3: Suddenly the subscript $I$ is in italic math fonts, whereas previously it was upright. Is this intentional and intended to communicate some meaningful distinction? Or is it merely an artifact of inconsistent macros? FWIW, the italicized $I$ typesets much nicer and matches the notation used when referring to the issuer in non-subscripts.
Def 2(3): You seem to have paired a $\Bigl[$ with a $\bigr]$.
Def 4: Is there a distinction between $h$ and $\mathsf{h}$? (Occurs many times going forward...)
S3.4: "(see Section 5.6verification)"
S4: "(this would allow her to comment the same thing twice)." $\gets$ ??
S5.0.1: "...large-scale fraud would have serious repercussions for the issuing government." $\gets$ This is debatable at best! Had Russia helped the IRA obtain ~3k fake credentials, would it have made the repercussions worse? What if China did the same? Or North Korea? Or the USA?
- "...this can easily be resolved by using..." $\gets$ I would caution against calling the seed of an idea "easy" prior to fleshing out its details; who knows what gotchas lurk just beneath the surface?
S5.1: "save on ~~personal~~ [personel]" (??)
- "...this will raise doubts." $\gets$ will it? In the intro, you claimed just ~3k identities related to the IRA. Would 3k fake Reddit users or NYT subscribers raise doubts, or would they disappear in rounding errors?
- "...or [is] a readily available governmental service..."
- As crazy as it may sound, a substantial portion of some populations don't have a passport. Indeed, in the US it is very controversial to require *any* form of state-issued ID for voting because doing so, in practice, implicitly suppresses the vote from large swaths of the population. Indeed, even if TrollThrottle were effective in thwarting IRA trolls, it might end up being equally effective in silencing certain demographics that those IRA trolls sought to undermine in the 2016 elections...
Fig 2, step 3: you have a superfluous ')'
S5.5: "...that his genesis... She concludes..." $\gets$ your gender pronouns don't seem to agree
5.6: "...where they can log[ ]in from..."
- "$sk_U$ derivable from their login and password are chosen by themselves." $\gets$ I'm having trouble parsing this sentence
5.6: \$634,501 seems like a big number, but it's really not so large next to the budget you cited for the IRA in your introduction...
S6: You keep saying "we *will*" instead of "we *did*"; was this text lifted from a research proposal that was written before you actually did this?
- "...without any modification to the server[-]side code..."
S6.2: "...we simulate the load on [a] [R]uby on [R]ails implementation..."
S7: "...driven ~~by~~ both by learning..."
S8: "...Sybil-detection is strictly simpler..." $\gets$ if you're going to employ loaded words, please provide an argument. Sybil detection is not generally regarded as "simple".
- "Building on the same assumptions, a Sybil-detection scheme could be built by pseudo-randomly defining sets of users need to show liveness at the same time" $\gets$ interesting idea, but I'm not sure how you'd make this usable in practice
S9: "...by using a ledger [and] a common set of rules..." (??)
- `credit` $\mapsto$ `credit'
Strengths
---------
+ The paper is pleasantly well written.
+ TrollThrottle targets an important problem of increasing relevance.
+ The authors have implemented their approach and demonstrated its feasibility on a subreddit; they also argue that the total cost of running their protocol is peanuts relative to the cost of hiring a team of moderators.
Weaknesses
----------
- The construction itself is not terribly interesting from a technological perspective.
- The paper does not clearly articulate how TrollThrottle relates to/improves upon a handful of existing works; e.g., $n$-TAA.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Review #683C
===========================================================================
Overall merit
-------------
2. Weak reject
Reviewer expertise
------------------
2. Some familiarity
Paper summary (2-3 sentences)
-----------------------------
The paper addresses astroturfing. It presents an approach which allows users to post on different websites under different pseudonyms while limiting each user to a fixed number of posts per time frame. The approach is based on direct anonymous attestation.
Comments for author
-------------------
While the presented approach seems to be a novel solution to the problem of astroturfing, I would imagine that users will avoid web pages if they have to identify themselves with their id in order to write comments. Furthermore, your system forces each user to use a new pseudonym per comment. Sometimes, however, linkability might be desirable.
It would be helpful to add more explanation to the description of your approach (Section 2.2). You could, for example, state which concrete party will play which role in the protocol, letting the reader get an impression of how the system would actually be used. I had to read the detailed description of the protocol to fully understand the overall idea. This can be improved.
Your protocol is split into several parts. First, you introduce a basic version. Afterwards, you make several extensions to it (encryption messages on the ledger, revocation, etc.). But there is only a security proof of the basic version.
Some parts of the protocol are already in the basic version but first explained in the extensions. For example, the hash function $h$ is used in the basic version (Page 4), but why we use a hash function is first explained on Page 7 in the description of Figure 2. In addition, in the description you stated that a core feature of your protocol is that domain names are bound to some specific values. This is not part of the TrollThrottle protocol, it is first introduced in Figure 2.
Furthermore, there are some technical problems in Definitions 2 and 4:
- You defined NymGen as a deterministic algorithm. Since it should, with high probability, output the same as NymExtract, it follows that the used pseudonyms of the users are easy to link to specific users.
- The steps in Definition 4 are not linked to specific parties ("compute the parameters", "execute ..."). You should make clear which parties run which parts of the protocol.
- Definition 4 does not include identity verifiers. For example, on Page 7 you stated that we assume direct communication between the issuer and the verifier. But the latter is not participating in the protocol at all.
- You did not define NymExtract.
- Often it remains unclear for which message $\sigma$ (variable for a signature) is a signature.
- On the ledger, the comment to be published is hashed. But after the server receives this data from the ledger, the protocol assumes he knows the comment. How is that possible? As presented in Figure 1, users and servers only communicate over the ledger.
You did not motivate all parts of your approach. For example, why do you consider encryption of comments on the ledger (section 5.2)? Furthermore, which parties hold the secret key? What is the billing period used for?
- Figure 2 and following: What do you mean by "principals"? As stated before it would be easier if you clearly describe which parties are involved.
- Figure 2: what do you mean by "m is acceptable"?
Further Remarks:
- You have a lot of different verifies: the verifiers for the identities of the users, the verifiers of the comments of the users, the verifies of the DAA scheme, etc. At many places you just write "verifier", leaving open which verifier is actually meant. For example on Page 6 you describe the issuer of the DAA scheme and stated that he cannot forge identities without collusion with a verifier. Here you should clearly state that you mean the identity verifier rather than the verifier of the DAA scheme.
- Figure 2: in Step 2, there is a superfluous ')'.
- What is the purpose of Appendix A?
- Theorem 5: What is $\omega_2$?
Strengths
---------
- The approach seems to be a novel solution to an interesting problem.
Weaknesses
----------
- There are issues in the description of the system.
- Some building blocks are not motivated such that their purpose remained unclear.
- There is a security proof of the basic version only.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Review #683D
===========================================================================
Overall merit
-------------
3. Weak accept
Reviewer expertise
------------------
2. Some familiarity
Paper summary (2-3 sentences)
-----------------------------
This paper aims to tackle the problem of detecting troll accounts in an open online commenting environment. The solution uses an extension of DAA that provides instant linkability across a global identity domain to detect when a series cooperating of pseudonym accounts have reach a collective commenting limit. The authors present an implementation and validate it in several scenarios.
Comments for author
-------------------
This paper addresses an interesting challenge, how can we limit the amplification effect of malicious actors creating multiple accounts in a public forum? The authors created a solution that aims to provide accountability across a user's pseudonyms while also maintaining a level of unlinkability between those accounts.
The authors also evaluate the system in terms of performance and give a reasonable indication that certain overhead costs are not unreasonable. However, the simulation only begins to touch on many of the real challenges that this system will have to address. Public ledgers incur costs beyond storage including potentially lengthy network propagation, consensus, and congestion. This is not well justified in the paper and raises concerns about scalability.
Another major challenge is finding an Identity Verification Service that will be universally applicable to most websites and regions. Certainly, it can be argued that for something like a national debate platform on the topic of elections, a national identity could be used for registering an IVS to get access to online forums, but the same could hardly be said for more general or international forums. Moreover, if a major online newspaper could rely on real human identity registration, then they may very well want to prohibit the ability to create pseudonyms all together, which eases challenge of limiting comments. Finally, there is always the consideration that for a dedicated state actor, obtaining legitimate identities may not be such an unreasonable cost. The authors quote a rough estimate of around $600K, but this is quite insignificant to well-funded actors. Ultimately, addressing all of these issues would be far more than expected of a conference paper, but greate
r discussion of it is warranted.
Strengths
---------
+ The paper hits on a highly relevant and challenging topic
+ The solution considers different integration models and approaches to address practical challenges of building such a system
+ The author attempt to validate the properties of the design formally and empirically
Weaknesses
----------
- The solution leverages a public ledger for auditability, but evaluation does not consider overhead due to consensus protocols
- Real world trolls could obtain multiple legitimate accounts to bypass the threshold
- Solution seems to assume a centralized identity authority for all or most comment forums.