W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > January 2019

Re: [dxwg] Profiles Guide doc Security and Privacy (#478)

From: Annette Greiner <amgreiner@lbl.gov>
Date: Mon, 7 Jan 2019 16:09:28 -0800
To: "Svensson, Lars" <L.Svensson@dnb.de>
Cc: "public-dxwg-wg@w3.org" <public-dxwg-wg@w3.org>
Message-ID: <66c22143-8784-bee2-15e6-2c78abac87db@lbl.gov>
Hi Lars,

Thanks for following up on this.

I think we should address question 4.1 a bit more fully. Since the web 
server receives information about all profiles prioritized, it could 
obtain information about the user that identifies them by the overlap of 
profiles or a profile plus their IP address. For example, if a user 
requests information with a profile used in a specific area of interest 
and also a company-specific profile, the identity of the person could 
become knowable (e.g., a person interested in model railroads who works 
for Adobe in San Francisco). Moreover, any health-specific profile 
information could hint at personal health information. Also, it's worth 
considering that marketers could look for specific profiles for targeted 

The question about high-value data (4.2) is interesting. There's no 
reason conneg could not be used for high-value data. Could the specific 
profile chosen to obtain high-value data have consequences? What happens 
if stock traders share a profile and that footprint were suddenly seen 
more frequently at a certain company's web site? Could that information 
get passed to a third party? Perhaps this specification should actually 
distinguish between first-party and third-party contexts.

Question 4.5 should be a yes, I think. Profile preference information is 
exposed to the origin server.

Re persisting data to the user's local device, the profile settings in a 
browser that supports content negotiation by profile would be persisted.

Re enabling persistent monitoring, a user with specific settings for 
profiles could be tracked by the headers created by those settings. The 
feasibility of that technique of monitoring depends on the uniqueness 
and the prevalence of profile settings.

I think the above all depends on whether and how browser makers support 
content negotiation by profile. It might be worth considering adding 
some MUSTs to ensure security in future browsers.

4.14 has a typo, I think. It says "The only difference could be that the 
use or profile URIs is prohibited in private browsing mode". That 
probably should say "use of profile URIs".

4.15 has a typo, I think. It says "This specification defines a 
request-/response-interaction and does not specify and storage of data." 
That probably should say "does not specify any storage".


On 1/7/19 7:23 AM, Svensson, Lars wrote:
> Dear Annette,
> On Monday, December 17, 2018 6:59 PM, Annette Greiner [mailto:amgreiner@lbl.gov] wrote:
>> oops, sorry, my comments were for the prof conneg doc, not the guidance!
> So are your comments relevant for the prof-conneg security and privacy section [1]? To me they don't directly address anything in that section or in the answers to the questionnaire [2].
> [1] https://www.w3.org/TR/dx-prof-conneg/#security_and_privacy
> [2] https://www.w3.org/2017/dxwg/wiki/CnegPrivacyAndSecurityQuestionnaire
> Best,
> Lars
>> On 12/15/18 12:08 PM, Nicholas Car via GitHub wrote:
>>> Questions from https://w3ctag.github.io/security-questionnaire/ with
>>> answers:
>>> **4.1 What information might this feature expose to Web sites or other
>>> parties, and for what purposes is that exposure necessary?**  Guidance
>>> document - no code/system exposing anything directly.
>>> **4.2 Is this specification exposing the minimum amount of information
>>> necessary to power the feature?**  N/A
>>> **4.3 How does this specification deal with personal information or
>>> personally-identifiable information or information derived thereof?**
>>> It does not.
>>> **4.4 How does this specification deal with sensitive information?**
>>> It does not.
>>> **4.5 Does this specification introduce new state for an origin that
>>> persists across browsing sessions?**  No.
>>> **4.6 What information from the underlying platform, e.g.
>>> configuration data, is exposed by this specification to an origin?**  N/A
>>> **4.7 Does this specification allow an origin access to sensors on a
>>> user’s device?**  No.
>>> **4.8 What data does this specification expose to an origin? Please
>>> also document what data is identical to data exposed by other
>>> features, in the same or different contexts.**  N/A
>>> **4.9 Does this specification enable new script execution/loading
>>> mechanisms?**  No.
>>> **4.10 Does this specification allow an origin to access other
>>> devices?**  No.
>>> **4.11 Does this specification allow an origin some measure of control
>>> over a user agent’s native UI?**  No.
>>> **4.12 What temporary identifiers might this this specification create
>>> or expose to the web?**  No temporary identifiers. Use of it will
>>> ultimately generate persistent identifiers (URIs) for documents
>>> (profiles).
>>> **4.13 How does this specification distinguish between behavior in
>>> first-party and third-party contexts?**  It does not.
>>> **4.14 How does this specification work in the context of a user
>>> agent’s Private \ Browsing or "incognito" mode?**  N/A
>>> **4.15 Does this specification have a "Security Considerations" and
>>> "Privacy Considerations" section?**  Yes but a trivial one for now. To
>>> be updated.
>>> **4.16 Does this specification allow downgrading default security
>>> characteristics?**  No or N/A.
>>> **4.17 What should this questionaire have asked?**  I can't think of
>>> what it could ask to better probe potential privacy issues for this
>>> kind of Guidance document.
>> --
>> Annette Greiner
>> NERSC Data and Analytics Services
>> Lawrence Berkeley National Laboratory

Annette Greiner
NERSC Data and Analytics Services
Lawrence Berkeley National Laboratory
Received on Tuesday, 8 January 2019 00:10:11 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 April 2019 13:45:05 UTC