rejection notice purple copper

[joette cordsen]

I have been "fighting" the purple metal rejection notices for about a week. Research says its related to how my extension handles user data. I'm not sure what type of user data they are referring to. I thought it might be personal things like user email, name, etc. But I don't do any of that. I don't transmit user data at all unless storing random non personal data in local or sync storage counts - which I'm 100% sure it doesn't. I asked for support with the first rejection and then cleaned up some code that was not implemented that I thought might be causing the problem (I had a variable named useremail which wasn't an actual user email, don't ask me why, lol), its still getting rejected. So what exactly do they mean by user "data". This is a very frustrating situation, I have yet to hear back from support on exactly what the problem is. If anyone can shed some light on this, including how long it takes for someone to actually respond from support,  I would appreciate it.

[Oliver Dunk]

Hi Joette,

Could you share your extension ID and the case ID you received from support?

In general, using the support process is the best way to resolve situations like this. I can take a look to make sure everything is going as expected though.

Thanks,

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

On Tue, Jan 16, 2024 at 11:56 AM joette cordsen <jill...@gmail.com> wrote:

I have been "fighting" the purple metal rejection notices for about a week. Research says its related to how my extension handles user data. I'm not sure what type of user data they are referring to. I thought it might be personal things like user email, name, etc. But I don't do any of that. I don't transmit user data at all unless storing random non personal data in local or sync storage counts - which I'm 100% sure it doesn't. I asked for support with the first rejection and then cleaned up some code that was not implemented that I thought might be causing the problem (I had a variable named useremail which wasn't an actual user email, don't ask me why, lol), its still getting rejected. So what exactly do they mean by user "data". This is a very frustrating situation, I have yet to hear back from support on exactly what the problem is. If anyone can shed some light on this, including how long it takes for someone to actually respond from support,  I would appreciate it.

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/d32d6568-08a0-4b3f-8b79-4653014c1c39n%40chromium.org.

[joette cordsen]

 case number is  0-0382000035017.  extension id is  bpkpgohmmbgdhonlpcffgmlakgilgijc. I just received a response that continues to make no sense to me. It  says 

I'm handling "user data" over http incorrectly. To be honest, I don't think I do this, so I have no idea what the problem is. I don't collect any user data. and I don't transmit any data to any external

processes. My response to their response: 

I don't transmit user data over http. I'm not even sure what you mean by "user data". My extension runs on the client side. It doesn't send anything to a server.

Thru the use of context scripts,  it interacts with private company web pages to track time spent working tasks, and then stores the time tracking information in local storage. To assist users with completing 

their invoices/timecards, it also interacts with private company pages to fill in time keeping information, taking it from local storage. 

Please clarify what you mean by "insecure handling of user data by transmitting data over HTTP."  

[Patrick Kettner]

Hi Joette,

Looking the code of your extension, it looks like in multiple files you are sending a information to http://apps.cordsen.us:9091/. 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/e3d83325-b21e-4545-b3b7-2c1530a17ef7n%40chromium.org.

[joette cordsen]

I appreciate you looking at it - that code was not implemented and has actually been removed in my latest version that I attempted to publish.  And, as I said earlier - it was a bad design on my part

 which is one of the reasons when I migrated to manifest V3 I didn't implement it. Since the first rejection I removed all code that was related to that functionality.

But, just now, doing a quick search on that url - I did find some code that was in the package that did reference that url. Even though that source was not included in the manifest, but is included in the zip file, because its in the folder with all the other code, do you think that could be the issue? I can easily remove it. 

Jill 

[Patrick Kettner]

Hi Joette,

I wouldn't be able to say definitively, as I didn't do the review. But given the explanation from OSS you shared, I would be suspicious of any code that has "http://" in it.