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: Fri, 25 Jan 2019 13:30:17 -0800
To: "Svensson, Lars" <L.Svensson@dnb.de>
Cc: "public-dxwg-wg@w3.org" <public-dxwg-wg@w3.org>
Message-ID: <a19dc0a1-a2e7-dd30-9a7f-2b5597d602c4@lbl.gov>
If you're looking for text to answer question 4.13, assuming I'm 
interpreting the question correctly, I'd suggest

The specification does not distinguish between first party and third 
party contexts. The sharing of profile settings information with a third 
party (such as a company wishing to target advertising to those 
interested in a specific topic) would have potential privacy concerns, 
but the specification itself does not address this. Implementors of the 
specification are advised to disclose such use of profile information as 
they would the use of cookies or other user tracking techniques.

And yes, that is for privacy reasons, not technical reasons. Personally, 
I do think it's important to consider privacy issues in the development 
of new technology.

-Annette

On 1/25/19 12:35 AM, Svensson, Lars wrote:
> Hi Annette,
>
> On Wednesday, January 23, 2019 8:02 PM, Annette Greiner [mailto:amgreiner@lbl.gov] wrote:
>
>> 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.
> OK, I see your point and no, I don't think that we can prevent the passing on of profile setting information to third parties (although I'd love to be proven wrong!). Can you suggest some text?
>
>> 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."
> Right, but that would be for privacy reasons, not for technical reasons. Right?
>
> Best,
>
> Lars
>
>> 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

-- 
Annette Greiner
NERSC Data and Analytics Services
Lawrence Berkeley National Laboratory
Received on Friday, 25 January 2019 21:30:43 UTC

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