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: Wed, 23 Jan 2019 11:01:39 -0800
To: "Svensson, Lars" <L.Svensson@dnb.de>
Cc: "public-dxwg-wg@w3.org" <public-dxwg-wg@w3.org>
Message-ID: <8626d39c-6dee-b3ef-0241-8e701e6bb806@lbl.gov>
Hi Lars,

Question 4.13 asks about distinguishing behavior in 1st party and third 
party contexts. I was thinking about third parties like advertisers and 
their third-party cookies. It would be good to prevent profile request 
information from reaching those sorts of third parties, but I'm not sure 
how practical it would be. Can we say something like "Profile settings 
information MUST not be passed to a third party"? Anyway, the answer you 
have to the question is accurate, I'm just thinking we might want to add 
something to the spec to address the issue.

Re the more general comment about offering some MUSTs, see above for an 
example. But this observation is about the spec, not the replies to the 
security questions. In the next round, we might want to add some 
language like "Profile setting data MUST NOT be stored by origins."


On 1/23/19 3:04 AM, Svensson, Lars wrote:
> Hi Annette,
> On Tuesday, January 08, 2019 1:09 AM, Annette Greiner [mailto:amgreiner@lbl.gov] wrote:
>> Thanks for following up on this.
> Thanks for your feedback! I've updated the wiki page [1] to the best of my understanding while taking the liberty to use some of your suggestions verbatim.
>> 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
>> advertising.
> OK.
>> 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.
> I don't think I quite understand what you mean here, particularly your distinction between first-party and third-parte contexts... Can you suggest some text?
>> Question 4.5 should be a yes, I think. Profile preference information is
>> exposed to the origin server.
> OK.
>> Re persisting data to the user's local device, the profile settings in a
>> browser that supports content negotiation by profile would be persisted.
> That's 4.15. OK.
>> 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.
> That's 4.16. OK.
>> 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.
> Here too: Can you suggest some text?
>> 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".
> Fixed.
>> 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".
> Fixed.
> Thanks again!
> [1] https://www.w3.org/2017/dxwg/wiki/CnegPrivacyAndSecurityQuestionnaire
> Best,
> Lars
>> 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

Annette Greiner
NERSC Data and Analytics Services
Lawrence Berkeley National Laboratory
Received on Wednesday, 23 January 2019 19:03:37 UTC

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