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

On Friday, January 25, 2019 10:30 PM, Annette Greiner [mailto:amgreiner@lbl.gov] wrote:

> 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.

Thanks Annette, I've updated the wiki page using your proposal.

> 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.

There we're absolutely on the same page! My question way only for clarification.

Best,

Lars


> 
> -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 Wednesday, 13 February 2019 08:26:21 UTC