FW: Brainfood – Adbutler

This is a multipart message in MIME format.

——=_NextPart_000_003D_01DAA6AF.D2CE3D30
Content-Type: multipart/alternative;
boundary=”—-=_NextPart_001_003E_01DAA6AF.D2CE3D30″

——=_NextPart_001_003E_01DAA6AF.D2CE3D30
Content-Type: text/plain;
charset=”utf-8″
Content-Transfer-Encoding: quoted-printable

Please =CE=B5=CE=BD=CE=B7=CE=BC=CE=B5=CF=81=CF=89=CF=83=CE=B5 =
=CE=BC=CE=B5 =CE=B1=CE=BD =CE=BB=CF=85=CE=B8=CE=B7=CE=BA=CE=B1=CE=BD =
=CE=BF=CE=BB=CE=B1 =CE=BC=CE=B5 =CE=B1=CF=85=CF=84=CE=B1 =
=CF=80=CE=BF=CF=85 =CF=83=CE=BF=CF=85 =
=CE=B5=CF=83=CF=84=CE=B5=CE=B9=CE=BB=CE=B5

=CE=95=CE=B4=CF=89 =CE=BA=CE=B1=CE=B9 =CE=B7 =
=CE=B1=CF=80=CE=B1=CE=BD=CF=84=CE=B7=CF=83=CE=B7 =CF=84=CE=BF=CF=85

=CE=A4=CE=B7=CE=BD =CE=BF=CF=80=CE=BF=CE=B9=CE=B1 =
=CF=86=CF=85=CF=83=CE=B9=CE=BA=CE=B1 =CE=B4=CE=B5=CE=BD =CE=B8=CE=B1 =
=CE=BA=CE=B1=CE=BD=CF=89 =CE=B4=CE=B5=CE=BA=CF=84=CE=B7

=20

=20

Tasos Vogiatzis

Managing Director

=20

www.brainfoodmedia.gr | =
www.brainfood.gr=20

Alfavita.gr | Allyou.gr | Avopolis.gr | Botrini.gr | Childit.gr | =
Glykouli.gr

Enwsi.gr | Epixeiro.gr | Platform.gr | Tetrapodo.gr | Thecaller.gr | =
Theopinion.gr

=20

P. 212-1056743 | M: +306940715510

=20

=20

From: Rob Janes =20
Sent: Tuesday, May 14, 2024 10:46 PM
To: Tasos Vogiatzis
Cc: Mark Webster ; Rob Janes =
; nickh@brainfoodmedia.gr; =
ge.michalopoulos@brainfoodmedia.gr
Subject: Re: Brainfood – Adbutler

=20

Tasos, we appreciate your detailed response and understand your =
frustrations. We share your sense of urgency.

=20

However, there might be some misunderstandings or miscommunications =
about the roles and responsibilities of different platforms in your tech =
stack.

=20

First, let me cover the consent and ad-serving side of things and TCF.

=20

If a user does not give consent under the Transparency and Consent =
Framework (TCF), a consent string (also known as a TC string) will still =
exist, but it will reflect the user’s choices. The consent string is a =
standardized way to encode and transmit the user’s consent preferences, =
and it is essential for communicating these preferences across the ad =
tech ecosystem.

=20

The consent string encodes the user’s choices regarding the processing =
of their personal data, including whether they have given or withheld =
consent for various purposes and to specific vendors.

=20

When a user does not give consent, the consent string will indicate =
this. It will have specific bits to show that consent is not granted for =
certain processing purposes and vendors.

The string may also include the user’s choices regarding legitimate =
interest claims, where applicable.

=20

A Consent Management Platform (CMP) generates the consent string based =
on the user’s interactions with the consent notice. The CMP encodes the =
user’s preferences into the consent string, whether those preferences =
include granting or denying consent.

=20

The consent string is passed along with ad requests to the ad server to =
ensure that all parties in the ad delivery chain (advertisers, DSPs, =
SSPs, ad exchanges, etc.) can interpret and respect the user’s =
preferences.

=20

Ad tech vendors use the consent string to determine whether they can =
process personal data for targeted advertising, tracking, and other =
purposes. Consent is based on tracking of personal data and is =
independent of the =E2=80=98serving=E2=80=99 of ads.

=20

This is how AdButler is built by design. We accept the consent string =
and then pass it along to your demand sources to let them determine =
whether or not they want to participate in this auction based on the =
user’s consent decision.

=20

AdButler was listed as a TCF vendor for many years but withdrew in =
February of 2022 when Belgium and other companies decided that the TCF =
spam regulations were illegal. While this had been resolved in 2023, we =
had not opted to renew our TCF registration.

=20

As TCF is a framework that uses self-attestation, our platform was and =
remains fully TCF compliant by passing along the consent string to =
demand partners. However, we did not renew registration with the IAB to =
be listed on the TCF vendor list. We can certainly revisit this, as we =
think it makes sense from a business perspective to be included on this =
list once again. Still, I want to reiterate that it does not change =
functionality in AdButler as we are already TCF compliant.=20

=20

The biggest takeaway here may be a misunderstanding regarding your =
expectations of the ad server vs. the principles of GDPR and TCF. TCF =
is around tracking the user and demand partners using their personal =
data to show targeted ads, but it does not mean that all ads are =
prevented. That=E2=80=99s why AdButler sends the consent string and the =
bid request to our demand partners. If the user wanted to avoid ads =
altogether, they wouldn=E2=80=99t use =E2=80=98consent=E2=80=99 as a =
means of blocking ads; they would use an ad-blocker.=20

=20

Steps Forward

=20

As for steps forward, I think your two options make sense, and we would =
certainly like to continue working with you.

=20

Option 1 – Continue the Agreement with the following understanding:

1. AdButler will not issue another invoice until the successful OpenRTB =
request between AdButler AdForm works as intended. (This should be =
good to go; we=E2=80=99ve modified PMP deals as well. I will send a =
follow-up technical email)
2. We will give an additional 30-day grace period after that time in =
which we will not issue a bill.
3. As you requested, we will credit the account with $1250 towards the =
first bill for the prepaid priority support over the holidays.
4. AdButler plans to participate in the vendor list for TCF again, =
though the timeline will depend on the IAB EU’s review and approval.
5. AdButler has implemented a feature where if the user has given =
consent for purposes 1, 2, 3, 4, and 7 of the TCF framework, we will =
execute the decision logic as usual. However, if the user has not given =
consent to any of these purposes, AdButler will not perform any decision =
logic and will return no ads at all, including direct, non-personalized =
ads. This means if the user does not consent, no ads from Brainfood will =
be served, regardless of whether they are programmatic, direct, =
self-serve, etc. I=E2=80=99ve included a quick summary table at the =
bottom outlining consent purposes according to the TCF.

Option 2 – Termination of Agreement:

It does sound like you=E2=80=99ve already vetted Epom, and we understand =
and respect your decision to switch. We will reimburse you for your =
prepaid amount to date and terminate the partnership here.

=20

=20

TCF Consent Purposes for Reference in Option 1.5:

Purpose Consents (10)

[1] Store and/or access information on a device: true

[2] Use limited data to select advertising: true

[3] Create profiles for personalized advertising: true

[4] Use profiles to select personalized advertising: true

[5] Create profiles to personalize content: true

[6] Use profiles to select personalized content: true

[7] Measure advertising performance: true

[8] Measure content performance: true

[9] Understand audiences through statistics or combinations of data from =
different sources: true

[10] Develop and improve services: true

=20

Purpose Legitimate Interests (9)

[2] Use limited data to select advertising: true

[3] Create profiles for personalized advertising: true

[4] Use profiles to select personalized advertising: true

[5] Create profiles to personalize content: true

[6] Use profiles to select personalized content: true

[7] Measure advertising performance: true

[8] Measure content performance: true

[9] Understand audiences through statistics or combinations of data from =
different sources: true

[10] Develop and improve services: true

=20

=20

Let me know which option you decide.

=20

-Rob

=20

=
=20

=20

_____ =20

=20

Rob Janes

Head of Product

Find me on Social Media!
Tweets by TheRobJanes
https://www.linkedin.com/in/robert-alexander-janes/

=
=20

AdButler =20

rob@adbutler.com =20

=20

=20

=20

Sent via Superhuman =20

=20

=20

On Tue, May 14, 2024 at 3:25 AM, Tasos Vogiatzis <tv@brainfoodmedia.gr =
> wrote:

Dear Mark and Rob,

=20

After several unsuccessful attempts (emails on March, April 4, 11, etc) =
to let you understand the seriousness of the situation, but also to find =
an overall solution for the 6 months’ prepayment (which of course is -in =
no way- your assurance that we will not be billed further in these 6 =
months, for something that we have already been invoiced for and paid!) =
and based on Rob’s last email (which ends in =E2=80=9CAs it stands at =
the moment, everything from the AdButler side, except for the PMP deal =
ID field from AdButler is working as expected=E2=80=9D), I am forced to =
state and list all details and evidence of what has happened the last 5 =
months and the progress. The picture presented by you is rather =
embellished -to say the least- and in no way even comes close to the =
reality of a working adserver/SSP that we should have had in our hands =
for 5 months now.=20

=20

Unfortunately, I have spent a lot of hours and days (off my valuable =
time) to note and explain all facts, developments, issues – firstly =
internally, to my partners, and secondly/mainly to you. The reason is =
that no matter how many friendly/unofficial/personal attempts have been =
made on my part, either to explain the magnitude of the damage/losses of =
the company from the unresolved issues and the delay, or to find a =
compromise solution for the prepayment (which was surely a big mistake =
from our part), or to push for faster delivery of an ad server that will =
work on (basic and non basic features) what we have agreed on from day 1 =
and not month 5, not only are they not appreciated, but they go =
unnoticed, at least in terms of their substance and what should follow =
in terms of speed of resolution, attitude towards the customer (which =
not is of course not =E2=80=9Cworking as expected=E2=80=9D on the 5th =
month) and of course in the commercial part, in which we have =
practically prepaid millions of requests, without recompense.=20

=20

What we have agreed and prepaid

=20

January (1 to 31)

Priority team on your side so that any issues can be addressed promptly.
[=E2=80=9CFirstly, in order to get you set up for at least the initial =
stages for the MVP process, you will need a priority team on our side so =
that any issues can be addressed promptly.]

January

Developing period with 1M requests included

February

Developing period with 1M requests included

March

End of Development =E2=80=93 everything working and beginning (at 1st of =
March) of Testing period on white label / own domain solution
$1500 minimum usage cost PREPAID or request/usage costs according to =
plan (whichever is bigger)

April

2nd month Testing period
$2500 minimum usage cost PREPAID or request/usage costs according to =
plan (whichever is bigger)

May

All network integrated, Prepaid $3000 minimum costs

June=20

All network integrated, Prepaid $3000 minimum costs

=20

=C2=B7 From the 1st day (developing month) we should have had a =
fully working API enabled solution for our development phase.

=C2=B7 We should have had a fully working white-label solution =
on our domain.

=20

Where we are now:

=20

Practically, between the 1st and 2nd month

=C2=B7 In no way end of development (we still can=E2=80=99t =
implement PMP deals)

=C2=B7 In no way everything working (March)

=C2=B7 We can=E2=80=99t be charged for $1500 minimum cost =
PREPAID for requests (March)

=C2=B7 Until mid of April we only had a working demo and not a =
fully working white-label solution on our domain.

=20

We also have paid for 1 month =E2=80=9CPriority team on your side so =
that any issues can be addressed promptly=E2=80=9D and this payment was =
not present at any deal in any email until we saw it in the contract. In =
any case, I agreed to pay these $1250 for the first month, but actually:

=20

=C2=B7 We lost nearly 10 days with your (dedicated?) team being =
absent for holidays and actually there are emails referring to =
=E2=80=9Creduced=E2=80=9D support team for this period

=C2=B7 We never had prompt replies

=C2=B7 Issued were not addressed/resolved or anything promptly.

=20

Several issues (to offer an idea):

1. Sandbox API Access [reported 1/2/2024] – [solved 13/3/2024]

2. Vast 4 Wrapper Bug Ad item [reported 1/2/2024] – [solved =
20/03/2024]

3. Postal Code Targeting [reported 17/1/2024] – Hasn’t been solved =
– We found another way

4. Get Tags with Http bug [reported 1/2/2024] – [solved =
25/04/2024]

5. Get zone tags with http – Since moving the white label =
[reported 25/04/2024] – [solved 2/05/2024]

6. Adbutler Passback code inside Adbutler zone tag not working in =
Native [Hasn=E2=80=99t been solved and we can=E2=80=99t work with =
websites that will have no option of passback in their programmatic =
zones)

7. Get Vast tags through API =E2=80=93 [reported 25/04/24] – =
[solved 13/05/24]

8. PMP deals not working =E2=80=93 blocked by 9

9. Adform RTB rerquest for Vast [reported 12/02/2024] =
=E2=80=93 [solved ???] 10. User syncing issue – [to be solved]=20
and some more, as the domain referrer, the passing of the values to the =
CMP (solved at 10th of May), the gdpr and more.

I understand that you may find several excuses for the lack of =
connection with Adform, but having a fully working white label solution =
with all API features working and ad server / PMP / Open Marketplace is =
something we might expect by the end of the month May hopefully.

(At the end of this email) I will also take the time and space to =
explain some of the existing issues and their importance, because this =
idea/image you present that =E2=80=9Cexcept PMP everything is working as =
expected=E2=80=9D, is not accurate at all. And we can spend hours and =
many lines stating and explaining what has happened all these months and =
why we are in month 1 and not in month 5. In fact, with PMP deals on =
hold, all this discussion would be actually useless, but I will try it.

=20

Losses/Damages assessed until now if we stop the collaboration: $64,000 =
+ $10,750 (prepayment) =3D $75K

=20

* We have a dedicated team of 5 developers, struggling for 5 =
months now

* a dedicated product manager

* A trial with Adform that has been ended and we now pay minimum =
costs

* Commercial losses (campaigns that will not run, one of them was =
the European Parliament campaign commissioned to us by Havas Media) and =
delay losses have yet to be assessed.

=20

Current state

=20

* We have started or restarted discussions and presentations with =
other ad servers (you can see the list at the GDPR compliance part of =
this email)

* Some of them (with Epom first) can cover us in everything, with =
written agreement, from gdpr to pmp connection with adform, real time =
support =E2=80=93and (most important) we don=E2=80=99t even need to pay =
brid.tv for the video player, they have a natively =
working video player.

* A part of our development team is studying their API and =
evaluating and the others are still committed to this

=20

Solutions

=20

Mainly based on the options you offer in your April email, there are two =
roads:

=20

=C2=B7 Stop the collaboration, terminate the agreement as you =
propose, and we lose 5 months work and 5 months time, plus 2 months in =
order to evaluate/agree/test the next adserver/white label SSP. This =
internal damage has been assessed at about $100K. As the management team =
and partners are not willing to throw away these months of work, the =
decision is (if we are led to this solution) to proceed with a detailed =
evaluation of the whole situation and the damages and surely not to lose =
$100,000 and 7 months of work just like that. It might be very simple =
for you to just disconnect everything, but (believe me) it won=E2=80=99t =
be so easy for me (personally, as I believed in this collaboration and =
presented it as the best possible) and mainly for the company.=20

=20

=C2=B7 Go on with current collaboration and=20
a. Have all issues resolved until the end of the month (31th of May),=20
b. Written acknowledgment that from June 1st we will practically be on =
February 1st of our contract, which means an extension of our contract =
from June 30th to November 30th. It is understood that all prepayments =
(which essentially concern requests) do not include income from Open =
Marketplace and PMP deals for which you will normally receive the rates =
we have agreed (3% up to 100000 etc.)
c. =CE=99ssue of credit invoice and refund for the $1250 of dedicated =
and prompt support that never came. Alternatively, and if everything is =
working as expected, we can use it as a deposit/amount for your =
(hopefully) rates payment for the Open Marketplace.

=20

At this stage, and after what has gone before, we cannot be left without =
options, therefore we proceed with both scenarios.

Firstly, we will wait until the end of the week for your feedback, =
agreement (or/and solutions), and secondly, in any case, even in the =
scenario of continuing our collaboration, we have to wait for all the =
issues to be resolved – even now.

In case they are not resolved, or further delayed due to your obvious =
lack of development and support staff, to my great dismay, I have no =
option than to protect my company. You would do that in my position too.

And in your position, if all this had happened from our part (in any =
client), I wouldn’t put so simply on the table the option of simply =
terminating the contract and return the prepayment. It will be a complex =
and arduous process, in which no self-respecting company is going to =
walk away from whatever (big) damage they have suffered. I think you may =
understand that.

=20

Explaining 2 of the issues and why we can=E2=80=99t collaborate without =
their solution.

=20

GDPR compliance

=20

The purpose of CMP is to ask for a visitor’s consent(s), store it, and =
pass these consents to an ad server. Most publishers at this moment in =
Europe use CMPs compatible with the technical standard of the IAB =
Transparency and Consent Framework (TCF v2). The ad server will get =
consent from CMP and change its behavior accordingly. Full support of =
CMPs and GDPR compliance means that the ad server is not only passing =
and accepting parameters, but cooperates and supports consent management =
platforms (CMPs) compatible with the technical standard of the IAB =
Transparency and Consent Framework (TCF).

Moreover (if have been implemented might have simplified the process), =
the IAB Europe Transparency and Consent Framework (TCF) has simplified =
your/our work with accredited TCF Vendors list. With an annual fee of =
only =E2=82=AC1,575 and a Compliance questionnaire on =
https://iabeurope.eu/join-the-tcf/, Adbutler could have been in the list =
of Global Vendor List (GVL), which is open for Vendors to apply for =
approval to participate in the IAB Europe Transparency and Consent =
Framework (TCF).

Of course, being a member of this Global Vendor List means respecting =
the rules, but this simplifies the process also for publishers, as they =
have the chance by default to handle all IAB approved vendors on their =
CMP and perform actions automatically (blocking/approving), which is =
what it happens right now.

Project Agora, for example, which is a greek programmatic platform, is =
already listed.

Brid is listed for their ad manager / vendor features.

All API enabled / white label ad servers that we were having discussions =
are already registered (Admixer, Exads, Epom, Equativ, Smartyads).

Adbutler is not listed and (additionally or not) does not do anything on =
their side even if consent is not given by the user.

=20

Most important is that all competitors, starting from Google Ad Manager =
and ending up in the companies mentioned before, are fully compliant.

The logic that we record the information but do not do anything (rather =
than pass it back) is not functional. The reason is that although at the =
OpenRTB level this can work (i.e. the demand partner decides whether or =
not to display the ad), at the direct ads level, it cannot work. The =
publisher cannot turn into an ad tech company nor does it have a way to =
cut the ad by itself so that it is not illegal when the user does not =
give consent. We put a burden of tech responsibility on publishers that =
cannot be attributed in any case and that other ad managers offer.

So, we fully cancel all direct ad capabilities, which is the main =
purpose of an adserver.

=20

Finally, on our discussions this week with Epom, we understand that the =
ad server (at least theirs), does not throw away the consent information =
or just pass it back, but they have a settings feature where the user =
can decide to display or not a banner ad if the user hasn=E2=80=99t =
given their consent. Be sure that most publishers are not only fully =
aware of GDPR laws, but they won=E2=80=99t be willing to use an ad =
server that does display ads without consent =E2=80=93 they =
won=E2=80=99t risk any action that will put them into a danger of very =
large fines. Practically, our ad server is useless in Europe for =
publishers that would like to use it out of the box.

=20

SSP / Programmatic

As you already know, the main use of the adserver in our case is the SSP =
feature. As we already have a network fully working on PMP deals and =
Open Marketplace on Vidverto, we can’t transfer any site into our =
platform, not only if extensive tests will have been made, but firstly =
if we are ensured that both Open Marketplace and PMP deals are working. =
Finally, web development without being able to have data cannot be put =
in serious progress.=20

As for the second part (PMP Deals), which is the main point of our =
collaboration with Adform, as it was already a demand partner / PMP ad =
tech provider for PMP deals through Vidverto, you have admitted that (on =
our 5th month) is not working and we are waiting for a solution.

As for the first part (OpenRTB), there are 2 different cases:

=C2=B7 Display campaigns. =E2=80=9CIf the adserver has already =
identified an AdForm user ID for this user, it will pass that ID into =
the OpenRTB request. If we do not have an AdForm user ID for this user, =
this request will cookie-sync the user so that all subsequent requests =
will have that user=E2=80=99s ID=E2=80=9D. So, this means that for the =
first visit, the user will not be available for OpenRTB requests. Losing =
this inventory opportunity us totally unacceptable. Just to give you an =
idea of what this means, we quote the numbers from google analytics of =
one of the sites we work with, for the last 4 weeks (28 days report from =
GA):

=09
Total

Unique

page_view

8.704.986

2.403.807

=09

session_start

6.866.302

2.439.859

=09

user_engagement

6.628.517

1.814.244

=09

first_visit

1.598.929

1.271.643

=09

=20

=C2=B7 1,271,643 out of 2,403,807 total users visited the site =
for the first time. This is 47%. Some of them will not have the chance =
to see a single ad if they are in the bounce rate portion. Would you be =
willing to lose all this ad traffic, especially if you are already in a =
platform that doesn’t have this limitation? In this case we are a weak =
competitor to our own existing platform and the whole commercial model =
will surely collapse. Moreover, this corresponds to at least 17% loss of =
income from lost advertising inventory, which is much more actually as =
loss, as unique users make the difference and not many repeated =
impressions.`

=C2=B7 VAST campaigns. Out of the Box and Industry Standard you =
suggest: The out-of-the-box and industry solution here that is the way =
it=E2=80=99s solved by other publishers using any ad platform is a =
cookie-syncing pixel placed on the publisher page before any other ad =
calls. This pixel syncs the user, and all other ad calls can read that =
cookie.=20

=20

The problem there is that we limit the use of the platform as a fully =
working ad server (which clearly does not do the job, as already =
specified and explained), built on the publisher. Actually, it =
doesn=E2=80=99t work like that on ad networks that use a portion of the =
ad inventory of the publisher. We are not publishers. In all other =
cases, we have publishers having their own ad server solutions, mostly =
free and fully GDPR compliant (Google Ad Manager). We have a =
collaboration with over 100 publishers, by sending a single zone tag to =
them and this tag is implemented only on the place it needs to be =
inserted. No access or demand to have access on head, which will not be =
acceptable and will have a lot more issues (interfering with their code =
and the lack of implementing simple things on their side), especially =
for a single video ad placements. All, but all, but all, video ad =
monetization services we know do not place anything on the head, nor =
wait until the second view/request to be able to sync the user. =
Moreover, the second solution (sneaking AdButler user syncing pixel into =
one of the VAST tracking event URLs, so when one of the VAST tracking =
events gets fired, as an example, the =E2=80=9CVideo Start=E2=80=9D =
event, we can also call our user sync URL and sync the user. This means =
all subsequent ad requests would include the AdForm user ID) means that =
the first ad request for a unique visitor to a page will not be synced =
to that AdForm user, so we lose also the first impression in times of =
inventory, which is also a 17% (all inventory) / 47% (first visit) loss. =
=20

=C2=B7 =CE=91 very rough but not completely correct (*) solution =
would be to set the user sync cookie to fire in all Open Marketplace and =
PMP enabled zones (even on native that serve video player / Brid tag) as =
a tag/pixel before anything else happens. This would solve the display =
and native issue as there would always be pre-recognition, it would =
solve the brid video player issue as there would always be =
pre-recognition but it would not solve the issue in vast campaigns that =
would play by users with another player. But we can live with that, as =
we want Open Marketplace and PMP deals for VAST campaigns to be =
implemented through our video player (Brid).=20

=C2=B7 But, it is very important to avoid useless requests, so =
Adbutler could by default recognize (for positions that are Open =
Marketplace and PMP enabled) the new user (frequency cap 1), and call =
Adbutlers user sync URL and sync the user.

=20

* This is not a completely correct (*) solution as we will have to add =
this user sync URL call for every DSP we will collaborate. At this stage =
it’s only Adform, but the purpose of the SSP is to collaborate with many =
DSPs, so in this case we would have to add a pixel from all providers =
before the first view.

=20

=20

=20

=20

Tasos Vogiatzis

Managing Director

=20

www.brainfoodmedia.gr | =
www.brainfood.gr=20

Alfavita.gr | Allyou.gr | =
Avopolis.gr | Botrini.gr | =
Childit.gr | Glykouli.gr =20

Enwsi.gr | Epixeiro.gr | =
Platform.gr | Tetrapodo.gr =
| Thecaller.gr | Theopinion.gr =
=20

=20

P. 212-1056743 | M: +306940715510

=20

=20

——=_NextPart_001_003E_01DAA6AF.D2CE3D30
Content-Type: text/html;
charset=”utf-8″
Content-Transfer-Encoding: quoted-printable

v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}