7 ms·

> I hope the developer finds another load of permissions they can tighten up, resubmits, and is approved. You're missing the point here. The developer isn't gi

> I hope the developer finds another load of permissions they can tighten up, resubmits, and is approved. You're missing the point here. The developer isn't given any guidance on what needs tightening. This shouldn't be guess and check. These rules impact this developer's livelihood. They should be well defined, documented, and communicated.

the_gipsy 6y ago
> These rules impact this developer's livelihood. Let this be the millionth lesson of "the perils of building on a platform instead of on a protocol".
- crankylinuxuser 6y ago
  You misspelled "sharecropper".
  - fdavison 6y ago
    I don't know why you are being downvoted, sharecropper is exactly the right metaphor.
danpalmer 6y ago
Well they did give details on what needs tightening, it's just that those details are in the form of policy points not being hit. What do you think they should be providing? Honest question, I have some ideas but they all feel very tricky/error prone to implement.
- laughinghan 6y ago
  At the very, very least, they could identify which of the permissions are in violation and need to be made more restrictive, and which aren't. Someone at some point at Google clearly had that information when they decided to flag the extension, but Google's processes failed to ensure they communicated it. For the record, I actually agree with you that this is a good policy and will be a positive outcome for users. But while you seem to agree that Google could have handled this better, you're not doing a good job of acknowledging just how developer-hostile Google was here, which is why you're getting a lot of pushback.
  - danpalmer 6y ago
    Most of the discussion on this link is about how Google is being developer hostile. I think that's getting plenty of attention. > At the very, very least, they could identify which of the permissions are in violation If they've flagged this through user reports of the permissions being too wide then they may not actually know which permissions need to be changed. This is purely speculation though.
    - rrss 6y ago
      > they may not actually know which permissions need to be changed How can they not know? They decide whether the update is accepted or rejected, and there's somebody or something at google that makes that decision, so google has to know. If they didn't know what permissions need to be changed, how is the accept/reject decision made? Something like "accept the fourth try if the developer makes it that far because it is probably an improvement?"
    - function_seven 6y ago
      > ... may not actually know which permissions need to be changed. Sure, the first notice may have come from user flags, and the motivation for those flags is unknowable. But it's been rejected again, after substantial permissions pruning. Either they know why they rejected the update, in which case they should tell the developer; or they don't know why they rejected the update, in which case they're holding developers hostage to an inscrutable black box. Both scenarios are shitty.
    - laughinghan 6y ago
      Most of the discussion on this link is about how Google is being developer hostile. I think that's getting plenty of attention. You are certainly within your rights to state things divisively if it pleases you. I was merely suggesting how you might make your point in a way people will agree with you. If they've flagged this through user reports of the permissions being too wide then they may not actually know which permissions need to be changed. Even if this were true, 1) what about the update that narrowed the permissions, surely Google knew which permissions remained in violation? Remember, it was the rejection of that update that prompted this post 2) user reports of permissions being too wide should also be required to identify the specific permission that is in violation. That would not only help the developer, but also help Google make the decision on whether to ultimately ban the extension 3) Google should have clearly stated in the initial message that they hadn't actually verified that the alleged violations are occurring
- laughinghan 6y ago
  For comparison, some anecdotes elsewhere in the thread about how Apple attaches screengrabs and even decompiles apps to point to exact methods/lines of code in apps they reject from the iOS App Store, even small free ones: https://news.ycombinator.com/item?id=23170498 https://news.ycombinator.com/item?id=23170498

the_gipsy 6y ago

> These rules impact this developer's livelihood. Let this be the millionth lesson of "the perils of building on a platform instead of on a protocol".

crankylinuxuser 6y ago
You misspelled "sharecropper".
- fdavison 6y ago
  I don't know why you are being downvoted, sharecropper is exactly the right metaphor.

danpalmer 6y ago

Well they did give details on what needs tightening, it's just that those details are in the form of policy points not being hit. What do you think they should be providing? Honest question, I have some ideas but they all feel very tricky/error prone to implement.

laughinghan 6y ago
At the very, very least, they could identify which of the permissions are in violation and need to be made more restrictive, and which aren't. Someone at some point at Google clearly had that information when they decided to flag the extension, but Google's processes failed to ensure they communicated it. For the record, I actually agree with you that this is a good policy and will be a positive outcome for users. But while you seem to agree that Google could have handled this better, you're not doing a good job of acknowledging just how developer-hostile Google was here, which is why you're getting a lot of pushback.
- danpalmer 6y ago
  Most of the discussion on this link is about how Google is being developer hostile. I think that's getting plenty of attention. > At the very, very least, they could identify which of the permissions are in violation If they've flagged this through user reports of the permissions being too wide then they may not actually know which permissions need to be changed. This is purely speculation though.
  - rrss 6y ago
    > they may not actually know which permissions need to be changed How can they not know? They decide whether the update is accepted or rejected, and there's somebody or something at google that makes that decision, so google has to know. If they didn't know what permissions need to be changed, how is the accept/reject decision made? Something like "accept the fourth try if the developer makes it that far because it is probably an improvement?"
  - function_seven 6y ago
    > ... may not actually know which permissions need to be changed. Sure, the first notice may have come from user flags, and the motivation for those flags is unknowable. But it's been rejected again, after substantial permissions pruning. Either they know why they rejected the update, in which case they should tell the developer; or they don't know why they rejected the update, in which case they're holding developers hostage to an inscrutable black box. Both scenarios are shitty.
  - laughinghan 6y ago
    Most of the discussion on this link is about how Google is being developer hostile. I think that's getting plenty of attention. You are certainly within your rights to state things divisively if it pleases you. I was merely suggesting how you might make your point in a way people will agree with you. If they've flagged this through user reports of the permissions being too wide then they may not actually know which permissions need to be changed. Even if this were true, 1) what about the update that narrowed the permissions, surely Google knew which permissions remained in violation? Remember, it was the rejection of that update that prompted this post 2) user reports of permissions being too wide should also be required to identify the specific permission that is in violation. That would not only help the developer, but also help Google make the decision on whether to ultimately ban the extension 3) Google should have clearly stated in the initial message that they hadn't actually verified that the alleged violations are occurring
laughinghan 6y ago
For comparison, some anecdotes elsewhere in the thread about how Apple attaches screengrabs and even decompiles apps to point to exact methods/lines of code in apps they reject from the iOS App Store, even small free ones: https://news.ycombinator.com/item?id=23170498 https://news.ycombinator.com/item?id=23170498