Secure webservices?!

> -----Original Message-----
> From: Paul Johnston [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, September 16, 2003 4:30 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [ cf-dev ] Stopping 'db scrapes'
> 
> 
> Flash can decrypt data... Afaik so encrypt the data in an xml 
> packet... And
> make the key a rotating key (something based on date or 
> something like that)
> and you have automatically created a difficult thing to 
> "scrape" (although
> not impossible but that is the nature of IT... Everything can 
> be reverse
> engineered unless you use one-way encryption algorithms but 
> that's useless
> here because you need to get the data back!)
> 
> Again, cease and desist letter MUST be the first port of call 
> to get the
> legal ball rolling...
> 
> Paul
> 
> > -----Original Message-----
> > From: Peter Harrison [mailto:[EMAIL PROTECTED] 
> > Sent: 16 September 2003 15:46
> > To: [EMAIL PROTECTED]
> > Subject: RE: [ cf-dev ] Stopping 'db scrapes'
> > 
> > 
> > The Flash front end would have to get its data via some URL, 
> > yes? Sniff the URL, ignore the Flash front end and use your own.
> > 
> > The cease and desist letter sounds like JUSTICE! to me. 
> *the mob grows
> > hungry*
> > 
> > - Peter
> > 
> > -----Original Message-----
> > From: Paul Johnston [mailto:[EMAIL PROTECTED]
> > Sent: 16 September 2003 11:01
> > To: [EMAIL PROTECTED]
> > Subject: RE: [ cf-dev ] Stopping 'db scrapes'
> > 
> > 
> > And they just "simulate" registrations...
> > 
> > It's pretty easy to get around when a company is using a 
> > program to simulate clicks...
> > 
> > However, there is one possibility...
> > 
> > How about sending the data as XML and having an external XSL 
> > stylesheet, and if the user is using IE 6 then you can do the 
> > HTML creation on the client side... That way the java applet 
> > MAY get confused (it may not take long to get round though)...
> > 
> > Other than that, the simulated HTTP GET/POST statements must 
> > be in some common format?  Maybe check for that common format 
> > in some way and if it appears to be from the applet, then 
> > dump the request...?  This can of course be got around!
> > 
> > I still think creating a Flash front end for the search 
> > results may provide you with more protection (although it 
> > means flash being used on the site which may or may not be 
> > worthwhile)...  That way a scrape is a lot more difficult.
> > 
> > Erm...
> > 
> > Cease and Desist letter at same time would probably be 
> > effective too! Btw... It is very easy to write a flash 
> > checker to see if a user has flash installed and most do.  
> > That way you would have two versions of the relevant bits (ie 
> > search results and house details for example) BUT you would 
> > stop plain old HTML scraping occurring.
> > 
> > Paul
> > 
> > > Oih dear. That's very sneaky.
> > > Perhaps a registration to access the site is required then
> > >
> > > > -----Original Message-----
> > > > From: Rich Wild [mailto:[EMAIL PROTECTED]
> > > > Sent: 16 September 2003 10:30
> > > > To: '[EMAIL PROTECTED]'
> > > > Subject: RE: [ cf-dev ] Stopping 'db scrapes'
> > > >
> > > >
> > > > > Not if the URL is not on any of the pages.
> > > >
> > > > What I'm saying is that if a page is available to a 
> > normal user of 
> > > > Peter's site with a normal browser without having to sign 
> > in, then 
> > > > the competitor will be able to get that page also, no 
> matter what 
> > > > you do.
> > > >
> > > > They're not linking to any pages, they're using a java 
> applet to 
> > > > simulate a user clicking and submitting search forms and then 
> > > > they're scraping the results. Hence if a user can see the 
> > data, then 
> > > > so can their java applet, no matter what you put in the url.
> > > >
> > > >
> > > > --
> > > > ** Archive:
> > > http://www.mail-archive.com/dev%> 40lists.cfdeveloper.co.uk/
> > > >
> > >
> > > > To unsubscribe, e-mail:
> > > [EMAIL PROTECTED]
> > > > For additional commands, e-mail: 
> [EMAIL PROTECTED] 
> > > > For human help, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > ** Archive: 
> > http://www.mail-archive.com/dev%> 40lists.cfdeveloper.co.uk/
> > >
> > 
> > > To unsubscribe, e-mail: 
> > [EMAIL PROTECTED]
> > > For additional commands, e-mail: 
> > [EMAIL PROTECTED] For 
> > > human help, e-mail: [EMAIL PROTECTED]
> > >
> > 
> > 
> > 
> > --
> > ** Archive: 
> http://www.mail-archive.com/dev%> 40lists.cfdeveloper.co.uk/
> > 
> 
> > To unsubscribe, e-mail: 
> [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > For human help, e-mail: [EMAIL PROTECTED]
> > 
> > 
> > -- 
> > ** Archive: 
> http://www.mail-archive.com/dev%> 40lists.cfdeveloper.co.uk/
> > 
> 
> > To unsubscribe, e-mail: 
> [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > For human help, e-mail: [EMAIL PROTECTED]
> > 
> 
> 
> 
> -- 
> ** Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/
> 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> For human help, e-mail: [EMAIL PROTECTED]
> 
> 



-- 
** Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
For human help, e-mail: [EMAIL PROTECTED]

Reply via email to