You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What about the scenario where an app looks non-malicious in the current language, but serves malicious fields / values in the localization members of the manifest? e.g. You install in spanish (system is spanish language), but you switch to the english language on your system after. What if the manifest specified, say, "Bank of America" on their english bits, change the icon to that, etc?
I'm not sure it's possible for a site to detect the system's current language setting... maybe it is, it would make sense it could... so then it could change itself?
I think we can use similar protections we have for manifest update, where any changes to security sensitive members would require a confirmation. And so we would likely need to NOT give the OS all the translations of these security sensitive members until that switch is detected, and then we need to show a dialog...
Anyways - I suspect we might want to put something in the spec to alert user agents to this type of attack.
The text was updated successfully, but these errors were encountered:
The web application has a name & icons defined for both French and English.
Steps are:
User installs the web application.
User changes their system locale from English to French
Result
The name and icon shouldn't be updated without user consent or appropriate heuristics.
The developer should not expect security sensitive members to update immediately. They may update with user consent by the UA, or never.
To prevent security sensitive members from updating without the user knowing:
The user agent can use the system's locale to select the appropriate security sensitive members at install time.
The user agent may discard other localizations for security sensitive members because the user has not seen them.
The user agent may keep them, but require user consent or or can rely on heuristics to allow updating presented security sensitive members when the user changes their system's locale.
What if we decided to accomplish two things that are needed here, one is this warning, but also to make a very brief description of update:
Algorithm to update manifest presentation
Given two manifests old and new, who's computed app id are the same.
The user agent will update the presentation of non-security-sensitive manifest members.
The user agent may discard updates to presentation of security sensitive members.
The user agent may require user consent or heuristics to allow updating presentation of security sensitive member.
how this hooks in for localized stuff
When the user's system locale changes, run the update algorithm with 'old' being the current manifest presentation, and 'new' being the new presentation with the new system locale applied?
@mkruisselbrink brought this up today:
What about the scenario where an app looks non-malicious in the current language, but serves malicious fields / values in the localization members of the manifest? e.g. You install in spanish (system is spanish language), but you switch to the english language on your system after. What if the manifest specified, say, "Bank of America" on their english bits, change the icon to that, etc?
I'm not sure it's possible for a site to detect the system's current language setting... maybe it is, it would make sense it could... so then it could change itself?
I think we can use similar protections we have for manifest update, where any changes to security sensitive members would require a confirmation. And so we would likely need to NOT give the OS all the translations of these security sensitive members until that switch is detected, and then we need to show a dialog...
Anyways - I suspect we might want to put something in the spec to alert user agents to this type of attack.
The text was updated successfully, but these errors were encountered: