Discussion:
Phorm and consent
(too old to reply)
Peter Fairbrother
2008-03-09 11:45:02 UTC
Permalink
I think it is generally agreed that what BT and Phorm propose involves
looking at the content of communications, ie what they are doing is
interception.

Is it lawful interception? People have suggested that it may be, based
on consent. Let's look at RIPA. s3(1):

"Conduct by any person consisting in the interception of a communication
is authorised by this section if the communication is one which, or
which that person has reasonable grounds for believing, is both—

(a) a communication sent by a person who has consented to the
interception; and

(b) a communication the intended recipient of which has so consented."


So the interceptor has to have reasonable grounds to believe that both
the sender and the intended recipient have consented. For HTTP traffic
this will be the user and a server, each taking on both roles.



First. from the user's side, can any opt-out scheme cover this? I doubt
it very much, failing to opt-out is not the same as having consented. It
doesn't say "hasn't objected", it says "has consented".

The Phorm scheme, which relies on the user who wants to opt-out storing
a cookie, doesn't even work in many cases - for example, my browser
deletes any cookies every time it is shut down, for security and privacy
reasons. I don't keep long-term cookies. It's a standard option in
Firefox, and probably most other browsers too. Not having a cookie
stored doesn't mean I have consented.

How about opt-in schemes? Where two people may share a browser, even an
opt-in cookie does not give them reasonable cause to believe the action
of granting consent, as opposed to not objecting, has occurred - and
they won't normally know when that happens, so an opt-in cookie, or even
expressed permission from the account holder to the ISP, is
insufficient - the account holder may not be the sender or intended
recipient of the communication.



And what about the server side of things? For example, I run several
websites, and I do not, and never will, give Phorm permission to
intercept the communications from these websites. It would be possible
for Phorm to get permission from a subset of websites, but not all - do
they only look at traffic coming from those websites (remembering that
the user has to give permission too)?



I can't see how lawful interception based on consent could be made to
work on any substantial scale.



Not to mention the interception issues raised by how they decide whether
consent has been granted - they will need some information for that, and
it seems likely that they will need to intercept in order to get the
information needed to make the decisions.


-- Peter Fairbrother
Peter Sommer
2008-03-09 12:41:09 UTC
Permalink
Peter Fairbrother asks:
>
> And what about the server side of things? For example, I run several
> websites, and I do not, and never will, give Phorm permission to
> intercept the communications from these websites. It would be possible
> for Phorm to get permission from a subset of websites, but not all -
> do they only look at traffic coming from those websites (remembering
> that the user has to give permission too)?
>

Although I agree with you in terms of the need to get explicit opt-in
consent from ISP customers, the position of those who provide a
generally available web-site (ie one that is not password-protected)
seems to be more difficult. What is the purpose of the website if not
to get people to visit it? How in practice do you set up a web-site
to whom all are invited bar a very small number of people/entities?

You also have a further problem: the traffic to the customer goes via
the ISPs facilities - how in practice do you set up an open website so
that the ISP is given permission to pass traffic to its customers but
not to the specific facilities that link into Phorm? (

By the way, one of the difficulties in writing about Phorm's technical
infrastructure is that the precise method of collecting data keeps on
changing).


Peter Sommer
Dave Howe
2008-03-09 12:57:00 UTC
Permalink
Peter Sommer wrote:

> Although I agree with you in terms of the need to get explicit opt-in
> consent from ISP customers, the position of those who provide a
> generally available web-site (ie one that is not password-protected)
> seems to be more difficult. What is the purpose of the website if not
> to get people to visit it? How in practice do you set up a web-site
> to whom all are invited bar a very small number of people/entities?

I think the issue is not who are invited to visit a given site, as who
should be permitted to intercept visits by other users.

If I am willing to talk to you, that doesn't mean I am automatically
willing to have you hang around and listen to conversations I may be
having with other people - nor can I imagine a world where one
willingness could be possibly confused with the other.
Peter Fairbrother
2008-03-09 13:11:32 UTC
Permalink
Peter Sommer wrote:
> Peter Fairbrother asks:
>>
>> And what about the server side of things? For example, I run several
>> websites, and I do not, and never will, give Phorm permission to
>> intercept the communications from these websites. It would be possible
>> for Phorm to get permission from a subset of websites, but not all -
>> do they only look at traffic coming from those websites (remembering
>> that the user has to give permission too)?
>>
>
> Although I agree with you in terms of the need to get explicit opt-in
> consent from ISP customers, the position of those who provide a
> generally available web-site (ie one that is not password-protected)
> seems to be more difficult. What is the purpose of the website if not
> to get people to visit it? How in practice do you set up a web-site
> to whom all are invited bar a very small number of people/entities?

You miss the point. I'm not stopping Phorm visiting my non-password
protected websites - I'm stopping them from intercepting other people
doing so (looking at "my webtraffic").

> You also have a further problem: the traffic to the customer goes via
> the ISPs facilities - how in practice do you set up an open website so
> that the ISP is given permission to pass traffic to its customers but
> not to the specific facilities that link into Phorm?


I don't know what you mean. If the technical difficulty is for Phorm to
stop looking at my webtraffic, as opposed to someone else's webtraffic
when the server and user have given permission, without looking at my
webtraffic in order to do so - then that's Phorm's problem, not mine.

If you mean I don't want to let Phorm see my website, I can eg block
their IPs. But I'm not particularly bothered if Phorm looks at them, I'm
bothered if Phorm looks at other people looking at them.

My webstats are my business. not Phorm's, as is the content I send to
other people.


>
> (By the way, one of the difficulties in writing about Phorm's technical
> infrastructure is that the precise method of collecting data keeps on
> changing).


I'm not at all surprised - I don't think it can be done legally.


-- Peter Fairbrother
Roland Perry
2008-03-09 14:32:49 UTC
Permalink
In article <47D3E204.3000406-1HOZaDBbGgxaa/***@public.gmane.org>, Peter Fairbrother
<zenadsl6186-1HOZaDBbGgxaa/***@public.gmane.org> writes
>If you mean I don't want to let Phorm see my website, I can eg block
>their IPs. But I'm not particularly bothered if Phorm looks at them,
>I'm bothered if Phorm looks at other people looking at them.

Steeping aside from the actual details of how Phorm works (which may not
be entirely determined yet, anyway), what is your policy with regard to
web caches accessing your site?

It may be the case that web caches are used less these days, but would
you have an objection to the intended recipient of a request to your
website being a cache (maybe, even, a look-ahead cache), which then
distributed the answers to customers of the cache (ie customers of that
ISP) at its convenience?

Of course, this isn't just an issue of interception [1] but also one of
the fundamental objections that rightsholders had to whole concept of
caches. After a huge debate, they were persuaded that caches were "OK"
and should be exempt. See the Copyright Directive Article 5.1 and
Recital 33.

[1] If a cache is a legitimate requester of pages, then perhaps it is
the intended recipient. Just as it can be argued that the intended
recipient of this email is a list server, not the entirety of the people
signed up to the list server.
--
Roland Perry
Peter Fairbrother
2008-03-09 15:11:50 UTC
Permalink
Roland Perry wrote:
> In article <47D3E204.3000406-1HOZaDBbGgxaa/***@public.gmane.org>, Peter Fairbrother
> <zenadsl6186-1HOZaDBbGgxaa/***@public.gmane.org> writes
>> If you mean I don't want to let Phorm see my website, I can eg block
>> their IPs. But I'm not particularly bothered if Phorm looks at them,
>> I'm bothered if Phorm looks at other people looking at them.
>
> Steeping aside from the actual details of how Phorm works (which may not
> be entirely determined yet, anyway), what is your policy with regard to
> web caches accessing your site?

They are a pain and a pestilence, and they should be banned outright,
and all the operators shot, after being tortured (though not
waterboarded, ugh) - whether they are doing anything illegal or not, or
doing anything to my webpages or not, just for operating web caches. I
hate them.

That's my _user_ perspective.


As a website owner, they are most definitely "not approved" for
redistribution to people who want to get to "my live website now" - eg
php scripts, rapidly changing fixed pages, and so on. Not that there are
any PHP scripts on most of my webpages, nor do they change rapidly -

- but accessing a webcache simply ain't accessing the live webcontent.



-- Peter
Roland Perry
2008-03-09 15:50:09 UTC
Permalink
In article <47D3FE36.5070706-1HOZaDBbGgxaa/***@public.gmane.org>, Peter Fairbrother
<zenadsl6186-1HOZaDBbGgxaa/***@public.gmane.org> writes
>Roland Perry wrote:
>> In article <47D3E204.3000406-1HOZaDBbGgxaa/***@public.gmane.org>, Peter Fairbrother
>><zenadsl6186-1HOZaDBbGgxaa/***@public.gmane.org> writes
>>> If you mean I don't want to let Phorm see my website, I can eg block
>>>their IPs. But I'm not particularly bothered if Phorm looks at them,
>>>I'm bothered if Phorm looks at other people looking at them.
>> Steeping aside from the actual details of how Phorm works (which may
>>not be entirely determined yet, anyway), what is your policy with
>>regard to web caches accessing your site?
>
>They are a pain and a pestilence, and they should be banned outright,
>and all the operators shot, after being tortured (though not
>waterboarded, ugh) - whether they are doing anything illegal or not, or
>doing anything to my webpages or not, just for operating web caches. I
>hate them.
>
>That's my _user_ perspective.

In a world without the glut of backbone connectivity we appear to have
today, caches might just be the only way to get a decent user experience
at all. Like the Third World, even today.

>As a website owner, they are most definitely "not approved" for
>redistribution to people who want to get to "my live website now" - eg
>php scripts, rapidly changing fixed pages, and so on. Not that there
>are any PHP scripts on most of my webpages, nor do they change rapidly
> - but accessing a webcache simply ain't accessing the live webcontent.

A properly run cache should be aware of dynamic content and refetch it
each time, and as a website publisher you can set refresh times and even
"no cache" flags.

Now, having got that off our chest; what about my point regarding the
cache being the "intended recipient" of a page that the cache asks you
for?
--
Roland Perry
Nicholas Bohm
2008-03-09 16:25:35 UTC
Permalink
Roland Perry wrote:
...

> Now, having got that off our chest; what about my point regarding the
> cache being the "intended recipient" of a page that the cache asks you for?

I think the cache must be among the intended recipients; I don't see how
caching by itself can be interception. Persons requesting things from
the cache are also intended recipients, I would think. If the cache
operator uses the content of the things it fetches for the purpose of
modifying those things before sending them in response to a request,
that sounds like interception.

(Done without consent at both "ends" also sounds like a variety of
wrongs; e.g. passing off against the person whose material is altered,
by analogy with unlawfully putting inserts in newspapers in course of
distribution, which is actionable by the publisher; and some form of
fraud or misrepresentation against the customer who isn't getting what
he asked for but doesn't know it.)

Nicholas
--
Salkyns, Great Canfield, Takeley,
Bishop's Stortford CM22 6SX, UK

Phone 01279 870285 (+44 1279 870285)
Mobile 07715 419728 (+44 7715 419728)

PGP public key ID: 0x899DD7FF. Fingerprint:
5248 1320 B42E 84FC 1E8B A9E6 0912 AE66 899D D7FF
Simon Davies
2008-03-09 16:45:01 UTC
Permalink
(with apologies if this also appears subsequent to my subscription to
uk_crypto)

There's been some commentary on this list - and much bile expelled -
concerning Privacy International's alleged endorsement of Phorm.

I have made it absolutely clear in numerous news outlets that PI does not
endorse Phorm. Any claim by the company or anyone else that PI has signed
off on the technology, its legal compliance or the Phorm process, is
absolutely incorrect. PI does not endorse products or services.

The controversy arose because Gus Hosein and I (both from PI) created a
privacy startup called 80/20 Thinking Ltd, which was asked by Phorm to
review and assess the company's privacy claims. We were not tasked to
investigate compliance aspects under RIPA.

I haven't had chance to review the uk_crypto archive, but if you haven't
done so already, perhaps you should be asking Simon Watkin for his take on
the matter. He has been consulted by Phorm, and as you probably know, has
produced an assessment of the compliance aspects. My own view is that
compliance is largely in the hands of the ISP's.

FWIW, we do believe the company has created some extremely interesting and
privacy friendly technology. And in my view the company has gone above and
beyond the norm to expunge personal data from its system. Of course, that
only deals with one of several controversial aspects of its deployment.

There are dozens of discussion/argument points that I'm happy to address,
but PI's endorsement is not one of them.

Simon Davies
Peter Fairbrother
2008-03-09 17:43:26 UTC
Permalink
Simon Davies wrote:
> (with apologies if this also appears subsequent to my subscription to
> uk_crypto)
>
> There's been some commentary on this list - and much bile expelled -

no, only one little spit .. and I expressed that ..

> concerning Privacy International's alleged endorsement of Phorm.
>
> I have made it absolutely clear in numerous news outlets that PI does not
> endorse Phorm. Any claim by the company or anyone else that PI has signed
> off on the technology, its legal compliance or the Phorm process, is
> absolutely incorrect. PI does not endorse products or services.
>
> The controversy arose because Gus Hosein and I (both from PI) created a
> privacy startup called 80/20 Thinking Ltd, which was asked by Phorm to
> review and assess the company's privacy claims. We were not tasked to
> investigate compliance aspects under RIPA.

Then in accepting that limited contract, you were foolish. Simon D, I
know your heart is at least semi-pure, but ..!!! Stupid? A little greedy?


> I haven't had chance to review the uk_crypto archive, but if you haven't
> done so already, perhaps you should be asking Simon Watkin for his take on
> the matter.

We have asked - but he hasn't been here.

He has been consulted by Phorm,

OHO!! - did they offer to pay him? Simon W .. naaah, you wouldn't accept.

What I really wonder is whether you would, or maybe will, be prepared to
show the Phorm chaps to jail?

:)


and as you probably know, has
> produced an assessment of the compliance aspects. My own view is that
> compliance is largely in the hands of the ISP's.

Could you explain how, please?
>
> FWIW, we do believe the company has created some extremely interesting and
> privacy friendly technology. And in my view the company has gone above and
> beyond the norm to expunge personal data from its system. Of course, that
> only deals with one of several controversial aspects of its deployment.
>
> There are dozens of discussion/argument points that I'm happy to address,
> but PI's endorsement is not one of them.

I thought PI did not endorse anything ...


-- Peter Fairbrother (drink taken) !
Simon Davies
2008-03-09 18:12:01 UTC
Permalink
>>
>> The controversy arose because Gus Hosein and I (both from PI) created a
>> privacy startup called 80/20 Thinking Ltd, which was asked by Phorm to
>> review and assess the company's privacy claims. We were not tasked to
>> investigate compliance aspects under RIPA.
>
> Then in accepting that limited contract, you were foolish. Simon D, I
> know your heart is at least semi-pure, but ..!!! Stupid? A little greedy?

Hardly. We're not legal experts. They appear to all be on this list. We keep
to our core competence. Phorm says "We don't collect personal information",
so we check that claim. Phorm says "We do not create profiles", so we check
that. It's the process we're able to investigate. The legal wrangle is best
left for those who understand the law.

Stupid? A little greedy? Wow, that's a little harsh. I think I'll step
gingerly over the ad hominem attacks.

> and as you probably know, has
>> produced an assessment of the compliance aspects. My own view is that
>> compliance is largely in the hands of the ISP's.
>
> Could you explain how, please?

Phorm is, first and foremost, a platform. As I understand it, Phorm has no
"customer interface" because, strictly speaking, it has no customers, only
random numbers. So from a purely lay perspective I can imagine the ISP's are
responsible for the notice and consent mechanism, assuming notice and
consent are key to compliance.

Simon

>
>
> -- Peter Fairbrother (drink taken) !
>
Peter Tomlinson
2008-03-09 18:37:50 UTC
Permalink
Simon Davies wrote:
>
> Phorm is, first and foremost, a platform. As I understand it, Phorm has no
> "customer interface" because, strictly speaking, it has no customers, only
> random numbers. So from a purely lay perspective I can imagine the ISP's are
> responsible for the notice and consent mechanism, assuming notice and
> consent are key to compliance.
It seems to me that the ICO is beginning to apply a duty of care, which
means not hiding behind contracts or (in the public sector) allocation
of responsibilities to different groups. Basically, don't pass into the
hands of someone else a job that you really should yourself be
responsible for, don't give responsibility to people who do not have
proven capability to discharge it, and don't give misleading advice to
people who don't have proven ability even though they may be claimed to
have responsibility. In the junior doctors recruitment case (MTAS),
DoH was censured. With the new national bus travel concession pass
(which is issued on a smart card) the LAs were given misleading advice
that would if followed have resulted in personal information about the
pass holder being revealed electronically, and the defence included
saying that its the responsibility of LAs (who mostly do not understand
the technology) to comply with the DPA.

With Phorm the argument seems to be that the data collected is
anonymised, but I remember that argument being demolished in the case of
medical data. It seems to me that IP addresses will be collectable and
associated with the activity of the people at those addresses, and that
it will not prove all that difficult to associate them with physical
addresses and thence identify the groups of people living at those
addresses. To claim that Phorm is always and for ever trustworthy and
the ISPs have to be sure that they don't leak is not on. Arguing about
positive opt-in v assumed consent but then having to block Phorm by
holding a cookie is tangential to the real objection: using Phorm is
electronic eavesdropping (interception).

Peter
Simon Davies
2008-03-09 19:05:13 UTC
Permalink
> Simon Davies wrote:
>>
>> Phorm is, first and foremost, a platform. As I understand it, Phorm has no
>> "customer interface" because, strictly speaking, it has no customers, only
>> random numbers. So from a purely lay perspective I can imagine the ISP's are
>> responsible for the notice and consent mechanism, assuming notice and
>> consent are key to compliance.
> It seems to me that the ICO is beginning to apply a duty of care, which
> means not hiding behind contracts or (in the public sector) allocation
> of responsibilities to different groups. Basically, don't pass into the
> hands of someone else a job that you really should yourself be
> responsible for, don't give responsibility to people who do not have
> proven capability to discharge it, and don't give misleading advice to
> people who don't have proven ability even though they may be claimed to
> have responsibility.

Having looked at its system and its gestation, I'd argue that Phorm isn't
passing the buck in this way. I understand what you're saying, and the
healthcare example is compelling, but as far as I can see, the discussions
between Phorm and the ISP's have very much been centred on mutual
responsibility. By that I don't mean to imply that - in terms of the DPA -
Phorm has a legal duty one way or the other, but it does seem to be anxious
to take responsibility above and beyond the requirements of the DPA.
>
> With Phorm the argument seems to be that the data collected is
> anonymised, but I remember that argument being demolished in the case of
> medical data. It seems to me that IP addresses will be collectable

By whom? Certainly not at the Phorm end of the pipe. To the best of our
knowledge there's no way to triangulate IP's and cookies within Phorm.

> addresses. To claim that Phorm is always and for ever trustworthy and
> the ISPs have to be sure that they don't leak is not on. Arguing about
> positive opt-in v assumed consent but then having to block Phorm by
> holding a cookie is tangential to the real objection: using Phorm is
> electronic eavesdropping (interception).
>
If Phorm doesn't use a cookie then surely the only alternative is for it to
collect and store PII, something which it's avoiding at all costs.

> Peter
>
>
>
Kevin Townsend
2008-03-09 19:20:13 UTC
Permalink
Simon Davies wrote:
> If Phorm doesn't use a cookie then surely the only alternative is for
> it to
> collect and store PII, something which it's avoiding at all costs.
>
>
Wow! Does that mean that if the old lady won't give me her handbag, I'm
justified in taking it some other way? Surely I shouldn't be there in
the first place?
Ian Batten
2008-03-09 21:56:03 UTC
Permalink
>>
> If Phorm doesn't use a cookie then surely the only alternative is
> for it to
> collect and store PII, something which it's avoiding at all costs.


Phorm has many alternatives to using cookies. It could operate as a
brokerage for plumbers in large urban areas. It could sell fish door
to door. It could write C++ compilers. The argument ``we must use
cookies or we must collect PII'' begs the question of why they are
doing what they are doing in the first place.

If Privacy International are now providing cover for former adware
companies, whose mode of operation is secret from the public but
Privacy International can still certify it OK under NDA, then good
luck in your new commercial venture.

ian
Simon Davies
2008-03-09 22:40:04 UTC
Permalink
>
> If Privacy International are now providing cover for former adware
> companies, whose mode of operation is secret from the public but
> Privacy International can still certify it OK under NDA, then good
> luck in your new commercial venture.
>

Did you bother to read my previous posting Ian? I was extremely clear that
this has nothing to do with PI. And I'm not under an NDA.

> ian
>
>
Ian Batten
2008-03-10 09:10:02 UTC
Permalink
On 9 Mar 2008, at 22:40, Simon Davies wrote:

>>
>> If Privacy International are now providing cover for former adware
>> companies, whose mode of operation is secret from the public but
>> Privacy International can still certify it OK under NDA, then good
>> luck in your new commercial venture.
>>
>
> Did you bother to read my previous posting Ian? I was extremely
> clear that
> this has nothing to do with PI. And I'm not under an NDA.

So why are Phorm trumpeting their approval from PI? Were you naive
enough to believe that they were employing Simon Davies, and not Simon
Davies of Privacy International honestly even if he says he's doing
other work?

ian
Charles Lindsey
2008-03-10 16:25:04 UTC
Permalink
On Sun, 09 Mar 2008 19:05:13 -0000, Simon Davies <s.g.davies-QBqurZHE+u5aa/***@public.gmane.org>
wrote:

>> Simon Davies wrote:
>>
> If Phorm doesn't use a cookie then surely the only alternative is for it
> to
> collect and store PII, something which it's avoiding at all costs.

Yes, but its not _that_ cookie people are worried about. Its the
'anti-phorm' cookie you have to accept and then not delete in order for
you to be recognized as having opted-out.

If they had set it up so that you had to "opt-in" by accepting and
permanently storing some cookie, then all the fuss would immediately
disappear. But then Phorm/BT would have insufficient 'subscribers' to make
a profit out of it all :-( .

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 
   Web: http://www.cs.man.ac.uk/~chl
Email: chl-***@public.gmane.org      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
Peter Fairbrother
2008-03-10 04:33:55 UTC
Permalink
Simon Davies wrote:
>>> The controversy arose because Gus Hosein and I (both from PI) created a
>>> privacy startup called 80/20 Thinking Ltd, which was asked by Phorm to
>>> review and assess the company's privacy claims. We were not tasked to
>>> investigate compliance aspects under RIPA.
>> Then in accepting that limited contract, you were foolish. Simon D, I
>> know your heart is at least semi-pure, but ..!!! Stupid? A little greedy?
>
> Hardly. We're not legal experts. They appear to all be on this list. We keep
> to our core competence. Phorm says "We don't collect personal information",
> so we check that claim. Phorm says "We do not create profiles", so we check
> that. It's the process we're able to investigate. The legal wrangle is best
> left for those who understand the law.
>
> Stupid? A little greedy? Wow, that's a little harsh. I think I'll step
> gingerly over the ad hominem attacks.

A confusion of hats - as a spokesman for 80/20 you can say "their claims
are true"; but as a spokesman for PI you should be considering the wider
view - "their claims are true, but ..."


BTW, how did you investigate their claims? Did you get to see code? Do
you know how it works? Can you tell us?



-- Peter Fairbrother.
David Hansen
2008-03-09 19:50:30 UTC
Permalink
On 9 Mar 2008 at 18:12, Simon Davies wrote:

> Phorm says "We don't collect personal
> information", so we check that claim. Phorm says "We do not create
> profiles", so we check that. It's the process we're able to investigate.

What is presented and checked may well not be the same as what happens
in reality. That is certainly the case with dodgy companies that wish
to force unwanted advertising on people.



--
David Hansen, Edinburgh
I will *always* explain revoked encryption keys, unless RIP prevents
me
http://www.opsi.gov.uk/acts/acts2000/00023--e.htm#54
Nicholas Bohm
2008-03-09 17:42:55 UTC
Permalink
Simon Davies wrote:
> (with apologies if this also appears subsequent to my subscription to
> uk_crypto)
>
> There's been some commentary on this list - and much bile expelled -
> concerning Privacy International's alleged endorsement of Phorm.

I must have missed it, unless Simon is thinking of another list.

> I have made it absolutely clear in numerous news outlets that PI does not
> endorse Phorm. Any claim by the company or anyone else that PI has signed
> off on the technology, its legal compliance or the Phorm process, is
> absolutely incorrect. PI does not endorse products or services.
>
> The controversy arose because Gus Hosein and I (both from PI) created a
> privacy startup called 80/20 Thinking Ltd, which was asked by Phorm to
> review and assess the company's privacy claims. We were not tasked to
> investigate compliance aspects under RIPA.
>
> I haven't had chance to review the uk_crypto archive, but if you haven't
> done so already, perhaps you should be asking Simon Watkin for his take on
> the matter. He has been consulted by Phorm, and as you probably know, has
> produced an assessment of the compliance aspects.

Has this been published?

> My own view is that
> compliance is largely in the hands of the ISP's.

If compliance (i.e. not committing the offence of interception) depends
on the consents of the clients and the servers involved, Phorm can no
doubt delegate the task of getting the consents to ISPs. Was that what
you had in mind? It would of course leave Phorm as the party guilty of
the offence if the necessary consent wasn't obtained.

Nicholas
--
Salkyns, Great Canfield, Takeley,
Bishop's Stortford CM22 6SX, UK

Phone 01279 870285 (+44 1279 870285)
Mobile 07715 419728 (+44 7715 419728)

PGP public key ID: 0x899DD7FF. Fingerprint:
5248 1320 B42E 84FC 1E8B A9E6 0912 AE66 899D D7FF
Roland Perry
2008-03-09 18:04:12 UTC
Permalink
In article <47D40F7F.6070709-AE7ukr+ASQqsTnJN9+***@public.gmane.org>, Nicholas Bohm
<nbohm-AE7ukr+ASQqsTnJN9+***@public.gmane.org> writes

>> Now, having got that off our chest; what about my point regarding the
>>cache being the "intended recipient" of a page that the cache asks you
>>for?
>
>I think the cache must be among the intended recipients; I don't see
>how caching by itself can be interception. Persons requesting things
>from the cache are also intended recipients, I would think. If the
>cache operator uses the content of the things it fetches for the
>purpose of modifying those things before sending them in response to a
>request, that sounds like interception.

I think this misses the point I was trying to make. That the end user
knows there is a cache (let's assume that for now) and therefore asks
the cache to be an intermediary. Interception can therefore only take
place between the user and the cache, or between the cache and the
website.

Even without that situation, if the cache is discarding or modifying
things, that's not interception (unless there's a non-intended recipient
involved somewhere).

Let's take a postal example: if the letter-sorting machine chews a chunk
out of a letter and (in effect) discards it, delivering the remaining
tatters is not the result of an interception.

>(Done without consent at both "ends" also sounds like a variety of
>wrongs; e.g. passing off against the person whose material is altered,
>by analogy with unlawfully putting inserts in newspapers in course of
>distribution, which is actionable by the publisher; and some form of
>fraud or misrepresentation against the customer who isn't getting what
>he asked for but doesn't know it.)

Phorm is apparently inserting adverts, but I'm still not clear whether
those inserted adverts replace an advert the original webpage was
serving (eg to non-Phormed end users), replacing a blank space, or is
somehow in addition to what was on the page originally.

--
Roland Perry
Ian Batten
2008-03-09 21:46:10 UTC
Permalink
On 9 Mar 2008, at 18:04, Roland Perry wrote:
>
> Phorm is apparently inserting adverts, but I'm still not clear
> whether those inserted adverts replace an advert the original
> webpage was serving (eg to non-Phormed end users), replacing a blank
> space, or is somehow in addition to what was on the page originally.

Most of those would be extremely dubious. An ISP which removed the
origin server's paid-for advertising and replaced it with the ISP's
own paid-for advertising would, I hope, become a leper at the next
ISPA meeting. I would be equivalent to my newsagent getting into my
Guardian and pasting adverts for the local curry takeaway [*] over
those expensive adverts that Nationwide buy. Mucking with the
whitespace would be against those old ``not sold in a mutilated form
or other binding'' provisions in books for the seventies and eighties,
and I suspect there is a more modern analogue --- just because I give
you the right to read the content of my website doesn't mean I give
you the right to distribute it in a mash-up, which would be what such
modification would be doing.

However, I don't think this is Phorm's gig. I think what the Guardian
has signed up to do is sell its advertisers ``we'll place your adverts
with suitable readers''. So I go to the Guardian and say ``I want to
advertise my product in your pages'', and they say ``OK, £X per 1000
page impressions, or £Y per 1000 page impressions by people who are
targeted'', where Y>X but Y<nX, where n is the number of people you
need to show the advert to in order to hit one who Phorm would target.

So I think the underlying Phorm gig is a more complex doubelclick
proposition: website owners sell their advertisers place holders, and
those placeholders are filled by Phorm. Alternatively, website owners
sell the placeholders direct to Phorm, and Phorm then sell the space
to advertisers, but I don't think that can be the case: it wouldn't
provide a path to insert adverts for non-Phorm users.

ian
Roland Perry
2008-03-09 22:07:49 UTC
Permalink
In article <F0E64CA0-F949-4E61-9A8A-09785F20DA46-BFib/+***@public.gmane.org>, Ian
Batten <igb-BFib/+***@public.gmane.org> writes
>
>On 9 Mar 2008, at 18:04, Roland Perry wrote:
>>
>> Phorm is apparently inserting adverts, but I'm still not clear
>>whether those inserted adverts replace an advert the original webpage
>>was serving (eg to non-Phormed end users), replacing a blank space, or
>>is somehow in addition to what was on the page originally.
>
>Most of those would be extremely dubious. An ISP which removed the
>origin server's paid-for advertising and replaced it with the ISP's own
>paid-for advertising would, I hope, become a leper at the next ISPA
>meeting.

Perhaps they are only playing with web pages served by people who have
joined their club.

BIG PENNY DROPS - If that's the case there is the "consent" from the
website that several people have been looking for.

>So I think the underlying Phorm gig is a more complex doubelclick
>proposition: website owners sell their advertisers place holders, and
>those placeholders are filled by Phorm. Alternatively, website owners
>sell the placeholders direct to Phorm, and Phorm then sell the space to
>advertisers, but I don't think that can be the case: it wouldn't
>provide a path to insert adverts for non-Phorm users.

Phorm must be selling something, they are paying the ISPs to install
their gear, and need to make a profit. Whether they are selling direct
to advertisers, or via effectively an agency at each partner website, I
don't know.

If the adverts are selected by dynamically Phorm, I suppose they could
bung in a random one if the subscriber hasn't been Phormed.
--
Roland Perry
Ian Batten
2008-03-09 22:36:19 UTC
Permalink
On 9 Mar 2008, at 22:27, Paul Vigay wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In a dim and distant universe <qkmb+Jc1+F1HFAox-QmCu5Paugg/10XsdtD+***@public.gmane.org>,
> Roland Perry <lists-***@public.gmane.org> enlightened us thusly:
> [Snippety snip]
>
>> If the adverts are selected by dynamically Phorm, I suppose they
>> could
>> bung in a random one if the subscriber hasn't been Phormed.
>
> I thought most web browsers blocked all adverts anyway these days. I
> wouldn't see any adverts anyway, Phorm'ed or not.

Rather like the id cards are the tip of the privacy invading register,
the adverts are the tip of the privacy invading data collection. I
don't care if I don't see the adverts, I still object to having my
data collected.

ian
Dave Howe
2008-03-09 23:06:54 UTC
Permalink
Paul Vigay wrote:
> In a dim and distant universe
> <58DC1126-7CEB-42B5-B8C0-45E7601A204E-BFib/+***@public.gmane.org>, Ian Batten
> <igb-BFib/+***@public.gmane.org> enlightened us thusly: [Snippety snip]
>
>> Rather like the id cards are the tip of the privacy invading
>> register, the adverts are the tip of the privacy invading data
>> collection. I don't care if I don't see the adverts, I still
>> object to having my data collected.
>
> Oh absolutely. I completely agree with you. I was merely making a
> rather facetious comment!
>
> Which makes me wonder that, if adverts are so easy to block, and most
> people do so anyway, why is Phorm going to all the effort unless
> they have further plans on their agenda?

Perhaps said adverts won't be blockable? They may appear to be sourced
from the desired site, and/or be intermezzos where blocking them will
prevent you ever reaching the site you wanted to see?
Roland Perry
2008-03-10 07:20:02 UTC
Permalink
In article <4f7d92ea38ukcrypto-vEWq/***@public.gmane.org>, Paul Vigay
<ukcrypto-vEWq/***@public.gmane.org> writes
>if adverts are so easy to block, and most people do so anyway, why is
>Phorm going to all the effort

Advertiser are spending more online now than in newspapers. It doesn't
really matter if ukcrypto subscribers think that "most people" block
adverts [1], Phorm is in business because of what advertisers think.

[1] I don't think it's true anyway.
--
Roland Perry
Dave Howe
2008-03-09 22:50:42 UTC
Permalink
Paul Vigay wrote:
> I thought most web browsers blocked all adverts anyway these days. I
> wouldn't see any adverts anyway, Phorm'ed or not.

I have seen claims that that is theft from the website. However, I have
also seen that claim for fast-forwarding past adverts on a VCR :)

For that matter though, I have seen more and more popunders make it past
whatever filtering is in place by default on firefox. my response
(perhaps predictably) has been to global-block the entire provider site
the ad was served by, which just incidentally blocks banner ads too
(which before I was simply ignoring)
Peter Fairbrother
2008-03-10 04:52:55 UTC
Permalink
Roland Perry wrote:
> In article <F0E64CA0-F949-4E61-9A8A-09785F20DA46-BFib/+***@public.gmane.org>, Ian
> Batten <igb-BFib/+***@public.gmane.org> writes
>>
>> On 9 Mar 2008, at 18:04, Roland Perry wrote:
>>>
>>> Phorm is apparently inserting adverts, but I'm still not clear
>>> whether those inserted adverts replace an advert the original webpage
>>> was serving (eg to non-Phormed end users), replacing a blank space,
>>> or is somehow in addition to what was on the page originally.
>>
>> Most of those would be extremely dubious. An ISP which removed the
>> origin server's paid-for advertising and replaced it with the ISP's
>> own paid-for advertising would, I hope, become a leper at the next
>> ISPA meeting.
>
> Perhaps they are only playing with web pages served by people who have
> joined their club.
>
> BIG PENNY DROPS - If that's the case there is the "consent" from the
> website that several people have been looking for.

The problem isn't getting consent from websites why pay Phorm - it's
getting consent from everyone else.

If phorm, or anyone, want to target advertising based on user's browsing
habits, they have to what the users's browsing habits are - which means
looking at all the traffic a user does.

Which simply cannot be done legally.

-- Peter Fairbrother
Roland Perry
2008-03-10 08:19:33 UTC
Permalink
In article <47D4BEA7.2070200-1HOZaDBbGgxaa/***@public.gmane.org>, Peter Fairbrother
<zenadsl6186-1HOZaDBbGgxaa/***@public.gmane.org> writes

>If phorm, or anyone, want to target advertising based on user's
>browsing habits, they have to what the users's browsing habits are -
>which means looking at all the traffic a user does.

But the user will be giving them permission to do that. The
communication from the user is something like:

"Dear Phorm, here is a url which I'd like you to scan and use to profile
me, when you've finished doing that, send the url to the website it
represents [1]. When you get the answer (as the intended recipient of
your request to the website) scan the content of the page as well, and
add your additional conclusions to my profile. When you've finished,
send me the page, and if the website in question is one of your
subscribers, you have both their permission and my permission to replace
the adverts with more targeted ones."

[1] Unless it's on your phishing blacklist, in which case warn me, or
Unless it's on your IWF blocklist, in which case pretend it's a 404.
--
Roland Perry
Peter Fairbrother
2008-03-11 07:45:37 UTC
Permalink
Roland Perry wrote:
> In article <47D4BEA7.2070200-1HOZaDBbGgxaa/***@public.gmane.org>, Peter Fairbrother
> <zenadsl6186-1HOZaDBbGgxaa/***@public.gmane.org> writes
>
>> If phorm, or anyone, want to target advertising based on user's
>> browsing habits, they have to what the users's browsing habits are -
>> which means looking at all the traffic a user does.
>
> But the user will be giving them permission to do that. The
> communication from the user is something like:
>
> "Dear Phorm, here is a url which I'd like you to scan and use to profile
> me, when you've finished doing that, send the url to the website it
> represents [1]. When you get the answer (as the intended recipient of
> your request to the website) scan the content of the page as well, and
> add your additional conclusions to my profile. When you've finished,
> send me the page, and if the website in question is one of your
> subscribers, you have both their permission and my permission to replace
> the adverts with more targeted ones."

And the average luser is going to understand that when he gets data from
a website he's actually asking BT/Phorm to get it for him?

And the average website is going to understand that the data they send
to an IP address isn't going to the person who signed on, or accepted a
short-term cookie?

Lead. Pigs. Fly.


-- Peter Fairbrother
Roland Perry
2008-03-11 09:32:00 UTC
Permalink
In article <47D638A1.8080603-1HOZaDBbGgxaa/***@public.gmane.org>, Peter Fairbrother
<zenadsl6186-1HOZaDBbGgxaa/***@public.gmane.org> writes

>>> If phorm, or anyone, want to target advertising based on user's
>>>browsing habits, they have to what the users's browsing habits are -
>>>which means looking at all the traffic a user does.
>> But the user will be giving them permission to do that. The
>>communication from the user is something like:
>> "Dear Phorm, here is a url which I'd like you to scan and use to
>>profile me, when you've finished doing that, send the url to the
>>website it represents [1]. When you get the answer (as the intended
>>recipient of your request to the website) scan the content of the
>>page as well, and add your additional conclusions to my profile. When
>>you've finished, send me the page, and if the website in question is
>>one of your subscribers, you have both their permission and my
>>permission to replace the adverts with more targeted ones."
>
>And the average luser is going to understand that when he gets data
>from a website he's actually asking BT/Phorm to get it for him?

The average user doesn't need to understand it. Any more than he
understands how DNS servers work.

>And the average website is going to understand that the data they send
>to an IP address isn't going to the person who signed on, or accepted a
>short-term cookie?

They will be sending it to the IP address of the Phorm platform. Anyone
looking at the logs will have to find a way of coping with that, just
like they cope with spiders, caches and any other "non-person" accesses
that seem to happen.
--
Roland Perry
Ian Batten
2008-03-11 09:51:31 UTC
Permalink
On 11 Mar 08, at 0932, Roland Perry wrote:
>
> They will be sending it to the IP address of the Phorm platform.
> Anyone looking at the logs will have to find a way of coping with
> that, just like they cope with spiders, caches and any other "non-
> person" accesses that seem to happen.

One difference is that most caches and spiders are operated by people
you _want_ to access your website: caches are just users in disguise,
spiders are usually search engines that (in general) you want to
access your site. If you're not a Phorm customer, Phorm are just
bandwidth and resource leeches.

For example, if the implication that the URLs are spidered by Phorm
offsite (ie not synchronous with the user access) anyone operating a
UK website is going to need to double their bandwidth, as every page
will be fetched twice.

The IP numbers of Phorm's servers will be trivial to locate: you just
access a website you control from an infected ISP and look at your
logs. After that, blocking is easy.

One thing I'm concerned about is that we operate several low-security
portals where we pass passwords in non-hhtps connections, with the
source IP number thrown into the mix. ie you have an account which is
a username, a password, and a source IP number you need to come from.
It's legacy ware, from back in the days when https was a resource
pig. Presumably Phorm are planning to capture passwords and fetch the
URLs from our origin servers?

ian
Roland Perry
2008-03-11 10:50:55 UTC
Permalink
In article <6561277E-6F04-47F1-B8EC-16491FE6E988-BFib/+***@public.gmane.org>, Ian
Batten <igb-BFib/+***@public.gmane.org> writes
>
>On 11 Mar 08, at 0932, Roland Perry wrote:
>>
>> They will be sending it to the IP address of the Phorm platform.
>>Anyone looking at the logs will have to find a way of coping with
>>that, just like they cope with spiders, caches and any other "non-
>>person" accesses that seem to happen.
>
>One difference is that most caches and spiders are operated by people
>you _want_ to access your website: caches are just users in disguise,
>spiders are usually search engines that (in general) you want to access
>your site. If you're not a Phorm customer, Phorm are just bandwidth
>and resource leeches.

That wasn't the question. It was about *knowing* that you were sending
the data to the Phorm platform.

>For example, if the implication that the URLs are spidered by Phorm
>offsite (ie not synchronous with the user access) anyone operating a UK
>website is going to need to double their bandwidth, as every page will
>be fetched twice.

So every Phormed ISP will have to double its bandwidth as well? At the
very least one might expect any second-fetches to restrict themselves to
the simple text. Or perhaps the ISP can stick a cache between the Phorm
platform and the outside world?

>One thing I'm concerned about is that we operate several low-security
>portals where we pass passwords in non-hhtps connections, with the
>source IP number thrown into the mix. ie you have an account which is
>a username, a password, and a source IP number you need to come from.

Do ISP caches know to ignore page accesses like that? I suppose they
must, or this would have been a well known problem.

> It's legacy ware, from back in the days when https was a resource pig.
>Presumably Phorm are planning to capture passwords and fetch the URLs
>from our origin servers?

Maybe you should read the technical descriptions Richard Clayton keeps
alluding to? I haven't got the spare time this week I'm afraid.
--
Roland Perry
Ian Batten
2008-03-11 11:15:33 UTC
Permalink
>
>> One thing I'm concerned about is that we operate several low-
>> security portals where we pass passwords in non-hhtps connections,
>> with the source IP number thrown into the mix. ie you have an
>> account which is a username, a password, and a source IP number you
>> need to come from.
>
> Do ISP caches know to ignore page accesses like that? I suppose they
> must, or this would have been a well known problem.

Most caches pass through anything with a ? in the URL.

>
>
>> It's legacy ware, from back in the days when https was a resource
>> pig. Presumably Phorm are planning to capture passwords and fetch
>> the URLs from our origin servers?
>
> Maybe you should read the technical descriptions Richard Clayton
> keeps alluding to? I haven't got the spare time this week I'm afraid.

Each description I've seen is different. At the moment the whole
thing smacks of a marketing exercise which has no technology behind
it. I'd be interested to know if the likes of 80/20 have seen source
or just slideware, because the question of if (for example) the Phorm
analysis of the returned webpage is done in-line, synchronously with a
second copy or asynchronously with a second copy is opaque. The
statement that blocking webwise cookies acts as an opt-out is new,
because last week it was clear you had to maintain an opt-out cookie.
And so on: I think they're making it up as they go along, so Simon's
imprimatur is of what he saw one week, which isn't what's being
deployed the next.

ian
Roland Perry
2008-03-11 11:34:09 UTC
Permalink
In article <965E933D-6F01-43F2-95EF-DB0DED401992-BFib/+***@public.gmane.org>, Ian
Batten <igb-BFib/+***@public.gmane.org> writes
>>
>>> One thing I'm concerned about is that we operate several low-
>>>security portals where we pass passwords in non-hhtps connections,
>>>with the source IP number thrown into the mix. ie you have an
>>>account which is a username, a password, and a source IP number you
>>>need to come from.
>>
>> Do ISP caches know to ignore page accesses like that? I suppose they
>>must, or this would have been a well known problem.
>
>Most caches pass through anything with a ? in the URL.

And we think Phorm won't? If it's going to break lots of stuff, seems a
bit of a "courageous" decision.

>>> It's legacy ware, from back in the days when https was a resource
>>>pig. Presumably Phorm are planning to capture passwords and fetch the
>>>URLs from our origin servers?
>>
>> Maybe you should read the technical descriptions Richard Clayton
>>keeps alluding to? I haven't got the spare time this week I'm afraid.
>
>Each description I've seen is different.

That's one reason I think it's going to take me more time than I have at
the moment to read *all* the sources and try to spot commonality.

--
Roland Perry
Ian Batten
2008-03-11 11:45:00 UTC
Permalink
On 11 Mar 08, at 1134, Roland Perry wrote:
>>
>> Most caches pass through anything with a ? in the URL.
>
> And we think Phorm won't? If it's going to break lots of stuff,
> seems a bit of a "courageous" decision.

They explicitly say they're taking search terms from Google (etc)
requests. All of those URLs contain a ?: that's how the parameters
are passed. For example,

http://www.google.com/search?client=safari&rls=en-gb&q=roland+perry&ie=UTF-8&oe=UTF-8

A cache would be unwise to try to cache searches and respond with
cached search results: the hit-rate would be low, the implications for
users quite unpleasant. But Phorm explicitly have to catch search
terms, as that's a large part of their proposition.

ian
Chris Edwards
2008-03-11 12:25:23 UTC
Permalink
On Tue, 11 Mar 2008, Ian Batten wrote:

| On 11 Mar 08, at 1134, Roland Perry wrote:
| > >
| > > Most caches pass through anything with a ? in the URL.
| >
| > And we think Phorm won't? If it's going to break lots of stuff, seems a bit
| > of a "courageous" decision.
|
| They explicitly say they're taking search terms from Google (etc) requests.
| All of those URLs contain a ?: that's how the parameters are passed. For
| example,
|
| http://www.google.com/search?client=safari&rls=en-gb&q=roland+perry&ie=UTF-8&oe=UTF-8
|
| A cache would be unwise to try to cache searches and respond with cached
| search results: the hit-rate would be low, the implications for users quite
| unpleasant. But Phorm explicitly have to catch search terms, as that's a
| large part of their proposition.

Aside from the cookie insertion stuff, I'm assuming the content scanner
will be some sort of wire-speed echelon type passive sniffer. In which
case there's little risk of breaking stuff in the way a badly-configured
proxy cache can.
Roland Perry
2008-03-11 12:34:22 UTC
Permalink
In article <B5D69F00-1D46-4843-89F6-A8F5589B419A-BFib/+***@public.gmane.org>, Ian
Batten <igb-BFib/+***@public.gmane.org> writes
>>> Most caches pass through anything with a ? in the URL.
>>
>> And we think Phorm won't? If it's going to break lots of stuff, seems
>>a bit of a "courageous" decision.
>
>They explicitly say they're taking search terms from Google (etc)
>requests. All of those URLs contain a ?: that's how the parameters are
>passed. For example,
>
>http://www.google.com/search?client=safari&rls=en-gb&q=roland+perry&ie=U
>TF-8&oe=UTF-8
>
>A cache would be unwise to try to cache searches and respond with
>cached search results: the hit-rate would be low, the implications for
>users quite unpleasant. But Phorm explicitly have to catch search
>terms, as that's a large part of their proposition.

Can't they "pass it through" and "process it" both at the same time? I
know that probably destroys my model of the Phorm platform as intended
recipient of the answer (from the point of view of the web server).
--
Roland Perry
Peter Fairbrother
2008-03-11 11:05:40 UTC
Permalink
Roland Perry wrote:
> In article <47D638A1.8080603-1HOZaDBbGgxaa/***@public.gmane.org>, Peter Fairbrother
> <zenadsl6186-1HOZaDBbGgxaa/***@public.gmane.org> writes
>
>>>> If phorm, or anyone, want to target advertising based on user's
>>>> browsing habits, they have to what the users's browsing habits are -
>>>> which means looking at all the traffic a user does.
>>> But the user will be giving them permission to do that. The
>>> communication from the user is something like:
>>> "Dear Phorm, here is a url which I'd like you to scan and use to
>>> profile me, when you've finished doing that, send the url to the
>>> website it represents [1]. When you get the answer (as the intended
>>> recipient of your request to the website) scan the content of the
>>> page as well, and add your additional conclusions to my profile.
>>> When you've finished, send me the page, and if the website in
>>> question is one of your subscribers, you have both their permission
>>> and my permission to replace the adverts with more targeted ones."
>>
>> And the average luser is going to understand that when he gets data
>> from a website he's actually asking BT/Phorm to get it for him?
>
> The average user doesn't need to understand it. Any more than he
> understands how DNS servers work.

But the average user is going to believe that he's asking a for a
website when he enters a URL - and therefore the intended recipient, as
intended by the user, is the website.

>> And the average website is going to understand that the data they send
>> to an IP address isn't going to the person who signed on, or accepted
>> a short-term cookie?
>
> They will be sending it to the IP address of the Phorm platform. Anyone
> looking at the logs will have to find a way of coping with that, just
> like they cope with spiders, caches and any other "non-person" accesses
> that seem to happen.

The point is quite different - the intended recipient of any reply to a
spider is the person who sent the spider - but if the website thinks
it's talking to human no 124690 but finds instead that it's talking to
Phorm - well, Phorm simply isn't the intended recipient.


Not to mention that any Judge worth his salt will throw your "contract"
out with no more than a quick look.


-- Peter Fairbrother.
Roland Perry
2008-03-11 11:38:33 UTC
Permalink
In article <47D66784.8080909-1HOZaDBbGgxaa/***@public.gmane.org>, Peter Fairbrother
<zenadsl6186-1HOZaDBbGgxaa/***@public.gmane.org> writes

>But the average user is going to believe that he's asking a for a
>website when he enters a URL - and therefore the intended recipient, as
>intended by the user, is the website.

And the user presumably doesn't think that the expected recipient of the
emails he sends is a spam filter (or possibly several)?

>>> And the average website is going to understand that the data they
>>>send to an IP address isn't going to the person who signed on, or
>>>accepted a short-term cookie?
>> They will be sending it to the IP address of the Phorm platform.
>>Anyone looking at the logs will have to find a way of coping with
>>that, just like they cope with spiders, caches and any other
>>"non-person" accesses that seem to happen.
>
>The point is quite different - the intended recipient of any reply to a
>spider is the person who sent the spider - but if the website thinks
>it's talking to human no 124690 but finds instead that it's talking to
>Phorm - well, Phorm simply isn't the intended recipient.

Perhaps the website should be more careful about who it thinks it's
sending things to? There seems to be a general consensus that it will be
easy to spot that a request has come from Phorm.

>Not to mention that any Judge worth his salt will throw your "contract"
>out with no more than a quick look.

Which contract was that?
--
Roland Perry
Peter Fairbrother
2008-03-11 12:11:45 UTC
Permalink
Roland Perry wrote:
> In article <47D66784.8080909-1HOZaDBbGgxaa/***@public.gmane.org>, Peter Fairbrother
> <zenadsl6186-1HOZaDBbGgxaa/***@public.gmane.org> writes
>
>> But the average user is going to believe that he's asking a for a
>> website when he enters a URL - and therefore the intended
>> recipient, as intended by the user, is the website.
>
> And the user presumably doesn't think that the expected recipient of
> the emails he sends is a spam filter (or possibly several)?

I dunno - but the situation is different. Spam filtering would be
interception if the sender didn't realise it was happening - but it
would be lawful interception under 3(3)(or so it is claimed, and no-one
has argued it out afaict).

Whereas in Phorm's case it would not be lawful interception.
>
>>>> And the average website is going to understand that the data
>>>> they send to an IP address isn't going to the person who
>>>> signed on, or accepted a short-term cookie?
>>> They will be sending it to the IP address of the Phorm platform.
>>> Anyone looking at the logs will have to find a way of coping
>>> with that, just like they cope with spiders, caches and any
>>> other "non-person" accesses that seem to happen.
>>
>> The point is quite different - the intended recipient of any reply
>> to a spider is the person who sent the spider - but if the website
>> thinks it's talking to human no 124690 but finds instead that it's
>> talking to Phorm - well, Phorm simply isn't the intended recipient.
>>
>
> Perhaps the website should be more careful about who it thinks it's
> sending things to? There seems to be a general consensus that it will
> be easy to spot that a request has come from Phorm.

The website has no liability to do anything at all - Phorm are required
to obtain consent from the website.

>> Not to mention that any Judge worth his salt will throw your
>> "contract" out with no more than a quick look.

> Which contract was that?

The one between the user and the ISP implied by :

"Dear Phorm, here is a url which I'd like you to scan and use to
profile me, when you've finished doing that, send the url to the
website it represents [1]. When you get the answer (as the intended
recipient of your request to the website) scan the content of the page
as well, and add your additional conclusions to my profile. When you've
finished, send me the page, and if the website in question is one of
your subscribers, you have both their permission and my permission to
replace the adverts with more targeted ones."




-- Peter Fairbrother
Roland Perry
2008-03-11 12:41:01 UTC
Permalink
In article <47D67701.40500-1HOZaDBbGgxaa/***@public.gmane.org>, Peter Fairbrother
<zenadsl6186-1HOZaDBbGgxaa/***@public.gmane.org> writes

>>> But the average user is going to believe that he's asking a for a
>>>website when he enters a URL - and therefore the intended
>>> recipient, as intended by the user, is the website.
>> And the user presumably doesn't think that the expected recipient of
>> the emails he sends is a spam filter (or possibly several)?
>
>I dunno - but the situation is different. Spam filtering would be
>interception if the sender didn't realise it was happening

Which is true most of the time.

>- but it would be lawful interception under 3(3)(or so it is claimed,
>and no-one has argued it out afaict).
>
>Whereas in Phorm's case it would not be lawful interception.

Why? I'm not persuaded either way, but flat denials don't help.

>> Perhaps the website should be more careful about who it thinks it's
>>sending things to? There seems to be a general consensus that it will
>> be easy to spot that a request has come from Phorm.
>
>The website has no liability to do anything at all - Phorm are required
>to obtain consent from the website.

Only if the interception isn't otherwise legal, and only if you believe
that the website is sending to an IP address other than Phorm's (thereby
making Phorm the intended recipient).

>>> Not to mention that any Judge worth his salt will throw your
>>>"contract" out with no more than a quick look.
>
>> Which contract was that?
>
>The one between the user and the ISP implied by :
>
>"Dear Phorm, here is a url which I'd like you to scan and use to
>profile me, when you've finished doing that, send the url to the
>website it represents [1]. When you get the answer (as the intended
>recipient of your request to the website) scan the content of the page
>as well, and add your additional conclusions to my profile. When you've
>finished, send me the page, and if the website in question is one of
>your subscribers, you have both their permission and my permission to
>replace the adverts with more targeted ones."

That's what the informed consent (although you may wish to argue it's
neither informed nor consent) is putting in place.

I think you are generally falling into a trap of being scared of a
technology you don't understand, and yet insufficiently concerned about
technologies you think you do (the way email is handled).
--
Roland Perry
Dave Howe
2008-03-09 22:47:53 UTC
Permalink
Ian Batten wrote:
> So I think the underlying Phorm gig is a more complex doubelclick
> proposition: website owners sell their advertisers place holders, and
> those placeholders are filled by Phorm.

But if they have the willing cooperation of the site owners, why bother
with interception at all? If it were like broadcast TV (where you can
select advertisements regionally because you know your customers are
located within reception range of the transmitter) I can understand
wanting to place them on a per-ISP basis, but you aren't really going to
know your user's location more accurately than you could by having a
list of what IP ranges are assigned to what ISPs, and that can as easily
be obtained free.

It would be possible by such a interception process to replace selected
adverts by (say) doubleclick with targeted content though - or more
probably, add an intermezzo screen showing a timed ad targeted on the
page content, before displaying the (unaltered) page (so visit a car
dealership, get a nice ad for some car that may or may not be sold there
for 30 seconds before you see the page). With a little work, the user
may never know he didn't see an annoying ad provided by the site itself,
rather than a third party.

> Alternatively, website owners sell the placeholders direct to Phorm,
> and Phorm then sell the space to advertisers, but I don't think that
> can be the case: it wouldn't provide a path to insert adverts for
> non-Phorm users.

Indeed so. unless their placeholder was *itself* an advert, to provide a
fallback/default for the non-instream users.
Ian Batten
2008-03-10 09:10:47 UTC
Permalink
On 9 Mar 2008, at 22:47, Dave Howe wrote:

> Ian Batten wrote:
>> So I think the underlying Phorm gig is a more complex doubelclick
>> proposition: website owners sell their advertisers place holders, and
>> those placeholders are filled by Phorm.
>
> But if they have the willing cooperation of the site owners, why
> bother
> with interception at all?


They are selling to the site owners the profile of all the sites you
visit, not just the sites that are also customers.

ian
Dave Howe
2008-03-09 22:27:42 UTC
Permalink
Roland Perry wrote:
> I think this misses the point I was trying to make. That the end user
> knows there is a cache (let's assume that for now) and therefore asks
> the cache to be an intermediary. Interception can therefore only take
> place between the user and the cache, or between the cache and the website.

I have had an ISP tell me explicitly that there is no cache, when I can
see from the error messages I get that a transparent cache is in place....
Dave Howe
2008-03-09 23:00:19 UTC
Permalink
Paul Vigay wrote:
> In a dim and distant universe <47D4645E.6050004-puGfsi27rH1aa/***@public.gmane.org>, Dave Howe
> <DaveHowe-puGfsi27rH1aa/***@public.gmane.org> enlightened us thusly:
>> I have had an ISP tell me explicitly that there is no cache, when I
>> can see from the error messages I get that a transparent cache is
>> in place....
>
> Of course it might not be the ISP though. I've noticed that some
> browsers operate a transparent proxy, unknown to the ISP. For
> instance Opera Mini 4 on mobile phones proxies through opera-mini.net
> irrespective of ISP. I discovered this myself when I found that they
> were censoring^H^Hblocking some sites.
>

nah. on that occasion, I was using ethereal to try and find out why I
was getting weird errors from certain dynamic pages. I knew fine well
the packets were labelled up with the right IP when they left our
firewall's external hub for the ISPs router. And I could see pages
arrive back without the query ever making it to the webserver...

Problem was partially with the target server (not marking up the pages
for no-cache despite the fact they were dynamically served) but mostly I
was annoyed that I couldn't get the ISP to clear down its cached pages
as it wouldn't admit there *was* a cache...
Roland Perry
2008-03-10 07:26:28 UTC
Permalink
In article <47D4645E.6050004-puGfsi27rH1aa/***@public.gmane.org>, Dave Howe <DaveHowe-puGfsi27rH1aa/***@public.gmane.org>
writes
>> I think this misses the point I was trying to make. That the end user
>>knows there is a cache (let's assume that for now) and therefore asks
>>the cache to be an intermediary. Interception can therefore only take
>>place between the user and the cache, or between the cache and the
>>website.
>
>I have had an ISP tell me explicitly that there is no cache, when I can
>see from the error messages I get that a transparent cache is in
>place....

But the ISPs deploying the Phorm platform are not denying it exists.
They need to confirm it exists as part of the process of having users
opt in (decide not to opt out, or whatever).
--
Roland Perry
Dave Howe
2008-03-10 08:20:36 UTC
Permalink
Roland Perry wrote:
> In article <47D4645E.6050004-puGfsi27rH1aa/***@public.gmane.org>, Dave Howe <DaveHowe-puGfsi27rH1aa/***@public.gmane.org>
> writes
>> I have had an ISP tell me explicitly that there is no cache, when I
>> can see from the error messages I get that a transparent cache is in
>> place....
>
> But the ISPs deploying the Phorm platform are not denying it exists.
> They need to confirm it exists as part of the process of having users
> opt in (decide not to opt out, or whatever).

True but it means that the argument "they must know they are going
though a proxy" is false; they may not be explicitly defining a proxy in
their browsers, and further, the ISP may be denying they use a proxy at
all....
Roland Perry
2008-03-10 08:48:07 UTC
Permalink
In article <47D4EF54.7030502-puGfsi27rH1aa/***@public.gmane.org>, Dave Howe <DaveHowe-puGfsi27rH1aa/***@public.gmane.org>
writes
>>> I have had an ISP tell me explicitly that there is no cache, when I
>>>can see from the error messages I get that a transparent cache is in
>>>place....
>> But the ISPs deploying the Phorm platform are not denying it exists.
>>They need to confirm it exists as part of the process of having users
>>opt in (decide not to opt out, or whatever).
>
>True but it means that the argument "they must know they are going
>though a proxy" is false; they may not be explicitly defining a proxy
>in their browsers, and further, the ISP may be denying they use a proxy
>at all....

The Phorm platform is the proxy (small p). No Proxy (big P) needs to be
set up by the user, nor is anyone denying that the Phorm platform is in
place.

--
Roland Perry
Dave Howe
2008-03-10 10:03:29 UTC
Permalink
Roland Perry wrote:
> In article <47D4EF54.7030502-puGfsi27rH1aa/***@public.gmane.org>, Dave Howe
> <DaveHowe-puGfsi27rH1aa/***@public.gmane.org> writes
>>>> I have had an ISP tell me explicitly that there is no cache,
>>>> when I can see from the error messages I get that a transparent
>>>> cache is in place....
>>> But the ISPs deploying the Phorm platform are not denying it
>>> exists. They need to confirm it exists as part of the process of
>>> having users opt in (decide not to opt out, or whatever).
>>
>> True but it means that the argument "they must know they are going
>> though a proxy" is false; they may not be explicitly defining a
>> proxy in their browsers, and further, the ISP may be denying they
>> use a proxy at all....
>
> The Phorm platform is the proxy (small p). No Proxy (big P) needs to
> be set up by the user, nor is anyone denying that the Phorm platform
> is in place.

Nobody is calling it a proxy though, or apparently telling anyone (or
until recently, admitting it was happening.

Relying on "they must know they are going though a proxy" first
implies that the users have been informed (first I heard about this was
here; my ISP may of course not be indulging in this scramble for an
alternative revenue stream, but I am sure nobody has told me about it)

I *do* know customers of BT and TalkTalk though, and their general
reaction has been "they are DOING WHAT???" when I have broached the
subject. Any publicity has therefore been of the "beware of the leopard"
variety.

Second, when I did a little digging online, I found a register article
- http://www.theregister.co.uk/2008/02/27/bt_phorm_121media_summer_2007/

I am assuming it is accurate of course, (I imagine BT would have sued
if it wasn't :) but it states that BT had been doing this since mid-2007
and denying it to customers. That doesn't exactly square with the idea
that this is all open and above board.

Thirdly, I did a bit more searching and found entries like this:

http://uk.techcrunch.com/2008/02/29/phorm-might-be-onto-something/

which again (probably because it is not for a technical audience) uses
words like "deep packet inspection boxes" while avoiding terms like
proxy or interception. Although the article is careful to point out that
phorm avoid (for example) banks, it has no info on how to get your site
opted out of data collection, it asserts that the "cookie" is doing the
work, and repeats the assertion that PI have approved the privacy claims.

From that, even as a technical (but not networking expert) reader, I
would make the assumption that blocking this magical, work-doing cookie
(while not identifying which cookie I need to block of course) was
enough to opt out of the scheme - while there is no way to know if this
is true, or if it will *continue* to be true if it starts to impact
their revenue stream too much. I would also assume it was this magical
cookie was responsible for the browser lookups mentioned in the ElReg
article, which all ties together nicely...

So again, I am far from seeing the whole "users *know* they are going
though a proxy" opt-in here.
Roland Perry
2008-03-10 12:27:36 UTC
Permalink
In article <47D50771.50902-puGfsi27rH1aa/***@public.gmane.org>, Dave Howe <DaveHowe-puGfsi27rH1aa/***@public.gmane.org>
writes

>> The Phorm platform is the proxy (small p). No Proxy (big P) needs to
>>be set up by the user, nor is anyone denying that the Phorm platform
>>is in place.
>
> Nobody is calling it a proxy though,

I'm not sure why you are clinging to the word "proxy", it has no special
status. The concept is that of an intermediary.

>or apparently telling anyone (or until recently, admitting it was
>happening.

It seems unlikely that the service has been launched yet. Every such
service has a date at which it starts to be talked about.

> Relying on "they must know they are going though a proxy" first
>implies that the users have been informed (first I heard about this was
>here; my ISP may of course not be indulging in this scramble for an
>alternative revenue stream, but I am sure nobody has told me about it)

Again, timing. This is all stuff that will happen in the future.

> I *do* know customers of BT and TalkTalk though, and their general
>reaction has been "they are DOING WHAT???"

GOING TO BE doing ...

> when I have broached the subject. Any publicity has therefore been of
>the "beware of the leopard" variety.

Timing. Although I agree that the lack of clarity about what the system
will actually be doing doesn't help put people's minds at rest (or
otherwise).

> Second, when I did a little digging online, I found a register article
>- http://www.theregister.co.uk/2008/02/27/bt_phorm_121media_summer_2007/
>
> I am assuming it is accurate of course, (I imagine BT would have sued
>if it wasn't :) but it states that BT had been doing this since mid-2007
>and denying it to customers. That doesn't exactly square with the idea
>that this is all open and above board.

An undisclosed pilot is worrying, if true. This part of the story
doesn't quite add up yet, especially if the permission of the subscriber
is the thing which makes it legal.

> Thirdly, I did a bit more searching and found entries like this:
>
>http://uk.techcrunch.com/2008/02/29/phorm-might-be-onto-something/
>
> which again (probably because it is not for a technical audience) uses
>words like "deep packet inspection boxes" while avoiding terms like
>proxy or interception. Although the article is careful to point out that
>phorm avoid (for example) banks, it has no info on how to get your site
>opted out of data collection, it asserts that the "cookie" is doing the
>work, and repeats the assertion that PI have approved the privacy claims.

That article is recycling lots of other speculation/marketing_bumf.
Doesn't mean it's not true, but isn't itself "further proof".

> From that, even as a technical (but not networking expert) reader, I
>would make the assumption that blocking this magical, work-doing cookie
>(while not identifying which cookie I need to block of course) was
>enough to opt out of the scheme - while there is no way to know if this
>is true, or if it will *continue* to be true if it starts to impact
>their revenue stream too much. I would also assume it was this magical
>cookie was responsible for the browser lookups mentioned in the ElReg
>article, which all ties together nicely...

Opt-out mechanisms have been discussed in other subthreads. They do, of
course, assume that Phorm is telling the truth about their efficacy, but
that's not an especially greater leap of faith than believing that ISPs
in general have been keeping their web cache logs secret.

> So again, I am far from seeing the whole "users *know* they are going
>though a proxy" opt-in here.

I don't think they've been asked yet. Even if there have been some
pilots, and even if several ISPs are "signed up", are you really sure
that this system is now widely active.

Perhaps you (or someone else with BT Broadband) could look for these
cookies and/or dns tricks as described in the Reg, to see if it's
actually deployed yet. BT say the following:

"We will be trialling BT Webwise in mid March to about 10,000
customers who will be invited to participate in the trial via a
special web page that will appear when those customers start a
web browsing session."

If any of those 10,000 are in the house could they please put their hand
up?
--
Roland Perry
Dave Howe
2008-03-10 14:08:11 UTC
Permalink
Roland Perry wrote:
> In article <47D50771.50902-puGfsi27rH1aa/***@public.gmane.org>, Dave Howe <DaveHowe-puGfsi27rH1aa/***@public.gmane.org>
> writes
>> Nobody is calling it a proxy though,
>
> I'm not sure why you are clinging to the word "proxy", it has no
> special status. The concept is that of an intermediary.

I didn't introduce the concept of a "user-expected proxy" into this
conversation, you did (as a reason why a user of the service might
reasonably expect some intermediate host to be making queries on his/her
behalf).

My point is that the user has no expectation that anything but routing
happens to his packets until they hit the webserver; even "packet
inspection" seems to suggest sniffing rather than proxying. If we can
agree that the user has no expectation of interception unless he is (at
some future point, of course) notified of the scheme and presumably how
to opt out, we can drop it :)

>> or apparently telling anyone (or until recently, admitting it was
>> happening.
> It seems unlikely that the service has been launched yet. Every such
> service has a date at which it starts to be talked about.

See below regarding BT's trial of the technology. I note that the
later interview (
http://www.theregister.co.uk/2008/03/07/phorm_interview_burgess_ertegrul/print.html
) leaves phorm smelling of roses and doing the "right thing" - customer
information and site content never leaves the interception box at the
ISP at all, instead, the interception box requests an advert of the
correct type when it sees a "tagged" host site for the advert.

Presumably the "think of the children" excuse - that someone might
fail to clear down the cookie and get pr0n ads when someone else is
using the machine - is addressed there as well, given they claim
objectionable ads (adult, tobacco, gambling, medical) are not to be served.

> Again, timing. This is all stuff that will happen in the future.

Again, see below

> GOING TO BE doing ...

ditto...

> Timing. Although I agree that the lack of clarity about what the
> system will actually be doing doesn't help put people's minds at rest
> (or otherwise).

and ditto...

>
>> Second, when I did a little digging online, I found a register
>> article -
>> http://www.theregister.co.uk/2008/02/27/bt_phorm_121media_summer_2007/
>>
>>
>>
>> I am assuming it is accurate of course, (I imagine BT would have
>> sued if it wasn't :) but it states that BT had been doing this
>> since mid-2007 and denying it to customers. That doesn't exactly
>> square with the idea that this is all open and above board.
>
> An undisclosed pilot is worrying, if true. This part of the story
> doesn't quite add up yet, especially if the permission of the
> subscriber is the thing which makes it legal.

Which is where it gets interesting. The above interview lays the blame
squarely on BT:

| We've been working with BT for quite some time. The announcement
| wasn't the product of a couple of weeks' discussions.
|
| The BT engineers evaluated our system, but I can't comment on the
| exact nature of any evaluation that they did.
|
| I understand that BT has said it's looking into exactly what happened
| when people were seeing sysip.net and I think that what you're going
| to find is that it will respond shortly but we have to defer to them.

Note if this IS interception, you would also need the permission of
the site holder. I don't think RIPa allows single-sided assignment of
permission just because its convenient for marketing purposes, and this
device is deliberately harvesting data from sites not members of their
marketing scheme to target ads on the member sites.

This may however not be interception (as non-member site data is not
"made available" to the machine owner or even ISP) which may be the
loophole pharm are expecting to escape prosecution under (I am fine with
the concept of people not being arrested for things that aren't
offences, even if they are offensive to me :).

Member sites are modified, but then, this is happening anyway if you
host a doubleclick banner, so there is nothing majorly new there either
(except where the modification happens, which is at the ISP rather than
at the browser directly)

>> Thirdly, I did a bit more searching and found entries like this:
>>
>> http://uk.techcrunch.com/2008/02/29/phorm-might-be-onto-something/
>
> That article is recycling lots of other speculation/marketing_bumf.
> Doesn't mean it's not true, but isn't itself "further proof".

Indeed so. however, that's the only sort of information out there - a
reasonably tech savvy internet user, worried about pharm, is likely to
find it and articles like it. and this new interview of course :)

> Opt-out mechanisms have been discussed in other subthreads. They do,
> of course, assume that Phorm is telling the truth about their
> efficacy, but that's not an especially greater leap of faith than
> believing that ISPs in general have been keeping their web cache logs
> secret.

Sure. however, everyone involved has been pretty cagey about how you
opt out; I wouldn't be entirely surprised if there is more information
(mixed in with our wild speculation of course) on this list than was
known across the internet in total.. The point is, until the technology
is finalized and rolled out, nobody knows exactly how it will work or
what impact it will have, nor do we know what mechanisms will be valid
and which won't be.

However (from the interview) it looks like they are going out of their
way to make opt out easier and the process transparent (while pushing
back at the ISPs the poor media handling so far)

They plan (for example) to devote a portion of the served ads to
notifications of webwise being "on" or "off" - presumably clicking such
would take you to a control/info page to allow you to opt in and out of
the scheme. I am surprised by just how clean pharm's hands look in that
interview (considering an ElReg interviewer is likely to be at least
semi-hostile based on their current coverage)

> I don't think they've been asked yet. Even if there have been some
> pilots, and even if several ISPs are "signed up", are you really sure
> that this system is now widely active.

No. however, surely the time to alert people to how to opt out (if you
are in a legal regime where *opt in* is required to avoid criminal
charges) is *before* you turn on the system, even in pilot? That
presumes this is of course in any way illegal...

> Perhaps you (or someone else with BT Broadband) could look for these
> cookies and/or dns tricks as described in the Reg, to see if it's
> actually deployed yet. BT say the following:

I don't have BT broadband, so unless they (as wholesale providers to
my ISP "Demon" - or "Thus" or whatever they want to call themselves this
week :) are also planning something even naughtier, I doubt I will be on
their trial or even the final rollout.

I also assume that if they are planning a public trial (and even if
they weren't, given someone noticed the dns traffic) their pilot box
will be disconnected by now - there is little point in running two
boxes, and the first step in claiming nothing ever happened is to make
sure it isn't happening now.

Its also of course possible that this was meant to be a limited-member
trial restricted to two or three test nodes (operated by BT staff), and
accidentally got too wide a mask applied. It wouldn't be the first time
something like that happened, or indeed that I messed up and did
something like that myself. :)

Another possibility is that the substitution technology was supposed to
be disabled while they ran a load test (ran 10,000 users traffic though
it to see if it caused any delays or overloaded the interception
hardware) and the off switch was broken...

There is no shortage of possible failure modes that could lead to a
limited trial suddenly becoming a public one, and malicious intent is
usually a less likely explanation than implementation stupidity :)

> "We will be trialling BT Webwise in mid March to about 10,000
> customers who will be invited to participate in the trial via a
> special web page that will appear when those customers start a web
> browsing session."
>
> If any of those 10,000 are in the house could they please put their
> hand up?
Roland Perry
2008-03-10 17:07:53 UTC
Permalink
In article <47D540CB.3000505-puGfsi27rH1aa/***@public.gmane.org>, Dave Howe <DaveHowe-puGfsi27rH1aa/***@public.gmane.org>
writes

>>> Nobody is calling it a proxy though,
>> I'm not sure why you are clinging to the word "proxy", it has no
>>special status. The concept is that of an intermediary.
>
> I didn't introduce the concept of a "user-expected proxy" into this
>conversation, you did (as a reason why a user of the service might
>reasonably expect some intermediate host to be making queries on his/her
>behalf).

I was using a cache (not a proxy) as an *example* of an intermediary
that users might be comfortable with today. An intermediary that
modifies the interaction between the user and the website.

> My point is that the user has no expectation that anything but routing
>happens to his packets until they hit the webserver; even "packet
>inspection" seems to suggest sniffing rather than proxying.

In what context? A reasonably well informed user will know what a cache
does. ISPs will be telling users what Phorm does (once it goes properly
live).

>> It seems unlikely that the service has been launched yet. Every such
>> service has a date at which it starts to be talked about.
>
> See below regarding BT's trial of the technology. I note that the
>later interview (
>http://www.theregister.co.uk/2008/03/07/phorm_interview_burgess_ertegrul
>/print.html
>) leaves phorm smelling of roses and doing the "right thing" - customer
>information and site content never leaves the interception box at the
>ISP at all,

Which is in line with one of my earlier predictions that the "Phorm box"
is operated by the ISP under their normal exemptions. So in the legal
sense maybe no more of an interception than a cache.

>instead, the interception box requests an advert of the
>correct type when it sees a "tagged" host site for the advert.
>
> Presumably the "think of the children" excuse - that someone might
>fail to clear down the cookie and get pr0n ads when someone else is
>using the machine

What they haven't discussed is how long the profiles persist in the
normal course of events. What if I do lots of browsing for cars. How
many days/months after I've bought one as a result, will I still be
seeing adverts for cars.

And as I've written before, different users sharing exactly the same
browser (and not even using the Windows "user" feature) will have many
other side effects as well. This is just one more for the list.

> - is addressed there as well, given they claim objectionable ads
>(adult, tobacco, gambling, medical) are not to be served.

It's always a bit dangerous to impose one person's moral values on a
whole bunch of others. Some of those adverts have statutory bans in any
event (eg tobacco) but what about advertising to children - there are
specific codes of practice here. Will they assume all users are
children, or that none are? eg: Advertising soft drinks & high fat /
sugar foods to children (which is in the ASA's code)

>| I understand that BT has said it's looking into exactly what happened
>| when people were seeing sysip.net and I think that what you're going
>| to find is that it will respond shortly but we have to defer to them.

I saw that too. We will have to wait and see what they say. In the short
term I'm going to give them the benefit of the doubt because the fallout
if it turns out they were acting illegally is likely to be substantial.

> Note if this IS interception, you would also need the permission of
>the site holder.

No, that's what I being saying about the Phorm platform as intermediary.
My theory is that the intended recipient of the website's output is the
thing that asked the website for the page: the Phorm platform.

Of course, I could be wrong, but please say why, rather than continuing
to ignore this as a proposition.

> This may however not be interception (as non-member site data is not
>"made available" to the machine owner or even ISP) which may be the
>loophole pharm are expecting to escape prosecution under (I am fine with
>the concept of people not being arrested for things that aren't
>offences, even if they are offensive to me :).

This is another key issue. Are the ISP exempt anyway because it's part
of the way they deliver the service (of shipping port 80 packets
around), or might they be exempt because there's no relevant "making
available" to a relevant "person".

>> Opt-out mechanisms have been discussed in other subthreads. They do,
>>of course, assume that Phorm is telling the truth about their
>>efficacy, but that's not an especially greater leap of faith than
>>believing that ISPs in general have been keeping their web cache logs
>> secret.
>
> Sure. however, everyone involved has been pretty cagey about how you
>opt out;

I've gone to the FAQ webpage Richard Clayton mentioned, and thence to
the opt-out page. Even though I'm not a BT broadband customer it did
place an "opt-out" cookie on my system.

> There is no shortage of possible failure modes that could lead to a
>limited trial suddenly becoming a public one, and malicious intent is
>usually a less likely explanation than implementation stupidity :)

Hence why I'm in "benefit of the doubt" mode at the moment.
--
Roland Perry
Peter Tomlinson
2008-03-10 17:42:31 UTC
Permalink
Roland Perry wrote:
> What they haven't discussed is how long the profiles persist in the
> normal course of events. What if I do lots of browsing for cars. How
> many days/months after I've bought one as a result, will I still be
> seeing adverts for cars.
For ever, because the data will be sold on - your permanently allocated
but randomly chosen number will be a pointer to your IP address. I had
an email last week from a firm of accountants soliciting for my business
in Wales (this will I think be because up to 8 years ago I used an
accountant whose office was in Wales, even though my business was in
England). I asked them why, and they admitted that they buy lists of
email addresses off the internet. While I think that selling lists of
business email addresses is probably legit, who is to say whether an
email address or an IP address is used for business or personally?

Peter
Ian Batten
2008-03-10 17:57:50 UTC
Permalink
On 10 Mar 08, at 1742, Peter Tomlinson wrote:
> ago I used an accountant whose office was in Wales, even though my
> business was in England). I asked them why, and they admitted that
> they buy lists of email addresses off the internet.

Our former parent company kindly maintain an MX record for our former
name.

We used that domain name from 1988 to 1993. It had, at peak, about
twenty externally visible users.

We get several hundred items of spam per day to it, which we feed
straight into the Bayesian classifier. As few spammers have archives
of mail dating back to the early Major years, I assume they're buying
bogus lists.

I see some assure us that we'd opted in on a webpage. The domain in
question largely predates the concept of `webpage' and when it was in
use the mail was delivered using either UUCP or X.400(88): I don't
recall ever using that domain with SMTP.

I've sold the domain we used from 1993 to 1995 --- for 25K! --- so I
don't know how much spam that's getting. Historically we got less on
that, I think.

ian
Roland Perry
2008-03-10 19:26:19 UTC
Permalink
In article <2423203F-1DB7-4475-AA7D-D63F697939C2-BFib/+***@public.gmane.org>, Ian
Batten <igb-BFib/+***@public.gmane.org> writes
>We used that domain name from 1988 to 1993. It had, at peak, about
>twenty externally visible users.
>
>We get several hundred items of spam per day to it

I get spam to an address that I used once in a usenet posting, about 10
years ago. Pretty sure it's not as a result of a dictionary attack,
either. Once these things get into the spammer's systems, they keep
getting recycled.
--
Roland Perry
James Davis
2008-03-11 10:10:44 UTC
Permalink
Ian Batten wrote:

> We get several hundred items of spam per day to it, which we feed
> straight into the Bayesian classifier. As few spammers have archives of
> mail dating back to the early Major years, I assume they're buying bogus
> lists.

The spammers, and by that I mean the people sending the spam on behalf
of the advertisers, will probably only care about the numbers they can
tell the advertiser and not the accuracy.

I recently investigated a compromised system which was being used by a
spammer. From the quality of their scripts I suspect it wasn't the most
sophisticated operating. They left behind a database of approximately
250,000 addresses. A quick sampling with a perl script showed that 50%
of the e-mail addresses were for domains with no MX records and 45% of
the addresses were for domains that lack NS records. I spotted one
address directed at a system that's been turned off for at least five years.

I'm sure there must be spammers using more accurate lists than this, but
I hope this gives some idea of the quality at the lower end :-)

James

--
James Davis +44 1235 822 229 PGP: 0x890F159E
JANET CSIRT 0870 850 2340 (+44 1235 822 340)
Lumen House, Library Avenue, Didcot, Oxfordshire, OX11 0SG
PeteM
2008-03-11 10:53:59 UTC
Permalink
James Davis wrote on 11-03-08 10:10:
> I recently investigated a compromised system which was being used by a
> spammer. From the quality of their scripts I suspect it wasn't the most
> sophisticated operating. They left behind a database of approximately
> 250,000 addresses. A quick sampling with a perl script showed that 50%
> of the e-mail addresses were for domains with no MX records and 45% of
> the addresses were for domains that lack NS records. I spotted one
> address directed at a system that's been turned off for at least five
> years.
>
> I'm sure there must be spammers using more accurate lists than this, but
> I hope this gives some idea of the quality at the lower end :-)
>

IME that level of inaccuracy is (or was) quite normal for *physical*
mass-mailing lists used for sales mailshots and controlled circulation
magazines. It's simply a function of the rate at which people change
address/job and the practical impossibility of cleaning the lists. Since
obsolete records are so hard to detect, they accumulate over the years
until they come to dominate the content of the largest and most
expensive lists. Like DDT in top predators.

--
Pete Mitchell
Chris Edwards
2008-03-11 11:02:06 UTC
Permalink
On Tue, 11 Mar 2008, PeteM wrote:

| James Davis wrote on 11-03-08 10:10:
| >
| > I'm sure there must be spammers using more accurate lists than this, but I
| > hope this gives some idea of the quality at the lower end :-)
|
| IME that level of inaccuracy is (or was) quite normal for *physical*
| mass-mailing lists used for sales mailshots and controlled circulation
| magazines. It's simply a function of the rate at which people change
| address/job and the practical impossibility of cleaning the lists. Since
| obsolete records are so hard to detect, they accumulate over the years

In this case, the spammer could have trivially run a script like James did
to weed out the ones with no NS/MX records.

(well, assuming he can make the large numbers of DNS requests required...)
Roland Perry
2008-03-10 19:23:18 UTC
Permalink
In article <47D57307.80706-BPqP8yNAJjH10XsdtD+***@public.gmane.org>, Peter Tomlinson
<pwt-BPqP8yNAJjH10XsdtD+***@public.gmane.org> writes
>Roland Perry wrote:
>> What they haven't discussed is how long the profiles persist in the
>>normal course of events. What if I do lots of browsing for cars. How
>>many days/months after I've bought one as a result, will I still be
>>seeing adverts for cars.
>For ever, because the data will be sold on - your permanently allocated
>but randomly chosen number will be a pointer to your IP address.

You'll have to explain that.

1) What if I have a dynamic IP address, or my ISP has deployed NAT (like
my mobile Internet supplier has). Even people with fairly constant IP
addresses (like cable modems) get a fresh one from time to time.

2) Why wouldn't there be some expiry date within the profile, to avoid
averts becoming stale because my interests have changed?

>I had an email last week from a firm of accountants soliciting for my
>business in Wales (this will I think be because up to 8 years ago I
>used an accountant whose office was in Wales, even though my business
>was in England). I asked them why, and they admitted that they buy
>lists of email addresses off the internet. While I think that selling
>lists of business email addresses is probably legit, who is to say
>whether an email address or an IP address is used for business or personally?

That's a whole other situation that several of us have been grappling
with for years. It's very likely most of those email addresses are being
used illegally, but it's hard to find people to police it.

--
Roland Perry
Dave Howe
2008-03-10 20:18:03 UTC
Permalink
Roland Perry wrote:
> In article <47D540CB.3000505-puGfsi27rH1aa/***@public.gmane.org>, Dave Howe
> <DaveHowe-puGfsi27rH1aa/***@public.gmane.org> writes

>> I didn't introduce the concept of a "user-expected proxy" into this
>> conversation, you did (as a reason why a user of the service might
>> reasonably expect some intermediate host to be making queries on
>> his/her behalf).

> I was using a cache (not a proxy) as an *example* of an intermediary
> that users might be comfortable with today. An intermediary that
> modifies the interaction between the user and the website.

Perhaps you meant it that way - but you didn't mention it was "just an
example" nor did you give any other examples of intermediaries that a
reasonable user might expect to be acting on their behalf. Nor can I
think of any other intermediary that might be reasonably expected to be
under the control of the isp and affect http traffic.

and as to a cache/proxy distinction - at what point is a cache server
NOT a proxy?

>> My point is that the user has no expectation that anything but
>> routing happens to his packets until they hit the webserver; even
>> "packet inspection" seems to suggest sniffing rather than proxying.

> In what context? A reasonably well informed user will know what a
> cache does. ISPs will be telling users what Phorm does (once it goes
> properly live).

I am a reasonably well informed user - and I expect my ISP NOT to run
an active transparent proxy on my traffic without informing me. There is
no trace of such a device on my traffic that I have been able to detect
(and yes, I have looked :)

At the other end of the scale, my neighbour can just about manage the
concept behind "my computer goes out onto the internet and fetches
things". a NAT router (such as was supplied for her by her isp recently)
confused her. The concepts behind a caching proxy, what it does, and why
someone would do it to her computer when it "goes out onto the internet"
is not something that was ever broached to her.

So she and I share the same reasonable expectation - that nobody else
is deliberately messing with our traffic. There could well be a
intermediate band of users (techno-savvy enough to have heard of a
transparent web proxy and understand its operation) but I doubt most of
them would automatically believe their ISP was doing so (although most
would probably not be surprised to be told that it was)

So we have two extremes of user who aren't expecting a proxy, and a
intermediate band that wouldn't be too confused by being told that there
was one. This is a lot of people who really can't be characterized as
having given informed consent to anything (and of course RIPa exception
outside of legal warrant or for the provision of the service is strictly
opt IN)

> Which is in line with one of my earlier predictions that the "Phorm
> box" is operated by the ISP under their normal exemptions. So in the
> legal sense maybe no more of an interception than a cache.

Difficult to tell. Is it a legal interception in the course of normal
operations? That would require you to define normal operations as
examining your customer's traffic and modifying it for your own profit
(not your customers). Although obviously a web proxy would come under
that heading too (its not like ISPs do that because it costs them more
money, and I understand most stopped it once it started costing them
more money to do than they were saving in bandwidth charges)

> What they haven't discussed is how long the profiles persist in the
> normal course of events. What if I do lots of browsing for cars. How
> many days/months after I've bought one as a result, will I still be
> seeing adverts for cars.

I expect so. of course, they could embed individual expiry dates for
channels into the cookie, but I suspect what will really happen is that
each channel will be given a "rating" which is how often it is coming up
in your web traffic. by decrementing the totals every day, then adding
to them each time you see new instances of "qualifying" traffic, you
would see the probability of a car ad decline steadily once you stop
looking at car sites.

This is another of those things that will require us to look at an
actual instance of a running service - until then, its just speculation.

> And as I've written before, different users sharing exactly the same
> browser (and not even using the Windows "user" feature) will have
> many other side effects as well. This is just one more for the list.

Sure. however, that will actually cause a strange profile that is less
accurately targeted to any individual (a "user" who spends half of "his"
time on the cbeebies site, a quarter on ebay, then the rest on teen chat
sites, is probably a family with a young child and a teenager. And is
going to see a strange combination of offers :)

but I would say for the less tech savvy, a single user session (with IE)
is the norm. most families I know have a single internet connected pc,
which has a single login that is autoauthed by the boot process.

>> - is addressed there as well, given they claim objectionable ads
>> (adult, tobacco, gambling, medical) are not to be served.

> It's always a bit dangerous to impose one person's moral values on a
> whole bunch of others. Some of those adverts have statutory bans in
> any event (eg tobacco) but what about advertising to children - there
> are specific codes of practice here. Will they assume all users are
> children, or that none are? eg: Advertising soft drinks & high fat /
> sugar foods to children (which is in the ASA's code)

That's actually a more important question, and one that would be
extremely difficult to code in. Of course, it could be that said foods
(and alcohol) are also on the list. I can't recall ever seeing an ad
online for sugary foods or drinks, and rarely for alcohol.

> No, that's what I being saying about the Phorm platform as
> intermediary. My theory is that the intended recipient of the
> website's output is the thing that asked the website for the page:
> the Phorm platform.

Unfortunately, if it *is* illegal to do that after opt-out, they are in
trouble, as they are still intercepting that data (even if they choose
not to look at it)

> Of course, I could be wrong, but please say why, rather than
> continuing to ignore this as a proposition.

This would be because I, as a user, would not expect any intermediary to
be making queries on my behalf, and would firmly assert my unwillingness
for phorm (or anyone) to do so. That being true, by the time they have
intercepted my traffic and held a conversation *with my browser* to
obtain my opt out cookie, the damage has been done. They have already,
and explicitly against my permission, intercepted my http get request
(or whatever).

>> This may however not be interception (as non-member site data is
>> not "made available" to the machine owner or even ISP) which may be
>> the loophole pharm are expecting to escape prosecution under (I am
>> fine with the concept of people not being arrested for things that
>> aren't offences, even if they are offensive to me :).

> This is another key issue. Are the ISP exempt anyway because it's
> part of the way they deliver the service (of shipping port 80 packets
> around), or might they be exempt because there's no relevant "making
> available" to a relevant "person".

I would suspect the latter. It would be massively difficult to describe
data mining and substitution based on content as being part of the
normal operation of a packet-shifting service, and also as being
compatible with the "mere conduit" defences many seem to raise when the
Four Horsemen are waved in parliament by publicity see... I mean
concerned individuals.

However, that opens the virus-scanning can of worms (again)

>> Sure. however, everyone involved has been pretty cagey about how
>> you opt out;

> I've gone to the FAQ webpage Richard Clayton mentioned, and thence to
> the opt-out page. Even though I'm not a BT broadband customer it did
> place an "opt-out" cookie on my system.

odd. I went to http://webwise.bt.com/webwise/index.html and couldn't
turn it on - it firmly asserted that webwise was off, and the "turn it
on" link did nothing.

I assumed that was because I wasn't a BT user. Maybe I need to relax a
few rules :)

>> There is no shortage of possible failure modes that could lead to a
>> limited trial suddenly becoming a public one, and malicious intent
>> is usually a less likely explanation than implementation stupidity
>> :)

> Hence why I'm in "benefit of the doubt" mode at the moment.

Same here. At least to the extent that I believe BT wouldn't have gone
this far without a lawyer signing off on it :)

It might be interesting to see what happens if you perform a paper-based
opt-out - write a lawyergram to the ISP along the lines of "I do not
authorize and have not authorized the inspection or modification of my
internet traffic for the purposes of targeted advertising and will
consider any such action interception for the purposes of the RIP act
2000" and see what they decide to do to opt you out :)
Roland Perry
2008-03-10 21:45:35 UTC
Permalink
In article <47D5977B.2020601-puGfsi27rH1aa/***@public.gmane.org>, Dave Howe <DaveHowe-puGfsi27rH1aa/***@public.gmane.org>
writes

>>> I didn't introduce the concept of a "user-expected proxy" into this
>>> conversation, you did (as a reason why a user of the service might
>>> reasonably expect some intermediate host to be making queries on
>>> his/her behalf).
>
>> I was using a cache (not a proxy) as an *example* of an intermediary
>> that users might be comfortable with today. An intermediary that
>>modifies the interaction between the user and the website.
>
>Perhaps you meant it that way

I thought it was obvious from the context, but let's move on.

>>> My point is that the user has no expectation that anything but
>>> routing happens to his packets until they hit the webserver; even
>>> "packet inspection" seems to suggest sniffing rather than proxying.
>
>> In what context? A reasonably well informed user will know what a
>> cache does. ISPs will be telling users what Phorm does (once it goes
>> properly live).
>
> I am a reasonably well informed user - and I expect my ISP NOT to run
>an active transparent proxy on my traffic without informing me.

I have not suggested they would!!

> At the other end of the scale, my neighbour

Who is clearly not a "reasonably well informed user".

Those of us who are, must pave the way for the less fortunate, by
spotting any potential hazards (as is the case with Phorm).

> So she and I share the same reasonable expectation - that nobody else
>is deliberately messing with our traffic.

And when one of the ISPs concerned tells you about Phorm, (both of) you
will know there's "someone messing". The questions being: is it legal
and does it matter. Those questions have been discussed at some length.

>> Which is in line with one of my earlier predictions that the "Phorm
>> box" is operated by the ISP under their normal exemptions. So in the
>> legal sense maybe no more of an interception than a cache.
>
> Difficult to tell. Is it a legal interception in the course of normal
>operations? That would require you to define normal operations as
>examining your customer's traffic and modifying it for your own profit
>(not your customers).

Nonsense. The legal definition is nothing like that.

>I suspect what will really happen is that
>each channel will be given a "rating" which is how often it is coming up
>in your web traffic. by decrementing the totals every day, then adding
>to them each time you see new instances of "qualifying" traffic, you
>would see the probability of a car ad decline steadily once you stop
>looking at car sites.

Sounds plausible. And any site advertising to me may wish to only
advertise those things I'm *most* interested in, which could cause quite
a bit of natural churn.

>> And as I've written before, different users sharing exactly the same
>> browser (and not even using the Windows "user" feature) will have
>> many other side effects as well. This is just one more for the list.
>
>Sure. however, that will actually cause a strange profile that is less
>accurately targeted to any individual (a "user" who spends half of "his"
>time on the cbeebies site, a quarter on ebay, then the rest on teen chat
>sites, is probably a family with a young child and a teenager. And is
>going to see a strange combination of offers :)

Or maybe the advertisers' self interest will win over and everyone will
get just adverts relevant for cbeebies (As that's the most prominent
interest).

>but I would say for the less tech savvy, a single user session (with IE)
>is the norm. most families I know have a single internet connected pc,
>which has a single login that is autoauthed by the boot process.

I agree. And as a result I think both Phorm and the users will find that
adverts aren't as tightly targeted as they expect.

>>> - is addressed there as well, given they claim objectionable ads
>>>(adult, tobacco, gambling, medical) are not to be served.
>
>> It's always a bit dangerous to impose one person's moral values on a
>> whole bunch of others. Some of those adverts have statutory bans in
>> any event (eg tobacco) but what about advertising to children - there
>> are specific codes of practice here. Will they assume all users are
>>children, or that none are? eg: Advertising soft drinks & high fat /
>> sugar foods to children (which is in the ASA's code)
>
>That's actually a more important question, and one that would be
>extremely difficult to code in. Of course, it could be that said foods
>(and alcohol) are also on the list. I can't recall ever seeing an ad
>online for sugary foods or drinks, and rarely for alcohol.

I have most adverts blocked anyway, so am relatively unaware of what it
is that gets thrust at "normal" users.

>> No, that's what I being saying about the Phorm platform as
>> intermediary. My theory is that the intended recipient of the
>> website's output is the thing that asked the website for the page:
>> the Phorm platform.
>
>Unfortunately, if it *is* illegal to do that after opt-out, they are in
>trouble, as they are still intercepting that data (even if they choose
>not to look at it)

But they may not be illegally intercepting at all, and "consent" could
be a red herring. In any event, if they "aren't looking at it", whatever
that means in practice, then it's not "being made available" to even
themselves (and that's assuming they are a [sufficiently 3rd party, ie
not the ISP itself] person within the RIPA definitions).

>> Of course, I could be wrong, but please say why, rather than
>> continuing to ignore this as a proposition.
>
>This would be because I, as a user, would not expect any intermediary to
>be making queries on my behalf, and would firmly assert my unwillingness
>for phorm (or anyone) to do so. That being true, by the time they have
>intercepted my traffic and held a conversation *with my browser* to
>obtain my opt out cookie, the damage has been done. They have already,
>and explicitly against my permission, intercepted my http get request
>(or whatever).

You may dislike what they are doing, but I suspect you are also using
the word "intercept" in a rather imprecise non-RIPA way.

By the way, what "damage" is done, if your browsing command is thrown
away as soon as it's been translated into one of their categories?

Or do you consider it interception that they say to themselves "guess
what, Dave seems to be interested in ipods".

>>> This may however not be interception (as non-member site data is
>>> not "made available" to the machine owner or even ISP) which may be
>>> the loophole pharm are expecting to escape prosecution under (I am
>>> fine with the concept of people not being arrested for things that
>>> aren't offences, even if they are offensive to me :).
>
>> This is another key issue. Are the ISP exempt anyway because it's
>> part of the way they deliver the service (of shipping port 80 packets
>> around), or might they be exempt because there's no relevant "making
>> available" to a relevant "person".
>
>I would suspect the latter. It would be massively difficult to describe
>data mining and substitution based on content as being part of the
>normal operation of a packet-shifting service,

It would certainly clear the air if we could establish whether or not
this was their 'defence'.

>and also as being compatible with the "mere conduit" defences many seem
>to raise when the Four Horsemen are waved in parliament by publicity
>see... I mean concerned individuals.

They are still being a mere conduit for the majority of the content. I
wonder if mere conduit status is something like virginity where if you
lose it once, it's gone for ever; or if it's a defence against liability
for specific pieces of data (eg specific web pages). As all the web
pages that are being 'modified' are from customers of theirs, perhaps
the contract says that the customer won't sue them as a result of the
modification.

>However, that opens the virus-scanning can of worms (again)
>
>>> Sure. however, everyone involved has been pretty cagey about how
>>> you opt out;
>
>> I've gone to the FAQ webpage Richard Clayton mentioned, and thence to
>> the opt-out page. Even though I'm not a BT broadband customer it did
>> place an "opt-out" cookie on my system.
>
>odd. I went to http://webwise.bt.com/webwise/index.html and couldn't
>turn it on - it firmly asserted that webwise was off, and the "turn it
>on" link did nothing.
>
>I assumed that was because I wasn't a BT user. Maybe I need to relax a
>few rules :)

I just tried it again, and it won't switch on, or leave me a cookie.
Maybe my earlier experience was one of those mysterious glitches?

>>> There is no shortage of possible failure modes that could lead to a
>>> limited trial suddenly becoming a public one, and malicious intent
>>> is usually a less likely explanation than implementation stupidity
>>> :)
>
>> Hence why I'm in "benefit of the doubt" mode at the moment.
>
>Same here. At least to the extent that I believe BT wouldn't have gone
>this far without a lawyer signing off on it :)
>
>It might be interesting to see what happens if you perform a paper-based
>opt-out - write a lawyergram to the ISP along the lines of "I do not
>authorize and have not authorized the inspection or modification of my
>internet traffic for the purposes of targeted advertising and will
>consider any such action interception for the purposes of the RIP act
>2000" and see what they decide to do to opt you out :)

They might write back and say "we don't [consider it Interception] and
we've told you the webpage to use to opt out".
--
Roland Perry
Richard Clayton
2008-03-10 22:29:27 UTC
Permalink
In article <fc0WQZC$va1HFA9o-QmCu5Paugg/10XsdtD+***@public.gmane.org>, Roland Perry <***@internetpo
licyagency.com> writes

>They are still being a mere conduit for the majority of the content. I
>wonder if mere conduit status is something like virginity where if you
>lose it once, it's gone for ever; or if it's a defence against liability
>for specific pieces of data (eg specific web pages). As all the web
>pages that are being 'modified' are from customers of theirs, perhaps
>the contract says that the customer won't sue them as a result of the
>modification.

It's worthwhile inspecting the technical details that are available!

latest today:

http://www.theregister.co.uk/2008/03/07/phorm_interview_burgess_ertegrul/

There are no modified web pages involved... the targeted ads are
embedded into web pages on sites which have signed up for the Phorm
system (rather as doubleclick banners are embedded into other sites
today). So there's no replacement of existing adverts, or adverts being
added to pages that would not normally have them...

Note that the interception (of traffic to the user) is NOT anything to do
with the ads, but is to establish the nature of the pages that are served
(so that Phorm knows what you are interested in).

What they do is to tokenise the page contents, discard useless words
("and" "or" "the" etc) and then establish the 10 most common words on the
page, and try and match that with words they think are associated with
their advertising categories (cars, travel, etc).

What's unclear from this interview (and continues to give one the feeling
that some things are not entirely cast in stone) is why on other
occasions there's been mention of doing the inspection of visited sites
in an offline manner....

- --
richard Richard Clayton

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. Benjamin Franklin
Dave Howe
2008-03-11 00:24:17 UTC
Permalink
Richard Clayton wrote:
> What's unclear from this interview (and continues to give one the feeling
> that some things are not entirely cast in stone) is why on other
> occasions there's been mention of doing the inspection of visited sites
> in an offline manner....

Yeah. there are a number of comments along the lines of "we tried doing
it *that* way, but currently are doing it *this other* way" that left me
wondering "and if that doesn't work, then what?"
Roland Perry
2008-03-11 06:55:40 UTC
Permalink
In article <ENPiFECHZb1HFAu3-dqO9MOo5Mr+***@public.gmane.org>, Richard Clayton
<richard-dqO9MOo5Mr+***@public.gmane.org> writes
>In article <fc0WQZC$va1HFA9o-QmCu5Paugg/10XsdtD+***@public.gmane.org>, Roland Perry <***@internetpo
>licyagency.com> writes
>
>>They are still being a mere conduit for the majority of the content. I
>>wonder if mere conduit status is something like virginity where if you
>>lose it once, it's gone for ever; or if it's a defence against liability
>>for specific pieces of data (eg specific web pages). As all the web
>>pages that are being 'modified' are from customers of theirs, perhaps
>>the contract says that the customer won't sue them as a result of the
>>modification.
>
>It's worthwhile inspecting the technical details that are available!
>
>latest today:
>
>http://www.theregister.co.uk/2008/03/07/phorm_interview_burgess_ertegrul/
>
>There are no modified web pages involved... the targeted ads are
>embedded into web pages on sites which have signed up for the Phorm
>system (rather as doubleclick banners are embedded into other sites
>today). So there's no replacement of existing adverts, or adverts being
>added to pages that would not normally have them...

I wonder what one of those web pages looks like to a subscriber whose
ISP doesn't use Phorm? It was the possibility of a "placeholder" or
"default" advert being superceded by one delivered by the Phorm platform
that probably gave rise to the notion that the 'original' page was being
modified.

>Note that the interception (of traffic to the user) is NOT anything to do
>with the ads, but is to establish the nature of the pages that are served
>(so that Phorm knows what you are interested in).

Yes, I do agree that the discussion of the interception of the web
traffic back to the user has been a bit of a distraction. I think it
arose originally because some people regard the web server as the
"intended recipient" of the http request, and so its permission might be
required to intercept the http request. Of course, that would be any
website, not just Phorm partners.

>What they do is to tokenise the page contents, discard useless words
>("and" "or" "the" etc) and then establish the 10 most common words on the
>page, and try and match that with words they think are associated with
>their advertising categories (cars, travel, etc).

And also the search terms in your http request, and the page's keywords
(by which I presume they mean its meta-tags). It would be interesting to
know if they prioritise these at all. A search term is probably more
weighty than a page that happens to have extremely repetitive and
promiscuous meta-tag content because they are trying (maybe not
successfully) to wangle their Google ranking.
--
Roland Perry
Richard Clayton
2008-03-11 09:19:06 UTC
Permalink
In article <VVQESAHszi1HFA9l-QmCu5Paugg/10XsdtD+***@public.gmane.org>, Roland Perry <***@internetp
olicyagency.com> writes

>In article <ENPiFECHZb1HFAu3-dqO9MOo5Mr+***@public.gmane.org>, Richard Clayton
><richard-dqO9MOo5Mr+***@public.gmane.org> writes

>>It's worthwhile inspecting the technical details that are available!

I repeat this advice

>>latest today:
>>
>>http://www.theregister.co.uk/2008/03/07/phorm_interview_burgess_ertegrul/
>>
>>There are no modified web pages involved... the targeted ads are
>>embedded into web pages on sites which have signed up for the Phorm
>>system (rather as doubleclick banners are embedded into other sites
>>today). So there's no replacement of existing adverts, or adverts being
>>added to pages that would not normally have them...
>
>I wonder what one of those web pages looks like to a subscriber whose
>ISP doesn't use Phorm?

you will get a "random" advert, rather than one targeted at your
specific profile (Phorm would say interests)

> It was the possibility of a "placeholder" or
>"default" advert being superceded by one delivered by the Phorm platform
>that probably gave rise to the notion that the 'original' page was being
>modified.

there's no need to keep on speculating

>>Note that the interception (of traffic to the user) is NOT anything to do
>>with the ads, but is to establish the nature of the pages that are served
>>(so that Phorm knows what you are interested in).
>
>Yes, I do agree that the discussion of the interception of the web
>traffic back to the user has been a bit of a distraction.

arguably it is a key issue on the RIP front, given that there is
permission (albeit perhaps very informed permission) obtained for the
interception of the traffic going the other way

>I think it
>arose originally because some people regard the web server as the
>"intended recipient" of the http request, and so its permission might be
>required to intercept the http request. Of course, that would be any
>website, not just Phorm partners.
>
>>What they do is to tokenise the page contents, discard useless words
>>("and" "or" "the" etc) and then establish the 10 most common words on the
>>page, and try and match that with words they think are associated with
>>their advertising categories (cars, travel, etc).
>
>And also the search terms in your http request,

they don't do that on the traffic coming back from the website, which is
what I was describing

> and the page's keywords
>(by which I presume they mean its meta-tags).

I presume that they mean the process I outlined in the quoted paragraph

>It would be interesting to
>know if they prioritise these at all.

I doubt they try too hard, most of this is being done at line speed.

One might usefully compare the process employed by Phorm with the
"factors" outlined in RIP s8(3) : generally understood to refer to
GCHQ's scanning of communication channels for the presence of key words

Of course, GCHQ then go on to capture the entire communication...

... whereas Phorm only collects some of the data, the tokenised values.
Nevertheless, I note that the definition of "interception" in s2(2) says
"some or all" of the communication, so in my view (IANAL) this is
clearly interception and one can only appeal to the lack of any "person"
in the process to prevent a criminal offence being committed. In my view
that appeal fails :(

>A search term is probably more
>weighty than a page that happens to have extremely repetitive and
>promiscuous meta-tag content because they are trying (maybe not
>successfully) to wangle their Google ranking.

Sites that try and game Google usually come to a sticky end. You may
wish to note that Privila's sites have disappeared from Google's search

http://www.google.com/search?q=site:www.soccerlove.com

http://www.lightbluetouchpaper.org/2008/03/06/the-two-faces-of-privila/

so in the grand scheme of things, these sites are almost non-existent.

- --
richard Richard Clayton

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. Benjamin Franklin
Roland Perry
2008-03-11 10:22:56 UTC
Permalink
In article <KnsB$wUK6k1HFA8Y-dqO9MOo5Mr+***@public.gmane.org>, Richard Clayton
<richard-dqO9MOo5Mr+***@public.gmane.org> writes

>>>What they do is to tokenise the page contents, discard useless words
>>>("and" "or" "the" etc) and then establish the 10 most common words on the
>>>page, and try and match that with words they think are associated with
>>>their advertising categories (cars, travel, etc).
>>
>>And also the search terms in your http request,
>
>they don't do that on the traffic coming back from the website, which is
>what I was describing

The http request would be something like this, going *out* of course:

<http://search.bbc.co.uk/cgi-bin/search/results.pl?scope=all&edition=d&q=
blue+touchpaper>

>> and the page's keywords
>>(by which I presume they mean its meta-tags).
>
>I presume that they mean the process I outlined in the quoted paragraph
>
>>It would be interesting to
>>know if they prioritise these at all.
>
>I doubt they try too hard, most of this is being done at line speed.

It hardly seems worth collecting the "blue" and "touchpaper" above, and
then not prioritise them, as they will otherwise be swamped by words on
the returning page.

>Sites that try and game Google usually come to a sticky end. You may
>wish to note that Privila's sites have disappeared from Google's search

The sites I had more in mind were those with very large (and/or
repetitive) meta name="keywords" fields. Although if these words are
also given no special priority over the actual content of the page, the
effect will be less pronounced. Or maybe people don't do that any more
either.
--
Roland Perry
Ian Batten
2008-03-11 10:35:30 UTC
Permalink
More puffs here:

http://news.bbc.co.uk/1/hi/technology/7283333.stm

Simon'n'Gus get their own paragraph.

ian
Dave Howe
2008-03-11 00:17:22 UTC
Permalink
Roland Perry wrote:
> In article <47D5977B.2020601-puGfsi27rH1aa/***@public.gmane.org>, Dave Howe
> <DaveHowe-puGfsi27rH1aa/***@public.gmane.org> writes
>> Difficult to tell. Is it a legal interception in the course of
>> normal operations? That would require you to define normal
>> operations as examining your customer's traffic and modifying it
>> for your own profit (not your customers).
>
> Nonsense. The legal definition is nothing like that.

Which is the point, really. it can only be legal for the ISP to do it
if it is (a) by or on behalf of a person who provides a
telecommunications service and (b) it takes place for purposes connected
with the provision or operation of that service. Operating a web cache
to more efficiently deliver pages could reasonably be argued to fall
under (b), I doubt data-mining for targeting purposes would.

> Sounds plausible. And any site advertising to me may wish to only
> advertise those things I'm *most* interested in, which could cause
> quite a bit of natural churn.

I suspect it will be a tradeoff. The priorities would give them the
list of things you are most interested in, in order. Their own
commercial priorities may find that one channel is more profitable (or
has a higher percentage of as yet unshown ads that they cannot therefore
yet bill for) so while the ideal model would say that you would see
mostly what you most query for, then less of each lower priority item
down to items you rarely look at, commercial bias may cause less popular
items (that are still on your list) to be shown more often, in the hope
you will click though on one or more of them and so earn them more money.

Discount coupons from loyalty cards are seldom for the products you
buy, in the quantity you normally buy them - more usually, they are for
bulk packs or more expensive competing brands.

> Or maybe the advertisers' self interest will win over and everyone
> will get just adverts relevant for cbeebies (As that's the most
> prominent interest).

anything is possible. but outside of "whine" factor and except in the
run up to xmas, under 5's don't have much marketing pull, and as
cbeebies is unlikely to sign up for targeted advertising, what is more
likely is that the ebay and chatroom users will see a bunch of
advertising for kids stuff. The ebay user may well be interested in new
ways to keep the kids quiet, but the teens are less likely to be
influenced. Which is why I suspect that, in cases where the traffic
comes from more than one person *and* the person most likely to visit
partner sites such as /the guardian/ is unlikely to perform the bulk of
the web browsing, the targeting will be wildly inaccurate.

> I agree. And as a result I think both Phorm and the users will find
> that adverts aren't as tightly targeted as they expect.

Assuming venture (vulture?) capital, it is possible they don't care - if
they can make a convincing argument, they may be able to clear their
profit and get out before anyone realises its a losing bet.

>>> It's always a bit dangerous to impose one person's moral values
>>> on a whole bunch of others. Some of those adverts have statutory
>>> bans in any event (eg tobacco) but what about advertising to
>>> children - there are specific codes of practice here. Will they
>>> assume all users are children, or that none are? eg: Advertising
>>> soft drinks & high fat / sugar foods to children (which is in
>>> the ASA's code)
>>
>> That's actually a more important question, and one that would be
>> extremely difficult to code in. Of course, it could be that said
>> foods (and alcohol) are also on the list. I can't recall ever
>> seeing an ad online for sugary foods or drinks, and rarely for
>> alcohol.
>
> I have most adverts blocked anyway, so am relatively unaware of what
> it is that gets thrust at "normal" users.

I tend to allow them but tune them out. Pop-ups/unders however annoy
me enough that I usually pull up the page source, find where they were
loaded from, and block the entire domain. If that catches a few banner
images as well, what the hell :)

> But they may not be illegally intercepting at all, and "consent"
> could be a red herring. In any event, if they "aren't looking at it",
> whatever that means in practice, then it's not "being made
> available" to even themselves (and that's assuming they are a
> [sufficiently 3rd party, ie not the ISP itself] person within the
> RIPA definitions).
>
>>> Of course, I could be wrong, but please say why, rather than
>>> continuing to ignore this as a proposition.
>>
>> This would be because I, as a user, would not expect any
>> intermediary to be making queries on my behalf, and would firmly
>> assert my unwillingness for phorm (or anyone) to do so. That being
>> true, by the time they have intercepted my traffic and held a
>> conversation *with my browser* to obtain my opt out cookie, the
>> damage has been done. They have already, and explicitly against my
>> permission, intercepted my http get request (or whatever).
>
> You may dislike what they are doing, but I suspect you are also using
> the word "intercept" in a rather imprecise non-RIPA way.

I would say it was accurate in a technical sense - they are redirecting
packets (labelled as destined for a specified webserver) to their own
box - and then holding a conversation with my browser in which they
pretend to be the target web server - at least to the extent of getting
a cookie. I would consider this a classic man-in-the-middle attack.

if it is RIPa unlawful interception is another matter - and I suspect it
isn't. They seem to be going to great lengths to avoid "making some or
all of the contents of the communication available, while being
transmitted, to a person other than the sender or intended recipient of
the communication."

The article mentions that the ISP is making the data available to the
phorm "box" though, so it is possible that, if the court applies the
"person behind the machine" criteria that have been (mis)applied in some
online pornography cases, then it is *still* BT rather than phorm that
have performed the interception.

> By the way, what "damage" is done, if your browsing command is thrown
> away as soon as it's been translated into one of their categories?

the same as would be done if they chose to let themselves into my house
and take a look around while I wasn't there. the fact that they then see
a "phorm not welcome here!" sign and leave doesn't alter the fact they
decided to let themselves in in the first place.

> Or do you consider it interception that they say to themselves "guess
> what, Dave seems to be interested in ipods".

They claim not to get that far - however, I suppose one positive
benefit might be that more sites find reason to install https
certificates...

I suspect that "this http page is about ipods" is sufficiently
specific to qualify as "some or all of the contents"; I would also
suspect that it doesn't matter though, given the box doesn't actually
come out and say that at any point but (presumably) just updates your
local cookie until it is modifying a page from a partner site, at which
point it also reads the cookie for purposes of targeted advertising.

>>> This is another key issue. Are the ISP exempt anyway because it's
>>> part of the way they deliver the service (of shipping port 80
>>> packets around), or might they be exempt because there's no
>>> relevant "making available" to a relevant "person".

>> I would suspect the latter. It would be massively difficult to
>> describe data mining and substitution based on content as being
>> part of the normal operation of a packet-shifting service,

> It would certainly clear the air if we could establish whether or not
> this was their 'defence'.

I would assume revealing your defences before you are attacked is as
poor a tactic in law as it would be in war games... The best weapon is
one you never have to reveal, as uncertainty is as good a deterrent as
any (and a lot better than most).

>> and also as being compatible with the "mere conduit" defences many
>> seem to raise when the Four Horsemen are waved in parliament by
>> publicity see... I mean concerned individuals.

> They are still being a mere conduit for the majority of the content.

I would argue that *all* traffic is being inspected, even if only a
small amount is modified. It can't be a defence to say "But we don't
look at the bits, we just push them down the tubes" if you DO look at
the bits. Or could they get away with "ok, so we DO look at the bits,
but only for marketing purposes, and we deliberately don't remember what
we saw"?

> I wonder if mere conduit status is something like virginity where if
> you lose it once, it's gone for ever; or if it's a defence against
> liability for specific pieces of data (eg specific web pages). As all
> the web pages that are being 'modified' are from customers of
> theirs, perhaps the contract says that the customer won't sue them as
> a result of the modification.

I know they don't have that in their T&C right now. I suspect it might
be highly dubious if you could retroactively give yourself permission to
do whatever is profitable by changing your T&C to suit. Regardless
though, I would be surprised if the conduit defence still works if you
look at (but usually don't modify) the bits you shift.

> I just tried it again, and it won't switch on, or leave me a cookie.
> Maybe my earlier experience was one of those mysterious glitches?

Its possible they have disabled it due to too many Reg readers and
UKCrypto readers going and clicking stuff - or it was another of those
inadequately specific masks retroactively repaired that we discussed
earlier :)

>> It might be interesting to see what happens if you perform a
>> paper-based opt-out - write a lawyergram to the ISP along the lines
>> of "I do not authorize and have not authorized the inspection or
>> modification of my internet traffic for the purposes of targeted
>> advertising and will consider any such action interception for the
>> purposes of the RIP act 2000" and see what they decide to do to
>> opt you out :)
>
> They might write back and say "we don't [consider it Interception]
> and we've told you the webpage to use to opt out".

They might, yes. However, I don't know many lawyers who would be happy
about something like that going out on paper before it was tested in
court :)
Roland Perry
2008-03-11 08:41:31 UTC
Permalink
In article <47D5CF92.2030403-puGfsi27rH1aa/***@public.gmane.org>, Dave Howe <DaveHowe-puGfsi27rH1aa/***@public.gmane.org>
writes

>>> Difficult to tell. Is it a legal interception in the course of
>>>normal operations? That would require you to define normal operations
>>>as examining your customer's traffic and modifying it for your own
>>>profit (not your customers).
>> Nonsense. The legal definition is nothing like that.
>
> Which is the point, really. it can only be legal for the ISP to do it
>if it is (a) by or on behalf of a person who provides a
>telecommunications service

The Phorm platform appears to be "franchised" to the ISPs, who operate
it within their network.

>and (b) it takes place for purposes connected
>with the provision or operation of that service. Operating a web cache
>to more efficiently deliver pages could reasonably be argued to fall
>under (b), I doubt data-mining for targeting purposes would.

The Phorm people are working hard at the proposition that seeing "more
targeted" advertising *is* a benefit to the user. I don't know if this
is to justify it being part of the provision of the ISPs service, or if
it's simply to persuade people not to opt out.

>> Or maybe the advertisers' self interest will win over and everyone
>>will get just adverts relevant for cbeebies (As that's the most
>>prominent interest).
>
>anything is possible. but outside of "whine" factor and except in the
>run up to xmas, under 5's don't have much marketing pull, and as
>cbeebies is unlikely to sign up for targeted advertising, what is more
>likely is that the ebay and chatroom users will see a bunch of
>advertising for kids stuff.

That's what I meant. The cbeebies "profile" being the dominant one even
when the last half hour's surfing has been by the parents.

>The ebay user may well be interested in new ways to keep the kids
>quiet,

Is eBay likely to show Phorm adverts? Or the BBC? Several of the very
popular sites might not be Phorm partners, and therefore much of the
profiling may be wasted.

>Pop-ups/unders however annoy me enough that I usually pull up the page
>source, find where they were loaded from, and block the entire domain.

Pop-up are banned here too, and anything in Flash. You'd be surprised
how much that cleans up the screen :)

>>I suspect you are also using the word "intercept" in a rather
>>imprecise non-RIPA way.
>
>I would say it was accurate in a technical sense - they are redirecting
>packets (labelled as destined for a specified webserver) to their own
>box - and then holding a conversation with my browser in which they
>pretend to be the target web server - at least to the extent of getting
>a cookie. I would consider this a classic man-in-the-middle attack.

Many activities on the Internet involve "men in the middle", and not
necessarily as an attack (on the user). Spam filters, for example.

>if it is RIPa unlawful interception is another matter - and I suspect it
>isn't. They seem to be going to great lengths to avoid "making some or
>all of the contents of the communication available, while being
>transmitted, to a person other than the sender or intended recipient of
>the communication."

If it's not available to such a person, what's the problem ;-)

>The article mentions that the ISP is making the data available to the
>phorm "box" though, so it is possible that, if the court applies the
>"person behind the machine" criteria that have been (mis)applied in some
>online pornography cases, then it is *still* BT rather than phorm that
>have performed the interception.

That's the virus-checker situation, but BT is the ISP, and they have
"rights" to be able to inspect the content in order to provide the
service (see above).

>> By the way, what "damage" is done, if your browsing command is thrown
>> away as soon as it's been translated into one of their categories?
>
>the same as would be done if they chose to let themselves into my house
>and take a look around while I wasn't there. the fact that they then see
>a "phorm not welcome here!" sign and leave doesn't alter the fact they
>decided to let themselves in in the first place.

You still aren't explaining why that's bad, if the result of the
expedition leaves no trace. Your privacy can't be invaded if no
information is abstracted.

>> Or do you consider it interception that they say to themselves "guess
>> what, Dave seems to be interested in ipods".
>
> They claim not to get that far

Their papers say exactly that in (page 7):
http://www.phorm.com/user_privacy/EY_Phorm_Exam.pdf

> - however, I suppose one positive benefit might be that more sites
>find reason to install https certificates...

It's mildly amusing that they say they won't look at the content inside
https pages, I think they mean that they *can't*.

>>> and also as being compatible with the "mere conduit" defences many
>>> seem to raise when the Four Horsemen are waved in parliament by
>>>publicity see... I mean concerned individuals.
>
>> They are still being a mere conduit for the majority of the content.
>
> I would argue that *all* traffic is being inspected, even if only a
>small amount is modified.

Mere Conduit is only about Selecting and Modifying (and other things
that aren't relevant here). They will probably fail the "Selecting and
Modifying" test for the adverts they insert. The question is, what
liability does that incur. If they are already pre-qualifying adverts to
meet their moral standards you can be sure they will also pass any
liability on the to advertiser. The only content that's being modified
belongs to the partner site, who can also be contractually prevented
from objecting (indeed the whole point is that Phorm *does* modify).

My earlier question about Mere Conduit and virginity (versus item by
item) still stands, however.

>It can't be a defence to say "But we don't look at the bits, we just
>push them down the tubes" if you DO look at the bits. Or could they get
>away with "ok, so we DO look at the bits, but only for marketing
>purposes, and we deliberately don't remember what we saw"?

Defence against what?

>> I wonder if mere conduit status is something like virginity where if
>> you lose it once, it's gone for ever; or if it's a defence against
>>liability for specific pieces of data (eg specific web pages). As all
>> the web pages that are being 'modified' are from customers of
>>theirs, perhaps the contract says that the customer won't sue them as
>> a result of the modification.
>
>I know they don't have that in their T&C right now. I suspect it might
>be highly dubious if you could retroactively give yourself permission to
>do whatever is profitable by changing your T&C to suit. Regardless
>though, I would be surprised if the conduit defence still works if you
>look at (but usually don't modify) the bits you shift.

Mere Conduit is nothing to do with looking at bits. It's about being
not-responsible for *originating* bits that are merely (sic) passing
through under someone else's instructions.

>> They might write back and say "we don't [consider it Interception]
>>and we've told you the webpage to use to opt out".
>
> They might, yes. However, I don't know many lawyers who would be happy
>about something like that going out on paper before it was tested in
>court :)

Their lawyers must be happy it's not interception, otherwise the gaols
will be full of BT employees as soon as they are "found out".
--
Roland Perry
Peter Fairbrother
2008-03-11 10:52:04 UTC
Permalink
A quick recap of RIPA, and the arguments which have been raised as to
why and how Phorm/BT's planned action might not be illegal interception.

First question, is it interception under s.1? It certainly seems to be,
though perhaps the ss.2(2) "machine-only,not-a-person" argument - or
perhaps the ss.2(5) "it's-traffic-data-only" argument might prevent it
from being interception.

If, as we almost all suspect, it is interception, is it lawful
interception under s.3 or s.4? Because if not then it's a criminal offense.

Two possibilities here again, first that it's lawful interception under
s3(1) because both the sender and intended recipient have granted
consent - or perhaps it's lawful under ss.3(3), because it's done by the
ISP and for the ISP's reasons.

But I see no chance of any of these arguments being accepted.



Roland Perry wrote:
> In article <47D5CF92.2030403-puGfsi27rH1aa/***@public.gmane.org>, Dave Howe <DaveHowe-puGfsi27rH1aa/***@public.gmane.org>
> writes
>
>>>> Difficult to tell. Is it a legal interception in the course of
>>>> normal operations? That would require you to define normal
>>>> operations as examining your customer's traffic and modifying it
>>>> for your own profit (not your customers).
>>> Nonsense. The legal definition is nothing like that.
>>
>> Which is the point, really. it can only be legal for the ISP to do it
>> if it is

this is from ss.3(3) btw:

(a) by or on behalf of a person who provides a
>> telecommunications service
>
> The Phorm platform appears to be "franchised" to the ISPs, who operate
> it within their network.

I don't know what that means, either!

>> and (b) it takes place for purposes connected
>> with the provision or operation of that service. Operating a web cache
>> to more efficiently deliver pages could reasonably be argued to fall
>> under (b), I doubt data-mining for targeting purposes would.
>
>> The article mentions that the ISP is making the data available to the
>> phorm "box" though, so it is possible that, if the court applies the
>> "person behind the machine" criteria that have been (mis)applied in some
>> online pornography cases, then it is *still* BT rather than phorm that
>> have performed the interception.
>
> That's the virus-checker situation, but BT is the ISP, and they have

> "rights" to be able to inspect the content in order to provide the
> service (see above).

s.2(1):

" “telecommunications service” means any service that consists in the
provision of access to, and of facilities for making use of, any
telecommunication system (whether or not one provided by the person
providing the service); and

“telecommunication system” means any system (including the apparatus
comprised in it) which exists (whether wholly or partly in the United
Kingdom or elsewhere) for the purpose of facilitating the transmission
of communications by any means involving the use of electrical or
electro-magnetic energy. "

So BT etc can lawfully look at content under ss.3(3) in order to
"facilitat[e] the transmission of communications" - but looking at
content to obtain web profiles does not make interception lawful under
ss.3(3).


-- Peter Fairbrother
Roland Perry
2008-03-11 11:51:14 UTC
Permalink
In article <47D66454.1070000-1HOZaDBbGgxaa/***@public.gmane.org>, Peter Fairbrother
<zenadsl6186-1HOZaDBbGgxaa/***@public.gmane.org> writes
>A quick recap of RIPA, and the arguments which have been raised as to
>why and how Phorm/BT's planned action might not be illegal interception.
>
>First question, is it interception under s.1? It certainly seems to be,
>though perhaps the ss.2(2) "machine-only,not-a-person" argument - or
>perhaps the ss.2(5) "it's-traffic-data-only" argument might prevent it
>from being interception.
>
>If, as we almost all suspect, it is interception, is it lawful
>interception under s.3 or s.4? Because if not then it's a criminal
>offense.
>
>Two possibilities here again, first that it's lawful interception under
>s3(1) because both the sender and intended recipient have granted
>consent - or perhaps it's lawful under ss.3(3), because it's done by
>the ISP and for the ISP's reasons.
>
>But I see no chance of any of these arguments being accepted.

There must be some lawyers at Phorm and the ISPs who disagree with you.
Is this going to end up being tested in court?

>> The Phorm platform appears to be "franchised" to the ISPs, who
>>operate it within their network.
>
>I don't know what that means, either!

The Phorm platform seems to be within the ISP and operated by the ISP,
and Phorm itself is "hands off" the day to day workings.

>s.2(1):
>
>" “telecommunications service” means any service that consists in
>the provision of access to, and of facilities for making use of, any
>telecommunication system (whether or not one provided by the person
>providing the service); and
>
>“telecommunication system” means any system (including the
>apparatus comprised in it) which exists (whether wholly or partly in
>the United Kingdom or elsewhere) for the purpose of facilitating the
>transmission of communications by any means involving the use of
>electrical or electro-magnetic energy. "
>
>So BT etc can lawfully look at content under ss.3(3) in order to
>"facilitat[e] the transmission of communications" - but looking at
>content to obtain web profiles does not make interception lawful under
>ss.3(3).

You appear to be asserting that Phorm does not qualify under those
definitions. I'm not so sure - at a marketing level they are claiming to
provide a service of "less annoying advertising" and "anti-phishing",
and you can't deny that whatever else the Phorm platform is doing it is
also transferring webs pages (in general) between the websites and the
user. The definitions above don't have a concept of "necessary" in them,
so an ISP can provide "frilly bits" as well.

Perhaps you can explain why you think Spam filters might be legal
(interfering as they do with the transmission of emails). Note that such
filters don't always delete suspicious email, sometimes they mark it and
pass it on.
--
Roland Perry
Roland Perry
2008-03-11 06:39:17 UTC
Permalink
In article <fc0WQZC$va1HFA9o-QmCu5Paugg/10XsdtD+***@public.gmane.org>, Roland Perry
<lists-***@public.gmane.org> writes
>>I went to http://webwise.bt.com/webwise/index.html and couldn't
>>turn it on - it firmly asserted that webwise was off, and the "turn it
>>on" link did nothing.
>>
>>I assumed that was because I wasn't a BT user. Maybe I need to relax a
>>few rules :)
>
>I just tried it again, and it won't switch on, or leave me a cookie.

And just now I did get a cookie (so maybe my finger trouble) when
switching it "off", although switching it "on" doesn't result in a claim
that it's on:

http://webwise.net/webwise_status/frame.php
Name OPTED_OUT
Value YES
Host .webwise.net
Path /
Secure No
Expires Thu, 11 Mar 2010 06:33:16 GMT
--
Roland Perry
Dave Howe
2008-03-10 12:24:45 UTC
Permalink
More from El Reg
Interview with CEO Kent Ertegrul from Pharm

http://www.theregister.co.uk/2008/03/07/phorm_interview_burgess_ertegrul/
Charles Lindsey
2008-03-10 16:17:08 UTC
Permalink
On Sun, 09 Mar 2008 18:04:12 -0000, Roland Perry
<lists-***@public.gmane.org> wrote:

> Phorm is apparently inserting adverts, but I'm still not clear whether
> those inserted adverts replace an advert the original webpage was
> serving (eg to non-Phormed end users), replacing a blank space, or is
> somehow in addition to what was on the page originally.

I think the webpage that you are browsing contains a "hole" for an advert
to go in. The script for filling that hole tries to call some javascript
routine and, if that javascript routine is present (as inserted by BT when
delivering the page to you), that routine causes a "suitable" ad (or maybe
no ad at all) to be inserted in that hole.

Alternatively, the website looks for a phorm cookie on your site, which
gives it your "random number" (and maybe more - those cookies might be
quite complex). The website that chooses a "suitable" ad based on that
random number (with assistance from Phorm of from other information in
that cookie) and places it in that hole.

Each time this happens, Phorm and BT receive a 'cut'.

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 
   Web: http://www.cs.man.ac.uk/~chl
Email: chl-***@public.gmane.org      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
Ian Batten
2008-03-09 21:33:00 UTC
Permalink
On 9 Mar 2008, at 16:25, Nicholas Bohm wrote:
>>
>
> I think the cache must be among the intended recipients; I don't see
> how caching by itself can be interception.

Wasn't there some suggestion a few years ago that EU copyright
proposals would have caused problems for caches? Which implied that
the cache was seen as distinct from the mere process of (permitted)
fetching and reading? And haven't various complaints been made about
Google's caching of content on similar grounds?

ian
Roland Perry
2008-03-09 21:52:51 UTC
Permalink
In article <653DEB92-D9AD-4B9C-BB6C-AF79D1A79888-BFib/+***@public.gmane.org>, Ian
Batten <igb-BFib/+***@public.gmane.org> writes
>Wasn't there some suggestion a few years ago that EU copyright
>proposals would have caused problems for caches? Which implied that
>the cache was seen as distinct from the mere process of (permitted)
>fetching and reading?

Yes. I have written about this earlier today. The rightsholders were
eventually persuaded that there wasn't any extra risk from caches.

There is also what amounts to a description of a "well behaved cache" in
the Ecommerce Directive (article 13).

>And haven't various complaints been made about Google's caching of
>content on similar grounds?

Google's "cache" is rather stretching the meaning of the word. It's more
like the tip of archive.org's iceberg.

Compared, for example, to what the page looked like the last time
someone clicked on the link.
--
Roland Perry
Richard Clayton
2008-03-09 17:54:01 UTC
Permalink
In article <47D3DAE5.7010608-dr0oxk7mE8FWk0Htik3J/***@public.gmane.org>, Peter Sommer
<peter-dr0oxk7mE8FWk0Htik3J/***@public.gmane.org> writes

>Although I agree with you in terms of the need to get explicit opt-in
>consent from ISP customers, the position of those who provide a
>generally available web-site (ie one that is not password-protected)
>seems to be more difficult. What is the purpose of the website if not
>to get people to visit it?

It's helpful to consider the notion of the connected and unconnected
web... the connected web is the plethora of sites that can be located
and accessed by starting at one point and following all possible links
to all possible places, by picking URLs out of archived emails, by
consulting the DNS to learn of domain names and so on and so forth.

To a first approximation the connected web is what a search engine knows
about (I'd name Google specifically, but they might start looking at
email traffic via @gmail addresses and that would give them more than
just the connected web to examine...)

There is then the unconnected web, which is everything else. Some
estimates suggest that may well be bigger than the connected web.

>How in practice do you set up a web-site
>to whom all are invited bar a very small number of people/entities?

I set up www.example.com/secretsquirrel/ and only tell a small number
of people about /secretsquirrel/. It is, if you like, "security
through obscurity" (and is a damn site simpler to do than setting up
passwords, SSL, and all that palaver).

I would argue that it was implicit in my failing to provide links from
the front page of www.example.com that it was my intention that this
subsite was private -- and hence that examining the content of the pages
within this subsite was unauthorised.

>You also have a further problem: the traffic to the customer goes via
>the ISPs facilities - how in practice do you set up an open website so
>that the ISP is given permission to pass traffic to its customers but
>not to the specific facilities that link into Phorm? (

You will recall that it is NOT interception if content is accessed for
either a lawful business practice or for the purposes of providing a
service. The latter is why caches are lawful (not some random appeal to
the Copyright Directive!)

>By the way, one of the difficulties in writing about Phorm's technical
>infrastructure is that the precise method of collecting data keeps on
>changing).

Indeed -- if they were only looking at outgoing traffic (GETs etc) then
provided that they had permission from the user then this would be
lawful. It is, in my view, when they look at the traffic coming back
from the website that it becomes unlawful -- albeit only in some
circumstances.

I find that the documentation is somewhat vague as to whether the
returning content is examined on-the-fly to pick out keywords (to try
and decide what sort of site it is) or whether the system merely
accumulates URLs and some offline process visits the sites to take a
view as to what might be on them --- the notion being that if they are
lots of pictures of luxury cars then you are in the market for a Lexus
(though you might not have understood that yet) and so you should be
bombarded with ads for a Lexus until you purchase own (and doubtless for
time thereafter until the system works out that you're not seeking
automobile porn any more!)

I also wonder about how common law notions of confidentiality come into
all of this....

IANAL :)

- --
richard Richard Clayton

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. Benjamin Franklin
Roland Perry
2008-03-09 18:33:23 UTC
Permalink
In article <Dxwj6$W5QC1HFAcH-dqO9MOo5Mr+***@public.gmane.org>, Richard Clayton
<richard-dqO9MOo5Mr+***@public.gmane.org> writes
>You will recall that it is NOT interception if content is accessed for
>either a lawful business practice or for the purposes of providing a
>service.

One possible service being the anti-phishing etc that ISPs might use to
"sell" the system to users.

> The latter is why caches are lawful (not some random appeal to
>the Copyright Directive!)

Perhaps you misunderstand my earlier remarks. Rightsholders were
determined to make caches illegal *because* of the copyright issues.

They had all sorts of scenarios where data would "leak" - for example
what if a cache-operating ISP was to have a page somewhere called "top
ten web accesses today" (a bit like the BBC's 'Most Popular Stories")
then they considered the content would be delivered to people in breach
of copyright (let alone in breach of any pay-per-view). In similar vein,
what if someone made a browser which could reproduce its history
offline, making extra "copies" without the rightsholders knowing [1].
They also had concerns about caches bypassing their mechanisms for
counting hits [2] and delivering out-of-date content. In short they
hated the whole idea. The Copyright Directive was simply the vehicle
they chose to attempt to outlaw them altogether, unless (and this is
another echo of the Phorm debate) cache operators got prior permission
explicitly from every website they proposed to cache.

{1] There are many other ways that copyright material might be
downloaded and copied in breach, however the rightsholders seemed
determined to have a model where browsing websites was uniquely
ephemeral.

[2] Maybe Phorm does the reverse, and multiplies hits?
--
Roland Perry
Richard Clayton
2008-03-09 22:59:20 UTC
Permalink
In article <AFHBmNGz1C1HFA+X-QmCu5Paugg/10XsdtD+***@public.gmane.org>, Roland Perry <***@intern
etpolicyagency.com> writes

>In article <Dxwj6$W5QC1HFAcH-dqO9MOo5Mr+***@public.gmane.org>, Richard Clayton
><richard-dqO9MOo5Mr+***@public.gmane.org> writes
>
>>You will recall that it is NOT interception if content is accessed for
>>either a lawful business practice or for the purposes of providing a
>>service.
>
>One possible service being the anti-phishing etc that ISPs might use to
>"sell" the system to users.

The explanation provided so far by Phorm of the anti-phishing service
is that it will be a bog-standard "match the URL against a blacklist"
system, viz: it will not require the site contents to be inspected by
the system.

That doesn't surprise me, the whole point of a phishing website is
that it appears to be identical to the real bank -- so it's a bit
silly to consider a blocking system based on the content.

- --
richard Richard Clayton

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. Benjamin Franklin
Dave Howe
2008-03-09 22:26:24 UTC
Permalink
Richard Clayton wrote:
> To a first approximation the connected web is what a search engine knows
> about (I'd name Google specifically, but they might start looking at
> email traffic via @gmail addresses and that would give them more than
> just the connected web to examine...)
>
> There is then the unconnected web, which is everything else. Some
> estimates suggest that may well be bigger than the connected web.
>
>> How in practice do you set up a web-site
>> to whom all are invited bar a very small number of people/entities?
>
> I set up www.example.com/secretsquirrel/ and only tell a small number
> of people about /secretsquirrel/. It is, if you like, "security
> through obscurity" (and is a damn site simpler to do than setting up
> passwords, SSL, and all that palaver).
>
> I would argue that it was implicit in my failing to provide links from
> the front page of www.example.com that it was my intention that this
> subsite was private -- and hence that examining the content of the pages
> within this subsite was unauthorised.

Also of course possibly you could use your robots.txt to exclude
webcrawlers from the page even if they know about it (and I understand
some search-engine-provided browser toolbars do request info for the
page, which could mark them for a later visit by bot even if not
connected to the "visible" web)
Nicholas Bohm
2008-03-09 14:36:02 UTC
Permalink
Peter Fairbrother wrote:

> I think it is generally agreed that what BT and Phorm propose involves
> looking at the content of communications, ie what they are doing is
> interception.
>
> Is it lawful interception? People have suggested that it may be, based
> on consent. Let's look at RIPA. s3(1):
>
> "Conduct by any person consisting in the interception of a communication
> is authorised by this section if the communication is one which, or
> which that person has reasonable grounds for believing, is both—
>
> (a) a communication sent by a person who has consented to the
> interception; and
>
> (b) a communication the intended recipient of which has so consented."
>
>
> So the interceptor has to have reasonable grounds to believe that both
> the sender and the intended recipient have consented. For HTTP traffic
> this will be the user and a server, each taking on both roles.
>
> First. from the user's side, can any opt-out scheme cover this? I doubt
> it very much, failing to opt-out is not the same as having consented. It
> doesn't say "hasn't objected", it says "has consented".
>
> The Phorm scheme, which relies on the user who wants to opt-out storing
> a cookie, doesn't even work in many cases - for example, my browser
> deletes any cookies every time it is shut down, for security and privacy
> reasons. I don't keep long-term cookies. It's a standard option in
> Firefox, and probably most other browsers too. Not having a cookie
> stored doesn't mean I have consented.
>
> How about opt-in schemes? Where two people may share a browser, even an
> opt-in cookie does not give them reasonable cause to believe the action
> of granting consent, as opposed to not objecting, has occurred - and
> they won't normally know when that happens, so an opt-in cookie, or even
> expressed permission from the account holder to the ISP, is
> insufficient - the account holder may not be the sender or intended
> recipient of the communication.
>
> And what about the server side of things? For example, I run several
> websites, and I do not, and never will, give Phorm permission to
> intercept the communications from these websites. It would be possible
> for Phorm to get permission from a subset of websites, but not all - do
> they only look at traffic coming from those websites (remembering that
> the user has to give permission too)?
>
> I can't see how lawful interception based on consent could be made to
> work on any substantial scale.
>
> Not to mention the interception issues raised by how they decide whether
> consent has been granted - they will need some information for that, and
> it seems likely that they will need to intercept in order to get the
> information needed to make the decisions.

I don't think there's any answer to Peter's argument, if his facts are
right. There seems to be some doubt whether the facts have emerged
fully, and of course until this "service" starts, no offence has been
committed.

So it may be sensible to wait until something happens (if I am right in
thinking it hasn't yet) before trying to push anyone into taking action
against it.

Nicholas
--
Salkyns, Great Canfield, Takeley,
Bishop's Stortford CM22 6SX, UK

Phone 01279 870285 (+44 1279 870285)
Mobile 07715 419728 (+44 7715 419728)

PGP public key ID: 0x899DD7FF. Fingerprint:
5248 1320 B42E 84FC 1E8B A9E6 0912 AE66 899D D7FF
Roland Perry
2008-03-09 18:09:06 UTC
Permalink
In article <47D3CDBE.90807-1HOZaDBbGgxaa/***@public.gmane.org>, Peter Fairbrother
<zenadsl6186-1HOZaDBbGgxaa/***@public.gmane.org> writes

>The Phorm scheme, which relies on the user who wants to opt-out storing
>a cookie, doesn't even work in many cases - for example, my browser
>deletes any cookies every time it is shut down, for security and
>privacy reasons. I don't keep long-term cookies. It's a standard option
>in Firefox, and probably most other browsers too. Not having a cookie
>stored doesn't mean I have consented.

Perhaps a cookie expert can answer this for me:

It seems widely accepted that Phorm requires an "opt-out" cookie and
therefore anyone storing no-cookies can't opt-out beyond their current
session.

Why can't a browser be set up to operate with either:

No-cookies apart from the Phorm opt-out one

Cookies, but rejecting any of those placed by Phorm to facilitate the
adverts.

>How about opt-in schemes? Where two people may share a browser, even
>an opt-in cookie does not give them reasonable cause to believe the
>action of granting consent, as opposed to not objecting, has occurred -
>and they won't normally know when that happens, so an opt-in cookie, or
>even expressed permission from the account holder to the ISP, is
>insufficient - the account holder may not be the sender or intended
>recipient of the communication.

I've written before about the difference between a "subscriber" who may
opt in/out of things, and the users of the connectivity on that
subscription. It didn't seem to spark much comment.
--
Roland Perry
David Hansen
2008-03-09 19:54:39 UTC
Permalink
On 9 Mar 2008 at 18:09, Roland Perry wrote:

> Why can't a browser be set up to operate with either:
>
> No-cookies apart from the Phorm opt-out one

I'm sure many/most readers of this list could do that. I suspect many
more general operators ofweb browsers couldn't.

That is beside the point however. Why should anyone spend even a few
seconds changing their settings in order to try and stop being spied on
by some slimeballs in leage with slimeballs like British Telecom who
both want to push unwanted advertising at people? If people want to opt
in they can.




--
David Hansen, Edinburgh
I will *always* explain revoked encryption keys, unless RIP prevents
me
http://www.opsi.gov.uk/acts/acts2000/00023--e.htm#54
Roland Perry
2008-03-09 20:17:45 UTC
Permalink
In article <4f7d7f7501ukcrypto-vEWq/***@public.gmane.org>, Paul Vigay
<ukcrypto-vEWq/***@public.gmane.org> writes
>> I've written before about the difference between a "subscriber" who may
>> opt in/out of things, and the users of the connectivity on that
>> subscription. It didn't seem to spark much comment.
>
>Again, if you have multiple users on a single network connection, then it
>would make sense to have some kind of gateway machine acting as a proxy
>server, through which each user connects. You could then configure
>different settings for each user, independent of their machine or browser.

People who are worrying about multiple users getting their cookies
confused on the same PC are presumably assuming these users aren't
taking advantage of the in-built user account system in Windows. So an
even more sophisticated system seems a pipe dream.
--
Roland Perry
Richard Clayton
2008-03-09 22:48:22 UTC
Permalink
In article <LV7DiKECfC1HFA$***@perry.co.uk>, Roland Perry <***@internetp
olicyagency.com> writes

>Perhaps a cookie expert can answer this for me:
>
>It seems widely accepted that Phorm requires an "opt-out" cookie and
>therefore anyone storing no-cookies can't opt-out beyond their current
>session.
>
>Why can't a browser be set up to operate with either:
>
> No-cookies apart from the Phorm opt-out one
>
> Cookies, but rejecting any of those placed by Phorm to facilitate the
> adverts.

a brief read of BT's FAQs would assist

http://webwise.bt.com/webwise/help.html?_faqs=21#f21

basically if you block all cookies from www.webwise.net then you are
entirely opted out and remain so whether you keep cookies or not

- --
richard Richard Clayton

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. Benjamin Franklin
Roland Perry
2008-03-10 08:04:13 UTC
Permalink
In article <9AT8GXC2kG1HFAZr-dqO9MOo5Mr+***@public.gmane.org>, Richard Clayton
<richard-dqO9MOo5Mr+***@public.gmane.org> writes

>>Perhaps a cookie expert can answer this for me:
>>
>>It seems widely accepted that Phorm requires an "opt-out" cookie and
>>therefore anyone storing no-cookies can't opt-out beyond their current
>>session.
>>
>>Why can't a browser be set up to operate with either:
>>
>> No-cookies apart from the Phorm opt-out one
>>
>> Cookies, but rejecting any of those placed by Phorm to facilitate the
>> adverts.
>
>a brief read of BT's FAQs would assist
>
> http://webwise.bt.com/webwise/help.html?_faqs=21#f21
>
>basically if you block all cookies from www.webwise.net then you are
>entirely opted out and remain so whether you keep cookies or not

Which, of course, differs from the position most people previously
understood, and which is described elsewhere in their faq as:

"BT Webwise uses cookies stored on your computer to capture your
preference ... If you delete the cookie, you'll need to reset
your preference [to switch off Phorm]."

If there's a second way to turn the service off, then that entirely
alters the premise upon which my questions above were asked!

If it's that simple, what's their motivation for starting the scare that
"people who value their privacy sufficiently to turn off cookies, have
no way to disable Phorm, because it uses a cookie".
--
Roland Perry
Charles Lindsey
2008-03-10 16:08:55 UTC
Permalink
On Sun, 09 Mar 2008 22:48:22 -0000, Richard Clayton
<richard-dqO9MOo5Mr+***@public.gmane.org> wrote:

> a brief read of BT's FAQs would assist
>
> http://webwise.bt.com/webwise/help.html?_faqs=21#f21
>
> basically if you block all cookies from www.webwise.net then you are
> entirely opted out and remain so whether you keep cookies or not

Lots of interesting stuff on that site.

1. It is clearly "opt out". You have to take action, either by permitting
their cookie to remain, or by blocking cookies from webwise.

2. If they don't see their 'opted out' cookie, they will try to set their
own 'opted in' cookie containing (at least) your personal "random number".
But it won't be set if you have blocked webwise. Whether they will still
try to keep your browsing history based on your IP address id not clear,
but for sure you will not see any ads.

3. If you merely delete all cookies overnight, then you will get a new
random number each morning. This may confuse their system, or it may cause
you to receive some not-very-well-targetted ads during that day.

4. The site makes it clear that they will examne the whole of the URLs
they send, including query options. So, ibnsofrar as this is interception,
is is more than just interception of trafic data. This is onterception of
real content.

5. BT are willing to block your access to known phishers' sites, but only
if you agree to take those ads too.

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 
   Web: http://www.cs.man.ac.uk/~chl
Email: chl-***@public.gmane.org      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
Brian Morrison
2008-03-10 20:19:33 UTC
Permalink
On Mon, 10 Mar 2008 16:08:55 -0000
"Charles Lindsey" <chl-***@public.gmane.org> wrote:

> 2. If they don't see their 'opted out' cookie, they will try to set their
> own 'opted in' cookie containing (at least) your personal "random number".
> But it won't be set if you have blocked webwise. Whether they will still
> try to keep your browsing history based on your IP address id not clear,
> but for sure you will not see any ads.

Well you will, but not Phorm's "targeted" ads. Whatever happens, the
profiler box at the ISP is still slurping all your browsing data, and
who knows what it will be doing with it?

--

Brian Morrison

bdm at fenrir dot org dot uk

"Arguing with an engineer is like wrestling with a pig in the mud;
after a while you realize you are muddy and the pig is enjoying it."

GnuPG key ID DE32E5C5 - http://wwwkeys.uk.pgp.net/pgpnet/wwwkeys.html
Roland Perry
2008-03-10 21:49:23 UTC
Permalink
In article <20080310201933.04bb2b65-***@public.gmane.org>, Brian
Morrison <bdm-***@public.gmane.org> writes
>Whatever happens, the profiler box at the ISP is still slurping all
>your browsing data, and who knows what it will be doing with it?

This seems to be the fundamental trust issue. ISPs have all sorts of
ways to slurp your browsing data already - but people seem to have
trusted them. Phorm says they won't touch the data if you are opted out
(and they won't even save the data if you are opted in), but you don't
trust them - is that fair summary?
--
Roland Perry
Brian Morrison
2008-03-11 10:41:49 UTC
Permalink
Roland Perry wrote:
> In article <20080310201933.04bb2b65-***@public.gmane.org>, Brian
> Morrison <bdm-***@public.gmane.org> writes
>> Whatever happens, the profiler box at the ISP is still slurping all
>> your browsing data, and who knows what it will be doing with it?
>
> This seems to be the fundamental trust issue. ISPs have all sorts of
> ways to slurp your browsing data already - but people seem to have
> trusted them. Phorm says they won't touch the data if you are opted out
> (and they won't even save the data if you are opted in), but you don't
> trust them - is that fair summary?

I have a contract with my ISP, and a commercial relationship with them
because of it. I don't have that with Phorm and I don't see how their
business model works at all without requiring an explicit (set opt-out
cookie) or implicit (block all webwise cookies) decision from only a
small minority of web browsing customers; if that percentage is fairly
high then the value of the correlation between browsing habits and
advertising accuracy begins to fall and any premium Phorm can charge
advertisers for link insertion must begin to be suspect.

At the heart of my concern is that the profiler box's software is
written by Phorm and although operated by the ISP I will have no way to
monitor what is being sent to whom and for what purpose. I don't use one
of the ISP's currently mentioned as being likely Phorm customers but I'm
still beginning to consider a VPN to somewhere else as a way of
obscuring all of this stuff (and with luck defeating potential LEA
monitoring as a by-product). It might cost me money, but that's a price
worth paying to keep the scum at bay. And yes I know about the need to
have some authentication to prevent the SSL proxy MITM attack that is
possible.

--

Brian
Roland Perry
2008-03-11 11:00:51 UTC
Permalink
In article <47D661ED.8080606-***@public.gmane.org>, Brian Morrison
<bdm-***@public.gmane.org> writes
>At the heart of my concern is that the profiler box's software is
>written by Phorm and although operated by the ISP I will have no way to
>monitor what is being sent to whom and for what purpose.

So you don't trust your ISP to have checked that the system is OK?

[Which could mean "works the way Phorm claims it does" or "works without
infringing you privacy", or whatever?]

You don't have any way to monitor whether your emails are leaking from
the ISP's spam filtering box (that they also bought in from an external
supplier) either.
--
Roland Perry
Brian Morrison
2008-03-11 11:37:38 UTC
Permalink
Roland Perry wrote:
> In article <47D661ED.8080606-***@public.gmane.org>, Brian Morrison
> <bdm-***@public.gmane.org> writes
>> At the heart of my concern is that the profiler box's software is
>> written by Phorm and although operated by the ISP I will have no way
>> to monitor what is being sent to whom and for what purpose.
>
> So you don't trust your ISP to have checked that the system is OK?

Not to a sufficiently high degree of confidence, no.

>
> [Which could mean "works the way Phorm claims it does" or "works without
> infringing you privacy", or whatever?]

In my case it would have to be "never sees any of my traffic, much less
processes any of it".

>
> You don't have any way to monitor whether your emails are leaking from
> the ISP's spam filtering box (that they also bought in from an external
> supplier) either.

I do, because I don't use any of my ISP's servers, I have my own MX
record and receive my mail by SMTP directly from the senders.

--

Brian
Roland Perry
2008-03-11 11:55:46 UTC
Permalink
In article <47D66F02.6090707-***@public.gmane.org>, Brian Morrison
<bdm-***@public.gmane.org> writes
>>> At the heart of my concern is that the profiler box's software is
>>>written by Phorm and although operated by the ISP I will have no way
>>>to monitor what is being sent to whom and for what purpose.
>> So you don't trust your ISP to have checked that the system is OK?
>
>Not to a sufficiently high degree of confidence, no.

Ok, that's one thing established then.

>> [Which could mean "works the way Phorm claims it does" or "works
>>without infringing you privacy", or whatever?]
>
>In my case it would have to be "never sees any of my traffic, much less
>processes any of it".

But why does it matter if a machine sees it, then forgets what it's seen
(but draws a limited conclusion)?

>> You don't have any way to monitor whether your emails are leaking
>>from the ISP's spam filtering box (that they also bought in from an
>>external supplier) either.
>
>I do, because I don't use any of my ISP's servers, I have my own MX
>record and receive my mail by SMTP directly from the senders.

And of course you are sure there's no invisible proxy for outbound mail
(you presumably don't use their SMTP out server)?

So, try to put yourself in the position of someone with your concerns,
but who uses an ISP for email. Would you trust them to operate non-leaky
email servers?
--
Roland Perry
Brian Morrison
2008-03-11 12:10:11 UTC
Permalink
Roland Perry wrote:

>>
>> In my case it would have to be "never sees any of my traffic, much
>> less processes any of it".
>
> But why does it matter if a machine sees it, then forgets what it's seen
> (but draws a limited conclusion)?

Because I cannot be certain that it does forget, nor what it does with
the conclusion drawn.

>
>>> You don't have any way to monitor whether your emails are leaking
>>> from the ISP's spam filtering box (that they also bought in from an
>>> external supplier) either.
>>
>> I do, because I don't use any of my ISP's servers, I have my own MX
>> record and receive my mail by SMTP directly from the senders.
>
> And of course you are sure there's no invisible proxy for outbound mail
> (you presumably don't use their SMTP out server)?

No, I don't. If I were able to I would use an offshore mail injection
point with authenticated SSL, but it's a matter of cost and I can PGP
stuff I want unreadable.

>
> So, try to put yourself in the position of someone with your concerns,
> but who uses an ISP for email. Would you trust them to operate non-leaky
> email servers?

No, because in so many cases it's already been shown that things leak or
are accidentally deleted.

--

Brian
Richard Clayton
2008-03-11 11:40:34 UTC
Permalink
In article <doTWtIhjZm1HFA$***@perry.co.uk>, Roland Perry <***@internetp
olicyagency.com> writes

>In article <47D661ED.8080606-***@public.gmane.org>, Brian Morrison
><bdm-***@public.gmane.org> writes
>>At the heart of my concern is that the profiler box's software is
>>written by Phorm and although operated by the ISP I will have no way to
>>monitor what is being sent to whom and for what purpose.
>
>So you don't trust your ISP to have checked that the system is OK?

I don't think that the average ISP (or even the largest three who are
currently relevant) employs people with the skills (or spare time) to
audit a complex piece of equipment (which probably has many key features
implemented in programmable hardware rather than just software).

Any audit that takes place will be done on the basis of a whitepaper and
a rather bloated .PPT file, and will probably be performed by someone in
the regulatory department with a legal background, rather than by any
sort of technician, let alone someone with a background in security
engineering.

>[Which could mean "works the way Phorm claims it does" or "works without
>infringing you privacy", or whatever?]
>
>You don't have any way to monitor whether your emails are leaking from
>the ISP's spam filtering box (that they also bought in from an external
>supplier) either.

Trust, in the NSA sense means, "this system component can disclose my
data", so these are all trusted components.

The difference with Phorm is their background (which they are at pains
to distance themselves from -- understandably) and that they intend for
data, albeit to some extent sanitised data, to leak.

The latter aspect makes system analysis orders of magnitude harder (you
cannot simplify your view of the system by considering where "data
diodes" prevent particular flows. The former aspect means that it is
hard to give the system engineers the benefit of the doubt, and so you
need to look at every possible aspect :(

- --
richard Richard Clayton

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. Benjamin Franklin
Ian Batten
2008-03-11 11:08:47 UTC
Permalink
On 11 Mar 08, at 1041, Brian Morrison wrote:
> I'm still beginning to consider a VPN to somewhere else as a way of
> obscuring all of this stuff

Presumably one thing would be a uk.crypto.org proxy server, located in
a suitable datacenter, which runs authenticated https-ised squid. A
cabal of us could run it to make mutually certain we're not subverting
it, and it could discard all logs.

ian
Chris Edwards
2008-03-11 12:16:58 UTC
Permalink
On Tue, 11 Mar 2008, Ian Batten wrote:

| Presumably one thing would be a uk.crypto.org proxy server, located in a
| suitable datacenter, which runs authenticated https-ised squid. A cabal of us
| could run it to make mutually certain we're not subverting it, and it could
| discard all logs.

Fine - but would need to accept slightly-impaired response times.

Of course, this assumes that it remains easy to find a suitable datacenter
with phorm-free connectivity...
Simon Davies
2008-03-09 20:16:34 UTC
Permalink
>
> So far presumably it either doesn't require an IP address or only uses it
> initially to identify a new visitor. Now, assuming the IP address and no
> other private data is stored, it only has the cookie to go on, in order to
> look up that person's profile in the Phorm database and extract what it
> needs (advert data?). This means there must be some uniquely identifiable
> signature or something in the cookie.

Targeting is session based, and yes, the cookie has a unique code that Phorm
recognises.

To gather more of the technical detail it's definitely worth checking out a
good patent analysis published at
http://www.politicalpenguin.org.uk/blog/p,295/ as well as Q&A's with Phorm's
CEO and CTO at www.badphorm.co.uk and The Register.
>
> But, if someone deletes cookies after each session, then how can Phorm
> identify that person unless it does something like another IP address
> lookup or something?

Again, as far as I know, there's no IP look-up.
>
Continue reading on narkive:
Loading...