This bug requires manual review: Reverts referenced in bugdroid comments after merge request.
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), Abdul Syed@(Desktop)
For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Large change (c#31) for a new feature two weeks past feature freeze - and the feature hasn't been enabled by default until now?
We're actively developing new merge guidelines (will be shared with the team soon) and this is violating a couple of the principles we're setting out there, so rejecting this for 59 - we should wait for 60. That said, it's possible our parameters are too strict, so if you'd like to chat about it you can ping me and I'm happy to discuss.
**Bulk edit**
Feature freeze for M-60 is today!! (Friday May 12), and we are trying to lock down the shipping set of features. Your feature has either M=60 or Launch-M-Target=60-Beta/Stable-Exp, but has not moved to a review requested state yet (Launch-M-Status=Review-Requested/Approval-Requested).
To help clarify what's shipping, we will change the milestone label for your launch to M-60 by Weds, 5/17 (since there appears to be no activity in review). If you still plan to ship for M-60, please transition to a review/request state now (Launch-M-Status=Review-Requested/Approval-Requested).
Thanks for your help in making our data set cleaner, it's a big help to the cross functional teams!
What's the basis for the 100,000 limit? It seems so high as to effectively not be a limit; in which case, why have a limit at all? (Also, it's duplicated in the code, potentially leading to divergence in the future?)
Chris, the 100,000 limit is to prevent out-of-memory errors. 100K origins at ~250 ASCII chars each is ~25MB, so easily fits in memory. This should not open us up to attacks.
modules/payments/AndroidPayTokenization.idl led me here.
The URL described in the IDL file is not found.
Could you tell me (1)is AndroidPayTokenization still used, (2)where is its spec, and (3)do you have any plan to update/remove this file?
For the issue 816352 , I'd like to drop use cases of "Dictionary" type in idl.
Hello!
The URL should be updated to https://developers.google.com/pay/api/web/paymentrequest/tutorial.
AndroidPayTokenization is still being used on Android in the browser process. It's not a web standard, so there's no spec for it.
Because we send this data to the browser process, it needs to be serialized. There're two ways to serialize the data:
1) Convert to JSON string. This would require parsing an untrusted JSON string in the browser process, which is dangerous, so we would like to avoid it.
2) Convert into an IPC structure. This avoids JSON string parsing in the browser process. We prefer this method for security. Here's the IPC structure:
https://cs.chromium.org/chromium/src/third_party/WebKit/public/platform/modules/payments/payment_request.mojom?rcl=abc05e02599c0aa1ad88da9940619f57d887d77c&l=83
We do have a plan to remove this file when the Google Payments team switches over to the Generic 3rd party native Android payment app API, which was implemented in this bug here. The switch is in their task queue, but is a low priority, unfortunately. When the switch happens, all mention of AndroidPay can be removed from Chrome.
As for issue 816352 , can you please explain what is meant by "dictionary definitions"? Thank you.
Comment 1 by rouslan@chromium.org
, Jun 15 2016