1. Reading is not transactional or remunerative in most cases. There are exceptions (subscription-based content). Those might still be supported without going full-blown shopping, though in general I'd prefer alternate monetisation mechanisms.
2. Shopping involves payment methods and creates tremendous privacy concerns. Both of those are problematic in a generalised browser, to the extent that commerce sites are increasingly limiting which browsers they function with, which is to say, commerce is not a generalised Web capability. Payments functions could be removed from my generalised browser. The commerce-oriented app would have specific attention paid to security and privacy measures.
2a. My uparmoured Web browser using auto-deleting cookies, uMatrix, uBlock Origin, Ghostry, and other features to fight against surveillance and general Web annoyances plays poorly with most shopping sites as is. This means I've got to specifically remove armour to use such sites. This becomes more complicated when having to support others, at work or home, similarly.
2b. Information leakage between non-commercial browsing and commerce-based activity is a major concern and increasing threat. App-separation would provide a further firewall between the two.
3. A hypertext commerce platform could be URI based much as the present Web is. There are non-HTML URIs (ftp:// mail:// news:// doi:// ...). A "shop://" or "httpc://" transport (HTTP Commerce) would clearly distinguish shopping from other Web traffic and invoke the shopping application itself.
4. A possible risk would be that a large and well-resourced commerce provider might decide on delivering its own commerce app, or capture development of that app in much the same way as, hypothetically, a major Internet advertising entity might conceivably optimse a dominant Web browser as an advertising-delivery mechanism. These cases would have to be regulated by a conscientious, empowered, and principled competitions / anti-trust agency.
5. A standardised and capabilities-limited commerce application should reduce the use of dark patterns, or at least make them more difficult and apparent when employed.
Specification of a commerce-oriented application should reflect interests and concerns of vendors, shoppers, competition regulators, finance and payment processors, and advocates for groups of concern (the elderly, disabled, minorities, unbanked, etc.). The limited focus would make this far more tractable than for generalised Web browsers.
1. Reading is not transactional or remunerative in most cases. There are exceptions (subscription-based content). Those might still be supported without going full-blown shopping, though in general I'd prefer alternate monetisation mechanisms.
2. Shopping involves payment methods and creates tremendous privacy concerns. Both of those are problematic in a generalised browser, to the extent that commerce sites are increasingly limiting which browsers they function with, which is to say, commerce is not a generalised Web capability. Payments functions could be removed from my generalised browser. The commerce-oriented app would have specific attention paid to security and privacy measures.
2a. My uparmoured Web browser using auto-deleting cookies, uMatrix, uBlock Origin, Ghostry, and other features to fight against surveillance and general Web annoyances plays poorly with most shopping sites as is. This means I've got to specifically remove armour to use such sites. This becomes more complicated when having to support others, at work or home, similarly.
2b. Information leakage between non-commercial browsing and commerce-based activity is a major concern and increasing threat. App-separation would provide a further firewall between the two.
3. A hypertext commerce platform could be URI based much as the present Web is. There are non-HTML URIs (ftp:// mail:// news:// doi:// ...). A "shop://" or "httpc://" transport (HTTP Commerce) would clearly distinguish shopping from other Web traffic and invoke the shopping application itself.
4. A possible risk would be that a large and well-resourced commerce provider might decide on delivering its own commerce app, or capture development of that app in much the same way as, hypothetically, a major Internet advertising entity might conceivably optimse a dominant Web browser as an advertising-delivery mechanism. These cases would have to be regulated by a conscientious, empowered, and principled competitions / anti-trust agency.
5. A standardised and capabilities-limited commerce application should reduce the use of dark patterns, or at least make them more difficult and apparent when employed.
Specification of a commerce-oriented application should reflect interests and concerns of vendors, shoppers, competition regulators, finance and payment processors, and advocates for groups of concern (the elderly, disabled, minorities, unbanked, etc.). The limited focus would make this far more tractable than for generalised Web browsers.